3 Struktura języka

Ten rozdział opisuje strukturę języka modelowania architektury przedsiębiorstwa ArchiMate. Szczegółowe definicje i przykłady standardowego zestawu elementów i relacji znajdują się w rozdziałach 4 do 1

3.1 Rozważania dotyczące projektowania języka

Głównym wyzwaniem w procesie tworzenia ogólnego metamodelu architektury przedsiębiorstwa jest znalezienie odpowiedniego kompromisu między szczegółowością języków dla poszczególnych dziedzin architektury a bardzo ogólnym zestawem pojęć architektonicznych, które odzwierciedlają perspektywę systemów jako prostego zbioru wzajemnie powiązanych jednostek.

Projektowanie języka ArchiMate rozpoczęło się od zestawu względnie ogólnych pojęć. Zostały one dostosowane do zastosowania na różnych poziomach architektonicznych, jak wyjaśniono w kolejnych sekcjach. Najważniejszym ograniczeniem projektowym języka jest jego celowe zaprojektowanie jako możliwie najmniejszego, ale nadal użytecznego do większości zadań modelowania architektury przedsiębiorstwa. Wiele innych języków stara się uwzględnić potrzeby wszystkich możliwych użytkowników. W interesie uproszczenia nauki i użytkowania język ArchiMate został ograniczony do pojęć wystarczających do modelowania typowych 80% przypadków praktycznych.

Ten standard nie opisuje szczegółowych rozważań dotyczących projektowania języka ArchiMate. Ciekawych czytelników prosimy o odniesienie się do [1], [2] i [3], które zawierają szczegółowe opisy budowy języka i rozważań projektowych.

3.2 Struktura najwyższego poziomu języka

Rysunek 1 przedstawia hierarchiczną strukturę najwyższego poziomu języka:

Model to zbiór pojęć – pojęcie to albo element albo relacja
Element to albo element zachowania, element struktury, element motywacji, albo element złożony

Zauważ, że są to abstrakcyjne pojęcia; nie są przeznaczone do bezpośredniego użycia w modelach. Aby to oznaczyć, są przedstawione w białym kolorze z etykietami w kursywie. Zobacz rozdział 4, aby uzyskać wyjaśnienie notacji użytej na rysunku 1.

Rysunek 1: Hierarchia najwyższego poziomu pojęć ArchiMate

3.3 Warstwowanie języka ArchiMate

Język podstawowy ArchiMate definiuje strukturę ogólnych elementów i ich relacji, które mogą być specjalizowane na różnych poziomach. W języku podstawowym ArchiMate zdefiniowano trzy warstwy, jak poniżej:

Warstwa Biznesowa przedstawia usługi biznesowe oferowane klientom, które są realizowane w organizacji za pomocą procesów biznesowych wykonywanych przez aktorów biznesowych.
Warstwa Aplikacyjna przedstawia usługi aplikacyjne wspierające biznes oraz aplikacje, które je realizują.
Warstwa Technologicznaobejmuje zarówno technologię informacyjną, jak i operacyjną. Można na przykład modelować technologię przetwarzania, przechowywania i komunikacji wspierającą świat aplikacji i warstwy biznesowe, a także modelować technologię operacyjną lub fizyczną za pomocą obiektów, sprzętu fizycznego, materiałów i sieci dystrybucyjnych.

Ogólna struktura modeli w różnych warstwach jest podobna. Używane są te same typy elementów i relacji, choć ich dokładna natura i szczegółowość się różnią. W następnej rozdziale przedstawiona jest struktura ogólnego metamodelu. W rozdziałach 8, 9 i 10 te elementy są specjalizowane, aby uzyskać elementy charakterystyczne dla konkretnej warstwy.

Zgodnie z koncepcją orientacji na usługi, najważniejszą relacją między warstwami jest relacja „obsługi”[1]relacje, które pokazują, jak elementy w jednej warstwie są obsługiwane przez usługi innych warstw. (Zauważ jednak, że usługi nie muszą obsługiwać tylko elementów w innej warstwie, ale mogą również obsługiwać elementy w tej samej warstwie.) Drugim typem połączenia są relacje realizacji: elementy w niższych warstwach mogą realizować odpowiednie elementy w wyższych warstwach; np. obiekt

„obiekt danych” (warstwa aplikacji) może realizować „obiekt biznesowy” (warstwa biznesowa); albo

„artefakt” (warstwa technologiczna) może realizować albo „obiekt danych”, albo „komponent aplikacji” (warstwa aplikacji).

3.4 Podstawowy framework ArchiMate

