Architektura oprogramowania - Software architecture

Rozwój oprogramowania
Podstawowa działalność
inżynierii oprogramowania
Paradygmaty i modele
Metodologie i ramy
Dyscypliny wspierające
Praktyki
Narzędzia
Standardy i zbiory wiedzy
Glosariusze
Wytyczne

Architektura oprogramowania odnosi się do podstawowych struktur systemu oprogramowania oraz dyscypliny tworzenia takich struktur i systemów. Każda struktura zawiera elementy oprogramowania, relacje między nimi oraz właściwości zarówno elementów, jak i relacji. Architektura systemu oprogramowania jest metaforą, analogiczne do architektury budynku. Funkcjonuje jako plan dla systemu i rozwijającego się projektu, określając zadania niezbędne do wykonania przez zespoły projektowe.

Architektura oprogramowania polega na dokonywaniu fundamentalnych wyborów strukturalnych, których zmiana po wdrożeniu jest kosztowna. Wybór architektury oprogramowania obejmuje określone opcje konstrukcyjne z możliwości projektowania oprogramowania . Na przykład systemy, które sterowały pojazdem startowym promu kosmicznego, musiały być bardzo szybkie i bardzo niezawodne. Dlatego należałoby wybrać odpowiedni język przetwarzania w czasie rzeczywistym . Dodatkowo, aby zaspokoić potrzebę niezawodności, można dokonać wyboru, aby mieć wiele nadmiarowych i niezależnie produkowanych kopii programu oraz uruchamiać te kopie na niezależnym sprzęcie podczas sprawdzania wyników.

Dokumentująca architektura oprogramowania ułatwia komunikację między zainteresowanymi stronami , umożliwia przechwytywanie wczesnych decyzji dotyczących projektu wysokiego poziomu i umożliwia ponowne wykorzystanie komponentów projektowych między projektami.

Oprogramowanie_Architektura_Działania

Zakres

Opinie co do zakresu architektur oprogramowania są różne:

  • Makroskopowa struktura systemu : odnosi się do architektury jako abstrakcji wyższego poziomu systemu oprogramowania, która składa się ze zbioru komponentów obliczeniowych wraz ze złączami opisującymi interakcję między tymi komponentami.
  • Ważne rzeczy — cokolwiek to jest : odnosi się do faktu, że architekci oprogramowania powinni zajmować się tymi decyzjami, które mają duży wpływ na system i jego interesariuszy.
  • To, co jest fundamentalne dla zrozumienia systemu w jego otoczeniu
  • Rzeczy, które ludzie postrzegają jako trudne do zmiany : ponieważ projektowanie architektury ma miejsce na początku cyklu życia oprogramowania, architekt powinien skupić się na decyzjach, które „muszą” być słuszne za pierwszym razem. Idąc tym tokiem rozumowania, problemy związane z projektowaniem architektonicznym mogą stać się niearchitektoniczne, gdy uda się przezwyciężyć ich nieodwracalność.
  • Zbiór architektonicznych decyzji projektowych : architektura oprogramowania nie powinna być traktowana jedynie jako zbiór modeli lub struktur, ale powinna zawierać decyzje, które prowadzą do tych konkretnych struktur, oraz uzasadnienie ich powstania. Te spostrzeżenia doprowadziły do ​​poważnych badań nad zarządzaniem wiedzą o architekturze oprogramowania .

Nie ma wyraźnego rozróżnienia między architekturą oprogramowania a projektowaniem i inżynierią wymagań (patrz Powiązane pola poniżej). Wszystkie są częścią „łańcucha intencjonalności” od intencji wysokiego poziomu do szczegółów niskiego poziomu.

Charakterystyka

Architektura oprogramowania charakteryzuje się następującymi cechami:

Mnogość interesariuszy: systemy oprogramowania muszą obsługiwać różnych interesariuszy, takich jak menedżerowie biznesowi, właściciele, użytkownicy i operatorzy. Wszyscy ci interesariusze mają swoje własne obawy dotyczące systemu. Zrównoważenie tych obaw i wykazanie, że są one rozwiązane, jest częścią projektowania systemu. Oznacza to, że architektura obejmuje radzenie sobie z szeroką gamą problemów i interesariuszy oraz ma charakter multidyscyplinarny.

