Badanie zgodności w obrębie grup współdziałania

Wytwarzanie oprogramowania to proces złożony, obejmujący wiele etapów. Rozpoczyna się w momencie ustalenia zakresu opracowania i obejmuje aktywności związane z analizą biznesową i systemową (określenie wymagań funkcjonalnych i niefunkcjonalnych), projektem systemu, implementacją oraz wdrożeniem i utrzymaniem opracowanego oprogramowania. Jakość oraz użyteczność produktu informatycznego zależy w dużej mierze od właściwego zrozumienia dziedziny przedmiotowej oraz umiejętności stworzenia modeli będących abstrakcją rozpatrywanego wycinka rzeczywistości. Znaczenie modeli jest ogromne z uwagi na konieczność testowania i weryfikacji uzyskanych rezultatów. O kształcie produktu końcowego w znacznym stopniu decydują etapy początkowe, obejmujące analizę biznesową i systemową. Stąd też w artykule skupiliśmy się na problemie badania zgodności w obrębie grup współdziałania oraz pomiędzy diagramami współdziałania i diagramami klas. Uznaliśmy, zgodnie z metodyką RUP [KRU1999], która jest ukonkretnieniem generycznej metodyki wytwarzania oprogramowania USDP [JAC1999], że modelowanie w początkowych etapach opiera się głównie na diagramach przypadków użycia i ich realizacji z użyciem grup współdziałania.Grupa współdziałania (ang. collaboration) jest zespołem powiązanych elementów, które współpracują ze sobą w celu dostarczenia określonych usług. Elementami grupy są obiekty, występujące w ustalonych rolach, a powiązaniami są role asocjacji.

Struktura grupy współdziałania jest przedstawiana zgodnie z [OMG2001], za pomocą diagramów współdziałania na poziomie specyfikacji (lub diagramów klas), a zachowanie – za pomocą diagramu współdziałania na poziomie instancji (diagramów sekwencji lub diagramów aktywności). Grupy współdziałania wykorzystuje się do przedstawienia realizacji operacji lub przypadku użycia. Semantyka przypadku użycia wyraża się przez zbiór interakcji. Interakcja jest, zwykle skończonym, częściowo uporządkowanym zbiorem komunikatów wymienianych podczas świadczenia usługi. W prezentowanych rozważaniach ograniczamy się do przypadku liniowo uporządkowanych zbiorów komunikatów. Dla nietrywialnych przypadków użycia zbiór interakcji jest duży, nawet nieskończony, podczas gdy pojedyncze diagramy współdziałania na poziomie instancji reprezentują tylko pojedyncze interakcje. Dlatego z pojedynczym diagramem współ-działania na poziomie specyfikacji jest związany zbiór diagramów współdziałania na poziomie instancji.

Diagramy współdziałania mają zastosowanie między innymi w fazie analizy biznesowej, która ma na celu przedstawienie biznesowych przypadków użycia i sposobu ich realizacji. Zestaw diagramów współdziałania stanowi biznesowy model obiektowy – zasadniczy, obok słownika dziedzinowego i modelu przypadków użycia, element modelu biznesowego. Ponadto diagramy współdziałania są wykorzystywane do opisu (systemowych) przypadków użycia w fazie analizy systemowej. W dalszych fazach wytwarzania oprogramowania, w tym w fazie projektowej, do opisu struktury realizatora usług wykorzystuje się diagramy klas.

Zdefiniujemy trzy rodzaje diagramów: diagramy współdziałania na poziomie specyfikacji i poziomie instancji oraz diagramy klas, oznaczane odpowiednio symbolami InstCollD, SpecCollD, ClassD.Każdy z diagramów jest widziany jako etykietowany skierowany multigraf, różnice dotyczą tylko funkcji etykietujących.

Skierowany multigraf jest zdefiniowany jako trójka:

G = <VerID, ArcID, Arc>,

gdzie

VerID jest skończonym zbiorem identyfikatorów wierzchołków,

ArcID jest skończonym zbiorem identyfikatorów łuków,

Arc ⊆ VerID × ArcID × VerID jest zbiorem łuków. Łuk a∊Arc jest trójką <v1, a, v2>, gdzie a jest identyfikatorem łuku, zaś v1 oraz v2 są odpowiednio identyfikatorami wierzchołka początkowego i końcowego. Zakładamy, że identyfikator ajednoznacznie określa łuk α i dlatego dla danego łuku a∊ArcID funkcje source(a) oraz sink(a) jednoznacznie wyznaczają jego wierzchołek początkowy i końcowy.

Nazwy multigrafów i ich elementów dla poszczególnych diagramów będą prefiksowane symbolami InstColl, SpecColl, Class odpowiednio dla diagramów współdziałania na poziomie instancji i na poziomie specyfikacji oraz dla diagramów klas, na przykład, dla diagramu klas będzie to multigraf ClassG = < ClassVerID, ClassArcID, ClassArc>.

