Fragment opublikowanego artykułu:
S.J.Niepostyn, Ilona Bluemke, Model przestrzenny DOD, XI Krajowa Konferencja Inżynierii Oprogramowania KKIO 2009, 14-17.09.2009, Pułtusk, w: W. Dąbrowski, A. Stasiak (red.), Od modelu do wdrożenia – kierunki badań i zastosowań inżynierii oprogramowania, WKŁ, Warszawa 2009, 343-352. ISBN 978-83-206-1747-4.

Model perspektyw architektonicznych „4 + 1” Kruchtena uporządkował metodę tworzenia oprogramowania opartą na opracowywaniu kolejnych modeli od scenariuszy, aż do perspektywy fizycznej budowanego systemu informatycznego. Model ten jest również podstawą metodyki RUP. Model Kruchtena jednakże jest dość ogólnym zarysem rozwiązania opartego na modelowaniu kolejnych perspektyw i niestety nie daje wyczerpujących odpowiedzi na pytania pojawiające się przy odwzorowywaniu poszczególnych elementów z jednej perspektywy na inną. Co więcej model 4 + 1 nie wskazuje nawet powiązań między elementami z poszczególnych diagramów w zakresie danej perspektywy, czy też pomiędzy perspektywą „+1”, a pozostałymi perspektywami „4”. Niniejszy artykuł opisuje model przestrzenny DOD, który w znacznej części pokazuje stosowne odwzorowania pomiędzy wymiarami wybranych perspektyw modelu Kruchtena, a także umożliwia określenie kompletności modelu, a więc i moment zakończenia prac projektowych nad wybraną perspektywą. Model przestrzenny DOD ma zastosowanie przede wszystkim do prac nad perspektywą przypadków użycia oraz perspektywą logiczną docelowego systemu.

1.      Wstęp

Model perspektyw architektonicznych „4 + 1” Kruchtena 4 opisuje proces tworzenia oprogramowania, w którym elementy z pewnych perspektyw są dość luźno powiązane z elementami innych perspektyw na zasadzie bliżej nieokreślonych reguł decyzyjnych oraz heurystyk. Innymi słowy proces tworzenia oprogramowania w dużym stopniu zależny jest od wiedzy i doświadczenia projektantów docelowego systemu. Nadrzędną perspektywą w tym modelu jest perspektywa przypadków użycia (scenarios - Rysunek 1). Jej głównym zadaniem jest kontrola i nadzorowanie procesu tworzenia pozostałych perspektyw.

Biorąc pod uwagę metodykę RUP 4, która bardziej szczegółowo opisuje sposób budowy oprogramowania w oparciu o model perspektyw architektonicznych 4+1, należy zauważyć, że w metodyce tej brakuje wyraźnych powiązań pomiędzy perspektywą przypadków użycia („+1”), a pozostałymi perspektywami („4”). Ponadto trudno dostrzec powiązania pomiędzy zachowaniem, a strukturą systemu (dwa główne typy diagramów UML - 4) w danej perspektywie, a także należy wskazać na brak jednoznacznych związków pomiędzy elementami (nawet całymi perspektywami) w pozostałych perspektywach „4”. Jednocześnie można stwierdzić, na podstawie dotychczasowych doświadczeń autorów, że rozważanie struktury projektowanego systemu bez uwzględniania jego zachowania (i na odwrót) zazwyczaj prowadzi do niespójnych i niekompletnych modeli docelowego systemu.

Rysunek 1 Model perspektyw architektonicznych “4 + 1” [4]

Rozwiązaniem powyższych niedostatków modelowania systemów informatycznych mógłby być model, który wiązałby w danej perspektywie wszystkie te diagramy, które są niezbędne do opisu odpowiednich aspektów (wymiarów) architektury danej perspektywy, a z drugiej strony opisywałby architekturę systemu w danej perspektywie w ten sposób, że „pozostałoby tylko to, gdy nie można już usunąć niczego więcej, a system ciągle jest zrozumiały i można objaśnić jego działanie” - 4.

W niniejszym artykule zaproponowano model przestrzenny Diagramu Obiegu Dokumentów (3DOD) pozwalający spełnić powyższy postulat oraz umożliwiający skonstruowanie kompletnego i spójnego mechanizmu wiązania ze sobą poszczególnych diagramów (elementów) do opisu perspektywy logicznej. Model ten składa się z kilku diagramów UML (reprezentujących określone wymiary wybranej perspektywy) zintegrowanych jednoznacznie z diagramem DOD.