Oddzielenie obaw : ustalonym sposobem dla architektów na zmniejszenie złożoności jest oddzielenie obaw, które kierują projektem. Dokumentacja architektury pokazuje, że wszystkie obawy interesariuszy są rozwiązywane poprzez modelowanie i opisywanie architektury z oddzielnych punktów widzenia związanych z różnymi problemami interesariuszy. Te oddzielne opisy są nazywane widokami architektonicznymi (zobacz na przykład model widoku architektonicznego 4+1 ).

Oparte na jakości: klasyczne podejścia do projektowania oprogramowania (np. Programowanie strukturalne Jacksona ) były napędzane wymaganą funkcjonalnością i przepływem danych przez system, ale obecny pogląd jest taki, że architektura systemu oprogramowania jest ściślej powiązana z jego atrybutami jakości, takimi jak tolerancji błędu , wsteczna kompatybilność , rozszerzalność , niezawodność , łatwość konserwacji , dostępność , bezpieczeństwo, użyteczność, i inne takie - ilities . Obawy interesariuszy często przekładają się na wymagania dotyczące tych atrybutów jakościowych, które są różnie nazywane wymaganiami niefunkcjonalnymi, wymaganiami pozafunkcjonalnymi, wymaganiami behawioralnymi lub wymaganiami atrybutów jakości.

Powtarzające się style: podobnie jak architektura budynku, dyscyplina architektury oprogramowania opracowała standardowe sposoby rozwiązywania powtarzających się problemów. Te „standardowe sposoby” są nazywane różnymi nazwami na różnych poziomach abstrakcji. Wspólne terminy dla powtarzających się rozwiązań to styl architektoniczny, taktyka, architektura referencyjna i wzorzec architektoniczny .

Integralność koncepcyjna: termin wprowadzony przez Freda Brooksa w The Mythical Man-Month, aby wskazać ideę, że architektura systemu oprogramowania reprezentuje ogólną wizję tego, co powinien robić i jak powinien to robić. Tę wizję należy oddzielić od jej realizacji. Architekt pełni rolę „strażnika wizji”, upewniając się, że dodatki do systemu są zgodne z architekturą, a tym samym zachowują integralność koncepcyjną .

Ograniczenia poznawcze: obserwacja po raz pierwszy poczyniona w artykule z 1967 roku przez programistę komputerowego Melvina Conwaya, że organizacje projektujące systemy są zmuszone do tworzenia projektów, które są kopiami struktur komunikacyjnych tych organizacji. Podobnie jak w przypadku integralności koncepcyjnej, to Fred Brooks przedstawił ją szerszej publiczności, cytując artykuł i pomysł w swoim eleganckim klasyku The Mythical Man-Month , nazywając go „Prawem Conwaya”.

Motywacja

Architektura oprogramowania jest „intelektualnie uchwyconą” abstrakcją złożonego systemu. Ta abstrakcja zapewnia szereg korzyści:

  • Daje podstawę do analizy zachowania systemów oprogramowania przed jego zbudowaniem. Możliwość sprawdzenia, czy przyszły system oprogramowania spełnia potrzeby interesariuszy bez konieczności budowania go, oznacza znaczne oszczędności i ograniczenie ryzyka. Opracowano szereg technik do przeprowadzania takich analiz, takich jak ATAM lub tworzenie wizualnej reprezentacji systemu oprogramowania.
  • Stanowi podstawę do ponownego wykorzystania elementów i decyzji. Kompletną architekturę oprogramowania lub jej części, takie jak indywidualne strategie i decyzje architektoniczne, można ponownie wykorzystać w wielu systemach, których interesariusze wymagają podobnych atrybutów jakościowych lub funkcjonalności, co pozwala zaoszczędzić koszty projektowania i zmniejszyć ryzyko błędów projektowych.
  • Obsługuje wczesne decyzje projektowe, które mają wpływ na rozwój, wdrażanie i konserwację systemu. Właściwe podejmowanie wczesnych decyzji o dużym wpływie jest ważne, aby zapobiec przekroczeniu harmonogramu i budżetu .
  • Ułatwia komunikację z interesariuszami, przyczyniając się do stworzenia systemu, który lepiej spełnia ich potrzeby. Komunikowanie się o złożonych systemach z punktu widzenia interesariuszy pomaga im zrozumieć konsekwencje stawianych wymagań i opartych na nich decyzji projektowych. Architektura daje możliwość komunikowania się o decyzjach projektowych jeszcze przed wdrożeniem systemu, gdy są one jeszcze stosunkowo łatwe do adaptacji.
  • Pomaga w zarządzaniu ryzykiem. Architektura oprogramowania pomaga zmniejszyć ryzyko i ryzyko niepowodzenia.
  • Umożliwia redukcję kosztów . Architektura oprogramowania to sposób na zarządzanie ryzykiem i kosztami w złożonych projektach informatycznych.

