Projektowanie z językiem UML
Język modelowania UML
• UML
(ang. Unified Modeling Language)
jest graficznym językiem
do:
• specyfikowania
• obrazowania
• tworzenia
• dokumentowania
elementów (artefaktów) systemów oprogramowania
• UML jest ‘językiem' do specyfikowania a nie metodą czy procedurą
– UML stosuje się do zdefiniowania systemu oprogramowania; do
uszczegółowienia artefaktów tego systemu, do jego udokumentowania i
skonstruowania
• to jest język w którym pisze się „blueprint” systemu
– UML można użyć na wiele sposobów wspierając określone metodologie
tworzenia oprogramowania (taką jak Rational Unified Process)
• Ale sam w sobie nie specyfikuje takiej metodologii czy procesu
Elementy składowe
• Podstawowymi elementami składowymi UML są:
– elementy modelu (klasy, interfejsy, komponenty,
przypadki użycia, itp.)
– związki (asocjacje, generalizacje, zależności, itp.)
– diagramy (diagramy klas, diagramy przypadków użycia,
diagramy interakcji, itp.)
• Proste elementy składowe pozwalają składać się
w duże, złożone struktury
• UML definiuje także mechanizmy rozszerzenia
– Aby sprostać różnym specjalizowanym potrzebom (na
przykład rozszerzenia modelowania procesów
biznesowych - Business Process Modeling).
Historia UML
• Przez wiele lat głównymi konkurującymi
metodologiami obiektowego
programowania były
• Rumbaugh’s Object Modeling Technique
(OMT)
• Booch’s metodologia O-O, oraz
• Jacobsen’s metodologia Objectory(OOSE)
• UML scala notacje z tych trzech w jeden
zunifikowany model obiektowy
• UML stał się standardem dla obiektowo
zorientowanej analizy i projektowania
przez Object Management Group (OMG)
• UML 2.0 jest dostępny w:
Składniki UML
• W skład UML wchodzą :
– Składniki modelu
– Relacje (wiążące składniki
modelu ze sobą)
– Diagramy
• grupują określone składniki
– Graficznie prezentują
zestawy elementów
• najczęściej w formie
schematów
Klasa Stan Węzeł
Przypadek
użycia
Zależności Generalizacje Inne
Język UML – opis notacji
• Model interakcji użytkownika (
Model przypadków użycia
)
– Zakres oraz interakcja między systemem a użytkownikami
• Koresponduje w pewnym zakresie z modelem wymagań
• Model interakcji lub komunikacji
– jak obiekty systemu oddziałują wzajemnie dla wykonania zadania
• Model stanów (
Model dynamiczny
)
– stany lub warunki jakie klasy przyjmują z biegiem czasu
• Wykresy aktywności opisują workflow zaimplementowany w systemie
• Model logiczny (
Model klas
)
– opisuje klasy i objekty wchodzące w skład systemu
• Model fizyczny (
Model elementów
)
– opisuje oprogramowanie (czasem sprzęt) tworzące system
• Model wdrożenia
– fizyczna architektura i wdrożenie elementów architektury
sprzętowej
Model przypadków użycia
• Opisuje proponowaną funkcjonalność nowego
systemu
– Przypadek użycia jest dyskretną jednostkową interakcją
pomiędzy użytkownikiem (człowiekiem lub maszyną) a
systemem
• Ta interakcja będzie elementem realnego zadania takiego jak
Załóż konto lub Przeglądaj szczegółową informację.
• Spojrzenie na system z punktu widzenia zachowań
widzianych przez użytkowników
• Każdy przypadek użycia opisuje określoną
funkcjonalność wchodzącą do proponowanego
systemu
– która może włączyć funkcjonalność innego przypadku użycia
lub rozciągnąć inny przypadek użycia na swoje zachowanie
Zastosowania przypadków użycia
• modelowanie zachowania bytów
- opis
ciągu akcji zmierzających do realizacji
danej funkcji systemu,
• modelowanie otoczenia systemu
-
definiowanie aktorów i ich ról,
• modelowanie wymagań stawianych
systemowi
- określenie co system
powinien robić,
• testowanie systemu
.
Przypadki użycia
• Funkcje:
• zdefiniowanie zachowania się
systemu,
• wypracowanie porozumienia
między
programistami
,
użytkownikami
i
ekspertami
,
• weryfikacja architektury
systemu w czasie jego
budowania (
testowanie
regresywne
),
• zdefiniowanie
kooperacji
realizujących określone
funkcje (kooperacją może być
pojedynczy przypadek użycia).
• Cechy:
• zbiór ciągów akcji
opisujących
interakcję elementów z otoczenia
systemu
• (aktorów) z samym systemem,
– aktor
- człowiek lub
zautomatyzowany system,
• przypadki użycia mogą mieć
ogólne lub bardziej szczegółowe
warianty,
– dany przypadek użycia może być
podzbiorem większego przypadku
użycia,
• opisują co system robi, ale NIE
jak to robi
,
– mogą pojawiać się alternatywne
ciągi akcji.
Opisy przypadku użycia
•
Ogólne uwagi i adnotacje opisujące dany przypadek użycia
•
Wymagania takie jak
–
<możność aktualizacji zlecenia>,<możność modyfikacji zlecenia>,
itp.
•
Ograniczenia
–
Reguły określające co można i co nie można. Przykłady:
•
<wystaw zlecenie> musi poprzedzać <modyfikuj zlecenie>;
•
<zlecenie zostało zmodyfikowane i jest koherentne>;
•
zamówienie musi zawsze mieć numer klienta
•
Scenariusze
–
Sekwencyjny opis kroków potrzebnych do realizacji danego
przypadku.
•
Diagramy scenariuszy
–
Diagramy sekwencji obrazujące workflow
•
Dodatkowe atrybuty jak faza implementacji, numer wersji, ocena
złożoności, stereotypy lub status
Scenariusze
• Formalne wyszczególnienie kroków, które
trzeba wykonać realizując dany przypadek
użycia, lub bieg zdarzeń w danej instancji
przypadku użycia.
– Mogą one obejmować wiele scenariuszy dla
opisania szczególnych okoliczności i
alternatywne sposoby rozwiązania.
• Scenariusze są zazwyczaj prezentowane w
formie tekstu i odpowiadają tekstowemu
przedstawieniu diagramu sekwencji
Diagramy przypadków użycia
• Służą do modelowania funkcjonalności
systemu
–
są „spisem treści” wymagań funkcjonalnych;
• Są stosowane do modelowania sekwencji
działań wykonywanych przez system,
które przynoszą określone rezultaty
komuś lub czemuś spoza systemu;
• Wykorzystując prostą graficznie notację
–
są zrozumiałe dla użytkownika
Modelowanie wymagań
•
Zdefiniowanie co system ma robić (
określenie
wszystkich funkcjonalności systemu
)
•
Modelowanie obejmuje również wymagania
niefunkcjonalne
–
realizowane przez sam system
–
nie realizowane przez aktorów, korzystających z
systemu.
•
Etapy modelowania:
1. zdefiniowanie aktorów,
2. zdefiniowanie i uporządkowanie przypadków użycia
realizowanych przez aktorów (funkcjonalności),
3. zdefiniowanie przypadków użycia realizowanych
przez system (czynności niefunkcjonalnych).
Rola przypadków użycia
• Dostarczyć bardziej funkcjonalne
spojrzenie na system
oprogramowania
– funkcje, aktorzy
– granice
– odczytywalne przez klienta/użytkownika
• Zwykle definiowane przed
diagramami klas
Perspektywa przypadków użycia
• Przypadki użycia
– Zachowania systemu z
punktu widzenia
• Użytkowników
• Analityków
• Osób wykonujących
testy
– Aspekty statyczne
• diagramy przypadków
użycia,
– Aspekty dynamiczne
• diagramy interakcji
• diagramy stanów
• diagramy czynności
• Notacja
– Przypadek użycia
– Aktor
– Interakcja
– Blok ponownego
użycia
– Relacja «include»
lub «extend»
– Nazwa systemu
• wraz z
otoczeniem
wypłata
pienięd
zy
klient
weryfikac
ja
klienta
«
include
»
System obsługi
klienta
wnętrze systemu
Podstawowe pojęcia - aktor
• Ktoś lub coś spoza systemu,
wchodzący w interakcję z systemem.
• Aktor może zlecić systemowi
zadanie i/lub współdziałać z
systemem w czasie jego realizacji.
• Aktor musi posiadać unikatową
nazwę.
• Aktor – jest pewną klasą obiektów,
związaną z pełnieniem określonej
roli.
<<aktor>>
Podstawowe pojęcia -
przypadek użycia
• Reprezentuje sekwencję akcji
realizowanych przez system,
w efekcie których do aktora
dostarczane są obserwowalne
rezultaty.
• Sekwencja akcji występuje w
odpowiedzi na interakcję
aktora z systemem.
• Przypadek użycia musi
posiadać unikatową nazwę,
która powinna określać cel
zaistnienia przypadku.
Przypadki użycia: zależności
• Zależność zawierania
(inkluzja)
–
Jeden przypadek użycia może
włączyć funkcjonalność innego
–
Włączony przypadek będzie
wołany zawsze, gdy główna
ścieżka jest egzekwowana
• Zależność rozszerzania
(ekstensja)
–
Jeden przypadek użycia można
rozciągnąć na zachowanie się
innego
–
Przykład: przypadek użycia
<uzyskaj aprobatę> można
opcjonalnie rozciągnąć na
przypadek <zmień zlecenie>
klient
banku
wpłata
pieniędzy
wypłata
pieniędzy
kasjer
sprawdź
stan konta
weź
pożyczkę
zarząd
banku
«
include
»
uaktualnianie
stanu konta
«
include
»
«
extend
»
Zależność zawierania: przykład
Sprawdzenie salda
rachunku
Wypłata
Wpłata
<<include>>
<<include>>
Bankomat
<<actor
>>
System
bankowy
Klient
Zależność rozszerzania: przykład
Wydruk
potwierdzeni
a
Wypłata
Wpłata
<<extend>>
<<extend>>
Bankomat
Klient
Generalizacja aktorów
• Generalizacja aktorów
– ustala hierarchię dziedziczenia
dostępu do funkcji systemu
• Aktor wyspecjalizowany
może zrobić to co
ogólniejszy
– co więcej – ma swój własny,
specyficzny sposób korzystania
z systemu.
Generalizacja przypadków
• Generalizacja przypadków: potomny przypadek
dziedziczy wszystkie atrybuty, ciągi zachowań i
punkty rozszerzenia przypadku macierzystego.
Bierze także udział we wszystkich jego związkach.
Operacja bankowa
Wpłata
Wypłata
Polecenie przelewu
Przykładowy diagram
Źródło: AGH
Diagramy interakcji
• Podzbiór diagramów zachowania które
zajmują się interakcjami obiektu.
• Obejmują one:
– Diagramy sekwencji
– Diagramy komunikacji
– Diagramy czasu
– Diagramy przeglądu interakcji
• Diagramy interakcji używa się gdy chcemy
modelować zachowanie się szeregu obiektów
w przypadku użycia
Diagramy sekwencji
• Pokazują kolejność interakcji w scenariuszu
– Aktorzy i komponenty
– Wysyłane komunikaty, zapętlenia
• Użyteczne dla uchwycenia i łatwej wizualizacji
czasowych właściwości scenariusza
• Diagramy sekwencji
– Wzbogacają przypadki użycia
– Dają obraz dynamicznego zachowania się klas
• Jedna pionowa linia przypadająca na obiekt lub na
aktora
– Czas biegnie z góry na dół
– Strzałki przedstawiają komunikaty przesyłane między
obiektami
Użycie diagramów sekwencji
• Diagramy te stosuje się do projektowania,
dokumentacji i walidacji architektury, interfejsów i
logiki systemu
– opisując sekwencję akcji które należy podjąć dla wykonania
zadania czy też scenariusza
• Są one także wykorzystywane jako narzędzia inżynierii
systemów
– do projektowania architektury systemu,
• Także w inżynierii procesów biznesowych jako
– Diagramy przepływu procesu,
– Grafy sekwencji komunikatów i przepływu połączeń przy
projektowaniu systemów telekomunikacyjnych czy
bezprzewodowych
• Dla analizy i projektowania stosu protokołów
Symbole nagłówka diagramu
• Aktor
– Reprezentuje zewnętrzną osobę lub
urządzenie interacts with the system
• Obiekt
– Reprezentuje obiekt w systemie lub jeden
z jego komponentów
• Unit
– Reprezentuje podsystem, komponent, unit,
lub inny element logiczny w systemie
• Separator
– Reprezentuje interfejs lub granicę między
podsystemami, komponentami lub unitami
• interfejs bezprzewodowy, Internet, sieć
• Grupa
– Pogrupowanie elementów nagłówka w
podsystemy lub komponenty
Symbole treści diagramu -1
• Akcja
– Reprezentuje akcję podjętą przez aktora,
obiekt lub unit
• Asynchroniczny komunikat
– pomiędzy elementami nagłówka
• Blok
– Blok reprezentuje pętlę lub uwarunkowanie
dla określonego elementu nagłówka
• Komunikat wywołania
– Komunikat wywołania (procedury) między
elementami nagłówka
• Komunikat kreowania
– Komunikat „kreuj" który kreuje element
nagłówka (reprezentowany przez lifeline
going from dashed to solid pattern)
Symbole treści diagramu - 2
• Destrukcja elementu
– Reprezentuje destrukcję elementu nagłówka
• Komunikat destrukcji
– Reprezentuje destrukcję elementu nagłówka jako
wynik wywołania z innego elementu
• Link diagramu
– Reprezentuje część diagramu traktowaną jako
blok funkcjonalny
• Opcjonalnie może reprezentować link do innego
diagramu.
• Blok „Else”
– Reprezentuje część "else" w diagramie bloku
• Nota do przepływu
– Notatka dokumentacyjna przypisana automatycznie do
przepływu po poprzedzającym elemencie
• Swobodna nota
– Notatka dokumentacyjna która może być umieszczona
gdziekolwiek w diagramie
Symbole treści diagramu - 3
• Komunikat
– Prosty komunikat między elementami nagłówka
• Przerwa strony
• Komunikat zwrotny - między elementami
nagłówka
• Start scenariusza
• Przypadek scenariusza
– Start alternatywy lub przypadku w scenariuszu
• Koniec scenariusza
• Stan - Zmiana stanu dla elementu nagłówka
• Ustalony stan - w systemie
• Start timera
– Start timera dla danego elementu najłówka
• Stop timera
– Zatrzymanie timera dla danego elementu najłówka
• Upłynięcie timera
– Upłynięcie czasu dla danego elementu nagłówka
Przykład diagramu sekwencji
• Graficzne zobrazowanie interakcji obiektów w czasie
– Zwykle pokazują użytkownika (aktora), oraz obiekty i komponenty z
którymi mają interakcję
Komunikaty przekazywane między obiektami staną się operacjami klas w końcowym modelu
Obszary zastosowań
• Złożone interakcje pomiędzy komponentami
– Zwłaszcza gdy komponenty są tworzone równolegle przez
różne zespoły
• Rozwinięcie przypadków użycia
– Diagramy sekwencji opisują spodziewane zachowanie się
systemu
• Rozproszone oraz internetowe systemy
– dla dokumentowania i walidacji architektury, interfejsów i logiki
komponentów składowych
• Złożona logika
– Przez pokazanie interakcji między różnymi obiektami Maszyny
stanowe
– Telekomunikacyjne, bezprzewodowe i wbudowane systemy
szeroko stosują projektowanie oparte na maszynach stanowych
Kartkówka
•
•
•
•
•
•
•
• Temat Nr. 29
W grupach proszę opracować tematy ćwiczeń do wyboru:
Proszę podzielić pracę między uczestników grupy,
aby przedstawić jak najpełniejszą dokumentację.
Zbiorowo proszę ocenić poziom opracowania części
składowych opracowania.
Diagramy komunikacji
• Diagramy te opisują interakcje między obiektami w
postaci sekwencji komunikatów
• Diagramy komunikacji
biorą informację z
diagramów klas, sekwencji, oraz przypadków
użycia
– opisując zarówno statyczną strukturę i dynamiczne
zachowania w systemie
• Pokazują obiekty i ich związki z innymi obiektami
systemu oprócz tego jak oddziaływają nawzajem
• Związki między obiektami nie są widoczne w
diagramach sekwencji
– Zaawansowane narzędzie modelowania może z łatwością
przekształcić diagram komunikacji w diagram sekwencji i
na odwrót
Przepływ komunikatów
•
Przeciwnie do diagramów sekwencji, diagramy
komunikacji nie odnotowują bezpośrednio czasu
– W to miejsce numerują komunikaty w kolejności ich
egzekucji
•
Diagramy komunikacji pokazują przepływ
komunikatów pomiędzy obiektami w obiektowo-
zorientowanej aplikacji
– ponadto podają podstawowe związki (relacje) między
klasami
•
Diagramy komunikacji tworzy się w ten sam sposób
jak
diagramy sekwencji
– Jedyną istotną różnicą jest notacja robiona w inny sposób
Symbole diagramu komunikacji
Obiekt: współdziała z innymi
obiektami w systemie. Przedstawia
prostokąt zaopatrzony w nazwę
obiektu w środku, poprzedzoną
dwukropkiem i podkreśloną.
Relacja/Asocjacja: link łączący
skojarzone obiekty. Kwalifikatory
mogą znajdować się po obu stronach
asocjacji dla pokazania liczności
Komunikaty: Strzałka wskazująca
na docelowy obiekt pokazuje
interakcje pomiędzy obiektami.
Liczba reprezentuje kolejność
/sekwencję tej interakcji.
Przykład: Administrowanie kursem
Ten diagram używa klasy CourseAdministrator, Course, Topic, oraz Tutor
Diagramy czasu
• Używa się ich do analizy zachowania się jednego
lub więcej obiektów w danym okresie czasu.
• Rozróżnia się dwie podstawowe odmiany
diagramów czasu (harmonogramowania):
– Notacja zwięzła
– Notacja silna.
• Diagramy czasu
często używa się w
projektowaniu programów wbudowanych
(embedded)
– Takich jak oprogramowanie sterujące wtryskiem paliwa w
silnikach samochodowych,
– Niekiedy używa się je również w programach biznesowych
Pojęcia diagramu czasu
• Diagram harmonogramowania reprezentuje na osi
czasu zmiany dopuszczalnych stanów, jakie może
przyjmować instancja klasyfikatora uczestnicząca
w interakcji
• Podstawowe kategorie pojęciowe
– Klasyfikator
• Pojęcie klasyfikatora związane jest z bytem stanowiącym
opis własności zbioru wystąpień (instancji).
– nazwa stanu - typowe stany takie jak:
• bezczynność,,,
• wykonywanie,
• obliczanie.
– linia zmiany stanów instancji klasyfikatora
• Może przedstawiać stany instancji klasyfikatora lub
określonej, mierzalnej zmiennej
Przykłady harmonogramów
• Diagram
harmonogramowania dla
obiektu klasy Rezerwacja
• Diagram
harmonogramowania ze
zdarzeniami i
ograniczeniami
czasowymi
• Alternatywna notacja
diagramów
harmonogramowania
Komunikaty na diagramach czasu
Diagramy przeglądu interakcji
• Diagram przeglądu interakcji jest pewną formą
diagramu aktywności, w którym węzły są diagramami
interakcji.
– Diagramy interakcji mogą obejmować diagramy sekwencji,
komunikacji, przeglądu interakcji oraz harmonogramowania
• Większość notacji w diagramach przeglądu interakcji
jest taka sama jak w diagramach aktywności
– Na przykład, start, koniec, romb decyzyjny, węzły
rozwidlenia i złączenia są takie same.
• Dwa nowe składniki notacji:
– Występowanie interakcji
– Elementy interakcji
Przegląd interakcji - sprzedaż
Diagramy stanów
• Diagramy stanów używa się dla opisu
zachowania się systemu
– Opisują one wszystkie możliwe stany obiektu w
następstwie zdarzeń
– Każdy diagram reprezentuje zwykle obiekty jednej
klasy i śledzi różne stany tych obiektów w systemie
• Można użyć diagramy stanu dla
zademonstrowania zachowania się obiektu w
obrębie wielu przypadków użycia w systemie.
– Diagramy stanów stosuje sie nie dla wszystkich klas
– Nie są one też użyteczne dla opisu kolaboracji
wszystkich obiektów zawartych w przypadku użycia
• Stosowany do pokazania przejść lub zmian
stanu jakie obiekt może mieć w systemie
Elementy diagramu stanów
• Podstawowe elementy to są:
– Zaokrąglone prostokąty
reprezentujące stan obiektu
– Strzałki wskazujące przejście do
następnego stanu.
• Diagramy stanów zazwyczaj
pokazują start i koniec
– Wszystkie diagramy stanów
pokazują początkowy stan
obiektu
• Stan w chwili kreowania obiektu
– Wychodząc z początkowego
stanu obiekt zaczyna zmieniać
stan
Symbole diagramu stanów
• Stan początkowy
– Pokazuje punkt startowy
• Stan:
– Reprezentuje stan obiektu w danej chwili
• Przejście: Strzałka wskazująca przejście
obiektu z jednego stanu do drugiego
• Zdarzenie i akcja : trigger powodujący
przejście w następstwie zdarzenia lub akcji
• Signal: Komunikat może być wysłany do
stanu wywołującego przejście; ten
komunikat nazywa sie signal.
Reprezentowany jako klasa z ikoną
<<Signal>> ponad opisem akcja/zdarzenie
• Final State: The end of the state diagram
Przykład: Zakupy
Przykład: Zamówienie
Gdy obiekt wejdzie do stanu
Sprawdzanie wykonuje czynność
„sprawdź magazyn." Po wykonaniu
tej czynności obiekt przechodzi do
następnego stanu zależnie od
sytuacji [mamy wszystkie pozycje]
lub [brak jednej pozycji].
Gdy brak jest towaru zamówienie
zostaje anulowane. Gdy są
wszystkie zamawiane towary
zamówienie kieruje się do
ekspedycji (Wysyłka) i wykonuje
się czynność. „zainicjuj wysyłkę".
Po wykonaniu tej czynności obiekt
przechodzi do stanu Dostawa.
Diagram aktywności
• Odmiana diagramu stanów
obrazująca strumień kolejno
wykonywanych czynności
– przedstawia sekwencyjne
lub współbieżne kroki
procesu obliczeniowego
• Pokazuje jak są zbudowane
workflows w systemie
– Możliwość wielu ścieżek
decyzyjnych
– Gdzie można się spodziewać
równoległego wykonywania
czynności
Diagramy aktywności
• Diagramy te opisują stan czynności
przez pokazanie sekwencji
wykonanych czynności
– Diagramy aktywności mogą pokazywać
czynności które są warunkowe lub
równoległe.
• Diagramy aktywności nie pokazują
jednakowoż szczegółów jak obiekty
się zachowują lub jak obiekty
kooperują ze sobą
• Diagramy te czyta się z góry na dół
– Mają one odgałęzienia i rozwidlenia
definiujące warunki oraz czynności
równoległe
– Rozwidlenie stosuje się, gdy kilka
czynności mogą mieć miejsce w tym
samym czasie
Symbole diagramu aktywności
• Początek
– Pokazuje punkt startowy
• Aktywność:
Czynność do
wykonania
• Przejście: Strzałka wskazująca
kierunek
• Romb decyzyjny: badanie warunku
• Fork:
– Rozwidlenie na kilka operacji.
• Join:
– złączenie kilku operacji
• Koniec: Punkt końcowy diagramu
Aktywnosc
Przykład: Realizacja zamówienia
Przykład: Sterownik telewizora
Diagram klas
• Diagram klas pokazuję części składowe
obiektowo-zorientowanego systemu
– Jest to przedstawienie statycznego widoku modelu, lub
części modelu opisujące jego atrybuty i zachowanie
• Bardziej niż uszczegółowiając metody dla wykonania
operacji
• Diagramy klas są najbardziej użyteczne w
ilustrowaniu relacji między klasami oraz
interfejsami
• Generalizacje, agregacje i asocjacje są wielce
pożyteczne w zakresie dziedziczenia, kompozycji
lub użycia, a także połączeń.
Model logiczny
• Statyczne przedstawienie klas i
obiektów tworzących przestrzeń
projektowania/analizy
• Model domeny
– Zgrubne przedstawienie obiektów i
podmiotów biznesowych
• Model klasy
– Ścisły projektowo zorientowany model
– Klasa jest typową konstrukcją UML
• klasa jest specyfikacją
• obiekt jest instancją klasy
• możliwość dziedziczenia
• zawieta stan (atrybuty)
• manipuluje nimi (zachowanie)
– Dobry obiektowo-zorientowany projekt
ogranicza bezpośredni dostęp do
atrybutów klas
• Opis zbioru
obiektów
–
Nazwy proste lub
ścieżkowe
–
Z atrybutami lub
bez
–
Z operacjami lub
bez
• Asocjacja
• Agregacja
• Generalizacja
• Zgrupowanie
elementów modelu
–
możliwa
enkapsulacja
–
powtórne użycie.
• Komentarz
tekstowy
Klasy
• Klasa jest elementem, który
definiuje atrybuty i zachowania
jakie obiekt może mieć
• Zachowanie się jest opisane przez
komunikaty, które klasa rozumie,
wraz z operacjami właściwymi dla
każdego komunikatu
• Klasy mogą też zawierać definicje
ograniczeń, wartości znaczników i
stereotypów.
• Klasy są przedstawiane jako
prostokąty pokazujące nazwę klasy
i opcjonalnie nazwy atrybutów i
operacji
– Oddzielne pola rozdzielają nazwy klas,
atrybutów i operacji.
Obiekty
• Obiektem jest jakaś osoba, miejsce,
rzecz, koncept, zdarzenie, ekran, lub
raport odnoszący się do danego
systemu
• Obiekty zarówno wiedzą o rzeczach
(mają atrybuty) jak też robią pewne
rzeczy (mają metody)
• Klasa jest reprezentacją obiektu,
czymś w rodzaju szablonu według
którego tworzy się obiekty.
– Jedna klasa nazwana Student będzie
reprezentować całe zbiorowisko studentów
• Obiekt jest konkretnym
urzeczywistnieniem klasy
Przykładowe diagramy
Proste asocjacje
•
Asocjacje istnieją między
obiektami, reprezentują one
trwałe zależności
•
Operacje mogą ustalać/
przerywać asocjacje między
obiektami
Jednokierunkowa
nawigacja między
klasami
Określenie ról
w asocjacjach
Symbole diagramu klas - 1
• Klasy
• Aktywna klasa
– inicjuje i kontroluje bieg czynności
– pasywne klasy przechowuję dane i wspomagają
inne klasy
• Widzialność
– Prywatna widzialność ukrywa informację przed
wszystkimi na zewnątrz danej klasy
– Publiczna widzialność pozwala wszystkim klasom
widzieć zaznaczoną informację
– Chroniona widzialność udostępnia informację klas
dzieci którą dziedziczą od klasy rodzica
• Asocjacje
– Nazwę asocjacji umieszcza się w sąsiedztwie linii
asocjacji
• Wypełniony grot wskazuje kierunek relacji
– Odgrywane role zaznacza się przy końcach asocjacji
• Role reprezentują sposób w jaki dwie klasy widzą się
nawzajem
Przykłady: Asocjacje
Zależność jeden-do jednego
Zależność jeden-do wielu
Zależność wielu-do wielu
Symbole diagramu klas - 2
• Liczność
– Notację liczności umieszcza sie przy
końcach asocjacji
• Symbole te zaznaczają liczbę instancji jednej
klasy linked to jednej instancji drugiej klasy
• Ograniczenie
– Umieszcza się wewnątrz nawiasów
klamrowych {}
Proste ograniczenie
• Kompozycja i agregacja
– Kompozycja jest odmianą agregacji
cechującą się silnym posiadaniem Klasy A,
całości i Klasy B, jej części
• Kompozycję oznacza się wypełnionym
rombem
– Przy agregacji „cała" klasa odgrywa
ważniejszą rolę, lecz te dwie klasy nie są od
siebie zależne
• Prostą agregację oznacza się pustym rombem
Symbole diagramu klas - 3
• Generalizacja
– Jest to inna nazwa dziedziczenia.
• Odnosi się to do relacji między
dwoma klasami gdy jedna klasa jest
specjalizowaną wersją drugiej.
• Pakiety
– Używa się foldera z zakładką do
pokazania pakietu.
• Nazwę pakietu wpisuje się do
zakładki lub do wnętrza foldera.
• Podobnie jak w klasach można w
pakiecie umieścić listę atrybutów
• Zależności
– Zależność określa taką relację w
której zmiany w jednym pakiecie
będą wpływać na inny pakiet
• Import jest typem zależności dającą
jednemu pakietowi dostęp do
zawartości drugiego
Agregacja i generalizacja
Agregacja
• Jest to specjalizacja asocjacji
• Cechuje się zależnością
‘części’ (lub ‘posiada') między
obiektami odnośnych klas
Generalizacja
• Zależność między klasą a jej
bardziej szczegółowymi wersjami
• Subklasy dziedziczą wszystkie
właściwości superklasy
Przykład: Zamówienie z katalogu
System przetwarzania wsadowego, który zbiera
informacje o godzinach pracy oraz stawkach
wynagrodzeń i na ich podstawie drukuje paski
wynagrodzeń i druki przelewów bankowych.
Model narzędzia raportowania
błędów oprogramowania
Powiązania
Nawigacja
Numer
Klasa
Dziedziczenie
Subklasa
Agregacja
Artefakt
Projekt
Pracownik
Kierownik
Projekta
nt
Kierowany przez
Na temat
Raport błędu
kodowania
Raport
problemu
Wpis do
historii
Log historii
odpowiedzialny za
przydzielony dla
nazwisko: String
nazwa: String
nazwa: String
status: ArtStEnum
id: Int
description: text
priorytet: PriEnum
status: ProbEnum
bugRp: String
kiedy: Date
coZrobiono: text
plikSrc: String
plikDtech: Strin
Źródło: University of Virginia
Perspektywa logiczna
Diagramy obiektów
• Diagramy obiektów modelują instancje
klas
– Ten typ diagramu używa się dla opisu systemu
w konkretnym momencie czasu.
– Z punktu widzenia notacji, diagramy obiektów
pożyczają elementy z diagramów klas
• Wiele diagramów obiektów używa tylko
– Obiekty
• Obiekty są przedstawiane umieszczając nazwę
instancji po której jest dwukropek (:) przed
nazwą klasy.
• Wartości atrybutów zapisuje się parą
"nazwa=wartość"
– Asocjacje – między obiektami
Przykład diagramu obiektów
Diagramy komponentów i wdrażania
• Komponenty
– Fizyczne moduły kodu
– Reprezentują klasy
• Poszczególne realizacje komponentów sa instancjami
tych komponentów
• Węzły
– Dostępne zasoby: stacja robocza, drukarka, serwer, sieć
itp
• Zależności rezydowania, użycia lub wdrożenia
• Asocjacje komunikacyjne
– Powiązania między węzłami
Diagram komponentów
• Diagram komponentów opisuje organizację
fizycznych komponentów w systemie
• Komponenty zarówno oferują jak i używają
interfejsów
– interfejs stanowi definicję zbioru jednej lub więcej metod, i
zero lub więcej atrybutów
• Ten diagram pokazuje zależności między
komponentami, w tym komponenty kodu
źródłowego, komponenty kodu binarnego, oraz
komponenty wykonywalne
– Pewne komponenty mają miejsce w czasie kompilacji, w
czasie łączenia, w czasie wykonywania.
Komponenty i interfejsy
• Diagram komponentowy z
etykietami stereotypów
Notacja UML 1.4 w dalszym ciągu akceptowana w
UML 2.x
Diagram komponentów UML 2
• W UML 2 komponent jest traktowany
jako specjalizowana wersja konceptu
klasy
– Interfesy mogą być układane pionowo
• <<provided interfaces>> – oferowane
• <<required interfaces>> - żądane
– Stereotypem komponentu jest
<<component>>
• Alternatywna notacja używa
graficznych symboli interfejsów
• Poniżej pokazano trzy możliwe symbole
komponentu używane w UML 2
Diagram komponentów UML 1.4
Diagram komponentów UML 2
Wewnętrzna struktura komponentu
• Czasem ma sens pokazanie wewnętrznej struktury komponentu
– Komponent Store oferuje interfejs OrderEntry oraz potrzebuje interfejs Account
• Interfejsy te mają kwadracik na brzegu komponentu zwany port (bramka)
– Komponent Store składa się z trzech komponentów: Order, Customer, Product
• Port OrderEntry deleguje do obliczeń interfejs OrderEntry komponentu Order
• Żądany interfejs Account komponentu Customer jest delegowany do portu Account w Store
Diagramy wdrożenia
• Diagramy wdrożenia obrazują fizyczne zasoby
systemu
– węzły, komponenty i połączenia
• Diagram wdrożenia przedstawia konfigurację
elementów czasu wykonywania
– Komponenty oprogramowania, procesy, oraz ich obiekty
– Instancje komponentów oprogramowania przedstawiają
przejaw czasu wykonywania jednostek kodu
• Obejmuje to modelowanie konfiguracji
sprzętowych wraz z ich komponentami
oprogramowania
Symbole diagramu wdrożenia
• Węzeł
– Węzeł reprezentuję element sprzętowy w
systemie
• Węzeł przedstawia się jako trójwymiarowy sześcian
• Komponent
– Komponent reprezentuje element
oprogramowania w systemie, taki jak pliki jodu
źródłowego, programy, dokumenty, oraz pliki
zasobów
• W diagramie wdrożenia, określenia miejsca ich
wdrożenia
• Komponent przedstawia się jako prostokąt z
dworna prostokątami sterczącymi z lewej strony,
• Asocjacja
– Asocjacja oznacza linię komunikacji pomiędzy
elementami sprzętowymi
• Rysuje się jako ciągłą linię między dwoma węzłami.
Przykład: Diagram wdrożenia
• Węzeł CustomerComputer ma dwa
komponenty:
– WebBrowser połączony do interfejsu
komponentu Apache httpd węzła
WebServer
– JavaApplet połaczony przez SSL do
interfejsu w JavaServlet węzła
WebBrowser
– Węzły połączone są przez TCP/IP
• Węzeł DatabaseServer ma
komponent MySQL
– Interfejs JDBC jest połączony przez
SSL z komponentem JavaServer
węzła WebBowser
– Węzły połączone są przez TCP/IP
Diagramy komponentów i
wdrożenia: przykład
•
Pakiet Interfejs użytkownika
wykorzystuje pakiet Narzędzia
oraz interfejs iPrzetwarzanie
biznesowe, udostępniony przez
podsystem Przetwarzanie
biznesowe
•
Pakiety Interfejs użytkownika
oraz podsystemy Przetwarzanie
biznesowe i Dane rezydują w
komponencie Interfejs
użytkownika.
•
Podsystem Przetwarzanie
biznesowe używa pakietu
Narzędzia i wykorzystuje
interfejsy iProdukt oraz
iSurowiec udostępnione przez
podsystem Dane
•
Komponent Interfejs
użytkownika jest wdrożony w
węźle Kierownik projektu
•
Węzeł Kierownik projektu jest
połączony z węzłem Archiwum
dokumentacji
Diagram wdrożenia UML 2
Literatura