1.

GENEROWANIE SPJNYCH MODELI UML Z MODELU

PRZESTRZENNEGO DOD
Stanisaw Jerzy NIEPOSTYN

, Ilona BLUEMKE

Streszczenie
Przedstawiono generowanie spjnych modeli UML z modelu przestrzennego Diagramu Obiegu
Dokumentw (DOD). Model przestrzenny DOD umoliwia zaprojektowanie struktury aplikacji,
jej zachowania i funkcjonalnoci. Taki sposb modelowania docelowego systemu umoliwia
otrzymanie zestawu wybranych i spjnych diagramw UML, pozwalajcy na peny i kompletny
opis architektury w perspektywie projektowej.
1. Wprowadzenie
Utworzenie prostego i zrozumiaego modelu opisujcego wszystkie aspekty projektowanego
oprogramowania nie jest moliwe. Dobrym pomysem okazao si przedstawienie architektury
oprogramowania za pomoc powizanych modeli opisujcych wybrane aspekty systemu
informatycznego. Przedstawianie tego samego systemu z rnych perspektyw moe jednak
prowadzi do powstania niespjnoci pomidzy modelami. Bardzo popularnym jzykiem do
budowy modeli opisujcych oprogramowanie jest jzyk UML (Unified Modeling Language) [8].
UML za pomoc rnorodnych diagramw pozwala opisa system informatyczny z rnych
perspektyw. Semantyka UML jest opisana w jzyku naturalnym i nie posiada cech jzyka
formalnego co znacznie ogranicza moliwoci kontroli spjnoci i kompletnoci diagramw
UML, jak rwnie caego systemu informatycznego opisywanego przez te diagramy. Konieczna

Politechnika Warszawska, Wydzia Elektroniki i Technik Informacyjnych, Instytut Informatyki, e-mail:

j.niepostyn@ii.pw.edu.pl; I.Bluemke@ii.pw.edu.pl.



jest kontrola spjnoci modeli. Obecne metody kontroli spjnoci modeli realizuje si poprzez
badanie pokrywania si modeli, identyfikacj i analiz niespjnoci pomidzy modelami.
W pracy zaproponowano kontrol spjnoci modeli UML poprzez utworzenie jednego spjnego
modelu w notacji DOD [3], a nastpnie wygenerowanie z niego kilku spjnych modeli UML.
Zamiast wic bada, analizowa i wykrywa niespjnoci pomidzy modelami UML, tak jak
realizowane jest to dotychczas, zaproponowano generowanie spjnych modeli, ktre nie
wymagaj implementacji kosztownych, czasochonnych i niepewnych regu kontroli spjnoci
modeli UML.
W pracy przedstawiono koncepcj kontroli spjnoci modeli UML w oparciu o
wygenerowane z modelu przestrzennego Diagram Obiegu Dokumentw 3D DOD spjne modele
UML. Przedstawiona koncepcja kontroli spjnoci modeli UML wykorzystuje popularny opis
architektury oprogramowania: model perspektyw architektonicznych 4+1 Philippe Kruchtena
[1], przy czym generowane modele UML opisuj wycznie perspektyw projektow
architektury oprogramowania. Definicj uywanej spjnoci pokazano w sekcji 2.
Model przestrzenny DOD, bdcy oryginalnym rozwizaniem Autorw [4], w skrcie
przedstawiony w sekcji 3, umoliwia wygenerowanie kompletnych i spjnych diagramw UML.
Pozwala take zaprojektowa spjne i kompletne diagramy UML poprzez odwzorowanie ich
poszczeglnych elementw w elementy diagramu 3D DOD. Transformacja tych trzech
diagramw UML w model przestrzenny DOD umoliwia weryfikacj ich spjnoci i
kompletnoci. Weryfikacja ta jest realizowana automatycznie i pozwala zachowa spjno i
kompletno projektowanego systemu. W sekcji 4 przedstawiono metamodel DOD i
transformacje pomidzy poszczeglnymi elementami modeli UML, a odpowiednimi elementami
modelu DOD. Transformacje te realizuje modeler Dodocum [5] implementujcy model
przestrzenny DOD, zrealizowany w rodowisku Topcased [7]. Wan cech modelera Dodocum
jest moliwo utworzenia diagramu DOD na podstawie diagramw UML (diagram klas,
stanw, przypadkw uycia). Waciwo ta pozwala na kontrol spjnoci i kompletnoci
trzech podstawowych diagramw UML (poprzez ich utworzenie i sprawdzenie moliwoci
transformacji do modelu DOD) na podstawie metamodelu DOD. W sekcji 4 pokazano take
przykady kontroli spjnoci modeli UML.
2. Spjno modeli
Problemem spjnoci modeli opisujcych system informatyczny zaczto si szczeglnie
interesowa w kocu lat osiemdziesitych. Wypracowano wtedy szereg technik, metod i



