Opracowano w Lab. Informatyki AGH (Kraków)home.agh.edu.pl/~rklimek/io/ztpo-3-4.pdf · 2012-03-27 2...

2012-03-27

1

(c) Radosław Klimek 1

Przypadki użyciaPrzypadki użycia((use casesuse cases))

Opracowano w Lab. Informatyki AGH (Kraków)


Aktor – spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia.

AnalitykKredytowy

Rys. Przykład aktora

Aktorzy mogą występować w wielu modelach, nie należą jednak do systemu, lecz stanowią elementy otoczenia.

Podstawowe pojęciaPodstawowe pojęcia

Aktorzy


klient przedstawiciel handlowy pracownik

Firma kurierska<<actor>>

System magazynowy <<actor>>

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


Jan Kowalski: klient

Pan Piotr: przedstawiciel handlowy

Kasia: pracownik

DHL: firma kurierska

<<actor>>Magazyn1:

System magazynowy

<<actor>>Księgowa:

System księgowy

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.

Wystąpienia aktorów

Adam:pracownik


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.

Przyznaj kredyt Sensors:: Reset

Rys. Nazwa prosta i ścieżkowa w przypadkach użycia

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.


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.

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.

2012-03-27

2

Dokumentowanie przypadków użyciaOpis każdego przypadku użycia musi zawierać szczegółoweinformacje o tym, co trzeba zrobić aby spełnił on swoją funkcję.

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


Przebieg zdarzeńPrzebieg zdarzeń to ciąg zdań oznajmujących wyliczającykolejne kroki przypadku użycia z punktu widzenia aktora.

Przypadek użycia Zapłać podatekPrzebieg zdarzeń1. System stwierdził wystąpienie końca okresu rozliczeniowego.2. System oblicza kwotę - należny podatek VAT3. System dokonuje elektronicznego przelewu obliczonego

podatku na konto urzędu skarbowego4. System stwierdza, że pieniądze zostały przelane


Warianty można przedstawiać za pomocą rozgałęzień

Przypadek użycia Znajdź zamówieniePrzebieg zdarzeń1. Użytkownik wybrał Znajdź zamówienie.2. Użytkownik wprowadza numer zamówienia, numer klienta lub

nazwisko klienta3. Użytkownik wybrał Szukaj4. Użytkownik wprowadził numer zamówienia

a) System wyświetla to zamówienie i kończy przypadek użycia5. Użytkownik wprowadził nazwisko klienta albo jego numer

a) System zwraca listę wszystkich zamówień dla tego klientab) Użytkownik wybiera jedno zamówienie z listyc) System wyświetla to zamówienie i przypadek użycia kończy

się.


Jeżeli trzeba wielokrotnie powtórzyć wykonanie jakiegoś kroku lubzbioru kroków to korzysta się z powtórzeń (pętli).

Przypadek użycia Złóż zamówieniePrzebieg zdarzeń:1. Klient wybiera złóż zamówienie2. Klient wprowadza swoje imię, nazwisko oraz adres3. Klient wprowadza kody towarów, które chce zamówić4. Dla każdego wybranego kodu towaru

a) System wyświetla opis i cenę towarub) System dodaje cenę towaru do sumy

5. Klient wprowadza informacje o karcie płatniczej6. Klient wybiera zatwierdź7. System zapisuje zamówienie jako oczekujące8. Przesyła informację o płatności do systemu księgowego9. System potwierdza złożenie zamówienia


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żnieod wykonanego przebiegu zdarzeń czy rozgałęzień jakie zostaływybrane.


Przypadek użycia Złóż zamówienie

Warunki wstępne: użytkownik zalogował się w systemiePrzebieg zdarzeń: 1. Klient wybrał opcję Złóż zamówienie2. Klient wprowadza imię, nazwisko i adres3. Klient wprowadza kody towarów, które chce zamówić4. System podaje opis i cenę każdego wybranego towaru5. System przechowuje bieżącą sumę cen wybranych towarów6. Klient wprowadza informacje o karcie płatniczej7. 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 jakopotwierdzone


2012-03-27

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ń



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 dopunktu 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.


Związki na diagramachWystępujące związki:

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ą.


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


2012-03-27

4

Przykład uogólnienia na diagramie przypadków użycia


klient

Przedstawiciel handlowy

Złóżzamówienie

Złóż zamówieniePrzez WWW

