&]� Ł ,
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 13
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
14 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
5R]G]LD�
=QDF]HQLH RELHNWRZR FL
Z PRGHORZDQLX V\VWHPŃZ
LQIRUPDW\F]Q\FK
Modelowanie systemów informatycznych to nieustaj ce i trudne wyzwanie dla twór-
ców systemów, pocz wszy od pierwszych biznesowych zastosowa systemów z lat 50.
Pierwsze, stosunkowo proste podej cia do modelowania systemów zmieniały si i ewo-
luowały w zawansowane teoretycznie paradygmaty tworzenia systemów informatycz-
nych (TSI). Szczególnie dwa podej cia zdominowały analiz oraz projektowanie syste-
mów  podej cie strukturalne oraz obiektowe. Zaskakuje mnogo ć i ró norodno ć
zwi zanych z nimi metodyk i notacji. Ró norodno ć ta doprowadziła w latach 80. do
swoistych  wojen metodologicznych , w ramach których ró ne grupy twórców współ-
zawodniczyły z sob , akcentuj c odr bno ć własnych koncepcji. Ósma dekada XX wie-
ku to okres szczególnej dominacji podej cia strukturalnego, które zaowocowało wie-
loma metodykami wypracowanymi przez rodowiska naukowe i biznesowe. Mimo
istotnych ró nic pomi dzy nimi, istniały punkty, kategorie i mechanizmy wspólne, b -
d ce podstaw dalszego rozwoju. Zaliczyć do nich nale y poj cie i składniki metodyki
tworzenia systemów informatycznych, cykl ycia systemu, prototypowanie, diagramy
zwi zków encji, modele relacyjnych baz danych czy te narz dzia CASE (Computer-
-Aided Software Engineering).
Naturalnie ró norodno ć ta wprowadzała spory w ród specjalistów z dziedziny in y-
nierii oprogramowania co do warto ci i u yteczno ci oferowanych, odmiennych po-
dej ć. Równie pewne obietnice podej cia strukturalnego  chocia by automatyzacja
procesu tworzenia systemów informatycznych od analizy do generowania kodu  nie
zostały spełnione. W celu uporz dkowania wiedzy i procedur modelowania systemów
informatycznych podj to dwie znacz ce inicjatywy unifikacyjne:
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 15
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
t podj t przez IFIP (International Federation of Information Processing)
w postaci grupy roboczej CRIS (Comparative Review of Information Systems
Methodologies),
t podj t przez Uni Europejsk w ramach zespołu reprezentuj cego autorów
metodyk u ywanych w ró nych krajach członkowskich pod nazw EuroMethod.
Wymienione inicjatywy unifikacji procesu projektowania i wdra ania systemów infor-
matycznych nie zyskały aprobaty rodowiska informatyków. Niemniej ogólna, zbiorowa
wiedza na temat ró norodnych metodyk strukturalnych i zwi zane z nimi narz dzia
CASE, stały si w latach 80. i pó niej bardzo przydatnym, rutynowo wykorzystywa-
nym, klasycznym narz dziem analizy oraz projektowania systemów informatycznych.
Problemy zwi zane z podej ciem strukturalnym sprzyjały zainteresowaniu oraz rozwo-
jowi prac naukowo-badawczych i wdro eniowych, opieraj cych si na innych pod-
stawach teoretycznych. Wymienić tu nale y przede wszystkim społeczne i obiektowe
modelowanie systemów. Od pocz tku lat 90. szczególnie modele obiektowe znalazły
si w centrum zainteresowania twórców i u ytkowników systemów. Wzrost znacze-
nia obiektowo ci stymulowany był przez:
t wyzwania post pu technologicznego w informatyce, polegaj ce na coraz
bardziej powszechnym u ytkowaniu systemów czasu rzeczywistego i systemów
wbudowanych;
t ró norodno ć i powszechno ć aplikacji internetowych w gospodarce opartej
na wiedzy, czyli w takich dziedzinach jak e-business, e-health, e-government,
e-learning;
t multimedialny charakter aplikacji, wykorzystuj cych w coraz wi kszym stopniu
d wi k, głos, grafik , film;
t globalizacj gospodarki, a zatem integracj systemów informatycznych
 w telekomunikacji, bankowo ci, edukacji, turystyce, transporcie;
t powszechno ć i dost pno ć aplikacji, zwłaszcza internetowych, dla potrzeb
społecze stwa informacyjnego.
Wyzwaniom tym w najwy szym stopniu sprostało podej cie obiektowe. Rozwijane od
lat 50. XX wieku, w latach 90. znalazło si w centrum zainteresowania badaczy i prak-
tyków. Poj cie obiektowo ci pocz tkowo wykorzystywane było w obiektowych j zy-
kach programowania, takich jak SIMULA czy SmallTalk. Podej cie obiektowe ma
obecnie najwi ksze znaczenie w nast puj cych zastosowaniach:
t metodykach tworzenia oprogramowania (przede wszystkim Rational Unified
Process);
t graficznych j zykach ogólnego przeznaczenia (UML);
t obiektowych j zykach programowania (JAVA, platforma .NET);
t bazach danych (np. ObjectStore).
16 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
Ka dy model obiektowy opiera si na pewnych elementarnych poj ciach i kategoriach,
które pod wzgl dem metodologicznym stanowi tzw. podstawowy model obiektowy.
Model ten jest szczegółowo przedstawiony w wielu opracowaniach naukowych na
temat podej cia naukowego. Główne poj cia podstawowego modelu obiektowego
 obiekt, klas , komunikat, hermetyzacj , polimorfizm i dziedziczenie  charakte-
