Softwarová architektura

Architektura softwaru je soubor  nejdůležitějších rozhodnutí o organizaci softwarového systému. Architektura zahrnuje:

• volba konstrukčních prvků a jejich rozhraní, pomocí kterých je systém složen, i jejich chování v rámci spolupráce konstrukčních prvků;
• spojování vybraných prvků struktury a chování do stále větších systémů;
• architektonický styl, který řídí celou organizaci – všechny prvky, jejich rozhraní, spolupráci a jejich propojení [1] [2] .

Dokumentace softwarové architektury (SW) zjednodušuje proces komunikace mezi vývojáři, umožňuje zaznamenávat provedená návrhová rozhodnutí a poskytovat o nich informace provoznímu personálu systému [3] , opakovaně používat komponenty a šablony projektů v jiných.

Neexistuje žádná obecně přijímaná definice „softwarové architektury“. Stránky Ústavu softwarového inženýrství tedy poskytují více než 150 definic tohoto pojmu [4] [5] .

Přehled

Oblast informatiky se od svého vzniku potýká s problémy souvisejícími se složitostí softwarových systémů. Dříve problémy se složitostí řešili vývojáři výběrem správných datových struktur, vývojem algoritmů a aplikací konceptu oddělení moci. Ačkoli termín „softwarová architektura“ je v odvětví vývoje softwaru relativně nový, základní principy tohoto oboru byly průkopníky vývoje softwaru aplikovány bez rozdílu od poloviny 80. let. První pokusy pochopit a vysvětlit softwarovou architekturu systému byly plné nepřesností a trpěly nedostatkem organizace, často jen schématem bloků propojených čarami. V 90. letech došlo ke snaze definovat a systematizovat hlavní aspekty této disciplíny. Během této doby byla vyvinuta počáteční sada návrhových vzorů , designových stylů, osvědčených postupů, popisných jazyků a formální logiky [6] .

Základní myšlenkou disciplíny softwarové architektury je myšlenka snížení složitosti systému prostřednictvím abstrakce a oddělení pravomocí. Dodnes stále neexistuje shoda na jasné definici pojmu „softwarová architektura“.

Jako v současnosti se vyvíjející disciplína bez jasných pravidel o „správném“ způsobu budování systému je návrh softwarové architektury stále směsí vědy a umění. „Uměleckým“ aspektem je, že jakýkoli komerční systém zahrnuje aplikaci nebo poslání. Z pohledu uživatele softwarové architektury poskytuje softwarová architektura směr pro pohyb a řešení problémů souvisejících se specializací každého takového uživatele, například zainteresovaná strana, vývojář softwaru, tým softwarové podpory, správce softwaru, specialista na nasazení softwaru, tester, a také koncoví uživatelé. V tomto smyslu softwarová architektura ve skutečnosti spojuje různé pohledy na systém. Skutečnost, že těchto několik různých úhlů pohledu lze kombinovat v softwarové architektuře, je argumentem ve prospěch nutnosti a účelnosti vytvoření softwarové architektury ještě před fází vývoje softwaru [7] [8] [9] .

Historie

Softwarová architektura jako koncept začala výzkumnou prací Edsgera Dijkstra v roce 1968 a Davida Parnassuse na počátku 70. let. Tito učenci zdůraznili, že struktura softwarového systému je důležitá a že vybudování správné struktury je rozhodující. Studium tohoto oboru rostlo na popularitě od počátku 90. let 20. století výzkumem architektonických stylů (vzorů), jazyků popisu architektury, dokumentace architektury a formálních metod.

Výzkumné instituce hrají důležitou roli ve vývoji softwarové architektury jako disciplíny. Mary Shaw a David Garlan z Carnegie Mellon University napsali v roce 1996 knihu s názvem „Software Architecture: Perspectives on a New Discipline“, ve které předložili koncepty softwarové architektury, jako jsou komponenty, konektory, styly a tak dále. Irvine Institute for Software Research na University of California zkoumá především architektonické styly, jazyky pro popis architektury a dynamické architektury.

Prvním standardem softwarové architektury je IEEE 1471: ANSI/IEEE 1471-2000: Pokyny pro popis převážně softwarových systémů. Byla přijata v roce 2007 pod názvem ISO ISO/IEC 42010:2007.

Jazyky popisu architektury

