Opis architektury oprogramowania

Opis architektury oprogramowania to zestaw praktyk służących do wyrażania, komunikowania się i analizowania architektur oprogramowania (zwanych także renderowaniem architektury) oraz wynik zastosowania takich praktyk poprzez produkt pracy wyrażający architekturę oprogramowania ( ISO/IEC/IEEE 42010 ).

Opisy architektury (AD) są czasami określane jako reprezentacje architektury , specyfikacje architektury lub dokumentacja architektury oprogramowania .

koncepcje

Opis architektury definiuje praktyki, techniki i typy reprezentacji używane przez architektów oprogramowania do rejestrowania architektury oprogramowania. Opis architektury jest w dużej mierze czynnością modelowania ( programowy model architektoniczny ). Modele architektury mogą przybierać różne formy, w tym tekst, nieformalne rysunki, diagramy lub inne formy ( język modelowania ). Opis architektury często wykorzystuje kilka różnych rodzajów modeli, aby skutecznie dotrzeć do różnych odbiorców, interesariuszy (takich jak użytkownicy końcowi, właściciele systemów, twórcy oprogramowania, inżynierowie systemowi, menedżerowie programów) oraz różne kwestie architektoniczne ( takie jak funkcjonalność, bezpieczeństwo, dostawa, niezawodność, skalowalność).

Często modele opisu architektury są zorganizowane w wiele widoków architektury, tak że „każdy [widok] dotyczy konkretnych problemów interesujących różnych interesariuszy systemu”. Perspektywa architektury to sposób patrzenia na system ( RM ODP ). Każdy widok w opisie architektury powinien mieć punkt widzenia dokumentujący obawy i interesariuszy, do których jest skierowany, oraz rodzaje modeli, notacje i konwencje modelowania, z których korzysta ( ISO/IEC/IEEE 42010 ).

Korzystanie z wielu widoków, choć skuteczne w komunikowaniu się z różnymi zainteresowanymi stronami oraz rejestrowaniu i analizowaniu różnych problemów, stwarza potencjalne problemy: ponieważ widoki zazwyczaj nie są niezależne, możliwość nakładania się oznacza, że ​​może występować redundancja lub niespójność między widokami jednego systemu. Różne mechanizmy mogą być używane do definiowania i zarządzania zgodnością między widokami w celu udostępniania szczegółów, zmniejszania redundancji i wymuszania spójności.

Powszechnym nieporozumieniem dotyczącym opisów architektury jest to, że AD omawiają tylko „kwestie techniczne”, podczas gdy AD muszą odnosić się do kwestii istotnych dla wielu interesariuszy. Niektóre problemy mają charakter techniczny; wiele problemów nie jest: AD są używane, aby pomóc architektom, ich klientom i innym osobom zarządzać kosztami, harmonogramem i procesami. Powiązanym nieporozumieniem jest to, że AD odnoszą się tylko do strukturalnych aspektów systemu. Jednak rzadko zadowala to interesariuszy, których obawy często obejmują kwestie strukturalne, behawioralne, estetyczne i inne „pozafunkcjonalne”.

Historia

Najwcześniejsze opisy architektury wykorzystywały nieformalne obrazy i diagramy oraz związany z nimi tekst. Nieformalne opisy pozostają najczęściej używanymi reprezentacjami w przemyśle. Wpływy na opis architektury pochodziły z obszarów inżynierii oprogramowania (takich jak abstrakcja danych i programowanie na dużą skalę) oraz z projektowania systemów (takich jak SARA).