Zasadniczymi elementami składowymi diagramu współdziałania na poziomie specyfikacji są role klasyfikatorów i role asocjacji. Składnia języka UML dopuszcza, by występowały również inne elementy, na przykład związki zależności. Diagramy współdziałania występujące w fazie analizy biznesowej ograniczają zbiór klasyfikatorów do ról aktorów i ról klas, a poza nimi na diagramie występują tylko związki asocjacji i generalizacji. Uzasadniają to powszechnie znane i praktycznie stosowane metodyki [KRU1999, JAC1999].

Rola aktora na diagramie współdziałania na poziomie specyfikacji jest jedną z ról przypisanych danemu aktorowi. Przypomnijmy: aktor jest definiowany w UML jako zbiór ról, przy czym w asocjacji z jednym przypadkiem użycia może wystąpić tylko w jednej roli.

Rola klasy wiąże się z pewną perspektywą widzenia danej klasy, zwanej klasą bazową. W UML rola klasy jest definiowana jako podzbiór właściwości klasy bazowej. Zbiór właściwości klasy będzie dalej przedstawiany w postaci listy, zatem rola klasy będzie podlistą właściwości klasy bazowej.

Rola asocjacji jest ograniczonym użyciem danej asocjacji, zwanej asocjacją bazową. Podobnie jak asocjacja, rola asocjacji jest określona przez zbiór swoich końców. Liczność danego końca roli asocjacji jest podzbiorem liczności określonej dla odpowiadającego mu końca asocjacji bazowej.

Do oznaczenia ról klas i asocjacji będzie dalej stosowana następująca notacja:

/R: C – jest nazwą roli klasy opartą na klasie bazowej C,

/R – jest nazwą roli klasy opartą na anonimowej klasie bazowej, w takich przypadkach będziemy domyślnie przyjmować R jako nazwę klasy bazowej,

: C – jest anonimową rolą klasy opartą na klasie bazowej C, w takich przypadkach będziemy domyślnie przyjmować /C jako nazwę roli,

/a – jest nazwą roli asocjacji opartej na asocjacji bazowej a; w przypadku braku nazwy roli asocjacji przyjmujemy dla niej nazwę domyślną – nazwę roli pisaną z małej litery, z kolejnymi indeksami, do której prowadzi asocjacja.

Diagram współdziałania na poziomie specyfikacji jest zdefiniowany następująco:

SpecCollD = <SpecCollG, SpecCollTypeVer, SpecCollVerLab, SpecCollTypeA, SpecCollArcLab>

gdzie

SpecCollG = <SpecCollVerID, SpecCollArcID, SpecCollArc> jest skierowanym multigrafem, którego wierzchołki reprezentują role klas, a łuki – role asocjacji lub związki generalizacji.

SpecCollTypeVer : SpecCollVerID → {Actor, Class} jest funkcją określająca rodzaj wierzchołka v, SpecCollTypeVer(v) = Actor oznacza, że v reprezentuje rolę aktora, zaś SpecCollTypeVer(v) = Class – rolę klasy.

SpecCollVerLab jest funkcją etykietującą wierzchołki. Dla danego v∊SpecCollVerID, etykieta SpecCollVerLab(v) jest trójką: <name(v), classifier(v), listOfProperties(v)>, gdzie name(v) jest nazwą roli, classifier(v) jest nazwą klasy bazowej i ListOfProperties(v) jest listą właściwości roli – atrybutów i odpowiedzialności. Nazwa roli lub nazwa klasy bazowej mogą być nieokreślone (np. dla aktora). Pojęcie odpowiedzialności jest tu używane ze względu na to, że jest pojęciem naturalnym w fazie analizy biznesowej. Nieformalnie pod pojęciem odpowiedzialności kryje się pewna aktywność. W dalszych fazach wytwarzania oprogramowania odpowiedzial-ność wyraża się jako własność behawioralna, czyli operacja, metoda lub obsługa sygnału.

SpecCollTypeA : SpecCollArcID → {AssArc, GenArc} jest funkcją określającą rodzaj łuku reprezentowanego identyfikatorem a. SpecCollTypeA(a) = AssArc oznacza, że a reprezentuje rolę asocjacji, zaś SpecCollTypeA(a) = GenArc oznacza, że areprezentuje generalizację.

SpecCollArcLab jest funkcją etykietującą łuki. Funkcja jest zdefiniowana tylko dla łuków reprezentujących role asocjacji. Dla danego a∊SpecCollArcID takiego, że SpecCollType(a) = AssArc, etykieta SpecCollArcLab(a) jest parą: <name(a), mult(a)>, gdzie name(a) jest nazwą roli asocjacji, zaś mult(a) ⊆Nat jest licznością końca roli asocjacji wskazywanego końcem łuku.

