Analiza i projektowanie aplikacji 3. 4.Modelowanie struktury. Diagram klas. 5.Strukturalizowanie modelu PU. Model systemowych PU.

Podobne dokumenty
Modelowanie obiektowe systemów

Plan wykładu 2. Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja

Język UML w modelowaniu systemów informatycznych

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie obiektowe - Ćw. 3.

Diagramy przypadków użycia

Projektowanie systemów informatycznych. Diagramy przypadków użycia

Diagramy klas. WYKŁAD Piotr Ciskowski

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

TECHNOLOGIE OBIEKTOWE. Wykład 3

Modelowanie danych, projektowanie systemu informatycznego

Podstawy programowania III WYKŁAD 4

Diagram maszyny stanowej - POJĘCIA

Diagramy klas. dr Jarosław Skaruz

Świat rzeczywisty i jego model

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

1 Projektowanie systemu informatycznego

Rysunek 1: Przykłady graficznej prezentacji klas.

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Diagram przypadków użycia

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie obiektowe

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Podstawy języka UML UML

Inżynieria oprogramowania II

Podstawy projektowania systemów komputerowych

MAS dr. Inż. Mariusz Trzaska

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Systemy informatyczne. Modelowanie danych systemów informatycznych

Modelowanie i analiza systemów informatycznych Spis treści

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Narysować diagram sekwencji pokazujący rejestrację wypożyczenia przez Jana Kowalskiego książki Potop

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

UML w Visual Studio. Michał Ciećwierz

UML - zarys 2007/2008

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Spis treúci. 1. Wprowadzenie... 13

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Język UML w modelowaniu systemów informatycznych

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Podstawy modelowania w języku UML

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Tworzenie warstwy zasobów projektowanie metodą strukturalną

UML. zastosowanie i projektowanie w języku UML

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

UML cz. II. UML cz. II 1/38

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

MODELOWANIE OBIEKTOWE

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Agenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Projektowanie systemów informatycznych

KatMPBSoft - 1 -

Inżynierski Projekt Zespołowy

Specyfikowanie wymagań przypadki użycia

IX Konferencja Informatyki Stosowanej

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Programowanie obiektowe

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Język UML. dr inż. Piotr Szwed C3, pok

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Język UML. dr inż. Piotr Szwed C3, pok

Faza analizy (modelowania) Faza projektowania

Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp Podziękowania...

Programowanie obiektowe

Modelowanie i Programowanie Obiektowe

MODELOWANIE PRZEPŁYWU DANYCH

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Podstawy języka UML UML

Podstawy inżynierii oprogramowania

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

SPECYFIKACJA WYMAGAŃ

UML 1 diagramy interakcji

UML cz. I. UML cz. I 1/1

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Paweł Kurzawa, Delfina Kongo

Instrukcja poruszania się po katalogu on-line

PRAKTYKI USOS 6.1.0

Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.

Program Partnerski Junkers Platforma

Transkrypt:

Analiza i projektowanie aplikacji 3 4.Modelowanie struktury. Diagram klas. 5.Strukturalizowanie modelu PU. Model systemowych PU. 6.Metodyka ZP/RUP o modelowaniu biznesowym i wymaganiach do SI. 1

Obiekty i klasy Obiekt: byt o dobrze określonych granicach, który ma tożsamość, cechy statyczne (wartości atrybutów i związki z innymi obiektami), które określają jego stan oraz cechy dynamiczne, które określają jego zachowanie. Obiekt łączy w sobie dane i funkcje. rekućkonto:konto numer:231 właściciel: Ludmiła Rekuć saldo: 300.00 :Student indeks:122231 nazwisko: Kowalski imie: Jan księgowość 2

Obiekty i klasy Klasa: reprezentacja wspólnych cech grupy obiektów, które mają takie same właściwości, stany, zachowanie, związki i znaczenie. Obiekt jest egzemplarzem (instancją, wystąpieniem, urzeczywistnieniem) klasy. Konto numer:int właściciel:string saldo: double depozyt() wypłata() Nazwa klasy jest obowiązkowa Sekcja atrybutów (opcjonalna). Atrybut: nazwana właściwość związana z dziedziną wartości. Uwaga! Wartość atrybutu może byc typu prostego, być obiektem innej lub tej samej klasy, być zbiorem obiektów. Sekcja operacji (opcjonalna). Operacja: nazwana usługa realizowana przez obiekt. 3