narzdzi do identyfikacji, analizy i obsugi rnych form niespjnoci w modelach poprzez
zastosowanie szerokiej gamy jzykw i notacji m.in.: Z, LOTOS, KAOS. Formalny opis
zagadnienia niespjnoci modeli, a take zarzdzania niespjnoci zaproponowali Spanoudakis
i Andrea Zisman w 2001 [6]. Zauwayli oni, e niespjnoci powstaj pomidzy modelami
opisujcymi ten sam system z rnych punktw widzenia i uywajcych wsplnych elementw.
Wsplny element moe by inaczej interpretowany w rnych modelach. Spanoudakis i Zisman
formalnie zdefiniowali niespjnoci, a nastpnie opisali gwne czynnoci w procesie
zarzdzania niespjnociami. Zaczli od definicji interpretacji.
Definicja 1. Interpretacja modelu oprogramowania S okrelonego jako zbir powizanych ze
sob elementw E jest to taka para (I, U), dla ktrej:
U jest niepust list oddzielnych zbiorw zwanych domenami (dziedzinami) interpretacji
modelu,
I jest zbiorem przeksztace, ktry odwzorowuje kady element e ze zbioru E na relacj
stopnia n taki, e R | U
n
zwany rozszerzeniem elementu e (n=1,2, ...,|U|).
Zgodnie z t definicj, interpretacja odwzorowuje kady element modelu na zbir jednostek lub
relacj midzy tymi jednostkami w danej dziedzinie, ktre s oznaczone przez ten element.
Zatem interpretacja odzwierciedla to, jak agent (agentem moe by zarwno osoba jak i
komponent systemu) rozumie model oprogramowania w odniesieniu do danej dziedziny.
Posugujc si powysz definicj interpretacji okrelili rodzaje pokrywania si modeli
oprogramowania.
Definicja 2. Dana jest para elementw e
i
oraz e
j
dwch modeli oprogramowania S
i
i S
j
oraz dwie
interpretacje T
iA
= (I
ia
, U
iA
) i T
jB
= (I
jB
, U
jB
) tych modeli S
i
i S
j
przypisanych im przez agentw
(aktorw) A i B w nastpujcy sposb:
(a) e
i
i e
j
nie pokrywaj si w ogle w odniesieniu do T
iA
i T
jB
jeli I
iA
(e
i
) , I
jB
(e
j
), i
I
iA
(e
i
) I
jB
(e
j
)=
(b) e
i
i e
j
pokrywaj si cakowicie w odniesieniu do T
iA
i T
jB
jeli I
iA
(e
i
) , I
jB
(e
j
), i
I
iA
(e
i
)= I
jB
(e
j
)
(c) e
i
pokrywa cakowicie (inkluzja) e
j
w odniesieniu do T
iA
i T
jB
jeli I
iA
(e
i
) , I
jB
(e
j
), i
I
jB
(e
j
) I
iA
(e
i
)
(d) e
i
pokrywa czciowo e
j
w odniesieniu do T
iA
i T
jB
jeli I
iA
(e
i
) , I
jB
(e
j
), I
iA
(e
i
)
I
jB
(e
j
), I
iA
(e
i
) - I
jB
(e
j
), i I
jB
(e
j
) - I
iA
(e
i
)
Zgodnie z t definicj, dwa elementy modelu pokrywaj si cakowicie, jeli posiadaj
identyczne interpretacje, pokrywaj si czciowo, jeli nie posiadaj identycznych.