Diagram współdziałania na poziomie instancji odzwierciedla realizację interakcji. W ogólnym przypadku realizacja może wiązać się ze zmianami strukturalnymi – mogą być kreowane i kasowane instancje uczestniczące w realizacji tej interakcji, podobnie mogą być tworzone i kasowane powiązania pomiędzy instancjami. Oznacza to, że w momentach kolejnych zmian strukturalnych diagram współdziałania na poziomie instancji będzie reprezentowany różnymi podgrafami grafu reprezentującego realizację interakcji. Każdy z tych podgrafów przedstawia zbiór aktualnie istniejących instancji i łączących je powiązań. W dalszych rozważaniach dotyczących diagramów współdziałania na poziomie instancji przyjmujemy następujące założenia:

• każda instancja i każde powiązanie na diagramie instancyjnym musi być zgodne z diagramem specyfikacyjnym,
• dopuszczamy by w trakcie realizacji interakcji nie były spełnione ograniczenia licznościowe, natomiast ograniczenia te muszą być spełnione po zakończeniu realizacji interakcji.

Oznacza to, że zamiast zbioru podgrafów będzie rozpatrywany tylko jeden podgraf, zwany podgrafem końcowym, reprezentujący sytuację po zakończeniu realizacji interakcji. Wyznaczenie grafu końcowego wymaga interpretacji sekwencji wymienianych komunikatów w celu ustalenia, które z instancji ról i powiązań są elementami przejściowymi, a które są elementami trwałymi. Algorytm wyznaczania grafu końcowego nie jest tu prezentowany.

Diagram współdziałania na poziomie instancji jest zdefiniowany następująco:

InstCollD = <InstCollG, InstCollTypeV, InstCollVerLab, InstCollArcLab>

gdzie

InstCollG = <InstCollVerID, InstCollArcID, InstCollArc> jest skierowanym multigrafem, którego wierzchołki reprezentują instancje ról klas i aktorów, a łuki – instancje ról asocjacji.

InstCollTypeV : InstCollVerID → {Actor, Class} jest funkcją określająca rodzaj wierzchołka, zdefiniowaną podobnie jak w przypadku diagramów współdziałania na poziomie specyfikacji, różnica polega tylko na tym, że funkcja wskazuje na instancje aktorów i instancje ról klas.

InstCollVerLab jest funkcją etykietującą wierzchołki. Dla danego v∊InstCollVerID, etykieta InstCollVerLab(v) jest parą <name(v), role(v)>, gdzie name(v) jest nazwą instancji, a role(v) jest nazwą roli dla tej instancji.

InstCollArcLab jest funkcją etykietującą łuki. InstCollArcLab(a) jest parą: <role(a), listOfMessages(a)>, gdzie role(a) jest nazwą roli, której łuk a jest instancją, zaś listOfMessages(a) jest listą komunikatów przesyłanych przez łuk a. Każdy komunikatk jest związany dokładnie z jedną odpowiedzialnością o, co będzie zapisywane w postaci: k:o. Oznacza to, że przesłanie komunikatu inicjuje wykonanie aktywności reprezentującej daną odpowiedzialność. Lista komunikatów jest uporządkowana czasowo, a każdy element listy – komunikat – ma przypisaną liczbę porządkową, która określa numer komunikatu w realizacji interakcji. Liczba porządkowa komunikatu jest unikalna w całym diagramie współdziałania.

Diagram klas jest zdefiniowany jako:

ClassD = <ClassG, ClassVer, ClassTypeA, ClassArc>

gdzie

ClassG = <ClassVerID, ClassArcID, ClassArc> jest skierowanym multigrafem, którego wierzchołki reprezentują klasy, a łuki – asocjacje i generalizacje.

ClassVerLab jest funkcją etykietującą wierzchołki, która danemu wierzchołkowi v∊ClassVerID przypisuje listę właściwości klasy listOfProperties(v), lista ta może być nieokreślona.

ClassTypeA : ClassArcID → {AssArc, GenArc} jest funkcją określającą rodzaj łuku w taki sam sposób jak definiuje to funkcja SpecCollTypeA dla diagramów współdziałania na poziomie specyfikacji.

ClassArcLab jest funkcją etykietującą łuki. Funkcja jest zdefiniowana tylko dla łuków reprezentujących asocjacje w taki sam sposób jak funkcja SpecCollCollAr.

Diagram współdziałania na poziomie instancji powinny być zgodne z odpowiednimi diagramami na poziomie specyfikacji. W celu sprecyzowania tej zgodności wprowadzamy pomocniczy diagram, nazywany rozwiniętym diagramem współdziałania na poziomie specyfikacji. Rozwinięty diagram współdziałania jest modyfikacją (nierozwiniętego) diagramu współdziałania na poziomie specyfikacji polegającą na eliminacji generalizacji i przeniesieniu informacji o dziedziczonych właściwościach bezpośrednio do wierzchołków reprezentujących role klasyfikatorów. Oznacza to, że funkcja etykietująca wierzchołki wyznacza pełny deskryptor danej roli klasyfikatora. Prosty algorytm transformacji diagramu nierozwiniętego w diagram rozwinięty jest tu pominięty.Z definicyjnego punktu widzenia rozwinięty diagram współdziałania na poziomie specyfikacji