Podstawowy framework ArchiMate to framework składający się z dziewięciu komórek używanych do kategoryzowania elementów języka podstawowego ArchiMate. Składa się on z trzech aspektów i trzech warstw, jak pokazano na rysunku 2. Jest to znany jako podstawowy framework ArchiMate.

Ważne jest zrozumienie, że kategoryzacja elementów na podstawie aspektów i warstw jest tylko ogólna. Elementy architektury z rzeczywistego świata nie muszą być ściśle ograniczone do jednego aspektu lub warstwy, ponieważ elementy łączące różne aspekty i warstwy odgrywają kluczową rolę w spójnym opisie architektury. Na przykład, wyprzedzając późniejsze rozważania koncepcyjne, role biznesowe pełnią funkcję pośredniczącą między elementami „wyłącznie behawioralnymi” a elementami „wyłącznie strukturalnymi”, a to, czy dany fragment oprogramowania jest uznawany za część warstwy aplikacji czy warstwy technologicznej, może zależeć od kontekstu.

Rysunek 2: Podstawowy framework ArchiMate

Struktura frameworku pozwala na modelowanie przedsiębiorstwa z różnych punktów widzenia, gdzie położenie w komórkach podkreśla interesy stakeholdera. Stakeholder zazwyczaj może mieć interesy obejmujące wiele komórek.

Wymiary frameworku są następujące:

Warstwy – trzy poziomy, na których przedsiębiorstwo może być modelowane w ArchiMate – Biznes, Aplikacja i Technologia (jak opisano w sekcji 3.3)
Aspekty:

—Aspekt struktury aktywnej, który reprezentuje elementy strukturalne (aktorów biznesowych, komponentów aplikacji i urządzeń, które wykazują rzeczywistą działalność; tzn.

„podmioty” działalności)

—Aspekt behawioralny, który reprezentuje zachowanie (procesy, funkcje, zdarzenia i usługi) wykonywane przez aktorów; elementy strukturalne są przypisywane do elementów behawioralnych, aby pokazać, kto lub co wykazuje dane zachowanie

—Aspekt struktury pasywnej, który reprezentuje obiekty, na których wykonywane jest zachowanie; są to zazwyczaj obiekty informacyjne w warstwie biznesowej i obiekty danych w warstwie aplikacji, ale mogą również służyć do reprezentowania obiektów fizycznych

Te trzy aspekty zostały inspirowane językiem naturalnym, w którym zdanie ma podmiot (strukturę aktywną), czasownik (zachowanie) i dopełnienie (strukturę pasywną). Używając tych samych konstrukcji, do których ludzie są przyzwyczajeni w swoich językach, język ArchiMate jest łatwiejszy do nauki i czytania.

Ponieważ notacja ArchiMate tograficznajęzyk, w którym elementy są organizowane przestrzennie, ten porządek nie ma znaczenia podczas modelowania.

Element złożony, jak pokazano na rysunku 1, to element, który niekoniecznie pasuje do jednego aspektu (kolumny) frameworku, ale może łączyć dwa lub więcej aspektów.

Zauważ, że język ArchiMate nie wymaga od modelera używania jakiegokolwiek konkretnego układu, takiego jak struktura tego frameworku; jest on jedynie kategoryzacją elementów języka.

3.5 Pełny framework ArchiMate

Pełny framework ArchiMate, jak opisano w tej wersji standardu, dodaje kilka warstw i aspektu do frameworku podstawowego. Elementy fizyczne są uwzględnione w warstwie technologicznej w celu modelowania obiektów fizycznych, sprzętu, sieci dystrybucyjnej i materiałów. W związku z tym są to również elementy podstawowe. Elementy strategii wprowadzono w celu modelowania kierunków i wyborów strategicznych. Są one opisane w rozdziale 7. Aspekt motywacji jest wprowadzony na poziomie ogólnym w następnym rozdziale i szczegółowo opisany w rozdziale 6. Elementy implementacji i migracji są opisane w rozdziale 12. Ostateczny framework ArchiMate Full przedstawiono na rysunku 3.

Rysunek 3: Pełny framework ArchiMate

Język ArchiMate nie definiuje specjalnej warstwy dla informacji; jednak elementy z aspektu struktury biernych, takie jak obiekty biznesowe, obiekty danych i artefakty, są używane do reprezentowania jednostek informacji. Modelowanie informacji jest wspierane na różnych warstwach ArchiMate.

3.6 Abstrakcja w języku ArchiMate

