Aktorzy. Wystąpienia aktorów. Opracowano w Lab. Informatyki AGH (Kraków)

Transkrypt

1 Podstawowe pojęcia Przypadki użycia (use cases) Aktor spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. Opracowano w Lab. Informatyki AGH (Kraków) Aktorzy mogą występować w wielu modelach, nie należą jednak do systemu, lecz stanowią elementy otoczenia. Rys. Przykład aktora AnalitykKredytowy (c) Radosław Klimek 1 (c) Radosław Klimek 2 Aktorzy Wystąpienia aktorów klient przedstawiciel handlowy pracownik Jan Kowalski: klient :pracownik Pan Piotr: przedstawiciel handlowy Adam Kasia: pracownik Firma kurierska <<actor>> System magazynowy <<actor>> System księgowy DHL: firma kurierska <<actor>> Magazyn1: System magazynowy <<actor>> Księgowa: System księgowy W języku UML aktor przedstawiany jest w postaci ludzika, lub w postaci klasy oznaczonej słowem kluczowym actor i nazwą klasy aktorów (c) Radosław Klimek 3 Przedstawiono tutaj różne wystąpienia (instancje) aktorów z klas aktorów pokazanych na poprzednim slajdzie. Jan Kowalski jest klientem, Kasia pracownikiem, Adam niewyspecyfikowanym typem wystąpienia aktora, a także pracownik nie posiadający nazwy, dla którego podany jest tylko typ. (c) Radosław Klimek 4 Przypadek użycia (use case) opis zbiorów ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku. Między aktorami a przypadkami użycia mogą być związki typu powiązania. Oznacza to, że aktor i przypadek użycia porozumiewają się ze sobą wysyłając i odbierając komunikaty. Nazwy są w zasadzie dowolnym tekstem (bez dwukropka), najczęściej jest to krótkie wyrażenie z czasownikiem w trybie rozkazującym na początku. Czasownik ten określa czynność ze słownika modelowanego systemu. Przypadek użycia opisuje co system (podsystem, klasa, operacja) realizuje, nie określa natomiast jak to robi. Ciąg zdarzeń przypadku użycia może być określony tekstowo (nieformalny tekst z ogranicznikami początku i końca) lub zazwyczaj w kolejnym kroku, przez diagramy interakcji. Przyznaj kredyt Sensors:: Reset Rys. Nazwa prosta i ścieżkowa w przypadkach użycia (c) Radosław Klimek 5 (c) Radosław Klimek 6 1

2 Dokumentowanie przypadków użycia Opis każdego przypadku użycia musi zawierać szczegółowe informacje o tym, co trzeba zrobić aby spełnił on swoją funkcję. Przebieg zdarzeń Przebieg zdarzeń to ciąg zdań oznajmujących wyliczający kolejne kroki przypadku użycia z punktu widzenia aktora. Należy przeanalizować: podstawowe jego funkcje możliwe warianty błędy warunki jakie muszą być spełnione przed rozpoczęciem warunki jakie muszą być spełnione po jego zakończeniu Każdy przypadek użycia może zawierać warunki rozgałęzienia pętle (c) Radosław Klimek 7 Przypadek użycia Zapłać podatek Przebieg zdarzeń 1. System stwierdził wystąpienie końca okresu rozliczeniowego. 2. System oblicza kwotę - należny podatek VAT 3. System dokonuje elektronicznego przelewu obliczonego podatku na konto urzędu skarbowego 4. System stwierdza, że pieniądze zostały przelane (c) Radosław Klimek 8 Warianty można przedstawiać za pomocą rozgałęzień Przypadek użycia Znajdź zamówienie Przebieg zdarzeń 1. Użytkownik wybrał Znajdź zamówienie. 2. Użytkownik wprowadza numer zamówienia, numer klienta lub nazwisko klienta 3. Użytkownik wybrał Szukaj 4. Użytkownik wprowadził numer zamówienia a) System wyświetla to zamówienie i kończy przypadek użycia 5. Użytkownik wprowadził nazwisko klienta albo jego numer a) System zwraca listę wszystkich zamówień dla tego klienta b) Użytkownik wybiera jedno zamówienie z listy c) System wyświetla to zamówienie i przypadek użycia kończy się. (c) Radosław Klimek 9 Jeżeli trzeba wielokrotnie powtórzyć wykonanie jakiegoś kroku lub zbioru kroków to korzysta się z powtórzeń (pętli). Przypadek użycia Złóż zamówienie Przebieg zdarzeń: 1. Klient wybiera złóż zamówienie 2. Klient wprowadza swoje imię, nazwisko oraz adres 3. Klient wprowadza kody towarów, które chce zamówić 4. Dla każdego wybranego kodu towaru a) System wyświetla opis i cenę towaru b) System dodaje cenę towaru do sumy 5. Klient wprowadza informacje o karcie płatniczej 6. Klient wybiera zatwierdź 7. System zapisuje zamówienie jako oczekujące 8. Przesyła informację o płatności do systemu księgowego 9. System potwierdza złożenie zamówienia (c) Radosław Klimek 10 Warunki wstępne i końcowe Warunki wstępne informacja o tym w jakim stanie musi się znajdować system na początku przypadku użycia Warunki końcowe - informują o tym w jakim stanie musi się znajdować system na końcu przypadku użycia Warunki wstępne i końcowe muszą być spełnione niezależnie od wykonanego przebiegu zdarzeń czy rozgałęzień jakie zostały wybrane. Przypadek użycia Złóż zamówienie Warunki wstępne: użytkownik zalogował się w systemie Przebieg zdarzeń: 1. Klient wybrał opcję Złóż zamówienie 2. Klient wprowadza imię, nazwisko i adres 3. Klient wprowadza kody towarów, które chce zamówić 4. System podaje opis i cenę każdego wybranego towaru 5. System przechowuje bieżącą sumę cen wybranych towarów 6. Klient wprowadza informacje o karcie płatniczej 7. Klient wybiera Zatwierdź 8. System sprawdza podane informacje, zapisuje zamówienie jako oczekujące i przesyła informacje o płatności do systemu księgowego. Jeśli jakieś informacje są niepoprawne, system prosi o poprawienie 9. Po potwierdzeniu płatności zamówienie jest oznaczone jako potwierdzone system podaje klientowi numer zamówienia 10. Jeśli płatność nie została potwierdzona system prosi o poprawienie danych albo anulowanie zamówienia Warunki końcowe: Zamówienie zostaje zapisane w systemie i zaznaczone jako potwierdzone (c) Radosław Klimek 11 (c) Radosław Klimek 12 2

