maj
21

ArchiMate a przypadek użycia

Źródło: Andrzej Sobczak
Print Friendly

integrationTworząc modele architektoniczne możemy stosować do tego celu różne języki. Z badań, które przeprowadziłem w zeszłym roku najpopularniejszy w Polsce w dalszym ciągu jest  język UML (stworzony przez OMG), coraz częściej zaczyna być również stosowany ArchiMate (stworzony przez The Open Group). W praktyce spotykam się również z taką kombinacją: na poziomie architektury strategicznej i segmentów (obydwa te pojęcia wprowadza TOGAF) stosowany jest ArchiMate, zaś na poziomie architektury potencjału/rozwiązania – UML. Pojawia się tutaj jednak kwestia jak łączyć takie modele.

Oczywiście zawsze można powiedzieć, że taką “integrację” umożliwia narzędzie informatyczne. Czyli w jednej bazie mamy gromadzone modele stworzone w różnych językach (np. w Sparx Enterprise Architect bezproblemowo obsłuży połączenie ArchiMate – BPMN [do uszczegółowienia procesów w architekturze biznesowej] – UML [do uszczegółowienia architektury aplikacji]).

Zupełnie innym poziomem “integracji” jest próba dokonania mapowania poszczególnych obiektów tych języków między sobą. Ostatnio prowadziłem dyskusję “skąd biorą  się przypadki użycia”  – tj. z jakich elementów ArchiMate można je “wywieść”.

Chwilę trwało, zanim doszedłem z rozmówcą do konsensusu – bo jak zwykle diabeł tkwił w szczegółach. On myślał o “biznesowych przypadkach użycia” (business use case), a ja o systemowych przypadkach użycia (system use case).

Dla porządku przytaczam obydwie definicje tych pojęć:

Biznesowy przypadek użycia – reprezentuje funkcje dostarczane przez organizacje; opisuje on proces biznesowy z punktu widzenia zewnętrznej, dodanej wartości; biznesowe przypadki użycia to procesy biznesowe, które przecinają granice organizacji, obejmując ewentualnie partnerów i dostawców, aby zapewnić wartość dodaną organizacji (definicja przytoczona za M. Wolski).

Systemowy przypadek użycia (puryści używają określenia: przypadek użycia) –  interakcja pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem w postaci określonej sekwencji kroków. Przypadek użycia powinien opisywać w jaki sposób system jest używany przez aktora, aby umożliwić mu realizację konkretnego celu.

Stosunkowo łatwo można dokonać mapowania obiekt ArchiMate – systemowy przypadek użycia. Proponuję, aby po stronie ArchiMate używać obiektu “usługa aplikacji” (application service), która  jest zdefiniowana w tym standardzie, jako usługa udostępniająca [warstwie biznesowej – przypis A.S.] zautomatyzowane zachowanie. W zależności do poziomu modeli architektonicznych tworzonych w ArchiMate (tj. architektura strategiczna/segmentów) usługa aplikacji może być zdekomponowana na 1…n systemowych przypadków użycia.

Zupełnie inaczej wygląda mapowanie obiekt ArchiMate – biznesowy przypadek użycia. Tutaj jest o wiele trudniej dokonać takiego przyporządkowania, gdyż w samej definicji biznesowego przypadku użycia następuje odwołanie do procesu, funkcji oraz wartości. W ArchiMate są to oddzielne obiekty – czyli proces biznesowy, funkcja biznesowa, wartość.
Ze względu jednak na fakt, że dla mnie sednem jego definicji jest zwrot: “z punktu widzenia zewnętrznej, dodanej wartości […] organizacji”, sugeruję aby mapować go na usługę biznesową (business service), którą ArchiMate definiuje jako: “usługę, która zaspokaja potrzebę biznesową klienta”. Czyli jednej usłudze biznesowej będzie najczęściej odpowiadał jeden biznesowy przypadek użycia.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “ArchiMate a przypadek użycia

  1. hm… dzielenie przypadków użycia na “rodzaje” zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojecie “przypadek użycia systemu”, gdzie systemem jest “analizowany/modelowany system” (patrząc na system w rozumieniu teorii systemów, tu zwracam uwagę na fakt, że UML to nie tylko IT). Wobec tego skoro system zanim będzie rozpatrywany musi być określony (granice systemu, nad jest jest super system, a ten składa się z podsystemów, polecam Sienkiewicz, Teoria Systemów), otrzymamy prostą rzecz: przypadek użycia ma jedną definicję, ale w danym momencie rozpatrywanym systemem jest np. oprogramowanie ale te z może nim być organizacja. Tak więc przypadek użycia “oprogramowania” (np. wystawianie faktury VAT) niczym się nie różni od “przypadku użycia” firmy sprzedającej rowery “dostarczenie zamówionego roweru”… jeżeli coś tu się różni do granice systemu: raz jest nią granica “oprogramowania” a raz “organizacji”. A ArchiMate jest moim zdaniem problem taki, że pojęcie, np. takie jak proces biznesowy, funkcja biznesowa, wartość są nieprecyzyjne… (czym się różni proces dostarczenia roweru od funkcji dostarczenia roweru dla fabryki rowerów???). Moim zdaniem trudno obronić tezę, że jakieś “różne przypadki użycia”, raczej łatwo jest obronić tezę, że w wielu projektach mieszane są granice różnych systemów w ramach jednej analizy.

  2. Osobiście wolę modelować “systemowy przypadek użycia” za pomocą “application function”. Przykład z aktualnej pracy:

    1) Usługa aplikacyjna “Application Service”: ‘Możliwość zarządzania kontami użytkowników’ jest wykorzystywana w interakcji “Business Interaction” ‘Zakładanie kont użytkownikom’

    2) Usługa jest zrealizowana za pomocą funkcji aplikacyjnych “Application functions”: ‘Zablokowanie konta użytkownika’ i ‘Założenie konta użytkownika’

  3. Jeszcze tytułem uzupełnienia – dla mnie “usługa aplikacyjna” jest tworem sztucznym – być może zbyt mało miałem do czynienia z SOA. Niemniej jednak porównuję to do “Usługi biznesowej”, z którą często spotykam się w umowach oraz z “Usługą technologiczną”, której dla mnie przykładem jest serwis www i wychodzi, że usługa aplikacyjna to grupowanie funkcji aplikacyjnych dotyczących pewnego określonego zagadnienia. Nie pasuje to do przypadku użycia…

  4. Zmuszony jestem zmodyfikować moje podejście do systemowego przypadku użycia. “Interakcja pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem” wedle metamodelu Archimate jest spełniona przez “Business Function”, który ma połączenia z “Business Role” i “Application Component” (który utożsamiam z wymienionym przez autora “systemem”).

    “Application Service” nie łączy się z “Application Component” (który utożsamiam z wymienionym przez autora “aktorem”), a więc nie spełnia definicji.

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>