ExSpecCollD = <ExSpecCollG, ExSpecCollTypeVer, ExSpecCollVerLab,

ExSpecCollTypeA, ExSpecCollArcLab>

różni się tylko tym od diagramu nierozwiniętego, że funkcja określająca typ łuku ExSpecCollArcLab przyjmuje tylko wartość AssArc.

Oczywiście zbiór wierzchołków diagramu rozwiniętego jest taki sam jak zbiór wierzchołków diagramu nierozwiniętego, czyli

ExSpecCollVerID = SpecCollVerID.

Funkcja określająca rodzaj wierzchołka ExSpecCollVerLab jest identyczna z funkcją SpecCollVerLab. Zbiór łuków diagramu rozwiniętego zawiera wszystkie łuki grafu nierozwiniętego, które reprezentują asocjacje i dodatkowo pojawiają się asocjacje, będące konsekwencją eliminacji relacji generalizacji, czyli

{a∊SpecCollArcID | SpecCollTypeA(a)} = AssArc} ⊆ ExSpecCollArcID.

Nowe asocjacje maja takie same nazwy i liczności jak asocjacje, po których dziedziczą.

Funkcja etykietująca wierzchołki określa takie same nazwy i reprezentuje wszystkie specyficzne i dziedziczone atrybuty i odpowiedzialności, czyli jeśli

ExSpecCollVerLab(v) = <exname, exclass, exlist>

SpecCollVerLab(v) = <name, class, list>

to

exname = name, exclass = class, list ⊆ exlist,

gdzie symbol inkluzji oznacza, że lista list jest podlistą listy exlist.

Funkcja etykietująca łuki ExSpecCollArcLab dla zbioru łuków {a∊SpecCollArcID | SpecCollTypeA(a)} przyjmuje takie same wartości jak funkcja SpecCollArcLab.

Diagram współdziałania na poziomie instancji

InstCollD = <InstCollG, InstCollTypeV, InstCollVerLab, InstCollArcLab>

jest zgodny z rozwiniętym diagramem współdziałania na poziomie specyfikacji

ExSpecCollD = <ExSpecCollG, ExSpecCollTypeVer, ExSpecCollVerLab, ExSpecCollTypeA, ExSpecCollArcLab>

gdy istnieją dwie całkowicie określone funkcje:

VerMap : InstCollVerID → ExSpecCollVerID

ArcMap : InstCollArcID → ExSpecCollArcID

takie, że spełniony jest warunek:

Jeżeli

ArcMap(insa) = exa,

oraz

ExSpecCollArcLab(exa) = <name, mult>,

InstCollArcLab(insa) = <role, listOfMess>

to

1. name = role,
2. dla dowolnego komunikatu, postaci k : o, z listy listOfMess, odpowiedzialność o jest elementem listy właściwości listOfProperties(v), gdzie wierzchołek v = VerMap(sink(insa)),
3. card({a∊InstCollArcID | InstCollArcLab(a)=<name’,listOfMes>, name’ = name})∊mult.

Zgodność pomiędzy diagramem współdziałania na poziomie specyfikacji i diagramem klas jest zdefiniowana następująco: diagram klas ClassD jest zgodny z diagramem współdziałania na poziomie specyfikacji SpecCollD gdy istnieją dwie całkowicie określone funkcje:VerMap : SpecCollVerID → ClassVerID

ArcMap : SpecCollArcID → ClassArcID

spełniające następujące warunki:

1. Jeżeli VerMap(vr) = v to

listOfProperties(vr) ⊆listOfProperties(v),

2. Jeżeli ArcMap(ar) = a to

VerMap(source(ar)) = source(a) oraz VerMap(sink(ar)) = sink(a).

3. Jeżeli ArcMap(ar1) = … = ArcMap(arn) = a to name(ar1) = … = name(arn).

Wymóg ten wynika z założenia, że role asocjacji o tej samej nazwie mają na diagramach współdziałania taką samą semantykę, własność tę powinny również zachowywać diagramy klas.

Jeżeli ArcMap(ar1) = … = ArcMap(arn) = a oraz CollArcLab(ari) = <name(ari), mult(ari)> dla i = 1, …, n to

mult(ar1) ∪ … ∪ mult(arn) ∪ aux ⊆ mult(a),

Zbiór aux jest zdefiniowany następująco:

Niech Csink będzie klasą reprezentowaną przez wierzchołek sink(a) oraz niech Csource będzie klasą reprezentowaną przez wierzchołek source(a). Jeżeli na diagramie współdziałania na poziomie specyfikacji istnieje rola oparta o klasyfikator Csource, która nie jest w asocjacji ar z pewną rolą opartą o klasyfikator Csink, to zbiór pomocniczy

aux = {0}, w przypadku przeciwnym aux = ∅.

Postać warunku jest słuszna przy założeniu, że asocjacje ar1, …, arn nie wiążą ze sobą tych samych wierzchołków. Jeżeli source(ar1) = source(ar2) oraz sink(ar1) = sink(ar2), to asocjacje ar1 i ar2 należy zastąpić jedną asocjacją wiążącą te same wierzchołki o liczności

mult(ar1) ⊕ mult(ar2)

gdzie operator ⊕ : 2 Nat × 2 Nat → 2 Nat jest zdefiniowany następująco: jeśli Ai są skończonymi podzbiorami postaci {mi, …, mi + ni}, gdzie mi, ni ∊Nat, dla i = 1, 2, to

A1 ⊕ A2 = {m1 + m2, …, m1 + m2 + n1 + n2}

Na przykład, jeśli A1 = {1,…, 3} oraz A2 = {2,…, 5}, to A1 ⊕ A2 = {3,…,8}

Jeśli jeden ze zbiorów jest nieskończony, powiedzmy A1 = {m1, m1 +1, … }, to

A1 ⊕ A2 = {m1 + m2, m1 + m2 + 1, … }

Każdy podzbiór liczb naturalnych można przedstawić w postaci skończonej sumy zbiorów o podanej wyżej postaci, stąd operator ⊕ jest dobrze zdefiniowany dla dowolnego podzbioru liczb naturalnych.

Przykład zawarty w niniejszym rozdziale posłuży do pokazania praktycznych sposobów reprezentacji grup współdziałania i badania spójności między diagramami.Punktem wyjścia do rozważań jest definicja prostego procesu biznesowego „Wynajęcie miejsca w pokoju”.

Proces biznesowy: Wynajęcie miejsca w pokoju

Celem procesu biznesowego jest wynajęcie przez studenta miejsca w pokoju w akademiku, co skutkuje wydaniem studentowi karty mieszkańca oraz wpisaniem go na listę mieszkańców akademika. Wynajęcia miejsca w pokoju dokonuje się na podstawie ważnego skierowania do akademika, wydanego na nazwisko studenta.

Proces biznesowy jest inicjalizowany przez studenta, który przychodzi do biura akademika ze skierowaniem, wydanym przez władze uczelni. Student dowiaduje się od kierownika jaka jest aktualna oferta akademika, tzn. w których pokojach są miejsca do wynajęcia, jaka jest opłata za miejsce w poszczególnych pokojach z oferty i kto w tych pokojach zamieszkuje. Po wybraniu pokoju przez studenta kierownik przypisuje studenta do pokoju, dopisuje studenta do listy mieszkańców oraz wypisuje studentowi kartę mieszkańca.

Zgodnie z podejściem autorów zaproponowanym w [HNA2002b] tworzenie diagramów reprezentujących grupę współdziałania związaną z danym procesem biznesowym jest poprzedzone identyfikacją i specyfikacją ról. Wśród ról wyróżnia się role aktywne oraz pasywne. Role aktywne zwykle reprezentują aktorów lub pracowników w procesie biznesowym, podczas gdy role pasywne – byty, na których manipulują role aktywne. Role mogą być opisane przez pewien zbiór atrybutów. Z rolą wiąże się pewien zakres odpowiedzialności, wyrażony w terminach aktywności, które podejmuje dana rola w trakcie realizacji procesu biznesowego. Zakres odpowiedzialności w przypadku ról pasywnych sprowadza się do aktywności zapisu lub odczytu stanu roli. Zakres odpowiedzialności roli jest abstrakcją własności behawioralnych jej klasy bazowej.

Na podstawie opisu procesu biznesowego Wynajęcie miejsca w pokoju zidentyfikowano następujące nazwane role: Student, Kierownik oraz anonimowe role klas bazowych Pokój, Cennik, Lista mieszkańców, Skierowanie, Karta mieszkańca. Przykłady definicji własności dla ról Kierownik oraz Student zamieszczono poniżej.

Przykład listy własności roli Kierownik:

• własności strukturalne: imię, nazwisko, …,
  • zakres odpowiedzialności:
    • wynajmuje studentowi miejsce w pokoju (aktywność złożona)
    • informuje o ofercie akademika (aktywność prosta)
    • przypisuje studenta do miejsca w pokoju
    • dopisuje studenta do listy mieszkańców
    • wypisuje kartę mieszkańca

Przykład listy własności roli Student:

• własności statyczne: imię, nazwisko, ….,
  • zakres odpowiedzialności:
    • wynajmuje miejsce w pokoju
    • wybiera pokój z oferty
    • odbiera kartę mieszkańca