Pokrywajce si interpretacje - jeden element pokrywa wcznie drugi, jeli interpretacja jednego
z elementw zawiera interpretacj drugiego. Dwa elementy nie pokrywaj si, jeli posiadaj
rozczne interpretacje. Relacja pokrywania si elementw modeli identyfikowana jest przez
aktora, std te niespjno elementw moe by ledzona dopiero po jej stwierdzeniu przez
aktora.
Wykorzystujc interpretacj i rodzaje pokrywania si modeli ostatecznie Zisman i
Spanoudakis zaproponowali definicj niespjnoci.
Definicja 3. Przyjmijmy zbir modeli oprogramowania S
1
... S
n
, zbir relacji pokrywania
pomidzy nimi O
a
(S
i
, S
j
) (i = 1, ..., n oraz j = 1, ..., n), dziedzin D oraz regu spjnoci CR.
Modele S
1
, ..., S
n
uznajemy za niezgodne z dan regu spjnoci CR ze wzgldu na ich
pokrywanie si wyraone zbiorami O
a
(S
i
, S
j
) i dziedzin D, jeeli mona wykaza, e regua
spjnoci CR nie jest speniona przez modele.
Dziedzina D w tej definicji moe wyrazi pewn ogln wiedz na temat domeny systemu, ktry
jest opisany przez modele i/lub pewn ogln wiedz z zakresu inynierii oprogramowania (np.
zalenoci pomidzy jakoci, a wzorcami projektowymi architektury systemu).
Spanoudakis i Zisman zaproponowali take metod zarzdzania niespjnoci, w ktrej
wyrnili nastpujce etapy:
detekcja pokrywania si modeli - czynno wykonywana przez odpowiednia osob w
celu identyfikacji pokrywania si modeli oprogramowania,
detekcja niespjnoci modeli - czynno wykonywana w celu sprawdzenia naruszenie
zasad spjnoci przez modele oprogramowania,
diagnoza niespjnoci - czynno zwizana z identyfikacj rda, przyczyn i skutkw
niespjnoci,
obsuga niespjnoci - identyfikacja moliwych dziaa obsugi niespjnoci; ocena
kosztw i korzyci powyszych dziaa; ocena ryzyka wynikajcego z braku obsugi
niespjnoci; wybr akcji do wykonania,
ledzenie wynikw obsugi niespjnoci - zapis uzasadnienia powstania niespjnoci;
zapis rde, przyczyn i wpywu niespjnoci, zapis dziaa zwizanych z obsug
wykrytej niespjnoci, zapis uzasadnienia decyzji o wyborze jednej z opcji i odrzuceniu
innych
specyfikacja i implementacja polityk niespjnoci - specyfikacja: agentw do
identyfikacji pokrywania si modeli; regu spjnoci; warunkw uruchamiajcych
wykrywanie pokrywania si modeli i ich niespjnoci; mechanizmw diagnozowania



niespjnoci; mechanizmw oceny wpywu niespjnoci; mechanizmw oceny kosztw,
korzyci i zagroe zwizanych z rnymi opcjami obsugi niespjnoci; osb
odpowiedzialnych za obsug niespjnoci.

