Język opisu architektury - Architecture description language

Opis architektury językach ( ADLS ) są wykorzystywane w wielu dziedzinach: inżynierii systemów , inżynierii oprogramowania i modelowania Przedsiębiorstwo inżynieryjne.

Społeczność inżynierów systemów używa języka opisu architektury jako języka i / lub modelu koncepcyjnego do opisywania i reprezentowania architektur systemu .

Wspólnota inżynierii oprogramowania wykorzystuje architekturę opis języka jako języka komputerowego do tworzenia opisu o architekturze oprogramowania . W przypadku tak zwanej architektury technicznej o architekturze należy poinformować twórców oprogramowania; architektura funkcjonalna jest przekazywana do różnych zainteresowanych stron i użytkowników. Niektóre opracowane ADL to: Acme (opracowane przez CMU ), AADL (opracowane przez SAE ), C2 (opracowane przez UCI ), SBC-ADL (opracowane przez National Sun Yat-Sen University ), Darwin (opracowane przez Imperial College London ) i Wright (opracowane przez CMU ).

Przegląd

Dokument ISO / IEC / IEEE 42010 , Inżynieria systemów i oprogramowania - Opis architektury , definiuje język opisu architektury jako „dowolną formę wyrażenia do użycia w opisach architektury” i określa minimalne wymagania dotyczące ADL .

Społeczność zajmująca się modelowaniem i inżynierią przedsiębiorstwa opracowała również języki opisu architektury, które są obsługiwane na poziomie przedsiębiorstwa. Przykłady obejmują ArchiMate (obecnie standard The Open Group ), DEMO , ABACUS (opracowany przez University of Technology w Sydney ). Języki te niekoniecznie odnoszą się do komponentów oprogramowania itp. Większość z nich odnosi się jednak do architektury aplikacji jako architektury, która jest przekazywana inżynierom oprogramowania.

Większość poniższych tekstów odnosi się przede wszystkim do perspektywy społeczności inżynierów oprogramowania.

Standardowa notacja (ADL) do reprezentowania architektur pomaga promować wzajemną komunikację, ucieleśnienie wczesnych decyzji projektowych i tworzenie możliwej do przeniesienia abstrakcji systemu. Architektury w przeszłości były w dużej mierze reprezentowane przez rysunki prostokątne z adnotacjami takimi jak natura komponentu, właściwości, semantyka połączeń i ogólne zachowanie systemu. ADL są wynikiem lingwistycznego podejścia do formalnej reprezentacji architektur i jako takie eliminują jej wady. Co również ważne, wyrafinowane ADL pozwalają na wczesną analizę i testowanie wykonalności decyzji architektonicznych.

Historia

ADL zostały podzielone na trzy szerokie kategorie: nieformalne rysunki typu box-and-line, język opisu architektury formalnej i notacje oparte na UML ( Unified Modeling Language ).

Ramka i linia były przez długi czas najbardziej dominującym sposobem opisywania SA. Poziom nieformalności, dostarczając użytecznej dokumentacji, ograniczał użyteczność opisu architektury. Wymagany był bardziej rygorystyczny sposób opisu SA. Cytując Allena i Garlana (1997), „chociaż te opisy [ramka i kreska] mogą stanowić użyteczną dokumentację, obecny poziom nieformalności ogranicza ich użyteczność. Ponieważ jest ogólnie nieprecyzyjne, co oznaczają takie opisy architektoniczne, może być niemożliwe przeanalizować architekturę pod kątem spójności lub określić jej nietrywialne właściwości. Ponadto nie ma możliwości sprawdzenia, czy implementacja systemu jest wierna projektowi architektonicznemu ”. Podobny wniosek wyciągają Perry i Wolf (1992), którzy donoszą, że: „Oprócz zapewnienia jasnej i precyzyjnej dokumentacji, głównym celem specyfikacji jest zapewnienie automatycznej analizy dokumentów i ujawnienie różnego rodzaju problemów, które w przeciwnym razie nie wykryty."

Od tamtej pory prowadzono wątek badań nad językami formalnymi do opisu SA. Zaproponowano dziesiątki formalnych ADL, z których każdy charakteryzuje się innymi koncepcyjnymi elementami architektonicznymi, inną składnią lub semantyką, koncentrując się na określonej dziedzinie operacyjnej lub nadających się tylko do różnych technik analizy. Na przykład, ADL specyficzne dla domeny zostały zaprezentowane w celu radzenia sobie z systemami wbudowanymi i systemami czasu rzeczywistego (takimi jak AADL, EAST-ADL i EADL), aplikacjami pętli sterowania (DiaSpec), architekturami linii produktów (Koala) i systemami dynamicznymi (Π-ADL)). Zaproponowano specyficzne dla analizy ADL, aby zajmować się dostępnością, niezawodnością, bezpieczeństwem, zużyciem zasobów, jakością danych i analizą wydajności w czasie rzeczywistym (AADL, analiza behawioralna (Fractal)) i analizą wiarygodności (TADL).

