Inżynieria oprogramowania

Przeznaczenie UML

UML – język znormalizowany służący do zapisywania
projektu systemu. Może być stosowany do obrazowania,
specyfikowania, tworzenia i dokumentowania budowy
systemu.
Nadaje się do modelowania rozmaitych systemów – od
systemów informacyjnych w przedsiębiorstwie, poprzez
oprogramowanie dla WWW, do systemów wbudowanych
czasu rzeczywistego.
To język stanowi zatem jedno z narzędzi używanych w
procesie tworzenia oprogramowania.
Proces projektowy powinien być ukierunkowany na przypadki
użycia, architekturocentryczny, iteracyjny i przyrostowy.

Gdzie można stosować

UML ?

UML jest przeznaczony przede wszystkim do
budowy systemów informatycznych.
Można modelować nie tylko oprogramowanie.
Z powodzeniem stosowano go już w:
tworzeniu systemów informacyjnych
przedsiębiorstw, usługach bankowych i
finansowych, telekomunikacji, transporcie,
przemyśle obronnym i lotniczym, sprzedaży
detalicznej, elektronice w medycynie, nauce,
rozproszonych usługach internetowych,...

Konsekwencje braku

obrazowania

Gdy nie ma modeli (tak naprawdę powstają one wówczas

w głowie programisty, serwetce, tablicy i są potem

bezpośrednio zapisywane w postaci kodu) komunikacja w

zespole jest nieprecyzyjna (chyba, że wszyscy w zespole

używają tego samego języka).
Niektórych aspektów systemu nie da się opanować bez

pomocy modeli (analizując kod wszystkich klas można

dostrzec znaczenie hierarchii, ale trudno zrozumieć jej

konsekwencje, trudno czytając wiersze oprogramowania

WWW nie można zrozumieć zasad rozproszenia obiektów).
Jeśli programista nie utrwalił budowanych (w jego głowie)

modeli lub gdy przenosi się do innej firmy modele można

odtworzyć tylko częściowo na podstawie implementacji.

Obrazowanie za pomocą

modeli

Modele wspomagają porozumiewanie się

między członkami zespołu programistycznego,

minimalizują problemy związane z komunikacją.
Modele pozwalają obrazować struktury, których

nie da się wygodnie przedstawić za pomocą

języka programowania (np. wspomniana

wcześniej wizualizacja hierarchii klas).
UML wiąże z symbolami graficznymi ściśle

określone znaczenia. Dzięki temu modele sę

jednoznacznie rozumiane przez innych

programistów, a nawet przez inne narzędzia.

Specyfikowanie

Oznacza tu opracowanie modeli, które
są precyzyjne, jednoznaczne i pełne.
W szczególności UML, wspomaga
specyfikowanie wszystkich ważnych
decyzji analitycznych, projektowych i
implementacyjnych, które muszą być
podejmowane ww trakcie wytwarzania
i wdrażania systemu informatycznego.

Tworzenie

UML nie jest językiem programowania graficznego, ale

modele w nim utworzone mogą być wprost powiązane z

wieloma językami programowania – łatwo przekształcić

model UML w kod języka programowania, czy tabelę

relacyjnej bazy danych. To co najlepiej wyrazić graficznie jest

przestawiane graficznie, to co łatwo przedstawić tekstowo

jest zapisywane językiem programowania.
UML umożliwia inżynierię do przodu – generowanie kodu na

podstawie modelu UML i inżynierię wstecz (odwrotnie, jednak

wymaga odpowiednich narzędzi i interwencji człowieka).
Niektóre środowiska UML umożliwiają nie tylko

przekształcanie modeli w kod, ale też ich wykonywanie,

symulację lub dostrajanie elementów wdrażanych systemów.

Dokumentacja

W skład dokumentacji oprogramowania powinny
wchodzić (mniej lub bardziej formalnie opracowane):

wymagania,
projekt,
plany

projektu,

prototypy,

architektura,
kod źródłowy,
testy,
kolejne

wersje.

Zwykle dokumentują kolejne etapy prac i

odgrywają istotną rolę w procesie

kontroli, oceny i przekazie informacji o

systemie - podczas tworzenia i po

wdrożeniu systemu.

Dokumentowanie

UML obejmuje dokumentowanie
architektury systemu i wszystkich
jego szczegółów. Składa się z:
języka do zapisu wymagań i testów;
języka modelowania czynności
wykonanych podczas planowania
danego przedsięwzięcia i
zarządzania wersjami systemu.

Rodzaje bloków

konstrukcyjnych

UML wyróżnia trzy rodzaje bloków

konstrukcyjnych:
elementy – są to podstawowe obiektowe
bloki konstrukcyjne UML, główne składniki
modelu;
związki – obrazują powiązania pomiędzy
elementami;
diagramy – służą do grupowania
istotnych elementów.

