Projektowanie

systemów

informatycznych

Diagramy UML

GK (PSI(4) - 2009)

2

Wstęp

UML

(Unified Modeling Language) jest formalnym

językiem służącym do opisu obiektów świata rzeczywistego w
analizie obiektowej (Object-oriented analysis) oraz
programowaniu obiektowym (Object-oriented programming).

UML jest językiem modelowania wizualnego,

pozwalającym twórcom systemów na konstruowanie projektów, na
których ich wizje zostają uchwycone i wyrażone w standardowy,
łatwy do zrozumienia sposób. Dostarcza też mechanizmów
ułatwiających wymianę informacji i przekazywanie projektów
innym.
Właściwości UML:



UML jest standardowym językiem do specyfikacji, wizualizacji,

budowy i dokumentowania wszystkich wytworów (artefaktów)
dowolnego systemu,



UML jest językiem o szerokim zakresie zastosowań,



UML nadaje się do opisu systemów programowych i

nieprogramowych (tzw. systemów biznesowych) w różnych
dziedzinach i branżach, np. w produkcji, bankowości, handlu
elektronicznym itd.,



UML może być stosowany w całym procesie tworzenia systemu

informatycznego, od gromadzenia wymagań, aż po implementację
systemu,



UML nie jest to zastrzeżonym i zamkniętym językiem

modelowania.

GK (PSI(4) - 2009)

3

Wstęp

Rozwój UML:



lata 80-90: różnorodne metodologie, techniki , różnorodne

notacje, symbole, oznaczenia,



lata 90-95: wyróżniają się 3 główne metody:

•

Grady’ego Boocha (Booch ’93) kładzie nacisk na
projektowanie i tworzenie systemów oprogramowania.
Niewielka przydatność dla analizy,

•

Jamesa Rumbaugha (OMT-2 - Object Modeling Technique)
kładzie nacisk na analizę systemów informatycznych.
Niewielka przydatność dla projektowania,

•

Ivara Jacobsona (OODE - Object-Oriented Software
Engineering) kładzie nacisk na modelowanie biznesowe i
analizę wymagań,



lata 95-97:

•

Powstał język UML 1.0 w firmie Rational Software

Corporation jako wynik współpracy James’a Rumbaugh,

Ivar’a Jacobson’a i Grady’ego Boocha,



po roku 97:

•

standaryzacja, korekty i prace nad wersją 2.0

GK (PSI(4) - 2009)

4

Wstęp

Cele UML:



wyposażenie użytkowników i analityków w graficzny

język modelowania,



dostarczenie mechanizmów rozszerzania i

specjalizacji (do koncepcji bazowej):

• budowanie modeli dla standardowych aplikacji,

• dodawanie nowych pojęć i notacji do koncepcji

podstawowej,

• wybór pomiędzy różnymi wariantami.



wspomaganie specyfikacji niezależnych od języka

programowania i metod tworzenia,



wspomaganie koncepcji: wzorców, komponentów,

współpracy, programów ramowych.

UML jest

językiem modelowania a

nie metodą projektowania
systemów informatycznych

5

Bibliografia:

1. Booch G., Raumbaugh J., Jacobson I.,

UML: Przewodnik

użytkownika

, WNT, Warszawa 2001.

2. Cheesman J., Daniels J.,

Komponenty w UML

, WNT, Warszawa 2004.

3. Booch G., Raumbaugh J., Jacobson I., UML:

Przewodnik

użytkownika

, WNT, Warszawa 2001.

4. Flower M., Scott K.,

UML w kropelce

, Wydawnictwo LT&P, Warszawa

2002.

5. Wrycza S., Marcinkowski B., Wyrzykowski K.,

Język UML 2.0 w

modelowaniu systemów informatycznych

, Helion, Gliwice 2005.

6. Śmiałek M.,

Zrozumieć UML. Metody modelowania obiektowego

,

Helion, Gliwice 2005.

7. Wrycza S. (red.),

Ćwiczenia UML 2.1

, Helion 2006.

8. Maksimchuk R.A., Nalburg E.J.,

UML dla zwykłych śmiertelników

,

PWN SA, Warszawa 2007.

9. Dąbrowski W., Stasiak A., Wolski M,

Modelowanie systemów

informatycznych w języku UML 2.1 w praktyce

, PWN SA, Warszawa

2009.

10.Schmuller J.,

UML dla każdego

, Helion, Gliwice 2003.

11.Graessle P., Baumann H., Baumann P.,

UML 2.0 w akcji.

Przewodnik oparty na projektach

, Helion, Gliwice 2005.

Wstęp

GK (PSI(4) - 2009)

Wstęp

W praktycznej realizacji UML przyjmuje postać graficznej

prezentacji projektowanego systemu za pomocą logicznie

powiązanych

diagramów

. Diagramy opisują projektowany system

z różnych punktów widzenia.

W UML są tworzone następujące diagramy:

6

GK (PSI(4) - 2009)

1. Diagramy struktury

• Klas

• Obiektów

• Pakietów

• Przypadków użycia

• Struktur złożonych

• Wdrożeniowe

• Komponentów

2. Diagramy dynamiki

• Czynności

• Maszyny stanowej

• Zależności czasowych

• Interakcji:

o

Sekwencji

o

Komunikacji

o

Sterowania

interakcją

Projektując system informatyczny, rozpoczyna się

przeważnie od tworzenia diagramów w następującej kolejności:

Przypadków użycia

,

Klas

,

Czynności

i

Sekwencji

. Są to

wykorzystywane najczęściej. Pozostałe z nich bywają pomijane,
zwłaszcza przy tworzeniu niedużych systemów informatycznych.

Wstęp

7

GK (PSI(4) - 2009)

Lp.

Diagram

Opis

1

Diagram klas (Class
Diagram)

Graficzne przedstawienie statycznych,
deklaratywnych elementów dziedziny
przedmiotowej oraz związków między nimi

2

Diagram obiektów
(Object Diagram)

Wystąpienie (realizacja, instancja) diagramu
klas, odwzorowujące strukturę systemu w
wybranym momencie jego funkcjonowania

3

Diagram pakietów
(Package Diagram)

Graficzne przedstawienie logicznej struktury
systemu w postaci pakietów połączonych
zależnościami i zagnieżdżeniami

4

Diagram struktur
złożonych
(Composite
Structure Diagram)

Graficzne przedstawienie współdziałających ze
sobą elementów w celu osiągnięcia wymaganej
wspólnej funkcjonalności

5

Diagram
komponentów
(Component
Diagram)

Rodzaj diagramu wdrożeniowego, który
odwzorowuje organizację i zależności między
komponentami

6

Diagram
rozlokowania
(Deployment
Diagram)

Rodzaj diagramu wdrożeniowego, który
przedstawia sieć połączonych ścieżkami
komunikowania węzłów z ulokowanymi w nich
artefaktami

7

Diagram
przypadków użycia
(Use Case Diagram)

Graficzne przedstawienie przypadków użycia i
aktorów oraz związków między nimi
występujących w dziedzinie przedmiotowej

8

Diagram czynności
(Activity Diagram)

Graficzne przedstawienie sekwencyjnych i
współbieżnych przepływów sterowania oraz
danych pomiędzy uporządkowanymi ciągami
czynności, akcji i obiektów

9

Diagram maszyny
stanowej (State
Machine Diagram)

Graficzne odzwierciedlenie skokowego
zachowania skończonych systemów stan-
przejście

10

Diagram sekwencji
(Sequence Diagram)

Rodzaj diagramu interakcji, opisujący interakcje
pomiędzy instancjami klasyfikatorów systemu w
postaci sekwencji komunikatów wymienianych
między nimi

11

Diagram
komunikacji
(Communication
Diagram)

Rodzaj diagramu interakcji, opisujący
strukturalne związki pomiędzy instancjami
klasyfikatorów, biorącymi udział w interakcji oraz
wymianę komunikatów między nimi