Sprawdźstan zamówienia

Złóż zamówienietelefonicznie

Przygotujraport


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.

przykład przypadków użycia z zawieraniem


klient

Złóżzamówienie

Sprawdź stanzamówienia

Zaloguj się

<<include>>

<<include>>


Związku zawierania używa się w celu uniknięcia wielokrotnego definiowania tego samego ciągu zdarzeń.

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.

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.


Rozszerzenie (<<extends>>) oznacza, że bazowy przypadek użycia w sposób domniemany włącza zachowanie innego przypadku użycia w określonym miejscu.

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.

Związek rozszerzania służy do warunkowego rozszerzania zachowania przypadku użycia.

Jest to metoda dodawania zachowań do przypadku użycia bez zmiany pierwotnego przypadku użycia.

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.


2012-03-27

5

PrzykładZłóż Zamówienie z rozszerzającymi przypadkami użycia


klient

Złóż zamówienieExtension point

towar przecenionyrabat dla stałych

klientów

Rabat dlastałych klientów

Cena z wyprzedażyposezonowej

<<extend>>[Towar przeceniony] [towar na liście towarów przecenionych]


Złóż zamówienieExtension pointsokreśl priorytet

Złóż zamówienieekspresowe

Śledź zamówienie

Weryfikujużytkownika

Sprawdź hasło

Porównajsiatkówkę

Rys. Uogólnienie, zawieranie i rozszerzanie przypadków użycia

InterfejsyInterfejsy można definiować dla: aktorów przypadków użycia albo jednych i drugich

Interfejs nie jest częścią aktora ani przypadku użycia, jestopisem w jaki sposób ma przebiegać współpraca z aktoremalbo przypadkiem użycia.