W dalszej części podrozdziału objaśniono termin „wymiar” używany do opisu wybranej perspektywy (logicznej), a następnie opisano przykład procesu biznesowego, który posłuży do zaprezentowania modelu 3DOD. W przykładzie tym zobrazowano odpowiednie odwzorowania pomiędzy poszczególnymi elementami z różnych diagramów (wymiarów) za pomocą trójwymiarowego modelu przestrzennego na bazie DOD.

2.      Wymiary perspektyw architektury

W trakcie modelowania docelowego systemu projektanci mają do dyspozycji przeróżne diagramy UML, za pomocą których mogą konstruować architekturę systemu. W standardzie UML poszczególne diagramy zostały podzielone na dwie części – zachowanie oraz struktura. Modelowanie docelowego systemu zazwyczaj rozpoczyna się od konstruowania perspektywy przypadków użycia (diagram przypadków użycia – zachowanie systemu), gdzie tworzy się poszczególne scenariusze. Dodatkowo, oprócz tekstowych opisów, wykorzystuje się do wizualizacji scenariuszy diagramy aktywności (zachowanie systemu), czy też diagramy sekwencji (zachowanie systemu). Równocześnie modeluje się docelowy system w perspektywie logicznej wykorzystując zazwyczaj diagram klas, czy diagram obiektów (struktura systemu), a także diagramy sekwencji oraz diagramy stanów (zachowanie systemu) - 4, 4.

Jak widać powyższa technika wykorzystywania poszczególnych diagramów w opisie danej perspektywy wynika raczej z heurystyk i doświadczenia projektantów systemu. Wprowadzając jednakże pojęcie wymiaru danej perspektywy, można uporządkować pewne zależności i odwzorowania pomiędzy poszczególnymi elementami z wybranych diagramów używanych do modelowania danej perspektywy. Zachowanie systemu (wymiar zachowania) można zamodelować m.in. za pomocą diagramów sekwencji, czy stanów. Strukturę systemu (wymiar struktury) można zamodelować za pomocą diagramu klas, czy diagramu obiektów, natomiast funkcjonalność systemu można zamodelować za pomocą diagramu przypadków użycia (wymiar funkcjonalności). Jednocześnie można zauważyć, że złożeniem tych trzech wymiarów może być diagram obrazujący realizację przypadków użycia (zazwyczaj diagram aktywności, bądź diagram sekwencji). Innymi słowy za pomocą diagramu opisującego realizację przypadków użycia można powiązać ze sobą pozostałe wymiary perspektywy logicznej oraz wymiar funkcjonalności (identyczny z wymiarem funkcjonalności perspektywy przypadków użycia).

Na Rysunek 2 pokazano na pewnym abstrakcyjnym przykładzie perspektywę logiczną zamodelowaną za pomocą diagramów UML reprezentujących poszczególne wymiary: diagram obiektów (struktura); diagram stanów obiektów (zachowanie) oraz diagram przypadków użycia (funkcjonalność). Diagramy te są w pewnym sensie do siebie ortogonalne. Sprzężenie zaś tych diagramów (wymiarów) może znacznie ułatwić zachowanie spójności i kompletności budowanego modelu. Oznacza to, że zmiana w danym wymiarze (diagramie) może pociągnąć za sobą zmiany w pozostałych wymiarach (diagramach) tak, by została zachowana spójność i kompletność modelu.

Rysunek 2 Wymiary perspektywy architektury oprogramowania

Uwzględniając te wszystkie trzy wymiary (poszczególne diagramy UML) w jednym modelu przestrzennym okazuje się, że najlepszym przybliżeniem takiego „wspólnego” diagramu (modelu) jest Diagram Obiegu Dokumentów.

W dalszej części artykułu przedstawiono własności modelu przestrzennego DOD, a następnie zaprezentowano wnioski wynikające z zastosowania tego modelu 3DOD do spójnego i kompletnego opisu architektury oprogramowania w perspektywie logicznej.

3.      Model 3DOD