Jazyky pro popis architektury (ADLS) se používají k popisu architektury softwaru. Několik různých ADLS bylo vyvinuto různými organizacemi, včetně AADL (standard SAE), Wright (vyvinutý na Carnegie Mellon University), Acme (vyvinutý na Carnegie Mellon University), xADL (vyvinutý na UCI), Darwin (vyvinutý na Imperial College London). , DAOP-ADL (vyvinutý na univerzitě v Malaze) a ByADL (Univerzita v L'Aquile, Itálie). Společnými prvky pro všechny tyto jazyky jsou koncepty komponent, konektorů a konfigurace. Kromě specializovaných jazyků se k popisu architektury často používá také jednotný modelovací jazyk UML .

Zobrazení

Softwarová architektura obvykle obsahuje několik pohledů, které jsou podobné různým typům výkresů ve stavebnictví. V ontologii definované ANSI/IEEE 1471-2000 jsou pohledy instancemi pohledu, kde existuje hledisko, které popisuje architekturu z pohledu daného souboru zúčastněných stran.

Architektonický pohled se skládá ze 2 částí:

• Prvky
• Vztahy mezi prvky

Architektonické pohledy lze rozdělit do 3 hlavních typů [10] :

1. Modulární pohledy (angl. module views ) - zobrazují systém jako strukturu různých softwarových bloků.
2. Komponenty-a-konektory (angl. component-and-connector views ) - ukazují systém jako strukturu paralelně běžících prvků (komponent) a jejich vzájemné působení (konektory).
3. Alokace (angl. alokační pohledy ) - zobrazuje umístění prvků systému v externích prostředích.

Příklady modulárních pohledů:

• Dekompozice (angl. decomposition view ) - skládá se z modulů v kontextu vztahu "je submodul"
• Use (angl. used view ) - skládá se z modulů v kontextu vztahu „uses“ (tj. jeden modul využívá služby jiného modulu)
• Úrovňové zobrazení (angl. layered view ) - zobrazuje strukturu, ve které jsou moduly související funkcí sloučeny do skupin (úrovní)
• Třída / generalizační pohled (angl. c lass / generalization view ) - skládá se z tříd souvisejících prostřednictvím vztahu "zděděno od" a "je instancí"

Příklady typů komponent a konektorů:

• Procesní pohled (angl. process view ) - sestává z procesů spojených komunikačními, synchronizačními a/nebo vylučovacími operacemi
• Paralelní pohled (angl. concurrency view ) - skládá se z komponent a konektorů, kde konektory jsou "logické toky"
• Typ výměny dat (angl. shared-data (repository) view ) – skládá se z komponent a konektorů, které vytvářejí, ukládají a přijímají trvalá data
• Pohled klient-server (angl. client-server view ) – sestává z interagujících klientů a serverů a také z konektorů mezi nimi (například protokoly a běžné zprávy)

Příklady typů ubytování:

• Deployment (angl. deployment view ) - skládá se ze softwarových prvků, jejich umístění na fyzická média a komunikačních prvků
• Implementace (angl. implementation view ) - skládá se z programových prvků a jejich korespondence se strukturou souborů v různých prostředích (vývoj, integrace atd.)
• Pracovní zadání (angl. work order view ) - skládá se z modulů a popisu toho, kdo je odpovědný za realizaci každého z nich

Přestože bylo vyvinuto několik jazyků k popisu softwarové architektury, v současné době neexistuje žádná shoda na tom, která sada pohledů by měla být přijata jako referenční. Jazyk UML vznikl jako standard „pro modelování softwarových systémů (nejen)“.

Architektonické vzory

Různé architektonické vzory jsou použity k uspokojení navrženého systému s různými atributy kvality. Každá šablona má své vlastní cíle a nevýhody.

Příklady architektonických vzorů:

• Vrstvený vzor. Systém je rozdělen do úrovní, které jsou v diagramu znázorněny nad sebou. Každá úroveň může vyvolat pouze úroveň 1 pod ní. Vývoj každé úrovně tak může být prováděn relativně nezávisle, což zvyšuje modifikovatelnost systému. Nevýhodou tohoto přístupu je složitost systému a pokles výkonu.
• Vzor makléře. Když je v systému velké množství modulů, jejich přímá vzájemná interakce se příliš komplikuje. Pro řešení problému se zavádí prostředník (například datová sběrnice), přes který mezi sebou moduly komunikují. Tím se zvýší interoperabilita modulů systému. Všechny nevýhody plynou z přítomnosti prostředníka: snižuje výkon, jeho nedostupnost může znepřístupnit celý systém, může se stát objektem útoku a úzkým hrdlem systému.
• Vzor "Model-View-Controller" (vzor Model-View-Controller). Protože Jelikož se nejčastěji mění požadavky na rozhraní, je potřeba jej často upravovat při zachování správné interakce s daty (čtení, ukládání). K tomu je ve vzoru Model-View-Controller (MVC) rozhraní odděleno od dat. To vám umožňuje měnit rozhraní a také vytvářet jejich různé verze. V MVC je systém rozdělen na:
  • Model, který ukládá data
  • Pohled, který zobrazuje část dat a komunikuje s uživatelem
  • Ovladač, který zprostředkovává mezi pohledy a modelem

Koncept MVC má však i své nevýhody. Zejména kvůli komplikaci interakce klesá rychlost systému.

• Vzor klient-server (vzor klient-server). Pokud existuje omezený počet zdrojů, které vyžadují omezený přístup velkého počtu spotřebitelů, je vhodné implementovat architekturu klient-server. Tento přístup zvyšuje škálovatelnost a dostupnost systému. Zároveň se ale server může stát úzkým hrdlem systému, pokud je nedostupný, stane se nedostupným celý systém.

Základní frameworky pro softwarovou architekturu

K oblasti softwarové architektury se vztahují následující rámce ( anglicky  softwarové architekturní rámce ):

• 4+1
• RM-ODP (referenční model otevřeného distribuovaného zpracování)
• Service Oriented Modeling Framework (SOMF)

Příklady architektury, jako je Zachman Framework, DoDAF a TOGAF, spadají do domény podnikových architektur.

Viz také

• Architektura systému

Poznámky

1. ↑ Kruchten, Philippe . The Rational Unified Process-An Introduction, Addison-Wesley, 1998
2. ↑ Rumbaugh, J. , Jacobsen, I. a Booch, G. Referenční příručka jednotného modelovacího jazyka. Reading, Mass.: Addison-Wesley, 1999
3. ↑ Documenting Software Architectures: Views and Beyond, 2010 , P.1.1. Přehled.
4. ↑ Documenting Software Architectures: Views and Beyond, 2010 , P.1.2. Architektura a atributy kvality.
5. ↑ Software Architecture:Glossary Archived 5. ledna 2013 na Wayback Machine , Software Engineering Institute
6. ↑ Jaká je vaše definice softwarové  architektury ? resources.sei.cmu.edu. Získáno 23. října 2019. Archivováno z originálu dne 28. února 2020.
7. ↑ ISO/IEC/IEEE 42010: Definice „architektury“ . www.iso-architecture.org. Získáno 23. října 2019. Archivováno z originálu dne 7. dubna 2017. (neurčitý)
8. ↑ M. Fowler. Design – Kdo potřebuje architekta?  // Software IEEE. — 2003-9. - T. 20 , č. 5 . — S. 11–13 . - doi : 10.1109/MS.2003.1231144 . Archivováno z originálu 23. října 2019.
9. ↑ Úvod do softwarové architektury . Získáno 23. října 2019. Archivováno z originálu 6. května 2021. (neurčitý)
10. ↑ Len Bass, Paul Clements, Rick Kazman. Softwarová architektura v praxi (3. vydání) (SEI Series in Software Engineering). - 3. vydání (5. října 2012). - 2012. - 640 s. — ISBN 978-0321815736 .

Literatura

• Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paul Merson; Robert North; Judith Staffordová. Dokumentace softwarových architektur: Pohledy a dále. - Druhé vydání. - Addison-Wesley Professional, 2010. - ISBN 978-0-13-248861-7 .
• Len Bass, Paul Clements, Rick Kazman:  Softwarová architektura v praxi, třetí vydání . Addison Wesley, 2012,  ISBN 978-0321815736  (Tato kniha, nyní ve třetím vydání, výmluvně pokrývá základní pojmy této disciplíny. Téma se soustředí na dosažení kvalitativních atributů systému.)

Odkazy

• Retrospektiva softwarových architektur
• Softwarová architektura: Glosář , Software Engineering Institute  
• Architektura: Publikace , Institut softwarového inženýrství