Inżynieria
oprogramowania
Wykład II. Poznajemy UML
Politechnika Radomska
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.
Model pojęciowy języka
Od niego rozpoczniemy naukę.
Składa się z trzech podstawowych
składników:
bloków konstrukcyjnych;
reguł określających sposób
łączenia bloków;
mechanizmów językowych.
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.
Inne rodzaje związków
Istnieją także inne rodzaje bloków
reprezentujących związki:
udoskonalenie
ślad
zawieranie
i rozszerzenie (rodzaje 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
Zasadnicze rozgraniczenia
Na rysunku widać jeden
komponent korektorPisowni.dll,
który jest implementacją dwóch
interfejsów: lUnknown i IPisownia.
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ę
z
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
Te
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
do
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
i
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
w
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
z
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
na
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
i
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
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
w
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.