Identyfikacja klas Dziedzina wiedzy Nazw a atrybut1 atrybut2 atrybut3 oper1() oper2() rzeczowniki rzeczowniki - dopełniacze. czasowniki. 4

Związki klas - powiązanie Powiązanie(asocjacja) Zespół 0..1 członek 2..* Osoba Powiązanie klas wskazuje na związek między ich obiektami oznaczane jest linią ciągłą; może mieć nazwę z ewentualnie dodanym kierunkiem odczytu; ma końce (dwa lub więcej) wskazujące na klasy; końce mogą być oznaczone nazwami ról, w których występują w związku obiekty danych klas; na końcu związku może być pokazana liczebność (krotność), która wskazuje, ile obiektów danej klasy może być związana z jednym obiektem po drugiej stronie powiązania (tylko w związkach binarnych, wiążących dwie klasy). 5

Powiązanie Oznaczenie liczebności:...z jednym obiektem danej klasy może być związany:. 0..1 jeden lub żaden, opcjonalne powiązanie; 0..* jeden, wiele lub żaden, * wiele lub żaden, wskazuje na niedokładność zbadania; 1..* jeden lub wiele; 1 tylko jeden; Brak wiele lub żaden, wskazuje na niedokładność zbadania;(w UML1.5 - tylko jeden). Miasto 1 od * Trasa 1 do * 6

Klasa powiązania Firma * 1..* Osoba pracodawca pracownik Zatrudnienie wynagrodzenie zawrzyjumowę Powiązanie, które ma własne atrybuty i/lub operacje może być modelowane jako klasa. 7

Klasa powiązania Klasa powiązania Student * zalicza * Kurs 1 klasa powiązania Zaliczenie ocena * 1 Indeks 1 8

Klasa zwykła zamiast klasy powiązania: Firma /pracuje dla Osoba Pracodawca Pracownik 1 * 1 * Stanowisko 0..1 Kierownik powiązanie zwrotne 1.. * Podwładny Kieruje 9

Agregacja: związek całość składa się z części lub właściciel i jego własność * * 1 Zdjęcie Osoba * DowódTożsamości Agregacja słaba (współdzielona) - pewien obiekt może należeć do wielu innych, jest częścią wielu, oznacza się niewypełnionym rombem po stronie "całości. Agregacja całkowita - kompozycja - wyłączna własność całości nad częścią; czas życia "części" nie może być dłuższy niż czas życia "całości", oznacza się wypełnionym czarnym rombem po stronie "całości"; 10

Agregacja, przykłady Trasa * 2..* {ordered} Przystanek Faktura 1 1..* PozycjaFaktury 11

Uogólnienie (generalizacja/specjalizacja) Osoba * uczy Student * Wykładowca Uogólnienie: związek między klasą bardziej ogólną (nadklasą) a bardziej specyficzną (podklasą). Podklasa dziedziczy cechy nadklasy: atrybuty operacje związki ograniczenia Podklasy mogą: - dodać nowe cechy do odziedziczonych; - zmienić odziedziczone operacje zapewniając inną treść operacji przy zachowaniu tego samego nagłówka. 12

Uogólnienie przykład Zawodnik nazwisko waga wysokość podajpiłkę() strzelkosza() Obrońca róbprzechwyt( ) róbasystę() Skrzydłowy Środkowy zróbwsad() Źródło: J.Schmuller UML dla każdego, HELION, 2003, str. 63. 13

Ograniczenia (w nawiasach klamrowych) dodatkowe wymagania, które nie udaje się wyrazić za pomocą standardowych konstrukcji diagramu. Mogą one dotyczyć operacji, związku miedzy atrybutami, wartości atrybutów, powiązań i tp. Konto * {XOR} 1 Osoba Zespół członek * {podzbiór} Osoba Konto jest związane z osobą lub z firmą * 1 Firma 1 szef szef jest jednym z członków zespołu Faktura nr data 1 1..* {ordered} podstawa PozycjaFaktury lp symbol ilość {XOR} oznacza, że wystąpienia związków są alternatywne. {Ordered} - na końcu powiązania oznacza, że jeden obiekt danej klasy może być związany z kilkoma obiektami klasy docelowej i obiekty te są uporządkowane. 14

Przykład diagramu klas Egzemplarz * 1 Umiejscowienie nr 1..* Temat nazwa opis * * Dokument 0..1 poprzednik TypDokumentu 1 * tytuł autor datawydania zawartość jest wersją nazwa * * * zawier a 15

