Inżynieria Oprogramowania

Język modelowania UML

• UML

(ang. Unified Modeling Language)

jest graficznym językiem

do:

• specyfikowania
• obrazowania
• tworzenia
• dokumentowania

elementów (artefaktów) systemów oprogramowania

• UML jest ‘językiem' do specyfikowania a nie metodą czy procedurą

– UML stosuje się do zdefiniowania systemu oprogramowania; do

uszczegółowienia artefaktów tego systemu, do jego udokumentowania i

skonstruowania

• to jest język w którym pisze się „blueprint” systemu

– UML można użyć na wiele sposobów wspierając określone metodologie

tworzenia oprogramowania (taką jak Rational Unified Process)

• Ale sam w sobie nie specyfikuje takiej metodologii czy procesu

Elementy składowe

• Podstawowymi elementami składowymi UML są:

– elementy modelu (klasy, interfejsy, komponenty,

przypadki użycia, itp.)

– związki (asocjacje, generalizacje, zależności, itp.)
– diagramy (diagramy klas, diagramy przypadków użycia,

diagramy interakcji, itp.)

• Proste elementy składowe pozwalają składać się

w duże, złożone struktury

• UML definiuje także mechanizmy rozszerzenia

– Aby sprostać różnym specjalizowanym potrzebom (na

przykład rozszerzenia modelowania procesów
biznesowych - Business Process Modeling).

Historia UML

• Przez wiele lat głównymi konkurującymi

metodologiami obiektowego

programowania były

• Rumbaugh’s Object Modeling Technique

(OMT)

• Booch’s metodologia O-O, oraz
• Jacobsen’s metodologia Objectory(OOSE)

• UML scala notacje z tych trzech w jeden

zunifikowany model obiektowy

• UML stał się standardem dla obiektowo

zorientowanej analizy i projektowania

przez Object Management Group (OMG)

• UML 2.0 jest dostępny w:

www.omg.org

Składniki UML

• W skład UML wchodzą :

– Składniki modelu

– Relacje (wiążące składniki

modelu ze sobą)

– Diagramy

• grupują określone składniki

– Graficznie prezentują

zestawy elementów

• najczęściej w formie

schematów

Klasa Stan Węzeł
Przypadek
użycia

Zależności Generalizacje Inne

Język UML – opis notacji

• Model interakcji użytkownika (

Model przypadków użycia

)

– Zakres oraz interakcja między systemem a użytkownikami

• Koresponduje w pewnym zakresie z modelem wymagań

• Model interakcji lub komunikacji

– jak obiekty systemu oddziałują wzajemnie dla wykonania zadania

• Model stanów (

Model dynamiczny

)

– stany lub warunki jakie klasy przyjmują z biegiem czasu

• Wykresy aktywności opisują workflow zaimplementowany w systemie

• Model logiczny (

Model klas

)

– opisuje klasy i objekty wchodzące w skład systemu

• Model fizyczny (

Model elementów

)

– opisuje oprogramowanie (czasem sprzęt) tworzące system

• Model wdrożenia

– fizyczna architektura i wdrożenie elementów architektury

sprzętowej

Model przypadków użycia

• Opisuje proponowaną funkcjonalność nowego

systemu

– Przypadek użycia jest dyskretną jednostkową interakcją

pomiędzy użytkownikiem (człowiekiem lub maszyną) a
systemem

• Ta interakcja będzie elementem realnego zadania takiego jak

Załóż konto lub Przeglądaj szczegółową informację.

• Spojrzenie na system z punktu widzenia zachowań

widzianych przez użytkowników

• Każdy przypadek użycia opisuje określoną

funkcjonalność wchodzącą do proponowanego
systemu

– która może włączyć funkcjonalność innego przypadku użycia

lub rozciągnąć inny przypadek użycia na swoje zachowanie

Zastosowania przypadków użycia

• modelowanie zachowania bytów

- opis

ciągu akcji zmierzających do realizacji
danej funkcji systemu,

• modelowanie otoczenia systemu

definiowanie aktorów i ich ról,

• modelowanie wymagań stawianych

systemowi

- określenie co system

powinien robić,

• testowanie systemu

Przypadki użycia

• Funkcje:

• zdefiniowanie zachowania się

systemu,

• wypracowanie porozumienia

między

programistami

użytkownikami

ekspertami

• weryfikacja architektury

systemu w czasie jego