Elementy w UML

strukturalne – wyrażone rzeczownikami,

statyczne części modelu; reprezentują

składniki pojęciowe lub fizyczne (klasa,

interfejs, kooperacja, przypadek użycia,

klasa aktywna, komponent, węzeł)
czynnościowe (interakcja, maszyna

stanowa),
grupujące (pakiety),
komentujące (notatka).

Elementy strukturalne -

klasa

Klasa to opis zbioru obiektów,

które mają takie same

atrybuty, operacje, związki i

znaczenie.
Klasa realizuje jeden lub więcej

interfejsów.
Na diagramie jest

przedstawiana jako prostokąt,

który zwykle ma nazwę,

atrybuty i operacje.

Elementy strukturalne -

Interfejs

Interfejs to zestaw operacji, które
wyznaczają usługi oferowane przez klasę
lub komponent.
Interfejs definiuje zatem zewnętrzne
obserwowalne zachowania takiego
elementu. Określa zbiór deklaracji
(sygnatur) ale nigdy implementacji operacji.
Na diagramie jest przedstawiany jako okrąg
z nazwą interfejsu.
Rzadko występuje sam, zwykle jest
powiązany z realizującą go klasą lub
komponentem.

IPisownia

Elementy strukturalne -

kooperacja

Kooperacja definiuje interakcję. Jest to

zestaw ról i innych bytów,

współdziałających w celu wywołania

pewnego zespołowego zachowania

niemożliwego do osiągnięcia w

pojedynkę.
Pojedyncza klasa może brać udział w

wielu kooperacjach.
Kooperacje reprezentują więc

implementację wzorców, które składają

się na system.
Na diagramie przedstawiana jako elipsa

o przerywanej linii brzegowej, zazwyczaj

tylko z nazwą w środku.

Hierarchia

odpowiedzialności

Elementy strukturalne –

przypadek użycia

Przypadek użycia to opis zbioru

ciągów akcji wykonywanych przez

system w celu dostarczenia danemu

aktorowi godnego uwagi wyniku.
Służy do określenia w modelu

struktury zachowania systemu.
Jest urzeczywistniany przez

kooperację.
Graficzną reprezentacją przypadku

użycia jest elipsa o ciągłej linii

brzegowej zazwyczaj tylko z nazwą w

środku.

Wystaw

zamówienie

Elementy strukturalne –

klasa aktywna

Klasa aktywna zawiera obiekty, w

skład których wchodzi przynajmniej

jeden proces lub wątek.
Takie obiekty mogą samodzielnie

rozpocząć przepływ sterowania.
Jest podobna do zwykłej klasy, z tym,

że jej obiekty reprezentują elementy

działające równolegle z innymi.
Na diagramie jest przedstawiona tak

jak klasa z tym, że obramowanie

prostokąta jest pogrubione.

Elementy strukturalne -

komponent

Komponent to fizyczna, wymienna

część systemu, która wykorzystuje i

realizuje pewien zbiór interfejsów.
W każdym systemie można spotkać

wiele rodzajów wdrożonych

komponentów (COM+, Java Beans,

VCL), a także elementów będących

wynikiem procesu wytwarzania

(plików źródłowych).
Komponenty to fizyczne opakowanie

elementów logicznych takich jak

klasy, interfejsy i kooperacje.

Elementy strukturalne -

węzeł

Węzeł to fizyczny składnik
działającego systemu.
Reprezentuje zasoby
obliczeniowe. Ma zwykle
pewną ilość pamięci i
zdolność przetwarzania.
Zbiór komponentów może
się znajdować w węźle,a
czasem przemieszczać się
pomiędzy węzłami.

Serwer

Inne elementy

strukturalne

Istnieją pewne dodatkowe warianty

omówionych pojęć:

aktorzy, sygnały, klasy funkcji
usługowych (rodzaje klas)
procesy i wątki (rodzaje klas
aktywnych)
programy, dokumenty, pliki, biblioteki,
witryny, tabele (rodzaje komponentów)

Elementy czynnościowe

Stanowią dynamiczną część modelu
UML
Są wyrażone czasownikami
opisującymi zachowanie w czasie i
przestrzeni.
Istnieje dwa rodzaje takich elementów:

– Interakcja
– Stan

Elementy czynnościowe

- interakcja

Interakcja to zachowanie polegające na wymianie
komunikatów między obiektami w pewnym otoczeniu i w
pewnym celu.
Za pomocą interakcji można zdefiniować zachowanie
zespołu obiektów jak i pojedynczą operację.
Składa się z wielu innych bytów: Komunikatów, ciągów akcji
(odpowiedzi na komunikaty) i połączeń między obiektami
Przedstawiany na diagramie jako strzałka z nazwą operacji.