2.1. Wymiary perspektywy architektury oprogramowania
Obecnie brak jest narzdzi pozwalajcych weryfikowa spjno i kompletno projektowanego
systemu pomidzy rnymi modelami m.in. perspektywy projektowej. W projektach budowy
oprogramowania z zastosowaniem notacji UML [8], najpierw tworzy si diagram przypadkw
uycia, nastpnie diagram klas i diagram stanw. Naleaoby przede wszystkich zadba o
spjno tych trzech podstawowych diagramw UML. Diagramy te zwane przez nas
odpowiednio wymiarem funkcjonalnoci (diagram przypadkw uycia), zachowania (diagram
stanw) oraz struktury (diagram klas) tworz razem wystarczajcy opis perspektywy projektowej
(logicznej). Diagramy te, jak pokazano na Rys.1, posiadaj elementy, ktre w ogle si nie
pokrywaj, gdy posiadaj rozczne interpretacje (Definicja 2. (a)). Zatem odpowiednie
sprzenie tych diagramw (wymiarw) mogoby znacznie uatwi zachowanie spjnoci i
kompletnoci budowanego modelu. Sprzenie tych diagramw, czy wymiarw przedstawiaoby
model, ktry mona by nazwa tymczasowo modelem Trzy w jednym - 3D. Zaprojektowanie
za stosownych transformacji umoliwioby automatyczne generowanie z takiego modelu trzech
podstawowych diagramw UML, a take umoliwioby kontrol spjnoci tych trzech
diagramw UML. Kontrola spjnoci diagramw UML odbywa si poprzez poprawne
zbudowanie na ich podstawie jednego, spjnego modelu 3DOD, zamiast tworzenia i
sprawdzanie rozbudowanych regu spjnoci na tworzonych modelach UML.

Rys.1. Trzy wymiary perspektywy architektury oprogramowania



3. Model przestrzenny DOD
Na Rys. 2 przedstawiono przykad prostego procesu biznesowego zamodelowanego za pomoc
diagramu DOD wraz z jego rzutami od frontu, z gry oraz z dou. Rzuty te mona interpretowa
jako sprzone z DOD diagramy UML opisujce perspektyw logiczn. Rzut z gry mona
interpretowa jako diagram stanw dla wszystkich obiektw, rzut z dou mona interpretowa
jako diagram klas, a rzut od frontu jako diagram przypadkw uycia. Szczegowy opis
powiza pomidzy poszczeglnymi elementami diagramu DOD, a jego rzutami
interpretowanymi jako poszczeglne diagramy UML zamieszczono w [4]. Ponadto w pracy
[?4?] przedstawiono sposb uzyskania stosownych transformacji na przykadzie poszczeglnych
rzutw trjwymiarowego modelu przestrzennego DOD (3D DOD) na odpowiednio dobrane
paszczyzny. Odpowiednie rzuty modelu przestrzennego 3D DOD mona interpretowa jako
odwzorowanie czci elementw diagramu DOD na konkretny diagram UML reprezentujcy
wyrniony wymiar perspektywy projektowej.

Rys. 2. Model przestrzenny DOD i jego rzuty



Odwzorowanie odpowiednich diagramw UML w czci elementw diagramu DOD
pozwala zaprojektowa spjne i kompletne diagramy UML. Mechanizm odwzorowania
diagramw UML na diagram DOD zapewnia automatyczn weryfikacj spjnoci i
kompletnoci skadowych diagramw UML. Weryfikacja spjnoci i kompletnoci
projektowanego systemu realizowana jest automatycznie w trakcie budowy poprawnego modelu
przestrzennego DOD. Skadowe diagramy UML tworzc poprawny proces biznesowy w
DOD, jednoczenie speniaj wymagania spjnoci i kompletnoci projektowanego
systemu. Do implementacji tego mechanizmu niezbdne jest zdefiniowanie metamodelu DOD
oraz zaprojektowanie transformacji pomidzy metamodelem DOD, a odpowiednimi
fragmentami metamodelu UML.