12

Diagram zależności
czasowych (Timing
Diagram)

Rodzaj diagramu interakcji, reprezentujący na
osi czasu dopuszczalne zmiany stanów, które
może przyjmować instancja klasyfikatora
uczestnicząca w interakcji

13

Diagram sterowania
interakcją
(Interaction
Overview Diagram)

Diagram dokumentujący przepływ sterowania
pomiędzy logicznie powiązanymi diagramami i
fragmentami interakcji z wykorzystaniem
kategorii modelowania diagramów czynności

Pełna lista
diagramów
UML:

GK (PSI(4) - 2009)

8

Modelowanie złożonych systemów jest zadaniem trudnym i

angażuje wiele osób o różnym sposobie postrzegania systemu.
Uwzględniający te różne punkty widzenia, UML jest często
określany jako język modelowania posiadający 4+1 perspektyw.
Cztery pierwsze opisują wewnętrzną strukturę systemu na różnych
poziomach abstrakcji i szczegółowości. Ostatnia perspektywa (+1)
opisuje funkcjonalność systemu widzianą przez jego
użytkowników.
Są to następujące perspektywy:

Perspektywa przypadków użycia

– opisuje funkcjonalność,

oczekiwanej od systemu przez przyszłych użytkowników (mówi

co

powinien robić system),

Perspektywa logiczna

– zawiera opis sposobu realizacji

funkcjonalności, strukturę systemu widzianą przez projektanta
(opisie

jak

funkcjonalność systemu ma być realizowana),

Perspektywa implementacyjna

– opisuje szczegółowo

poszczególne moduły i ich interfejsy wraz z zależnościami, z
określeniem ograniczeń wynikających z zastosowanego języka
programowania, wybranych technologii etc., jest sposobem
widzenia systemu przez programistę,

Wstęp

GK (PSI(4) - 2009)

9

 Perspektywa procesowa

– zawiera podział systemu na

procesy (czynności) i procesory (jednostki wykonawcze),
opisuje właściwości niefunkcjonalne systemu i służy
programistom i integratorom,

 Perspektywa wdrożenia

– definiuje fizyczny podział

elementów systemu i sposób ich rozmieszczenia w
infrastrukturze, perspektywa taka służy integratorom i
instalatorom systemu.

Każda perspektywa korzysta z własnego

zestawu diagramów pozwalających czytelnie
przedstawić modelowane zagadnienie.

Wstęp

Diagram

Przypadków użycia

10

GK (PSI(4) - 2009)

Diagram Przypadków użycia

(User Case Diagram –

UCD), narzędzie stosowane w

perspektywie przypadków

użycia

,

odwzorowuje funkcjonalności tworzonego systemu

wraz z jego otoczeniem poprzez graficzną prezentację:



własności

tworzonego systemu informatycznego,

postrzeganych i wymaganych przez

użytkownika

tego

systemu,



usług

oferowanych przez tworzony system informatyczny,

postrzeganych przez

otoczenie

tego systemu.

Diagram UCD jest tworzony przed rozpoczęciem prac

projektowych nad systemem informatycznym i odgrywa

najważniejszą rolę w procesie tworzenia tego systemu, gdyż

pozwala na identyfikację oczekiwanych funkcjonalności

systemu, weryfikację postępów w dalszym modelowaniu,

projektowaniu i implementacji tego systemu oraz zapewnia

komunikatywność kontaktów między zespołem projektantów,

a użytkownikiem systemu.

W procesie tworzenia przypadków użycia

najistotniejsze jest to, że opisują,

co robi system z punktu

widzenia zewnętrznego obserwatora

, a

nie jak to robi

, co

oznacza, iż przypadki użycia, oprócz funkcjonalności, nie
definiują jednocześnie sposobu ich implementacji. Określają
one zatem wymagane zachowanie, ale nie narzucają sposobu
jego rozwiązania, a więc dzięki nim użytkownicy i eksperci w
dziedzinie problemu mogą rozmawiać z projektantami i
programistami bez konieczności analizowania nieistotnych
szczegółów.

Diagram

Przypadków użycia

11

GK (PSI(4) - 2009)

Własności przypadków użycia. Przypadki użycia:



określają zbiory ciągów akcji, z których każdy reprezentuje

interakcję elementów z otoczenia systemu z funkcjami
samego systemu, których na etapie identyfikacji wymagań i
analizy używa się do obrazowania, specyfikowania, tworzenia i
dokumentowania spodziewanego zachowania systemu,



reprezentują wymagania funkcjonalne dla systemu jako

całości,



obejmują interakcje aktorów i systemu, przy czym aktor

(człowiek, system itp.) reprezentuje spójny zbiór ról
odgrywanych przez użytkowników przypadku użycia w czasie
jego realizacji,



mogą mieć warianty, które są uszczegółowionymi wersjami

innych przypadków użycia, są częściami innych przypadków
użycia lub rozszerzają znaczenie innych podstawowych
przypadków użycia



mają za zadanie dostarczyć istotne wyniki,



służą do analizy całego systemu, ale można je również

stosować do analizy części systemu (np. podsystemów), a
nawet pojedynczych jego elementów,



są podstawą do opracowania testów dla modelowanych

funkcjonalności systemu.

Diagram

Przypadków użycia

notacja i semantyka

12

GK (PSI(4) - 2009)

Przypadek użycia

(User Case). Przypadek użycia reprezentuje

z

espół czynności realizowanych przez system w celu

wytworzenia określonego wyniku, mającego znaczenie dla

aktora (użytkownika). Zatem:



przypadek użycia reprezentuje sekwencję, inicjowanych

przez aktora, niezbyt odległych w czasie operacji
wykonywanych przez system,



przypadek użycia modeluje oczekiwanie zachowanie systemu

wobec danego aktora, nie precyzując sposobu realizacji tego
zachowania,



uruchomienie danego przypadku użycia ma dostarczyć

aktorowi wymiernych wyników,



przypadek użycia zwykle opisuje pewien proces a nie

elementarną czynność (działanie),



przypadek użycia jest całością zadania widzianego z punktu

widzenia

aktora

.

Graficzna symbol przypadku użycia:

Wystawienie faktury

Diagram

Przypadków użycia

notacja i semantyka

13

GK (PSI(4) - 2009)

Każdy przypadek użycia może być opisany za pomocą:

•nazwy,

•przepływu zdarzeń (scenariuszy),

•zależności i relacji,

• listy działań charakteryzujących przypadek użycia (przebieg

zdarzeń)

,

•wymagań specjalnych,

•warunków wstępnych i/lub końcowych.
W zależności od potrzeb przypadek użycia może być
zaopatrzony w dodatkowy opis szczegółowy.

Nazwa

przypadku użycia może być tekstem

zawierającym dowolną liczbę liter, cyfr i znaków
przestankowych (z wyjątkiem dwukropka oddzielającego
nazwę przypadku użycia od nazwy jego pakietu), zapisanym w
wielu wierszach. W praktyce nazwę podaje się w formie
krótkiego wyrażenia z czasownikiem w formie bezosobowej
(najczęściej) na początku, określającego pewną czynność
pochodzącą ze słownictwa modelowanego systemu, np.:

Diagram

Przypadków użycia

notacja i semantyka

14

GK (PSI(4) - 2009)

Aktor

(Actor). Aktor to d

owolny byt będący w interakcji z

przypadkiem użycia (systemem), np. człowiek, inny program,

sprzęt elektroniczny, składnica danych, sieć komputerowa, firma,

jednostka organizacyjna.

Aktor reprezentuje spójny zbiór ról

odgrywanych przez użytkowników przypadku użycia w czasie

interakcji z tym przypadkiem. Aktorzy nie są elementami

tworzonego systemu informatycznego. Istnieją poza systemem.