3 Główny ciąg zdarzeń i nadzwyczajne ciągi zdarzeń Przykład przypadku WeryfikujUzytkownika. Główny ciąg zdarzeń. 1. Pytanie klienta o PIN. 2. Klient wprowadza PIN. 3. Klient potwierdza wprowadzony PIN (Enter). 4. System sprawdza poprawność PIN-u. 5. Jeśli PIN jest poprawny system informuje o tym klienta. Nadzwyczajny ciąg zdarzeń to taki, który opisuje inny przebieg, niż to, co było opisane w głównym ciągu zdarzeń. Być może użytkownik ma w jakimś momencie możliwość wyboru jednej z kilku czynności. Albo może wystąpić jakiś błąd Najbardziej prawdopodobny wybór opisany jest w głównym ciągu zdarzeń. Pozostałe wybory opisujemy jako nadzwyczajne ciągi zdarzeń (c) Radosław Klimek 13 (c) Radosław Klimek 14 Nadzwyczajny ciąg zdarzeń 1. Klient może w każdym momencie nacisnąć przycisk Cancel. Przypadek użycia wraca wówczas do stanu początkowego. Nadzwyczajny ciąg zdarzeń 2. Jeśli klient wprowadził błędny PIN, to przypadek użycia wraca do punktu początkowego. Gdy zdarzy się to 3 razy z rzędu, system anuluje całą transakcję i przez 90 sekund nie reaguje na działania klienta. (c) Radosław Klimek 15 Występujące związki: Związki na diagramach asocjacja związek pomiędzy aktorem a przypadkiem użycia; zawieranie stereotypowany związek oznaczający że jeden związek jest częścią drugiego; rozszerzenie związek pomiędzy przypadkami użycia dotyczący uzupełniającej (opcjonalnej) funkcjonalności wykorzystywanej np. pod pewnymi warunkami; zależność związek pomiędzy aktorami lub pomiędzy przypadkami użycia, bez wskazywania na czym polega zależność; generalizacja związek pomiędzy pewnym przypadkiem użycia a jego specjalizacją. (c) Radosław Klimek 16 Przypadki użycia można uporządkować przez zdefiniowanie uogólnień i związków zawierania i rozszerzania. Uogólnienie oznacza, że przypadek użycia-potomek dziedziczy całe zachowanie i znaczenie po przypadku-przodku. Potomek może wprowadzać nowe elementy do odziedziczonego zachowania. Potomek może zastąpić przodka, np. różny sposób weryfikacji klienta w bankomacie. Uogólnienie pomiędzy aktorami oznacza, że: jeden z aktorów odgrywa wszystkie role drugiego aktora może on grać dodatkowe role wspólne role ogrywane są jednakowo Uogólnienie pomiędzy przypadkami użycia oznacz że: jeden przypadek użycia jest uszczegółowioną wersją drugiego uszczegółowiony przypadek użycia dziedziczy zachowanie przypadku ogólnego może dodawać własne zachowania (c) Radosław Klimek 17 (c) Radosław Klimek 18 3

