Analiza i modelowanie systemów

informatycznych – diagramy UML

dr inż. Elżbieta Zamiar

ezamiar@wsb.gda.pl
Agenda

 Przypomnienie
 Różnice w podejściu strukturalnym a
obiektowym
 Co to jest model
 Charakterystyka języka UML
 Diagramy klas
 Diagram obiektów
 Diagramy aktywności
Model
 Spójny opis systemu
 Stanowi kompletny obraz systemu utworzony z
określonej perspektywy na pewnym poziomie
szczegółowości, co oznacza, że niektóre elementy
systemu są ukryte, a inne wyeksponowane
 Pojedynczy model zazwyczaj nie wystarcza ani do
zrozumienia wszystkich aspektów systemu
jednocześnie, ani do jego implementacji
 Proces projektowania systemu informatycznego
polega na kolejnym tworzeniu i wzajemnym
przekształcaniu wielu modeli
Diagram a model

 Diagram służy do opisania modelu

 Model może być opisywany przy
pomocy wielu diagramów
DC i SD we wzorcu mediatora
Podejście strukturalne a
obiektowe
STRUKTURALNE
 dane i procesy modelowane
osobno,
 wykorzystanie w zasadzie
tylko prostych typów danych,
 dobrze dostosowane do
relacyjnego modelu danych,
 podstawowe techniki
 diagramy hierarchii funkcji
(FHD),
 diagramy związków encji
(ERD),
 diagramy przepływu danych
(DFD).
OBIEKTOWE
 dane i procesy modelowane
łącznie,
 wykorzystują złożone typy
danych,
 dostosowane do obiektowego
modelu danych,
 podstawowe techniki:
 diagramy opisu struktury
(diagramy klas UML)
 diagramy opisu dynamiki
(przypadki użycia (DPU),
modele dynamiczne UML:
interakcji , czynności i
stanów).
UML
 Służy do modelowania systemów
 Jest graficznym językiem wizualizacji,
specyfikowania, tworzenia i dokumentowania
składników i systemów …. informatycznych
 UML nie jest metodyką projektowania
 Jest notacją, opierającą się o podstawowe pojęcia
obiektowości
 Notacja, która może być użyta w dowolnej
metodyce
 Zapewnia semantykę ułatwiającą wymianę danych
