Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Transkrypt

1 Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy diagramu klas. 2. Zasady tworzenia projektowego diagramu klas. 3. Model implementacyjny. 2 1

2 Projektowy diagram klas 3 Kiedy tworzymy projektowy diagram klas? Projektowy diagram klas (design class diagram DCD) ma za zadanie wizualizować klasy softwarowe (i interfejsy) składające się na tworzoną aplikację. Diagram taki powinien zawierać pełne informacje o klasach: atrybuty, asocjacje, metody. Diagram tworzony jest równolegle z procesem tworzenia diagramów interakcji. Przykład: 4 2

3 Co składa się na projektowy diagram klas Elementy, które są zawarte w projektowym diagramie klas: Klasy, asocjacje i atrybuty, Interfejsy, Metody, Informacja o typie atrybutów, Skierowanie (navigability), Zależności (dependency). W przeciwieństwie do modelu wiedzy dziedzinowej, projektowy diagram klas zawiera klasy softwarowe, a nie pojęcia ze świata rzeczywistego (klasy konceptualne). Nazwa projektowy diagram klas jest skrótem od nazwy diagram klas w modelu projektowym. 5 Model wiedzy dziedzinowej, a projektowy diagram klas (1) Model wiedzy dziedzinowej ma za zadanie wizualizację pojęć (klas konceptualnych) występujących w rozpatrywanej dziedzinie, a nie reprezentację klas softwarowych występujących w tworzonym systemie. Podczas pracy nad projektem, model wiedzy dziedzinowej ma inspirować projektantów do wprowadzania do modelu projektowego klas nazywanych podobnie jak w modelu wiedzy dziedzinowej. Pozwala to na zmniejszanie luki reprezentacyjnej (luki semantycznej) pomiędzy modelem konceptualnym danej dziedziny, a jego reprezentacją w konkretnym rozwiązaniu informatycznym. W projektowym diagramie klas mogą pojawiać się klasy, które nie były wcześniej zawarte w modelu wiedzy dziedzinowej! Klasy takie mogą odnosić się do klas konceptualnych wcześniej nie znalezionych oraz do klas, które nie majążadnego związku z rozpatrywaną dziedziną (nie mają odpowiadających sobie klas konceptualnych w modelu wiedzy dziedzinowej)! 6 3

4 Model wiedzy dziedzinowej, a projektowy diagram klas (2) Klasy o tych samych nazwach w modelu wiedzy dziedzinowej oraz w projektowym diagramie klas oznaczają różne pojęcia. Np. w modelu wiedzy dziedzinowej klasa Sprzedaz oznacza abstrakcję pojęcia ze świata rzeczywistego, które jest rozważane jako kandydat do umieszczenia w tworzonej aplikacji. W projektowym diagramie klas klasa Sprzedaz opisuje komponent softwarowy. 7 Zasady tworzenia projektowego diagramu klas 8 4

5 Identyfikacja klas i dodanie metod W pierwszym kroku tworzenia projektowego diagramu klas analizujemy wszystkie utworzone diagramy interakcji wyszukując pojawiające się klasy. Dla programu POS są to następujące klasy: Kasa, Sprzedaz, KatalogProduktow, OpisProduktu, Sklep, ElementPozycjiSprzedazy, Platnosc Nie wszystkie klasy z modelu wiedzy dziedzinowej znajdą się w modelu projektowym np. klasa Kasjer (w rozpatrywanej iteracji nie ma potrzeby wprowadzanie takiej klasy). Do modelu należy wprowadzić metody, które pojawiają się w diagramach interakcji. 9 Komunikat create Komunikat create jest elementem występującym jedynie w UML i nie występuje jako taki w większości języków programowania. Tworzenie obiektów jest realizowane na różny sposób: w C++ wymagana jest alokacja pamięci, wywołanie operatora new i wywołanie konstruktora, w Javie wywołanie operatora new i wywołanie konstruktora. Ponieważ interpretacje tej metody są różne w różnych językach programowania i ponieważ jest to czynność powszechna i oczywista, w większości sytuacji pomija się w projektowym diagramie klasy metody związane z komunikatem create. 10 5

6 Metody dostępu do danych Metody dostępu do danych to metody pozwalające na czytanie (akcesory), bądź ustawianie (mutatory) wartości atrybutów. W większości języków programowania (C++, Java) przyjmuje się, że wprowadzony jest akcesor i mutator dla każdego atrybutu. Wynika to z faktu deklarowanie atrybutów w sekcji prywatnej (w celu zwiększenia enkapsulacji). W większości sytuacji akcesory i mutatory nie są umieszczane w projektowym diagramie klas. Np. w diagramie klas dla programu POS nie zostanie umieszczona metoda podajcene w klasie OpisProduktu, ponieważ jest to akcesor. 11 Umieszczanie informacji o typach danych W projektowym diagramie klas można umieszczać informację o typach atrybutów, parametrów metod i wartości zwracanych przez metody. Podczas umieszczania tych informacji należy brać pod uwagę odbiorców diagramu: Jeżeli projektowy diagram klas tworzony jest w narzędzie typu CASE z automatycznym generowaniem kodu, pełny i wyczerpujący opis typów danych jest niezbędny, Jeżeli projektowy diagram klas jest tworzony dla programistów tylko w celu zapoznania się z ogólnymi koncepcjami, umieszczanie oczywistych typów danych może utrudniać czytanie modelu; jeżeli na postawie diagramu programiści mają podejmować decyzje dotyczące rodzaju użytych danych szczegółowość diagramu powinna być większa. 12 6

