Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Transkrypt

1 Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście od wymagań i analizy do projektu 2. Diagramy interakcji 3. Notacja zapisu diagramów interakcji w UML 2 1

2 Przejście od wymagań i analizy do projektu 3 Od wymagań i analizy obiektowej do projektu obiektowego Faza zbierania wymagań oraz faza analizy obiektowej miała za zadanie dać odpowiedzi na pytania dotyczącego tego jakie są funkcjonalności tworzonej aplikacji oraz jakie są podstawowe pojęcia występujące w dziedzinie, której aplikacja dotyczy ( Do the right thing ). Faza projektu obiektowego ma za zadanie zaprojektować system w sposób poprawny, tak aby w pełni spełniał zebrane wymagania ( Do the thing right ). Podczas realizacji fazy projektowania obiektowego mogą pojawić się nowe wymagania oraz może pojawić się potrzeba modyfikowania wymagań wcześniej zebranych. Faza projektowania nie powinna być zbyt długa (przy dużych projektach przy każdej iteracji powinna zabierać kilka dni). 4 2

3 Czym jest projekt obiektowy? Podczas projektowania obiektowego, tworzony jest logiczny model systemu uwzględniający założenia paradygmatu obiektowego. W Unified Process na model projektu składają się dwa elementy: Diagramy interakcji obrazujące współpracę pomiędzy obiektami realizowaną w celu spełnienia zebranych wymagań, Diagram klas (diagram fazy projektowej) obrazujący klasy oraz związki pomiędzy nimi. Tworzenie tych dwóch elementów jest realizowane równolegle. Tworzenie diagramów interakcji wymaga wiele uwagi i twórczego podejścia poprawne ich tworzenia wymaga opanowania umiejętności przyporządkowywania obiektom odpowiedzialności. Tworzenie poprawnych modeli wymaga również stosowania istniejących zasad projektowych oraz wzorców projektowych (patterns). 5 Projektowanie obiektowe, a tworzenie modeli w UML W fazie projektowania należy odróżnić umiejętność myślenia i projektowania obiektowego od znajomości notacji do tworzenia diagramów w UML. Diagramy tworzone w UML odzwierciedlają procesy które zachodzą podczas fazy projektowania obiektowego, znajomość UML znacząco ułatwia pracę podczas modelowania. Kluczowe w fazie projektowania obiektowego jest umiejętność projektowania obiektowego na którą składają się: Zasady przypisywania odpowiedzialności obiektom, Zasady projektowe oraz wzorce projektowe (patterns). 6 3

4 Diagramy interakcji 7 Diagramy interakcji (1) Diagramy interakcji obrazują w jaki sposób obiekty współpracują ze sobą przy pomocy przesyłania komunikatów. Diagramy interakcji to: Diagramy współpracy (collaboration diagrams), Diagramy sekwencji (sequence diagrams). Diagramy współpracy obrazują współpracę pomiędzy obiektami w postaci grafu w którym obiekty mogą pojawić się w dowolnym miejscu: 8 4

5 Diagramy interakcji (2) Diagramy sekwencji ilustrują interakcję pomiędzy obiektami, w której obiekty umieszczone są jeden obok drugiego: 9 Diagramy współpracy, czy diagramy sekwencji? Zalety Wady Diagramy sekwencji Diagramy współpracy W czytelny sposób przedstawiona jest sekwencja zdarzeń oraz czasowe uporządkowanie przesyłanych komunikatów. Używana notacja jest prosta i czytelna. W dobry sposób obrazowany jest złożone zależności pomiędzy obiektami oraz iteracje. Zapis ekonomiczny jeżeli chodzi o wykorzystywany obszar prostota w dodawaniu nowych obiektów. Niewygodny gdy konieczne jest dodanie wielu obiektów wymaga dużo przestrzeni. Trudna wizualizacja sekwencji przesyłania komunikatów. Bardziej złożona notacja. 10 5

6 Przykład: diagram współpracy 11 Przykład diagramu sekwencji 12 6

7 Znaczenie diagramów interakcji Tworzenie diagramów interakcji obrazuje proces przypisywania odpowiedzialności obiektom. Faza ta wydaje się trudniejsza niż faza tworzenia przypadków użycia oraz modelu wiedzy dziedzinowej. Sugeruje się, aby faza te była realizowana zespołowo, a nie samodzielnie. Dzięki współpracy tworzone diagramy interakcji będą pełniejsze i bardziej poprawne. Nie zakłada się, że diagramy tworzone w fazach początkowych mają być pełne. Przyjmuje się, że będą one mogły być modyfikowane podczas programowania. Wykorzystywanie zasad projektowych oraz wzorców projektowych ułatwia proces tworzenia diagramów interakcji. 13 Notacja zapisu diagramów interakcji w UML 14 7

8 Klasy, instancje, komunikaty W UML używa się tego elementu graficznego na opisanie klasy i instancji. Różnica polega jedynie na użyciu podkreślenia przy nazwie instancji: Sprzedaż :Sprzedaż sprzedaz1:sprzedaż klasa instancja nazwana instancja Składnia zapisu komunikatów: return:= message(parameter : parametertype) : returntype Przykład: wartosc = podajspecyfikacjeproduktu(produkt) wartosc = podajspecyfikacjeproduktu(produkt:produkt) wartosc = podajspecyfikacjeproduktu(produkt:produkt):specyfikacjap 15 Diagramy współpracy: połączenia i komunikaty Połączenie (ang. link) to instancja asocjacji. Pomiędzy dwoma obiektami przy pomocy tego samego połączenia może być przesyłanych wiele komunikatów: 16 8

9 Diagramy współpracy: komunikaty typu self i tworzenie instancji Komunikaty mogą być przesłane od danego obiektu do siebie samego: Do tworzenia nowych instancji dedykowane są metody nazywane create, bądź używany jest stereotyp <<create>>: 17 Diagramy współpracy: numerowanie przepływu komunikatów 18 9

10 Diagramy współpracy: komunikaty warunkowe i wykluczające sięścieżki 1) Komunikaty warunkowe: 2) Wykluczające się ścieżki: 19 Diagramy współpracy: iteracje i pętle 20 10

11 Diagramy sekwencji: połączenia i komunikaty W przeciwieństwie do diagramów współpracy w diagramach sekwencji połączenia nie są reprezentowane! Komunikaty: 21 Diagramy sekwencji: komunikaty typu self 22 11

12 Diagramy sekwencji: tworzenie instancji 23 Diagramy sekwencji: czas życia obiektów i ich usuwanie 24 12

13 Diagramy sekwencji: komunikaty warunkowe 25 Diagramy sekwencji: wykluczające sięścieżki 26 13

14 Diagramy sekwencji: iteracje i pętle 27 14