Struktura języka ArchiMate umożliwia kilka znanych form abstrakcji i wzbogacenia. Po pierwsze, rozróżnienie między widokiem zewnętrznym (czarna skrzynka, abstrahującym od zawartości skrzynki) a wewnętrznym (biała skrzynka) jest powszechne w projektowaniu systemów. Widok zewnętrzny przedstawia, co system musi wykonać dla swojego środowiska, podczas gdy widok wewnętrzny przedstawia, jak to robi.

Po drugie, rozróżnienie między zachowaniem a strukturą aktywną jest często używane do oddzielenia tego, co system musi wykonywać, i sposobu, w jaki to robi, od składników systemu (osób, aplikacji i infrastruktury), które to robią. W modelowaniu nowych systemów często wygodnie jest zacząć od zachowań, które system musi wykonywać, podczas gdy w modelowaniu istniejących systemów często wygodnie jest zacząć od osób, aplikacji i infrastruktury, które tworzą system, a następnie szczegółowo przeanalizować zachowania wykonywane przez te struktury aktywne.

Trzecie rozróżnienie dotyczy poziomów abstrakcji konceptualnej, logicznej i fizycznej. Ma swoje korzenie w modelowaniu danych: elementy konceptualne reprezentują informacje, które są istotne dla biznesu; elementy logiczne zapewniają strukturę logiczną tej informacji do jej manipulacji przez systemy informacyjne; elementy fizyczne opisują przechowywanie tej informacji, np. w formie plików lub tabel bazy danych. W języku ArchiMate odpowiada to obiektom biznesowym, obiektom danych i artefaktom, razem z relacjami realizacji między nimi.

Rozróżnienie między elementami logicznymi a fizycznymi zostało również przeniesione do opisu aplikacji. Metamodel przedsiębiorstwa TOGAF [4] zawiera zestaw encji opisujących komponenty i usługi biznesowe, danych, aplikacji i technologii w celu opisania koncepcji architektury. Elementy logiczne to niezależne od implementacji lub produktu zamknięcia danych lub funkcjonalności, podczas gdy elementy fizyczne to tangible komponenty oprogramowania, urządzenia itp. To rozróżnienie jest ujęte w ramach TOGAF w postaci Bloków Budowlanych Architektury (ABB) i Bloków Budowlanych Rozwiązań (SBB). To rozróżnienie znów jest przydatne w przejściu od ogólnych, abstrakcyjnych opisów architektury do konkretnych, poziomu implementacji projektów. Zauważ, że bloki budowlane mogą zawierać wiele elementów, które zazwyczaj są modelowane za pomocą pojęcia grupowania w języku ArchiMate.

Język ArchiMate ma trzy sposoby modelowania takich abstrakcji. Po pierwsze, jak opisano w [6], elementy zachowania, takie jak funkcje aplikacji i technologii, mogą być używane do modelowania komponentów logicznych, ponieważ reprezentują niezależne od implementacji zamknięcia funkcjonalności. Odpowiadające komponenty fizyczne mogą następnie być modelowane za pomocą elementów struktury aktywnej, takich jak komponenty aplikacji i węzły, przypisane do elementów zachowania. Po drugie, język ArchiMate wspiera pojęcie realizacji. Najlepiej można to wyjaśnić, pracując od warstwy technologicznej w górę. Warstwa technologiczna definiuje artefakty fizyczne i oprogramowanie, które realizują komponent aplikacji. Dostarcza również mapowanie do innych pojęć fizycznych, takich jak urządzenia, sieci itp., potrzebnych do realizacji systemu informacyjnego. Relacja realizacji jest również używana do modelowania bardziej abstrakcyjnych form realizacji, takich jak między (bardziej szczegółowym) wymaganiem a (bardziej ogólnym) zasadą, gdzie spełnienie wymagania oznacza zgodność z zasadą. Realizacja jest również dozwolona między komponentami aplikacji i między węzłami. W ten sposób można modelować fizyczny komponent aplikacji lub technologii realizujący komponent logiczny aplikacji lub technologii, odpowiednio. Po trzecie, komponenty logiczne i fizyczne aplikacji mogą być zdefiniowane jako specjalizacje poziomu metamodelu elementu komponentu aplikacji, jak opisano w rozdziale 14 (patrz również przykłady w sekcji 14.2.2). To samo dotyczy komponentów logicznych i fizycznych technologii w metamodelu zawartości TOGAF, które mogą być zdefiniowane jako specjalizacje elementu węzła (patrz sekcja 14.2.3).