7 Skierowanie (1) Każdy z końców asocjacji posiada rolę, która może być uzupełniona o skierowanie (navigability). Skierowanie informuje, że asocjacja działa tylko w jedną stronę od obiektu źródła do obiektu celu. W większości sytuacji skierowanie zakłada występowanie widzialności typu atrybutowego. 13 Skierowanie (2) Umieszczenie skierowanie przy asocjacji oznacza, że w trakcie implementacji w obiekcie źródło pojawi się atrybut zawierający referencję/wskaźnik do obiektu cel. W związku z powyższym asocjacje na projektowym diagramie klas powinny zawierać skierowania informacja ta ma wpływ na implementację! Informacja dotycząca skierowań odróżnia model wiedzy dziedzinowej od projektowego diagramu klas. Sytuacje sugerujące wprowadzenie skierowania od klasy A do klasy B: A wysyła komunikat do B, A tworzy instancję klasy B, A potrzebuje zachować powiązanie do B. 14 7

8 Skierowanie (3) 15 Skierowanie (4) 16 8

9 Relacja zależności (1) W UML można opisać informację o relacji zależności (dependency), która wskazuje, że jeden element posiada wiedzę na temat innego elementu. Relacja ta jest wykorzystana do opisu widoczności nie atrybutowych. Widoczność atrybutowa jest opisywana przy pomocy asocjacji. Zależność jest wizualizowana w UML przy pomocy przerywanej linii zakończonej strzałką. 17 Relacja zależności (2) 18 9

10 Model implementacyjny 19 Czym jest model implementacyjny Unifed Process określa jako Model Implementacyjny wszystkie byty tworzone podczas fazy kodowania: kod źródłowy, model bazy danych, uszczegółowione diagramy klas itp. Podczas tworzenia modelu implementacyjnego byty abstrakcyjne opisane w projektowym diagramie klasy oraz w diagramach interakcji są przenoszone do kodu w obiektowym języku programowania. Kodowanie w języku obiektowym nie jest częścią procesu analizy i projektowania obiektowego, jest tylko celem tego procesu. Przenoszenie wyników analizy i projektowania obiektowego do kodu nie jest jedynie mechanicznym ich przełożeniem!! Wynik analizy i projektowania obiektowego powinien być traktowany jako niekompletny pierwszy krok, który dopiero w trakcie programowania i testowania doprowadzi nas produktu ostatecznego dla danej iteracji

11 Zmiany kody, a proces iteracyjny (1) Poprawnie zbudowany model będący wynikiem fazy analizy i projektowania oraz odpowiednio dobrany proces iteracyjny powinien zapewniać wygodne iteracyjne konstruowanie aplikacji. Przyjmuje się, że kod uzyskany podczas danego przyrostu powinien być punktem wyjścia do wszystkich etapów kolejnego przyrostu: Analiza wymagań Analiza wymagań Analiza wymagań Analiza i projekt Analiza i projekt Analiza i projekt Implementacja i testowanie Implementacja i testowanie Implementacja i testowanie Pierwszy przyrost Drugi przyrost Trzeci przyrost Zmiany kodu, a proces iteracyjny (2) Podczas implementacji w procesie iteracyjnym należy pamiętać o tym, że kod uzyskany w wyniku n-tej iteracji różni się przeważnie od modelu z n-tej iteracji podczas implementacji wprowadzone są do kodu wszelkie niezbędne zmiany dotyczące struktury modelu. Ważnym problemem jest więc zsynchronizowanie modelu opisanego w diagramie projektowym z modelem, który de facto jest opisany w kodzie po zakończeniu danego przyrostu. Problem ten może być rozwiązany poprzez stosowanie narzędzi modelowania typu CASE (modelery), które pozwalają na budowanie modeli obiektowych z gotowego kodu. Zagadnienie to nosi nazwę reverse-engineering, czyli generowanie diagramów z kodu zapisanego w języku obiektowym

12 Tworzenie kodu: budowa klasy w oparciu o definicje zapisane w projektowym diagramie klas W większości przypadków projektowy diagram klas posiada wszelkie niezbędne informacje konieczne do zapisania w języku obiektowym kodu dla rozpatrywanej klasy. Metoda create została zastąpiona konstruktorem 23 Tworzenie kodu: dodawanie atrybutów referencyjnych Atrybut referencyjny to atrybut, który wykorzystywany jest do przechowywania referencji, bądź wskaźnika do obiektu, a nie do typu prostego takiego jak liczba, bądź łańcuch. Atrybuty referencyjne są wykorzystywane do implementacji asocjacji zapisanych w projektowym diagramie klas atrybuty takie nie są zapisywane wprost w projektowym diagramie klas. Atrybut referencyjny 24 12

13 Tworzenie kodu: implementacja metod (1) W trakcie budowy diagramów interakcji do projektowego diagramu klas wprowadzone są metody, które będą musiały być zaimplementowane. Diagramy interakcji obrazują kolejność przesyłania komunikatów pomiędzy instancjami klas w odpowiedzi na wywołanie danej metody. W trakcie budowania ciała takiej metody sekwencja tych komunikatów przełoży się na kolejno wywoływane wyrażenia. 25 Tworzenie kodu: implementacja metod (2) Deklaracja klasy Kasa Definicja metody dodajprodukt 26 13

14 Kolejność implementacji Przyjmuje się, że kolejność implementacji klas zależy od stopnia ich powiązań w pierwszej kolejności powinny być implementowane klasy o niskim współczynniku powiązań