68
Inżynieria
oprogramowania
www.sdjournal.org
Software Developer’s Journal 06/2007
UML – potrzeba
standaryzacji notacji
P
racując od kilku lat przy budowie różnej klasy
systemów informatycznych, przyszedł czas,
aby zadać sobie jedno zasadnicze pytanie.
Mianowicie, co ma wspólnego zagadnienie modelo-
wania z wytwarzaniem oprogramowania? Kluczem
jest tu zrozumienie słowa „modelowanie”. Czym więc
jest model? Po co budowane są modele? Na czym
polega proces modelowania? W końcu, jak się ma do
tego wszystkiego notacja UML?
Model i proces modelowania
Model, pomimo tego, że uproszcza rzeczywistość, za-
wsze pozwala na opis sposobu zachowania się, struk-
tury i dynamiki rzeczywistego lub abstrakcyjnego
obiektu. Model przedstawia się w takiej formie, która
najlepiej ukazuje pożądane aspekty systemu i pozwa-
la zrozumieć jego działanie. Proces modelowania mó-
wiąc najbardziej obrazowo jest „próbą odwzorowania”
wybranego obiektu w „nową przestrzeń”, za pomocą
„pewnej transformacji”, w określonym celu. Modelowa-
nie pozwala więc na usystematyzowanie i strukturali-
zację zebranych informacji o obiekcie i z tego względu
ma istotne znaczenie jako samo działanie.
Poprawność modelu
Z mojego doświadczenia wynika, że nie ma mode-
li złych! Po prostu część modeli pozwala na realiza-
cję planowanego celu, a część nie. Spotkałem się jed-
nak z licznym zbiorem modeli niepoprawnych. Aby wy-
jaśnić jakie właściwości powinien posiadać poprawny
model posłużę się formalną definicję modelu matema-
tycznego, jako pary uporządkowanej, w której pierw-
szy element stanowi zbiór opisów wyróżnionych cech,
a drugi to zbiór opisów wyróżnionych związków pomię-
dzy cechami. Wyróżnione cechy i związki oraz forma
ich prezentacji zależą od celu, w jakim tworzony jest
model, a ich dobór jest uznaniowy (każdy przecież po-
strzega otaczającą go rzeczywistość inaczej). Przez
analogię z modelem matematycznym, poprawny mo-
del powinien spełniać następujące własności:
l
istotność wyróżnionych cech – każda z wyróżnio-
nych cech musi wystąpić przynajmniej w jednym
związku. Cechy nie spełniające powyższego wa-
runku są zbędne, gdyż nie wnoszą żadnego in-
formacji o badanym obiekcie.
l
istotność wyróżnionych związków – jeśli pewien
związek pomiędzy cechami obiektu jednoznacz-
nie wynika z innego związku to może być pominię-
ty, gdyż nie wnosi nowych informacji o obiekcie.
l
spójność modelu – oznacza, że model powinien
wiązać pośrednio lub bezpośrednio wszystkie
wyróżnione cechy.
l
niesprzeczność modelu – oznacza, że jeśli pew-
ne cechy występują w jakimś związku, to w wyniku
analizy pozostałych związków nie można dojść do
wniosku, że rozpatrywany związek ma inną postać.
Po co tworzyć modele
Przyszedł czas na udzielenie odpowiedzi na kolejne
pytanie. Po co tworzone są modele? Odpowiedzi ła-
two udzielić jeśli rozumiemy pojęcie modelu i sens pro-
cesu modelowania. Modele tworzymy przynajmniej
z dwóch powodów. Po pierwsze budujemy modele,
aby lepiej zrozumieć system (istniejący lub konstru-
owany), ponieważ zwykle nie jesteśmy w stanie „ogar-
nąć” go w całości. Dzięki temu jesteśmy w stanie zi-
dentyfikować możliwe problemy, a następnie je roz-
wiązać. Rosnący stopień skomplikowania systemów
powoduje, że coraz trudniejsze staje się ich wytwo-
rzenie. Niewystarczające okazuje się zwiększenie za-
sobów, rozumianych jako liczba osób i/lub pieniędzy
przeznaczonych na budowę systemu. Konieczne wy-
daje się znalezienie innego sposobu radzenia sobie ze
skalą problemów i wypracowywania rozwiązań. Mode-
lowanie wydaje się być słusznym podejściem. Po dru-
gie budujemy modele, aby ułatwić przepływ informa-
cji. Tworzone modele są podstawą komunikacji między
osobą zlecająca rozwiązanie problemu, osobą analizu-
jącą problem, projektującą rozwiązanie i w końcu oso-
bą konstruującą rozwiązanie. W końcu nie można za-
pominać, że modele są właściwie jedynym punktem
odniesienia przy ocenie rozwiązania.
Modelowanie w procesie
wytwarzania oprogramowania
Wróćmy teraz do procesu wytwarzania oprogramowa-
nia. Okazuje się, że na każdym etapie budowy syste-
mu informatycznego ma miejsce modelowanie i two-
rzenie modeli, tyle że często w sposób niejawny. Prze-
cież rozwiązanie każdego problemu opiera się na jego
zrozumieniu, czyli stworzeniu swoistego modelu. Bar-
dzo często tworzone są różnego rodzaju własne, nie-
standardowe opisy, które mają na celu zrozumienie
problemu, jego udokumentowanie, czy w końcu przed-
Rafał Kasprzyk
Autor jest absolwentem Wydziału Cybernetyki WAT, gdzie
od 2 lat zajmuje stanowisko asystenta w Instytucie Syste-
mów Informatycznych. Pracuje w firmie ISOLUTION bę-
dąc odpowiedzialnym za przygotowywanie, prowadzenie
i audyt szkoleń obejmujących analizę i projektowanie sys-
temów informatycznych z użyciem notacji UML.
Kontakt z autorem: rafal.kasprzyk@wat.edu.pl
UML – potrzeba standaryzacji notacji
69
www.sdjournal.org
Software Developer’s Journal 06/2007
stawienie innym osobom. Po co o tym piszę? Po prostu chcę
udowodnić, że, w celu rozwiązania danego problemu, intuicyj-
nie skłaniamy się ku opisywanemu procesowi modelowania i je-
go wynikom, czyli modelom. Ważne jest jednak jeszcze to, aby-
śmy byli tego świadomi. Nie wolno pozwolić, aby doszło do sytu-
acji, że powstawanie modeli jest wymuszane np. koniecznością
stworzenia dokumentacji. Zależność powinna być zupełnie od-
wrotna. To modele są elementem pierwotnym, a dokumentacja
(choć niezwykle istotna) jest wtórnym efektem ich budowy.
Jakie zyski przynosi modelowanie
Nie ma co ukrywać, że proces modelowania wymaga pewne-
go wysiłku, który musi się zwrócić. Oczywistym jest, że zyski
muszą przewyższać koszty. Dotychczasowe rozważania nie-
zbicie dowodzą, że tak jest. Spośród wielu zysków wynikają-
cych z modelowania, chciałbym zwrócić szczególną uwagę na
kilka kluczowych. Po pierwsze, modelowanie podnosi jakość
rozwiązania. Dzieje się tak, ponieważ ułatwione staje się zro-
zumienie problemu. Jakość rozwiązania przejawia się zwykle
w jego prostocie. Jak zauważył Einstein „wszystko powinno się
upraszczać o ile to możliwe, ale nie bardziej”. Modelowanie to
świetny sposób na przemyślane upraszczanie rzeczywistości.
Co ciekawe, otrzymane w ten sposób rozwiązania cechują się
zwykle wysoką elastycznością i skalowalnością.
Po drugie, modelowanie pozwala na wykorzystanie spraw-
dzonych rozwiązań. Niezwykłą popularnością cieszą się tzw.
wzorce (ang. patterns). Wzorce koncentrują się na wynikach
procesu modelowania – przykładowych modelach. Jednak wzo-
rzec to coś więcej niż model. Wzorce opisują sprawdzone spo-
soby „robienia czegoś”. Wzorce są zbierane przez ludzi, któ-
rzy zauważyli powtarzające się motywy pojawiające się przy
wytwarzaniu oprogramowania. Ludzie ci podejmują każdy z
tych motywów i opisują je, aby inni mogli zapoznać się z wzor-
cem, zrozumieć i zastosować. Tak więc, wzorzec musi opisać
problem, wytłumaczyć dlaczego jest rozwiązaniem problemu,
a także wyjaśnić w jakich sytuacjach sprawdza się, a w jakich nie.
Po trzecie, modelowanie ułatwia wykorzystanie narzędzi
wspomagających budowę systemów informatycznych tzw. CA-
SE (ang. Computer Aided Sotware Engineering). Na podstawie
modelu możliwe jest wykonanie szeregu prac w sposób zauto-
matyzowany. Narzędzia CASE pozwalają na budowę modeli
oprogramowania na różnym poziomie abstrakcji (analiza, projekt,
implementacja) wspomagając przejścia pomiędzy tymi modela-
mi i utrzymując spójność pomiędzy nimi. Przykładowo, z modelu
klas istnieje możliwość generacji szkieletu kodu w wielu językach
programowania i/lub kodu schematu bazy danych, czy w końcu
odzyskiwanie modelu klas na podstawie istniejącego już kodu.
Zasady modelowania
Znamy już pojęcie modelu, wiemy na czym polega proces mo-
delowania i zdajemy sobie sprawę z zysków, jakie uzyskujemy
modelując i opierając się na modelach w procesie wytwarzania
oprogramowana. Warto zdać sobie sprawę z podstawowych za-
sad modelowania, co ułatwia budowę poprawnych modeli, czy-
li pozwalających na realizację planowanego celu. Po pierwsze
najważniejsze jest aby pamiętać, że modele można opracowy-
wać na różnym poziomie szczegółowości. Mimo to model mu-
si odpowiadać rzeczywistości. Każdy model jakoś tą rzeczywi-
stość upraszcza. Cała sztuka polega na tym, aby mieć pew-
ność, że uproszczenie nie dotyczy istotnych (z punktu widzenie
celu modelowania) szczegółów. Po drugie okazuje się, że żaden
jeden model nie jest wystarczający, o ile nie mamy do czynienia
z trywialnym systemem. Niewielka liczba, często niemal niezależ-
nych modeli, wydaje się być zawsze najlepszym rozwiązaniem w
przypadku każdego niebanalnego systemu. Pamiętajmy więc (to
już ostatnia zasada) podjęcie decyzji jakie modele tworzyć, ma
wielki wpływ na to, w jaki sposób „zaatakujemy” problem, a co za
tym idzie, jaki kształt przyjmie ostateczne rozwiązanie.
Język modelowania
Język modelowania jest najczęściej graficzną notacją, którą wy-
korzystuje się do budowy modeli. Jak każdy język posiada syn-
taktykę, semantykę i pragmatykę. Syntaktyka określa jakie kon-
strukcje są poprawne tj. jak wolno ze sobą „składać” przyjęte
oznaczenia. Semantyka pozwala właściwie zinterpretować przy-
jęte oznaczenia i budowane z nich konstrukcje. Pragmatyka na-
tomiast mówi, w jaki sposób i do czego należy używać przyję-
tych oznaczeń. Przyglądając się budowanym modelom, docho-
dzę do wniosku, że większość osób korzystając już z jakiegoś
języka modelowania, co prawda zna jego syntaktykę, nie wszy-
scy rozumieją semantykę, ale tylko nieliczni zdają sobie sprawę
z pragmatyki. Okazuje się, że znajomość kolejnych „stopni wta-
jemniczenia” związana jest z doświadczeniem i oczywiście wy-
maga czasu. W przeszłości używano wielu różnych notacji do
budowy modeli, co niezwykle skutecznie utrudniało komunikację
pomiędzy klientem i twórcą systemu, jak również „budziło emo-
cje” w samym zespole wytwarzającym oprogramowanie. Stąd
też wynikła potrzeba standaryzacji notacji. Oczywistym jest, że
niezbędnym warunkiem powodzenia projektu jest dobre zrozu-
mienie się współpracujących stron. Wskazane jest również, aby
stosowana notacja była popularna i powszechnie stosowana.
Zalety standaryzacji notacji to przede wszystkim większa licz-
ba ekspertów, dostępność książek oraz szkoleń i w końcu po-
wszechność narzędzi wspierających proces modelowania z wy-
korzystaniem standardowej notacji.
Od chaosu do UML
Na początku lat 90-tych minionego stulecia liczba samych me-
tod obiektowych wykorzystujących różne notacje sięgnęła bli-
sko pięćdziesięciu. Było to wynikiem tzw. „wojny metod”, z któ-
rych trzy stały się wiodące tj. OOADA (ang. Object-Oriented
Rysunek 1.
Zestawienie diagramów UML
70
Inżynieria
oprogramowania
www.sdjournal.org
Software Developer’s Journal 06/2007
Analysis & Design with Application), której twórcą był Grady
Booch pracujący w firmie Rational; OMT opracowana przez Ji-
m’a Rumbaugh zatrudnionego wówczas w General Electronic
oraz OOSE promowana przez Ivar’a Jacobsona, gdy jeszcze
pracował w Objectory. Wyraźna dominacja przedstawionych
metod w środowisku promującym obiektowe podejście do wy-
twarzania oprogramowania w dużym stopniu przyczyniała się
do ich połączenia. Każda z metod dawała nieco inny punkt wi-
dzenia na otaczającą rzeczywistość, co pozwalało na budowę
innego modelu. Okazało się, że tylko suma modeli generowa-
nych w trzech metodach daje pełne spojrzenie na system i po-
zwala zrozumieć zasadę jego działania. Tak powstała koncep-
cja ujednoliconego języka modelowania, czyli UML. Oficjalny
początek prac nad UML datuje się na 1994 rok, kiedy Ram-
baugh dołączył do Booch’a pracującego w Rational. Następ-
nie dołączył do nich Jacobson. Po opublikowaniu UML w wer-
sji 0.9 przez rok zbierano uwagi środowiska inżynierii opro-
gramowania na temat nowego języka. W tym czasie powsta-
ło konsorcjum gotowe przeznaczyć część dochodów na przy-
gotowanie pełnej i spójnej specyfikacji UML. W skład konsor-
cjum weszło kilka firm, a wynikiem współpracy był UML 1.0,
który można uznać za stosunkowo precyzyjną specyfikację
języka modelowania stanowiącego bardzo silne narzędzie
umożliwiające rozwiązanie wielu praktycznych problemów
pojawiających się przy wytwarzaniu oprogramowania. Roz-
wój UML odbywa się jawnie. Za pośrednictwem OTUG) moż-
na wysyłać własne spostrzeżenia na temat notacji i w ten spo-
sób wpływać na postać kolejnych specyfikacji. Obecnie naj-
częściej stosowaną specyfikacją UML jest wersja 1.5, która
w stosunku do wersji 1.0 posiada szereg poprawek, rozsze-
rzeń i modyfikacji. Najnowsza specyfikacja UML to wersja 2.0,
która stanowi istotny krok ku umożliwieniu niezwykle precyzyj-
nego (zbliżonego do formalnego języka matematycznego) wy-
rażania opisu systemu. UML w wersji 2.0 jest najczęściej opi-
sywaną obecnie specyfikacją tego języka.
Perspektywy
i poziomy abstrakcji w UML
UML jako ujednolicona notacja wykorzystywana do budowy
modeli jest sama w sobie wartościowym wynikiem. Jednak to
nie sama standaryzacja jest najważniejsza. Wynik połączenia
trzech metod wprowadził swego rodzaju synergię. UML jest
znacznie potężniejszym narzędziem modelowania niż wszyst-
kie metody, wchodzące w jego skład. Przede wszystkim warto
zwrócić uwagę na wyraźne wyodrębnienie trzech perspektyw
modelowania systemu i trzech poziomów abstrakcji przekła-
dających się na szczegółowość modelu. Perspektywy są swe-
go rodzaju filtrami, przez które patrzy się na system, przez co
dostrzega się inne jego aspekty. Służą do tego celu różnego
rodzaju diagramy, które zostały zebrane w tabeli przedstawio-
nej na Rysunku 1. Tabela prezentuje dostępność diagramów
występujących w UML1.5 i UML2.0, z przydziałem ich do jed-
nej z trzech perspektyw oraz różnicami w nazewnictwie. Wy-
różnia się następujące perspektywy:
l
zachowanie – umożliwia przedstawienie wymagań funk-
cjonalnych oraz ich wzajemnych zależności. Do tego celu
wykorzystuje się diagramy przypadków użycia wraz z ich
scenariuszami. Scenariusze niekiedy opisywane są z wy-
korzystaniem diagramów aktywności.
l
struktura (statyka) – prezentuje statyczne elementy rozwiąza-
nia, wykorzystywane do realizacji wymagań funkcjonalnych
i niefunkcjonalnych. W tej perspektywie budowane są diagra-
my klas, komponentów, wdrożenia i pakietów. Często pomoc-
ne okazuje się wykorzystanie diagramu obiektów i nowego
diagramu struktur złożonych.
l
dynamika – prezentuje dynamiczne aspekty rozwiązania.
Budowane modele prezentują poszczególne ścieżki reali-
zacji wymagań funkcjonalnych. Modele z tej perspektywy
budowane są w oparciu o diagramy sekwencji, komunika-
cji, aktywności i stanów. W przypadku modelowania syste-
mów specjalizowanych pomocne mogą się okazać nowe
diagramy przeglądu interakcji i przebiegów czasowych.
Nie każdy użytkownik UML zdaje sobie sprawę z możliwości
wykorzystania UML na różnym poziomie abstrakcji. Owe po-
ziomy abstrakcji są niezwykłą zaletą języka. I tak, mówi się
o następujących poziomach:
l
analitycznym – na tym poziomie skupiamy się na pojęciach
z modelowanej dziedziny tzw. „kluczowych abstrakcjach”.
Chodzi o to, aby zrozumieć problem. Zupełnie abstrahuje-
my od możliwych sposobów jego rozwiązania, a tym bardziej
szczegółów technicznych, takich jak język programowania.
Pytanie, jakie należy sobie postawić na tym poziomie brzmi:
Co jest tak naprawdę do zrobienia? W czym tkwi problem?
l
projektowym (specyfikacyjnym) – ten poziom pozwala na
zobrazowanie możliwych sposobów rozwiązania proble-
mu. Abstrahujemy jednak od sposobów implementacji,
skupiając się jedynie na interfejsach. Obrazujemy zarów-
no strukturę, jak i dynamikę tworzonego rozwiązania. Py-
tanie na które odpowiedzieć możemy, patrząc na modele
zbudowane na tym poziomie abstrakcji brzmi: Jaką postać
przyjmie ostateczne rozwiązanie?
l
implementacyjnym – na tym poziomie przedstawiamy szcze-
góły przyjętego rozwiązania, a więc sposób implementacji
interfejsów. Takie modele nadają się doskonale do generacji
szkieletu kodu, co istotnie przyśpiesza programowanie.
Podsumowanie
Celem artykułu było zapełnienie istotnej luki, jaka występuje
w literaturze, a za którą uznaję próbę przedstawiania języka mo-
delowania bez nawiązania do formalnych podstaw modelowa-
nia. Nie wolno zapominać, że UML to obecnie najbardziej popu-
larna notacja do budowy modeli, ale jednak to tylko notacja. Mo-
delowanie ma bardzo bogatą historię i podstawy formalne, o któ-
rych należy pamiętać, aby zrozumieć istotę zunifikowanego języ-
ka modelowania. n
Bibliografia
l
[1] Władysław Findeisen, Analiza systemowa. Podstawy i me-
todologia, WNT, 1985
l
[2] Marin Fowler UML Distilled: A Brief Guide To The Stan-
dard Object Modeling Language, 3rd ed., Addison-Weslay
Professional, 2004
l
[3] Grady Booch, James Rumbaugh, Ivar Jacobson Unified Mo-
deling Language User Guide, 2nd ed., Addison-Weslay Profes-
sional, 2005