Historia

Porównanie między projektowaniem oprogramowania a architekturą (cywilną) zostało po raz pierwszy sporządzone pod koniec lat sześćdziesiątych, ale termin „architektura oprogramowania” nie był szeroko stosowany aż do lat dziewięćdziesiątych. Dziedzina informatyki borykała się z problemami związanymi ze złożonością od momentu jej powstania. Wcześniejsze problemy złożoności były rozwiązywane przez programistów poprzez dobór odpowiednich struktur danych , opracowanie algorytmów oraz zastosowanie koncepcji separacji obaw . Chociaż termin „architektura oprogramowania” jest stosunkowo nowy w branży, fundamentalne zasady tej dziedziny były sporadycznie stosowane przez pionierów inżynierii oprogramowania od połowy lat 80-tych. Wczesne próby uchwycenia i wyjaśnienia architektury oprogramowania systemu były nieprecyzyjne i zdezorganizowane, często charakteryzowane przez zestaw diagramów pudełkowo-liniowych .

Architektura oprogramowania jako koncepcja ma swoje początki w badaniach Edsgera Dijkstry w 1968 roku i Davida Parnasa we wczesnych latach 70-tych. Naukowcy ci podkreślili, że struktura systemu oprogramowania ma znaczenie, a jej prawidłowe ustawienie ma kluczowe znaczenie. W 1990 nastąpił wspólny wysiłek, aby określić i skodyfikować podstawowe aspekty tej dyscypliny, z prac badawczych, koncentrując się na stylach architektonicznych ( wzory ), opis architektury językach , architektura dokumentacji i metod formalnych .

Instytucje badawcze odegrały znaczącą rolę w rozwijaniu architektury oprogramowania jako dyscypliny. Mary Shaw i David Garlan z Carnegie Mellon napisali w 1996 roku książkę zatytułowaną Software Architecture: Perspectives on an Emerging Discipline, w której promowali koncepcje architektury oprogramowania, takie jak komponenty , złącza i style. University of California, Irvine Institute „s dla wysiłków badawczych w Oprogramowanie w architekturze oprogramowania badań jest skierowana głównie w stylach architektonicznych, opis architektury języków i dynamicznych architektur.

IEEE 1471 -2000, „Zalecana praktyka w zakresie opisu architektury systemów intensywnie korzystających z oprogramowania”, był pierwszym formalnym standardem w dziedzinie architektury oprogramowania. Została przyjęta w 2007 roku przez ISO jako ISO/IEC 42010:2007 . W listopadzie 2011 r. IEEE 1471-2000 został zastąpiony przez ISO/IEC/IEEE 42010:2011 , „Inżynieria systemów i oprogramowania – Opis architektury” (opublikowany wspólnie przez IEEE i ISO).

Podczas gdy w IEEE 1471 architektura oprogramowania dotyczyła architektury „systemów intensywnie korzystających z oprogramowania”, zdefiniowana jako „każdy system, w którym oprogramowanie ma istotny wpływ na projektowanie, budowę, wdrażanie i ewolucję systemu jako całości”, wydanie z 2011 r. idzie o krok dalej, włączając definicje systemu ISO/IEC 15288 i ISO/IEC 12207 , które obejmują nie tylko sprzęt i oprogramowanie, ale także „ludzi, procesy, procedury, obiekty, materiały i naturalnie występujące jednostki”. Odzwierciedla to związek między architekturą oprogramowania, architekturą korporacyjną i architekturą rozwiązania .

Działalność architektoniczna

Jest wiele czynności, które wykonuje architekt oprogramowania. Architekt oprogramowania zazwyczaj współpracuje z kierownikami projektów, omawia istotne architektonicznie wymagania z interesariuszami, projektuje architekturę oprogramowania, ocenia projekt, komunikuje się z projektantami i interesariuszami, dokumentuje projekt architektoniczny i nie tylko. W projektowaniu architektury oprogramowania istnieją cztery podstawowe działania. Te podstawowe działania związane z architekturą są wykonywane iteracyjnie i na różnych etapach początkowego cyklu życia oprogramowania, a także w trakcie ewolucji systemu.

