KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Analiza przypadków użycia - diagramy klas w fazie analizy Przygotował: mgr inż. Radosław Adamus
Wstęp Poprzednie ćwiczenie (Analiza przypadków użycia analiza zachowania) wprowadziło nas w pierwszą fazę procesu analizy przypadków użycia: wyszukiwanie kluczowych abstrakcji, budowę modelu projektowego oraz tworzenie realizacji przypadków użycia poprzez analizę zachowania na diagramach interakcji. Niniejsze ćwiczenie jest kontynuacją tego procesu polegającą na tworzeniu diagramów klas, definiowaniu atrybutów, związków (asocjacji) pomiędzy klasami oraz definiowaniu mechanizmu analizy uwzględniającego wymagania niefunkcjonalne. Definiowanie klas Po zdefiniowaniu diagramów interakcji opisujących realizację przypadków użycia, kolejnym zadaniem, jakie należy wykonać, jest odzwierciedlenie zachowania obiektów w statycznej strukturze klas. Zadania te składają się z następujących czynności: 1. Określenie odpowiedzialności poszczególnych klas (na podstawie komunikatów, jakie otrzymują obiekty tej klasy na diagramach interakcji) 2. Określenie atrybutów i asocjacji 3. Określenie mechanizmu analizy 4. Unifikacja klas z poszczególnych przypadków użycia Określanie odpowiedzialności klas Każda z klas analizy jest odpowiedzialna za wykonanie określonych zadań w przypadku użycia. Rozróżnienie pomiędzy klasami boundary, entity i control wprowadza już podstawowy podział odpowiedzialności: Klasy boundary odpowiedzialne za komunikację pomiędzy przypadkiem użycia a aktorem, Klasy control odpowiedzialne za sterowanie przepływem zadań wykonywanych w danym przypadku użycia. Klasy entity odpowiedzialne za zarządzanie i przetwarzanie danych potrzebnych do realizacji przypadku użycia.
Po dokonaniu tego wstępnego podziału należy określić szczegółowe odpowiedzialności poszczególnych klas. Na opis odpowiedzialności składają się: Działania, jakie obiekt klasy jest zobowiązany wykonać (wyrażane jako operacje) podstawowym źródłem informacji na ten temat są diagramy interakcji. Informacje, jakie obiekt posiada, którymi zarządza i które udostępnia (wyrażane jako atrybuty klas oraz operacje umożliwiające zarządzanie tymi danymi) podstawowym źródłem informacji są: specyfikacja systemu, specyfikacje przypadków użycia, słownik pojęć, wymagania niefunkcjonalne. Określanie atrybutów Atrybuty są wykorzystywane do przechowywania informacji, zakłada się ich atomowość i nie posiadanie odpowiedzialności. Nazwa atrybutu powinna być rzeczownikiem, który jasno określa, jakie informacje przechowuje dany atrybut. Jeżeli z nazwy atrybutu nie wynika, w sposób oczywisty, jakie informacje przechowuje powinien on być dodatkowo opisany. W fazie analizy nie przeznacza się dużo czasu na definiowane typów/sygnatur atrybutów. Typy powinny pochodzić z modelowanej dziedziny biznesowej i nie mieć związku ż żadnym konkretnym językiem programowania. Potencjalnymi źródłami atrybutów są: Wiedza dziedzinowa, Wymagania, Specyfikacje przypadków użycia. Należy pamiętać o tym, że atrybuty są atomowe i jeżeli jakaś własność klasy powinna posiadać odpowiedzialność to nie może być zamodelowana jako atrybut, ale jako osobna klasa połączona odpowiednim związkiem z daną klasą (asocjacja, agregacja). Decyzja o tym czy dana własność jest atomowa zależy od modelowanego problemu i powinna przede wszystkim uwzględniać ewentualną odpowiedzialność klasy a nie samą atomowość danych (np. typ data/godzina jest zazwyczaj traktowany jako atomowy mimo tego, że z punktu widzenia konkretnego języka implementacyjnego wcale nie musi być typem atomowym). Ogólnie można powiedzieć, że należy wykorzystać atrybuty, jeżeli:
Istotna jest tylko wartość, a nie jej lokalizacja, Informacja jest przypisana tylko do jednego obiektu, żadne inne obiekty nie odnoszą się bezpośrednio do tej informacji. Dostęp do informacji można zamodelować jako dwie operacje: ustaw (set) i pobierz (get), które dokonują co najwyżej prostych transformacji. Informacja nie posiada żadnego zachowania poza udostępnianiem swojej wartości. Z drugiej strony, jeżeli informacja posiada złożone zachowanie lub jest współdzielona przez dwa lub większą liczbę obiektów powinna być zamodelowana jako osobna klasa. Należy pamiętać, że proces określania atrybutów jest sterowany przypadkami użycia, co oznacza, że wszystkie wykryte atrybuty muszą być przydatne w realizacji przynajmniej jednego przypadku użycia. Określanie asocjacji Asocjacja reprezentuje strukturalny związek pomiędzy obiektami różnych klas (łączy instancje dwóch lub większej liczny klas przez pewien odcinek czasu). Asocjacje można wykorzystać w celu pokazania, że jeden obiekt wie o istnieniu innego obiektu. Wynika to z tego, że często, w celu umożliwienie interakcji pomiędzy nimi (np. przesyłania komunikatów), obiekty muszą przechowywać referencję do siebie nawzajem. Z tego względu cześć asocjacji pomiędzy klasami bezpośrednio wynika z interakcji opisanych na diagramach sekwencji czy współpracy. Większość asocjacji to proste związki łączące dwie klasy: Państwo Stolica Rys 1. Związek asocjacji Zdarza się, że klasa posada asocjację do samej siebie. Nie musi to jednak oznaczać, że instancja tej klasy jest związana ze sobą; częściej oznacza to, że jedna instancja klasy jest związana z inną instancją tej samej klasy.
Osoba podwładny szef Rys 2. Asocjacja typu self Asocjacja może posiadać nazwę, która może być umieszczona nad lub pod linią definiującą związek asocjacji. Nazwa powinna odzwierciedlać cel, jakiemu służy powiązanie i z tego względu powinna być czasownikiem. Firma pracuje_dla Osoba Rys 3. Nazwa asocjacji Należy unikać nazw, typu: posiada, zawiera, ponieważ nie wnoszą one żadnej nowej informacji o związku pomiędzy klasami (są zbyt ogólne, związek typu zawiera jest bezpośrednio wyrażany w UML-u jako specjalna forma asocjacji nazywana agregacją). Nazwa asocjacji jest opcjonalna i może zostać pominięta, jeżeli związek jest oczywisty (np. wynika z nazw klas biorących w nim udział lub jest naturalny). Nazwa asocjacji jest również pomijana, jeżeli opisane zostały role, jakie są grane przez klasy uczestniczące w danym związku. Opis asocjacji poprzez role jest niezbędny w przypadku, gdy związek łączy ze sobą tą samą klasę (patrz rysunek 2). Dodatkowym, (ale bardzo istotnym) opisem asocjacji jest określenie liczności dla klas występujących w związku. Dzięki liczności możemy wyrazić następujące własności asocjacji: Opcjonalność (liczność może przyjąć wartość zero) Związek jeden do jednego Związek jeden do wielu Związek wiele do wielu Zakres liczby obiektów występujących w danym związku.
Wymaganie istnienia jednocześnie kilku obiektów w związku (nieciągłe wartości liczności). Firma 1 1..* Osoba Rys 4. Liczność asocjacji Tabela 1: Oznaczenia liczności w UML- u. UML ZNACZENIE 1 1 1..* 1,2,3,... 2..* 2,3,4,... 3-5 3,4,5 2,4,18 2,4,18-1,? 0..1 0,1 0..* 0,1,2,... * 0,1,2,... Innym sposobem precyzowania asocjacji jest skierowanie, czyli określenie czy obie strony asocjacji wiedzą nawzajem o swoim istnieniu czy też, tylko jedna ze stron wie o istnieniu drugiej. Asocjacje domyślnie są skierowane (nawigowalne) w obu kierunkach, czyli zakładają, że z poziomu obiektu jednej klasy można dostać się do obiektu drugiej klasy i na odwrót. Jeżeli asocjacja powinna być tylko jednostronna należy to zaznaczyć poprzez dodanie grotu strzałki na końcu linii określającej związek asocjacji.
Rys. 5 Asocjacja skierowana Związek pomiędzy klasami może również być wyrażony jako szczególny przypadek asocjacji: agregacja lub generalizacja specjalizacja. Znajdowanie związków pomiędzy klasami Podstawowym źródłem dla procesu wyszukiwania asocjacji są diagramy współpracy pokazujące powiązania pomiędzy obiektami. Takie powiązanie wskazuje na to, że obiekty, pomiędzy którymi ono istnieje, musza się ze sobą komunikować. Oznacza to, że na diagramie klas powinno pojawić się powiązanie pomiędzy klasami, do których nalezą te obiekty. Czyli, należy przyjąć podstawową zasadę, że: Dla każdego związku pomiędzy dwoma obiektami na diagramie współpracy powinno pojawić się powiązanie pomiędzy odpowiednimi klasami na diagramie klas (diagram VOPC dla przypadku użycia). Powiązania, na diagramie współpracy, prowadzące do tego samego obiektu niekoniecznie muszą zostać odzwierciedlone w postaci związku na diagramie klas. Związek (typu self ) powinien pojawić się na diagramie klas, jeżeli powiązanie łączy ze sobą dwa obiekty tej samej klasy. Jeżeli na diagramie sekwencji dwa obiekty przesyłają między sobą różne komunikaty może to niekiedy oznaczać, że pomiędzy klasami, do których to obiekty należą, istnieje więcej niż jeden związek asocjacji. Sytuacja taka nie wynika jedna z liczby komunikatów, ale z ewentualnych różnych ról, jakie są przypisane do tych samych klas w różnych sytuacjach. Przykład z rysunku 6 pokazuje sytuację, w której osoba może być członkiem wielu komitetów, przewodniczącym tylko jednego. Nastąpiło tutaj rozróżnienie ról (członek komitetu, przewodniczący komitetu) i wynikające z tego różnice (w tym wypadku liczność) spowodowały potrzebę stworzenia dwóch osobnych asocjacji. jest_członkiem * * Osoba Komitet 1 jest_przewodniczącym * Rys. 6 Kilka asocjacji łączących te same klasy
Trzeba pamiętać o tym, że skupić się należy tylko na asocjacjach potrzebnych w realizacji przypadku użycia. Nie dodawać związków, które wydaje się, że powinny wystąpić, jeżeli nie zostały wykryte na podstawie analizy diagramu interakcji. Po zdefiniowaniu asocjacji należy określić i nazwać role, jakie klasy grają w tym związku (bądź nadać nazwę samej asocjacji), oraz określić liczność asocjacji. Na koniec należy krótko opisać asocjację w celu zasygnalizowania sposobu, w jaki asocjacja jest używana lub, jaki związek reprezentuje. Agregacja Agregacja jest szczególną formą asocjacji, wykorzystywaną do modelowania związku całość - część. Ponieważ, jest to po prostu specjalna forma asocjacji to wszystkie własności asocjacji (role, liczność, skierowanie) również dotyczą związku agregacji. Rys. 7 Agregacja, czyli związek całość część. Kiedy należy zdefiniować związek agregacji zamiast asocjacji? Obiekt jest złożony z innych obiektów (np. samochód składa się z silnika, czterech kół, itd.) obiekt jest niekompletny bez swoich części (na poziomie analizy nie rozpatruje się podziału na agregację i kompozycję), Obiekt jest logiczną kolekcją innych obiektów (np. rodzina składa się z rodziców i dzieci). Obiekt fizycznie zawiera w sobie inne obiekty (np. samolot zawiera pilota). Jednak odpowiedz na pytanie, czy należy wykorzystać asocjację, czy agregację jest w dużym stopniu zależna od konkretnej aplikacji. Jeżeli modelowanie dotyczy np. dealerów samochodowych to związek pomiędzy silnikiem a samochodem będzie niewątpliwie występował jako związek całość część, natomiast w przypadku modelowania sklepu z częściami samochodowymi silnik
może być mniej zależny od konkretnego samochodu i związek przyjmie postać asocjacji. Przyjmuje się, że w przypadku wątpliwości należy użyć asocjacji. Określanie mechanizmu analizy Wyidealizowany model analizy nie uwzględnia wymagań niefunkcjonalnych (np. wydajność, trwałość, rozproszenie, itd.). Jest to spowodowane tym, że wprowadzają one duży bagaż złożoności, który na tym etapie może spowodować przysłonięcie niektórych, istotnych z punktu widzenia dziedziny biznesowej własności funkcjonalnych projektowanego systemu. Nie oznacza to jednak, że wymagania niefunkcjonalne powinny zostać pominięte, są one równie istotne jak funkcje systemu. Dlatego, w celu uniknięcia nadmiernej złożoności na tym etapie projektu wprowadza się tzw. mechanizm analizy, który pozwala na przypisanie wymagań niefunkcjonalnych do poszczególnych elementów modelu analizy i ogólne opisanie ich (wymagań niefunkcjonalnych) charakterystyk w sposób niezależny od implementacji. Jeżeli, na przykład, analityk wykryje, że pewna grupa danych powinna być trwała (powinna istnieć nawet, gdy aplikacja w tym momencie nie pracuje), to, mimo tego, że nie został jeszcze wybrany mechanizm ani narzędzie (system bazy danych) zarządzania takimi danymi, musi mieć on możliwość zasygnalizowania takiej sytuacji. W tym celu używa on mechanizmu analizy, który pozwala opisać samą niefunkcjonalną własność elementu modelu, jak i określić jej charakterystyki. Przykładami mechanizmów analizy są: Trwałość (ang. Persistency) Typ komunikacji (IPC, RPC) Przekazywanie komunikatów (ang. Message routing) Rozproszenie (ang. Distribution) Transakcje (ang. Transaction Management) Synchronizacja procesów (ang. Process synchronization) Wymiana informacji, formaty konwersji (ang. Information exchange, format conversion) Bezpieczeństwo (ang. Security) Obsługa błędów (ang. Error detection, handling, reporting)
Nadmiarowość (ang. Redundancy) Interfejsy spadkowe (ang. Legacy Interface) Każdy mechanizm analizy ma przypisane właściwości umożliwiające sprecyzowanie wybranych własności, np.: Mechanizm: trwałość Ziarnistość Natężenie Czas trwania Mechanizm dostępu Częstotliwość dostępu Niezawodność Mechanizm: komunikacja międzyprocesowa Opóźnienie Synchronizacja Rozmiar komunikatu Protokół Mechanizm: interfejs spadkowy Opóźnienie Czas Mechanizm dostępu Częstotliwość dostępu Mechanizm: bezpieczeństwo Ziarnistość danych Ziarnistość użytkowników Reguły bezpieczeństwa Typy uprawnień
Proces opisu mechanizmu analizy W celu opisania mechanizmów analizy należy: Zebrać wszystkie mechanizmy analizy w postaci listy takie same mechanizmy analizy mogą występować w różnych sytuacjach pod różnymi nazwami (trwałość, baza danych, repozytorium, składowanie) (komunikacja między-procesowa, zdalne wywołanie procedury, przekazywanie komunikatów) Narysować mapę powiązań pomiędzy klasami i mechanizmami analizy klasy, nazwy mechanizmów, strzałki łączące klasy z odpowiednimi mechanizmami Określić właściwości mechanizmów analizy aby ułatwić w procesie projektowym wybór odpowiedniego rozwiązania projektowego należy opisać podstawowe właściwości mechanizmów. Zamodelować mechanizmy analizy przy użyciu kolaboracji kiedy mechanizmy zostały zidentyfikowane i nazwane, należy je zamodelować w postaci współpracujących ze sobą klas. Niektóre z tych klas nie udostępniają żadnej funkcjonalności specyficznej dla tworzonej aplikacji, ale jedynie służą wsparciu działania aplikacji (często umieszcza się je potem w specjalnej warstwie oprogramowania zwanej middleware). Unifikacja klas Zanim rozpocznie się proces projektowania przypadków użycia, klasy analizy powinny być zunifikowane w celu uniknięcia nadmiarowości w zdefiniowanych pojęciach. Niebezpieczeństwo powielania się pewnych elementów wynika przede wszystkim z tego, że dotychczas każdy przypadek użycia był rozpatrywany osobno i w odizolowaniu od pozostałych elementów (z wyjątkiem kluczowych abstrakcji). Na tym etapie powinny zostać połączone: Klasy, które opisują to samo zjawisko (być może z różnych punktów widzenia wynikających z innych własności tych zjawisk rozpatrywanych w różnych przypadkach użycia). Klasy, które definiują podobne zachowanie.
Klasy entity, które posiadają takie same atrybuty, nawet, jeżeli posiadają inne zachowanie (zachowanie klas powinno zostać zsumowane w klasie wynikowej). Zadania 1. Określ atrybuty, które musza posiadać klasy analizy określone w procesie wykrywania kluczowych abstrakcji oraz analizowania przypadków użycia na diagramach interakcji i umieść je (atrybuty) w odpowiednich klasach. 2. Określ asocjacje pomiędzy klasami analizy na podstawie związków na diagramach współpracy, opisz role i/lub nazwy asocjacji oraz liczność. Sprawdź asocjację pod kątem ich przekształcenia na agregacje. Umieść asocjacje na diagramach VOPC. 3. Dla każdej zidentyfikowanej klasy analizy określ czy należy jej przypisać mechanizmy analizy. Skoncentruj się na następujących mechanizmach: Trwałość, Rozproszenie, Bezpieczeństwo i Interfejs Spadkowy. Pamiętaj, że klasy nie musza mieć żadnego mechanizmu analizy lub mogą mieć jeden i więcej mechanizmów. Jako pomoc wykorzystaj Specyfikację Uzupełniającą. Określony mechanizm analizy wraz z opisanymi własnościami umieć w dokumentacji klas. Utwórz dokument programu Word o nazwie Mapa mechanizmów analizy i umieść w nim tabelkę wiążącą klasy z odpowiednimi mechanizmami analizy (patrz przykład w tabeli 2). Tabela 2: Przykładowa tabela mapująca klasy na odpowiednie mechanizmy analizy. KLASA ANALIZY Student Kurs Kontrole rejestracji MECHANIZM ANALIZY Trwałość, Bezpieczeństwo Trwałość, Interfejs Spadkowy Rozproszenie 4. Dokonaj unifikacji klas na diagramie Klasy Analizy w pakiecie Model projektowy.