Język ArchiMate świadomie nie wspiera różnicy między typami a instancjami. Na poziomie abstrakcji architektury przedsiębiorstwa częściej modeluje się typy i/lub przykłady, a nie instancje. Podobnie, proces biznesowy w języku ArchiMate nie opisuje pojedynczej instancji (tj. jednego wykonania tego procesu). W większości przypadków do modelowania typu obiektu (“cf.” klasa UML®) używany jest obiekt biznesowy, którego w organizacji może istnieć wiele instancji. Na przykład każde wykonanie procesu aplikacji ubezpieczeniowej może prowadzić do konkretnej instancji obiektu biznesowego polisy ubezpieczeniowej, ale nie jest to modelowane w architekturze przedsiębiorstwa.patrzklasa UML®), której w organizacji może istnieć kilka instancji. Na przykład każde wykonanie procesu aplikacji ubezpieczeniowej może prowadzić do konkretnej instancji obiektu biznesowego polisy ubezpieczeniowej, ale nie jest to modelowane w architekturze przedsiębiorstwa.

3.7 Pojęcia i ich notacja

Język ArchiMate rozdziela pojęcia języka (tj. składniki metamodelu) od ich notacji. Różne grupy interesariuszy mogą wymagać różnych notacji, aby zrozumieć model lub widok architektury. W tym względzie język ArchiMate różni się od języków takich jak UML lub BPMN™, które mają tylko jedną znormalizowaną notację. Mechanizm perspektywy wyjaśniony w rozdziale 13 zapewnia środki do definiowania takich wizualizacji skierowanych do interesariuszy.

Chociaż notacja pojęć ArchiMate może (i powinna) być dostosowana do interesariuszy, standard dostarcza jednej wspólny notacji graficznej, którą mogą używać architekci i inni tworzący modele ArchiMate. Notacja ta jest skierowana do odbiorców przyzwyczajonych do istniejących technik modelowania technicznego, takich jak diagramy relacji encji (ERD), UML lub BPMN, dlatego przypomina je. W dalszej części tego dokumentu, chyba że zaznaczono inaczej, symbole używane do przedstawienia pojęć języka reprezentują standardową notację ArchiMate. Standardowa notacja dla większości elementów składa się z prostokąta z ikoną w prawym górnym rogu. W kilku przypadkach ikona samodzielnie może być używana jako alternatywna notacja. Standardową ikonografię należy preferować, gdy to możliwe, aby każdy znający język ArchiMate mógł odczytać diagramy tworzone w tym języku.

3.8 Użycie zagnieżdżania

Zagnieżdżanie elementów w innych elementach może być używane jako alternatywna notacja graficzna do wyrażania niektórych relacji. Jest to szczegółowo wyjaśnione w rozdziale 5 oraz w definicji każdej z tych relacji.

3.9 Użycie kolorów i podpowiedzi notacyjnych

Na obrazach metamodelu w tym standardzie używane są odcienie szarości, aby odróżnić elementy należące do różnych aspektów frameworku ArchiMate, następująco:

Biały dla pojęć abstrakcyjnych (tj. niemogących być instancjami)
Słaby szary dla struktur biernych
Średni szary dla zachowań
Ciemny szary dla struktur aktywnych

W modelach ArchiMate nie przypisuje się formalnych semantyk kolorów, a ich użycie pozostawia się modelerowi. Można jednak swobodnie używać kolorów, aby podkreślić pewne aspekty w modelach. Na przykład w wielu modelach przykładów przedstawionych w tym standardzie kolory są używane do odróżnienia warstw frameworku podstawowego ArchiMate, następująco:

Żółty dla warstwy biznesowej
Niebieski dla warstwy aplikacji
Zielony dla warstwy technologicznej

Można również używać ich do podkreślenia wizualnego. Zalecanym tekstem zawierającym wytyczne jest rozdział 6 [1]. Oprócz kolorów, można używać innych podpowiedzi notacyjnych do odróżnienia warstw frameworku. Litera M, S, B, A, T, P lub I w lewym górnym rogu elementu może oznaczać element motywacji, strategii, biznesowy, aplikacji, technologiczny, fizyczny lub implementacji i migracji, odpowiednio. Przykład tej notacji przedstawiono na przykładzie 34.

Standardowa notacja używa również konwencji dotyczącej kształtu narożników symboli dla różnych typów elementów, jak poniżej:

Narożniki kwadratowe są używane do oznaczania elementów strukturalnych
Narożniki okrągłe są używane do oznaczania elementów zachowania
Narożniki skośne są używane do oznaczania elementów motywacji

[1]Zauważ, że w poprzednich wersjach standardu nazywano to „używane przez”. W celu jasności nazwa została zmieniona na „obsługujące”.