4. Modeler Dodocum
Modeler Dodocum jest implementacj modelu przestrzennego DOD zrealizowan w rodowisku
Topcased na platformie Eclipse. Reguy opisujce metamodel Dodocum umoliwiaj
weryfikacj spjnoci i kompletnoci diagramw UML, z ktrych budowany jest diagram DOD.
Proces weryfikacji spjnoci i kompletnoci polega na transformacji modelu zawierajcego trzy
podstawowe diagramy UML do jednego modelu DOD. Zasadniczymi elementami
wspomnianego wyej procesu jest metamodel DOD (pokazany w sekcji 4.1) oraz transformacje
pomidzy fragmentami metamodelu UML, a metamodelem DOD (sekcja 4.2). Do obsugi
diagramw UML wykorzystano istniejc wtyczk UML2 w rodowisku Topcased. Poniej
pokazano metamodel DOD, a nastpnie zaprezentowano transformacje z UML do DOD, po
czym zamieszczono przykady obrazujce prac modelera Dodocum.
4.1. Uproszczony metamodel DOD
Na Rys. 3 przedstawiono uproszczony metamodel Diagramu Obiegu Dokumentw. Na
diagramie zaznaczono poszczeglne elementy, ktre wykorzystywane s do opisu wymiaru
funkcjonalnoci, struktury oraz zachowania. Metamodel ten skada si ze wsplnych oraz
rozcznych znaczeniowo elementw. Wsplnym elementem integrujcym wymiary jest
Operacja (Operation), natomiast pozostae elementy, oprcz elementu Dokument (Document),
wystpuj wycznie w jednym konkretnym wymiarze. Std model DOD umoliwia zachowanie
spjnoci i kompletnoci tych trzech wymiarw zgodnie z definicj niespjnoci modeli podan
przez Spanoudakisa i Zismana. Szczegowy opis modelera Dodocum przedstawiono w [5].




Rys. 3. Uproszczony metamodel Diagramu Obiegu Dokumentw
4.2. Transformacje UML-to-DOD
Na Rys. 4 pokazano zaprezentowano transformacje pomidzy elementami uproszczonego
metamodelu UML dla klas a elementami metamodelu DOD. Element UML Class jest
jednoznacznie odwzorowany na element DOD Object, natomiast element UML Association
moe wymaga utworzenia wielu elementw DOD przedstawiajcych przepyw danych
pomidzy elementami DOD Object (a raczej instancjami DOD Object - Documents). Element
UML Operation odpowiadaa jednoznacznie elementom DOD Operation.




Rys.4. Transformacje pomidzy elementami diagramu klas a elementami DOD

Rys.5. Transformacje pomidzy elementami diagramu stanw a elementami DOD
Na Rys. 5 pokazano transformacje pomidzy elementami uproszczonego metamodelu UML dla
diagramu przypadkw uycia a elementami metamodelu DOD. Elementy Actor oraz UseCase
odpowiadaj jednoznacznie elementom DOD (Actor oraz Operation). Element Association z



metamodelu UML dla przypadkw uycia wyznaczany jest na podstawie przynalenoci danej
operacji DOD do konkretnego aktora DOD.
Rys. 6 pokazuje transformacje pomidzy elementami uproszczonego metamodelu UML
w czci opisujcej diagram stanw, a elementami metamodelu DOD. Elementowi UML Region
odpowiadaj odpowiednio pogrupowane stany konkretnego elementu DOD Document, bd sam
element Object, a elementowi UML State odpowiada element DOD Operation. W oglnoci
elementowi UML Transition moe odpowiada wiele elementw diagramu DOD zwizanych z
przepywem dokumentw pomidzy aktorami DOD.


Rys.6. Transformacje pomidzy elementami diagramu UseCase a elementami DOD

W przedstawionych wyej transformacjach nie pokazano wszystkich regu i zalenoci
pomidzy poszczeglnymi elementami z metamodelu UML oraz DOD. Gwnym elementem
diagramu DOD wicym poszczeglne elementy pozostaych diagramw UML jest element
DOD Operation. Elementowi Operation odpowiada jednoznacznie element UML UseCase z
diagramu przypadkw uycia, a take element UML State z diagramu stanw. Element DOD
Operation jest jednoznacznie zdefiniowany zarwno dla elementu DOD Actor, jak i dla elementu