Analiza architektoniczna to proces zrozumienia środowiska, w którym będzie działał proponowany system i określenia wymagań dla systemu. Dane wejściowe lub wymagania do czynności analitycznej mogą pochodzić od dowolnej liczby interesariuszy i obejmować takie elementy, jak:

  • co system zrobi po uruchomieniu (wymagania funkcjonalne)
  • jak dobrze system wykona wymagania niefunkcjonalne środowiska uruchomieniowego, takie jak niezawodność, operatywność, wydajność, bezpieczeństwo, kompatybilność określone w normie ISO/IEC 25010 :2011
  • czas rozwoju wymagań niefunkcjonalnych, takich jak pielęgnowalność i przenaszalność określonych w normie ISO 25010:2011,
  • wymagania biznesowe i konteksty środowiskowe systemu, które mogą się zmieniać w czasie, takie jak kwestie prawne, społeczne, finansowe, konkurencyjne i technologiczne

Wynikiem czynności analizy są te wymagania, które mają wymierny wpływ na architekturę systemu oprogramowania, zwane wymaganiami istotnymi architektonicznie.

Synteza lub projektowanie architektoniczne to proces tworzenia architektury. Biorąc pod uwagę określone w analizie wymagania architektoniczne, aktualny stan projektu oraz wyniki wszelkich działań ewaluacyjnych, projekt jest tworzony i udoskonalany.

Ocena architektury to proces określania, na ile aktualny projekt lub jego część spełnia wymagania wynikające z analizy. Ocena może mieć miejsce za każdym razem, gdy architekt rozważa decyzję projektową, może mieć miejsce po ukończeniu pewnej części projektu, może nastąpić po ukończeniu ostatecznego projektu lub może nastąpić po zbudowaniu systemu. Niektóre z dostępnych technik oceny architektury oprogramowania obejmują metodę analizy kompromisów architektury (ATAM) i TARA. Ramy do porównywania technik są omówione w ramach, takich jak SARA Report and Architecture Reviews: Practice and Experience .

Ewolucja architektury to proces utrzymywania i dostosowywania istniejącej architektury oprogramowania do zmian w wymaganiach i środowisku. Ponieważ architektura oprogramowania zapewnia podstawową strukturę systemu oprogramowania, jego ewolucja i konserwacja z konieczności wpłynęłyby na jego podstawową strukturę. W związku z tym ewolucja architektury dotyczy dodawania nowych funkcji, a także utrzymywania istniejącej funkcjonalności i zachowania systemu.

Architektura wymaga krytycznych działań wspierających. Te działania wspierające mają miejsce w całym procesie podstawowej architektury oprogramowania. Obejmują one zarządzanie wiedzą i komunikację, rozumowanie projektowe i podejmowanie decyzji oraz dokumentację.

Działania wspierające architekturę