Każdy aktor i przypadek użycia może mieć więcej niż jedeninterfejs (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 Magazynowyinterfejs 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ść


Przykład interfejsu dla aktora System Magazynowy


System magazynowy

Pobierz informacje

Obsługa zamówień

Pobierz informacjeO towarze

Aktualizuj ilośćtowaru

Interfejs Informacje o Towarze

InterfejsAktualizacja Stanu

Magazynu

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.

Przykład interfejsu przypadków użycia

Interfejs Złóż Zamówienie Złóż zamówienie na towary (identyfikator firmy, lista

towarów, osoba kontaktowa


Obsługa zamówień

Duży Systemwsadowy

Złóżzamówienie

InterfejsZłóż zamówienie

Tutaj przypadek użycia obsługuje interfejs a aktor z niego korzysta

2012-03-27

6


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.

Wytyczne względem modelowaniaWytyczne względem modelowaniaIdentyfikacja aktorów

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


Można też zadać sobie następujące pytania

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?


Odkrywanie przypadków użycia

Przypadek użycia to opis działania systemu, który tworzy pewienwynik, 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?


Inne przypadki użycia , które warto rozważyć

Uruchamianie systemu Wyłączanie systemu Diagnozowanie systemu Instalowanie systemu Szkolenia użytkowników Zmiany procesów biznesowych Przeprowadzanie naprawy


Opisywanie aktorów i przypadków użycia

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ówużycia.


2012-03-27

7

Opis aktorów w systemie np. obsługi zamówień

Klient – osoba zamawiająca towar od firmy Przedstawiciel handlowy – pracownik firmy , któryobsługuje życzenia klientówFirma kurierska – UPS, DHL, Poczta itd.Pracownik – pracownik firmy, który pakuje, opisuje,i wysyła zamówione towarySystem magazynowy – program przechowującyinformacje o stanie magazynu firmySystem księgowy – program przechowujący danefinansowe


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łatyZłóż skargę – klient wysyła komunikat do działu obsługi klientaDostarcz katalog – klient prosi o dostarczenie kataloguPobierz informacje o towarze - pobieranie informacji o towarze,jego cenie i stanie w magazynieZwróć towar – klient zwraca towar i dostaje zwrot pieniędzyAnuluj zamówienie – klient anuluje istniejące zamówienieDostarcz przesyłkę – prosimy firmę kurierską o dostarczenie towaruOblicz koszt przesyłki – określamy ile wynosi opłata za dostarczenieprzesyłkiAktualizuj ilość towaru –aktualizowanie ilości towaru w magazynieSprawdź stan zamówienia – klient sprawdza stan istniejącegozamówieniaWydrukuj etykietę – drukowanie etykiety adresowej dozamówienia



Diagramy przypadków użyciaDiagramy 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.

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.

Diagramy przypadków użycia są stosowane do obrazowania statycznych aspektów perspektywy przypadków użycia systemu.


Realizujtransakcje kartą

Rozlicz transakcję

Uzgodnijtransakcję

Obsługujrachunek klienta

Klient

Klientindywidualny

Instytucja

Jednostka handludetalicznego

Sponsorującaorganizacja

System kart kredytowych

Rys. Modelowanie otoczenia systemu

Modelowanie otoczenia systemuModelowanie otoczenia systemu


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.

Wytyczne modelowania granicy Wytyczne modelowania granicy systemsystem--otoczenieotoczenie


WytyczneWytyczne

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.

Modelowanie wymagań stawianych Modelowanie wymagań stawianych systemowisystemowi

2012-03-27

8


Realizujtransakcje kartą

Rozlicz transakcję

Uzgodnijtransakcję

Obsługujrachunek klienta

Klient

Jednostka handludetalicznego

Sponsorującaorganizacja

System kart kredytowych

Podaj stankonta

Rys. Dodatkowe przypadki użycia, niewidoczne dla klienta

Wykryj oszustwokartą

<<include>>


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.


Składniki diagramów

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>>


Składniki diagramów (c.d.)

Temat/moduł (subject) – określa granicę dla modelowanych przypadków użycia, może oznaczać system lub podsystem.

1


Klasy i związkiKlasy i związki

Opracowano w Lab. Informatyki AGH (Kraków)


Klasa (class) to opis zbioru obiektów, które mają takie same atrybuty, związki i znaczenie.

Obiekt (object) - konkretne wystąpienie abstrakcji; byt o dobrze określonych granicach i tożsamości, obejmujący stan i zachowanie; egzemplarz klasy.

Każda klasa musi mieć przypisaną nazwę prostą (rzeczownik) lub ścieżkową (poprzedzoną nazwą pakietu).


Sensor

Klient

Ściana

RegułyPrzedsiębiorstwa:: WykrywaczOszustw

Rys. Nazwy proste i ścieżkowe


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.

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

wysokość: Floatszerokość: Floatgrubość: FloatjestNośna: Boolean = false

atrybuty

Rys. Atrybuty klasy


Operacja to implementacja pewnej usługi, której wykonania można zażądać od każdego obiektu klasy.

Klasa może mieć dowolną ( ≥ 0) liczbę operacji.

CzujnikTermiczny

wyzeruj()ustawPrógAlarmu(t:Temperatura)odczytaj(): Temperatura

atrybuty

operacje

Rys. Operacje i ich sygnatury


Odpowiedzialność (responsibility) jest wyrażona kontraktem lub zobowiązaniem typu lub klasy.

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.

WykrywaczOszustw

Responsibilities

- określ ryzyko przyjęcia zamówieniaklienta

- wykorzystaj kryteria oceny ryzykadla konkretnego klienta

Rys. Zobowiązania

2


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.

Modelowanie słownictwa systemu


WytyczneWytyczne

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ń.


Klientnazwiskoimięadrestelefon

Zamówienie

pozycjailość

Towar

idnazwacenamiejsceSkładu

Faktura

Transakcjaoperacje

zatwierdź()wycofaj()powiodłaSię()

Hurtownia

Responsibilities- przechowuj informację o realizacjizamówienia dot. wysyłki

- śledź stan i lokalizację wysyłanych towarów

Wysyłka

Rys. Modelowanie słownictwa systemu


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.

Modelowanie rozkładu zobowiązań w systemieModelowanie rozkładu zobowiązań w systemie


WytyczneWytyczne

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ę.

Modelowanie elementów nieprogramowychModelowanie elementów nieprogramowych


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

3


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.

Modelowanie pierwotnych typów danych


<<datatype>>Int

{wartości z przedziałuod -2**31 do +2**31 - 1}

<<datatype>>Boolean

falsetrue

<<enumeration>>State

idlebusyerror

Rys. Modelowanie typów pierwotnych


Związki (relacje)Związki (relacje)

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.

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.


Zależność – oznacza, że zmiany dokonane w specyfikacji jednego elementu mogą mieć wpływ na inny element, który używa tego pierwszego.

Klip

nazwa

odtwórzNa(k: Kanał)uruchom()zatrzymaj()wyzeruj()

Kanał

Zależność

Rys. Przykład zależności


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).

Potomek dziedziczy właściwości przodka, w szczególności atrybuty i operacje. Może też mieć własne cechy.

Operacja potomka, mająca tę samą sygnaturę jest ważniejsza (polimorfizm), tzn. „przysłania” operację przodka.


Figura

położenie

przenieś()zmieńWielkość()wyświetl()

Prostokąt

wierzchołek: Punkt

Okrąg

Promień: Float

Wielokąt

Punkty: lista

Kwadrat Rys. Uogólnienie

4


Powiązania

Powiązanie to związek strukturalny specyfikujący połączenie obiektów jednego klasyfikatora z obiektami drugiego.

Powiązanie między klasami oznacza, że można przejść od obiektu jednej z nich do obiektu drugiej i odwrotnie.

Osoba PrzedsiębiorstwoPracuje dla

Nazwa Kierunek nazwy

Rys. Nazwa powiązania


Osoba Przedsiębiorstwo

Powiązanie

pracownik pracodawca

Nazwa roli

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.

Rola zachowanie bytu w ustalonym kontekście.


Osoba Przedsiębiorstwopracownik pracodawca1..* *

Liczebność

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).


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).