4 Przykład uogólnienia na diagramie przypadków użycia klient Złóż zamówienie Sprawdź stan zamówienia Złóż zamówienie Przez WWW Złóż zamówienie telefonicznie Zawieranie (<<include>>) oznacza, że bazowy przypadek użycia jawnie włącza się w zachowanie innego przypadku użycia, w miejscu przez siebie określonym. Włączany przypadek użycia nie występuje samodzielnie - jego egzemplarze mogą być tylko częścią większego, zawierającego go przypadku użycia. Przedstawiciel handlowy Przygotuj raport (c) Radosław Klimek 19 (c) Radosław Klimek 20 przykład przypadków użycia z zawieraniem Złóż zamówienie <<include>> Samodzielne wystąpienie bazowego przypadku użycia jest możliwe, jeśli, pod pewnymi warunkami, jego zachowanie może być rozszerzone przez zachowanie innego przypadku użycia. Zaloguj się Związku zawierania używa się w celu uniknięcia wielokrotnego definiowania tego samego ciągu zdarzeń. klient Sprawdź stan zamówienia <<include>> Jest to przykład delegowania - pewien zbiór zobowiązań jest specyfikowany przez składnik systemu, a inne elementy systemu (pozostałe przypadki użycia) włączają ten zbiór zobowiązań, jeśli zachodzi taka potrzeba. (c) Radosław Klimek 21 (c) Radosław Klimek 22 Związek rozszerzania służy do warunkowego rozszerzania zachowania przypadku użycia. Rozszerzenie (<<extends>>) oznacza, że bazowy przypadek użycia w sposób domniemany włącza zachowanie innego przypadku użycia w określonym miejscu. Jest to metoda dodawania zachowań do przypadku użycia bez zmiany pierwotnego przypadku użycia. Rozszerzenie służy do modelowania fragmentów przypadków użycia postrzeganych przez użytkownika jako opcjonalne zachowanie systemu. Można tym samym określić pewien podciąg zdarzeń, które mogą zachodzić pod pewnymi warunkami. Można również dołączyć wskazany podciąg w konkretnym miejscu. Miejsce rozszerzenia jest to punkt wskazujący gdzie rozszerzenie może wystąpić. Gdy dojdziemy do punktu rozszerzenia, wówczas jeżeli jest spełniony warunek to wykonywane są czynności w rozszerzającym przypadku użycia. (c) Radosław Klimek 23 (c) Radosław Klimek 24 4