Diagram obiektów Na diagramie klas klasy i ich związki. Na diagramie obiektów instancje klas i ich związek w pewnej chwili czasowej. Osoba 1..* pracownik 0..* pracodawca Firma Rekuć:Osoba PWr:Firma Dr inż. Ludmiła Rekuć 16 16

Diagram klas - przykład Przedsiębiorstwo 0..1 Dział 1..* 0..* jest nadrzędnym dla kierownik 0..1 Osoba 1..* AdresKontaktowy Dr inż. Ludmiła Rekuć 17 17

Diagram obiektów PPP SA:Przedsiębiorstwo SPK:Dział PPK:Dział nazwa = "Sprzedaż" nazwa = "Produkcja" SP1:Dział nazwa = "Sprzedaż internetowa" kierownik :Osoba nazwisko = "Kowal" ID = 4389 stanowisko = "Kierownik sprzedaży" :AdresyKontaktowe adres = "Kluczowa 10" Diagram przedstawia obiekty i ich wiązania w konkretnej chwili. Dr inż. Ludmiła Rekuć 18

Strukturalizacja modelu PU Uogólnienie (generalizacja) między aktorami - związek między aktorem bardziej ogólnym (rodzicem) a aktorem bardziej wyspecjalizowanym (dzieckiem). Dziecko dziedziczy role ( a więc i powiązania z PU) rodzica. Dr inż. Ludmiła Rekuć 19 19

Zatwierdzenie ocen końcowych Wprowadzenie ocen cząstkowych Pracownik dydaktyczny Wprowadzenie kryteriuw obliczania oceny końcowej «extend» P rzejrzenie planu zajęć z zarzadzaniem ocenam i «extend» M odyfikacja sprawdzianu P rzejrzenie planu zajęć Uprawniony pracownik dydaktyczny Dodanie sprawdzianu S prawdzenie ocen z zajęć Student Dr inż. Ludmiła Rekuć Wykorzystane źródło: Śmiałek M. Zrozumieć UML2.0 Metody modelowania obiektowego HELION, 2005. 20 20

Strukturalizacja Przypadków Użycia (poszukiwanie i wydzielenie pewnych struktur fragmentów PU) Są trzy główne powody strukturalizacji PU: ułatwienie zrozumienia; ułatwienie wielokrotnego użycia specyfikacji PU; ułatwienie utrzymania modelu. Kiedy należy zająć się strukturalizacją PU? Najlepiej zrobić to po szczegółowym opisaniu możliwych przebiegów PU i ich zrozumieniu. W strukturalizacji wykorzystuje się następujące rodzaje związków PU: zależności: zawierania rozszerzenia uogólnienia (generalizacji/specjalizacji). Dr inż. Ludmiła Rekuć 21 21

Uogólnienie (generalizacja) między PU: dwa lub więcej PU są specjalizacjami abstrakcyjnego, ogólnego PU. Należy skorzystać z uogólnienia, jeśli prowadzi to do uproszczenia modelu, a nie do jego skomplikowania! PU-dziecko: dziedziczy wszystkie cechy rodzica (związki, warunki wstępne i końcowe, kroki podstawowego i alternatywnego przebiegu); może mieć dodane inne związki, warunki wstępne i końcowe, kroki podstawowego i alternatywnego przebiegu zdarzeń; może zamienić cechy odziedziczone własnymi specyficznymi (za wyjątkiem związków). Dr inż. Ludmiła Rekuć 22 22

Jak opisywać na diagramie uogólnione PU? UML tego nie określa. Znajdź Produkt Znajdź Książkę Znajdź CD Styl opisu może być określony wewnętrznym standardem firmy lub zespołu twórców systemu. W przykładzie zastosowano zasadę: jeśli krok zmieniono - został on wyróźniony poprzez napisanie kursywą; jeśli krok dodano: został on wyróźniony poprzez wytłuszczenie. Dr inż. Ludmiła Rekuć 23 23