Zakres odpowiedzialności roli może być strukturalizowany, tzn. może mieć budowę hierarchiczną, w której wyróżnia się aktywności złożone (wynajmuje studentowi miejsce w pokoju) i aktywności proste, które nie są dalej wyrażane w terminach aktywności danej roli (informuje o ofercie akademika).

Po zidentyfikowaniu i wyspecyfikowaniu ról, biorących udział w realizacji procesu biznesowego można przystąpić do jego zamodelowania. W pierwszym etapie modelowania realizacji procesów biznesowych (przypadków użycia) bardzo użyteczne są diagramy aktywności. Jest tak dlatego, że diagramy te są wyrażone bezpośrednio w terminach ról (role aktywne są reprezentowane jako tory, ang. swimelines) oraz wykonywanych przez nie aktywności. Dodatkowo, mogą one ilustrować przepływ obiektów (ang. data flow) – instancje ról pasywnych – pomiędzy aktywnościami. Opis procesu biznesowego za pomocą diagramu aktywności przedstawia rysunek 1.

Diagramy współdziałania na poziomie instancji (lub używane zamiennie diagramy sekwencji) mogą pokazywać interakcję na różnym poziomie szczegółowości – porównaj rysunek 2. i rysunek 3.

Diagram sekwencji przedstawiony na rysunku 2. prezentuje w zasadzie te same informacje, co diagram aktywności, zaprezentowany na rysunku 1. Ogranicza on widok obiektów do tych, które są instancjami ról aktywnych. Każda aktywność z diagramu aktywności na diagramie sekwencji jest reprezentowana przez jeden komunikat (zwykle komunikat skierowany do samego siebie – self). Taka zależność możne być podstawą zdefiniowania reguł zgodności pomiędzy diagramami aktywności i sekwencji (poza zakresem opracowania). Diagram ten będzie przydatny w pierwszym etapie modelowania biznesowego, który służy przede wszystkim zrozumieniu modelowanego świata. W drugim etapie zrodzi się konieczność bardziej szczegółowego opisania tego, co dzieje się po odebraniu każdego komunikatu.Diagram przedstawiony na rysunku 3. dostarcza informacji na temat reakcji roli na dany komunikat. Każdy komunikat typu self do roli Kierownik został zastąpiony przez sekwencję komunikatów do instancji anonimowych ról klas pasywnych. Ze skryptu, umieszczonego po lewej stronie diagramu można odczytać, które aktywności wykonuje instancja roli Kierownik.

Liczbę komunikatów zminimalizowano do tych, które są niezbędne do wykonania danego zadania (brak szumu informacyjnego). Pozwolą one, w późniejszych etapach, na identyfikację publicznych operacji w klasyfikatorach bazowych dla rozważanych ról. Ponadto, diagram zawiera informacje o niezbędnych zasobach, związanych z realizacją procesu. Łatwo stwierdzić, że diagram ten jest spójny z diagramem aktywności z rysunku 1., ponieważ komunikaty reprezentują interakcje pomiędzy różnymi rolami, a ich parametry lub zwracane obiekty są odpowiednikiem obiektów przesyłanych pomiędzy aktywnościami.

Diagram przedstawiony na rysunku 4. powstał jako wynik przekształcenia diagramu z rysunku 3. za pomocą narzędzia Rational Rose. Zawiera on instancje tych samych ról oraz komunikatów, które występują na diagramie z rysunku 3, jednakże nie zawiera wszystkich informacji strukturalnych. W ramach interakcji mogą być kreowane nie tyko instancje, ale również połączenia pomiędzy instancjami, ponadto, część takich powiązań zwykle już istnieje przed rozpoczęciem współdziałania. Diagram po uzupełnieniach połączeń jest pokazany na rysunku 5.

Pokażemy, że zgodnie z definicją umieszczoną w podrozdziale 3. diagram ten jest spójny z diagramem współdziałania na poziomie specyfikacji – rysunek 6. Prezentacja będzie obejmowała fragment wskazany na rysunku 5.W pierwszym kroku należy zbudować rozwinięty diagram współdziałania na poziomie specyfikacji. Ponieważ na diagramie z rysunku 6. nie umieszczono żadnych relacji generalizacji, rozwinięty diagram współdziałania będzie dokładnie taki, jak diagram z rys. 6.

Zbiór wierzchołków diagramu ExSpecCollVerID =

{ /Student, /Kierownik:Pracownik, :Karta mieszkańca, :Cennik, :Pokój, :Lista mieszkańców, :Student }

przy czym:

ExSpecCollTypeVer(/Student) = Actor

ExSpecCollTypeVer(:Student) = Class

Dla uproszczenia przyjęto, że wierzchołki są identyfikowane przez specyfikacje ról umieszczone na diagramie.

Zbiór łuków diagramu ExSpecCollArcID =