5 Przykład Złóż Zamówienie z rozszerzającymi przypadkami użycia Złóż zamówienie Extension points określ priorytet Złóż zamówienie ekspresowe Sprawdź hasło klient Złóż zamówienie Extension point towar przeceniony rabat dla stałych klientów <<extend>> [Towar przeceniony] [towar na liście towarów przecenionych] Cena z wyprzedaży posezonowej Rabat dla stałych klientów Śledź zamówienie Weryfikuj użytkownika Porównaj siatkówkę Rys. Uogólnienie, zawieranie i rozszerzanie przypadków użycia (c) Radosław Klimek 25 (c) Radosław Klimek 26 Interfejsy można definiować dla: aktorów przypadków użycia albo jednych i drugich Interfejsy Interfejs nie jest częścią aktora ani przypadku użycia, jest opisem w jaki sposób ma przebiegać współpraca z aktorem albo przypadkiem użycia. Każdy aktor i przypadek użycia może mieć więcej niż jeden interfejs (może korzystać i obsługiwać więcej niż jeden interfejs) Interfejs składa się z nazwy i zbioru sygnatur operacji. Sygnatura operacji określa, jakiego rodzaju dane są przekazywane do tej operacji, a jakie są zwracane po jej zakończeniu. Przykład dla aktora System Magazynowy interfejs Aktualizacja Stanu Magazynu Zwiększ ilość w magazynie (kod towaru, ilość) Zmniejsz ilość w magazynie (kod towaru, ilość) interfejs Informacje o Towarze Pobierz opis im cenę towaru (kod towaru) zwróć opis, cenę, dostępną ilość Pobierz kod towaru i cenę (opis) zwróć kod towaru, cenę, dostępną ilość (c) Radosław Klimek 27 (c) Radosław Klimek 28 Przykład interfejsu dla aktora System Magazynowy Interfejs Informacje o Towarze System magazynowy Interfejs Aktualizacja Stanu Magazynu Obsługa zamówień Pobierz informacje O towarze Pobierz informacje Aktualizuj ilość towaru Linia pomiędzy aktorem a interfejsem oznacza, że aktor obsługuje dany interfejs. Strzałka narysowana przerywaną linią wskazuje przypadek użycia korzystający z interfejsu. (c) Radosław Klimek 29 Przykład interfejsu przypadków użycia Interfejs Złóż Zamówienie Złóż zamówienie na towary (identyfikator firmy, lista towarów, osoba kontaktowa Duży System wsadowy Interfejs Złóż zamówienie Obsługa zamówień Złóż zamówienie Tutaj przypadek użycia obsługuje interfejs a aktor z niego korzysta (c) Radosław Klimek 30 5

6 Wytyczne względem modelowania Identyfikacja aktorów 1. Identyfikacja aktorów będących w interakcji z dana jednostką. 2. Uporządkuj aktorów przez wyznaczenie ról ogólnych i szczegółowych. 3. Dla każdego aktora rozważ podstawowe sposoby jego komunikacji z daną jednostką. 4. Analizuj i określ sytuacje wyjątkowe, w których dochodzi do interakcji aktora z daną jednostką. 5. Usystematyzuj przypadki użycia - uogólnienie, zawieranie, rozszerzenie. Aktorzy zawsze istnieją poza systemem, nigdy nie są Jego częścią. Można ich szukać wśród: ludzi innego oprogramowania urządzeń sprzętowych składów danych sieci (c) Radosław Klimek 31 (c) Radosław Klimek 32 Można też zadać sobie następujące pytania Odkrywanie przypadków użycia Kto korzysta z systemu? Kto instaluje system? Kto uruchamia system? Kto pielęgnuje system? Kto wyłącza system? Jakie inne systemy korzystają z tego systemu? Kto pobiera informacje z tego systemu? Kto dostarcza informacje systemowi? Czy aktualnie coś dzieje się automatycznie? Przypadek użycia to opis działania systemu, który tworzy pewien wynik, mający znaczenie dla aktora. Można zadać sobie następujące pytania: Jakich funkcji dany aktor będzie oczekiwał od systemu? Czy system przechowuje informacje? Którzy aktorzy będą tworzyli, czytali, aktualizowali albo usuwali informacje? Czy system musi zawiadamiać aktora o zmianach w swoim wewnętrznym stanie? Czy są jakieś zewnętrzne zdarzenia, o których system powinien wiedzieć, Który aktor będzie informował o tych zadarzeniach? (c) Radosław Klimek 33 (c) Radosław Klimek 34 Inne przypadki użycia, które warto rozważyć Opisywanie aktorów i przypadków użycia Uruchamianie systemu Wyłączanie systemu Diagnozowanie systemu Instalowanie systemu Szkolenia użytkowników Zmiany procesów biznesowych Przeprowadzanie naprawy Każdy aktor i przypadek użycia musi mieć opisową nazwę i krótki opis (jedno lub dwuzdaniowy). Te informacje dołącza się do diagramu przypadków użycia. (c) Radosław Klimek 35 (c) Radosław Klimek 36 6

7 Opis aktorów w systemie np. obsługi zamówień Klient osoba zamawiająca towar od firmy Przedstawiciel handlowy pracownik firmy, który obsługuje życzenia klientów Firma kurierska UPS, DHL, Poczta itd. Pracownik pracownik firmy, który pakuje, opisuje, i wysyła zamówione towary System magazynowy program przechowujący informacje o stanie magazynu firmy System księgowy program przechowujący dane finansowe (c) Radosław Klimek 37 Opis przypadków użycia w systemie obsługi zamówień Złóż zamówienie klient tworzy nowe zamówienie, prosi o dostarczenie produktu i dokonuje zapłaty Złóż skargę klient wysyła komunikat do działu obsługi klienta Dostarcz katalog klient prosi o dostarczenie katalogu Pobierz informacje o towarze - pobieranie informacji o towarze, jego cenie i stanie w magazynie Zwróć towar klient zwraca towar i dostaje zwrot pieniędzy Anuluj zamówienie klient anuluje istniejące zamówienie Dostarcz przesyłkę prosimy firmę kurierską o dostarczenie towaru Oblicz koszt przesyłki określamy ile wynosi opłata za dostarczenie przesyłki Aktualizuj ilość towaru aktualizowanie ilości towaru w magazynie Sprawdź stan zamówienia klient sprawdza stan istniejącego zamówienia Wydrukuj etykietę drukowanie etykiety adresowej do zamówienia (c) Radosław Klimek 38 Diagramy przypadków użycia Diagram przypadków użycia przedstawia zbiór przypadków użycia i aktorów oraz związki między nimi. Modelowanie otoczenia systemu System kart kredytowych Realizuj transakcje kartą Diagramy przypadków użycia są stosowane do obrazowania statycznych aspektów perspektywy przypadków użycia systemu. Klient Rozlicz transakcję Uzgodnij transakcję Jednostka handlu detalicznego W ogólności dotyczy to realizacji 2 celów: 1. Modelowanie otoczenia systemu - granica system-otoczenie, wskazanie aktorów i znaczenia ich ról. 2. Modelowanie wymagań stawianych systemowi - co system powinien robić z punktu widzenia otoczenia. Klient indywidualny Instytucja Obsługuj rachunek klienta Sponsorująca organizacja Rys. Modelowanie otoczenia systemu (c) Radosław Klimek 39 (c) Radosław Klimek 40 Wytyczne modelowania granicy system-otoczenie Modelowanie wymagań stawianych systemowi Wytyczne 1. Zidentyfikuj aktorów działających w otoczeniu systemów. 2. Uporządkuj podobnych aktorów za pomocą uogólnień. 3. Jeśli potrzeba - utwórz stereotypy aktorów dla zwiększenia czytelności. 4. Połącz aktorów z odpowiednimi przypadkami użycia. 1. Zidentyfikuj aktorów systemu (określ jego otoczenie). 2. Dla każdego aktora rozważ działania, których oczekuje (wymaga) od systemu. 3. Znajdź powtarzające się fragmenty działań i uporządkuj przypadki użycia. 4. Uwzględnij zmodyfikowane przypadki użycia w definiowaniu związków z aktorami. 5. Dodaj notatki określające wymagania niefunkcjonalne. (c) Radosław Klimek 41 (c) Radosław Klimek 42 7

8 Klient System kart kredytowych Realizuj transakcje kartą Rozlicz transakcję Uzgodnij transakcję Obsługuj rachunek klienta <<include>> Wykryj oszustwo kartą Podaj stan konta Jednostka handlu detalicznego Sponsorująca organizacja Przypadki użycia w Tau G2 Zasadnicza zbieżność pomiędzy tymi diagramami w UML i Tau G2; pewne pojęcia są jakby doprecyzowane, np. przypadek użycia; nieco bogatsze związki. Rys. Dodatkowe przypadki użycia, niewidoczne dla klienta (c) Radosław Klimek 43 (c) Radosław Klimek 44 Składniki diagramów Składniki diagramów (c.d.) przypadek użycia - funkcjonalność realizowana przez system, pewne podobieństwo do operacji (tutaj stereotypowane), później poprzez inne diagramy definiowana (sekwencje, stany, także tekstowo) aktor obiekt biorący udział w interakcji, źródło informacji dla systemu, pełni rolę zewnętrzną do tematów (systemu), np. człowiek, urządzenie, inny system, sieć; pojedynczy aktor może występować wielokrotnie w różnych rolach, jak i ten sam aktor może być w interakcji z różnymi przypadkami użycia; na diagramach klas obiekt stereotypowany <<actor>> Temat/moduł (subject) określa granicę dla modelowanych przypadków użycia, może oznaczać system lub podsystem. (c) Radosław Klimek 45 (c) Radosław Klimek 46 8

9 Klasa (class) to opis zbioru obiektów, które mają takie same atrybuty, związki i znaczenie. Klasy i związki Obiekt (object) - konkretne wystąpienie abstrakcji; byt o dobrze określonych granicach i tożsamości, obejmujący stan i zachowanie; egzemplarz klasy. Opracowano w Lab. Informatyki AGH (Kraków) Każda klasa musi mieć przypisaną nazwę prostą (rzeczownik) lub ścieżkową (poprzedzoną nazwą pakietu). (c) Radosław Klimek 1 (c) Radosław Klimek 2 Sensor Atrybut jest nazwaną właściwością (cechą) klasy. Określa zbiór wartości, jakie można przypisać do poszczególnych egzemplarzy tej klasy. Klient RegułyPrzedsiębiorstwa:: WykrywaczOszustw Klasa może mieć dowolną liczbę atrybutów, lub nie mieć wcale. Atrybut reprezentuje właściwość modelowanego bytu, określoną dla wszystkich jego wystąpień. Ściana Rys. Nazwy proste i ścieżkowe Ściana wysokość: Float szerokość: Float grubość: Float jestnośna: Boolean = false atrybuty Rys. Atrybuty klasy (c) Radosław Klimek 3 (c) Radosław Klimek 4 Operacja to implementacja pewnej usługi, której wykonania można zażądać od każdego obiektu klasy. Odpowiedzialność (responsibility) jest wyrażona kontraktem lub zobowiązaniem typu lub klasy. Klasa może mieć dowolną ( 0) liczbę operacji. Modelując klasy rozpoczyna się zazwyczaj od wyspecyfikowania zobowiązań elementów słownictwa systemu. W trakcie doskonalenia (uściślania) modelu zobowiązania systemu są tłumaczone na realizujący je zbiór operacji i atrybutów. CzujnikTermiczny WykrywaczOszustw atrybuty wyzeruj() ustawprógalarmu(t:temperatura) odczytaj(): Temperatura operacje Rys. Operacje i ich sygnatury Responsibilities -określ ryzyko przyjęcia zamówienia klienta - wykorzystaj kryteria oceny ryzyka dla konkretnego klienta Rys. Zobowiązania (c) Radosław Klimek 5 (c) Radosław Klimek 6

10 Modelowanie słownictwa systemu Wytyczne Klasy wykorzystuje się do modelowania abstrakcji pochodzących z dziedziny danego problemu lub technologii rozwiązania. Każda z abstrakcji jest częścią słownictwa systemu - reprezentuje elementy istotne dla użytkowników i twórców systemu. 1. Zidentyfikuj elementy, które są stosowane przez użytkowników lub twórców systemu do opisu problemu lub rozwiązania. 2. Ustal zbiór zobowiązań każdej abstrakcji. Sprawdź czy wszystkie klasy są precyzyjnie określone i czy mają równomiernie rozłożone zobowiązania. 3. Uwzględnij atrybuty i operacje potrzebne do wykonania przez daną klasę zobowiązań. (c) Radosław Klimek 7 (c) Radosław Klimek 8 Klient nazwisko imię adres telefon Faktura Transakcja operacje zatwierdź() wycofaj() powiodłasię() Hurtownia Zamówienie pozycja ilość Rys. Modelowanie słownictwa systemu Towar id nazwa cena miejsceskładu Wysyłka Responsibilities - przechowuj informację o realizacji zamówienia dot. wysyłki - śledź stan i lokalizację wysyłanych towarów Modelowanie rozkładu zobowiązań w systemie Rozkład zobowiązań powinien być w miarę równomiernie rozłożony między poszczególne klasy. Wytyczne 1. Zidentyfikuj zbiór klas współpracujących w celu wykonania poszczególnych czynności. 2. Określ zbiór zobowiązań dla każdej klasy. 3. Rozważ zbiór klas jako całość, podziel klasy na mniejsze, jeśli mają zbyt dużo zobowiązań - scal w większe jeśli mają zbyt mało. Przenoś zobowiązania między klasami, aby każda była w pełni samodzielna. 4. Analizuj sposoby wzajemnej kooperacji tych klas i porozdzielaj ich zobowiązania, aby były równomiernie rozłożone. (c) Radosław Klimek 9 (c) Radosław Klimek 10 Modelowanie elementów nieprogramowych Wytyczne 1. Przedstaw każdy element nieprogramowy w postaci klasy. 2. W celu odróżnienia od standardowych bloków UML określ nowy rodzaj przy pomocy stereotypu i określ jego znaczenie i podaj nowy symbol graficzny. 3. Jeśli modelowany element jest sprzętem zawierającym oprogramowanie rozważ możliwość, czy nie można go przedstawić w postaci węzła, aby później rozwijać jego strukturę. Urzędnik Rozliczający Należności Robot przetwórzzamówienie() zmieńzamowienie() stan() Rys. Elementy nieprogramowe w postaci osoby: Urzędnik Rozliczający Należności i sprzętu: Robot (c) Radosław Klimek 11 (c) Radosław Klimek 12

11 Modelowanie pierwotnych typów danych Modelowane elementy mogą pochodzić z języka programowania (implementacji). Zwykle są to typy pierwotne (predefiniowane), np. liczby całkowite, znaki, napisy, typy wyliczeniowe itp. Wytyczne 1. Przedstaw typy jako klasy zaopatrzone odpowiednimi stereotypami. 2. Użyj ograniczeń, jeśli chcesz wyspecyfikować zbiór dopuszczalnych wartości pewnego typu. <<datatype>> Int {wartości z przedziału od -2**31 do +2**31-1} <<enumeration>> State idle busy error <<datatype>> Boolean false true Rys. Modelowanie typów pierwotnych (c) Radosław Klimek 13 (c) Radosław Klimek 14 Związki (relacje) Zależność oznacza, że zmiany dokonane w specyfikacji jednego elementu mogą mieć wpływ na inny element, który używa tego pierwszego. Związek to relacja między elementami. W diagramach UML związki są przedstawiane jako różne (w zależności od rodzaju związku) linie łączące elementy. Klip nazwa Najważniejsze rodzaje związków: 1. Zależność (Dependency) często reprezentowana przez relację użycia. 2. Uogólnienie (Generalization) - związek między klasą ogólną a szczegółową:klasa-podklasa lub potomek-przodek. 3. Powiązanie (Association) - jest związkiem strukturalnym między elementami klasy. odtwórzna(k: Kanał) uruchom() zatrzymaj() wyzeruj() Rys. Przykład zależności Zależność Kanał (c) Radosław Klimek 15 (c) Radosław Klimek 16 Uogólnienie jest związkiem między elementem ogólnym (nadklasa, przodek) a pewnym specyficznym jego rodzajem (podklasa, potomek). Uogólnienie polega m.in. na tym, że potomek może wystąpić wszędzie tam gdzie spodziewany jest przodek (lecz nie na odwrót). Figura położenie przenieś() zmieńwielkość() wyświetl() Potomek dziedziczy właściwości przodka, w szczególności atrybuty i operacje. Może też mieć własne cechy. Prostokąt wierzchołek: Punkt Okrąg Promień: Float Wielokąt Punkty: lista Operacja potomka, mająca tę samą sygnaturę jest ważniejsza (polimorfizm), tzn. przysłania operację przodka. Kwadrat Rys. Uogólnienie (c) Radosław Klimek 17 (c) Radosław Klimek 18

12 Powiązania Rola zachowanie bytu w ustalonym kontekście. Powiązanie to związek strukturalny specyfikujący połączenie obiektów jednego klasyfikatora z obiektami drugiego. Powiązanie Powiązanie między klasami oznacza, że można przejść od obiektu jednej z nich do obiektu drugiej i odwrotnie. Osoba pracownik pracodawca Przedsiębiorstwo Nazwa Kierunek nazwy Nazwa roli Osoba Pracuje dla Rys. Nazwa powiązania Przedsiębiorstwo Innymi słowy rola, to pewne oblicze, które obiekty klasy przy jednym końcu prezentują obiektom klasy przy drugim końcu. Na rysunku Osoba pełniąca rolę pracownika jest powiązana z Przedsiębiorstwem będącym w roli pracodawcy. (c) Radosław Klimek 19 (c) Radosław Klimek 20 Liczebność Powiązanie jest związkiem równorzędnych partnerów - klasy są na tym samym poziomie pojęciowym. Agregacja oznacza związek całość-część, tzn. dana klasa (całość) składa się z mniejszych (części). Osoba 1..* * pracownik pracodawca Przedsiębiorstwo Całość Przedsiębiorstwo 1 Przy modelowaniu często zachodzi potrzeba określenia ile obiektów może być połączonych przez jeden egzemplarz powiązania. Ta wielokrotność (ile) nazywana jest liczebnością (multiplicity). Część * Dział Rys. Agregacja (c) Radosław Klimek 21 (c) Radosław Klimek 22 Modelowanie prostych zależności Modelowanie dziedziczenia Najczęstszy przypadek - klasa używa innej klasy jako parametru operacji. Wytyczne Rozkład zajęć dodaj(p: Przedmiot) usuń(p: Przedmiot) <<friend>> Iterator Przedmiot Rys. Przykłady zależności 1. Poszukaj zobowiązań, atrybutów i operacji wspólnych dla co najmniej dwóch klas. 2. Przenieś wspólne zobowiązania, atrybuty i operacje do klasy ogólnej. Jeśli to konieczne utwórz nową klasę. 3. Zaznacz związki dziedziczenia - od potomka do przodka. (c) Radosław Klimek 23 (c) Radosław Klimek 24

13 Zabezpieczenie Modelowanie związków strukturalnych RachunekBieżący oprocentowanie bieżącawartość() AkcjaZwykła Akcja bieżącawartość() bieżącawartość() historia() Obligacja bieżącawartość() AkcjaUprzywilejowana Nieruchomość obciążenia bieżącawartość() Rys. Dziedziczenie Wytyczne 1. Dla każdej pary klas poszukaj, możliwości przechodzenia obiektów jednej z nich do obiektów drugiej. Dla takich klas określ powiązanie. Identyfikacja powiązania w oparciu o dane. 2. Analizuj, czy dla każdej pary klas konieczna jest interakcja między obiektami jednej a obiektami drugiej, inna niż przekazywanie ich jako parametrów. Dla takich klas określ powiązanie. Identyfikacja powiązania w oparciu o zachowanie. 3. Dla każdego powiązania określ liczebność i nazwy ról (ułatwiają zrozumienie modelu). 4. Jeśli jakaś klasa stanowi strukturalną lub organizacyjną całość w stosunku do klas z drugiego końca związku, to zaznacz powiązanie jako agregację. (c) Radosław Klimek 25 (c) Radosław Klimek 26 Uczelnia 1..* studiuje na ma 1 1..* Wydział 1..* * pracuje na 1 * 1..* 1..* dziekan Student uczęszcza na prowadzi Wykład Wykładowca * * * 1..* Diagramy klas w Tau G2 Diagramy klas przedstawiają statyczny obraz systemu, pokazują typy obiektów istniejących w systemie; najczęściej są to klasy ale także typy enumeratywne, interface y oraz inne; diagramy klas są bardzo dobrze i realistycznie zdefiniowane w Tau G2, bogate modelowanie związków; wprowadzono także elementy nowe. Rys. Związki strukturalne (c) Radosław Klimek 27 (c) Radosław Klimek 28 Klasy informacje podstawowe Klasa abstrakcyjna klasa (italic) bez instancji, do instancji wymaga się specjalizacji. Klasy, klasy aktywne - abstrakcja grupy obiektów o wspólnych własnościach posiadająca atrybuty i operacje jako własności tej klasy. Z własnościami są związane zakresy widoczności, zasadniczo: + publiczne (odwołania praktycznie z dowolnego miejsca); - prywatne (wykorzystywane tylko w danej klasie); # chronione (wykorzystywane przy specjalizacji). Związki w diagramach klas Podstawowe związki w diagramach klas: - asocjacja zwyczajna relacja mnogościowa; agregacja logiczna przynależność (zawieranie), całośćczęść, agregacja może być traktowana jako szczególny przypadek asocjacji; kompozycja kompozycja fizyczne zawieranie jednego elementu w drugim, tj. usunięcie obiektu zewnętrznego powoduje usunięcie wewnętrznego; (c) Radosław Klimek 29 (c) Radosław Klimek 30

14 Związki w diagramach klas (c.d.) Porty W diagramach klas występują także porty związane (tylko) z klasami aktywnymi. generalizacja związek dziedziczenia własności, jedna klasa jest bardziej ogólna (generalna), a druga jest specjalizowana (dziedziczy); Porty to miejsca przez które jest realizowana interakcja klasy aktywnej, to inaczej nazwane miejsca interakcji. Porty mogą być dziedziczone. zależność związek typu klient-dostawca, jedna z klas jest z pewnych powodów zależna od drugiej. Możemy także wyróżnić porty behawioralne i niebehawioralne. Pierwsze z nich związane są bezpośrednio z maszynami stanowymi wszystkie sygnały przechodzące przez port są konsumowane przez zachowanie klasy. Drugi rodzaj wymaga ustanowienia połączenia. (c) Radosław Klimek 31 (c) Radosław Klimek 32 Interfejsy Razem z portami mogą występować także interfejsy. Interfejs grupa atrybutów i operacji, które muszą być zaimplementowane w danej klasie. Operacje interfejsu zazwyczaj opisują pewne usługi oferowane przez daną klasę. Poza operacjami interfejs może zawierać atrybuty, a także sygnały. Istnieją dwa rodzaje interfejsów. Interfejsy (c.d.) Interfejs realizowany interfejs który klasa realizuje przez port. Interfejs wymagany pokazuje jakie sygnały wychodzące z klasy powinny być obsłużone. (c) Radosław Klimek 33 (c) Radosław Klimek 34 Wyróżniamy także klasy specjalne. Klasy inne Przykład diagramu Sygnały to asynchroniczne wiadomości przesyłane pomiędzy klasami aktywnymi. Można także definiować listy sygnałów. Zdarzenia typu timer -zdarzenia w istocie podobne do sygnałów. A także klasy inne. Ogólny przykład diagramu klas (c) Radosław Klimek 35 (c) Radosław Klimek 36