ID: PU11 Przypadek użycia: ZnajdźProdukt Aktorzy: Klient Warunek wstępny: Przebieg zdarzeń: 1. Klient wybiera "Znajdź produkt" 2. System pyta o kryteria wyszukiwania. 3. Klient wprowadza kryteria. 4. System wyszukuje produkty. 5. Jeśli system znajduje, to 5.1 System wyświetla listę produktów 6. W przeciwnym przypadku 6.1 System komunikuje, że nie znaleziono. Przypadek użycia: ZnajdźKsiążkę ID: PU67 ISA PU11 Aktorzy: Klient Warunek wstępny: Przebieg zdarzeń: 1.Klient wybiera "Znajdź książkę" 2.System pyta o kryteria wyszukiwania książki: autora, tytul, ISBN lub temat. 3. Klient wprowadza kryteria. 4. System wyszukuje książki. 5. Jeśli system znajduje, to 5.1 System wyświetla listę produktów 6. W przeciwnym przypadku 6.1 System komunikuje, że nie znaleziono. Warunki końcowe: Warunki końcowe: Alternatywne przebiegi: Dr inż. Ludmiła Rekuć 24 24

Zależność <<zawiera>> ( ang. <<include>>) między PU Jeśli w PU jest taki fragment przebiegu, że: do zrozumienia PU nie są istotne szczegóły przebiegu tego fragmentu, ważny jest jego wynik, nie sposób realizacji, lub Dr inż. Ludmiła Rekuć jeśli stanowi on wspólny fragment wielu przypadków użycia, można ten fragment wyodrębnić w osobny podprzypadek użycia. Wyodrębniona część jawnie jest częścią PU, zawiera się w nim. Używamy w tym przypadku związku zależności <<include>>. Zależność <<include>> oznacza, że operacje "zawieranego" podprzypadku użycia (strzałka na niego wskazuje) są realizowane zawsze w przypadku zawierającym. Notacja: przerywana linia ze strzałką i tekstem <<include>> (lub spolszczonym <<zawiera>>). 25 25

Zależność zawierania się między PU na diagramie i w opisach: Zamów Produkt <<include>> Znajdź Produkt Przypadek użycia: ZamówProdukt Przypadek użycia: ZnadźProdukt ID: oznaczeniepu11 Aktorzy: Branżysta Warunek wstępny: zalogowany w systemie Przebieg zdarzeń: 1... 2.include (ZnajdźProdukt) 3 ID: oznaczeniepu16 Aktorzy: Branżysta Warunek wstępny: Przebieg zdarzeń: 1...... Dr inż. Ludmiła Rekuć 26 26

Związek zależności <<rozszerza>> ( ang. <<extend>>) między PU Jeśli fragment PU jest opcjonalny i nie jest konieczny do zrozumienia głównego celu PU, można ten fragment wydzielić w osobny podpu i uprościć tym samym strukturę podstawowego. W tym przypadku używamy związku <<extend>>. Podstawowy PU "nic nie wie" o możliwym jego rozszerzeniu. Rozszerzający podpu musi się "powołać" na miejsce w podstawowym PU na tzw. punkt rozszerzenia. Miejsce to jest oznaczone, ale nie ponumerowane, jest między ponumierowanymi krokami! Dr inż. Ludmiła Rekuć 27 27

Zależność rozszerzania między PU na diagramie i w opisach: Zwrot Ksiązki punkt rozszerzenia przeterminowany <<extend>> (przeterminowany) Ukaranie grzywną Przypadek użycia: ZwrotKsiążki ID: PU11 Aktorzy: Bibliotekarz Warunek wstępny: Przebieg zdarzeń: 1. Bibliotekarz wprowadza ID Czytelnika. 2. System wyświetla listę wypożyczonych książek. 3. Bibliotekarz wskazuje książkę zwracaną. <ukaranie grzywną> 4. Bibliotekarz rejestruje zwrot.... Rozszerzający PU: UkaranieGrzywną ID: PU16 Dołączany segment 1: Jeżeli książka przeterminowana: 1. Bibliotekarz wybiera rejestracje zapłaty grzywny. 2. System wyświetla formularz. 3. Bibliotekarz rejestruje opłatę grzywny.... Dr inż. Ludmiła Rekuć 28 28

