Microsoft PowerPoint - 21_1_Notacja_UML_w

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ą

Modele budowane w procesie wytwarzania
oprogramowania (zgodnie z kolejnością
budowania)

Biznesowy

Wymagań

Analityczny

Projektowy

Danych

Implementacyjny

Konstrukcyjny

Elementy notacji (wprowadzenie)

(f rom Ac tors)

(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

pre emptive

Elementy notacji - związki

(f rom Actors)

(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

(from <Use Case Name>)

<Use-Case Name>

<<use-case realization>>

<<realize>>

NewActivity

[ Guard ]

New Object :

NewClass

: NewClass

Operacja( )

New Object :

NewClass

: NewClass

1: Operacja( )

preemptive

Connection

Stereotypy

NewPackage

<<layer>>

NewPackage

<<subsystem>>

(from <Use Case Name>)

NewUs eCase

(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

atrybut

operacja()

CC
atrybut

operacja()

<<control>>

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

Przykładowy diagram

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

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

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

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)

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

State2

State4

State5

State3

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

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

Rodzaje klas

Klasa zwykła

Klasa sparametryzowana

Klasa abstrakcyjna

Operacja abstrakcyjna

<<abstract>>

operacja zwykła()
operacja abstrakcyjna()

Arg1
Arg2

PaCl

Przykładowy diagram

message 3()

message 1()
message 3()
message 4()

2..7

+rola 2

message 2()

0..1

+rola 3

1..n

+rola 1

0..1

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

1..7

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

+Rola 2

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)

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

Diagram montażowy: przykład

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

Too many different views … ?

UML

+ Metodyka (RUP)

+ ...

= Projektowanie

I co dalej ?

Notacja UML

Koniec