ryzuje tabela 1.1.
7DEHOD Podstawowe poj cia obiektowo ci
3RM�FLH ,QWHUSUHWDFMD
obiekt Ka dy byt  poj cie lub rzecz  maj cy znaczenie w kontek cie rozwi zywania
(ang. object) problemu w danej dziedzinie przedmiotowej.
klasa Uogólnienie zbioru obiektów, które maj takie same atrybuty, operacje,
(ang. class) zwi zki i znaczenie.
komunikat Specyfikacja wymiany informacji mi dzy obiektami, zawieraj ca zlecenia
(ang. message) wykonania okre lonej operacji.
hermetyzacja Ró nicowanie dost pu do obiektu poprzez ujawnienie otoczeniu tylko tych
(ang. encapsulation) informacji o jego atrybutach lub operacjach, które s niezb dne do efektywnego
odwoływania si do obiektu w systemie za po rednictwem komunikatów.
polimorfizm Mo liwo ć nadawania tej samej nazwy ró nym atrybutom i operacjom
(ang. polymorphism) oraz wykonywania ró nych procedur i akcji poprzez operacje o tych samych
nazwach; pozwala na redukcj liczby nazw atrybutów i operacji.
dziedziczenie Przyporz dkowanie atrybutów i operacji klasom obiektów na podstawie
(ang. inheritance) hierarchicznej zale no ci mi dzy nimi. Mo liwe jest wielokrotne dziedziczenie,
co oznacza, e dana klasa dziedziczy atrybuty i operacje z dowolnej liczby
klas nadrz dnych.
Obiektowo ć stanowi podstaw teoretyczn j zyka UML (Unified Modeling Language).
W dalszych punktach niniejszego rozdziału przedstawiono ogólne zagadnienia zwi -
zane z tym j zykiem, a wi c:
t jego genez i ewolucj ,
t klasyfikacj oraz krótk charakterystyk diagramów UML,
t perspektywy architektury systemu,
t mechanizmy rozszerzalno ci.
*HQH]D L HZROXFMD M�]\ND 80/
W przypadku modelowania obiektowego równie nie udało si unikn ć metodyczne-
go rozproszenia. Szczególn dynamik charakteryzowały si lata 1989  1994, kiedy
to liczba identyfikowalnych rozwi za wzrosła z kilku do ponad 50. Jednak w odró -
nieniu od metodyk strukturalnych, spory nad kształtem metodyk obiektowych zako -
czyły si powszechnie uznawanym konsensusem. Autorzy dominuj cych w omawianym
okresie rozwi za , które ewoluowały wówczas niezale nie od siebie, zaproponowali
ujednolicony j zyk modelowania systemów informatycznych  UML. Nie nale y
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 17
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
przy tym uto samiać j zyka UML z pełn metodyk tworzenia systemów informa-
tycznych, która jest znacznie szersz kategori (por. rozdział 14.). Podstawowe trzy
autorskie ródła j zyka UML przedstawia tabela 1.2.
7DEHOD Wkład dominuj cych podej ć w standard UML
$XWRU 1D]ZD PHWRG\NL 6NUŃW QD]Z\ 3RGVWDZRZ\ ZN�DG 3XEOLNDFMH
Rumbaugh Object Modeling OMT Notacja diagramów UML, [Rumbaugh-1991]
Technique analiza i projektowanie
Booch Object Oriented OOAD Analiza i projektowanie [Booch-1991]
Analysis and Design
Jacobson Object Oriented OOSE Modelowanie biznesowe, [Jacobson-1992]
Software Engineering przypadki u ycia, diagramy
modelowania analitycznego
Modelowanie systemów informatycznych obejmuje aspekty funkcjonalne oraz niefunk-
cjonalne. Obie kategorie dynamicznie rozwijały si w zwi zku z wymaganiami obiek-
towego wytwarzania oprogramowania. W praktyce analitycy, projektanci czy integrato-
rzy wymagali adekwatnych metod i technik umo liwiaj cych modelowanie zło onych
współbie no ci, interakcji, maszyn stanowych itd. Zatem mo liwo ć modelowania
funkcjonalnych i niefunkcjonalnych aspektów systemów informatycznych była i nadal
jest motywem ewolucji j zyka UML, którego kolejne wersje s wzbogacane o nowe
kategorie, b d ce odpowiedzi na wymagania twórców systemów informatycznych sta-
wiane metodom i technikom modelowania.
W stworzeniu ujednoliconego podej cia upatrywano szansy nie tylko na osi gni cie
wi kszej przejrzysto ci oferty rynkowej, lecz równie na uzyskanie efektu skali po-
przez wymian do wiadcze . Zało enia autorów j zyka UML wykraczały poza doko-
nanie prostej kompilacji. Przede wszystkim zdawano sobie spraw z tego, e j zyk mo-
delowania po redniczy pomi dzy ludzkim rozumieniem funkcjonowania programów
komputerowych a ich fizyczn realizacj w postaci kodu ródłowego. St d j zyk taki
powinien jednocze nie:
t w sposób cisły definiować podstawowe i zaawansowane kategorie oraz zasady
modelowania obiektowego;
t umo liwiać dostosowywanie wykorzystywanej semantyki i notacji
do rozwi zywania szerokiego spektrum problemów;
t wykazywać elastyczno ć wystarczaj c do modelowania, obok systemów
oprogramowania, tak e systemów biznesowych;
t wykazywać daleko posuni t niezale no ć od konkretnych j zyków
programowania oraz metodyk tworzenia systemów informatycznych;
t uwzgl dniać skal realizowanych współcze nie projektów, zwi zanych z bardzo
rozbudowanymi systemami o kluczowym znaczeniu dla funkcjonowania
przedsi biorstw.
18 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
Ujednolicone podej cie, powstałe z uwzgl dnieniem metodyk ródłowych zaprezento-
wanych w tabeli 1.1 oraz wymienionych zało e , dynamicznie rozwijało si na przestrze-
ni ostatnich lat. Histori oraz cie k ewolucyjn j zyka UML przedstawia rysunek 1.1.
5\VXQHN Ewolucja j zyka UML
Prace nad j zykiem UML zapocz tkowano w pa dzierniku 1994 roku, kiedy J. Rum-
baugh doł czył do firmy Rational Software Corporation, gdzie wraz z G. Boochem
rozpocz li prac nad ujednoliceniem metod OMT i OOAD. Efektem współpracy stał
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 19
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
si zaprezentowany przez firm Rational na konferencji OOPSLA  95 pierwowzór j -
zyka UML. Wersj t zaprezentowano w pa dzierniku 1995 roku. Ten dokument robo-
czy znany był jako UM (Unified Method) 0.8. W tym samym roku do zespołu doł czył
I. Jacobson  autor metodyki OOSE. W czerwcu 1996 roku opublikowano wersj 0.9,
uwzgl dniaj c ju wkład I. Jacobsona, natomiast pod koniec tego samego roku wer-
sj 0.91. Od tego momentu j zyk okre la si jako UML.
80/ 8QLILHG 0RGHOLQJ /DQJXDJH MHVW JUDILF]Q\P M�]\NLHP ZL]XDOL]DFML VSHF\ILNR
ZDQLD WZRU]HQLD L GRNXPHQWRZDQLD V\VWHPŃZ LQIRUPDW\F]Q\FK
Partnerami projektu rozwoju UML w korporacji Rational stały si czołowe korporacje
wiata. Nale ały do nich: IBM, Digital Equipment Corporation, Hewlett-Packard, Intel-
licorp, I-Logix, Icon Computing, Oracle, Unisys czy te Microsoft. Ich wsparcie w istot-
ny sposób przyczyniło si do powstania wersji 1.0 w styczniu 1997 roku. Dzi ki tej
współpracy wersja 1.0 była ju silnym i precyzyjnie zdefiniowanym j zykiem mode-
lowania. Wersja ta została przekazana jako propozycja standardu organizacji OMG
(Object Management Group)  mi dzynarodowej organizacji, której misj jest promo-
wanie praktyki i teorii technologii obiektowych w tworzeniu oprogramowania. W OMG
powołano wówczas grup ADTF (Analysis and Design Task Force), która skoncen-
trowała si na rozwijaniu standardu.
W lipcu 1997 roku korporacja Rational przedstawia kolejn propozycj UML-a w wer-
sji 1.1, równie przekazan do OMG. Dwa miesi ce po jej przekazaniu, w listopadzie
1997 roku, OGM ADTF ostatecznie przyjmuje kolejny standard w wersji 1.1. W tym
momencie powoływany jest nowy zespół do spraw zmian standardu UML  OMG
RTF (Revision Task Force). Na jego czele staje Cris Kobryn, pod przewodnictwem
którego w czerwcu 1998 roku powstaje wersja UML 1.2. Zmiany wprowadzone w wer-
sji 1.2 były nieznaczne, koncentrowały si na poprawkach o charakterze redakcyjnym.
Wersja 1.2 oraz nast puj ca po niej wersja 1.3 to publikacje wewn trzne OMG  ofi-
cjalnym standardem wci pozostawała wersja 1.1. W wersji 1.3 wprowadzono zna-
cz ce zmiany w zakresie diagramów przypadków u ycia i diagramów czynno ci.
W kwietniu 1999 roku zespół OMG RTF publikuje kolejn wersj  UML 1.4. Jej nie-
oficjalna dokumentacja była dost pna w połowie 2000 roku, natomiast oficjaln spe-
cyfikacj wydano we wrze niu 2001 roku. Podobnie jak w przypadku przej cia z wer-
sji 1.1 do 1.2, nie były to daleko id ce zmiany  skoncentrowano si na poprawie
spójno ci dokumentacji.
W tym okresie OMG wyznacza wersj 2.0 jako oficjalny kierunek zmian, wyodr bnia-
j c z wówczas obowi zuj cej dokumentacji cztery podlegaj ce ró nym zespołom spe-
cyfikacje:
t infrastruktur UML, b d c podstaw architektoniczn składni j zyka UML 2.0,
jego metamodelem, pozwalaj c na definiowanie i rozwijanie superstruktury
UML [OMG-2003b];
t superstruktur UML, specyfikuj c ukierunkowane na u ytkownika kategorie
modelowania  elementarne składniki wykorzystywane w tworzeniu
poszczególnych diagramów [OMG-2003a];
20 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
t OCL  j zyk opisu ogranicze [Warmer-2003];
t wymienno ć diagramów UML, czyli mechanizm przenoszenia dokumentów
zgodnych ze standardem UML pomi dzy ró nymi narz dziami [OMG-2003c].
We wrze niu 2002 roku pojawia si jednak nieoficjalnie wersja 1.5, która wprowadza
bardzo szczegółowy model akcji. W marcu 2003 roku staje si ona wersj oficjaln .
Wersja 2.0 zaprezentowana zostaje w sierpniu 2003 roku. Wersja ta znacz co ró ni si
od poprzednich. Rozszerza ona zakres dost pnych diagramów do trzynastu oraz wpro-
wadza szereg nowych kategorii modelowania w istniej cych diagramach. Składni i kla-
syfikacj wielu istniej cych kategorii istotnie zmodyfikowano, opieraj c je na opraco-
wanej równie przez OMG metaskładni MOF (Meta Object Facility). Na podstawie
metaskładni MOF, OMG zdefiniowała mechanizm wymiany dokumentów zgodnych
ze standardem UML, wprowadzaj c standardy XMI (XML Metadata Interchange) oraz
CWM (Common Warehouse Metamodel). XMI umo liwia przej cie ze specyfikacji
UML do dokumentów opisanych w j zyku XML. Z kolei CWM opisuje wymian me-
tadanych pomi dzy hurtowniami danych, systemami klasy Business Intelligence, sys-
temami zarz dzania wiedz oraz technologiami internetowymi.
Standard UML na bie co podlega aktualizacji, modyfikacjom i wzbogacaniu. W 2004
roku dokumentacja UML 2.0 ulega przeredagowaniu, co skutkuje opublikowaniem do-
kumentu UML 2.0 Superstructure FTF Convenience Document [OMG-2004]. Obecnie
w pracach OMG współuczestniczy ponad 800 informatycznych organizacji biznesowych
i badawczych, wprowadzaj cych kolejne innowacje i rozszerzaj cych zakres dokumen-
tacji. Tym samym, ze wzgl du na charakter i przeznaczenie niniejszej ksi ki, mniejsz
wag przypisano kategoriom modelowania ci le zwi zanym z programowaniem.
'LDJUDP\ 80/
J zyk UML przyjmuje w praktyce postać graficznej reprezentacji tworzonego systemu,
składaj cej si z logicznie powi zanych z sob diagramów. Pozwalaj one na opisa-
nie systemu od modeli ogólnych do bardzo szczegółowych. W standardzie UML w wer-
sji 2.0 wyst puje trzyna cie rodzajów diagramów, które charakteryzuj statyk i dy-
namik tworzonego systemu. Klasyfikacj diagramów UML przedstawia rysunek 1.2.
Na rysunku 1.2 wyst puj kategorie diagramów abstrakcyjnych i konkretnych. Diagra-
my abstrakcyjne s jedynie nazwami uogólniaj cymi grupy diagramów konkretnych.
A zatem do kategorii diagramów abstrakcyjnych zalicza si diagramy struktury, dyna-
miki, interakcji, wdro eniowe oraz sam kategori diagramów UML. Abstrakcyjne ka-
tegorie poj ciowe zwyczajowo oznacza si kursyw . Pełny zestaw diagramów kon-
kretnych, stanowi cych standard j zyka UML 2.0, syntetycznie scharakteryzowano
w tabeli 1.3, a szczegółowo zaprezentowano w kolejnych rozdziałach pierwszej cz -
ci niniejszego podr cznika. Tabela 1.3 zawiera równie wyró niki rodzaju diagramu,
które w unikalny sposób wskazuj na jego specyficzn zawarto ć. Poza wymienio-
nymi na rysunku 1.2 diagramami, rodowiska akademickie i profesjonalne u ytkuj ce
j zyk UML oraz metodyk RUP zaproponowały inne techniki diagramowe ci le po-
wi zane ze standardem UML. S to m.in. diagramy modelowania analitycznego oraz
diagramy modelowania biznesowego. Techniki te opisano w cz ci drugiej.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 21
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
5\VXQHN Diagramy w j zyku UML 2.0
7DEHOD Proponowane wyró niki i charakterystyka rodzajów diagramów
:\UŃ QLN
URG]DMX GLDJUDPX
/3 5RG]DM GLDJUDPX &KDUDNWHU\VW\ND 5R]G]LD�
polski angielski
1 Diagram klas Diagram klas to graficzne przedsta- kls cld 3
(ang. Class Diagram) wienie statycznych, deklaratywnych
elementów dziedziny przedmiotowej
oraz zwi zków mi dzy nimi
2 Diagram obiektów Diagram obiektów to wyst pienie obk od 3
(ang. Object Diagram) diagramu klas, odwzorowuj ce
struktur systemu w wybranym
momencie jego działania
3 Diagram pakietów Diagram pakietów to graficzne pkt pd 13
(ang. Package przedstawienie logicznej struktury
Diagram) systemu w postaci zestawu pakietów
poł czonych zale no ciami
i zagnie d eniami
4 Diagram struktur Diagram struktur poł czonych to spl csd 12
poł czonych graficzne przedstawienie wzajemnie
(ang. Composite współdziałaj cych cz ci dla
Structure Diagram) osi gni cia po danej funkcjonalno ci
współdziałania
22 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
7DEHOD Proponowane wyró niki i charakterystyka rodzajów diagramów (ci g dalszy)
:\UŃ QLN
/3 5RG]DM GLDJUDPX &KDUDNWHU\VW\ND 5R]G]LD�
URG]DMX GLDJUDPX
5 Diagram komponentów Diagram komponentów to rodzaj kmp cod 11
(ang. Component diagramu wdro eniowego, który
Diagram) wskazuje organizacj i zale no ci
mi dzy komponentami
6 Diagram rozlokowania Diagram rozlokowania to rodzaj rzk dd 11
(ang. Deployment diagramu wdro eniowego, który
Diagram) przedstawia sieć poł czonych
cie kami komunikowania w złów
z ulokowanymi na nich artefaktami
7 Diagram przypadków Diagram przypadków u ycia to uzc ud 2
u ycia graficzne przedstawienie przypadków
(ang. Use Case u ycia, aktorów oraz zwi zków
Diagram) mi dzy nimi, wyst puj cych w danej
dziedzinie przedmiotowej
8 Diagram czynno ci Diagram czynno ci to graficzne czn ad 4
(ang. Activity Diagram) przedstawienie sekwencyjnych
i (lub) współbie nych przepływów
sterowania oraz danych pomi dzy
uporz dkowanymi ci gami czynno ci,
akcji i obiektów
9 Diagram maszyny Diagram maszyny stanowej stn sm 5
stanowej to graficzne odzwierciedlenie
(ang. State Machine dyskretnego, skokowego zachowania
Diagram) sko czonych systemów stan-przej cie
10 Diagram sekwencji Diagram sekwencji jest rodzajem skw sd 7
(ang. Sequence diagramu interakcji, opisuj cym
Diagram) interakcje pomi dzy instancjami
klasyfikatorów systemu w postaci
sekwencji komunikatów
wymienianych mi dzy nimi
11 Diagram komunikacji Diagram komunikacji jest rodzajem kmn cd 8
(ang. Communication diagramu interakcji, specyfikuj cym
Diagram) strukturalne zwi zki pomi dzy
instancjami klasyfikatorów bior cymi
udział w interakcji oraz wymian
komunikatów pomi dzy tymi
instancjami
12 Diagram Diagram harmonogramowania jest hrm td 9
harmonogramowania rodzajem diagramu interakcji,
(ang. Timing Diagram) reprezentuj cym na osi czasu zmiany
dopuszczalnych stanów, jakie mo e
przyjmować instancja klasyfikatora
uczestnicz ca w interakcji
13 Diagram sterowania Diagram sterowania interakcj jest sin iod 10
interakcj rodzajem diagramu interakcji,
(ang. Interaction dokumentuj cym przepływ sterowania
Overview Diagram) pomi dzy logicznie powi zanymi
diagramami i fragmentami interakcji
z wykorzystaniem kategorii
modelowania diagramów czynno ci
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 23
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
W publikacjach polskich dotycz cych j zyka UML, b d cych najcz ciej tłumaczenia-
mi literatury angloj zycznej, u ywano synonimów nazw diagramów. Najistotniejsze
z nich uwzgl dniono w słowniku angielsko-polskim (dodatek F). Specyfikacja j zyka
UML wprowadza poj cie klasyfikatora (ang. classifier), które ma zastosowanie w od-
niesieniu do praktycznie ka dego rodzaju diagramu j zyka UML 2.0.
.ODV\ILNDWRU WR DEVWUDNF\MQD NDWHJRULD PRGHORZDQLD V\VWHPX Z M�]\NX 80/ NWŃUD
XRJŃOQLD NROHNFM� LQVWDQFML R W\FK VDP\FK FHFKDFK
Na konkretnych diagramach j zyka UML zamieszcza si instancje poszczególnych ro-
dzajów klasyfikatorów. W wietle powy szej definicji instancj rozumieć nale y na-
st puj co:
,QVWDQFMD MHVW Z\VWńSLHQLHP HJ]HPSODU]HP NODV\ILNDWRUD
Tak wi c klasyfikatorem jest interfejs, a jego wyst pieniem IRejestracjaArtykułu. Za
podstawowy rodzaj klasyfikatora uznać nale y klas . Klasa ma instancje w postaci
obiektów. Inne omawiane w niniejszej ksi ce rodzaje klasyfikatorów obejmuj m.in.
w zeł, komponent, aktora, przypadek u ycia i pakiet. Ze wzgl du na logik prezentacji
materiału dydaktycznego wybrane rodzaje klasyfikatorów j zyka UML 2 podsumowano
w tabeli 7.3. Obecnie w j zyku UML istnieje ponad 30 klasyfikatorów. Pełn taksono-
mi klasyfikatorów UML 2 zawiera dokumentacja OMG [OMG-2004, zał cznik F].
W j zyku UML 2 funkcjonuje równie poj cie klasyfikatora ustrukturyzowanego (ang.
structured classifier). Klasyfikator ustrukturyzowany zawiera specyfikacj wewn trznej
struktury. Poj cie to odnosi si do diagramów struktur poł czonych (por. rozdział 12.).
Dowolny z wymienionych w tabeli 1.3 diagramów mo e być prezentowany w postaci:
t obramowanej,
t nieobramowanej.
Diagram w postaci obramowanej otoczony jest prostok tn ram (ang. frame) zawie-
raj c nagłówek. Przyjmuje on postać pentagramu umieszczonego w lewym górnym
rogu diagramu. Typowy nagłówek diagramu UML 2.0 charakteryzuje si formaln , za-
prezentowan poni ej składni :
::= [] []
przy czym:
t rodzaj  pełny lub skrótowy wyró nik diagramu zawartego w ramie;
t nazwa  syntetyczna nazwa odzwierciedlaj ca merytoryczn zawarto ć
diagramu;
t parametry  szczegółowe parametry kluczowe dla danego diagramu,
np. nazwy instancji klasyfikatorów, warto ci zwrotne, operatory interakcji.
Notacja ta oznacza, e rodzaj diagramu oraz jego parametry s elementami umiesz-
czanymi fakultatywnie, natomiast nazwa jest obligatoryjna. Elementy diagramu UML
w postaci obramowanej przedstawia rysunek 1.3.
24 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
5\VXQHN
QDJ�yZHN
Format diagramu

