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