Zatem:



aktorami mogą być ludzie, urządzenia, inne systemy

informatyczne,



pojęcia aktora odpowiada roli jaką on odgrywa w stosunku do

systemu,



pojęcia aktora nie odpowiada zawsze np. konkretnej osobie

fizycznej, bo ta może wcielać się w różne role (np. raz jako

administrator, a raz jako zwykły użytkownik),



jeden aktor może reprezentować całą grupę fizycznych

użytkowników systemu (aktor pracownik reprezentuje wszystkich

pracowników firmy),



aktorzy są zwykle aktywni - inicjują przypadki użycia, choć mogą

być również pasywni (np. aktor tylko korzystający z danych

przetworzonych w systemie).

Klient

Graficzny symbol aktora:

Diagram

Przypadków użycia

notacja i semantyka

15

GK (PSI(4) - 2009)

Nazwa

aktora jest to zwykle rzeczownik lub określenie

rzeczownikowe w liczbie pojedynczej. Nazwa aktora nie ma
identyfikować poszczególnych, realnie istniejących obiektów, ale
role, które pełnią.
W procesie ustalania aktorów należy kierować się następującymi
przesłankami:



jaka grupa użytkowników (w tym także systemów, aplikacji itp.)

potrzebuje wspomagania swojej działalności przez tworzony
system,



jacy użytkownicy i w jakim zakresie są niezbędni do

prawidłowego funkcjonowania tworzonego systemu (użytkownicy
merytoryczni i użytkownicy wspomagający),



w jakie środki komunikacji z tworzonym systemem będą

wyposażeni użytkownicy
i jakie techniki komunikacji z systemem będą przez nich
stosowane.

Każdy aktor musi użytkować co najmniej jeden przypadek

użycia (musi być z nim połączony na diagramie), natomiast
przypadek użycia musi być użytkowany przez co najmniej jednego
aktora (musi być z nim połączony na diagramie). Takie połączenie
aktora z przypadkiem użycia oraz połączenia między przypadkami
użycia noszą nazwę związków.

Diagram

Przypadków użycia

notacja i semantyka

16

GK (PSI(4) - 2009)

Związek

(Relationship). Związek oznacza interakcję aktora z

przypadkami użycia, która może oznaczać ich inicjowanie
(uruchamianie), dostarczanie im danych, otrzymywanie od nich
danych przetworzonych lub inne użytkowanie funkcjonalności
realizowanej przez ten przypadek użycia. Związek nie oznacza
żadnych konkretnych rozwiązań, np. nie wskazuje na to, jakie
dane są przekazywane od aktora do przypadku użycia.

Symbolami graficznymi związku są

asocjacje

nieskierowane i skierowane, obrazowane za pomocą
następujących znaków graficznych:

Asocjacja nieskierowana

(linia bez strzałki) wskazuje na

domyślną dwustronną komunikację pomiędzy aktorem a
przypadkiem użycia.

Asocjacja skierowana

(linia ze strzałką) jest

stosowana w przypadku, gdy zachodzi potrzeba wskazania

inicjatora

usługi. Skierowana asocjacja wskazuje również na fakt,

że element inicjujący zna zawsze element inicjowany, natomiast
element inicjowany nie zna tego pierwszego.

Diagram

Przypadków użycia

notacja i semantyka

17

GK (PSI(4) - 2009)

Przykład związku:

Możliwości uszczegółowiania związków

między przypadkami

użycia

stwarzają zależności (dependencies), które wskazują na

taki związek, w którym zmiana jednego przypadku użycia wpływa
na drugi. Wyróżnia się zależności:

•zawierania (include),

•rozszerzania (extend).

Klient

Złożenie zamówienia

Diagram

Przypadków użycia

notacja i semantyka

18

GK (PSI(4) - 2009)

Związek

zawierania

polega na tym, że

zawierający

(bazowy) przypadek użycia rozszerza swoją funkcjonalność na
zachowanie innego,

zawieranego

przypadku użycia, który stanowi

wydzieloną część funkcjonalności zawierającego przypadku
użycia. Zawierany przypadek użycia nie jest elementem
samodzielnym, uruchamianym tylko i zawsze, gdy jest
uruchamiany zawierający przypadek użycia. Przykład:

istota zależności

przykład realizacji

zależności

Tworzenie związku zawierania jest zasadne, gdy:

•istnieje możliwość wyłączenia w postaci zawieranego przypadku
użycia pewnej funkcjonalności, wspólnej dla kilku różnych
przypadków użycia,

•interakcje aktor-system są bardzo liczne.
Związki zawierania powodują istotne uproszczenie złożoności
modelu systemu oraz oprogramowania systemu.

Dokonanie wypłaty

Sprawdzenie stanu kasy

<<include>>

Zawierający

Zawierany

<<include>>

GK (PSI(4) - 2009)

19

Źródło: R. Simiński: Diagramy przypadków użycia (Internet).

Diagram

Przypadków użycia

notacja i semantyka

Przykład związku

zawieranie

:

Diagram

Przypadków użycia

notacja i semantyka

20

GK (PSI(4) - 2009)

Związek

rozszerzania

polega na tym, że

rozszerzany

(bazowy) przypadek użycia rozszerza swoją funkcjonalność o
funkcjonalność innego,

rozszerzającego

przypadku użycia, który

w sposób fakultatywny może zostać włączony do rozszerzanego
przypadku użycia. Rozszerzający przypadek użycia może być
elementem samodzielnym. Przykład:

istota zależności

przykład realizacji

zależności

Uruchamianie rozszerzającego przypadku użycia następuje
łącznie z rozszerzanym przypadkiem użycia, ale dopiero po
spełnieniu warunków określonych przez użytkownika, które mogą
być zapisane na diagramie w dowolnym języku.

Dokonanie wypłaty

Zapytanie o nominały

<<extend>>

Rozszerzany

Rozszerzający

Warunek roszerzenia

<<extend>>

Diagram

Przypadków użycia

notacja i semantyka

21

GK (PSI(4) - 2009)

Przykład związku

rozszerzanie

:

Źródło: R. Simiński: Diagramy przypadków użycia (Internet).

Diagram

Przypadków użycia

notacja i semantyka

22

GK (PSI(4) - 2009)

Generalizacja

(Generalization). Generalizacja (także uogólnienie)

jest związkiem pomiędzy aktorami lub przypadkami użycia, w

którym jeden z nich jest

przodkiem

, a drugi –

potomkiem

.

Potomek posiada wszystkie atrybuty przodka i dodatkowo jeszcze

specyficzne, własne: potomek jest niejako specjalizacją

(uszczegółowieniem) przodka. Generalizacja umożliwia tworzenie

hierarchii

dziedziczenia

(inheritance), która oznacza, że obiekty

będące potomkami dziedziczą atrybuty przodka, dodając własne

atrybuty indywidualne.

Generalizację graficznie oznacza się strzałką z pustym

grotem, skierowanym od potomka do przodka. Przykłady związku

generalizacji:

Generalizacja pomiędzy

aktorami

oznacza, że jeden aktor

odgrywa wszystkie role drugiego aktora i dodatkowo może

odgrywać jeszcze inne, własne role, a pomiędzy

przypadkami

użycia

– że jeden przypadek użycia jest uszczegółowioną wersją

drugiego i ten uszczegółowiony dziedziczy zachowanie ogólnego

oraz może dodawać dodatkowe zachowania własne.

Dyrektor

Pracownik

GK (PSI(4) - 2009)

23

Diagram

Przypadków użycia

notacja i semantyka

Przykład
diagramu
przypadk
ów użycia

Diagram

Przypadków użycia

proces tworzenia

24

GK (PSI(4) - 2009)

Proces tworzenia diagramu przypadków użycia obejmuje