Na Rysunek 3 przedstawiono przykład prostego procesu biznesowego zamodelowanego za pomocą diagramu DOD oraz „sprzężonych” z DOD diagramami UML opisującymi perspektywę logiczną. Diagram DOD posiada proste i jednoznaczne powiązania m.in. z diagramem obiektów (struktura), diagramem stanów (zachowanie) oraz diagramem przypadków użycia (funkcjonalność).

 Rysunek 3 DOD – perspektywa pośrednia pomiędzy perspektywami „4”, a „1”

Każdemu obiektowi z nagłówka diagramu DOD (oprócz rejestrów i innych systemów) odpowiada jeden obiekt. Natomiast związki pomiędzy obiektami wyznacza się poprzez identyfikację przepływów informacji (poziome strzałki) pomiędzy obiektami (egzemplarzami obiektów) na diagramie DOD. Ponadto dla każdego takiego obiektu zidentyfikowanego na diagramie DOD można w prosty i jednoznaczny sposób wyznaczyć jego zachowanie (diagram stanów). Ponieważ operacje w DOD są nazwane i jest ich ograniczona liczba, więc z powodzeniem można wykorzystać nazwy operacji z DOD do nazwania stanów obiektów na diagramie stanów. W podobny sposób można odwzorować elementy z diagramu DOD na diagram przypadków użycia.

Na diagramie DOD, dla każdego obiektu, wyraźnie zaznaczona jest kolejność w jakiej wykonywane są poszczególne operacje na tym obiekcie (egzemplarzu obiektu). Stąd też również i przejścia na diagramie stanów odwzorowane są w sposób jednoznaczny z odpowiednich przepływów na diagramie DOD. W celu zwiększenia czytelności podanego mechanizmu odwzorowań, zaznaczono w nazwach obiektów numery używane na diagramie DOD. Podobną technikę oznaczeń zastosowano na diagramie stanów – podane numery z diagramu stanów odpowiadają odpowiednim numerom operacji i przepływów z diagramu DOD. Diagram przypadku użycia nie wymaga tej techniki. Przykładowo na Rysunek 3 pokazano odwzorowania poszczególnych elementów na diagram przypadków użycia. Jako przypadek użycia systemu zidentyfikowano każdą operację z diagramu DOD i przypisano ją do odpowiedniego aktora, który również wyznaczany jest jednoznacznie z diagramu DOD. W nazwach systemowych przypadków użycia dodatkowo zamieszczono numery operacji, którym odpowiadają zidentyfikowane przypadki użycia. Na Rysunek 3 nie zobrazowano wszystkich odwzorowań w celu zwiększenia czytelności zastosowanej techniki.

Rysunek 4 Model przestrzenny DOD

W celu lepszego zobrazowania opisanego wyżej mechanizmu odwzorowania elementów diagramu DOD na poszczególne elementy odpowiednich diagramów UML zaprezentowano na Rysunek 4 trójwymiarowy model przestrzenny DOD (3DOD). W modelu tym poszczególne jego rzuty na odpowiednio dobrane płaszczyzny można potraktować jako odwzorowanie części elementów diagramu DOD na konkretny diagram UML reprezentujący wyróżniony wymiar perspektywy logicznej. Dla zwiększenia przejrzystości dokonano pewnych uproszczeń. I tak nie pokazano grotów na krawędziach, operacja akceptacji (podpisania) została przedstawiona w formie krzyżyka przestrzennego, zamiast trójkąta obrazującego operację archiwacji zastosowano stożek ze zdegradowaną podstawą do sześciokąta, by widoki z dołu i z góry różniły się dla operacji archiwizacji oraz dla operacji utworzenia dokumentu. Ponadto w kolejnych rysunkach wprowadzono pewne płaszczyzny, które przykrywają inne obszary modelu przestrzennego w celu uwypuklenia odwzorowania konkretnych elementów modelu.

3.1.   Realizacja biznesowego Przypadku użycia – diagram DOD

Rysunek 5 Diagram DOD – realizacja przypadku biznesowego