wyświetl

Elementy czynnościowe

– maszyna stanowa

Maszyna stanowa określa ciąg stanów, jakie

obiekt lub interakcja przyjmuje w odpowiedzi

na zdarzenia zachodzące w trakcie ich życia.
Określa też odpowiedź na te zdarzenia.
Za jej pomocą może być zdefiniowane

zachowanie poszczególnej klasy lub kooperacji.
Maszyna stanowa składa się z innych

elementów: stany, przejścia (między stanami),

zdarzenia (powodują przejścia) i czynności

(odpowiedzi na zdarzenia)
Graficzna reprezentacja stanu to prostokąt z

zaokrąglonymi rogami. Zazwyczaj zawiera

nazwę i podstany (jeśli istnieją)

Oczekiwanie

Elementy grupujące -

pakiet

Pakiet służy do grupowania elementów.
Może zawierać elementy strukturalne i czynnościowe, a
także inne elementy grupujące.
Jest jedynie bytem pojęciowym (nie istnieje fizycznie w
czasie wykonania programu)
Jest przedstawiany jako skoroszyt z fiszką z nazwą w
środku.
Istnieją inne elementy grupujące (różne rodzaje pakietów)

– zręby
– modele
– podsystemy

Elementy komentujące -

notatka

Odgrywają w UML rolę objaśniającą. Są to adnotacje,

których można użyć w celu opisania, uwypuklenia lub

zaznaczenia dodatkowych składników modelu.
Podstawowym rodzajem elementu tego typu jest

notatka. Jest to symbol umożliwiający skojarzenie

dodatkowych ograniczeń i objaśnień z pojedynczym

bytem lub grupą bytów.
Na diagramie jest przedstawiana jako prostokąt z

zagiętym rogiem, z komentarzem tekstowym lub

graficznym w środku.
Innym rodzajem elementu komentującego są

wymagania, - definiują zachowanie oczekiwane

przez otoczenie modelu.

Związki w UML

W UML są uwzględnione 4 rodzaje

związków:
zależność,
powiązanie,
uogólnienie,
realizacja.
Związki te są podstawowymi blokami

konstrukcyjnymi UML, służącymi do

łączenia elementów.

Zależność

Zależność to związek znaczeniowy

pomiędzy dwoma elementami.
Zmiany dokonane w definicji jednego

z tych elementów (niezależnego)

mogą mieć wpływ na znaczenie

drugiego z nich (zależnego).
Na diagramie związek ten jest

przedstawiany jako linia przerywana,

zazwyczaj z grotem i nazwą.

Powiązanie

Powiązanie to związek strukturalny, który określa
zbiór powiązań między obiektami.
Szczególnym przypadkiem powiązania jest
agregacja (składanie), które wyznacza więź między
całością a częściami.
Powiązanie jest przedstawiane na diagramie jako
linia ciągła, niekiedy z nazwą, ale częściej z
nazwami ról i oznaczeniem liczebności.

0..1

pracownik
pracodawca

Uogólnienie

Uogólnienie to związek pomiędzy dwoma bytami:
ogólnym (przodek) i szczegółowym (potomek),
czyli związek uogólnienie-uszczegółowienie.
Obiekt bytu szczegółowego może być używany w
zastępstwie obiektu bytu ogólnego. W takim
związku potomek ma strukturę i zachowanie
przodka.
Uogólnienie jest przedstawianie na diagramie jako
linia ciągła zakończona niewypełnionym grotem
wskazującym przodka związku.

Realizacja

Realizacja to związek znaczeniowy między

klasyfikatorami, z których jeden określa

kontrakt, a drugi zapewnia wywiązanie się z

niego.
Takie związki występują najczęściej między

interfejsami a klasami i komponentami oraz

miedzy przypadkami użycia a kooperacjami.
Na diagramie realizacja jest przedstawiana

jako kombinacja symboli uogólnienia i

zależności.

Diagramy w UML

Diagram to schemat przedstawiający zbiór bytów.
Najczęściej jest grafem, w którym wierzchołkami są

elementy, a krawędziami związki.
Będziesz rysować wiele diagramów, aby przedstawić

system z różnych punktów widzenia. Diagram to swego

rodzaju rzut systemu. Z wyjątkiem najbardziej banalnych

sytuacji daje jednak niepełny obraz bytów składających

się na system.
Ten sam byt może się pojawić na wszystkich diagramach,

tylko na niektórych (co się zdarza najczęściej) lub na

żadnym (przypadek wyjątkowy). Teoretycznie diagram

może zawierać dowolną kombinację elementów i

związków.

W praktyce jednak tylko

niektóre z kombinacji

odpowiadają pięciu

najbardziej użytecznym

perspektywom