następujące podstawowe etapy:
1.Identyfikacja aktorów.
2.Identyfikacja przypadków użycia.
3.Opracowanie związków (asocjacji).
4.Uszczegółowienie diagramu.
Podstawowy zbiór danych niezbędnych do utworzenia diagramu
przypadków użycia analityk, twórca tego diagramu, uzyskuje
poprzez opracowanie – wspólnie z przyszłym użytkownikiem
systemu informatycznego – wymagań do tego systemu.

Zwykle

pod pojęciem wymagań rozumie się wyrażenie odczuwalnej
potrzeby rozwiązania określonych problemów, których
rozwiązanie pozwoli na osiągnięcie zamierzonego celu.

W

szczególności wymagania powinny obejmować:



potrzeby i ograniczenia dotyczące funkcjonalności tworzonego

systemu informatycznego, własności oprogramowania, interfejsu
użytkownik-system, serwisu itp. (wymagania funkcjonalne),



określenie sposobu prezentacji potrzeb i ograniczeń (język

wymagań),



potrzeby, których spełnienie nie jest konieczne i wymagania o

różnych priorytetach (wymagania niefunkcjonalne).

Diagram

Przypadków użycia

proces tworzenia

25

GK (PSI(4) - 2009)

Jedną z najczęstszych przyczyn niepowodzenia projektów

systemów informatycznych są problemy związane z
wymaganiami do nich. Brak części wymagań, wymagania
niekompletne, źle sformułowane, różnie rozumiane przez
użytkownika i projektanta bądź często zmieniane w trakcie
trwania prac projektowych nad systemem są najczęściej
wymienianymi przyczynami powstawania systemów z usterkami
bądź przerywania w ogóle prac nad systemem. W celu uniknięcia
tych przykrych następstw, konieczne jest przed rozpoczęciem
prac projektowych możliwie najbardziej sformalizowane
zapisanie wymagań dotyczących całego systemu.

W przypadku systemu informatycznego wymagania

obejmują dwie ich kategorie: wymagania funkcjonalne i
wymagania niefunkcjonalne.

Wymagania funkcjonalne

to wymagania związane z

szeroko pojętą funkcjonalnością systemu, rozumianą jako
określenie tego,

co system ma robić

.

Wymagania niefunkcjonalne

odnoszą się do właściwości

systemu takich, jak jego bezpieczeństwo, niezawodność,
skalowalność itp., które w sumie mają określać

jaki system ma

być

.

Wyniki modelowania wymagań funkcjonalnych są

prezentowane w postaci diagramów przypadków użycia.

GK (PSI(4) - 2009)

26

Diagram

Klas -

notacja i

semantyka

Diagram Klas

(Class Diagram - CD) przedstawia

statykę systemu i stanowi podstawę do projektu przyszłej
obiektowej bazy danych. Formalnie diagram Klas można
określić jako graficzna prezentacja statycznych,
deklaratywnych elementów dziedziny przedmiotowe oraz
związków między nimi.

Podstawowymi pojęciami przy tworzeniu diagramu

klas są pojęcia

obiektu

i

klasy

.

Obiektem

jest każdy byt (osoba, rzecz, pojęcie)

umiejscowiony w dziedzinie przedmiotowej tworzonego
systemu informatycznego i mający znaczenie dla tego
systemu.

Z punktu widzenia modelowania obiekt jest

opisywany za pomocą trzech elementów:



tożsamości,



stanu,



zachowania.

Graficzny symbol obiektu:

student_Abacki

GK (PSI(4) - 2009)

27

Diagram

Klas -

notacja i

semantyka

Każdy obiekt jest opisywany za pomocą stałego zbioru

charakteryzujących go

atrybutów

(cech, właściwości – property)

np. nazwisko, imię, wzrost. Z każdym atrybutem jest związany
zbiór możliwych jego wartości (np. zbiorem wartości atrybutu
imię jest zbiór imion), przy czym atrybut w danej chwili może
przyjmować tylko jedną wartość.

Stan obiektu

(state) jest definiowany poprzez zbiór

wartości wszystkich jego atrybutów.

Tożsamość obiektu

(identity) jest określana przez wartość

atrybutu wyróżniającą ten obiekt spośród innych o takich samych
atrybutach. Np. tożsamość studenta na uczelni jest określana
poprzez wartość atrybutu „Numer albumu”.

Zachowanie obiektu

(behavior) jest to zbiór usług, które

obiekt potrafi wykonać na rzecz innych obiektów. Zachowanie
obiektu zapewnia możliwość modelowania dynamiki
(funkcjonowania) systemu. W ramach tej dynamiki obiekt może
prosić inny obiekt o wykonanie przez niego na swoją rzecz
określonej usługi, oczywiście możliwej do wykonania przez obiekt
poproszony. Wykonanie usługi może prowadzić do zmiany stanu
obiektu. Zwracanie się o wykonanie usługi następuje w formie

komunikatu

(message) z

parametrami

(parameters), które

stanowią wartości atrybutów obiektu, pozwalające na
odpowiednie sterowanie realizacją usługi.

Efekt wykonania

usługi zależy od stanu obiektu, parametrów wysłanego przez
niego komunikatu oraz od stanu obiektów biorących udział w
wykonaniu usługi.

GK (PSI(4) - 2009)

28

Klasa

(Class) jest nazwanym opisem grupy obiektów

o podobnych właściwościach. Klasa nie jest zbiorem
obiektów, lecz typem obiektu i jego właściwości: cech
strukturalnych i behawioralnych. Do cech strukturalnych
należą atrybuty i asocjacje. Do cech behawioralnych
(zachowań) należą operacje i metody. Każdy obiekt
przynależny do tej samej klasy, nazywany

instancją

, ma

wszystkie atrybuty charakteryzujące tę klasę oraz dostarcza
wszystkich usług określonych przez cechy behawioralne
klasy.

Klasa przechowuje definicje atrybutów, natomiast

wartości atrybutów przechowywane są w obiektach.

Atrybut klasy

jest to nazwana właściwość klasy,

określająca zbiór wartości, które mogą przyjmować jej

instancje. Atrybutu klas charakteryzują pojedyncze obiekty

lub niewielkie grupy obiektów, tworząc dla każdego z nich

niezależną instancję. Atrybuty mogą być przedstawiane na

diagramach na różnym poziomie szczegółowości.

Operacja

jest specyfikacją usługi udostępnianej przez

obiekt.

Metoda

jest implementacją operacji w klasie.

Określa jak obiekt z danej klasy wykonuje swoje działania.

Operacja może mieć zasięg obiektu (instancji) lub całej
klasy. Większość operacji ma zasięg obiektu. Szczególnym
przypadkiem operacji o zasięgu klasy jest operacja
tworzenia nowych obiektów w klasie, tzw. konstruktor.

Diagram

Klas -

notacja i

semantyka

GK (PSI(4) - 2009)

29

Ze względu na różnorodność sposobów

specyfikowania klas, stosuje się w diagramach różne ich
symbole:



na diagramie klasy nie występują sekcje atrybutów i

operacji:



klasa z niewyspecyfikowanymi operacjami lub atrybutami:



klasa z wyspecyfikowanymi atrybutami i operacjami:

Diagram

Klas -

notacja i

semantyka

Student

+NrAlbumu
+Pesel
+Nazwisko
+Imię

Student

+aktualizuj()

Student

Student

+NrAlbumu
+Pesel
+Nazwisko
+Imię

+aktualizuj()

Składnia atrybutów klasy:

[widoczność]

nazwa