obramowanego


rama
PHU\WRU\F]QD ]DZDUWR � GLDJUDPX
W formie obramowanej przedstawić mo na ka dy z 13 rodzajów diagramów j zy-
ka UML. Podczas tworzenia nagłówków diagramów mo na skorzystać z polsko- b d
angloj zycznych wyró ników rodzajów diagramów (tabela 1.3). Kwestia wyró ników
nie jest zagadnieniem ujednoliconym. I tak autorzy dokumentacji OMG oznaczaj na
przykład wszystkie diagramy interakcji wyró nikiem sd (ang. sequence diagram). Pro-
pozycje i dost pno ć wyró ników w pakietach CASE wspieraj cych j zyk UML s
zró nicowane.
Konwencja tworzenia diagramów obramowanych, chocia zalecana od momentu wpro-
wadzenia wersji 2.0 j zyka UML, nie musi być bezwarunkowo realizowana. Dokumen-
tacja systemu w j zyku UML, sporz dzona z uwzgl dnieniem informacji zawartych
w nagłówkach diagramów obramowanych, w przypadku rozbudowanych systemów po-
prawia przejrzysto ć dokumentacji.
Stosowanie formy obramowanej mo na rozszerzyć na poszczególne instancje klasyfi-
katorów j zyka UML. I tak przedstawienie pakietu systemu w formie ramy mo e wi -
zać si z wykorzystaniem nieskrótowego wyró nika jednoznacznie identyfikuj cego
zawarto ć ramy jako pakiet  np. wyró nika package. Z kolei zastosowanie ramy do
opisu pojedynczego przypadku u ycia opiera si na wyró niku useCase.
3HUVSHNW\Z\ Z RSLVLH
DUFKLWHNWXU\ V\VWHPX
W skutecznym tworzeniu i u ytkowaniu systemów informatycznych bierze udział wiele
osób o ró nych kompetencjach zawodowych i organizacyjnych. S to wła ciciele, me-
ned erowie, analitycy, projektanci, programi ci, testuj cy itd. Ka da z tych grup za-
wodowych ma własny pogl d na system informatyczny, tote poprzez swoje decyzje
powinna mieć wpływ na jego architektur . Ta ró norodno ć spojrze była zasadniczo
nieuwzgl dniana w podej ciu strukturalnym do TSI, a akcentowana w podej ciu spo-
łecznym. W kontek cie j zyka UML zró nicowanie punktów widzenia znajduje swój
wyraz w postaci powi zanej z nim metodyki RUP, proponuj cej pi ć perspektyw (ang.
views) architektury systemu informatycznego. S to:
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 25
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
t perspektywa przypadków u ycia  kluczowa i dominuj ca wobec pozostałych,
definiuje zakres i oczekiwan funkcjonalno ć tworzonego systemu;
t perspektywa dynamiczna  wskazuje, w jaki sposób jest realizowane
zachowanie instancji klasyfikatorów w systemie;
t perspektywa logiczna  dokumentuje statyk systemu;
t perspektywa komponentów  przeznaczona głównie dla programistów,
specyfikuje oprogramowanie na poziomie komponentów;
t perspektywa rozlokowania  specyfikuje sprz t informatyczny niezb dny
do funkcjonowania konkretnych komponentów systemu.
Ka da z perspektyw uwypukla zatem inne aspekty architektury systemu, pomijaj c jed-
nocze nie szczegóły nieistotne z punktu widzenia danej grupy zawodowej. Perspek-
tywy wspierane s poprzez okre lone zestawy diagramów (rysunek 1.4).
5\VXQHN Modelowanie perspektyw architektury systemu
26 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
0HFKDQL]P\ UR]V]HU]DOQR FL
J zyk UML zapewnia bogaty zestaw poj ć zwi zanych z modelowaniem systemów in-
formatycznych oraz elementów notacji przydatnych w zapisywaniu typowych projek-
tów systemów, niemniej odbiorcy mog wymagać dodatkowych cech wykraczaj cych
poza te zdefiniowane w specyfikacji j zyka. Z tego powodu autorzy zdecydowali si
na wł czenie do j zyka UML zestawu mechanizmów rozszerzalno ci (ang. extension
mechanisms), pozwalaj cego na u ywanie przez twórców systemu nowych kategorii
modelowania specyficznych dla danej dziedziny zastosowania. Umo liwiaj one wzbo-
gacanie ju istniej cych kategorii poj ciowych o dodatkowe informacje, jak równie
modyfikacj znaczeniow tych kategorii. W j zyku UML wyró nia si trzy rodzaje me-
chanizmów rozszerzalno ci:
t stereotyp,
t ograniczenie,
t metka.
6WHUHRSW\S
Stereotypów (ang. stereotypes) u ywa si do klasyfikowania b d oznaczania istnie-
j cych elementów modelu obiektowego oraz wprowadzania nowych kategorii mode-
lowania, wywodz cych si z ju istniej cych. I tak:
6WHUHRW\S WR PHFKDQL]P UR]V]HU]DOQR FL NWŃU\ Z]ERJDFD ]ELRURZR Ł VWDQGDUGRZ\FK
NDWHJRULL PRGHORZDQLD M�]\ND 80/
Wzbogacenie, rozszerzenie o stereotypy w praktyce oznacza wprowadzenie nowych
kategorii modelowania w poszczególnych diagramach j zyka UML, przy czym katego-
rie te bazuj na semantyce standardowych, istniej cych kategorii modelowania.
Wyró nia si stereotypy tekstowe oraz graficzne. Nazwa stereotypu tekstowego zwy-
czajowo ujmowana jest w podwójny cudzysłów ostrok tny i umieszczana na stereoty-
powanym elemencie. Przykładowym stereotypem tekstowym odnosz cym si do:
t pakietów jest <>,
t zwi zku zale no ci  <> czy te <>,
t komponentu  <>.
Z kolei stereotypy graficzne maj domy lnie postać specyficznych symboli graficznych
umieszczanych na stereotypowanych elementach. Zastosowanie stereotypów nie ogra-
nicza w ten sposób twórcy systemu, który ma daleko posuni t swobod w u ywaniu
i proponowaniu ró norodnych symboli, specyficznych dla danej aplikacji.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 27
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Twórca systemu ma do dyspozycji znaczn liczb stereotypów standardowych, reko-
mendowanych przez autorów j zyka UML oraz OMG  i w konsekwencji powszech-
nie stosowanych. Zostały one wymienione i scharakteryzowane w dokumentacji stan-
dardu [OMG-2004, zał cznik C].
2JUDQLF]HQLH
Kolejnym mechanizmem rozszerzenia jest ograniczenie (ang. constraint).
2JUDQLF]HQLH WR Z\UD HQLH VHPDQW\F]QH RNUH ODMńFH ZDUXQHN EńG ]DVWU]H HQLH ]ZLń
]DQH ] RJUDQLF]DQ\P HOHPHQWHP PRGHORZDQLD EńG JUXSń HOHPHQWŃZ
Ograniczenie jest w istocie tekstem wyra onym w j zyku naturalnym, formuł mate-
matyczn , predykatem logiki formalnej b d instrukcj pseudokodu. W standardzie UML
definiować je mo na w dedykowanym j zyku ogranicze OCL (Object Constraint
Language), zawieraj cym formaln składni ogranicze obiektowych. Ograniczenia
umieszczane s w nawiasach klamrowych w bezpo rednim s siedztwie elementu lub
elementów, których znaczenie jest precyzowane;
np. {disjoint}
{czas < 15 min}.
0HWND
Ka da kategoria modelowania j zyka UML charakteryzuje si specyficznym zestawem
wła ciwo ci. Taki zbiór wła ciwo ci mo e być rozszerzany z wykorzystaniem metek
(ang. tagged values).
0HWND VWDQRZL MDZQH ]GHILQLRZDQLH Z�D FLZR FL Z SRVWDFL SU]\SRU]ńGNRZDQLD QD]ZD
ZDUWR Ł
Konwencja wprowadzania metek do diagramów jest podobna jak w przypadku ogra-
nicze  jest to zapis w nawiasach klamrowych, składaj cy si z nazwy, separatora
oraz warto ci (z zastrze eniem, e jest on umieszczany bezpo rednio pod nazw danego
elementu). Dozwolone jest doł czanie metek tak e do stereotypów. Najpowszechniej
metki stosuje si celem okre lenia wła ciwo ci istotnych w generowaniu kodu oraz
zarz dzaniu konfiguracjami;
np. {wersja = beta}
{model = HP LaserJet 1500L}.
28 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
3RGVWDZRZH SRM�FLD
Common Warehouse Metamodel Stereotyp
Computer-Aided Software Engineering Graficzny
Cykl ycia systemu Tekstowy
Diagram UML Metodyka
Abstrakcyjny Obiektowa
Konkretny OMT
Diagramy dynamiki UML OOAD
Diagram czynno ci OOSE
Diagramy interakcji Społeczna
Diagram harmonogramowania Strukturalna
Diagram komunikacji Meta Object Facility
Diagram sekwencji Modelowanie systemów
Diagram sterowania interakcj Nagłówek diagramu
Diagram maszyny stanowej Nazwa
Diagram przypadków u ycia Wyró nik diagramu
Diagramy struktury UML Parametr
Diagram klas Notacja
Diagram obiektów Obiektowo ć
Diagram pakietów Dziedziczenie
Diagram struktur poł czonych Hermetyzacja
Diagramy wdro eniowe Klasa
Diagram komponentów Komunikat
Diagram rozlokowania Obiekt
Klasyfikator Polimorfizm
Ustrukturyzowany Object Constraint Language
Mechanizmy rozszerzalno ci OMG
Metka ADTF
Ograniczenie RTF
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 29
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
Perspektywa Superstruktura UML
Dynamiczna System informatyczny
Komponentów Tworzenie systemów
informatycznych (TSI)
Logiczna UML
Przypadków u ycia Wymienno ć diagramów UML
Rozlokowania XML Metadata Interchange
Rama
3\WDQLD L ]DGDQLD
Scharakteryzuj trendy rozwoju modelowania systemów informatycznych.

