Modelowanie obiektowe - Ćw. 3.

Transkrypt

1 1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas) prezentowały statyczny obraz systemu. Kolejne diagramy, które zostaną omówione, to diagramy ukazujące perspektywę dynamiczną, służące do pokazania w jaki sposób system i jego klasy zmieniają się w czasie. Perspektywa statyczna ułatwia analitykowi komunikowanie się z klientem, z kolei perspektywa dynamiczna pozwala na komunikowanie się z grupą tworzącą oprogramowanie z projektantami i z programistami 1. Jednak ani perspektywa statyczna, ani dynamiczna nie ilustrują zachowania systemu z punktu widzenia użytkownika. Do modelowania systemu z punktu widzenia użytkownika służą diagramy przypadków użycia. DIAGRAM PRZYPADKÓW UŻYCIA Diagram przypadków użycia (diagram PU) to graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej. O przypadku użycia można pomyśleć jak o zbiorze scenariuszy opisujących działanie systemu. Każdy scenariusz to ciąg zdarzeń inicjowany przez osobę, inny system, jakieś urządzenie lub upływ czasu. Byty, które inicjują ciąg zdarzeń, nazywane będą aktorami. Na rys. 1 przedstawiono podstawowe symbole tworzące diagram przypadków użycia. 1 Schmuller J., UML dla każdego. Ujedolicony Język Modelowania wyrażanie związków między klasami w projektowaniu obiektowym, Wyd. Helion, Gliwice 2003

2 2 Rys. 1 Przypadek użycia to specyfikacja ciągu akcji i ich wariantów, które system (lub inna jednostka) może wykonywać poprzez interakcje z aktorami tego systemu. Aktor to spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. Nazwę aktora wyraża się rzeczownikiem (określeniem rzeczownikowym) w liczbie pojedynczej, pamiętając cały czas, że aktor odzwierciedla nie indywidualne obiekty ze świata rzeczywistego, lecz role pełnione przez te obiekty. Związek stanowi semantyczne powiązanie pomiędzy elementami systemu. Na diagramach UML wyróżnić można trzy podstawowe rodzaje związków: asocjację uogólnienie zależność Nazwa związku asocjację uogólnienie zależność: o zawierania o rozszerzania Notacja graficzna Uwaga: Związki asocjacji występują wyłącznie pomiędzy aktorami a przypadkami użycia, związki uogólnienia pomiędzy aktorami lub pomiędzy

3 3 przypadkami użycia, natomiast związki zależności wyłączenie pomiędzy przypadkami użycia. Przykłady 2 : Rys. 2 2 Przykłady z: Schmuller J., UML dla każdego. Ujedolicony Język Modelowania wyrażanie związków między klasami w projektowaniu obiektowym, Wyd. Helion, Gliwice 2003 (str. 77) oraz Wrycza S., Marcinkowski B., Wyrzykowski K., Język UML 2.0 w modelowaniu systemów informatycznych, Wyd. Helion, Gliwice 2005 (str. 38).

4 4 Rys. 3 Zadanie 1: Utwórz w projekcie nowy diagram typu Use Case i nazwij go Diagram PU systemu USOS. Dodaj granice systemu z nazwą: System USOS. Utwórz dwóch aktorów: Student oraz Wykładowca. Dodaj do diagramu 5 przypadków użycia systemu USOS przez Studenta, oraz 3 przypadki użycia dla Wykładowcy. Niektóre PU mogą być wspólne dla obu aktorów. Zależność to taki związek pomiędzy dwoma elementami modelowania, w którym zmiana jednego z nich, niezależnego, wpływa na drugi, zależny. Zależność zawierania Zależność ZAWIERANIA <<include>> przedstawia powiązanie pomiędzy przypadkiem zawierającym (tj. bazowym przypadkiem użycia), a przypadkiem zawieranym (rys. 4). Jest to związek obligatoryjny. Zawierany przypadek użycia nie jest wykonywany samodzielnie, lecz wyłącznie przy odwołaniu się do większego, zawierającego przypadku użycia. Związek zawierania pozwala na wielokrotne użycie ciągu kroków z jednego przypadku użycia wewnątrz innego.

5 5 Rys. 4 Przykład: Rys. 5 Zależność rozszerzania Zależność ROZSZERZANIA <<extend>> przedstawia powiązanie pomiędzy rozszerzanym przypadkiem użycia (tj. przypadkiem bazowym), a przypadkiem rozszerzającym (rys. 6). Związek ten ma charakter opcjonalny. Funkcjonalność reprezentowana przez rozszerzający przypadek użycia może, ale nie musi zostać włączona do rozszerzanego przypadku użycia. Włączenie przypadku użycia rozszerzającego wymaga spełnienie określonego warunku. Związek rozszerzania pozwala na tworzenie nowych przypadków użycia poprzez dodawanie kroków do przypadków już istniejących. Rys. 6

