Inżynieria Oprogramowania wykład 4 - UML

1

Inżynieria oprogramowania

Inżynieria oprogramowania

(4)

(4)

→ Elementy notacji (języka) UML

Wykorzystano: materiały pomocnicze do książki Booch,

Rumbaugh, Jacobson „UML-przewodnik użytkownika” oraz szeroko

dostępną literaturę…

Przygotował: dr inż. Dariusz

Pierzchała

[e-mail]

Inżynieria Oprogramowania wykład 4 - UML

2

O czym teraz…



Geneza i charakterystyka UML;



Notacja UML;



Cel:



Zapoznanie z wybraną notacją wykorzystywaną w

modelowaniu, analizie i projektowaniu systemów

informatycznych;

Inżynieria Oprogramowania wykład 4 - UML

3

Notacja



W inżynierii oprogramowania w każdej

metodyce wytwarzania SI określa się m.in.:



modele systemu,



notację (język)

używaną do zapisu modeli;



Notacja:



Ułatwia

dokumentowanie

pośrednich i końcowych

wyników projektu;



Wspomaga

pamięć i wyobraźnię;



Ułatwia

komunikację

zarówno między członkami

zespołu projektowego, jak i między zespołem

projektowym a klientem;



Notacja powinna być powszechnie uznawana –

ideałem są standardowy;

Inżynieria Oprogramowania wykład 4 - UML

4

Notacja



Rodzaje notacji:



tekstowo-opisowa,



specyfikacje - ustrukturalizowany zapis tekstowy i

numeryczny,



notacje graficzne;



Jeżeli notacja posiada składnię (np. symbole

graficzne) oraz semantykę (znaczenie symboli

graficznych), staje się językiem;



Szczególną uwagę skupimy na notacji

graficznej;



Omówimy notację (język)

UML

….

Inżynieria Oprogramowania wykład 4 - UML

5

UML – notacja obiektowa



Unified Modeling Language – UML



The Unified Modeling Language™ (UML™) is the industry-standard

language for specifying, visualizing, constructing, and

documenting the artifacts of software systems.