architektonicznym

systemu

oprogramowania. Z

tego powodu w UML

wyróżnia się

następujących dziewięć

rodzajów diagramów:

1.  diagram klas,
2.  diagram obiektów,
3.   diagram  przypadków

użycia,

4.  diagram przebiegu,
5.  diagram kooperacji,
6.  diagram stanów,
7.  diagram czynności,
8.  diagram komponentów,
9.  diagram wdrożenia.

Diagram klas

Na diagramie klas mogą się znaleźć
klasy, interfejsy, kooperacje i związki
między nimi. Jest to najczęściej
spotykany diagram w modelach
obiektowych. Odnosi się do statycznych
aspektów perspektywy projektowej.
Diagram klas uwzględniający klasy
aktywne dotyczy statycznych aspektów
perspektywy procesowej.

Diagram obiektów

Na diagramie obiektów przedstawia

się obiekty i związki między nimi.

Diagram ten wyobraża statyczny zrzut

pewnych egzemplarzy elementów

występujących na diagramie klas.

Podobnie jak diagram klas, odnosi się

do statycznych aspektów perspektywy

projektowej lub procesowej. Korzystając

z niego, bierze się jednak pod uwagę

przypadki rzeczywiste lub prototypowe.

Diagram przypadków

użycia

Na diagramie przypadków użycia
przedstawia się przypadki użycia,
aktorów (specyficzny rodzaj klas) i
związki między nimi. Diagram ten
odnosi się do statycznych aspektów
perspektywy przypadków użycia.
Przydaje się zwłaszcza do wyznaczania
i modelowania zachowania systemu.

Diagram przebiegu i

diagram kooperacji

Diagram przebiegu i diagram kooperacji to

rodzaje diagramu interakcji, na którym

przedstawia się interakcję jako zbiór obiektów i

związków między nimi, w tym też komunikaty, jakie

obiekty przekazują między sobą. Diagram interakcji

odnosi się do modelowania dynamicznych

aspektów systemu. Diagram przebiegu obrazuje

kolejność przesyłania komunikatów w czasie. Na

diagramie kooperacji kładzie się nacisk na

organizację strukturalną obiektów wymieniających

komunikaty. Oba te diagramy są izomorficzne, to

znaczy można je przekształcać jeden w drugi.

Diagram stanów

Diagram stanów przedstawia maszynę

stanową składającą się ze stanów,

przejść, zdarzeń i czynności. Odnosi się

do modelowania dynamicznych

aspektów systemu. Jest szczególnie

przydatny w modelowaniu zachowania

interfejsów, klas i kooperacji.

Przedstawia reakcje obiektów na ciągi

zdarzeń i dlatego świetnie nadaje się do

projektowania systemów interakcyjnych.

Diagram czynności

Diagram czynności to szczególny
przypadek diagramu stanów, który
obrazuje strumień kolejno
wykonywanych czynności. Odnosi się
do modelowania dynamicznych
aspektów systemu. Jest bardzo
przydatny w modelowaniu funkcji
systemu. Kładzie się na nim nacisk na
przepływ sterowania między obiektami.

Diagram komponentów

Diagram komponentów obrazuje
uporządkowanie komponentów i
zależności między nimi. Odnosi się do
statycznych aspektów perspektywy
implementacyjnej. Ściśle wiąże się z
diagramem klas, ponieważ zwykle
każdemu komponentowi są
przyporządkowane pewne klasy,
interfejsy i kooperacje.

Diagram wdrożenia

Diagram wdrożenia obrazuje
konfigurację poszczególnych węzłów
działających w czasie wykonania i
zainstalowane na nich komponenty.
Odnosi się do statycznych aspektów
perspektywy wdrożeniowej. Wiąże się z
diagramem komponentów, ponieważ
zwykle każdy węzeł zawiera co
najmniej jeden komponent.

Reguły UML

Bloki konstrukcyjne UML nie mogą
być rozrzucone na chybił trafił. Jak w
każdym innym języku, tak w UML
obowiązują pewne reguły określające,
jak poprawny model ma wyglądać.
Poprawny model powinien być
wewnętrznie spójny oraz zgodny z
innymi powiązanymi z nim modelami.

Reguły znaczeniowe

W UML istnieją reguły znaczeniowe dotyczące:

nazw - jak nazywać elementy, związki i

diagramy;
zasięgu - jaki jest kontekst, który nadaje

nazwie specyficzne znaczenie;
widoczności - w jaki sposób nazwy mogą być

widziane i używane;
spójności - jak elementy są ze sobą logicznie

powiązane i czy są właściwe;
wykonywania - co oznacza działanie lub

symulowanie modelu dynamicznego.

Modele częściowe

Modele opracowywane podczas tworzenia systemu