Jakie było znaczenie i skutki inicjatyw unifikacyjnych w dziedzinie tworzenia

systemów informatycznych?
Jakie zjawiska sprzyjały wzrostowi znaczenia obiektowo ci w informatyce?

Podaj przykłady obszarów i narz dzi, w których model obiektowy znajduje

zastosowanie.
Wska i scharakteryzuj kluczowe poj cia obiektowo ci.

Zidentyfikuj nazwy kilku klas odnosz cych si do rodków transportu. Wska

przykładowe obiekty tych klas.
Zaprezentuj mechanizm dziedziczenia, wykorzystuj c zidentyfikowane klasy

rodków transportu.
Wymie metodyki ródłowe j zyka UML.

Jakie cele sformułowane zostały w trakcie tworzenia j zyka UML?

Podaj definicj j zyka UML.

Wyja nij zale no ć pomi dzy korporacj Rational oraz organizacj OMG w

kontek cie rozwoju standardu UML.
Przedstaw fazy rozwoju j zyka UML.

Wyja nij relacje pomi dzy poj ciami:

t superstruktura UML,
t infrastruktura UML,
t XMI,
t wymienno ć diagramów UML,
t MOF.
30 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc
5R]G]LD� 0 -�]\N 80/ v UR]ZŃM VWUXNWXUD SRM�FLD
Czy modelowanie w j zyku UML ogranicza si do systemów informatycznych?