budowania (

testowanie

regresywne

• zdefiniowanie

kooperacji

realizujących określone

funkcje (kooperacją może być

pojedynczy przypadek użycia).

• Cechy:

• zbiór ciągów akcji

opisujących

interakcję elementów z otoczenia

systemu

• (aktorów) z samym systemem,

– aktor

- człowiek lub

zautomatyzowany system,

• przypadki użycia mogą mieć

ogólne lub bardziej szczegółowe

warianty,

– dany przypadek użycia może być

podzbiorem większego przypadku

użycia,

• opisują co system robi, ale NIE

jak to robi

– mogą pojawiać się alternatywne

ciągi akcji.

Opisy przypadku użycia

•

Ogólne uwagi i adnotacje opisujące dany przypadek użycia

•

Wymagania takie jak

–

<możność aktualizacji zlecenia>,<możność modyfikacji zlecenia>,
itp.

•

Ograniczenia

–

Reguły określające co można i co nie można. Przykłady:

•

<wystaw zlecenie> musi poprzedzać <modyfikuj zlecenie>;

•

<zlecenie zostało zmodyfikowane i jest koherentne>;

•

zamówienie musi zawsze mieć numer klienta

•

Scenariusze

–

Sekwencyjny opis kroków potrzebnych do realizacji danego
przypadku.

•

Diagramy scenariuszy

–

Diagramy sekwencji obrazujące workflow

•

Dodatkowe atrybuty jak faza implementacji, numer wersji, ocena
złożoności, stereotypy lub status

Scenariusze

• Formalne wyszczególnienie kroków, które

trzeba wykonać realizując dany przypadek
użycia, lub bieg zdarzeń w danej instancji
przypadku użycia.

– Mogą one obejmować wiele scenariuszy dla

opisania szczególnych okoliczności i
alternatywne sposoby rozwiązania.

• Scenariusze są zazwyczaj prezentowane w

formie tekstu i odpowiadają tekstowemu
przedstawieniu diagramu sekwencji

Diagramy przypadków użycia

• Służą do modelowania funkcjonalności

systemu

–

są „spisem treści” wymagań funkcjonalnych;

• Są stosowane do modelowania sekwencji

działań wykonywanych przez system,

które przynoszą określone rezultaty

komuś lub czemuś spoza systemu;

• Wykorzystując prostą graficznie notację

–

są zrozumiałe dla użytkownika

Modelowanie wymagań

•

Zdefiniowanie co system ma robić (

określenie

wszystkich funkcjonalności systemu

)

•

Modelowanie obejmuje również wymagania
niefunkcjonalne

–

realizowane przez sam system

–

nie realizowane przez aktorów, korzystających z
systemu.

•

Etapy modelowania:

1. zdefiniowanie aktorów,
2. zdefiniowanie i uporządkowanie przypadków użycia

realizowanych przez aktorów (funkcjonalności),

3. zdefiniowanie przypadków użycia realizowanych

przez system (czynności niefunkcjonalnych).

Rola przypadków użycia

• Dostarczyć bardziej funkcjonalne

spojrzenie na system
oprogramowania

– funkcje, aktorzy
– granice
– odczytywalne przez klienta/użytkownika

• Zwykle definiowane przed

diagramami klas

Perspektywa przypadków użycia

• Przypadki użycia

– Zachowania systemu z

punktu widzenia

• Użytkowników
• Analityków
• Osób wykonujących

testy

– Aspekty statyczne

• diagramy przypadków

użycia,

– Aspekty dynamiczne

• diagramy interakcji
• diagramy stanów
• diagramy czynności

• Notacja

– Przypadek użycia

– Aktor

– Interakcja

– Blok ponownego

użycia

– Relacja «include»

lub «extend»

– Nazwa systemu

• wraz z

otoczeniem

wypłata

pienięd

klient

weryfikac

klienta

include

System obsługi

klienta

wnętrze systemu

Podstawowe pojęcia - aktor

• Ktoś lub coś spoza systemu,

wchodzący w interakcję z systemem.

• Aktor może zlecić systemowi

zadanie i/lub współdziałać z
systemem w czasie jego realizacji.

• Aktor musi posiadać unikatową

nazwę.

• Aktor – jest pewną klasą obiektów,

związaną z pełnieniem określonej
roli.

<<aktor>>

Podstawowe pojęcia -

przypadek użycia

• Reprezentuje sekwencję akcji

realizowanych przez system,

w efekcie których do aktora

dostarczane są obserwowalne

rezultaty.

• Sekwencja akcji występuje w

odpowiedzi na interakcję

aktora z systemem.

• Przypadek użycia musi

posiadać unikatową nazwę,

która powinna określać cel

zaistnienia przypadku.

Przypadki użycia: zależności

• Zależność zawierania

(inkluzja)

–

Jeden przypadek użycia może
włączyć funkcjonalność innego

–

Włączony przypadek będzie
wołany zawsze, gdy główna
ścieżka jest egzekwowana

• Zależność rozszerzania

(ekstensja)

–

Jeden przypadek użycia można
rozciągnąć na zachowanie się
innego

–

Przykład: przypadek użycia
<uzyskaj aprobatę> można
opcjonalnie rozciągnąć na
przypadek <zmień zlecenie>

klient
banku

wpłata

pieniędzy

wypłata

pieniędzy

kasjer

sprawdź

stan konta

weź

pożyczkę

zarząd

banku

include

uaktualnianie

stanu konta

include

extend

Zależność zawierania: przykład

Sprawdzenie salda
rachunku

Wypłata

Wpłata

<<include>>

Bankomat

<<actor
>>

System

bankowy

Klient

Zależność rozszerzania: przykład

Wydruk
potwierdzeni
a

Wypłata

Wpłata

<<extend>>

Bankomat

Klient

Generalizacja aktorów

• Generalizacja aktorów

– ustala hierarchię dziedziczenia

dostępu do funkcji systemu

• Aktor wyspecjalizowany

może zrobić to co
ogólniejszy

– co więcej – ma swój własny,

specyficzny sposób korzystania
z systemu.

Generalizacja przypadków

• Generalizacja przypadków: potomny przypadek

dziedziczy wszystkie atrybuty, ciągi zachowań i
punkty rozszerzenia przypadku macierzystego.
Bierze także udział we wszystkich jego związkach.

Operacja bankowa

Wpłata

Wypłata

Polecenie przelewu

Diagramy interakcji

• Podzbiór diagramów zachowania które

zajmują się interakcjami obiektu.

• Obejmują one:

– Diagramy sekwencji
– Diagramy komunikacji
– Diagramy czasu
– Diagramy przeglądu interakcji

• Diagramy interakcji używa się gdy chcemy

modelować zachowanie się szeregu obiektów
w przypadku użycia

Diagramy sekwencji

• Pokazują kolejność interakcji w scenariuszu

– Aktorzy i komponenty
– Wysyłane komunikaty, zapętlenia

• Użyteczne dla uchwycenia i łatwej wizualizacji

czasowych właściwości scenariusza

• Diagramy sekwencji

– Wzbogacają przypadki użycia
– Dają obraz dynamicznego zachowania się klas

• Jedna pionowa linia przypadająca na obiekt lub na

aktora

– Czas biegnie z góry na dół
– Strzałki przedstawiają komunikaty przesyłane między

obiektami

Użycie diagramów sekwencji

• Diagramy te stosuje się do projektowania,

dokumentacji i walidacji architektury, interfejsów i
logiki systemu

– opisując sekwencję akcji które należy podjąć dla wykonania

zadania czy też scenariusza

• Są one także wykorzystywane jako narzędzia inżynierii

systemów

– do projektowania architektury systemu,

• Także w inżynierii procesów biznesowych jako

– Diagramy przepływu procesu,
– Grafy sekwencji komunikatów i przepływu połączeń przy

projektowaniu systemów telekomunikacyjnych czy
bezprzewodowych

• Dla analizy i projektowania stosu protokołów

Symbole nagłówka diagramu

• Aktor

– Reprezentuje zewnętrzną osobę lub

urządzenie interacts with the system

• Obiekt

– Reprezentuje obiekt w systemie lub jeden

z jego komponentów

• Unit

– Reprezentuje podsystem, komponent, unit,

lub inny element logiczny w systemie

• Separator

– Reprezentuje interfejs lub granicę między

podsystemami, komponentami lub unitami

• interfejs bezprzewodowy, Internet, sieć

• Grupa

– Pogrupowanie elementów nagłówka w

podsystemy lub komponenty

Symbole treści diagramu -1

• Akcja

– Reprezentuje akcję podjętą przez aktora,

obiekt lub unit

• Asynchroniczny komunikat

– pomiędzy elementami nagłówka

• Blok

– Blok reprezentuje pętlę lub uwarunkowanie

dla określonego elementu nagłówka

• Komunikat wywołania

– Komunikat wywołania (procedury) między

elementami nagłówka

• Komunikat kreowania

– Komunikat „kreuj" który kreuje element

nagłówka (reprezentowany przez lifeline
going from dashed to solid pattern)

Symbole treści diagramu - 2

• Destrukcja elementu

– Reprezentuje destrukcję elementu nagłówka

• Komunikat destrukcji

– Reprezentuje destrukcję elementu nagłówka jako

wynik wywołania z innego elementu

• Link diagramu

– Reprezentuje część diagramu traktowaną jako

blok funkcjonalny

• Opcjonalnie może reprezentować link do innego

diagramu.

• Blok „Else”

– Reprezentuje część "else" w diagramie bloku

• Nota do przepływu

– Notatka dokumentacyjna przypisana automatycznie do

przepływu po poprzedzającym elemencie

• Swobodna nota

– Notatka dokumentacyjna która może być umieszczona

gdziekolwiek w diagramie

Symbole treści diagramu - 3

• Komunikat

– Prosty komunikat między elementami nagłówka

• Przerwa strony
• Komunikat zwrotny - między elementami

nagłówka

• Start scenariusza
• Przypadek scenariusza

– Start alternatywy lub przypadku w scenariuszu

• Koniec scenariusza
• Stan - Zmiana stanu dla elementu nagłówka
• Ustalony stan - w systemie
• Start timera

– Start timera dla danego elementu najłówka

• Stop timera

– Zatrzymanie timera dla danego elementu najłówka

• Upłynięcie timera

– Upłynięcie czasu dla danego elementu nagłówka

Przykład diagramu sekwencji

• Graficzne zobrazowanie interakcji obiektów w czasie

– Zwykle pokazują użytkownika (aktora), oraz obiekty i komponenty z

którymi mają interakcję

Komunikaty przekazywane między obiektami staną się operacjami klas w końcowym modelu

Obszary zastosowań

• Złożone interakcje pomiędzy komponentami

– Zwłaszcza gdy komponenty są tworzone równolegle przez

różne zespoły

• Rozwinięcie przypadków użycia

– Diagramy sekwencji opisują spodziewane zachowanie się

systemu

• Rozproszone oraz internetowe systemy

– dla dokumentowania i walidacji architektury, interfejsów i logiki

komponentów składowych

• Złożona logika

– Przez pokazanie interakcji między różnymi obiektami Maszyny

stanowe

– Telekomunikacyjne, bezprzewodowe i wbudowane systemy

szeroko stosują projektowanie oparte na maszynach stanowych

Kartkówka

•

•

•

•

•

•

•

• Temat Nr. 29

W grupach proszę opracować tematy ćwiczeń do wyboru:

Proszę podzielić pracę między uczestników grupy,
aby przedstawić jak najpełniejszą dokumentację.
Zbiorowo proszę ocenić poziom opracowania części
składowych opracowania.

Diagramy komunikacji

• Diagramy te opisują interakcje między obiektami w

postaci sekwencji komunikatów

• Diagramy komunikacji

biorą informację z

diagramów klas, sekwencji, oraz przypadków

użycia

– opisując zarówno statyczną strukturę i dynamiczne

zachowania w systemie

• Pokazują obiekty i ich związki z innymi obiektami

systemu oprócz tego jak oddziaływają nawzajem

• Związki między obiektami nie są widoczne w

diagramach sekwencji

– Zaawansowane narzędzie modelowania może z łatwością

przekształcić diagram komunikacji w diagram sekwencji i

na odwrót

Przepływ komunikatów

•

Przeciwnie do diagramów sekwencji, diagramy
komunikacji nie odnotowują bezpośrednio czasu

– W to miejsce numerują komunikaty w kolejności ich

egzekucji

•

Diagramy komunikacji pokazują przepływ
komunikatów pomiędzy obiektami w obiektowo-
zorientowanej aplikacji

– ponadto podają podstawowe związki (relacje) między

klasami

•

Diagramy komunikacji tworzy się w ten sam sposób
jak

diagramy sekwencji

– Jedyną istotną różnicą jest notacja robiona w inny sposób

Symbole diagramu komunikacji

Obiekt: współdziała z innymi
obiektami w systemie. Przedstawia
prostokąt zaopatrzony w nazwę

obiektu w środku, poprzedzoną
dwukropkiem i podkreśloną.
Relacja/Asocjacja: link łączący

skojarzone obiekty. Kwalifikatory
mogą znajdować się po obu stronach
asocjacji dla pokazania liczności
Komunikaty: Strzałka wskazująca
na docelowy obiekt pokazuje
interakcje pomiędzy obiektami.

Liczba reprezentuje kolejność
/sekwencję tej interakcji.

Diagramy czasu

• Używa się ich do analizy zachowania się jednego

lub więcej obiektów w danym okresie czasu.

• Rozróżnia się dwie podstawowe odmiany

diagramów czasu (harmonogramowania):

– Notacja zwięzła
– Notacja silna.

• Diagramy czasu

często używa się w

projektowaniu programów wbudowanych

(embedded)

– Takich jak oprogramowanie sterujące wtryskiem paliwa w

silnikach samochodowych,

– Niekiedy używa się je również w programach biznesowych

Pojęcia diagramu czasu

• Diagram harmonogramowania reprezentuje na osi

czasu zmiany dopuszczalnych stanów, jakie może

przyjmować instancja klasyfikatora uczestnicząca

w interakcji

• Podstawowe kategorie pojęciowe

– Klasyfikator

• Pojęcie klasyfikatora związane jest z bytem stanowiącym

opis własności zbioru wystąpień (instancji).

– nazwa stanu - typowe stany takie jak:

• bezczynność,,,
• wykonywanie,
• obliczanie.

– linia zmiany stanów instancji klasyfikatora

• Może przedstawiać stany instancji klasyfikatora lub

określonej, mierzalnej zmiennej

Przykłady harmonogramów

• Diagram

harmonogramowania dla
obiektu klasy Rezerwacja

• Diagram

harmonogramowania ze
zdarzeniami i
ograniczeniami
czasowymi

• Alternatywna notacja

diagramów
harmonogramowania

Diagramy przeglądu interakcji

• Diagram przeglądu interakcji jest pewną formą

diagramu aktywności, w którym węzły są diagramami
interakcji.

– Diagramy interakcji mogą obejmować diagramy sekwencji,

komunikacji, przeglądu interakcji oraz harmonogramowania

• Większość notacji w diagramach przeglądu interakcji

jest taka sama jak w diagramach aktywności

– Na przykład, start, koniec, romb decyzyjny, węzły

rozwidlenia i złączenia są takie same.

• Dwa nowe składniki notacji:

– Występowanie interakcji
– Elementy interakcji

Diagramy stanów

• Diagramy stanów używa się dla opisu

zachowania się systemu

– Opisują one wszystkie możliwe stany obiektu w

następstwie zdarzeń

– Każdy diagram reprezentuje zwykle obiekty jednej

klasy i śledzi różne stany tych obiektów w systemie

• Można użyć diagramy stanu dla

zademonstrowania zachowania się obiektu w

obrębie wielu przypadków użycia w systemie.

– Diagramy stanów stosuje sie nie dla wszystkich klas
– Nie są one też użyteczne dla opisu kolaboracji

wszystkich obiektów zawartych w przypadku użycia

• Stosowany do pokazania przejść lub zmian

stanu jakie obiekt może mieć w systemie

Elementy diagramu stanów

• Podstawowe elementy to są:

– Zaokrąglone prostokąty

reprezentujące stan obiektu

– Strzałki wskazujące przejście do

następnego stanu.

• Diagramy stanów zazwyczaj

pokazują start i koniec

– Wszystkie diagramy stanów

pokazują początkowy stan
obiektu

• Stan w chwili kreowania obiektu

– Wychodząc z początkowego

stanu obiekt zaczyna zmieniać
stan

Symbole diagramu stanów

• Stan początkowy

– Pokazuje punkt startowy

• Stan:

– Reprezentuje stan obiektu w danej chwili

• Przejście: Strzałka wskazująca przejście

obiektu z jednego stanu do drugiego

• Zdarzenie i akcja : trigger powodujący

przejście w następstwie zdarzenia lub akcji

• Signal: Komunikat może być wysłany do

stanu wywołującego przejście; ten
komunikat nazywa sie signal.
Reprezentowany jako klasa z ikoną
<<Signal>> ponad opisem akcja/zdarzenie

• Final State: The end of the state diagram

Przykład: Zamówienie

Gdy obiekt wejdzie do stanu
Sprawdzanie wykonuje czynność
„sprawdź magazyn." Po wykonaniu
tej czynności obiekt przechodzi do
następnego stanu zależnie od
sytuacji [mamy wszystkie pozycje]
lub [brak jednej pozycji].
Gdy brak jest towaru zamówienie
zostaje anulowane. Gdy są
wszystkie zamawiane towary
zamówienie kieruje się do
ekspedycji (Wysyłka) i wykonuje
się czynność. „zainicjuj wysyłkę".
Po wykonaniu tej czynności obiekt
przechodzi do stanu Dostawa.

Diagram aktywności

• Odmiana diagramu stanów

obrazująca strumień kolejno
wykonywanych czynności

– przedstawia sekwencyjne

lub współbieżne kroki
procesu obliczeniowego

• Pokazuje jak są zbudowane

workflows w systemie

– Możliwość wielu ścieżek

decyzyjnych

– Gdzie można się spodziewać

równoległego wykonywania
czynności

Diagramy aktywności

• Diagramy te opisują stan czynności

przez pokazanie sekwencji

wykonanych czynności

– Diagramy aktywności mogą pokazywać

czynności które są warunkowe lub

równoległe.

• Diagramy aktywności nie pokazują

jednakowoż szczegółów jak obiekty

się zachowują lub jak obiekty

kooperują ze sobą

• Diagramy te czyta się z góry na dół

– Mają one odgałęzienia i rozwidlenia

definiujące warunki oraz czynności

równoległe

– Rozwidlenie stosuje się, gdy kilka

czynności mogą mieć miejsce w tym

samym czasie

Symbole diagramu aktywności

• Początek

– Pokazuje punkt startowy

• Aktywność:

Czynność do

wykonania

• Przejście: Strzałka wskazująca

kierunek

• Romb decyzyjny: badanie warunku
• Fork:

– Rozwidlenie na kilka operacji.

• Join:

– złączenie kilku operacji

• Koniec: Punkt końcowy diagramu

Aktywnosc

Diagram klas

• Diagram klas pokazuję części składowe

obiektowo-zorientowanego systemu

– Jest to przedstawienie statycznego widoku modelu, lub

części modelu opisujące jego atrybuty i zachowanie

• Bardziej niż uszczegółowiając metody dla wykonania

operacji

• Diagramy klas są najbardziej użyteczne w

ilustrowaniu relacji między klasami oraz

interfejsami

• Generalizacje, agregacje i asocjacje są wielce

pożyteczne w zakresie dziedziczenia, kompozycji

lub użycia, a także połączeń.

Model logiczny

• Statyczne przedstawienie klas i

obiektów tworzących przestrzeń

projektowania/analizy

• Model domeny

– Zgrubne przedstawienie obiektów i

podmiotów biznesowych

• Model klasy

– Ścisły projektowo zorientowany model

– Klasa jest typową konstrukcją UML

• klasa jest specyfikacją
• obiekt jest instancją klasy

• możliwość dziedziczenia
• zawieta stan (atrybuty)
• manipuluje nimi (zachowanie)

– Dobry obiektowo-zorientowany projekt

ogranicza bezpośredni dostęp do

atrybutów klas

• Opis zbioru

obiektów

–

Nazwy proste lub

ścieżkowe

–

Z atrybutami lub

bez

–

Z operacjami lub

bez

• Asocjacja
• Agregacja
• Generalizacja
• Zgrupowanie

elementów modelu

–

możliwa

enkapsulacja

–

powtórne użycie.

• Komentarz

tekstowy

Klasy

• Klasa jest elementem, który

definiuje atrybuty i zachowania

jakie obiekt może mieć

• Zachowanie się jest opisane przez

komunikaty, które klasa rozumie,

wraz z operacjami właściwymi dla

każdego komunikatu

• Klasy mogą też zawierać definicje

ograniczeń, wartości znaczników i

stereotypów.

• Klasy są przedstawiane jako

prostokąty pokazujące nazwę klasy

i opcjonalnie nazwy atrybutów i

operacji

– Oddzielne pola rozdzielają nazwy klas,

atrybutów i operacji.

Obiekty

• Obiektem jest jakaś osoba, miejsce,

rzecz, koncept, zdarzenie, ekran, lub

raport odnoszący się do danego

systemu

• Obiekty zarówno wiedzą o rzeczach

(mają atrybuty) jak też robią pewne

rzeczy (mają metody)

• Klasa jest reprezentacją obiektu,

czymś w rodzaju szablonu według

którego tworzy się obiekty.

– Jedna klasa nazwana Student będzie

reprezentować całe zbiorowisko studentów

• Obiekt jest konkretnym

urzeczywistnieniem klasy

Przykładowe diagramy

Proste asocjacje

•

Asocjacje istnieją między
obiektami, reprezentują one
trwałe zależności

•

Operacje mogą ustalać/
przerywać asocjacje między
obiektami

Jednokierunkowa
nawigacja między
klasami

Określenie ról
w asocjacjach

Symbole diagramu klas - 1

• Klasy
• Aktywna klasa

– inicjuje i kontroluje bieg czynności
– pasywne klasy przechowuję dane i wspomagają

inne klasy

• Widzialność

– Prywatna widzialność ukrywa informację przed

wszystkimi na zewnątrz danej klasy

– Publiczna widzialność pozwala wszystkim klasom

widzieć zaznaczoną informację

– Chroniona widzialność udostępnia informację klas

dzieci którą dziedziczą od klasy rodzica

• Asocjacje

– Nazwę asocjacji umieszcza się w sąsiedztwie linii

asocjacji

• Wypełniony grot wskazuje kierunek relacji

– Odgrywane role zaznacza się przy końcach asocjacji

• Role reprezentują sposób w jaki dwie klasy widzą się

nawzajem

Symbole diagramu klas - 2

• Liczność

– Notację liczności umieszcza sie przy

końcach asocjacji

• Symbole te zaznaczają liczbę instancji jednej

klasy linked to jednej instancji drugiej klasy

• Ograniczenie

– Umieszcza się wewnątrz nawiasów

klamrowych {}

Proste ograniczenie

• Kompozycja i agregacja

– Kompozycja jest odmianą agregacji

cechującą się silnym posiadaniem Klasy A,

całości i Klasy B, jej części

• Kompozycję oznacza się wypełnionym

rombem

– Przy agregacji „cała" klasa odgrywa

ważniejszą rolę, lecz te dwie klasy nie są od

siebie zależne

• Prostą agregację oznacza się pustym rombem

Symbole diagramu klas - 3

• Generalizacja

– Jest to inna nazwa dziedziczenia.

• Odnosi się to do relacji między

dwoma klasami gdy jedna klasa jest
specjalizowaną wersją drugiej.

• Pakiety

– Używa się foldera z zakładką do

pokazania pakietu.

• Nazwę pakietu wpisuje się do

zakładki lub do wnętrza foldera.

• Podobnie jak w klasach można w

pakiecie umieścić listę atrybutów

• Zależności

– Zależność określa taką relację w

której zmiany w jednym pakiecie
będą wpływać na inny pakiet

• Import jest typem zależności dającą

jednemu pakietowi dostęp do
zawartości drugiego

Agregacja i generalizacja

Agregacja

• Jest to specjalizacja asocjacji

• Cechuje się zależnością

‘części’ (lub ‘posiada') między

obiektami odnośnych klas

Generalizacja

• Zależność między klasą a jej

bardziej szczegółowymi wersjami

• Subklasy dziedziczą wszystkie

właściwości superklasy

Model narzędzia raportowania

błędów oprogramowania

Powiązania

Nawigacja

Numer

Klasa

Dziedziczenie

Subklasa

Agregacja

Artefakt

Projekt

Pracownik

Kierownik

Projekta
nt

Kierowany przez

Na temat

Raport błędu

kodowania

Raport

problemu

Wpis do

historii

Log historii

odpowiedzialny za

przydzielony dla

nazwisko: String

nazwa: String

nazwa: String
status: ArtStEnum

id: Int
description: text
priorytet: PriEnum
status: ProbEnum
bugRp: String

kiedy: Date
coZrobiono: text

plikSrc: String
plikDtech: Strin

Źródło: University of Virginia

Perspektywa logiczna

Diagramy obiektów

• Diagramy obiektów modelują instancje

klas

– Ten typ diagramu używa się dla opisu systemu

w konkretnym momencie czasu.

– Z punktu widzenia notacji, diagramy obiektów

pożyczają elementy z diagramów klas

• Wiele diagramów obiektów używa tylko

– Obiekty

• Obiekty są przedstawiane umieszczając nazwę

instancji po której jest dwukropek (:) przed
nazwą klasy.

• Wartości atrybutów zapisuje się parą

"nazwa=wartość"

– Asocjacje – między obiektami

Diagramy komponentów i wdrażania

• Komponenty

– Fizyczne moduły kodu
– Reprezentują klasy

• Poszczególne realizacje komponentów sa instancjami

tych komponentów

• Węzły

– Dostępne zasoby: stacja robocza, drukarka, serwer, sieć

itp

• Zależności rezydowania, użycia lub wdrożenia
• Asocjacje komunikacyjne

– Powiązania między węzłami

Diagram komponentów

• Diagram komponentów opisuje organizację

fizycznych komponentów w systemie

• Komponenty zarówno oferują jak i używają

interfejsów

– interfejs stanowi definicję zbioru jednej lub więcej metod, i

zero lub więcej atrybutów

• Ten diagram pokazuje zależności między

komponentami, w tym komponenty kodu
źródłowego, komponenty kodu binarnego, oraz
komponenty wykonywalne

– Pewne komponenty mają miejsce w czasie kompilacji, w

czasie łączenia, w czasie wykonywania.

Diagram komponentów UML 2

• W UML 2 komponent jest traktowany

jako specjalizowana wersja konceptu
klasy

– Interfesy mogą być układane pionowo

• <<provided interfaces>> – oferowane
• <<required interfaces>> - żądane

– Stereotypem komponentu jest

<<component>>

• Alternatywna notacja używa

graficznych symboli interfejsów

• Poniżej pokazano trzy możliwe symbole

komponentu używane w UML 2

Wewnętrzna struktura komponentu

• Czasem ma sens pokazanie wewnętrznej struktury komponentu

– Komponent Store oferuje interfejs OrderEntry oraz potrzebuje interfejs Account

• Interfejsy te mają kwadracik na brzegu komponentu zwany port (bramka)

– Komponent Store składa się z trzech komponentów: Order, Customer, Product

• Port OrderEntry deleguje do obliczeń interfejs OrderEntry komponentu Order
• Żądany interfejs Account komponentu Customer jest delegowany do portu Account w Store

Diagramy wdrożenia

• Diagramy wdrożenia obrazują fizyczne zasoby

systemu

– węzły, komponenty i połączenia

• Diagram wdrożenia przedstawia konfigurację

elementów czasu wykonywania

– Komponenty oprogramowania, procesy, oraz ich obiekty
– Instancje komponentów oprogramowania przedstawiają

przejaw czasu wykonywania jednostek kodu

• Obejmuje to modelowanie konfiguracji

sprzętowych wraz z ich komponentami
oprogramowania

Symbole diagramu wdrożenia

• Węzeł

– Węzeł reprezentuję element sprzętowy w

systemie

• Węzeł przedstawia się jako trójwymiarowy sześcian

• Komponent

– Komponent reprezentuje element

oprogramowania w systemie, taki jak pliki jodu
źródłowego, programy, dokumenty, oraz pliki
zasobów

• W diagramie wdrożenia, określenia miejsca ich

wdrożenia

• Komponent przedstawia się jako prostokąt z

dworna prostokątami sterczącymi z lewej strony,

• Asocjacja

– Asocjacja oznacza linię komunikacji pomiędzy

elementami sprzętowymi

• Rysuje się jako ciągłą linię między dwoma węzłami.

Przykład: Diagram wdrożenia

• Węzeł CustomerComputer ma dwa

komponenty:

– WebBrowser połączony do interfejsu

komponentu Apache httpd węzła
WebServer

– JavaApplet połaczony przez SSL do

interfejsu w JavaServlet węzła
WebBrowser

– Węzły połączone są przez TCP/IP

• Węzeł DatabaseServer ma

komponent MySQL

– Interfejs JDBC jest połączony przez

SSL z komponentem JavaServer
węzła WebBowser

– Węzły połączone są przez TCP/IP

Diagramy komponentów i

wdrożenia: przykład

•

Pakiet Interfejs użytkownika

wykorzystuje pakiet Narzędzia

oraz interfejs iPrzetwarzanie

biznesowe, udostępniony przez

podsystem Przetwarzanie

biznesowe

•

Pakiety Interfejs użytkownika

oraz podsystemy Przetwarzanie

biznesowe i Dane rezydują w

komponencie Interfejs

użytkownika.

•

Podsystem Przetwarzanie

biznesowe używa pakietu

Narzędzia i wykorzystuje

interfejsy iProdukt oraz

iSurowiec udostępnione przez

podsystem Dane

•

Komponent Interfejs

użytkownika jest wdrożony w

węźle Kierownik projektu

•

Węzeł Kierownik projektu jest

połączony z węzłem Archiwum

dokumentacji

Document Outline