Przy rozpatrywaniu modelu przestrzennego procesów należy zauważyć, że rzut modelu przestrzennego od frontu jest po prostu diagramem DOD (Rysunek 5). Diagram DOD reprezentuje realizację biznesowego przypadku użycia (np. rozpatrzenie podania). Przy czym w diagramie DOD, dla uproszczenia, pomija się krawędzie łączące poszczególne operacje wykonywane na egzemplarzu dokumentu, a łączy się wyłącznie poszczególne egzemplarze (które zawierają te operacje). W modelu przestrzennym natomiast łączone są ze sobą poszczególne operacje. Rozważając model przestrzenny oraz jego rzut od przodu (diagram DOD) można powiedzieć, że ujęcie to jest pierwszoplanowym widokiem modelu przestrzennego. Zazwyczaj model biznesowy procesu (DOD) rozpoczyna się od uszczegółowienia diagramu aktywności dekomponowanych procesów biznesowych. Jednakże diagram aktywności nie posiada tak adekwatnej postaci jak diagram DOD, by w sposób jednoznaczny zintegrować ten diagram z innymi diagramami UML.

Rozważając model DOD można zauważyć, że pomijając przepływy pomiędzy operacjami oraz przyjmując, że pomiędzy aktorami, a operacjami wykonywanymi przez tych aktorów występują stosowne asocjacje otrzymamy diagram przypadków użycia. Oznacza to, iż z modelu 3DOD można jednoznacznie wyznaczyć wymiar funkcjonalności. Wymiar ten jest identyczny dla perspektywy logicznej jak i dla perspektywy przypadków użycia.

W dalszej części dokumentu pokazano kolejne rzuty modelu przestrzennego, które można zinterpretować jako pewne diagramy UML. Ponieważ diagramy te są po prostu rzutami modelu przestrzennego, więc są sprzężone z diagramem DOD. Ponadto jako ortogonalne diagramy do DOD mogą być rozwijane, uzupełniane i pielęgnowane przez innych uczestników procesu budowy systemu informatycznego (np. przez architektów systemu, projektantów baz danych, programistów) bez zbytnich modyfikacji np. samego diagramu DOD.

3.2.   WYMIAR STRUKTURY – DIAGRAM OBIEKTÓW

Przykrywając inne rejony dolnego rzutu rozważanego modelu 3DOD, a odkrywając inne można zauważyć, że dolny rzut modelu przestrzennego (Rysunek 6) można interpretować jako diagram obiektów perspektywy logicznej. Przy czym należy brać pod uwagę wyłącznie związki pomiędzy obiektami. Ponadto operacje wykonywane na dokumentach (egzemplarzach obiektów) mogły by być odwzorowywane na metody danego obiektu. Związki między obiektami biznesowymi odwzorowywane są z przepływów danych diagramu DOD (poziome strzałki). Widać z tego, że świetnym uzupełnieniem diagramu DOD byłaby możliwość definiowania atrybutów w obiektach znajdujących się w nagłówku diagramu DOD. W obecnej wersji diagramu DOD zrezygnowano z tego typu uszczegóławiania modelu poprzestając na jego prostocie opisu.

Rysunek 6 Wygenerowany diagram obiektów z modelu 3DOD

3.3.   WYMIAR ZACHOWANIA – DIAGRAM STANÓW

Dolna płaszczyzna znakomicie oddaje diagram stanów poszczególnych obiektów – Rysunek 7. Na poziomej osi znajdują się poszczególne obiekty, natomiast na osi pionowej stany tych obiektów. W diagramach DOD dla uproszczenia ujednolicono zakres dopuszczalnych stanów, jakie może przyjmować dany obiekt. Przy czym należy zauważyć, że na diagramach DOD stany te odwzorowane są z operacji wykonywanych na poszczególnych egzemplarzach obiektu. Natomiast przejścia pomiędzy stanami zostały odwzorowane z przepływów dokumentów (poziome strzałki) diagramu DOD. Diagram stanów opisuje zachowanie poszczególnych obiektów systemu.

Rysunek 7 Wygenerowany diagram stanów z modelu 3DOD

3.4.   Model 3DOD – inne diagramy

Z przedstawionego opisu modelu przestrzennego procesów biznesowych opartego na DOD (model 3DOD) wynika, że mechanizm odwzorowania modelu przestrzennego 3DOD na poszczególne diagramy UML jest prosty. Odwzorowanie elementów z diagramu DOD na poszczególne elementy innych diagramów UML jest jednoznaczne. Poza tym należy zauważyć, że posługując się różnymi sposobami przekształceń modelu przestrzennego można otrzymać automatycznie wiele innych bardzo ciekawych diagramów opisujących projektowany system (np. diagram sekwencji, diagram funkcji aktorów, itp.).