Prace nad programowaniem w dużych, takich jak języki łączenia modułów (MIL), skupiały się na wyrażaniu wielkoskalowych właściwości oprogramowania: modułów (w tym programów, bibliotek, podprogramów i podsystemów) oraz relacji między modułami (zależności i połączenia między modułami) . Ta praca wpłynęła zarówno na architektoniczne myślenie o językach programowania (np. Ada), jak i na notacje projektowe i architektoniczne (takie jak diagramy Buhra i mapy przypadków użycia oraz skodyfikowane w architekturze cechy UML: pakiety, podsystemy, zależności), a także na większość prac nad architekturą języki opisu. Oprócz MIL-ów, pod wpływem dojrzałych prac w obszarach Wymagań i Projektowania w Inżynierii Oprogramowania, różne rodzaje modeli zostały „podniesione” z inżynierii oprogramowania i projektowania do zastosowania do opisu architektur. Obejmowały one modele funkcji i aktywności z analizy strukturalnej SADT , techniki modelowania danych (entity-relation) i techniki obiektowe.

Perry i Wolf przytoczyli precedens architektury budynku dotyczący roli wielu widoków: „Architekt budynku pracuje z klientem za pomocą wielu różnych widoków, w których podkreśla się jakiś szczególny aspekt budynku”.

Perry i Wolf postulowali, aby reprezentacja architektury obejmowała: {elementy, formę i uzasadnienie} , rozróżniając trzy rodzaje elementów (a więc trzy rodzaje widoków):

  • przetwarzanie: w jaki sposób przetwarzane są dane;
  • dane: informacje, które są wykorzystywane i przekształcane;
  • łączenie: klej spajający pozostałe elementy;

Perry i Wolf zidentyfikowali cztery cele lub zastosowania opisów architektury (zwanych w swoim artykule „specyfikacjami architektury”):

  • określać ograniczenia architektoniczne bez zbytniego określania rozwiązań
  • oddzielić estetykę od inżynierii
  • wyrażać różne aspekty architektury, każdy w odpowiedni sposób
  • przeprowadzać analizy architektury, w szczególności analizy zależności i spójności

Po artykule Perry'ego i Wolfa pojawiły się dwie szkoły myślenia na temat opisu architektury oprogramowania [ potrzebne źródło ] :

  • Szkoła wielu widoków
  • Szkoła strukturalistyczna

Mechanizmy opisu architektury

Istnieje kilka typowych mechanizmów używanych do opisu architektury. Mechanizmy te ułatwiają ponowne wykorzystanie skutecznych stylów opisu, dzięki czemu można je zastosować w wielu systemach:

  • punkty widzenia architektury
  • języki opisu architektury
  • ramy architektury

Punkty widzenia architektury

Opisy architektury oprogramowania są zwykle zorganizowane w widoki , które są analogiczne do różnych typów planów tworzonych w architekturze budynków . Każdy pogląd odnosi się do zestawu problemów systemowych, zgodnie z konwencjami jego punktu widzenia , gdzie punkt widzenia jest specyfikacją opisującą notacje, techniki modelowania, które mają być użyte w celu wyrażenia danej architektury z perspektywy danego zestawu interesariuszy i ich obawy ( ISO/IEC 42010 ). Punkt widzenia określa nie tylko sformułowane obawy (tj. do rozwiązania), ale także prezentację, zastosowane rodzaje modeli, zastosowane konwencje i wszelkie zasady spójności (korespondencji), aby zachować spójność poglądu z innymi poglądami.

Przykłady punktów widzenia obejmują:

  • Funkcjonalny punkt widzenia
  • Logiczny punkt widzenia
  • Punkt widzenia informacji/danych
  • Punkt widzenia modułu
  • Punkt widzenia komponentu i złącza
  • Punkt widzenia wymagań
  • Punkt widzenia programisty/implementacji
  • Punkt widzenia współbieżności/procesu/środowiska wykonawczego/wątku/wykonania
  • Punkt widzenia wydajności
  • Punkt widzenia bezpieczeństwa
  • Punkt widzenia fizyczny/wdrożenia/instalacji
  • Punkt widzenia działań użytkownika/opinii

Termin typ widoku jest używany w odniesieniu do kategorii podobnych widoków, które mają wspólny zestaw elementów i relacji.

Języki opisu architektury

