plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 06/2007

UML – potrzeba

standaryzacji notacji

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:

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.

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.

spójność modelu – oznacza, że model powinien

wiązać pośrednio lub bezpośrednio wszystkie

wyróżnione cechy.

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

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

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:

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.

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.

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:

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?

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?

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

[1] Władysław Findeisen, Analiza systemowa. Podstawy i me-

todologia, WNT, 1985

[2] Marin Fowler UML Distilled: A Brief Guide To The Stan-

dard Object Modeling Language, 3rd ed., Addison-Weslay
Professional, 2004

[3] Grady Booch, James Rumbaugh, Ivar Jacobson Unified Mo-

deling Language User Guide, 2nd ed., Addison-Weslay Profes-
sional, 2005