informatycznego zwykle ewoluują, a podejście do nich zmienia się

oczywiście w miarę upływu czasu. Często więc zespół

programistyczny tworzy nie tylko poprawne modele.

Tworzy też modele:

 skrócone - pewne byty są ukryte, żeby wszystko było prostsze;
 niepełne - pewnych bytów może brakować;
 niespójne - spójność modelu nie jest zapewniona.

Trudno oczywiście ustrzec się przed opracowaniem nie całkiem

poprawnych modeli, ponieważ pewne szczegóły odkrywa się w

miarę tworzenia oprogramowania. Reguły UML ułatwiają jednak

rozważanie najważniejszych kwestii analitycznych, projektowych i

implementacyjnych, a co za tym idzie budowę poprawnych

modeli.

Podstawowe

mechanizmy językowe

UML

Jeśli budynek zaprojektowano zgodnie z powszechnie

przyjętymi wzorcami, to jego konstrukcja jest prostsza i

bardziej harmonijna. Styl budynku można określić jako

wiktoriański lub narodowy francuski przez porównanie go ze

wzorcami architektonicznymi tych stylów. To samo dotyczy

UML, który jest prostszy dzięki czterem podstawowym

mechanizmom, które są stosowane konsekwentnie w całym

języku. Chodzi tu o:

specyfikacje,
dodatki,
zasadnicze rozgraniczenia,
mechanizmy rozszerzania (wprowadzania nowych

konstrukcji).

Specyfikacje

Za każdym fragmentem graficznego zapisu kryje się
specyfikacja definiująca składnię i znaczenie bloku
konstrukcyjnego.
Ikona klasy reprezentuje specyfikację określającą zestaw
wszystkich atrybutów, operacji i funkcji, które ta klasa
może spełniać. Symbol klasy nie musi wyobrażać całej
specyfikacji, a tylko pewną niewielką jej część.
Co więcej, symbol tej samej klasy może przedstawiać
zupełnie inny zestaw jej składowych i będzie to całkowicie
poprawne. Notacja graficzna UML służy do zobrazowania
systemu, a specyfikacje do definiowania jego szczegółów.

Specyfikacje

Dzięki takiemu podziałowi można przystąpić do

przyrostowego konstruowania modelu - najpierw

narysować diagramy, a następnie dodać do nich

specyfikacje.Można także budować model od podstaw -

zacząć od utworzenia specyfikacji (np. za pomocą

inżynierii wstecz), a potem opracować diagramy

będące rzutami na ten zbiór specyfikacji.
Specyfikacje to znaczeniowa platforma UML, która

zawiera wszystkie części wszystkich modeli systemu,

logicznie ze sobą powiązane. Diagramy UML są zatem

po prostu graficznymi rzutami fragmentów tej

platformy, przy czym każdy diagram odsłania

specyficzny interesujący aspekt systemu.

Dodatki

Większość bytów UML ma jedyną i niezależną postać

graficzną, która oddaje najważniejsze ich aspekty.

Symbol klasy jest na przykład tak zaprojektowany,

aby można go było łatwo narysować, ponieważ jest

najczęściej

występującym

składnikiem

modeli

obiektowych. Ten symbol podkreśla najważniejsze

aspekty klasy, to znaczy nazwę, atrybuty i operacje.
Specyfikacja klasy może zawierać także inne

szczegóły, takie jak informacje o abstrakcyjności

klasy lub widoczności poszczególnych atrybutów i

operacji. Wiele z nich może być umieszczonych na

diagramach jako graficzne lub tekstowe uzupełnienia

prostokątnego symbolu klasy.

Dodatki

Na rysunku widać przykład klasy z dodatkami

wskazującymi, że jest to klasa abstrakcyjna z czterema

operacjami: dwiema publicznymi, jedną chronioną i jedną

prywatną.

Każdy element notacji UML składa się z symbolu

podstawowego i rozmaitych charakterystycznych dla

niego dodatków.

Zasadnicze rozgraniczenia

W modelowaniu systemów obiektowych

świat jest podzielony na co najmniej kilka

sposobów.
Po pierwsze, rozróżnia się klasę i obiekt.

Klasa jest abstrakcją, a obiekt jest jednym

konkretnym urzeczywistnieniem tej abstrakcji. W

UML można modelować zarówno klasy, jak i obiekty.
Na rysunku przedstawiono klasę o nazwie Klient i