Działania wspierające architekturę oprogramowania są realizowane podczas podstawowych działań związanych z architekturą oprogramowania. Te działania wspierające pomagają architektowi oprogramowania w przeprowadzeniu analizy, syntezy, oceny i ewolucji. Na przykład architekt musi gromadzić wiedzę, podejmować decyzje i dokumentować w fazie analizy.

  • Zarządzanie wiedzą i komunikacja to akt odkrywania i zarządzania wiedzą, która jest niezbędna do projektowania architektury oprogramowania. Architekt oprogramowania nie działa w odosobnieniu. Otrzymują dane wejściowe, wymagania funkcjonalne i niefunkcjonalne oraz konteksty projektowe od różnych interesariuszy; i dostarcza wyniki zainteresowanym stronom. Wiedza o architekturze oprogramowania jest często ukryta i utrzymywana w głowach interesariuszy. Działalność związana z zarządzaniem wiedzą o architekturze oprogramowania polega na znajdowaniu, komunikowaniu i utrzymywaniu wiedzy. Ponieważ problemy z projektowaniem architektury oprogramowania są skomplikowane i współzależne, luka w wiedzy w rozumowaniu projektowym może prowadzić do nieprawidłowego projektu architektury oprogramowania. Przykłady działań związanych z zarządzaniem wiedzą i komunikacją obejmują wyszukiwanie wzorców projektowych, prototypowanie, zadawanie pytań doświadczonym programistom i architektom, ocenianie projektów podobnych systemów, dzielenie się wiedzą z innymi projektantami i interesariuszami oraz dokumentowanie doświadczeń na stronie wiki.
  • Rozumowanie projektowe i podejmowanie decyzji to czynność polegająca na ocenie decyzji projektowych. To działanie ma fundamentalne znaczenie dla wszystkich trzech podstawowych działań związanych z architekturą oprogramowania. Obejmuje zbieranie i kojarzenie kontekstów decyzyjnych, formułowanie problemów związanych z decyzjami projektowymi, znajdowanie opcji rozwiązań i ocenę kompromisów przed podjęciem decyzji. Proces ten odbywa się na różnych poziomach szczegółowości decyzji podczas oceny istotnych wymagań dotyczących architektury i decyzji dotyczących architektury oprogramowania oraz analizy, syntezy i oceny architektury oprogramowania. Przykłady czynności rozumowania obejmują zrozumienie wpływu wymagania lub projektu na atrybuty jakościowe, kwestionowanie problemów, które projekt może powodować, ocenianie możliwych opcji rozwiązania i ocenianie kompromisów między rozwiązaniami.
  • Dokumentacja to czynność rejestrowania projektu generowanego podczas procesu architektury oprogramowania. Projekt systemu jest opisywany za pomocą kilku widoków, które często zawierają widok statyczny przedstawiający strukturę kodu systemu, widok dynamiczny przedstawiający działania systemu podczas wykonywania oraz widok wdrażania pokazujący, jak system jest umieszczany na sprzęcie w celu wykonania. Widok 4+1 Kruchtena sugeruje opis powszechnie używanych widoków do dokumentowania architektury oprogramowania; Dokumentowanie architektury oprogramowania: widoki i nie tylko zawiera opisy rodzajów notacji, które mogą być używane w opisie widoku. Przykładami czynności związanych z dokumentacją są pisanie specyfikacji, rejestrowanie modelu projektowego systemu, dokumentowanie przesłanek projektowych, opracowywanie punktu widzenia, dokumentowanie widoków.

Tematy architektury oprogramowania

Opis architektury oprogramowania

Główny artykuł: Opis architektury oprogramowania

Opis architektury oprogramowania obejmuje zasady i praktyki modelowania i reprezentowania architektur przy użyciu mechanizmów, takich jak języki opisu architektury, punkty widzenia architektury i struktury architektury.

Języki opisu architektury