[

: typ

[krotność] [{ograniczenia}] = wartość domyślna

30

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

widoczność

•

opcjonalna, nie ma wartości domyślnej,

•

wskazuje czy atrybut jest dostępny spoza klasy,

+

-

publiczny

– atrybut jest widoczny przez każdy element

systemu,

-

-

prywatny

– atrybut jest widoczny tylko we własnej klasie,

#

-

chroniony

– atrybut jest widoczny tylko wewnątrz własnej

klasy i w jej podklasach,

~

-

publiczny wewnątrz pakietu

– atrybut jest widoczny tylko

wewnątrz własnego pakietu,

typ

•

jest opcjonalny, nie ma wartości domyślnej,

•

typem atrybutu może być inna klasa,

•

pozostałe typy: boolean, integer, real, string.

GK (PSI(4) - 2009)

31

krotność (liczność)

•

oznacza liczbę wartości, które mogą być związane
jednocześnie z tym samym atrybutem w atrybucie, krotność,
powtarzalność atrybutu (np. imiona – najwięcej 2),

•

opcjonalna, ma wartość domyślną równą 1,

•

oznaczenia krotności:

1..*

- jedna lub wiele wartości,

3..5

– od 3 do 5 wartości (przedział),

2,4,18

– 2 lub 4 lub 18 wartości (wyliczenie),

*

- dowolna liczba wartości,

1..*

- fakultatywność: co najmniej 1 wartość,

0..1

– opcjonalnie: co najwyżej 1 wartość,

ograniczenia

•

ordered

- wskazuje, że wartości atrybutu są

uporządkowane,

•

unordered

- wskazuje, że wartości nie są uporządkowane

(domyślnie),

•

unique

– wartości atrybutu nie powtarzają się (np. numer

albumu studenta),

•

nonunique

– wartości atrybutu mogą się powtarzać (np.

imię studenta),

•

frozen

– wartość atrybutu nie może być zmodyfikowana po

jej przypisaniu.

Diagram

Klas -

notacja i

semantyka

[widoczność]

nazwa({lista_parametrów}) [: typ zwracany]

[{ograniczenia}]

Operacja to proces, który klasa potrafi wykonać.

32

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

lista_parametrów ([rodzaj] nazwa : typ [=

wartość_domyślna])

• rodzaj - jest opcjonalny, ma wartość domyslną in i może być

następujący:

o in – parametr jest tylko wejściowy i nie może być modyfikowany

przez operację,

o out – parametr jest tylko wyjściowy i może być modyfikowany

przez operację,

o inout – parametr jest wejściowo-wyjściowy, wprowadzany jako

wejściowy, a następnie modyfikowany przez operację,

o return – zwracany z operacji.

• typ zwracany i wartość-domyślna – są opcjonalne i nie

posiadają wartości domyślnych.

33

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

ogranizczenia



isQuery

- operacja jest zapytaniem i zwraca wartość bez

jakiejkolwiek modyfikacji klasy,



sequential

-

operacja może być wykonana tylko przez

jeden wątek programu,



leaf

-

operacja nie może być przedefiniowana przez klasy

pochodne (jest odwzorowywana na final w Javie, a w C++

odpowiada metodom zadeklarowanym bez słowa

kluczowego virtual),



guarded

-

podobnie jak sequential, ale współbieżne

wywołania tej operacji są obsługiwane sekwencyjne, bez

udziału obsługującego,



concurrent

-

operacja może jednocześnie obsługiwać wiele

wątków ją wywołujących.

wyszukaj(tytuł: String) : Wydawnictwo[]

post:
wynik != null
wynik instanceof

Wydawnictwo[]

pre:
tytuł != null

Warunki

wstępne

opisują stan

systemu
wymagany przed
wykonaniem
operacji

Warunki
końcowe

gwarancje dotyczące
stanu systemu po
wykonaniu operacji

34

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

GK (PSI(4) - 2009)

35

Diagram

Klas -

notacja i

semantyka

W diagramie klas klasy mogą być ze sobą łączone za

pomocą związkami, następujących rodzajów:

asocjacja

– obiekty klas są czasowo ze sobą powiązane,

uogólnienie (generalizacja)

– jedna klasa (podklasa) jest

szczególnym przypadkiem drugiej klasy (nadklasy),

zależność

– zmiana jednej klasy wpływa na drugą,

agregacja

– obiekt jednej klasy jest częścią obiektu drugiej

klasy.

Zależności

są najprostszym i najsłabszym rodzajem

relacji łączących klasy. Graficzne zależność jest obrazowana w
sposób następujący:

Klasa A

Klasa B

<<call>>

GK (PSI(4) - 2009)

36

Diagram

Klas -

notacja i

semantyka

Zależności oznaczają, że zmiana klasy wywołującej (A) w
pewien sposób wpływa na klasę wywoływaną (B), np.:

«call»

- klasa A wywołuje operację w klasie B,

«create»

- klasa A tworzy instancje klasy B,

«instantiate»

- obiekt A jest instancją klasy B,

«use»

- do funkcjonowania klasa A wymaga klasy B,

«import»

- część publiczna klasy B jest dołączana do klasy A,

«permit»

- klasa B zezwala klasie A na dostęp do swoich

atrybutów prywatnych.

Pracownia

StanowiskoBadawcze

<<use>>

Asocjacja

reprezentuje czasowe powiązanie pomiędzy

obiektami dwóch (asocjacje binarne) lub więcej (asocjacje n-arne)

klas. Obiekty związane asocjacją są od siebie niezależne.

Asocjacja jest też używana jako alternatywny (obok atrybutu)

i równorzędny sposób zapisu właściwości klasy. Graficznie asocjacja

w najprostszej formie jest przedstawiana za pomocą linii:

asocjacja binarna

asocjacja n-arna

37

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

Klasa A

Klasa A

Klasa B

Klasa A

Klasa C

Pełna interpretacja asocjacji
wymaga znajomości takich
jej atrybutów, jak:

nazwa

,

role powiązanych klas

,

nawigacji

,

liczebności

i

agregacji

.

GK (PSI(4) - 2009)

38

Diagram

Klas -

notacja i

semantyka

Nazwa asocjacji

. Asocjacje mogą być nienazwane i

nazwane, a te ostatnie – także czasami ze wskazaniem
kierunku odczytu asocjacji (strzałka przy nazwie):

asocjacja nienazwana

asocjacja

nazwana

Role

. Każda klasa pełni rolę jakąś rolę w asocjacji. W

asocjacji binarnej rola klasy oznacza powinność pełnioną
przez nią na rzecz drugiej klasy. W asocjacji n-arnej rola klasy
oznacza powinność, którą ona pełni na rzecz każdej z
powiązanych pozostałych klas. Graficzne oznaczenie ról w
asocjacji:

Klasa D

Klasa E

Klasa D

Klasa E

zarządza

Klasa D

Klasa E

zarządzanie

+zarządzany

+zarządca

GK (PSI(4) - 2009)

39

Diagram

Klas -

notacja i

semantyka

Nawigacja

oznacza komunikowanie się klas procesie

wykonywania operacji. Zwykła asocjacja (linia) oznacza
komunikowanie się dwukierunkowe, co oznacza, że klasy
wymieniają między sobą komunikaty w trakcie wykonywania
operacji. W przypadku, gdy taka komunikacja jest planowana
jako jednokierunkowa, do jej oznaczania stosuje się
oznaczenie w postaci strzałki, skierowanej od nadawcy do
odbiorcy, np.:

Nawigacja kierunkowa może być uzupełniona o warunki jej
realizowalności.

Liczebność

oznacza liczbę obiektów jednej klasy, które

w tym samym czasie mogą być związane z jednym obiektem
drugiej klasy znajdującej się w tej samej asocjacji z klasą
pierwszą. Liczebność jest określana dla każdej klasy w
asocjacji i jej interpretacja polega na rozpatrzeniu sytuacji,
gdy po jednej stronie asocjacji występuje jeden obiekt,
natomiast liczba obiektów drugiej klasy, które są z nim
związane, jest ustalana.

Klasa G

Klasa F

GK (PSI(4) - 2009)

40

Diagram

Klas -

notacja i

semantyka

Oznaczenia liczebności i ich interpretacja są podobne

do oznaczeń krotności atrybutów klas. I tak:

1

- dokładnie jeden obiekt,

n

- dokładnie

n>1

obiektów,

n..m

- od

n

do

m

obiektów (

n,m>1

,

m>n

),

*

- dowolna liczba obiektów,

1..*

- fakultatywność: co najmniej 1 wartość,

0..1

– opcjonalnie: co najwyżej 1 obiekt,

0..*

- opcjonalnie: żaden obiekt lub wiele obiektów.

Klient

Samochód

zakup +produkt

+właściciel

1..*

1

Jeden

klient

(obiekt), drogą

zakupu, może stać się
właścicielem co najmniej
jednego produktu w postaci
samochodu, natomiast jeden

samochód

(obiekt) może

mieć tylko jednego
właściciela.

GK (PSI(4) - 2009)

41

Diagram

Klas -

notacja i

semantyka

Agregacja

(aggregation) opisuje związek całość-część

pomiędzy klasami. Oznacza to, że agregacja umożliwia
oznaczanie sytuacji, w których wiele obiektów cząstkowych
składa się na obiekt całościowy. Wyróżnia się dwa typy
agregacji:



agregację całkowitą

(kompozycja), inaczej agregację silną

lub składową, służącą do modelowania „nierozerwalnego”
związku całość-część, w którym nie ma sensu samodzielne
istnienie części,



agregację częściową

, inaczej agregację słabą lub

współdzieloną.
Symbole graficzne agregacji występują agregatach, przy czym
romb wypełniony
oznacza agregację całkowitą, a romb pusty -
częściową.

Obydwie relacje oparte są na pojęciach

agregatu

(obiekt stanowiący całość) oraz

segmentu

(część obiektu).

Role poszczególnych składników relacji agregacji są ściśle
określone:

agregat

– „składa się z..”, „zawiera”, „obejmuje”,

segment

– „wchodzi w skład”, „należy do”, „jest zawarty

w”.

GK (PSI(4) - 2009)

42

Diagram

Klas -

notacja i

semantyka

W przypadku

agregacji całkowitej

segmenty, tj.

obiekty będące częściami agregatów nie mogą istnieć
samodzielnie i niezależnie funkcjonować, co oznacza, że
usunięcie agregatu powoduje automatyczne usunięcie jego
segmentów.

W przypadku

agregacji częściowej

segmenty, tj.

obiekty będące częściami agregatów mogą samodzielnie
istnieć i funkcjonować, co oznacza, że usunięcie agregatu
nie powoduje automatycznego usunięcie jego segmentów.

Komputery (

Komputer

)

będące (jeżeli były) na
wyposażeniu laboratorium
(

Laboratorium

) nie ulegają

likwidacji w przypadku
likwidacji laboratorium i
mogą być wykorzystane gdzie
indziej.

Laboratorium

Komputer

1

0..*

Laboratorium

StanowiskoBadawcze

1

1..*

Stanowiska badawcze
(

StanowiskoBadawcze

)

ulegają likwidacji w
przypadku likwidacji
laboratorium
(

Laboratorium

).

Uogólnienie (generalizacja)

reprezentuje hierarchiczny związek pomiędzy

elementem ogólnym

(klasa abstrakcyjna, nadklasa, przodek) a

specyficznym jego

rodzajem

– klasa konkretna (podklasa, potomek). Klasy abstrakcyjne nie mają

instancji (konkretnych obiektów), ale stanowią uogólnienie obiektów klas

konkretnych. O klasie abstrakcyjnej mówi się, że jest generalizacją klasy

konkretnej, natomiast o klasie konkretnej mówi się, że jest specjalizacją klasy

abstrakcyjnej.

Klasom abstrakcyjnym można przypisywać atrybuty i operacje podlegające

dziedziczeniu

zgodnie z hierarchią klas dzięki, któremu własności klasy

abstrakcyjnej są importowane do jej klas konkretnych, które oprócz własności

indywidualnych posiadają także wszystkie własności swojej klasy abstrakcyjnej.

43

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

Pracownik

PracownikEtatowy

PracownikSezonowy

Klasy na najniższym poziomie
hierarchii noszą nazwę liści
(leafs), a na najwyższym poziomie
hierarchii – korzeni (roots).

Na związek uogólnienia mogą być nakładane następujące ograniczenia:



{complete}

– zawiera wszystkie klasy konkretne dla danej klasy

abstrakcyjnej<



{incomplete}

– zestaw klas konkretnych przypisany danej klasie

abstrakcyjnej nie jest kompletny,



{disjoint}

– domyślny typ uogólnienia oznaczający, że każda klas

konkretna występująca w danej hierarchii jest związana w ogóle tylko z
jedną klasa abstrakcyjną,



{overlapping}

– występujące w hierarchii klasy mogą mieć wspólne

klasy konkretne (dziedziczenie wielokrotne).

44

GK (PSI(4) - 2009)

Diagram

Klas -

notacja i

semantyka

Pracownik

PracownikEtatowy

PracownikSezonowy

{incomple
te}

Jeszcze mogą być inne
kategorie
pracowników niż tylko
wymienione dwie.

45

GK (PSI(3) - 2009)

1. Zidentyfikuj kandydujące rzeczowniki ze sformulowania

problemu i wymagań jako potencjalne klasy.

2. Szukaj transakcji, zdarzeń, ról, i rzeczy dotykalnych, np.

3. Sklasyfikuj rzeczowniki jako: ludzie, miejsca, rzeczy,

organizacje, pojęcia (zasady, pomysły, reguły), zdarzenia
(rzeczy, które się zdarzają).

4. Zidentyfikuj rzeczowniki, które nie mają kompletnej definicji.

Przypisz je do kategorii atrybutów lub klas obiektów.

Transakcje: pożyczka, spotkanie, sprzedaż
Zdarzenia: lądowanie, zapytanie
Role: matka, ojciec, nauczyciel, pasażer
Rzeczy dotykalne: samochód, czujnik, składnik, samolot

Diagram

Klas -

notacja i

semantyka – identyfikacja

obiektów i klas

46

GK (PSI(3) - 2009)

5. Zidentyfikuj potencjalne kolekcje (zbiory). Pewne

rzeczowniki implikuja kolekcje i mogą stać się kontenerami
(container). Kolekcje wymagają bazy danych i specjalnego
programowania.

6. Zidentyfikuj obiekty stanowiące pogranicze systemu: obiekty

dostępne dla innych systemów, linie komunikacyjne,
urzadzenia peryferyjne, obiekty wejścia/wyjścia,..

Np.: każdy dostęp jest rejestrowany w dzienniku – dziennik jest kolekcją.

Charakterystyczne cechy obiektów we/wy:

• ich atrybuty lub stan są ulotne (niestabilne),

• zmieniają się pod wpływem bodźców zewnętrznych,

• są źródłem/przechowalnią komunikatów z zewnątrz,

• nie można ich usunąć.

Diagram

Klas -

notacja i

semantyka – identyfikacja

obiektów i klas

47

GK (PSI(3) - 2009)

1. Rzeczownik może być atrybutem, jeżeli nie można

przypisać mu zachowania i atrybutów.

2. Rzeczownik może być atrybutem, jeżeli wyjaśnienie jego

znaczenia zmusza do odwołania się do jakiegoś innego
rzeczownika (oznaczającego obiekt).

Np. rzeczownik

“kolor” zmusza do zadania pytania “kolor czego?”

.

3. Zastanów się czy coś, co może być atrybutem, nie jest

asocjacją między klasami.

4. Zidentyfikuj klasę lub asocjację, która jest najlepszym

kandydatem jako “właściciel” atrybutu.

Diagram

Klas -

notacja i

semantyka – identyfikacja

atrybutów

48

GK (PSI(3) - 2009)

1. Wyciągnij przed nawias wszelkie wspólne własności

(operacje i atrybuty) kilku powiazanych klas.

2. Zgrupuj te wspólne własności w jedną super-klasę.

3. Nazwij tę superklasę w taki sposób, aby każda pochodna

klasa mogła byc uważana za podklasę.

Np. pies jest

superklasą, pekińczyk, jamnik, pudel są podklasami klasy
pies

.

4. Podklasy moga mieć puste lub niepuste przecięcie. Oznacz

je odpowiednio.

Diagram

Klas -

notacja i

semantyka – generalizacja

GK (PSI(4) - 2009)

49

Diagram

Czynności -

notacja i

semantyka

Diagram Czynności

(Activity Diagram - AD) jest

jednym z diagramów opisujących dynamikę systemu i
stanowi graficzną reprezentację przepływu sterowania.
Diagram AD:

powinien być stosowany:



do analizowania przypadków użycia - gdy interesują

bardziej operacje niezbędne do realizacji danego

przypadku (czy też wzajemne zależności między tymi

operacjami), a nie to, kto jest odpowiedzialny za ich

przeprowadzenie,



do zrozumienia interakcji zachodzących między

przypadkami użycia,



do modelowania przetwarzania wielowątkowego,

nie powinien być stosowany:



do pokazywania współpracy między obiektami w

trakcie realizacji przypadku użycia – do tego bardziej

nadają się diagramy interakcji,



do pokazywania zachowań obiektów w trakcie ich życia

- w tym celu powinno się wykorzystywać diagramy

stanów.

Diagramy AD są tworzone z wykorzystaniem

następujących podstawowych elementów graficznych:

czynności

,

akcje

,

przepływy sterowania

,

początek

,

koniec

i

zakończenie przepływu

oraz

składnicy danych

.

GK (PSI(4) - 2009)

50

Diagram

Czynności -

notacja i

semantyka

Czynności

(activities) mogą określać rozbudowaną

funkcjonalność, tzn. reprezentować złożone procesy
biznesowe bądź algorytmy przetwarzania. Czynność definiuje
się jako określone zachowanie, złożone z logicznie
uporządkowanego ciągu czynności (akcji) oraz obiektów w
celu zrealizowania pewnego procesu.

Graficzny symbol czynności: .

W celu precyzyjniejszego opisu czynności dokonuje się ich
dekompozycji na czynności bardziej proste. Czynnościami
nie podlegającymi dalszemu dekomponowaniu są

akcje

,

które definiuje się jako elementarne jednostki specyfikacji
zachowania, które reprezentują transformację
(przetwarzanie) w modelowanym systemie.
Przykłady graficznej prezentacji akcji:

GK (PSI(4) - 2009)

51

Diagram

Czynności -

notacja i

semantyka

Przepływ sterowania

(control flow) jest relacją między

dwoma czynnościami bądź akcjami, wskazująca na kolejność
wykonywania tych czynności bądź akcji. Symbolem graficzny
przepływu sterowania jest strzałka , której
kierunek wyznacza kierunek przepływu sterowania i
następstwo wykonania czynności bądź akcji.

Prezentacja rzeczywistych sytuacji wymaga

umiejętności graficznego prezentowania przepływów
decyzyjnych oraz przepływów współbieżnych. Przepływy
decyzyjne są to przepływy alternatywne, uzależnione od
spełnienia

warunków

, czy wykonania

scalenia

lub

rozwidlenia

.

Warunek graficznie prezentuje się za pomocą

symbolu decyzyjnego postaci: .

Scalenie

i

rozwidlenie

oznacza się za pomocą symboli:

oraz .

GK (PSI(4) - 2009)

52

Diagram

Czynności -

notacja i

semantyka

Początek i koniec

są oznaczane na diagramie za pomocą symboli:

początek - , koniec - .

Zakończenie przepływu

to punkt zatrzymania wybranego

przepływu sterowania. Na jednym diagramie czynności może
wystąpić więcej niż jedno zakończenie

przepływu, które jest oznaczane symbolem .

Na diagramach czynności mogą również występować

sygnały

, które definiuje się jako asynchroniczne bodźce

inicjujące czynności lub akcje. Wyróżnia się sygnały

nadawcze

oraz

odbiorcze

, odpowiednio wysyłane i odbierane przez

czynności lub akcje. Graficzne symbole sygnałów:

•nadawczy: ,

•odbiorczy: .

GK (PSI(4) - 2009)

53

Diagram

Czynności -

notacja i

semantyka

Zobrazowanie sposobu realizacji przypadków użycia lub

innych procesów wymaga niejednokrotnie wskazania na

diagramach czynności źródła danych wejściowych do czynności

lub akcji względnie ujścia wytworzonych przez nie danych

wyjściowych. W tym celu wykorzystywane są

składnice danych

(data store nodes), które definiuje się jako pojemnik (bez

wskazywania jego implementacji) na dane przechowywane w

dłuższym okresie.

Graficzny symbol składnicy: .

Powiązanie symbolu składnicy z symbolem czynności lub akcji

następuje za pomocą linii przerywanej zakończonej otwartym

grotem.

W celu poprawienia czytelności diagramu są stosowane

na nim poziome i pionowe

partycje

(tory), służące do dzielenia

czynności (akcji) na grupy, z których każda reprezentuje

jednostkę (organizacji lub systemu) odpowiedzialną za realizację

przydzielonych czynności (akcji). Każda partycja ma nazwę,

unikatową w obrębie jednego diagramu, a każda czynność

(akcja) należy tylko do jednej partycji, ale przepływy mogą

przecinać granice partycji. Graficzne symbole pionowej i

poziomej

partycji: , .

GK (PSI(4) - 2009)

54

Diagram

Czynności -

notacja i

semantyka

GK (PSI(4) - 2009)

55

Diagram

Czynności –

proces

tworzenia

Diagram Czynności

powstaje w wyniku analizy

przypadków

użycia

i przebiega w następujących zasadniczych etapach:

1.Analiza przypadku użycia i jego scenariuszy.
2.Identyfikacja podstawowych czynności na podstawie
scenariusza przypadków użycia.
3.Połączenie czynności za pomocą przepływów sterowania.
4.Identyfikacja decyzyjnych i współbieżnych przepływów
sterowania.
5.Wprowadzenie warunków i ograniczeń przepływów sterowania.

GK (PSI(4) - 2009)

56

Diagram

Sekwencji -

notacja i

semantyka

Diagram Sekwencji

(Sequence Diagram – SD) jest

rodzajem diagramu interakcji i opisuje interakcje pomiędzy

instancjami klasyfikatorów systemu w postaci komunikatów

wymienianych między nimi. Jest związany z diagramem

przypadków użycia.

Interakcja

rozumiana jako zbiór komunikatów pomiędzy

instancjami klasyfikatorów, tj. wywołania operacji, tworzenie i

usuwanie instancji, jest opisywana w diagramie SD jest w dwóch

kierunkach:

poziomym

– jako oś na której zostały umieszczone instancje

klasyfikatorów biorących udział w interakcji (składowa

statyczna),

pionowym

– jako oś czasu przedstawiająca rozmieszczone

chronologicznie komunikaty (składowa dynamiczna).

Podstawowymi elementami diagram sekwencji są:

klasyfikator

,

komunikat

,

linia życia

i

ośrodek sterowania

.

Klasyfikator

to abstrakcyjna kategoria modelowania

uogólniająca kolekcje instancji o tych samych własnościach.

Klasyfikatorem może być aktor, przypadek użycia, klasa.

Linia życia

(lifeline)

to linia powiązana z konkretną

instancją klasyfikatora wskazująca na diagramie okres istnienia

instancji.

Komunikat

(message)

to specyfikacja wymiany danych

między instancjami klasyfikatorów, zawierająca zlecenia

wykonania określonych operacji przez adresata komunikatu.

nazwa1

Instancja klasyfikatora

Linia życia

Aktywacja

nazwa2

komunikat

Treść i parametry
odpowiedzi

(…)

odpowiedź

Ośrodek sterowania

Dezaktywacja

Treść i parametry
komunikatu

(…)

57

GK (PSI(4) - 2009)

Diagram

Sekwencji -

notacja i

semantyka

GK (PSI(4) - 2009)

58

Diagram

Sekwencji -

notacja i

semantyka

Linia życia

reprezentuje okres życia instancji

klasyfikatora, która w pewnych okresach swojego życia jest
aktywna, aktywowana przez komunikaty, a w pozostałych
okresach życia – nie jest aktywna, jest w stanie czuwania. W
okresach aktywności instancja klasyfikatora przejmuje
sterowanie interakcją oraz podejmuje działania zlecone w
komunikacie, a po ich wykonaniu i wysłaniu odpowiedzi
nadawcy komunikatu może przechodzić w stan czuwania.
Okresy aktywności instancji klasyfikatora noszą nazwę

ośrodków sterowania

(execution specification).

Ośrodek

sterowania na diagramie przyjmuje postać prostokąta
położonego na linii życia.

Ośrodek sterowania jest inicjowany

aktywacją

, a

przejście w stan czuwania –

dezaktywacją

.

Zaawansowanymi składnikami diagramu są m.in:

•rodzaje komunikatów,

•tworzenie i niszczenie obiektów,

•warunki,

•samowywołanie,

•iteracja,

•Rozgałęzienie.

GK (PSI(4) - 2009)

59

Diagram

Sekwencji -

notacja i

semantyka

Rodzaje komunikatów:

synchroniczny

,

asynchroniczny

,

zwrotny

,

utracony

,

znaleziony

,

opcjonalny

,

oczekujący

.

Wysłanie komunikatu

synchronicznego

oznacza

przekazanie sterowania do klasyfikatora-odbiorcy. W chwili
przesłania tego komunikatu aktualny

przepływ sterowania klasyfikatora-nadawcy zostaje przerwany
i będzie wznowiony dopiero po wykonaniu przez klasyfikator-
odbiorcę czynności lub operacji inicjowanej przez ten
komunikat.

GK (PSI(4) - 2009)

60

Diagram

Sekwencji -

notacja i

semantyka

Komunikat

asynchroniczny

nie

powoduje przerwania przepływu
sterowania klasyfikatora-nadawcy.
Klasyfikator-nadawca pozostaje w
stanie aktywności i nie oczekuje
odpowiedzi.

Komunikat

zwrotny

wskazuje na

powrót sterowania do
klasyfikatora-nadawcy po
wykonaniu komunikatu
synchronicznego. Komunikat
zwrotny nie tylko przekazuje
sterowanie, ale ma również za
zadanie zainicjowanie operacji.

GK (PSI(4) - 2009)

61

Diagram

Sekwencji -

notacja i

semantyka

Komunikat

utracony

– nieznany odbiorca:

Komunikat

znaleziony

– nieznany nadawca:

GK (PSI(4) - 2009)

62

Diagram

Sekwencji -

notacja i

semantyka

Komunikat

opcjonalny

oznacza,

że nadawca wysyła do odbiorcy
komunikat oczekując jego
bezzwłocznego obsłużenia. W
przypadku, gdy obsługa
komunikatu nie może być
natychmiastowa, nadawca nie
podejmuje dalszych prób jego
przesyłania, komunikat
opcjonalny nie zawsze może być
obsłużony.

Komunikat

oczekujący

– podobny

do opcjonalnego, tylko, że
nadawca czeka na jego wykonanie
przez określony odcinek czasu, a
potem rezygnuje i komunikatu
nie ponawia.

GK (PSI(4) - 2009)

63

Diagram

Sekwencji -

notacja i

semantyka

Tworzenie

lub

niszczenie

obiektu następuje po

przesłaniu odpowiedniego komunikatu

(<<create>>

lub

<<destroy>>

). Obiekt utworzony jest umieszczany na

diagramie sekwencji poniżej pierwotnie istniejących instancji
klasyfikatorów tak, aby jego położenie było zgodne z czasem
utworzenia. Po słowie

create

fakultatywnie może być

umieszczona nazwa operacji tworzącej obiekt.

Obiekt przestaje istnieć po odebraniu od niego komunikatu

destroy

, co na diagramie jest oznaczane znakiem X na linii

życia obiektu niszczonego.

Po słowie

destroy

fakultatywnie

może być umieszczona nazwa operacji niszczącej obiekt.

GK (PSI(4) - 2009)

64

Diagram

Sekwencji -

notacja i

semantyka

Wykonanie komunikatu może zależeć od spełnienia

określonych

warunków

.

Sposób zapisu warunków nie jest

skodyfikowana, ale najczęściej występują one w formie tekstu
ujętego w kwadratowe nawiasy i są umieszczane przed nazwą
komunikatu.

GK (PSI(4) - 2009)

65

Diagram

Sekwencji -

notacja i

semantyka

Samowywołanie

oznacza

sytuację, że instancja klasyfikatora
wywołuje własną operację. Na
diagramie oznaczane jest to za pomocą
zagnieżdżenia ośrodka sterowania
(iteracja).

Iteracja

oznacza wielokrotne, o

określonej wielokrotności,
powtórzenie komunikatu. Iteracja jest
opisana w nazwie komunikatu, a
krotność jej wykonania jest oznaczana
symbolem „

*

” , po którym następuje

liczba wykonań. Podstawowa notacja
iteracji:

*

|

*[

<specyfikacja-iteracji>

]

<nazwa-

operacji>

.

Przykłady:

*[i := 1..10] - komunikat będzie wysłany 10
razy,
*[x < 10] - komunikat będzie wysyłany
dopóki x < 10,
*[pozycja znaleziona] - komunikat będzie
wysyłany dopóty, dopóki pozycja nie
zostanie znaleziona
(do momentu, gdy warunek przyjmie
wartość FALSE)

GK (PSI(4) - 2009)

66

Diagram

Sekwencji -

notacja i

semantyka

Rozgałęzienie

jest sposobem przekazywania sterowania

z linii życia (ośrodka sterowania) klasyfikatora-nadawcy do
klasyfikatorów-odbiorców

(klasyfikatora-odbiorcy) w

zależności od spełnienia warunku przypisanego do
komunikatu.

Wspólny punkt czasowy

:

warunki muszą się
wykluczać – wysłany będzie
tylko jeden komunikat.
Wysyłane komunikaty mogą
być do jednego lub kilku
odbiorców (np. każdy
komunikat do innego
odbiorcy). W pierwszym
przypadku następuje
rozgałęzienie linii życia
odbiorcy (ilustracja).

GK (PSI(4) - 2009)

67

Diagram

Sekwencji –

proces

tworzenia

Diagram Sekwencji

powstaje w wyniku analizy

przypadków

użycia

i przebiega w następujących zasadniczych etapach:

1.Analiza przypadku użycia i jego scenariuszy.
2.Identyfikacja klasyfikatorów, których instancje będą
uczestniczyć w interakcjach.
3.Opracowanie koncepcyjnego (ogólnego) diagramu sekwencji
zawierającego:

•zidentyfikowane instancje klasyfikatorów, rozmieszczone na osi
poziomej,

•komunikaty, uporządkowane na osi pionowej,

•ośrodki sterowania, zlokalizowane na liniach życia instancji
klasyfikatorów.
4.Opracowanie implementacyjnego diagramu sekwencji poprzez
uszczegółowienie diagramu koncepcyjnego o:

•uszczegółowienie warunków komunikatów,

•tworzenie i niszczenie obiektów,

•samowywołania, iteracje, rozgałęzienia itp.