modelu pomiędzy wieloma narzędziami CASE
(polecam https://prezi.com/p/zu19htr1ldn7/narzedzia-case/ )
Obiekt, klasa, enkapsulacja

 Obiekt – instancja klasy (byt)

enkapsulująca:
 strukturę danych
 zachowanie
 Klasa – zbiór obiektów
 Klasa wzorcowa (bez instancji) – klasa
abstrakcyjna
Rodzaje diagramów

 Diagramy opisu
struktury

 Diagramy opisu
dynamiki
Diagramy UML
Diagram struktury
Delegowanie i przejmowanie
zadań przez klasy
 Związki
pomiędzy
diagramami
UML – Diagram Klas

(ang. Class diagram – CD)

Cel: Opis cech i metod obiektów

istotnych z punktu widzenia
analizowanej dziedziny
Klasa

 Zbiór jednorodnych
obiektów
 Posiada min nazwę
(Folder)
 Może posiadać:
 cechy/atrybuty (na
czerwono)
 metody/funkcje/pro
cesy (na zielono)
Atrybuty
 Atrybuty mogą być przedstawiane na diagramach
na różnych poziomach szczegółowości - wszystkie
elementy wchodzące w skład specyfikacji atrybutu,
oprócz jego nazwy, (czyli m.in. stereotyp,
dostępność, typ) mogą być opuszczone.
 Reguły nazewnictwa dla atrybutów są podobne do
reguł nazewnictwa dla klas, tzn. nazwa powinna
odzwierciedlać semantykę atrybutu i powinna być
możliwie krótka.
 Na etapie analizy nazwa może zawierać znaki,
które nie są dozwolone w środowisku implementacji
(np. spacje).
Atrybut klasy – składnia
 Pełne określenie atrybutu klasy posiada składnię:

[widoczność] nazwa: typ [krotność] {ograniczenia} =wart. domyślna

 Widoczność - 4 poziomy widoczności

 + publiczny – widoczny z każdego miejsca systemu
 - prywatny – widoczny tylko wewnątrz własnej klasy
 # chroniony – widoczny wewnątrz klasy i jej podklas
 ~ publiczny wewnątrz pakietu – widoczny wewnątrz
własnego pakietu
Atrybut klasy - składnia
 Pełne określenie atrybutu klasy posiada składnię:

[widoczność] nazwa: typ [krotność] {porządkowanie} =wart. domyślna

 Krotność jest opcjonalna, domyślnie =1= i oznacza wartości, które

mogę być przechowywane w atrybucie. Jeżeli krotność ma tylko 1
wartość to jest pomijana wraz z nawiasami kwadratowymi i
porządkowanie

 Najczęściej stosowane porządkowanie to:

 {unrdered} – elementy wewnątrz atrybutu są nieuporządkowane- default
 {ordered} – elementy wewnątrz atrybutu są uporządkowane
 {unique}– elementy wewnątrz atrybutu nie mogą się powtarzać
 {readOnly} – elementy wewnątrz atrybutu nie mogą być zmieniane
 {frozen} – elementy wewnątrz atrybutu, po ustawieniu nie mogą być
ponownie edytowane
 Rodzaje atrybutów
 proste - przechowują pojedyncze atomowe,
niepodzielne wartości, np.: imię, nazwisko, nazwisko
panieńskie, wiek, płeć, stosunek do służby
wojskowej;
 złożone - przechowują wartości, które potencjalnie
mogą nie być atomowe, np.: data urodzenia, adres
zamieszkania, lista poprzednich miejsc pracy, adres
firmy;
 opcjonalne - nie każdy obiekt danej klasy posiada
wartość dla tego atrybutu, np.: nazwisko
panieńskie, stosunek do służby wojskowej, lista
poprzednich miejsc pracy; na diagramie
opcjonalność atrybutu jest oznaczana poprzez
umieszczenie [0..1] po jego nazwie;
 powtarzalne - potencjalnie mogą przechowywać
wiele wartości tego samego typu, np.: lista
poprzednich miejsc pracy; na diagramie
powtarzalność atrybutu jest oznaczana poprzez
umieszczenie [0..*] po jego nazwie;
 pochodne - są wypadkową innych wartości,
np. wiek; nazwy atrybutów pochodnych są
poprzedzane ukośnikiem ("/");
 klasowe - ich wartości są identyczne dla wszystkich
obiektów klasy, np. adres firmy (oczywiście pod
warunkiem, że wszyscy pracownicy pracują w tej
samej firmie); na diagramie nazwy atrybutów
klasowych są podkreślane;
 atrybut będący obiektem, np. zdjęcie.
Metody klasy - składnia
 Metody to procesy, które klasa potrafi wykonać, pełne
określenie metody posiada składnię:

[widoczność] rodzaj nazwa(parametr1, parametr2,...) :typ

{ograniczenia}

 rodzaj określa sposób, w jaki metoda korzysta z danego

argumentu:
 in: metoda może czytać wartość parametru, ale nie może jej
zmieniać;
 out: metoda może zmieniać wartość parametru, ale nie może jej
czytać;
 inout: metoda może zarówno czytać, jak i zmieniać wartość
parametru.
Atrybut – klucz/id - NIE
 Jedną z podstawowych własności
obiektu jest jego tożsamość, nie
zachodzi potrzeba definiowania na
etapie analizy klucza, czyli specjalnego
atrybutu (atrybutów) unikalnie
identyfikującego (identyfikujących)
obiekt.
 Gdyby atrybut id_osoby miał służyć
wyłącznie do identyfikacji obiektu, czyli
spełniać rolę podobną do roli pełnionej
przez klucz główny w modelu
relacyjnym, to jego wprowadzenie
należałoby uznać za błąd.
 Jeżeli jednak ten atrybut nie pełniłby
takiej roli, ale miałby znaczenie w
dziedzinie problemowej, np.
odpowiadałby numerowi PESEL, to
umieszczenie go wśród inwariantów
klasy jest oczywiście jak najbardziej
poprawne.
Metody klasy - składnia
 Metody to procesy, które klasa potrafi wykonać, pełne
określenie metody posiada składnię:

[widoczność] rodzaj nazwa(parametr1, parametr2,...) :typ

{ograniczenia}

 Metody mogą mieć również przypisane warunki wstępny i

końcowy
 Warunek wstępny określa w jakim stanie muszą znajdować się
pewne elementy systemu by operacja wykonała się prawidłowo
 np. pre: parametr1 != null
 Warunek końcowy określa oczekiwany stan elementu systemu
po wykonaniu operacji
 np. post: wynik != null
Krotność

Pozwala określić minimalną i maksymalną

liczbę obiektów, jakie można powiązać z
daną relacją lub liczbę atrybutów obiektu:
 dolna granica..górna granica - przedział od-do
 1 - dokładnie jeden obiekt
 0..1 - opcjonalnie jeden obiekt
 1..* - przynajmniej jeden obiekt
 1, 3, 5 - konkretne liczby obiektów
 * - dowolna liczba obiektów (skrót 0..*)
Krotność - przykład
Związki między klasami -
skojarzenia/relacje

 Oznaczane liniami (ciągłą lub

przerywaną)
 Każdy koniec skojarzenia może być
etykietowany przez rolę
 Może posiadać strzałkę, gdy obiekt
inicjuje działanie
Rodzaje relacji między klasami
Relacje - Zależność

 Jest najsłabszym rodzajem relacji między

klasami
 Zmiana w jednej z klas wpływa jakoś ”na
drugą”.
 Zależność ta jest zwykle jednokierunkowa.
 Oznacza się ją przerywaną linią ze strzałką
określającą kierunek relacji
 Typy zależności

 Do typowych zależności należą:

 <<call>> -operacje klasy E_1 wywołują operacje
klasy E_2
 <<create>>– klasa E_1 tworzy instancje klasy E_2
 <<instantiate>> – obiekt E_1 jest instancją klasy 2
 <<use>> - aby zaimplementować klasę E_1
niezbędna jest klasa E_2
Relacje - asocjacje
 Asocjacja reprezentuje czasowe powiązanie między obiektami
dwóch klas
 Obiekty te jednak są od siebie niezależne.
 Ich czas życia może być różny.
 Asocjacja jest równorzędnym do atrybutu sposobem zapisu
cech klasy
Klasa asocjacyjna

 Zawiera informacje dotyczące samej

relacji asocjacji a nie przechowywane
przez żaden z połączonych obiektów
Asocjacja kwalifikowana

 Wskazuje konkretny atrybut danej klasy

zapewniający unikatowość relacji
 Atrybut ten jest jej kwalifikatorem
Relacje - agregacja

 Reprezentuje relację całość – część

 Część może należeć do kilku całości a
jej czas życia jest od nich niezależny
Relacje – kompozycja
(agregacja całkowita)

 Reprezentuje relację całość – część

 Część należy tylko do jednej całości a jej
czas życia jest od niej zależny. Jest jednym z
komponentów z których składa się całość
 Usunięcie klasy agregującej powoduje usunięcie
wszystkich jego części
Relacja - dziedziczenie

 Tworzy hierarchię klas

 Relacje wskazują klasę ogólną i klasy
bardziej szczegółowe
 Klasa abstrakcyjna –
dziedziczenie cech
Klasa abstrakcyjna nie posiada
własnych instancji - obiektów

Na diagramie oznaczana
Jest kursywą w nazwie
Klasy lub słowem {abstract}
Klasa abstrakcyjna –
dziedziczenie metod

Polimorfizm metod
Proces tworzenia diagramu
klas
 Zidentyfikowanie i nazwanie klas
 Połączenie klas z wykorzystaniem asocjacji
 Zidentyfikowanie i nazwanie atrybutów i operacji
 Określenie cech asocjacji (nazwa, role, nawigacja, liczebność,
agregacja, kwalifikacja)
 Opracowanie innych rodzajów związków (uogólnień -
dziedziczenie, zależności-agregacja, realizacji)
 Wyspecyfikowanie atrybutów i operacji według składni
 Dla uproszczenia na diagramie nie pokazujemy:
 metod służących do operowania na atrybutach (zwanych
żargonowo setterami i getterami)
 klas implementujących interfejs użytkownika oraz warstwy
dostępu do danych.
Interfejs – szczególny rodzaj
klas
 Klasa abstrakcyjnych
czysto wirtualnych
funkcji
 Wszystkie funkcje są
publiczne
 Interfejs nie może być
używany do tworzenia
obiektów
 Klasa nie posiada
danych
Role jako związki
Role w postaci klas i
kompozycji
Role jako klasy asocjacyjne
Diagram klas przykład–
telefonia komórkowa
Diagram obiektów
Powodzenia

 Teraz jesteś
gotowa/y do
rozwiązania
wejściówki

 Przyda się zastrzyk

z gorzkiej
czekolady 
http://www.redpill.com.pl/pl/art
ykuly/akademia
 Można się zastanawiać, czy w ogóle jest sens tworzyć model
dziedziny -- diagram z punktu widzenia implementacji
niekompletny. Czy nie jest to strata czasu? Czy nie lepiej od
razu narysować szczegółowy diagram projektowy? Jeśli
samodzielnie lub z kolegą tworzymy w miarę prosty program,
to rzeczywiście można od razu stworzyć docelowy projektowy
diagram klas. Jednak w dużych, komercyjnych projektach nie
bez powodu dzielimy prace na kilka faz, takich jak: analiza
biznesowa, analiza systemowa, projektowanie,
implementacja, testy i wdrożenie. Model dziedziny jest
elementem analizy systemowej, ukazującym biznesowe
struktury danych i zależności pomiędzy nimi. W dużych
projektach może on obejmować kilkaset klas. Decydując się
na jego stworzenie, nie pozwalamy, aby istotne decyzje
merytoryczne były podejmowane ad-hoc w trakcie
implementacji.
UML - Diagram aktywności

(ang. Activity diagram – ad)

Inaczej - Diagram czynności
Cel: Modelowanie procesów biznesowych,
scenariuszy,
przypadków użycia
lub algorytmów
Diagram klas
Diagram aktywności

 Diagram aktywności (czynności) - służy

do modelowania czynności i zakresu
odpowiedzialności elementów bądź
użytkowników systemu.
 Nie opisuje działań związanych z jednym
obiektem a wieloma, pomiędzy którymi
może występować komunikacja przy
wykonywaniu czynności.
Diagram aktywności/czynności

 (schematy blokowe) przedstawiają przepływ

sterowania od czynności do czynności
 większość diagramów czynności
przedstawia kroki procesu obliczeniowego
 łączą idee pochodzące z trzech źródeł:
 diagramów zdarzeń J.Odell'a,
 technik modelowania stanów,
 modelowania sieci Petriego.
DPU a diagram aktywności

 Przypadki użycia pokazują, co

powinien robić system
 Diagramy aktywności umożliwiają
określenie tego, w jaki sposób system
będzie osiągał swoje zamierzone cele
 Jakie akcje?
 Jak te akcje są połączone
Diagram aktywności/czynności
 Nie pokazuje wszystkich szczegółów przetwarzania.
 Prezentuje aktywności bez pokazywania bytów,
realizujących daną aktywność
 Jest punktem startowym dla procesu modelowania
zachowań
 Dla skompletowania projektu każda aktywność powinna być
zdekomponowana na szereg operacji (akcji/metod), z
których każdą trzeba będzie na późniejszym etapie
przydzielić do odpowiedniej klasy.
 Służy do:
 modelowanie przepływu czynności
 modelowanie operacji
Zastosowanie diagramów
aktywności / czynności

 Prezentacji
 wysoko poziomowych procesów biznesowych
 systemów oraz podsystemów
 scenariuszy przypadków użycia
 procesów systemowych charakteryzujących się
dużą liczbą równoległych czynności i sytuacji
decyzyjnych
 operacji
 algorytmów
Czynność vs. akcja
 Czynność:
 z perspektywy pojęciowej - to zadanie do wykonania i to
zarówno przez człowieka, jak i przez komputer
 z perspektywy projektu informatycznego - pojedyncza
metoda
 przejścia między stanami nie są związane z nadejściem
zdarzenia, ale z zakończeniem przetwarzania
wyspecyfikowanego dla danego stanu.
 Akcje są już niepodzielne, trwanie ich nie podlega
przerwaniu.
Czynność vs. akcja
 Czynności na diagramach mogą cechować się
rozbudowaną funkcjonalnością, tj. mogą
reprezentować niezwykle złożone procesy
biznesowe bądź algorytmy przetwarzania
 Dla osiągnięcia precyzyjnego ich opisu niezbędna
staje się dekompozycja czynności.
 Czynności mogą być i są zwykle dekomponowane
na zhierarchizowane podczynności
Diagram aktywności/czynności
 Zawartość:
 stany aktywności:
 stany czynności,
 przejścia,
 rozgałęzienia (branch) - decyzje,
 rozwidlanie (fork),
 scalanie (join),
 tory (swimlane),
 przepływ obiektów
 obiekty,
 notatki i ograniczenia.
Przykład diagramu aktywności
Znaczniki sterowania
 utworzenie znacznika
sterowania

 zniszczenie
wszystkich
znaczników
sterowania

 zniszczenie danego
znacznika sterowania
Decyzje

 Wyjście decyzji
stanowią dwa lub
więcej przepływów,
z których tylko
jeden może być
zrealizowany
Warunek logiczny
 kolejne warunki
muszą się wykluczać,
aby zapewnić
jednoznaczny
przepływ sterowania

 Rozgałęzienie
(decyzja)
Ścieżki współbieżne

 Rozwidlenie (1IN
– 2OUT, fork)

 Akcje współbieżne

 Scalenie
sterowania (2IN-
1OUT, join)
Przerywanie akcji
Złączenia

 Każdy przypływ
sterowania
docierający do
wejścia inicjuje
proces wyjściowy
Przykład

diagram aktywnosci -
logowanie.pdf
Pytania?

Dziękuję za uwagę

dr inż.Elżbieta Zamiar