Język opisu architektury ( ADL ) to dowolny środek wyrazu używany do opisu architektury oprogramowania ( ISO/IEC/IEEE 42010 ). Od lat 90. opracowano wiele ADL specjalnego przeznaczenia, w tym AADL (standard SAE), Wright (opracowany przez Carnegie Mellon), Acme (opracowany przez Carnegie Mellon), xADL (opracowany przez UCI), Darwin (opracowany przez Imperial College London ), DAOP-ADL (opracowany przez Uniwersytet w Maladze) i ByADL (Uniwersytet w L'Aquila, Włochy). Wczesne ADL kładły nacisk na modelowanie systemów pod względem ich komponentów, złączy i konfiguracji. Nowsze ADL (takie jak ArchiMate i SysML) były zwykle językami „szerokiego spektrum”, zdolnymi do wyrażania nie tylko komponentów i złączy, ale także różnorodnych problemów za pośrednictwem wielu podjęzyków. Oprócz języków specjalnego przeznaczenia, istniejące języki, takie jak UML , mogą być używane jako ADL „do analizy, projektowania i wdrażania systemów opartych na oprogramowaniu, a także do modelowania procesów biznesowych i podobnych”.

Ramy architektury

Ramy architektury obejmują „konwencje, zasady i praktyki dotyczące opisu architektur ustanowione w określonej dziedzinie zastosowania i/lub społeczności interesariuszy” ( ISO/IEC/IEEE 42010 ). Ramy są zwykle wdrażane pod względem jednego lub więcej punktów widzenia lub ADL. Ramy zainteresowania architekturą oprogramowania obejmują:

Wiele widoków

to, przedstawione w bardzo wpływowym artykule Kruchtena z 1995 r. na temat „modelu widoku 4 + 1” , kładło nacisk na różnych interesariuszy i problemy, które należy modelować.

Strukturalizm

Po drugie, odzwierciedlenie w pracach CMU i gdzie indziej, pogląd, że architektura jest organizacją wysokiego poziomu systemu w czasie wykonywania i że architektura powinna być opisana w kategoriach ich komponentów i złączy: „architektura systemu oprogramowania definiuje ten system pod względem komponentów obliczeniowych i interakcji między tymi komponentami”.

W latach 1990-2000 większość prac akademickich nad ADL odbywała się w ramach paradygmatu komponentów i złączy. Jednak te ADL miały bardzo niewielki wpływ na przemysł. Od lat 90. nastąpiła zbieżność podejść do opisu architektury, a IEEE 1471 w 2000 r. Kodyfikował najlepsze praktyki: wspieranie, ale nie wymaganie, wielu punktów widzenia w AD.

Opis architektury za pomocą decyzji

Rozwijając aspekt racjonalności oryginalnej formuły Perry'ego i Wolfa, wyłoniła się trzecia szkoła myślenia, dokumentująca decyzje i przyczyny decyzji jako podstawowy sposób pojmowania i wyrażania architektury oprogramowania. Podejście to traktuje decyzje jako pierwszorzędne elementy opisu architektury, wyjaśniając to, co często było ukryte we wcześniejszych reprezentacjach.

Zastosowania opisów architektury

Opisy architektury służą różnym celom, w tym ( ISO/IEC/IEEE 42010 ):

  • do kierowania budową i konserwacją systemu
  • aby wspomóc planowanie systemu, kalkulację kosztów i ewolucję
  • służyć jako medium do analizy, oceny lub porównania architektur
  • w celu ułatwienia komunikacji między interesariuszami systemu w zakresie architektury i systemu
  • dokumentować wiedzę architektoniczną wykraczającą poza zakres poszczególnych projektów (takich jak linie i rodziny produktów oprogramowania oraz architektury referencyjne)
  • do przechwytywania idiomów architektonicznych wielokrotnego użytku (takich jak style i wzorce architektoniczne)

Zobacz też

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Software_architecture_description&oldid=1090015493 ”