{ :Student–:Pokój, :Pokój–:Student, :Student–/Kierownik, /Kierownik–:Student, :Student–:Lista mieszkańców, :Lista mieszkańców–:Student, :Student–:Karta mieszkańca, :Karta mieszkańca–:Student, :Cennik–:Pokój, :Pokój–:Cennik, :Pokój–/Kierownik, /Kierownik–:Pokój, :Karta mieszkańca–/Student, /Student–:Karta mieszkańca, :Karta mieszkańca–/Kierownik, /Kierownik–:Karta mieszkańca, :Cennik–/Kierownik, /Kierownik–:Cennik, :Lista mieszkańców–/Kierownik, /Kierownik–:Lista mieszkańców, /Student–/Kierownik, /Kierownik–/Student }

Zbiór łuków diagramu ExSpecCollArcID ={ :Student–:Pokój, :Pokój–:Student, :Student–/Kierownik, /Kierownik–:Student, :Student–:Lista mieszkańców, :Lista mieszkańców–:Student, :Student–:Karta mieszkańca, :Karta mieszkańca–:Student, :Cennik–:Pokój, :Pokój–:Cennik, :Pokój–/Kierownik, /Kierownik–:Pokój, :Karta mieszkańca–/Student, /Student–:Karta mieszkańca, :Karta mieszkańca–/Kierownik, /Kierownik–:Karta mieszkańca, :Cennik–/Kierownik, /Kierownik–:Cennik, :Lista mieszkańców–/Kierownik, /Kierownik–:Lista mieszkańców, /Student–/Kierownik, /Kierownik–/Student }

Dla uproszczenia przyjęto, że identyfikator łuku będzie napisem, składającym się ze specyfikacji ról połączonych łukiem. Każda rola asocjacji z rysunku 6. jest reprezentowana przez dwa skierowane łuki w definicji multigrafu.

Poniżej przedstawiono wynik działania funkcji etykietującej wierzchołki ExSpecCollVerLab dla wierzchołków, należących do wybranego zakresu:

ExSpecCollVerLab(/Kierownik:Pracownik) = <Kierownik, Pracownik, imię, nazwisko, …, wynajmuje studentowi miejsce w pokoju, informuje o ofercie akademika, przypisuje studenta do miejsca w pokoju, dopisuje studenta do listy mieszkańców, wypisuje kartę mieszkańca>

ExSpecCollVerLab(/Student) =

<Student, Student, imię, nazwisko,…, wynajmuje miejsce w pokoju, wybiera pokój z oferty, odbiera kartę mieszkańca>

Wyniki działania funkcji etykietującej łuki ExSpecCollArcLab dla asocjacji z rozważanego zakresu:

ExSpecCollArcLab(/Kierownik–/Student) = < student1 , {1} >

ExSpecCollArcLab(/Student–/Kierownik) = < kierownik1 , {1} >

Teraz należy określić wyniki poszczególnych funkcji, definiujących diagram współdziałania na poziomie instancji (rysunek 5).

InstCollArcID =

{ /Student, /Kierownik, :Karta mieszkańca, :Cennik, :Pokój, :Lista mieszkańców, :Student }

InstCollVerID =

{:Student–:Pokój, :Pokój–:Student, :Student–/Kierownik, /Kierownik–:Student, :Student–:Lista mieszkańców, :Lista mieszkańców–:Student, :Student-:Karta mieszkańca,:Karta mieszkańca–:Student, :Pokój–/Kierownik, /Kierownik–:Pokój,:Karta mieszkańca-/Kierownik, /Kierownik–:Karta mieszkańca, :Cennik-/Kierownik, /Kierownik–:Cennik, :Lista mieszkańców–/Kierownik, /Kierownik–:Lista mieszkańców, /Student–/Kierownik, /Kierownik–/Student}

Konwencja etykietowania wierzchołków i łuków diagramu współdziałania na poziomie instancji jest analogiczna do tej, zastosowanej dla diagramu współdziałania na poziomie specyfikacji z tym wyjątkiem, że elementy składające się na nazwę są podkreślone.

Wyniki funkcji etykietującej wierzchołki InstCollVerLab dla instancji ról pozostających w zakresie rozważań:

InstCollVerLab(/Student) = < _, Student >

InstCollVerLab(/Kierownik:Pracownik) = < _, Kierownik>

Symbol ‘_’ oznacza, że dany element (tu: nazwa instancji) nie jest określony.

Wyniki funkcji etykietującej łuki InstCollArcLab dla łuków z zakresu rozważań:

InstCollArcLab(/Kierownik–/Student) =

< student1, < 5)wybierz pokój: wybiera pokój z oferty, 10) odbierz kartę: odbiera kartę mieszkańca> >

InstCollArcLab(/Student–/Kierownik) =

< kierownik1, <1)wynajmij pokój: wynajmuje studentowi miejsce w pokoju> >