6 6 Przykład: Rys. 7 Zadanie 2: Dodaj do projektu nowy diagram typu Use Case i nazwij go Diagram PU aukcji internetowej. Dodaj granice systemu o nazwie Aukcja internetowa. Dodaj aktora Obserwator. Na podstawie opisu sporządź diagram PU używając związku typu <<include>> oraz <<extend>>: Obserwator aukcji wyszukuje artykuły. Jeśli któryś produkt go zainteresuje może (ale nie musi) wziąć udział w licytacji. Aby wziąć udział w licytacji musi się przedtem zalogować. Związek uogólnienia Związki uogólnienia (ang. generalizations) dotyczą zarówno przypadków użycia, jak i aktorów. Uogólnienie oznacza, że jeden przypadek użycia (aktor) dziedziczy z innego przypadku użycia (aktora) tak jak było to w przypadku uogólnienia klas. Przykłady: Rys. 8

7 7 Rys. 9 Zadanie 3: w zadaniu 1. dodaj aktorów: Student stacjonarny, Student niestacjonarny, Pracownik UWM. Korzystając ze związku uogólnienia dołącz tych aktorów w odpowiedni sposób do diagramu. Zadanie 4: Dodaj do projektu nowy diagram typu Use Case i nazwij go Diagram PU PSSE. Na podstawie poniższego tekstu opisującego fragment działalności Powiatowej Stacji Sanitarno-Epidemiologicznej sporządź diagram PU. Tam, gdzie to zasadne użyj związków generalizacji. Dla ułatwienia przypadki użycia oraz aktorzy zostali wyróżnieni poprzez podkreślenie. Zgodnie z wymogami prawnymi do PSSE w ciągu 24h od rozpoznania należy zgłosić przypadek zachorowania na chorobę zakaźną. Zgłaszającym może być podmiot leczniczy lub laboratorium. PSSE sprawuje także nadzór na realizacją obowiązkowego Programu Szczepień Ochronnych w podmiotach leczniczych wykonujących szczepienia ochronne. Podmioty te mają obowiązek dostarczyć okresowe sprawozdania do PSSE. Wśród sprawozdań wyróżnić można: sprawozdanie ze stanu uodpornienia oraz sprawozdanie ze zużycia szczepionek. MODELOWANIE BIZNESOWE Zrozumienie istoty procesów biznesowych zachodzących w danej organizacji jest podstawą specyfikacji wymagań oraz analizy i projektowania przyszłych systemów informatycznych wspomagających jej działanie.

8 8 Modelowanie biznesowe jest sposobem odwzorowania i dokumentowania procesów biznesowych. Część ze zdefiniowanych procesów biznesowych danej organizacji na pewnym etapie tworzenia systemów informatycznych ulega transformacji w procesy systemowe. Modele biznesowe znajdują zastosowanie przede wszystkim w pierwszej fazie budowy systemu informatycznego wspomagającego działanie organizacji. Organizacja Model biznesowy Model systemowy Diagramy biznesowe są w ujęciu czysto technicznym odpowiednikami diagramów systemowych (omówionych wcześniej). Biznesowe diagramy przypadków użycia mają specjalną notację graficzną: Rys. 10 Diagram kontekstowy Diagram kontekstowy stanowi zestawienie aktorów będących w interakcji z danym systemem. Okazuje się pomocny w identyfikacji zbiorowości aktorów przed sporządzeniem pełnego diagramu przypadków użycia (DPU). Uwaga: w przypadku modelowania biznesowego należy pamiętać, że pracownicy danej organizacji są wewnątrz systemu, więc nie są aktorami.

9 9 Notację graficzną diagramu kontekstowego przedstawia rys. 11. Przykład: Rys. 11 Zadanie 5: dodaj nowy diagram typu Use Case i nazwij go Biznesowy diagram kontekstowy sklepu meblowego. Dodaj granice systemu o nazwie Sklep meblowy. Spośród wymienionych nazw wybierz te (i dodaj do diagramu), które prezentują aktorów biznesowych: Klient, Sprzedawca, Dostawca towaru, Urząd Skarbowy, Personel sprzątający, Operator kart kredytowych. Ćwiczenia opracowane przez mgr Ewelinę Jachimczyk (WNT, UWM Olsztyn) na podstawie: Schmuller J., UML dla każdego. Ujedolicony Język Modelowania wyrażanie związków między klasami w projektowaniu obiektowym, Wyd. Helion, Gliwice 2003 Wrycza S., Marcinkowski B., Wyrzykowski K., Język UML 2.0 w modelowaniu systemów informatycznych, Wyd. Helion, Gliwice 2005 Projektowanie systemów komputerowych notatki w internecie (AGH):