DOD Object. Element DOD Object jest jednoznacznie zdefiniowany dla elementu UML Class
diagramu klas, wic utworzenie diagramu DOD z tych trzech diagramw UML pozwala
zachowa spjno i kompletno tych diagramw UML.
W trakcie implementacji tych transformacji w modelerze Dodocum okazao si
konieczne takie okrelenie nazw niektrych elementw z diagramw UML (stany i przypadki
uycia), by moliwa bya identyfikacja elementw DOD Operation. Zrealizowano to poprzez
utworzenie nazwy stanu oraz przypadku uycia za pomoc zczenia nazwy rodzaju operacji i jej
numeru (np. Utworzenie02). Podobny mechanizm zastosowano przy identyfikacji elementu
DOD Object na podstawie stanu zoonego z diagramu stanw i klasy z diagramu klas.
Omawiane elementy UML musiay mie identyczn nazw jak element Object z diagramu DOD.
Istotn wasnoci diagramu stanw okazao si numerowanie przej pomidzy stanami, a take
okrelanie punktw wejcia i wyjcia. Przejcia musiay by okrelane w taki sposb, by powsta
diagram DOD z prawidowymi numerami elementw Operation oraz tych przej. Powysze
niedogodnoci mona niwelowa poprzez wielokrotne generowanie diagramu DOD z
diagramw UML, a nastpnie odwrotne generowanie diagramw UML z diagramu DOD w
trakcie iteracyjnego rozwoju modeli.
4.3. Przykady kontroli spjnoci modeli UML
Na Rys. 7 przedstawiono diagramy UML opisujce perspektyw logiczn czci systemu
informatycznego ECS/ICS dla Suby Celnej. System ECS/ICS przeznaczony jest do kontroli
eksportu towarw poza obszar celny Unii Europejskiej oraz importu towarw na jej obszar.
Przedstawiony model jest jedynie wstpnym szkicem systemu ECS/ICS w czci obsugi
eksportu towarw. Pominito przy tym diagram klas, ktry mona otrzyma wprost z diagramu
stanw (stany zoone reprezentuj poszczeglne instancje klas).




Rys.7. Diagramy UML opisujce perspektyw logiczn systemu informatycznego ECS
Na Rys.8 pokazano diagram DOD otrzymany z transformacji diagramw UML, natomiast w
prawej czci diagram klas wstecznie wygenerowany z tego diagramu DOD. Podstawowym
diagramem jest diagram stanw, gdzie zaznaczono numery i rodzaje stanw, ktre wraz z
odpowiadajcymi im nazwami przypadkw uycia umoliwi utworzenie elementw DOD
Operation. Jest to jedna z podstawowych regu transformacji diagramw UML do diagramu
DOD. Kolejn cech transformacji UML-to-DOD, jest odpowiednio nazw stanw zoonych
wzgldem klas. Zasadnicz regu umoliwiajc zbudowanie poprawnego diagramu DOD jest
prawidowo oznaczania sekwencji przechodzenia stanw i tranzycji pomidzy nimi. Brak
prawidowej sekwencji przej nie zawsze jest moliwy do zidentyfikowania, dlatego polecanym
sposobem tworzenia caego modelu jest generowanie diagramu DOD z modeli UML, przegld
diagramu DOD, a nastpnie wsteczne wygenerowanie diagramw UML z diagramu DOD (np.
diagram klas na Rys. 8).
Wsteczne wygenerowanie diagramu stanw oraz diagramu przypadkw uycia z
diagramu DOD nie wnosi istotnych zmian w porwnaniu z oryginalnymi diagramami, o ile nie
wniesiono zmian do diagramu DOD. Zmiany w diagramie DOD jak i w diagramach UML
mona wprowadza iteracyjnie, dbajc o spjno i kompletno modeli poprzez wygenerowanie



modelu DOD na podstawie diagramw UML, a nastpnie wsteczne wygenerowanie diagramw
UML na podstawie diagramu DOD w kolejnych iteracjach.


Rys.8. Diagram DOD utworzony na podstawie diagramw UML oraz diagram klas wstecznie
wygenerowany z diagramu DOD
5. Podsumowanie
W niniejszej pracy przedstawiono proces automatycznej kontroli spjnoci i kompletnoci
wybranych modeli UML, opisujcych perspektyw projektow systemu informatycznego, w
oparciu o metamodel DOD oraz odpowiednio zaprojektowane transformacje pomidzy
metamodelem DOD, a stosownymi fragmentami metamodelu UML. Proces ten



