plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 08/2007

UML – modelowanie statycznych

aspektów oprogramowania

ę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

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

��

��
��
��
��
��
��

��
��

��

��
��

��

��
��
��
��
��

��

��
��
��

��
��

��

�

��

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

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

��