Przedsiębiorstwo

Dział

1

*

Całość

Część Rys. Agregacja


Najczęstszy przypadek - klasa używa innej klasy jako parametru operacji.

Rozkład zajęć

dodaj(p: Przedmiot)usuń(p: Przedmiot)

Przedmiot

Iterator

<<friend>>Rys. Przykłady zależności

Modelowanie prostych zależnościModelowanie prostych zależności


WytyczneWytyczne

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.

Modelowanie dziedziczeniaModelowanie dziedziczenia

5


Zabezpieczenie

bieżącaWartość()historia()

RachunekBieżący

oprocentowanie

bieżącaWartość()

Akcja


Obligacja


Nieruchomość

obciążenia


AkcjaUprzywilejowanaAkcjaZwykła Rys. Dziedziczenie


WytyczneWytyczne

1. Dla każdej pary klas poszukaj, możliwości przechodzenia obiektówjednej 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 ichjako 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ązaniejako agregację.

Modelowanie związków strukturalnychModelowanie związków strukturalnych


Uczelnia Wydział

Student Wykład Wykładowca

1..*

*

studiuje na

ma

uczęszcza na prowadzi

pracuje na

1 1..*

0..1

1..*

1dziekan1..*

1..**

1..*

1..*

* *

Rys. Związki strukturalne


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’yoraz inne;diagramy klas są bardzo dobrze i realistycznie zdefiniowane w Tau G2, bogate modelowanie związków;wprowadzono także elementy nowe.


Klasy – informacje podstawowe

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).

Klasa abstrakcyjna –klasa (italic) bez instancji, do instancji wymaga się specjalizacji.


Związki w diagramach klasPodstawowe 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;

6


Związki w diagramach klas (c.d.)

generalizacja – związek dziedziczenia własności, jedna klasa jest bardziej ogólna (generalna), a druga jest specjalizowana (dziedziczy);

zależność – związek typu klient-dostawca, jedna z klas jest z pewnych powodów zależna od drugiej.


PortyW diagramach klas występują także porty związane (tylko) z klasami

aktywnymi.

Porty to miejsca przez które jest realizowana interakcja klasy aktywnej, to inaczej nazwane miejsca interakcji.

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.

Porty mogą być dziedziczone.


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 operacjamiinterfejs może zawierać atrybuty, a także sygnały.


Interfejsy (c.d.)Istnieją dwa rodzaje interfejsów.

Interfejs realizowany – interfejs który klasa realizuje przez port.

Interfejs wymagany – pokazuje jakie sygnały wychodzące z klasy powinny być obsłużone.


Klasy inne

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.

Wyróżniamy także klasy specjalne.

A także klasy inne.


Przykład diagramu

Ogólny przykład diagramu klas

Opracowano w Lab. Informatyki AGH (Kraków)home.agh.edu.pl/~rklimek/io/ztpo-3-4.pdf · 2012-03-27 2...

Documents

Transcript of Opracowano w Lab. Informatyki AGH (Kraków)home.agh.edu.pl/~rklimek/io/ztpo-3-4.pdf · 2012-03-27 2...