trzy obiekty: Jan (jawnie przypisany do klasy

Klient, :Klient (anonimowy obiekt klasy Klient) i Eliza

(w swojej specyfikacji określony jako rodzaj Klienta,

choć nie jest to jawnie pokazane na diagramie).

Zasadnicze rozgraniczenia

Prawie z każdym blokiem konstrukcyjnym UML jest związana

podobna dychotomia (jak dla klasa-obiekt). Można mieć

przypadki użycia i egzemplarze przypadków użycia,

komponenty i ich egzemplarze, węzły i ich egzemplarze.
Graficznie symbol obiektu różni się od symbolu klasy tego

obiektu jedynie tym, że nazwa obiektu jest podkreślona linią

ciągłą.
Po drugie, rozróżnia się interfejs i implementację. Interfejs to

deklaracja kontraktu, a implementacja to jedna z wielu

konkretnych realizacji tego kontraktu. Wszystko musi

przebiegać zgodnie ze znaczeniem interfejsu. W UML można

modelować zarówno interfejsy, jak i ich implementacje

Mechanizmy rozszerzania

Język UML zapewnia standardowe środki wyrazu

przydatne do zapisywania projektu systemu. Należy

jednak pamiętać, że nie ma tak uniwersalnego języka, w

którym dałoby się wyrazić wszystkie możliwe niuanse

każdego modelu dowolnego systemu w każdej dziedzinie

zastosowania i w każdym czasie.
Z tego właśnie powodu UML jest językiem otwartym.

Można go rozszerzać, ale w kontrolowany sposób.

Dostępne są następujące trzy mechanizmy rozszerzania.

stereotypy,
metki,
ograniczenia.

Stereotyp

Umożliwia

rozszerzanie

słownictwa

UML.

Możesz

tworzyć

nowe

bloki

konstrukcyjne,

wywodzące

się

tych

już

istniejących,

ale

specyficzne

dla danego zadania.
Jeśli na przykład programujesz w języku C++ lub Java, to z

pewnością chcesz uwzględnić w modelu wyjątki. W tych

językach są one klasami, choć traktowanymi w szczególny

sposób.
Zwykle chcesz , by wyjątki były jedynie zgłaszane i obsługiwane.

Możesz więc sprawić, by stały się w Twoich modelach

obywatelami pierwszej kategorii (będą wtedy traktowane jak

standardowe bloki konstrukcyjne). Musisz jedynie oznakować je

odpowiednim stereotypem, tak jak zrobiliśmy to z klasą

Przepełnienie na rysunku.

Metka

Umożliwia

rozszerzanie

listy

właściwości

bloku

konstrukcyjnego UML. Możesz dodać nowe informacje

do specyfikacji takiego bloku.
Jeśli na przykład zajmujesz się tworzeniem produktów

masowych, które wychodzą w wielu wersjach, to chcesz

z pewnością uwzględnić informacje o tych wersjach i

autorach pewnych istotnych abstrakcji. Informacje te

(wersja i autor) nie są elementarnymi pojęciami UML.
Można je dodać w postaci metki do dowolnego bloku

konstrukcyjnego (np. do klasy). Na rysunku (poprzedni

slajd) widać klasę KolejkaZdarzeń z jawnie podanym

autorem i wersją.

Ograniczenie

Umożliwia rozszerzanie znaczenia bloku
konstrukcyjnego UML. Możesz dodać nowe
reguły lub zmodyfikować już istniejące.
Możesz na przykład wprowadzić ograniczenie,
że dodawanie zdarzeń do egzemplarzy klasy
KolejkaZdarzeń odbywa się z zachowaniem
porządku.
Na rysunku (dwa slajdy wcześniej) widać, że
ograniczenie bezpośrednio wiąże się z operacją
dodaj.

Mechanizmy rozszerzania -

podsumowanie

trzy

mechanizmy

rozszerzania

ułatwiają

ukształtowanie i dopasowanie UML do potrzeb

konkretnego zadania.
Umożliwiają także dostosowanie go do nowych

technologii, takich jak na przykład coraz lepsze

języki programowania systemów rozproszonych.
Można

dodawać

nowe

bloki

konstrukcyjne,

modyfikować specyfikacje już istniejących, a nawet

zmieniać ich znaczenie, ale trzeba nad tym

procesem panować. Chodzi o to, by pamiętać,

że

UML

służy

przede

wszystkim

przekazywania informacji.

Planowanie architektury

systemu

Obrazowanie, specyfikowanie, tworzenie i dokumentowanie

systemu informatycznego wymaga podejścia do niego z

kilku punktów widzenia.
Różni uczestnicy danego przedsięwzięcia (użytkownicy,

analitycy, programiści, specjaliści od integracji systemu,

osoby wykonujące testy, autorzy dokumentacji technicznej i

kierownicy projektu) wnoszą doń co innego. Każdy patrzy na

zadanie z innej perspektywy i na innym etapie jego życia.
Architektura systemu to prawdopodobnie najważniejszy

artefakt, jaki może być wykorzystany do zapanowania nad

tymi

wszystkimi

punktami

widzenia.

Umożliwia

kontrolowanie iteracyjnego i przyrostowego procesu

tworzenia systemu.

Architektura

Architektura to zbiór znaczących decyzji dotyczących:

organizacji systemu komputerowego,
wyboru  elementów  strukturalnych  i  ich  interfejsów,  z
których system jest zbudowany,
zachowania tych elementów, opisanego w kooperacjach,
składania elementów strukturalnych i czynnościowych w
coraz większe podsystemy,
stylu  architektonicznego,  według  którego  tworzy  się
konstrukcję  systemu,  to  znaczy  charakterystycznych
elementów  statycznych  i  dynamicznych  oraz  ich
interfejsów, kooperacji i składania.

Modelowanie

architektury systemu

Architektura oprogramowania dotyczy nie tylko jego struktury

i zachowania, ale także stosowania go, jego funkcjonalności,

efektywności, odporności, możliwości ponownego użycia,

ograniczeń ekonomicznych i technologicznych oraz estetyki.
Na rysunku pokazano

sposób zobrazowania

architektury systemu

komputerowego – z

pięciu powiązanych ze

sobą perspektyw.

Każda z nich dotyczy

organizacji i struktury

systemu, ale w każdej

z nich kładzie się nacisk na pewien ustalony aspekt systemu.

Perspektywa przypadków

W  perspektywie  przypadków  użycia  bierze  się
pod  uwagę  zachowanie  systemu  widziane  oczyma
użytkowników,  analityków  i  osób  wykonujących
testy.
Nie definiuje się rzeczywistej organizacji systemu, a
opisuje  się  czynniki  wpływające  na  kształt
architektury systemu.
W  UML  aspekty  statyczne  tej  perspektywy  wyraża
się  za  pomocą  diagramów  przypadków  użycia,  a
dynamiczne  za  pomocą  diagramów  interakcji,
diagramów stanów i diagramów czynności.

Perspektywa projektowa

W perspektywie projektowej kładzie się nacisk

na klasy, interfejsy i kooperacje, które razem

składają się na słownictwo danego zadania i na

rozwiązanie tego zadania.
Perspektywa ta pomaga w zapisywaniu wymagań

funkcjonalnych, czyli usług, które system powinien

udostępniać swoim użytkownikom.
W UML aspekty statyczne tej perspektywy wyraża

się za pomocą diagramów klas i diagramów

obiektów, a dynamiczne za pomocą diagramów

interakcji,

diagramów

stanów

diagramów

czynności.

Perspektywa procesowa

W perspektywie procesowej zwraca się

uwagę na wątki i procesy, które kształtują

mechanizmy współbieżności i synchronizacji w

systemie.
Dotyczy

ona

głównie

efektywności,

skalowalności i przepustowości systemu.
W UML aspekty statyczne i dynamiczne tej

perspektywy są przedstawiane na takich samych

rodzajach

diagramów

jak

wypadku

perspektywy projektowej, z tą tylko różnicą, że

główny nacisk kładzie się na klasy aktywne,

które reprezentują procesy i wątki.

Perspektywie

implementacyjna

W perspektywie implementacyjnej znaczenie

mają komponenty i pliki, użyte do scalenia i

udostępnienia systemu fizycznego.
Wiąże się ona z zarządzaniem konfiguracją

poszczególnych wersji systemu, złożonych z

rozmaitych niezależnych komponentów i plików,

które można zespolić na wiele sposobów, aby

otrzymać działający system.
W UML aspekty statyczne tej perspektywy wyraża

się za pomocą diagramów komponentów, a

dynamiczne za pomocą diagramów interakcji,

diagramów stanów i diagramów czynności.

Perspektywa wdrożeniowa

W  perspektywie  wdrożeniowej  kładzie  się
nacisk  na  węzły,  składające  się  na  sprzęt,  na
którym system będzie uruchamiany
Wiąże  się  ona  głównie  z  rozmieszczeniem,
dostarczeniem  i  instalacją  części  systemu
fizycznego.
W  UML  aspekty  statyczne  tej  perspektywy
wyraża  się  za  pomocą  diagramów  wdrożenia,  a
dynamiczne  za  pomocą  diagramów  interakcji,
diagramów stanów i diagramów czynności.

Architektura –

podsumowanie

Każda z tych pięciu perspektyw jest autonomiczna.
Poszczególni

uczestnicy

przedsięwzięcia

programistycznego mogą skoncentrować się na tym

fragmencie architektury systemu, który ich najbardziej

interesuje.
Perspektywy ściśle się ze sobą wiążą. Węzły w

perspektywie wdrożeniowej zawierają komponenty z

perspektywy

implementacyjnej,

które

kolei

reprezentują fizyczną realizację klas, interfejsów,

kooperacji i klas aktywnych z perspektywy projektowej i

procesowej.
UML umożliwia zatem wyrażenie każdej z tych

perspektyw i ich wzajemnych oddziaływań.

Cykl tworzenia

oprogramowania

UML jest w zasadzie niezależny od przyjętych

procedur projektowych, co oznacza, że nie jest

dostosowany do jakiegokolwiek szczególnego

cyklu tworzenia oprogramowania. Przynosi

jednak największe korzyści w procesie, który

jest:

ukierunkowany

przypadki

użycia

systemu,

architekturocentryczny,
iteracyjny i przyrostowy.

Cykl tworzenia

oprogramowania

W procesie ukierunkowanym na przypadki

użycia systemu, to właśnie one służą do określania

pożądanego zachowania systemu, do weryfikacji i

atestowania jego architektury oraz do testowania

go.
Są także wykorzystywane w porozumiewaniu się

członków zespołu programistycznego między sobą.
W procesie architekturocentrycznym właśnie

architektura

jest

najważniejszym

artefaktem

używanym do wyrażenia koncepcji tworzonego

systemu, konstruowania go, zarządzania nim i do

rozwijania go.

Cykl tworzenia

oprogramowania

Plonem procesu iteracyjnego jest ciąg kolejnych

działających wersji systemu.
Proces przyrostowy polega na systematycznym

dopełnianiu architektury systemu w celu utworzenia

tych wersji, przy czym każda z nich zawiera pewne

nowe składniki i ulepszenia, które nie występują w

wersji poprzedniej.
Proces

iteracyjny

przyrostowy

zarazem

jest

jednocześnie procesem

sterowanym ryzykiem,

ponieważ przy tworzeniu każdej nowej wersji kładzie się

nacisk na wyeliminowanie czynników, które najbardziej

zagrażają powodzeniu danego przedsięwzięcia.

Etapy

Proces ukierunkowany na przypadki użycia systemu,

architekturocentryczny, iteracyjny i przyrostowy można

podzielić na etapy.
Etap to okres między kolejnymi głównymi kamieniami

milowymi procesu, w którym zostały osiągnięte pewne

ściśle ustalone cele, przedstawiono ukończone produkty

pracy i podjęto decyzje o przejściu do następnego etapu.
Na rysunku (następny slajd) widać cztery etapy cyklu

tworzenia oprogramowania: rozpoczęcie, opracowanie,

budowę i przekazanie.
Zadania są wymienione w pionie, a etapy - w poziomie.

Są też uwzględnione natężenia prac nad poszczególnymi

zadaniami.

Etapy

Rozpoczęcie to pierwszy etap procesu. Polega na

sformułowaniu i weryfikacji podstawowych założeń

danego przedsięwzięcia w takim co najmniej stopniu,

aby można było przejść do etapu opracowania.
Opracowanie to drugi etap procesu, podczas którego

powstaje wizja produktu i definicja jego architektury.

Zostają też sformułowane i utrwalone wymagania

systemowe. Określa się także priorytet każdego z nich.

Wymagania mogą być podane bardzo ogólnie lub

bardzo precyzyjnie, jako kryteria obowiązujące przy

określaniu

szczególnego

funkcjonalnego

lub

niefunkcjonalnego zachowania i stanowiące podstawę

do przyszłych testów.

Etapy

Budowa to trzeci etap procesu. Na gotowych fundamentach

architektonicznych powstaje oprogramowanie, które można

przekazać użytkownikom. Podobnie jak w poprzednim

etapie, wymagania, a zwłaszcza kryteria ich spełniania, są

systematycznie

ponownie

sprawdzane

pod

kątem

rzeczywistych

potrzeb

przedsiębiorstwa

danym

przedsięwzięciu. Przydziela się także środki wystarczające

do zwalczania wszelkich zagrożeń.
Przekazanie to czwarty etap procesu. Oprogramowanie

jest przekazywane do rąk użytkowników. Bardzo rzadko

oznacza to zakończenie procesu, ponieważ nawet w tym

etapie system jest stale ulepszany. Usuwa się błędy oraz

dodaje ulepszenia, które nie występowały w poprzednich

wersjach.

Iteracje

Elementem, który występuje we wszystkich czterech

etapach, jest iteracja - oddzielny zbiór czynności z

precyzyjnie określonym planem i kryteriami oceny.
Wynikiem iteracji jest nowa wersja systemu, która

może być przeznaczona do użytku wewnętrznego

lub zewnętrznego.
Oznacza to, że taki cykl tworzenia oprogramowania

polega na ciągłym budowaniu nowych wersji

architektury systemu. To przywiązywanie tak

wielkiego znaczenia do architektury powoduje, że w

UML kładzie się nacisk na modelowanie rozmaitych

perspektyw architektonicznych.

Document Outline