Rozważając pozostałe perspektywy modelu Kruchtena można zauważyć, że podobny mechanizm sprzężenia poszczególnych wymiarów do jednego, prostego diagramu realizacji można zastosować do pozostałych perspektyw. Przykładowo w perspektywie przypadków użycia wymiarem struktury mogą być związki pomiędzy aktorami, a zachowaniem funkcje jakie wypełniają ci aktorzy. Wymiarem funkcjonalności jest oczywiście diagram przypadków użycia identyczny jak w perspektywie logicznej. W perspektywie procesowej strukturą mogą być obiekty biznesowe, zachowaniem komunikaty poszczególnych obiektów, a realizacją np. diagram sekwencji. Tu również można zauważyć, że wymiarem funkcjonalności będzie diagram przypadków użycia, przy czym często stosuje się tu diagram aktywności, gdzie aktywności są stereotypowane na procesy (przypadek użycia odpowiada procesowi). Podział na wymiary można przeprowadzić w pozostałych perspektywach zauważając, że wspólnym wymiarem będzie wymiar funkcjonalności (dla implementacji – model systemowych przypadków użycia, dla wdrożenia – np. przypadki testowe).

4.      Podsumowanie

Zaproponowany model przestrzenny DOD umożliwia zachowanie, w procesie modelowania docelowego systemu, kompletności i spójności opisu architektury tego systemu w perspektywie logicznej. Budując model systemu za pomocą 3DOD można automatycznie odwzorować elementy w nim opisane na elementy niezbędne do kompletnego opisu perspektywy logicznej. Z drugiej strony należy zauważyć, że model ten umożliwia zachowanie spójności i kompletności opisu architektury przy modyfikacji jednego z trzech wymiarów perspektywy logicznej. Zmiany w jednym diagramie automatycznie przekładają się na odpowiednie modyfikacje w pozostałych. Mechanizm ten znakomicie może zastąpić iteracje postulowane przez Kruchtena przy mapowaniu elementów scenariusza na odpowiednie perspektywy. W modelu 3DOD mapowanie to realizowane jest automatycznie, więc zakończenie procesu projektowania danej perspektywy jest zależny wyłącznie od zakresu wybranych zagadnień (concerns) do modelowania.

Jednocześnie należy zauważyć, że model przestrzenny DOD jest modelem dość czytelnym i nie jest „przeładowany” zbytnią zawartością informacyjną. Rzec by można było nawet, że model ten, parafrazując definicję architektury podaną przez Kruchtena, to „model jaki pozostałby, gdy nie można już usunąć niczego więcej, a system ciągle jest zrozumiały i można objaśnić jego działanie”.

Model 3DOD posiada również inne własności, które mogłyby być wykorzystane w innych perspektywach. Zatem implementując mechanizmy modelu przestrzennego DOD w pozostałych perspektywach można spodziewać się uzyskania rozszerzonego modelu całego systemu informatycznego, w których wypełnione byłyby istniejące ponoć zawsze luki 4 między wymaganiami Zamawiającego, a implementowanymi modelami. Obecnie trwają badania własności modelu przestrzennego DOD w zakresie odwzorowań zarówno wewnątrz innych perspektyw, jak i pomiędzy nimi.

LITERATURA

1.     Architectural Blueprints—The “4+1” View Model of Software Architecture, Philippe Kruchten Rational Software Corp., Paper published in IEEE Software 12 (6) November 1995, pp. 42-50

2.     Philippe Kruchten, “Rational Unified Process od strony teoretycznej”, WNT 2007

3.     Mark Kennaley, Fourth Medium Consulting Inc., “The 3+1 Views of Architecture (in 3D)”: An Amplification of the 4+1 Viewpoint Framework, Seventh Working IEEE/IFIP Conference on Software Architecture

4.     Stephen T. Albin, The Art of Software Architecture: Design Methods and Techniques, John Wiley and Sons, 2003

5.     Heeseok Choi, Keunhyuk Yeom, An Approach to Software Architecture Evaluation with the 4+1 View Model of Architecture, Department of Computer Engineering, Pusan National University 30 Changjeon Dong, Keumjeong Ku, Pusan, 609-735, Korea

6.     Unified Modeling Language: Superstructure, version 2.0, formal/05-07-04