(http://www-306.ibm.com/software/rational/uml/)



Znormalizowany język graficzny służący do specyfikowania,

tworzenia i dokumentowania wyników (np. modeli) systemów

informatycznych;



Cechy:

•uniwersalny

– może być stosowany do modelowania zarówno

systemów informacyjnych, systemów WWW, systemów czasu

rzeczywistego;

•wspomaga jednoznacznie i szczegółowo

specyfikowanie

istotnych

decyzji etapów analizy, projektu i implementacji;

•umożliwia dokumentowanie architektury systemu i wszystkich jego

szczegółów w postaci tzw.

artefaktów

: wymagania, architektura,

projekt, kod źródłowy, plany projektu, testy, prototypy, kolejne

wersje.

Inżynieria Oprogramowania wykład 4 - UML

6

UML – notacja obiektowa

How it all began?
(strony IBM)

Ivar Jacobson

Jim Rumbaugh

Grady Booch

Inżynieria Oprogramowania wykład 4 - UML

7

UML – geneza

UML – chronologia zdarzeń

UML 1.1 Wrzesień, 1997

UML 1.0 Styczeń, 1997

UML 0.9 & 0.91 Lipiec 1996

Unified Method 0.8

Booch’93

OMT-2

OMT-1

OOSE

Booch’91

OOPLSA’95

Inne metody

Unified Partner’s Expertise

Fragmentacja

Unifikacja

Standaryzacja

Industrializacja

Styczeń, 2003

UML 1.4

UML 2.0

Ivar Jacobson

James Rumbaugh

Grady Booch

Inżynieria Oprogramowania wykład 4 - UML

8

UML – geneza



Wybrani inicjatorzy UML:



Rational Software Corporation



IBM



Hewlett-Packard



I-Logix



ICON Computing



Intellicorp



MCI Systemhouse



Microsoft



ObjecTime



Oracle



Platinum Technology



Taskon



Texas Instruments/Sterling Software



Unisys

Inżynieria Oprogramowania wykład 4 - UML

9

UML – składowe



Perspektywy modelowe – 4+1:

Implementacyjna

Przypadków użycia

Wdrożenia

Logiczna

Procesowa

Model

Inżynieria Oprogramowania wykład 4 - UML

10

UML – składowe



Słownik UML dzieli się na trzy grupy:



elementy,



związki (relacje),



diagramy;



Model

– kolekcja diagramów i informacji

dodatkowych, opisujących statyczne i
dynamiczne aspekty modelowanego systemu;

Inżynieria Oprogramowania wykład 4 - UML

11

UML – elementy



Elementami UML są podstawowe obiektowe

bloki konstrukcyjne stosowane do budowy

modeli:



strukturalne

•statyczne części modelu reprezentujące składniki pojęciowe

lub fizyczne;

•klasa, interfejs, przypadek użycia, komponent, węzeł,

kooperacja (grupa współdziałania);

Nazwa

Atrybuty

Operacje

Inne

(odpowiedzialność)

Kooperacja

Przypadek

użycia

Komponent

Węzeł

Interfejs

Inżynieria Oprogramowania wykład 4 - UML

12

UML – elementy



Elementami UML są podstawowe obiektowe

bloki konstrukcyjne stosowane do budowy

modeli:



czynnościowe

•elementy dynamiczne wyrażone czasownikami
•interakcja, stan;

stan

Pokaż okno

Inżynieria Oprogramowania wykład 4 - UML

13

UML – elementy



Elementami UML są podstawowe obiektowe

bloki konstrukcyjne stosowane do budowy

modeli:



grupujące

•bloki organizacyjne modelu;
•pakiet;



komentujące

•elementy objaśniające dla uwypuklenia lub zaznaczenia

składników;

•notatka;

Pakiet

Notka

Inżynieria Oprogramowania wykład 4 - UML

14

UML – związki



Związki:



służą do łączenia elementów;



w praktyce najczęściej stosowane są powiązanie i

uogólnienie;



zależność, powiązanie (asocjacja), uogólnienie

(generalizacja), realizację;

związek zależności

związek asocjacji

związek generalizacji

związek realizacji

10..20

*

Rola 1

Rola 2

Inżynieria Oprogramowania wykład 4 - UML

15

UML – związki



Związki klas:



Zależność



Asocjacja



Jednokierunkowa



Dwukierunkowa



Agregacja



Kompozycja



Generalizacji



Realizacja

Inżynieria Oprogramowania wykład 4 - UML

16

UML – diagramy



Diagramy UML są schematami przedstawiającymi

zbiory elementów i związków UML:



podstawowe rodzaje:

•diagram klas,
•diagram obiektów,
•diagram komponentów,
•diagram pakietów;
•diagram wdrożenia;
•diagram przypadków użycia,
•diagram stanów,
•diagram czynności,
•diagram sekwencji zdarzeń (przebiegów),
•diagram współpracy (kooperacji),



w praktyce rzadko prezentuje się systemy informatyczne na

wszystkich diagramach jednocześnie - najczęściej są to

diagramy przypadków użycia, klas, sekwencji zdarzeń;

statyczne aspekty systemu

dynamiczne aspekty systemu

Inżynieria Oprogramowania wykład 4 - UML

17

UML – diagramy



Diagramy UML

Model systemu

Diagramy
struktury

Diagramy
zachowania

Diagramy
interakcji

Diagramy klas

Diagramy obiektów

Diagramy wdrożenia

Diagramy komponentów

Diagramy stanów

Diagramy czynności

Diagramy kooperacji

Diagramy przebiegów

Diagramy przypadków użycia

Diagramy pakietów

Inżynieria Oprogramowania wykład 4 - UML

18

UML – diagramy



Różnice między diagramami w UML 1.4 i 2.0

Diagram

UML 2.0

UML 1.4

Use Case diagram - Diagram przypadków użycia

+

+

Class diagram - Diagram klas

+

+

Package diagram - Diagram pakietów

+

używany nieoficjalnie

Object diagram - Diagram obiektów

+

używany nieoficjalnie

Composite Structure diagram - Diagram
strukturalny

+

–

Component diagram - Diagram komponentów

+

+

Deployment diagram - Diagram wdrożenia

+

+

Activity diagram - Diagram akywności (czynności)

+

+

State Machine diagram - Diagram maszyny
stanowej

+

Statechart diagram

(diagram stanów)

Sequence diagram - Diagram przebiegu (sekwencji)

+

+

Communication diagram - Diagram komunikacji

+

Collaboration diagram

(diagram współpracy)

Timing diagram - Diagram przebiegów czasowych

+

–

Interaction Overview diagram - Diagram przeglądu
interakcji

+

–

Inżynieria Oprogramowania wykład 4 - UML

19

UML

Notacja symboli elementów

Inżynieria Oprogramowania wykład 4 - UML

20

UML – notacja elementów strukturalnych



Aktor:



spójny zbiór ról

odgrywanych przez zewnętrznych

użytkowników systemu w czasie ich interakcji z

analizowanym systemem;



interakcja aktora z systemem w zamkniętym

przedziale

czasowym

(niezbyt długim);



nazwa na bazie

rzeczownika

i opis jedno- lub dwuzdaniowy;



wyszukiwanie aktorów:

•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 systemu?
•Kto dostarcza informacje systemowi?
•Czy coś dzieje się automatycznie?

Inżynieria Oprogramowania wykład 4 - UML

21

UML – notacja elementów strukturalnych



Przypadek użycia:



odwzorowuje

wymagania użytkownika na

funkcjonalność

systemu - nie bierze się pod

uwagę struktury technicznej systemu, lecz
analizuje się zewnętrzne funkcje systemu;



opis zbioru

ciągów akcji i ich wariantów

wykonywanych przez system w celu

dostarczenia określonemu użytkownikowi

poprawnego wyniku zadziałania systemu;



scenariusz opisany w

3-9 krokach

;



ścieżki warunkowe przedstawiane

są jako „

rozszerzenia

”;

Nazwa przypadku

użycia

Inżynieria Oprogramowania wykład 4 - UML

22

UML – notacja elementów strukturalnych



Przypadek użycia:



opisuje

CO

system ma robić a nie

JAK

;

CO

JAK

CO

JAK

Inżynieria Oprogramowania wykład 4 - UML

23

UML – notacja elementów strukturalnych



Przypadek użycia – opis dodatkowy w dokumencie:



1.

Krótki opis



2.

Aktorzy



3.

Podstawowy przepływ zdarzeń



4.

Przepływy alternatywne

• 4.1<Obszar funkcjonalności>



4.1.1< Pierwszy przepływ alternatywny >



4.1.2< Drugi przepływ alternatywny >

• 4.2<Inny obszar funkcjonalności>



4.2.1< Inny przepływ alternatywny >



5.Podprzepływy

• 5.1< Pierwszy podprzepływ >
• 5.2< Drugi podprzepływ >



6.

Kluczowe scenariusze



7.

Warunki wstępne

• 7.1< Pierwszy warunek wejściowy >



8.

Warunki końcowe

• 8.1< Pierwszy warunek końcowy >



9.

Punkty rozszerzeń

• 9.1<Nazwa punktu rozszerzeń>



10. Specjalne wymagania

• 10.1< Pierwsze specjalne wymaganie >

Inżynieria Oprogramowania wykład 4 - UML

24

UML – notacja elementów strukturalnych



Klasa:



Klasa – opis zbioru obiektów posiadających

podobne atrybuty, operacje, metody, związki i

semantykę;



Interfejs – zdefiniowany zestaw operacji

oferowanych otoczeniu;



Atrybut – nazwana właściwość klasy, określająca

dziedzinę wartości dla poszczególnych

egzemplarzy;



Operacja – implementacja usługi dostarczanej

przez obiekt, manifestowana przez interfejs

obiektu, opatrzona sygnaturą z opisem

dopuszczalnych parametrów wej/wyj;

Inżynieria Oprogramowania wykład 4 - UML

25

UML – notacja elementów strukturalnych



Klasa – kilka porad:



klasa odpowiada pewnemu rzeczywistemu lub

koncepcyjnemu bytowi z analizowanego świata;



obejmuje dobrze określony, nieduży zbiór

zobowiązań;



zawiera tylko niezbędne atrybuty z punktu

widzenia celu systemu oraz wyróżnionych

odpowiedzialności;



jest prosta i zrozumiała, ale także rozszerzalna ;

Inżynieria Oprogramowania wykład 4 - UML

26

UML – notacja elementów czynnościowych



Interakcje:



odwzorowanie zachowania poprzez wymianę

wiadomości pomiędzy obiektami oraz rezultat tej

wymiany;



specyfikacja zdarzeń występujących w określonym

czasie i przestrzeni, dzielących kolejne stany;



Wiadomości (komunikaty):



wywołanie operacji w trybie synchronicznym lub

asynchronicznym, z opcjonalnym wynikiem operacji;



wysłanie sygnału (tryb asynchroniczny);



Stany:



opis zachowania pojedynczych obiektów;



odwzorowanie przepływu sterowania pomiędzy

aktywnościami (czynnościami) obiektu;

Inżynieria Oprogramowania wykład 4 - UML

27

UML – notacja elementów grupujących



Pakiet:



mechanizm organizowania elementów w

grupy;



zastosowanie

: modele systemów i

podsystemów;



Notka – element objaśniający:



element pomocniczy do przedstawiania

komentarzy, wyjaśnień, ograniczeń;



oznaczane są zagiętym rogiem;



mogą być zakotwiczane przy

elemencie przerywaną linią;



zastosowanie

: wprowadzanie

ograniczeń;

Notatka…

Pakiet

Inżynieria Oprogramowania wykład 4 - UML

28

UML

Notacja symboli związków

Inżynieria Oprogramowania wykład 4 - UML

29

UML – notacja związków



Związek zależności:



związek pomiędzy dwoma elementami polegający na

tym, że zmiana w jednym – niezależnym elemencie,

pociąga zmianę w drugim – zależnym elemencie;



(1) związek

uściślenia

– służy wyrażeniu relacji

pomiędzy elementami tworzonego modelu, m.in. w

fazie projektowania i implementacji oprogramowania

(wskazuje na pełniejszą specyfikację tego, co było

wyspecyfikowane ogólnie);



(2) związek

śladowalności

– wskazuje na powiązanie

elementów w projekcie, np. pewnej klasie wskazuje

inne klasy, które były posłużyły do jej definiowania;

Klasa 1

Klasa 2

zależność

Inżynieria Oprogramowania wykład 4 - UML

30

UML – notacja związków



Związek asocjacji:



reprezentuje

czasowe

powiązanie

pomiędzy

obiektami dwóch klas;



może zachodzić pomiędzy dwoma lub więcej

obiektami klas;



obiekty związane asocjacją są od siebie niezależne;



daje możliwością

nawigacji

pomiędzy elementami

asocjacji;



opisem związku może być:

•kwalifikator – atrybut klasy dla zapewnienia unikatowości

związku;

•rola - nazwa przypisana do jednej z dziedzin związku;

Klasa 1

Klasa 2

asocjacja

Rola 1

Rola 2

kwalifikator

Inżynieria Oprogramowania wykład 4 - UML

31

UML – notacja związków



Związek agregacji:



silniejszy

rodzaj

asocjacji

;



określa relację zawierania “

całość-część

” pomiędzy

agregatem (całością) a jego częściami;



w przypadku klas wartościami atrybutów obiektu

zagregowanego mogą być obiekty należące do klas

reprezentujących “części”;



przykład: Komputer jest złożony z Podzespołów;

Klasa

reprezentująca

„całość”

Klasa

reprezentująca

„część”

agregacja

Komputer

Podzespół

zbudowany z

Inżynieria Oprogramowania wykład 4 - UML

32

UML – notacja związków



Związek silnej agregacji - kompozycja:



silniejszy

rodzaj

agregacji

;



określa

relację

przynależności

elementów

składowych do elementu macierzystego wraz z

powiązaniem okresu życia elementów składowych z

ich elementem macierzystym;



elementy składowe mogą być kreowane po

utworzeniu elementu macierzystego a kasowane

wraz ze swoim element macierzystym lub wcześniej;



kompozycja może być rekursywna;

Klasa

reprezentująca

„całość”

Klasa

reprezentująca

„część”

silna agregacja

Inżynieria Oprogramowania wykład 4 - UML

33

UML – notacja związków



Związek uogólnienia (generalizacji),

dziedziczenie:



związek pomiędzy elementem

ogólnym

a

specjalizowanym

;



element specjalizowany jest w pełni zgodny z

elementem ogólnym;



egzemplarz elementu specjalizowanego może być

użyty w miejsce egzemplarza elementu ogólnego;



związek generalizacji jest głównie wykorzystywany

na etapie tworzenia modelu, pozwalając na

usystematyzowanie tworzenia modelu oraz na

wykorzystywanie wcześniej zbudowanych modeli;

Klasa

specjalizowana

Klasa

ogólna

generalizacja

Inżynieria Oprogramowania wykład 4 - UML

34

UML – notacja związków



Związek dziedziczenia klas:



w przypadku klas związek generalizacji określa

powiązanie pomiędzy klasą ogólną i klasą

specjalizowaną;



obiekty klasy specjalizowanej dziedziczą własności

strukturalne i behawioralne – atrybuty i operacje –

obiektów klasy ogólnej;



podklasa może:

•dodawać dodatkowe atrybuty, operacje i związki,
•redefiniować dziedziczone operacje (używać z rozwagą!);



wspólne atrybuty, operacje i/lub związki są

reprezentowane na najwyższym poziomie odniesienia w

hierarchii;



polimorfizm jest realizowany na bazie dziedziczenia -

wykorzystuje informacje dodatkowe zapisywane przy

instancjach obiektów klas dziedziczących;

Inżynieria Oprogramowania wykład 4 - UML

35

UML – notacja związków



Przykład:

POJAZD

+Waga
+Nr.rej.

<>Rejestruj( )

OSOBOWY

+Wielkość

CIĘŻAROWY

+Tonaż

<>DajPodatek( )

OSOBA

+Imie
+Nazwisko
+Pesel

PRZYCZEPA

+Liczba osi

SILNIK

+Pojemność

Klasa

abstrakcyjna

1..* 1

Widoczność
:
- private
# protected
+ public

Krotność

związku

Inżynieria Oprogramowania wykład 4 - UML

36

UML – notacja związków



Związek generalizacji przypadków użycia:



dla przypadków użycia związek generalizacji określa,

że:

•Przypadek ogólny zawiera część zachowania powielaną w

przypadku specjalizowanym;

•Przypadek specjalizowany może dołożyć nowe lub

zmodyfikować zachowanie przypadku ogólnego (np. nowe

sekwencje zdarzeń);

Instancja przypadku użycia

Ogólny przypadek użycia

Specjalizowany przypadek użycia

Inżynieria Oprogramowania wykład 4 - UML

37

UML – notacja związków



Związek realizacji:



związkiem pomiędzy dwoma elementami

(klasyfikatorami), z których jeden jest deklaracją a

drugi zapewnia praktyczną realizację deklaracji;



realizacja występuje np. pomiędzy interfejsem a jego

implementacją, czy też przypadkami użycia a

elementami je realizującymi;

Klasa realizująca

Realizuje

Deklaracja

przypadku użycia

Inżynieria Oprogramowania wykład 4 - UML

38

UML – notacja związków



Krotność związku - liczba wystąpień danej

klasy, która jest powiązana z jednym

wystąpieniem innej klasy (określana dla

każdego końca związku);

Nieokreślony
Dokładnie jeden
Zero lub więcej

Jeden lub więcej
Zero lub jeden

Określony zakres
Wiele, rozłączne zakresy

Inżynieria Oprogramowania wykład 4 - UML

39

UML – notacja związków



Notacja związku – kilka porad:



zależności wystąpią tam, gdzie klasa występuje jako

parametr operacji;



uogólnienie warto stosować, gdy kilka klas ma

wspólne atrybuty lub metody;



jeżeli klasa stanowi całość w odniesieniu do pewnego

zbioru klas, to stosuje się agregację;



agregacja może zastąpić wielodziedziczenie;



należy ograniczać cykliczne związki;

Inżynieria Oprogramowania wykład 4 - UML

40

UML

Notacja diagramów

Inżynieria Oprogramowania wykład 4 - UML

41

UML – notacja diagramów



Diagram przypadków użycia:



stosowany do opisu statycznej struktury usług systemu;



definiuje granice systemu, określa jego kontekst;



pokazuje system z zewnątrz poprzez użytkowników i

funkcje im udostępniane;



elementami diagramu są:

•przypadki użycia:



reprezentują zamkniętą i kompletną funkcjonalność dostępną z

zewnątrz systemu;



są inicjowane z zewnątrz i dostarczają wyniki na zewnątrz;

•aktorzy:



reprezentuje punkt widzenia na system;



inicjuje wykonanie funkcji systemu;



jest odbiorcą wyników działania systemu;

Inżynieria Oprogramowania wykład 4 - UML

42

UML – notacja diagramów



Diagram przypadków użycia:



związki składowe:

•Generalizacja (

uogólnienie

)



przypadek użycia jest uogólnieniem innego;

•Włączanie (

include

) – stereotyp związku:



Zachowanie włączanego przypadku użycia wchodzi

w podstawowy przypadek użycia;



Włączany przypadek użycia

musi być

wykonany, jeżeli jest w

przepływie

podstawowym

;



Może się zdarzyć, że przypadek bazowy

nie osiągnie

miejsca

uruchomienia

z przepływu

alternatywnego

;

•Rozszerzenie (

extend

) – stereotyp związku:



Zachowanie rozszerzającego przypadku użycia jest

włączane do podstawowego przypadku użycia

w ściśle określonym miejscu (tzw. extension point);



Rozszerzający przypadek użycia

może, lecz nie musi

być wykonany;

<<

include

>>

<<

extend

>>

Inżynieria Oprogramowania wykład 4 - UML

43

UML – notacja diagramów



Diagram przypadków użycia:



związki składowe- włączanie (include):

Instancja UC

Instancja UC #1

Instancja UC #2

Włączany UC

Włączany UC

Podstawowy UC

Podstawowy UC

Inżynieria Oprogramowania wykład 4 - UML

44

UML – notacja diagramów



Diagram przypadków użycia:



związki składowe- rozszerzenie (extend) :

Podstawowy UC

Podstawowy UC

Instancja UC

Instancja UC

Rozszerzający UC

Rozszerzający UC

Pkt Rozszerzenia

Pkt Rozszerzenia 1

Pkt Rozszerzenia 2

Inżynieria Oprogramowania wykład 4 - UML

45

UML – notacja diagramów



Diagram przypadków użycia:

Przypadek 1

Przypadek 2

Przypadek 3

Przypadek 4

„extend”

„include”

generalizacja

generalizacja

asocjacja

Protokół komunikacji pomiędzy
użytkownikiem a usługą

„include” oraz „extend” są standardowymi stereotypami uszczegóławiającymi
związek

Inżynieria Oprogramowania wykład 4 - UML

46

UML – notacja diagramów



Diagram przypadków użycia - przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

47

UML – notacja diagramów



Diagram klas:



zastosowanie: opis struktury systemu;



elementy: klasy, interfejsy, grupy współdziałania;



związki: zależności, generalizacji, asocjacji,

agregacji;



najczęściej używany diagram UML;

Klasa 2

Klasa 1

Klasa 3

Klasa 5

Klasa 4

asocjacja 1

asocjacja 2

generalizacja

zależność

asocjacja 3

asocjacja 4

Klasa 6

agregacja

Inżynieria Oprogramowania wykład 4 - UML

48

UML – notacja diagramów



Diagram klas - przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

49

UML – notacja diagramów



Diagram pakietów (cel: porządkowanie

struktury) - przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

50

UML – notacja diagramów



Diagram struktury złożonej (composite

structures):



wprowadzony od UML 2.0;



podobny do diagramu klas, lecz związki nie wynikają

ze statycznego powiązania, lecz realizowanego

zadania;



modeluje współpracę klas, interfejsów,

komponentów zaangażowanych w jednym zadaniu;



Przykład – faktura składa się z części,

które nie są oddzielnymi klasami

Inżynieria Oprogramowania wykład 4 - UML

51

UML – notacja diagramów



Diagram struktury złożonej (composite

structures);



Przykład: realizacja przypadku użycia przez „grupę

współdziałania”

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

52

UML – notacja diagramów



Diagram sekwencji

(przebiegu):



prezentuje chronologiczną

sekwencję interakcji obiektów;



odwzorowuje dynamikę

obiektów uczestniczących w

interakcjach oraz kolejność

wymienianych komunikatów;



nie przedstawia związków

pomiędzy obiektami;



może opisywać wszystkie

możliwe scenariusze lub tylko

jeden wybrany;

K o m u n i k a t :

[ w a r u n e k ]
n a z w a k o m u n ik a t u

Inżynieria Oprogramowania wykład 4 - UML

53

UML – notacja diagramów



Diagram sekwencji:

Ob1: TOb

Ob2:

:TOb

„Create”

a

Zdarzenia

b

d

e

f

{500 ms}

{d - c < 2 s}

Ograniczenie
czasowe

Rozgłaszanie
komunikatów

Komunikacja
pomiędzy dwoma
obiektami

{f - e < 3 s}

C

za

s

g

h

{AVE(h - e) < 5 s}

Komunikat 2

Komunikat 4

Utworzenie
obiektu

Skasowanie

obiektu

Wywołanie
operacji

Zwrot wyniku
operacji

Asynchroniczny
sygnał w UML
1.4

c

Pętla
wewnętrzn
a

Asynchroniczny
sygnał w UML
2.0

Inżynieria Oprogramowania wykład 4 - UML

54

UML – notacja diagramów



Diagram sekwencji – przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

55

UML – notacja diagramów



Diagram komunikacji (współpracy w 1.4):



odwzorowuje interakcje pomiędzy powiązanymi

obiektami (lub komponentami);



diagramy interakcji - sekwencji i diagramy

współdziałania - przedstawiają podobne informacje,

lecz diagram współdziałania przedstawia dodatkowe

związki pomiędzy obiektami;

Obiekt 1

Obiekt 2

Nazwa

Nazwa: klasa

1: DoIt

2: DoItAgain(p,r):=retValue

3: DoItAgain

p

retValue

Inżynieria Oprogramowania wykład 4 - UML

56

UML – notacja diagramów



Diagram komunikacji (współpracy w 1.4) –

przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

57

UML – notacja diagramów



Diagram stanów:



opisuje stany z życia obiektu,

jako reakcje na zewnętrzne

zdarzenia i komunikaty;



akcja - elementarna

(niepodzielna) czynność, np.

wywołanie operacji,

utworzenie lub skasowanie

obiektu, obliczenie wartości

wyrażenia;



aktywność - nieelementarna

czynność;



elementami są: stany,

tranzycje, zdarzenia,

aktywności, łączniki

pomiędzy stanami;

Stan 1

Stan 2

Tranzycja określająca
stan początkowy

Nazwa-zdarzenia (parametry) [dozór]
/ lista-akcji ^ lista-zdarzeń

Pseudostan końcowy

Pseudostan początkowy

Tranzycja określająca
stan końcowy

Inżynieria Oprogramowania wykład 4 - UML

58

UML – notacja diagramów



Diagram stanów:

A

A1

A2

B
entry: akcja-1( )
exit: akcja-2( )
do: aktywność-1,
aktywność -2

C

C1

C2

C3

H

event-1( )

[dozór 2]

[dozór 1]

event-2 ( ) / action-3 ^ event-3

Time-out (interval)

H - łącznik historyczny

Łącznik wyboru

Zdarzenie przeterminowania

Inżynieria Oprogramowania wykład 4 - UML

59

UML – notacja diagramów



Diagram stanów – przykład:

http://www.e-informatyka.edu.pl

Inżynieria Oprogramowania wykład 4 - UML

60

UML – notacja diagramów



Diagram stanów – przykład:

Inżynieria Oprogramowania wykład 4 - UML

61

UML – notacja diagramów



Diagram czynności:



Uogólniona wersja diagramu stanów;



Obrazuje przepływ sterowania od czynności do

czynności;



Czynności odpowiadają stanom wyróżnialnym w trakcie

przetwarzania, a nie stanom obiektów;



Czynność może być interpretowana jako:

•zadanie do wykonania przez człowieka lub komputer,
•odpowiedzialność/operacja/metoda klasy;



Składowe:

•stany akcji,
•stany czynności,
•przejścia,
•obiekty;

Inżynieria Oprogramowania wykład 4 - UML

62

UML – notacja diagramów



Diagram czynności - przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

63

UML – notacja diagramów



Diagram komponentów:



Obrazuje fizyczne i statyczne aspekty systemu;



Przedstawia uporządkowanie komponentów i

zależności między nimi;



Przykłady komponentów:

•programy wykonywalne, biblioteki, tabele, pliki, dokumenty,

bazy danych itp.



Ściśle związany z diagramem klas, ponieważ

zazwyczaj każdemu komponentowi

przyporządkowane są pewne klasy, interfejsy i

kooperacje;



Składowe:

•komponenty,
•interfejsy,
•związki: zależności, uogólnienia, powiązania, realizacje;

Inżynieria Oprogramowania wykład 4 - UML

64

UML – notacja diagramów



Diagram komponentów – przykład:

www.erudis.pl

Interfejs
„wymagany”

Interfejs
„udostępnian
y”

notacja
UML 2.0

Inżynieria Oprogramowania wykład 4 - UML

65

UML – notacja diagramów



Diagram wdrożenia:



Obrazują konfigurację sprzętową (węzły) z

uwzględnieniem rozmieszczenia (rozproszenia)

komponentów;



Węzły dzielimy na:

•Procesory – reprezentują zasoby obliczeniowe:



Posiadają pewną ilość pamięci i zdolność przetwarzania,



Mogą wykonywać kod komponentu;

•Urządzenia – są interfejsem do świata zewnętrznego:



Nie mają zdolności przetwarzania (np. monitor, drukarka);



Wiąże się z diagramem komponentów, ponieważ zwykle

każdy węzeł zawiera co najmniej jeden komponent;



Składowe:

•węzły,
•zależności,
•powiązania;

Inżynieria Oprogramowania wykład 4 - UML

66

UML – notacja diagramów



Diagram wdrożenia – przykład:

www.erudis.pl

Inżynieria Oprogramowania wykład 4 - UML

67

UML

Przykład „CD”

Inżynieria Oprogramowania wykład 4 - UML

68

UML – notacja diagramów



Diagram przypadków użycia - przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Inżynieria Oprogramowania wykład 4 - UML

69

UML – notacja diagramów



Diagram przypadków użycia - przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

System wspomaga obsługę sprzedaży CD
poprzez:

-This system lets the band manager view a
sales statistics report and the Billboard 200
report for the band's CDs.

-It also lets the record manager view a sales
statistics report and the Billboard 200 report
for a particular CD.

-The system delivers Billboard reports from an
external system called Billboard Reporting
Service.

System nie realizuje (nie ma tych „use cases”):

-It does not provide a way for a band
manager to listen to songs from the different
albums on the Billboard 200

Inżynieria Oprogramowania wykład 4 - UML

70

UML – notacja diagramów



Diagram klas - przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Wydzielone klasy odpowiadają:

-rzeczom, o których mówi się w
‘branży’: rock bands, CDs, radio play;

-bytom potrzebnym programistom;

‘CD’ nie wie nic o
‘CDSalesReport’

Inżynieria Oprogramowania wykład 4 - UML

71

UML – notacja diagramów



Diagram sekwencji – przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

‘generateCDSalesRep
ort’ musi być
realizowane przez
obiekty klasy
‘ReportGenerator’

‘date’ jest zmienną
przesyłaną do usługi
‘’setCreatedOn’ w
obiekcie
‘aCDReporter’

Inżynieria Oprogramowania wykład 4 - UML

72

UML – notacja diagramów



Diagram sekwencji – przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Przebieg:

-aServlet sends a message to the ReportGenerator
class instance named gen. The message is labeled
generateCDSalesReport;

-When gen instance receives a
generateCDSalesReport message, it then makes
subsequent calls to the CDSalesReport class, and
an actual instance of a CDSalesReport called
aCDReport gets returned.

-The gen instance then makes calls to the returned
aCDReport instance, passing it parameters on
each message call.

-At the end of the sequence, the gen instance
returns aCDReport to its caller aServlet.

Inżynieria Oprogramowania wykład 4 - UML

73

UML – notacja diagramów



Diagram stanów –

przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Inżynieria Oprogramowania wykład 4 - UML

74

UML – notacja diagramów



Diagram stanów –

przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Zmiany stanów:

-Loan processing begins in the Loan Application
state.

-When the pre-approval process is done,
depending on the outcome, you move to either the
Loan Pre-approved state or the Loan Rejected
state. This decision, which is made during the
transition process, is shown with a decision point --
the empty circle in the transition line.

-A person can tell that a loan cannot go from the
Loan Pre-Approved state to the Loan in
Maintenance state without going through the Loan
Closing state.

-Also a person can tell that all loans will end in
either the Loan Rejected state or the Loan in
Maintenance state.

Inżynieria Oprogramowania wykład 4 - UML

75

UML – notacja diagramów



Diagram czynności - przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Inżynieria Oprogramowania wykład 4 - UML

76

UML – notacja diagramów



Diagram komponentów – przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Inżynieria Oprogramowania wykład 4 - UML

77

UML – notacja diagramów



Diagram wdrożenia – przykład:

http://www-128.ibm.com/developerworks/rational/library/769.html

Inżynieria Oprogramowania wykład 4 - UML

78

UML

Przykład „studencki”

Inżynieria Oprogramowania wykład 4 - UML

79

UML – przykład systemu ewidencji

studentów



Diagram przypadków użycia

Student

Profesor

Wprowadzenie

studenta

Pobranie obciążenia

System

księgowania

Inżynieria Oprogramowania wykład 4 - UML

80

UML – przykład systemu ewidencji

studentów



Diagram klas (1) – klasy abstrakcyjne

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

Inżynieria Oprogramowania wykład 4 - UML

81

UML – przykład systemu ewidencji

studentów



Diagram klas (2) – klasy uszczegółowione

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nazwisko
nr indeksu

nazwisko
specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

Inżynieria Oprogramowania wykład 4 - UML

82

UML – przykład systemu ewidencji

studentów



Diagram klas (3) – związki klas

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nazwisko
…

nazwisko
specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

1

0..*

0..*

1

1

1..*

4

3..10

0..4

1

Inżynieria Oprogramowania wykład 4 - UML

83

UML – przykład systemu ewidencji

studentów



Diagram klas (4) – skierowanie i krotności

związków

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nazwisko
nr indeksu

nazwisko
specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

1

0..*

0..*

1

1

1..*

4

3..10

0..4

1

Inżynieria Oprogramowania wykład 4 - UML

84

UML – przykład systemu ewidencji

studentów



Diagram klas (5) – generalizacja

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nr indeksu

specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

1

0..*

0..*

1

1

1..*

4

3..10

0..4

1

nazwisko

Osoba

Inżynieria Oprogramowania wykład 4 - UML

85

UML – przykład systemu ewidencji

studentów



Diagram sekwencji zdarzeń

: Student

arkusz

rejestracji

kierownik

ewidencji

Kurs 1

1: wprowadzenie danych

2: zatwierdzenie

3: dodanie osoby(Nowak, Kurs 1)

4: Czy otwarty?

5: Czy otwarty?

6: Dodaj(Nowak)

7: Dodaj(Nowak)

Kurs 1

Grupa 1

Inżynieria Oprogramowania wykład 4 - UML

86

UML – przykład systemu ewidencji

studentów



Diagram współpracy

: Rejestrujący

arkusz kursu :

ArkuszKursu

Kierownik :

KierownikProgramowy

kurs :

Kurs

1: określ opis kursu

2: przetwarzaj

3: dodaj kurs

4: nowy kurs

Inżynieria Oprogramowania wykład 4 - UML

87

UML – przykład systemu ewidencji

studentów



Diagram stanów

Inicjalizacja

Otwieranie

entry: Zarejestruj studenta

exit: Zwiększ licznik

Zamknięcie

Anulowanie

do: Inicjalizuj kurs

do: Zamknij kurs

do: Powiadom studenta

Dodaj Studenta /

Licznik = 0

Dodaj Studenta[ licznik < 10 ]

[ Licznik = 10 ]

Anuluj

Anuluj

Anuluj