zaimplementowano w modelerze Dodocum. Narzdzie Dodocum pokazuje, e metoda
automatycznej kontroli diagramw UML w oparciu o metamodele innych notacji moe by
skutecznym sposobem na usunicie luk w procesie budowy oprogramowania pomidzy etapem
opracowywania wymaga, a etapem tworzenia kodw rdowych. Pokazana metoda pozwala
take czy zalety innych notacji z zaletami UML. W dotychczasowej praktyce autorw
zastosowanie opisanego modelera Dodocum znacznie wzbogacio, przypieszyo i
zautomatyzowao wiele prac zwizanych z projektowaniem i budow aplikacji poprzez
wykorzystanie zalet zarwno jzyka UML jak i innych notacji. Diagramy DOD byy
zastosowane przy analizie i projektowaniu systemu IACS (Integrating Administration Control
System) przy wdraaniu dopat UE dla rolnictwa. W notacji DOD zaprojektowano ponad 100
diagramw opisujcych procesy biznesowe, gdzie kady diagram opisywa do 10 obiektw i do
7 aktorw. Po kilku dniach uytkownicy potrafili sami projektowa poszczeglne procesy
biznesowe, a take byli w stanie szybko identyfikowa nieodpowiednie przepywy w procesach
biznesowych. DOD wykorzystano take w systemie Produkcja dla Polmos Stalowa Wola we
wsppracy ze spk Comers. W notacji DOD zaprojektowano wwczas 12 diagramw
opisujcych procesy biznesowe, gdzie kady diagram opisywa do 12 obiektw i do 6 aktorw.
Model przestrzenny DOD wykorzystano przy analizie i projektowaniu systemu informatycznego
dla RWE Poland. Model przestrzenny DOD bardzo dobrze nadaje si do transformacji modeli z
jednej notacji (np. UML) do innej notacji (m.in. XPDL) ze wzgldu na spjny opis modelu w
zakresie funkcjonalnoci, struktury i zachowania. Diagramy w notacji 3D DOD mog by
bezporednio transformowane na diagramy UML (diagram klas, diagram stanw, diagram
przypadkw uycia przygotowaniu). Mog by rwnie transformowane na pliki xml i w formie
procesw biznesowych (standard XPDL) mog by przenoszone do innych systemw, czy
narzdzi obsugujcych procesy biznesowe. Planuje si opracowanie transformacji pomidzy
modelami BPMN, EPC, jPDL, BPEL. Obecnie modeler Dodocum jest bezpatnie dostpny do
pobrania na stronie www.project-media.pl.
Bibliografia
1. Kruchten P.: Architectural BlueprintsThe 4+1 View Model of Software Architecture,
IEEE Software 12 (6) November 1995, pp. 42-50
2. Kruchten P.: The Rational Unified Process: An Introduction, 3 ed., Boston: Addison-
Wesley, 2003.



3. Niepostyn S., Bluemke I.: Diagramy obiegu dokumentw a UML w modelowaniu
procesw biznesowych, w Inynieria Oprogramowania - od teorii do praktyki praca
zbiorowa ed. Z. Huzar i Z. Mazur, Wydawnictwa Komunikacji i cznoci, 2008, rozdzia
3, ss. 37-47,
4. Niepostyn S., Bluemke I.: Model przestrzenny DOD, w Od modelu do wdroenia.
Kierunki bada i zastosowa inynierii oprogramowania cz 6, wyd. Wydawnictwa
Komunikacji i cznoci, 2009, rozdzia 29, ss. 343-352
5. Niepostyn S., Bluemke I.: Modeler modelu przestrzennego DOD w rodowisku
TOPCASED. Metody Informatyki Stosowanej, 2009 numer 2, strony 81-91.
6. Spanoudakis, G., Zisman, A., Inconsistency management in software engineering: survey
and open research issues, w Chang, S.K. (Ed.), Handbook of Software Engineering and
Knowledge Engineering, World Scientific Publishing Co., Singapore. pp. 329-380.
7. TOPCASED, The Open-Source Toolkit for Critical Systems, http://www.topcased.org
8. Unified Modeling Language, http://www.omg.org