1
Notacja UML
w skrócie
wprowadzenie do modelowania oprogramowania
Dlaczego ten temat?
Prawie każdy w swojej pracy wykorzystuje notację
graficzną (np. do modelowania, ilustrowania itp.)
Prawie każdy stosuje inną, którą musi definiować
We wspólnej grupie (produkcyjnej) konieczne jest
stosowanie jednolitej, wspólnej, dobrze zdefiniowanej
notacji, w tym graficznej
Notacja powinna być właściwa do zastosowań
Jest wskazane, aby notacja była popularna i powszechnie
uznana
W procesie dydaktycznym nie jest wskazane stosowanie
tylko jednej notacji, ale najpopularniejsze trzeba
uwzględniać
Modele budowane w procesie
wytwarzania oprogramowania
Biznesowy
Wymagań
Analityczny
Danych
Projektowy
Implementacyjny
Modele budowane w procesie
wytwarzania oprogramowania
Domain
Model
Requirements
Business
Modeling
Design
Partial artifacts,
refined in each
iteration.
Use-Case Model
text
use
cases
:System
foo( x )
system
operation
contracts
system
sequence
diagrams
bar( y )
use
case
diagrams
*
*
Design Model
system
operations
Modele: model dziedziny
Rodzaje diagramów
Modelujące algorytmy/aktywności
Modelujące związki statyczne między elementami
projektu oprogramowania
Modelujące związki dynamiczne między
elementami projektu oprogramowania
Modelujące wymagania
Modelujące organizacje (procesy biznesowe)
Modelujące związki między elementami
implementacyjnymi
Modelujące strukturę techniczną
2
Modele budowane w procesie wytwarzania
oprogramowania (zgodnie z kolejnością
budowania)
Biznesowy
Wymagań
Analityczny
Projektowy
Danych
Implementacyjny
Konstrukcyjny
Elementy notacji (wprowadzenie)
<Actor Name>
(f rom Ac tors)
<Use Case Name>
(from <Use Case Name>)
NewClass
Atrybut
Operacja()
NewPackage
NewState
entry/ Nam e
exit/ Na me
do/ Name
event Event In/ ^Event Out
NewActivity
New Object :
NewClass
NewCo
mponent
<processor name>
pre emptive
<process name >
<th rea d n am e>
<device name>
Elementy notacji - związki
<Actor Name>
(f rom Actors)
<Use Case Name>
(from <Use Case Name>)
NewClass
Atrybut
Operacja()
NewClass 2
NewClass
Atrybut
Operacja()
NewClass 2
NewClass
Atrybut
Operacja()
NewClass 2
NewClass
Atrybut
Operacja()
NewClass2
NewPackage
NewClass2
<Use Case Name>
(from <Use Case Name>)
<Use-Case Name>
<<use-case realization>>
<<realize>>
NewActivity
[ Guard ]
New Object :
NewClass
: NewClass
Operacja( )
New Object :
NewClass
: NewClass
1: Operacja( )
<processor name>
preemptive
<process name>
<thread name>
<device name>
Connection
Stereotypy
NewPackage
NewPackage
<<layer>>
NewPackage
<<subsystem>>
<Use Case Name>
(from <Use Case Name>)
NewUs eCase
<Use Case Name>
(from <Use Case Name>)
NewUs eCase
<<include>>
NewClass
Atrybut
Operacja()
NewClass
<<ste r>> Atrybut
<<ste r>> Operacja()
<<process>>
Sposoby prezentacji stereotypów
ClassB
<<subsystem>>
InterfaceB
<<Interface>>
BuisnessW_X
<<Business Worker>>
BuisnessW_X
CC
atrybut
operacja()
CC
atrybut
operacja()
<<control>>
CC
atrybut
operacja()
ClassB
<<subsystem>>
InterfaceB
BuisnessW_X
Diagram przypadków użycia
Graficzny model wymagań funkcjonalnych
Specyfika podejścia – opis interakcji
systemu z otoczeniem
Przedstawia:
Otoczenie – aktorów
Sposób używania stemu przez otoczenie –
przypadki użycia
Związki otoczenia z przypadkami użycia
Hierarchię otoczenia i przypadków użycia
Związki między przypadkami użycia
3
Przykładowy diagram
Register
Rola 1
UC_X
System 1
Rola 2
Find_a_Book
Hierarchia aktorów i przypadków
użycia
Buy_Books
User
Admin
Create_Account
Make_Deal
Uszczegółowienie przypadków
użycia
Rola 1
Rola 2
Get_Permission
5Get_Key
Fill_Tank
Borrow_Car
<<include>>
<<include>>
<<extend>>
NewUseCase6
NewUseCase3
<<extend>>
<<include>>
Biznesowe przypadki użycia
(organizacji)
Fragment modelu organizacji (przedsiębiorstwa)
Wykonywany opcjonalnie na etapie
wstępnym/strategicznym
Zazwyczaj duży poziom ogólności
Przedstawia sposób widzenia całej organizacji
przez jej otoczenie
Projektowane oprogramowanie jest tylko częścią
tak modelowanej organizacji
Modyfikacja „zwykłego” diagramu przypadków
użycia przez wprowadzenie odpowiednich
stereotypów
Przykładowy diagram
Rola 1
Rola 2
NewUseCase2
NewUseCase5
NewUseCase4
NewUseCase
<<include>>
<<include>>
<<extend>>
NewUseCase6
NewUseCase3
<<extend>>
<<include>>
Diagramy aktywności
Kiedyś rozumiany jako specjalizacja
diagramu stanów UML- zmiana
Wykorzystywany do opisu wymagań
procesowych (przypadki użycia są jego
fragmentem)
4
Przykładowy diagram
Ndo_A
Do_B
NewActivity3
NewActivity4
[ Warunek 1 ]
[ Warunek 2 ]
[ Warunek 3 ]
Stany początkowe i końcowe
NewActivity
NewActivity2
NewActivity
NewActivity2
NewActivity
NewActivity2
NewActivity3
Operacje równoczesne
NewActivity
NewActivity2
NewActivity3
Operacje równoczesne
NewActivity
NewActivity2
NewActivity3
NewActivity5
NewActivity4
„Tory pływackie”
NewActivity
NewActivity3
NewActivity2
NewSwimlane2
New Sw iml ane
Diagram stanów
Wykorzystywany do opisania dynamiki
(zachowania się) jednego elementu modelu
w zależności od wcześniejszych zdarzeń
Opracowane na bazie map stanów (Harel)
5
Przykładowy diagram
Pracuje
event wył
ą
czenie/ zatrzymanie
Przerwa
event wył
ą
czenie/ null
Wył
ą
czone
wł
ą
czenie
wył
ą
czenie
przerwanie
wznowienie
/
aktywuj
przerwanie
wznowienie
wył
ą
czenie
Akcje wykonywane w stanie
NewState
entry/ Akcja 1
do/ Akcja 2
exit/ Akcja 3
event Zdarzenie In( Arg )[ War 1 ]/ ^Cel.Zdarzenie Out(Arg)
event Zdarzenie In( Arg )[ War 2 ]/ ^Cel.Zdarzenie Out(Arg)
NewState 2
Zdarzenie In 2( Arg )[ War ] / Akcja ^Cel.Zdarzenie Out(Arg)
Zdarzenie 1
Zagnieżdżanie stanów i stany
historyczne
State1
H
State2
State4
State5
State3
H
State2
State4
State5
State3
State4
State5
z-0-1
z-4-5
z-3-3
z-1-0
z-2-3
z-0-2
Diagramy sekwencji
Modelują dynamikę oprogramowania
Uwypuklają następstwa czasowe
komunikatów
Prezentują jedną ścieżkę realizacji
konkretnego wymagania,
odpowiedzialności lub operacji
Przykładowy diagram
a : ClassA
: ClassB
: ClassC
message 1( )
message 2( )
message 3( )
message 4( )
Wywołania warunkowe i iteracje
:ClassA
: ClassB
: ClassC
messageX1( )
message 2( )
message 3( )
message 4( )
Opis warunku
Opis warunków
iteracji
Opis stanu obiektu
6
Komunikaty zwrotne
: NewClass
: NewClass2
: NewClass3
messageX( )
messageZ( )
messageY( )
Diagramy komunikacji
(współpracy)
Tak jak diagramy sekwencji, modelują
dynamikę oprogramowania
Uwypuklają związki między obiektami
Przykładowy diagram
: NewClass
: NewClass2
: NewClass3
1: message 1( )
2: message 2( )
3: message 3( )
4: message 4( )
Równoznaczność diagramów
sekwencji i komunikacji
: NewClass
: NewClass2
: NewClass3
message 1( )
message 2( )
message 3( )
message 4( )
: NewClass
: NewClass2
: NewClass3
1: message 1( )
2: message 2( )
3: message 3( )
4: message 4( )
Diagramy klas
Prezentują statyczne związki między elementami
logicznymi oprogramowania
Klasy
Pakiety
Interfejsy
Podsystemy
Warstwy
Związki między klasami określają wzajemną
„widoczność” klas
Zależności między pakietami wynikające z
„widoczności” klas
Opis klasy
Nazwa klasy
Operacje (odpowiedzialności, metody)
Atrybuty
Nazwa
atrybut 1 : Boolean
atrybut 2 : Integer
operacja 1()
operacja 2()
7
Rodzaje klas
Klasa zwykła
Klasa sparametryzowana
Klasa abstrakcyjna
Operacja abstrakcyjna
<<abstract>>
AC
operacja zwykła()
operacja abstrakcyjna()
Arg1
Arg2
PaCl
CC
Przykładowy diagram
A
message 3()
B
message 1()
message 3()
message 4()
2..7
1
+rola 2
1
C
D
message 2()
0..1
+rola 3
1..n
+rola 1
0..1
E
message C()
Związki
Asocjacje
Jedno i dwukierunkowe
Agregacje
Kompozycje
Generalizacja
(dziedziczenie)
Realizacja
Zależności
Ne wClass6
NewClass7
Ne wClass6
NewClass7
Ne wCl ass6
NewClass7
Ne wCl ass6
NewClass7
NewCl ass6
NewClass7
NewClass6
NewClass7
NewClass6
NewInterface7
Opis asocjacji
Nazwa (nieużywana)
Stereotyp
Nazwy ról
Krotność
Zakres widzialności
A
B
1..7
2
Nazwa
<<sterotyp>>
-rola B
+rola A
Zakres widzialności
Publiczny
Chroniony
Prywatny
Implementacyjny (zaprzyjaźniony)
NewClass6
NewClass7
+rola
#rola
-rola
rola
Nazwa
publiczny
chroniony
prywatny
Iiplementacyjny
publiczny()
chroniony()
prywatny()
implementacyjny()
Nazwa
+ Ppubliczny
# chroniony
- prywatny
Implementacyjny
+ publiczny()
# chroniony()
- prywatny()
implementacyjny()
Wykorzystanie pakietów
Pakiet 1
Pa kiet 2
NewClass
message 3()
(from Pakiet 1)
NewClass2
message 1()
message 3()
message 4()
(from Pakiet 1)
0..n
1
+Rola 2
1
0..n
NewClass4
(from Pakiet 2)
NewClass3
message 2()
(from Pakiet 2)
1..n
0..1
+Rola 3
1..n
+Rola 1
0..1
NewClass5
(from Pakiet 2)
8
Wykorzystanie podsystemów i
interfejsów
Podsystem to wyizolowany pakiet
widoczny tylko poprzez dokładnie
określony interfejs
Interfejs definiuje tylko operacje i stałe
implementowane w pakiecie, podsystemie
lub klasie
NewInterface
operacja 1()
operacja 2()
NewPackage
<<subsystem>>
NewInterface
operacja 1()
operacja 2()
<<Interface>>
NewClass8
Diagram procesów
Przedstawia hierarchię procesów,
podprocesów i wątków
Określa związek między procesami oraz
między procesami a implementującymi je
klasami
Przykładowy diagram procesów
Thread Name 1
<<thread>>
Threa d Nam e 2
<<thread>>
Process Name
<<process>>
Subprocess Name
<<process>>
Process Name 2
<<process>>
Thread Name 3
<<thread>>
Diagram komponentów
Jak perspektywa logiczna ma być
„zanurzona” w środowisku
implementacyjnym
Związek klas z komponentami
Komponenty odpowiadają zazwyczaj
jednostkom kompilacji (plikom)
Pakiety odpowiadają podsystemom
implementacyjnym (katalogom, pakietom)
Przykładowy diagram
NewSubprogSpec
NewCo
mponent
NewSubprogBody
NewMainSubprog
NewPackageSpec
NewPackageBody
NewTaskSpec
NewTaskBody
Diagram montażowy
Uświadamia ograniczenia konstrukcji
oprogramowania wynikające ze struktury
technicznej
Nie ma na celu precyzyjnego modelowania
struktury technicznej
Przedstawia elementy struktury technicznej:
Procesory – elementy aktywne
Urządzenia – elementy pasywne
Połączenie między elementami
Przedstawia rozmieszczenie programów (i
procesów) w procesorach
9
Diagram montażowy: przykład
NewCo
mponent
NewCo
mponent
Serwer
preemptive
NewMainSubprog
Process Name
Thread Name
Urz
ą
dzenie
USB
Stacja
Proces
Ethernet 100
Przykłady wykorzystania DM
Modelowanie oprogramowania w tym
statyczny model procesów i model
komunikacji/synchronizacji
Modelowanie organizacji – modelowanie
procesów organizacji
Model matematyczny – wektory stanów
56
Too many different views … ?
UML
+ Metodyka (RUP)
+ ...
= Projektowanie
I co dalej ?
Notacja UML
Koniec