Główny artykuł: Język 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), SBC-ADL (opracowany przez Narodowy Uniwersytet Sun Yat-Sen ) oraz ByADL (Uniwersytet L'Aquila, Włochy).

Punkty widzenia architektury

Główny artykuł: Zobacz model
Model widoku architektonicznego 4+1 .

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 widok odnosi się do zestawu problemów systemowych, zgodnie z konwencjami jego punktu widzenia , gdzie punkt widzenia jest specyfikacją opisującą notacje, modelowanie i techniki analizy, których należy użyć w widoku, który wyraża daną architekturę z perspektywy danego zestawu interesariuszy i ich obaw ( ISO/IEC/IEEE 42010 ). Punkt widzenia określa nie tylko kwestie, które zostały sformułowane (tj. należy się zająć), ale także prezentację, rodzaje zastosowanych modeli, stosowane konwencje i wszelkie zasady spójności (korespondencji), aby zachować spójność poglądu z innymi poglądami.

Ramy architektury

Główny artykuł: Framework architektury

Struktura architektury obejmuje „konwencje, zasady i praktyki dotyczące opisu architektur ustanowionych w określonej dziedzinie aplikacji i/lub społeczności interesariuszy” ( ISO/IEC/IEEE 42010 ). Framework jest zwykle implementowany w kategoriach jednego lub więcej punktów widzenia lub ADL.

Style i wzory architektoniczne

Główny artykuł: wzór architektoniczny

Wzorzec architektoniczny to ogólne, wielokrotnego użytku rozwiązanie często występującego problemu w architekturze oprogramowania w danym kontekście. Wzorce architektoniczne są często dokumentowane jako wzorce projektowe oprogramowania .

Podążając za tradycyjną architekturą budynku, „architektoniczny styl oprogramowania” jest specyficzną metodą budowy, charakteryzującą się cechami, które sprawiają, że jest godna uwagi” ( styl architektoniczny ).

Styl architektoniczny definiuje: rodzinę systemów pod względem wzorca organizacji strukturalnej; słownik komponentów i złączy, z ograniczeniami dotyczącymi ich łączenia.

Style architektoniczne to wielokrotnego użytku „pakiety” decyzji projektowych i ograniczeń, które są stosowane w architekturze w celu wywołania wybranych pożądanych właściwości.

Istnieje wiele uznanych wzorców i stylów architektonicznych, a wśród nich:

Jedni traktują wzorce architektoniczne i style architektoniczne jako to samo, inni traktują style jako specjalizacje wzorców. Łączy je to, że zarówno wzory, jak i style są idiomami używanymi przez architektów, „zapewniają wspólny język” lub „słownictwo” do opisywania klas systemów.

Architektura oprogramowania i zwinny rozwój

Główny artykuł: Zwinny rozwój

Istnieją również obawy, że architektura oprogramowania prowadzi do zbytniego projektowania z góry , szczególnie wśród zwolenników zwinnego tworzenia oprogramowania . Opracowano szereg metod w celu zrównoważenia kompromisów między początkowym projektem a zwinnością, w tym zwinną metodę DSDM, która nakazuje fazę „Fundamenty”, podczas której kładzie się „tylko wystarczającą ilość” fundamentów architektonicznych. IEEE Software poświęciło specjalne wydanie interakcji między zwinnością a architekturą.

Erozja architektury oprogramowania

Erozja architektury oprogramowania (lub „rozpad”) odnosi się do luki zaobserwowanej między planowaną i rzeczywistą architekturą systemu oprogramowania, jaka została zrealizowana podczas jego implementacji. Erozja architektury oprogramowania występuje, gdy decyzje wdrożeniowe albo nie w pełni osiągają architekturę zgodnie z planem, albo w inny sposób naruszają ograniczenia lub zasady tej architektury.

Jako przykład rozważmy system ściśle warstwowy , w którym każda warstwa może korzystać tylko z usług świadczonych przez warstwę bezpośrednio pod nią. Każdy składnik kodu źródłowego, który nie przestrzega tego ograniczenia, stanowi naruszenie architektury. Jeśli nie zostaną naprawione, takie naruszenia mogą przekształcić architekturę w monolityczny blok, co ma niekorzystny wpływ na zrozumiałość, łatwość konserwacji i ewolucję.

Zaproponowano różne podejścia do przeciwdziałania erozji. „Te podejścia, które obejmują narzędzia, techniki i procesy, są przede wszystkim podzielone na trzy ogólne kategorie, które mają na celu zminimalizowanie, zapobieganie i naprawę erozji architektury. W ramach tych szerokich kategorii każde podejście jest dalej podzielone, odzwierciedlając strategie wysokiego poziomu przyjęte do zwalczają erozję. Są to: zgodność architektury zorientowanej na procesy, zarządzanie ewolucją architektury, egzekwowanie projektu architektury, powiązanie architektury z implementacją, samoadaptacja i techniki przywracania architektury obejmujące odzyskiwanie, odkrywanie i uzgadnianie”.

Istnieją dwie główne techniki wykrywania naruszeń architektury: modele refleksyjne i języki specyficzne dla domeny. Techniki modelu refleksyjnego (RM) porównują model wysokiego poziomu dostarczony przez architektów systemu z implementacją kodu źródłowego. Istnieją również języki specyficzne dla domeny, które koncentrują się na określaniu i sprawdzaniu ograniczeń architektonicznych.

Odzyskiwanie architektury oprogramowania

Główny artykuł: Odzyskiwanie architektury oprogramowania

Odzyskiwanie (lub rekonstrukcja lub inżynieria wsteczna ) architektury oprogramowania obejmuje metody, techniki i procesy umożliwiające odkrycie architektury systemu oprogramowania na podstawie dostępnych informacji, w tym jego implementacji i dokumentacji. Odzyskiwanie architektury jest często konieczne do podejmowania świadomych decyzji w obliczu przestarzałej lub nieaktualnej dokumentacji i erozji architektury : decyzje dotyczące wdrożenia i konserwacji odbiegają od przewidywanej architektury. Istnieją praktyki odzyskiwania architektury oprogramowania jako statycznej analizy programu . Jest to część tematów objętych praktyką inteligencji oprogramowania .

Pola pokrewne

Projekt

Główny artykuł: Projektowanie oprogramowania

Architektura to projekt, ale nie każdy projekt jest architektoniczny. W praktyce to architekt wyznacza granicę między architekturą oprogramowania (projekt architektoniczny) a projektem wykonawczym (projekt niearchitektoniczny). Nie ma reguł ani wytycznych pasujących do wszystkich przypadków, chociaż podejmowano próby sformalizowania tego rozróżnienia. Zgodnie z Hipotezą Intencji/Lokalizacji rozróżnienie między projektem architektonicznym a szczegółowym jest definiowane przez Kryterium Lokalności , zgodnie z którym stwierdzenie dotyczące projektu oprogramowania jest nielokalne (architektoniczne) wtedy i tylko wtedy, gdy program, który je spełnia, może zostać rozszerzony na program, który tego nie robi. Na przykład styl klient-serwer jest architektoniczny (strategiczny), ponieważ program zbudowany na tej zasadzie można rozszerzyć do programu, który nie jest klientem-serwerem — na przykład przez dodanie węzłów peer-to-peer .

Inżynieria wymagań

Główny artykuł: Inżynieria wymagań

Inżynierię wymagań i architekturę oprogramowania można postrzegać jako podejścia komplementarne: podczas gdy architektura oprogramowania jest ukierunkowana na „ przestrzeń rozwiązań ” lub „jak”, inżynieria wymagań zajmuje się „ przestrzeń problemową ” lub „co”. Inżynieria wymagań pociąga za sobą aktywizacja , negocjacje , specyfikację , walidację , dokumentacji i zarządzania z wymaganiami . Zarówno inżynieria wymagań, jak i architektura oprogramowania obracają się wokół obaw, potrzeb i życzeń interesariuszy .

Istnieje znaczne nakładanie się inżynierii wymagań i architektury oprogramowania, czego dowodem jest na przykład badanie pięciu metod architektury oprogramowania przemysłowego, z którego wynika, że „dane wejściowe (cele, ograniczenia itp.) są zwykle źle zdefiniowane i dopiero zostają odkryte lub lepsze rozumieć, że architektura zaczyna się wyłaniać” i że chociaż „większość problemów architektonicznych wyraża się jako wymagania dotyczące systemu, mogą one również obejmować obowiązkowe decyzje projektowe” . Krótko mówiąc, wymagane zachowanie wpływa na architekturę rozwiązania, co z kolei może wprowadzać nowe wymagania. Podejścia takie jak model Twin Peaks mają na celu wykorzystanie synergicznego związku między wymaganiami a architekturą.

Inne rodzaje „architektury”

Główne artykuły: Computer Architecture , architektura Systemy i Enterprise Architecture
Architektura komputerowa
Architektura komputera jest ukierunkowana na wewnętrzną strukturę systemu komputerowego pod względem współpracujących elementów sprzętowych, takich jak procesor — lub procesor — magistrala i pamięć .
Architektura systemów
Termin architektura systemów był pierwotnie stosowany do architektury systemów, która składa się zarówno ze sprzętu, jak i oprogramowania . Głównym problemem, którym zajmuje się architektura systemów, jest zatem integracja oprogramowania i sprzętu w kompletnym, poprawnie działającym urządzeniu. W innym powszechnym – znacznie szerszym – znaczeniu termin ten odnosi się do architektury dowolnego złożonego systemu, który może mieć charakter techniczny, socjotechniczny lub społeczny.
Architektura korporacyjna
Celem architektury korporacyjnej jest „przełożenie wizji i strategii biznesowej na efektywne przedsiębiorstwo”. Struktury architektury korporacyjnej , takie jak TOGAF i Zachman Framework , zwykle rozróżniają różne warstwy architektury korporacyjnej. Chociaż różni terminologii od ramy do ramy, wiele zawiera co najmniej różnicy między służbowej warstwy , jest zastosowanie (lub informacja ) warstwy i technologii warstwy . Architektura korporacyjna zajmuje się między innymi wyrównaniem między tymi warstwami, zwykle w podejściu odgórnym.

Zobacz też

Bibliografia

Dalsza lektura

Zewnętrzne linki