72
Inżynieria
oprogramowania
www.sdjournal.org
Software Developer’s Journal 08/2007
UML – modelowanie statycznych
aspektów oprogramowania
B
ędąc świadomym wymagań stawianych sys-
temowi informatycznemu, kolejnym krokiem
jest zaprojektowanie sposobu realizacji tych-
że wymagań. W tym celu buduje się modele pre-
zentujące statyczne i dynamiczne aspekty oprogra-
mowania. Modele te budowane są w kontekście re-
alizacji poszczególnych przypadków użycia. Mode-
le dynamiki systemu przedstawiają wszelkie możli-
we ścieżki realizacji każdego wymagania funkcjonal-
nego (przypadku użycia). Analiza diagramów mode-
lujących dynamikę uwzględniająca wymagania nie-
funkcjonalne, prowadzi do zbudowania statycznego
modelu oprogramowania. W artykule przedstawio-
ne zostaną diagramy UML wykorzystywane do opisu
struktury oprogramowania.
Diagramy klas
Diagram klas jest ściśle powiązany z projekto-
waniem obiektowym systemów informatycznych.
Opisuje wyróżnione w systemie klasy obiektów
i statyczne powiązania między nimi. Zawiera on
również takie elementy jak atrybuty i operacje
klas oraz ograniczenia nakładane na klasy obiek-
tów i ich powiązania. Modelując statyczne aspek-
ty perspektywy projektowej, diagramów klas uży-
wa się do:
• Modelowanie słownictwa systemu. Zadanie to
polega między innymi na podejmowaniu decyzji,
które abstrakcje są częścią rozważanego syste-
mu, a które nie i jakie zobowiązania ma każda z
tych abstrakcji.
• Modelowanie prostych kooperacji. Kooperacja
jest to zestaw klas, interfejsów i innych bytów
istniejących celem realizacji pewnego zespo-
łowego zachowania wymagającego współpra-
cy wszystkich elementów. Nie należy skupiać
się nad jedną klasą, lecz nad zbiorem współ-
pracujących ze sobą klas, by zrozumieć, o co
chodzi. W tym wypadku diagramy klas wyko-
rzystuje się do zobrazowania i określenia tego
zbioru klas i związków między nimi.
• Modelowanie schematu logicznej bazy da-
nych. Przez schemat rozumiany jest plan
projektu koncepcyjnego bazy danych. W wie-
lu dziedzinach zachodzi potrzeba trwałe-
go przechowywania informacji w bazach da-
nych. W tym wypadku diagram klas wykorzy-
stuje się do modelowania schematów takich
baz danych.
Diagramy komponentów
Komponenty, w odróżnieniu od bytów koncep-
cyjnych jakimi są np. klasy, to elementy oprogra-
mowania istniejące w systemie komputerowym
i będące fizyczną realizacją zamysłu projektan-
ta oprogramowania. Należy tu uchwycić subtelną
granicę rozciągłości definicji klasy w stosunku do
definicji komponentu, tzn. najważniejszym wyróż-
nikiem odmienności tych dwóch pojęć jest to, iż
klasa jest abstrakcyjnym przedstawieniem zbioru
atrybutów i operacji, podczas gdy komponent jest
fizyczną częścią systemu.
Analizując zagadnienie projektowania realnych
fragmentów oprogramowania (komponentów) moż-
na dojść do wniosku, że szczególny nacisk powinien
zostać położony na możliwość wyizolowania kompo-
nentu i jego wielokrotnego użycia. Zadanie to uła-
twiają dobrze zdefiniowane interfejsy, które są jedy-
ną drogą przez którą dostępne są operacje kompo-
nentu - zupełnie jak w przypadku klas - relację tego
typu nazywamy realizacją. Nie można pominąć zna-
czenia interfejsu jako swego rodzaju "okna na świat"
dla komponentu, co warunkuje możliwości jego wy-
miany i wielokrotnego wykorzystania. Należy w tym
miejscu dodać, że w specyfikacji UML 2.0 wyróżnio-
ne zostały dwa typy interfejsów. Jeżeli komponent
udostępnia jakieś usługi w postaci interfejsu to mó-
wimy wówczas o tzw. interfejsie dostarczanym, udo-
stępnianym lub eksportowanym (ang. provided inter-
face). Może jednak zajść przypadek, że komponent,
aby w pełni realizować swoje usługi, potrzebuje sko-
rzystać z usług innych komponentów, co obrazuje
się za pomocą interfejsu wymaganego, importowa-
nym (ang. required interface). Wyróżniamy 3 podsta-
wowe rodzaje komponentów:
• wdrożenia - są podstawą oprogramowania wyko-
nywalnego
• COM+, JavaBeans, EJB, biblioteki DLL, pliki
wykonywalne EXE, ...
• procesu wytwórczego – komponenty będące ar-
tefaktami powstałymi w procesie wytwarzania, na
ich podstawie generuje się komponenty wdrożenia
Rafał Kasprzyk
Autor jest absolwentem Wydziału Cybernetyki WAT,
gdzie od 2 lat zajmuje stanowisko asystenta w Instytu-
cie Systemów Informatycznych. Pracuje w firmie ISO-
LUTION będąc odpowiedzialnym za przygotowywa-
nie, prowadzenie i audyt szkoleń obejmujących analizę
i projektowanie systemów informatycznych z użyciem
notacji UML.
Kontakt z autorem: rafal.kasprzyk@wat.edu.pl
UML – modelowanie statycznych aspektów oprogramowania
73
www.sdjournal.org
Software Developer’s Journal 08/2007
Rysunek 2.
Przykładowy diagram komponentów
������������������
��������
������������������
�����������
������������������
�������������
����������
����������
����������
��������������
�����������
�������
����������
�������
��������������
��������������
�����������
�����������
����
�������
����������
�������
��������������
�����������
��������
����������
��������
��������������
�����������
������
������������������
������
����������������������
����������
• schemat logiczny bazy danych, skrypty SQL, pliki z ko-
dem źródłowym,
• komponenty wykonania – tworzone jako rezultat działania
systemu
• wydruki, raporty.
W końcu dochodzimy do definicji diagramu komponentów,
który zawiera komponenty, interfejsy oraz ich wzajemne
związki. Elementy te są ze sobą luźno powiązane najczęściej
za pomocą zależności i realizacji.
Diagramy wdrożenia
Diagram wdrożenia, obok diagramu komponentów to jeden
z dwóch rodzajów diagramów przedstawiających fizyczne
aspekty systemów. Jego zadaniem jest zobrazowanie kon-
figuracji węzłów w czasie wykonania, na których rozmiesz-
Rysunek 1.
Przykładowy diagram klas
�������
�����������������
����������������������
�����������������������
��������������
����������������������
���������������������
���������������������������
�����������������������������������
����������
�����������������������
������������������������������
�������������������������
���������
�����������������
��������������������
��������������
����������������������
���������������
����������������������������
�������
�������������
��������������
���������������������
������������������������
�������������������������
�����������������
�����������������������
�
�
����
����
��������
��
���������������
����
����
����
����
���������
74
Inżynieria
oprogramowania
www.sdjournal.org
Software Developer’s Journal 08/2007
czone będą komponenty. Komponenty reprezentują fizycz-
ne (programowe – ang. software), wymienne części syste-
mu, które realizują elementy logiczne, podczas gdy węzły
to fizyczne (sprzętowe – ang. hardware) składnik systemu
na których wdrożone zostają komponenty. Najczęściej ma-
my do czynienia z sytuacją w której diagramy komponentów
„umieszczane” są na diagramach wdrożenia, aby pokazać,
które komponenty działają na których węzłach. Węzły dzie-
lone są na:
• procesowy – reprezentują zasoby obliczeniowe
• posiadają pewną ilość pamięci i zdolność przetwa-
rzania,
• mogą wykonywać kod komponentu
• urządzenia – są interfejsem do świata zewnętrznego
• nie mają zdolności przetwarzania (np. monitor, dru-
karka)
Diagramy wdrożenia są szczególnie przydatne dla projek-
tantów systemów, których sposób funkcjonowania zale-
ży równie silnie od oprogramowania wchodzącego w skład
systemu, jak i sprzętu, na którym to oprogramowanie ma
działać. Pozwalają na zobrazowanie infrastruktury wymaga-
nej przez system.
Można wyróżnić trzy zasadnicze typy systemów, przy mo-
delowaniu których warto wykorzystać diagramy wdrożenia:
systemy wbudowane, systemy typu klient-serwer oraz syste-
my rozproszone.
Istotną nowością, która została wprowadzona w specyfi-
kacji UML 2.0, jest dodanie elementu będącego specyfikacją
wdrożenia. Element ten odpowiada za opis parametrów po-
trzebnych do wdrożenia komponentu na danym węźle, co ma
na celu parametryzację relacji pomiędzy różnymi programo-
wymi i sprzętowymi technologiami. Specyfikacja wdrożenia
jest obrazowana za pomocą stereotypu
Ciekawym elementem jest również tzw. środowisko wy-
konania. Element ten reprezentuje wybrany rodzaj platformy i
jest obrazowany za pomocą stereotypu
Diagramy obiektów
Diagramy obiektów przedstawiają hierarchię obiektów i ich
wzajemne powiązania w danej chwili. Jako że przedstawia-
ją instancje klas, a nie same klasy - nazywane są też diagra-
mami instancji. Na diagramach obiektów umieszczamy spe-
cyfikacje instancji, a nie same instancje. Rozwiązanie takie
umożliwia nienadawanie wartości obowiązkowym atrybu-
tom lub też obrazowanie specyfikacji instancji klas abstrak-
cyjnych.
Diagramy obiektów podobne są do diagramów komunika-
cji, jednakże te pierwsze służą do zobrazowania struktury in-
Rysunek 3.
Przykładowy diagram wdrożenia
����������
����������
���������
�����������
������������
����������������������
������������
������������
�������������
�����������
�����������������
����������
�������������������
�����������
��������������
����������
���������
�����������
����������
�����������������
�����������������
�������
�������
����������������
�����������������
������
��������
�������������������
������������
�������������
������������������
�����������
�����������
�������������������
�������
��������
���������������
Bibliografia
• Marin Fowler UML Distilled: A Brief Guide To The Standard Ob-
ject Modeling Language, 3rd ed., Addison-Weslay Professional,
2004;
• Grady Booch, James Rumbaugh, Ivar Jacobson, Unified Mo-
deling Language User Guide, 2nd ed., Addison-Weslay Pro-
fessional, 2005;
• Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania
obiektowego, Helion, 2005;
• http://www.holub.com/goodies/uml/;
• http://www.agilemodeling.com/essays/umlDiagrams.htm.
UML – modelowanie statycznych aspektów oprogramowania
75
www.sdjournal.org
Software Developer’s Journal 08/2007
stancji, diagramy komunikacji natomiast do pokazania ich za-
chowań.
Diagramy struktur złożonych
Diagramy struktur złożonych służą do hierarchicznego opi-
sywania skomplikowanych obiektów. Pozwala to na zajęcie
się skomplikowanym elementem i podzielenie go na części.
Struktury złożone są podobne do pakietów. Aby uświadomić
sobie podstawową różnicę najlepiej myśleć o pakietach ja-
ko o sposobie grupowania elementów w czasie kompilacji,
podczas gdy struktury złożone grupują elementy w czasie
wykonania programu.
Diagramy struktury swoją notację i zakres stosowa-
nia wywodzą głównie z modeli systemów czasu rzeczywi-
stego, gdzie stosowane jest pojęcie tzw. kapsuły, która re-
prezentuje wyraźnie wydzielony i hermetyczny wątek ste-
rowania systemu. Całkowita izolacja kapsuły (w obu kie-
runkach) od jej otoczenia możliwa jest dzięki portom, które
pełnią rolę obiektów granicznych (interfejsów). Interesują-
cy jest fakt, że diagramy struktury mogą obrazować aspekt
statyczny i dynamiczny modelowanego systemów, co sta-
nowi o ich osobliwości. Najczęściej mamy do czynienia z
przypadkiem, w którym diagramy struktury ilustrują de-
kompozycję wskazującą z jakich części składa się kapsu-
ła i w jakie interfejsy jest ona zaopatrzona. Istnieje jednak
druga forma diagramów struktury umożliwiająca przedsta-
wienie komunikacji, jaka zachodzi pomiędzy wewnętrzny-
mi elementami kapsuły. Taka forma prezentacji diagramów
struktury została nazwana w UML 2.0 diagramem współ-
pracy. Należy pamiętać, że gdy diagram struktury przyjmu-
je pierwszą formę to można użyć na nim portów i interfej-
sów. Prezentując natomiast zbiór współpracujących ze so-
bą elementów składowych kapsuły nie można wykorzysty-
wać portów i interfejsów, ale należy skorzystać ze stereo-
typowych zależności: <<role binding>>, <<represents>>,
<<occurrence>>
Ponieważ struktury złożone są nowością, to trudno stwier-
dzić, jak przydatne okażą się w praktyce.
Diagramy pakietów
Pakiet jest konstrukcją pozwalającą organizować elementy
modelu np. klasy, w logiczne grupy. Natomiast diagram pakie-
tów to diagram składający się z pakietów i zależności między
nimi. Pakiety z reguły tworzy się, aby:
• W przejrzysty sposób zobrazować zależności pomiędzy
poszczególnymi elementami modelu.
• Efektywniej organizować kod źródłowy.
• Zaznaczyć podobieństwa i różnice pomiędzy poszczegól-
nymi elementami modelu.
Na diagramie pakietów wszelkie elementy modelu (klasy, in-
terfejsy, kooperacje, komponenty) grupowane są w pakie-
ty i/lub podpakiety zgodnie z poziomami zawierania. War-
to tworzyć tego typu diagramy dążąc do tego, aby elemen-
ty modelu połączone relacjami asocjacji, agregacji, czy to
kompozycji umieszczone były w jednym pakiecie. Z regu-
ły naturalnym jest, by w pakiecie umieszczać elementy mo-
delu, które w jakikolwiek sposób od siebie zależą. Diagramy
pakietów można także stosować w celu grupowania przy-
padków użycia. Ogólne zasady tworzenia diagramów pakie-
tów są bardzo proste:
• Zawsze nadawaj pakietom proste, opisowe nazwy
• Stosuj pakiety do upraszczania struktury diagramów
• Stosuj stereotypy by zaznaczyć warstwy architektury pro-
gramu
• Zależności między pakietami powinny odzwierciedlać fak-
tyczne wewnętrzne relacje w programie
• Pakiety powinna charakteryzować wysoka zwartość i ni-
skie sprzężenie.
Podsumowanie
Modelując elementy statyczne rozwiązania dążymy do uzy-
skania takiej struktury oprogramowania, która będzie umoż-
liwiała realizację wymagań funkcjonalnych przy spełnieniu
wymagań niefunkcjonalnych. W tej perspektywie budowane
są diagramy klas, komponentów, wdrożenia i pakietów (for-
malnie pojawiły się dopiero w UML2.0, chodź wykorzysty-
wane były już wcześniej). Często pomocne okazuje się wy-
korzystanie diagramu obiektów i nowego diagramu struktur
złożonych. n
Rysunek 5.
Przykładowy diagram struktur złożonych
���������
�������
�������
���������������������
�������
����������
������������������
����������
������
�������������������
�����������
���������������
������������
�����������
Rysunek 4.
Przykładowy diagram obiektów
��������
��������
��������
������������
���������
���������
���������
���������
�����������
�������
������������
�������
��������
�������
�������
��������
�������
�����������
�������
�������������
�������
�������������
�������