Strukturalizacja PU PU-1 Przyjmij zamówienie Aktorzy Sprzedawca Warunek wstępny: Podstawowy przebieg zdarzeń: 1. PU rozpoczyna Sprzedawca wybierając odpowiednią opcję. 2. System prezentuje formularz zamówienia. 3. Sprzedawca podaje dane pozwalające zidentyfikować klienta (PESEL lub Nazwisko/Nazwę firmy). 4. System wypełnia formularz zamówienia danymi klienta. 5. Sprzedawca wprowadza pozycje zamówienia. W tym celu dla każdej zamawianej pozycji: 5.1 podaje symbol (z indeksu) lub nazwę produktu. 5.2 system wyszukuje produkt i podaje jego stan; 5.3 sprzedawca potwierdza wybór i podaje ilość; 5.4 system prezentuje wypełnioną pozycję i umożliwia przejście do następnej lub zakończenie. 6. Sprzedawca potwierdza zamówienie. 7. System zapamiętuje zamówienie, rezerwuje zamówione produkty i wraca do poprzedniej opcji. Warunek końcowy: Zamówienie zarejestrowano, produkty zarezerwowano. Alternatywne przebiegi. A1. Nowy klient:ma miejsce po kroku 3, kiedy klient jest obsługiwany po raz pierwszy. Dr 1. inż. Sprzedawca Ludmiła Rekuć wywołuje opcje Nowy klient.... <<zawiera się>> /<<include>> PU-2 Wyszukaj produkt Aktorzy Warunek wstępny: Przebieg zdarzeń: Po wybraniu odpowiedniej opcji system umożliwia podanie nazwy i/lub indeksu produktu, następnie sprawdza stan magazynu i prezentuje wynik. <<rozszerza>> /<<extend>> PU-3 Zarejestruj klienta rozszerzający PU-1 w pkt. Nowy klient Aktorzy Warunek wstępny: Podstawowy przebieg zdarzeń: 1. PU rozpoczyna się wybraniem odpowiedniej opcji po kroku 3 PU-1, jeśli klient po raz pierwszy składa zamówienie. 2. System prezentuje formularz klienta. 3. Aktor podaje nazwisko klienta, PESEL, adres dostarczania zamówionych produktów,...... 29 29

ud Gospodarownie nieruchomościami mieszkania Przeprowadź Dokonaj zakupu Dokonaj Petent Dokonaj zakupu komunalnego gruntu komunlanego wydzierżawienia nieruchomosci Zmień zasady wydzierżawienia nieruchomości sesję rady gminy Uzyskaj dodatek mieszkaniowy Ustal granice podziału dla nieruchomości «extend» Rada gminy 30

Metodyka RUP(ZP) o modelowaniu biznesowym i wymaganiach Analiza środowiska Cel: zrozumienie organizacji i wyrażenie w modelach. Produkty: model środowiska ( architektura, procesy, słownik). Wizja SI... Wymagania Cel: pozyskanie wymagań i wyrażenie w modelu. Produkty: model PU, dodatkowa specyfikacja, rozbudowany słownik. Analiza Projektowanie 31

Metodyka RUP(ZP) o modelowaniu biznesowym i wymaganiach Zbuduj model biznesowych PU Znajdź aktorów SI Znajdź PU SI Nadaj priorytety PU Opisz wstępnie (zrozum) PU Ustrukturalizuj i udokumentuj model PU SI Zbuduj diagram klas dziedziny problemu (kluczowe abstrakcje) Zaktualizuj Wizję i słownik 32

Metodyka RUP(ZP) o modelowaniu biznesowym i wymaganiach Uwaga! Dwa modele PU w procesie wytwarzania SI! Model biznesowych PU buduje się, jeśli procesy organizacji są mało znane, trzeba je zrozumieć, żeby trafniej określić wymagania do systemu informatycznego. Byt typu pracownik modelu biznesowych PU często staje się aktorem w modelu systemowych PU. Nadanie priorytetu systemowym PU Kluczowym, wejściowym artefaktem w ustaleniu priorytetu PU jest Wizja, w której określa się, na czym najbardziej zależy zainteresowanym stronom i wymienia zagrożenia. Możliwe kryteria ustalenia priorytetu PU to: - korzyści uzyskiwane przez zainteresowane strony, - wpływ PU na architekturę, - stopień zagrożenia jaki jest związany z PU. 33

Pytania kontrolne 1. Czy każda klasa może mieć obiekty? 2. Czy każda sekcja definicji klasy jest obowiązkowa? 3. Czy prawdziwe jest twierdzenie: należy pokazać wszystkie atrybuty klasy lub nie pokazywać je wcale? 4. Czy klasa powiązania może mieć związki z innymi zwykłymi klasami? 5. Co dziedziczy podklasa po nadklasie? 6. Czy mogą wystąpić dwa obiekty klasy z takimi samymi wartościami atrybutów? 7. Jakie związki mogą wystąpić między PU? 8. Czy związek uogólnienia może wystąpić między aktorem a PU? 9. Co to jest punkt rozszerzenia? 10.Jaka jest różnica między zwiazkami include I extend? 34