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 | Un 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 ei oraz ej dwch modeli oprogramowania Si i Sj oraz dwie

interpretacje TiA = (Iia, UiA) i TjB = (IjB, UjB) tych modeli Si i Sj przypisanych im przez agentw

(aktorw) A i B w nastpujcy sposb:

(a) ei i ej nie pokrywaj si w ogle w odniesieniu do TiA i TjB jeli IiA(ei) , IjB(ej), i

IiA(ei) IjB(ej)=

(b) ei i ej pokrywaj si cakowicie w odniesieniu do TiA i TjB jeli IiA(ei) , IjB(ej), i

IiA(ei)= IjB(ej)

(c) ei pokrywa cakowicie (inkluzja) ej w odniesieniu do TiA i TjB jeli IiA(ei) , IjB(ej), i

IjB(ej) IiA(ei)

(d) ei pokrywa czciowo ej w odniesieniu do TiA i TjB jeli IiA(ei) , IjB(ej), IiA(ei)

IjB(ej), IiA(ei) - IjB(ej), i IjB(ej) - IiA(ei)

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 S1 ... Sn, zbir relacji pokrywania

pomidzy nimi Oa(Si, Sj) (i = 1, ..., n oraz j = 1, ..., n), dziedzin D oraz regu spjnoci CR.

Modele S1, ..., Sn uznajemy za niezgodne z dan regu spjnoci CR ze wzgldu na ich

pokrywanie si wyraone zbiorami Oa(Si, Sj) 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