Po formalnym zdefiniowaniu diagramów współdziałania możemy przystąpić do badania zgodności pomiędzy nimi.

Diagram współdziałania na poziomie instancji jest zgodny z rozwiniętym diagramem współdziałania na poziomie specyfikacji, gdy da się zdefiniować dwie całkowicie określone funkcje VerMap oraz ArcMap, spełniające określone warunki.

Definicja funkcji odwzorowującej wierzchołki diagramu współdziałania na poziomie instancji do wierzchołków diagramu współdziałania na poziomie specyfikacji:

VerMap : InstCollVerID → ExSpecCollVerID

jest trywialna, gdyż, w naszym przypadku oba zbiory są identyczne.

Przykładowe odwzorowania węzłów:

VerMap(/Student) = /Student

VerMap(/Kierownik) = /Kierownik

Definicja funkcji odwzorowującej łuki diagramu współdziałania na poziomie instancji do łuków diagramu współdziałania na poziomie specyfikacji jest odrobinę trudniejsza, ale wystarczy zauważyć, że zbiór łuków diagramu na poziomie instancji jest podzbiorem łuków na poziomie specyfikacji. W związku z tym, każdemu łukowi na poziomie instancji będziemy przyporządkowywać odpowiadający mu łuk na poziomie specyfikacji.

Przykładowe odwzorowania łuków:

ArcMap(/Student–/Kierownik) = (/Student–/Kierownik)

ArcMap(/Kierownik–/Student) = (/Kierownik–/Student)

Sprawdźmy, czy zdefiniowane funkcje spełniają warunki zgodności dla wskazanego zakresu rozważań.

Niech isna = /Student–/Kierownik. Wówczas:

• name = role = kierownik1
• dla komunikatu o numerze 1) wynajmij pokój: wynajmuje studentowi miejsce w pokoju własność wynajmuje studentowi miejsce w pokoju należy do własności wierzchołka /Kierownik
• card({a∊InstCollArcID | InstCollArcLab(a) = <name’, listOfMes>, name’ = kierownik1}) = 1 ∊ {1}

Dowiedzenie zgodności dla insa = /Student zostanie pominięte.

W procesie wytwarzania oprogramowania ocena zgodności modeli, które pozostają w relacji zależności, jest jednym z elementów procesu weryfikacji poprawności modeli. Proponowane przez nas rozwiązanie, dotyczące badania zgodności w obrębie grupy współdziałania oraz pomiędzy diagramami współdziałania i diagramami klas jest fragmentem większego przedsięwzięcia badawczego, częściowo prezentowanego w publikacjach [HNA2003, HNA2002a, HNA2002b], mającego na celu opracowanie metodyki wspierającej początkowe etapy procesu wytwarzania oprogramowania. Zakres objęty opracowaniem obejmuje aktywności związane z opracowywaniem modeli biznesowych oraz modeli analitycznych.W rozdziale przedstawiono sposób reprezentowania i wykorzystania grup współdziałania. Zaproponowano formalną definicję diagramów współdziałania i klas oraz określono reguły oceny zgodności pomiędzy nimi. Język UML rozróżnia diagramy współdziałania na poziomie specyfikacji i instancji, co nie znajduje odzwierciedlenia w metodykach i narzędziach CASE. W artykułach [HNA2002b, HNA2003] określono rolę diagramów współdziałania w procesie wytwarzania oprogramowania oraz zaproponowano metodyczny sposób ich wykorzystania do identyfikacji klas i konstrukcji diagramów klas.

Ważną częścią tego opracowania jest rozbudowany przykład. Punktem wyjścia naszych rozważań był proces biznesowy, dla którego zidentyfikowano role oraz ich odpowiedzialności. Odpowiedzialności mogą być rozpatrywane w dwóch kategoriach: przechowywania i udostępniania danych i realizacji usług (między innymi usług świadczonych przez klasyfikatory bazowe). W zależności od przyjętego poziomu abstrakcji diagramy interakcji mogą być użyte do:

• prezentacji interakcji pomiędzy aktorami biznesowymi i pracownikami biznesowymi,
• pokazania wymaganych zasobów informacyjnych w postaci encji biznesowych,
• pokazania zmian strukturalnych w obrębie obiektów i powiązań pomiędzy nimi,
• definiowania operacji udostępnianych przez klasy na bazie realizowanych odpowiedzialności.

Definicje diagramów współdziałania i diagramów klas w oparciu o skierowane multigrafy są podstawą dla opracowania algorytmów automatycznej weryfikacji modeli.

W ramach dalszych prac autorzy planują wykorzystanie wyników, przedstawionych w niniejszym opracowaniu oraz we wcześniejszych pracach [HNA2002b, HNA2003], do badania zgodności dowolnych diagramów klas w kontekście ustalonym przez diagramy współdziałania..