Odpowied uzasadnij.
Przedstaw klasyfikacj diagramów UML 2.0. Jakie diagramy nie wyst powały

we wcze niejszych wersjach tego standardu?
Jakie postacie mo e przyj ć dowolny diagram? Wska informacje zawarte

w nagłówku diagramu.
Wyja nij zale no ci pomi dzy nast puj cymi poj ciami:

t klasyfikator,
t instancja,
t klasa,
t obiekt.
Jakie perspektywy wyst puj w opisie architektury systemu? Omów istot

ka dej z nich.
Zapisz w jednej kolumnie wszystkie perspektywy architektury systemu,

a w drugiej poszczególne diagramy UML. Nast pnie powi odpowiednie
perspektywy z odpowiadaj cymi im diagramami.
Jaka jest rola mechanizmów rozszerzalno ci?

Wymie podstawowe mechanizmy rozszerzalno ci j zyka UML.

Opracuj przykłady:

t stereotypów tekstowych,
t ogranicze ,
t metek.
Modyfikacja sieci informatycznej uniwersytetu została udokumentowana

na stosownych diagramach. Zaprojektuj stereotypy graficzne odnosz ce si
do poszczególnych elementów sprz tu sieciowego.
Odszukaj w Internecie pod adresem www.omg.org aktualne specyfikacje

j zyka UML.
D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc (05-11-10) 31
 &]� Ł , 0 3RGVWDZ\ M�]\ND 80/
32 (05-11-10) D:\! AAA DZISIAJ\J zyk UML 2.0 w modelowaniu systemów informatycznych\06 poprawki\01.doc