Jednak wysiłki te nie przyniosły pożądanego przyjęcia w praktyce przemysłowej. Niektóre przyczyny tego braku przyjęcia w branży zostały przeanalizowane przez Woodsa i Hilliarda, Pandeya, Clementsa i innych: formalne ADL rzadko były włączane do cyklu życia oprogramowania, rzadko są wspierane przez dojrzałe narzędzia, słabo udokumentowane, koncentrujące się na bardzo specyficznych potrzeb i nie pozostawiając miejsca na rozszerzenia umożliwiające dodawanie nowych funkcji.

Aby przezwyciężyć niektóre z tych ograniczeń, UML został wskazany jako potencjalny następca istniejących ADL. Przedstawiono wiele propozycji wykorzystania lub rozszerzenia UML w celu bardziej odpowiedniego modelowania architektur oprogramowania.

W rzeczywistości, jak podkreślono w niedawnym badaniu przeprowadzonym z praktykami, podczas gdy praktycy są na ogół zadowoleni z możliwości projektowych zapewnianych przez języki, których używają, są niezadowoleni z funkcji analizy języka architektonicznego i ich zdolności do definiowania właściwości pozafunkcjonalnych; języki architektoniczne używane w praktyce najczęściej wywodzą się z rozwoju przemysłowego, a nie z badań naukowych; od języka architektonicznego wymaga się większej formalności i lepszej użyteczności.

Charakterystyka

Istnieje duża różnorodność ADL opracowanych przez grupy akademickie lub przemysłowe. Wiele języków nie miało być ADL, ale okazały się one odpowiednie do reprezentowania i analizowania architektury. Zasadniczo ADL różnią się od języków wymagań, ponieważ ADL są zakorzenione w przestrzeni rozwiązań , podczas gdy wymagania opisują przestrzenie problemowe. Różnią się od języków programowania, ponieważ ADL nie wiążą abstrakcji architektonicznych z określonymi rozwiązaniami punktowymi. Języki modelowania reprezentują zachowania, w których ADL koncentrują się na reprezentacji komponentów. Istnieją jednak języki modelowania specyficzne dla domeny (DSML), które koncentrują się na reprezentacji składników.

Minimalne wymagania

Język musi:

  • Nadawaj się do komunikowania architektury wszystkim zainteresowanym stronom
  • Wspieraj zadania związane z tworzeniem, udoskonalaniem i walidacją architektury
  • Zapewnia podstawę do dalszej implementacji, więc musi być w stanie dodawać informacje do specyfikacji ADL, aby umożliwić wyprowadzenie ostatecznej specyfikacji systemu z ADL
  • Zapewniają możliwość reprezentowania większości popularnych stylów architektonicznych
  • Wspieraj możliwości analityczne lub zapewniaj szybkie generowanie prototypów

ADL mają wspólne:

  • Składnia graficzna z często formą tekstową oraz formalnie zdefiniowaną składnią i semantyką
  • Funkcje modelowania systemów rozproszonych
  • Niewielkie wsparcie dla przechwytywania informacji projektowych, z wyjątkiem mechanizmów adnotacji ogólnego przeznaczenia
  • Możliwość reprezentowania hierarchicznych poziomów szczegółów, w tym tworzenia podstruktur poprzez tworzenie instancji szablonów

ADL różnią się zdolnością do:

  • Obsługuj konstrukcje w czasie rzeczywistym, takie jak terminy i priorytety zadań, na poziomie architektonicznym
  • Obsługa specyfikacji różnych stylów architektonicznych. Niewiele osób zajmuje się dziedziczeniem klas zorientowanych obiektowo lub architekturami dynamicznymi
  • Wspieraj analizę architektury
  • Obsługuj różne instancje tej samej architektury w odniesieniu do architektur linii produktów

Pozytywne elementy ADL

  • ADL to formalny sposób przedstawiania architektury
  • ADL mają być czytelne zarówno dla człowieka, jak i dla maszyny
  • ADL obsługują opisywanie systemu na wyższym poziomie niż było to wcześniej możliwe
  • ADL umożliwiają analizę i ocenę architektur pod kątem kompletności, spójności, niejednoznaczności i wydajności
  • ADL mogą obsługiwać automatyczne generowanie systemów oprogramowania

Negatywne elementy ADL

  • Nie ma powszechnej zgody co do tego, co powinny reprezentować ADL, szczególnie w odniesieniu do zachowania architektury
  • Obecnie używane reprezentacje są stosunkowo trudne do przeanalizowania i nie są obsługiwane przez narzędzia komercyjne
  • Większość ADL ma tendencję do bardzo pionowej optymalizacji pod kątem określonego rodzaju analizy

Wspólne koncepcje architektury

Społeczność ADL ogólnie zgadza się, że architektura oprogramowania to zestaw komponentów i połączeń między nimi. Ale są różne rodzaje architektur, takie jak:

Architektura połączeń obiektów

  • Konfiguracja składa się z interfejsów i połączeń systemu zorientowanego obiektowo
  • Interfejsy określają funkcje, które muszą być zapewniane przez moduły zgodne z interfejsem
  • Połączenia reprezentowane przez interfejsy wraz z wykresem wywołań
  • Zgodność zwykle wymuszana przez język programowania
    • Dekompozycja - kojarzenie interfejsów z unikalnymi modułami
    • Zgodność interfejsu - statyczne sprawdzanie reguł składniowych
    • Integralność komunikacji - widoczność między modułami

Architektura połączeń interfejsu

  • Rozszerza rolę interfejsów i połączeń
    • Interfejsy określają zarówno „wymagane”, jak i „dostarczone” funkcje
    • Połączenia są definiowane między funkcjami „wymaganymi” a funkcjami „dostarczonymi”
  • Składa się z interfejsów, połączeń i ograniczeń
    • Ograniczenia ograniczają zachowanie interfejsów i połączeń w architekturze
    • Ograniczenia w architekturze odwzorowują wymagania systemu

Większość ADL implementuje architekturę połączeń interfejsu.

Architektura a projektowanie

Architektura w kontekście systemów oprogramowania jest z grubsza podzielona na kategorie, przede wszystkim architekturę oprogramowania, architekturę sieci i architekturę systemów. W każdej z tych kategorii istnieje namacalna, ale niewyraźna różnica między architekturą a designem. Aby rozróżnić to tak uniwersalnie i jasno, jak to tylko możliwe, najlepiej jest rozważyć projekt jako rzeczownik, a nie jako czasownik, tak aby porównanie dotyczyło dwóch rzeczowników.

Projekt to abstrakcja i specyfikacja wzorców i organów funkcjonalności, które zostały lub zostaną wdrożone. Architektura jest wyższa zarówno pod względem abstrakcji, jak i szczegółowości. W konsekwencji architektura ma również bardziej charakter topologiczny niż projekt, ponieważ określa, gdzie spotykają się główne komponenty i jak są one ze sobą powiązane. Architektura koncentruje się na podziale głównych obszarów funkcjonalności na komponenty wysokiego poziomu, gdzie będą fizycznie lub wirtualnie przebywać, jakie gotowe komponenty mogą być efektywnie wykorzystywane, ogólnie jakie interfejsy będą eksponowane przez każdy komponent, jakie protokoły będą stosowane między oraz jakie praktyki i wzorce wysokiego poziomu mogą najlepiej odpowiadać rozszerzalności , łatwości konserwacji , niezawodności, trwałości, skalowalności i innym niefunkcjonalnym celom. Projekt to uszczegółowienie tych wyborów i bardziej konkretne wyjaśnienie, w jaki sposób wymagania funkcjonalne zostaną spełnione poprzez delegowanie części tej funkcji do bardziej szczegółowych komponentów i jak te mniejsze komponenty zostaną zorganizowane w ramach większych.

Często część architektury jest wykonywana podczas konceptualizacji aplikacji, systemu lub sieci i może pojawić się w niefunkcjonalnych sekcjach dokumentacji wymagań. Kanonicznie, projekt nie jest określony w wymaganiach, ale raczej się nimi kieruje.

Proces definiowania architektury może obejmować heurystykę, zdobytą przez architekta lub zespół architektów poprzez doświadczenie w tej dziedzinie. Podobnie jak w przypadku projektowania, architektura często ewoluuje poprzez serię iteracji i tak jak mądrość projektu wysokiego poziomu jest często testowana, gdy pojawia się projekt i implementacja niskiego poziomu, tak mądrość architektury jest testowana podczas specyfikacji projektu wysokiego poziomu. W obu przypadkach, jeśli mądrość specyfikacji zostanie zakwestionowana podczas detalowania, może być konieczna kolejna iteracja architektury lub projektu, w zależności od przypadku.

Podsumowując, podstawowe różnice między architekturą a projektowaniem to granularność i abstrakcja, a także (w konsekwencji) chronologia. (Architektura generalnie poprzedza projekt, chociaż nakładanie się i cykliczna iteracja jest powszechną rzeczywistością).

Przykłady

Poniżej lista podaje kandydatów na najlepszych dotychczas ADL.

Aby uzyskać aktualną listę aktualnie istniejących języków architektonicznych, zapoznaj się z aktualną listą ADL .

Podejścia do architektury

Podejścia do architektury

  • Podejście akademickie
    • skupić się na analitycznej ocenie modeli architektonicznych
    • poszczególne modele
    • rygorystyczne notacje modelowania
    • potężne techniki analizy
    • głębokość ponad szerokość
    • rozwiązania specjalnego przeznaczenia
  • Podejście przemysłowe
    • skupić się na szerokim zakresie zagadnień programistycznych
    • rodziny modeli
    • praktyczność nad rygorem
    • architektura jako duży obraz rozwoju
    • szerokość na głębokości
    • rozwiązania ogólnego przeznaczenia

Zobacz też

Bibliografia

Linki zewnętrzne