Mjukvaruarkitektur
Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från
versionen som granskades den 13 maj 2019; kontroller kräver
8 redigeringar .
Mjukvaruarkitektur är en uppsättning av de viktigaste besluten om hur ett mjukvarusystem ska organiseras . Arkitektur inkluderar:
- valet av strukturella element och deras gränssnitt, med hjälp av vilka systemet är sammansatt, liksom deras beteende inom ramen för samarbetet mellan strukturella element;
- koppla samman utvalda delar av struktur och beteende till allt större system;
- en arkitektonisk stil som vägleder hela organisationen – alla element, deras gränssnitt, deras samarbete och deras koppling [1] [2] .
Att dokumentera mjukvaruarkitekturen (SW) förenklar kommunikationsprocessen mellan utvecklare, låter dig registrera de designbeslut som fattats och ge information om dem till operativ personal i systemet [
3] , återanvända komponenter och projektmallar i andra.
Det finns ingen allmänt accepterad definition av "mjukvaruarkitektur". Så, webbplatsen för Institute of Software Engineering ger mer än 150 definitioner av detta koncept [4] [5] .
Översikt
Området datavetenskap har sedan starten stått inför utmaningar relaterade till mjukvarusystemens komplexitet. Tidigare löstes komplexitetsproblem av utvecklare genom att välja rätt datastrukturer, utveckla algoritmer och tillämpa konceptet maktdelning. Även om termen "mjukvaruarkitektur" är relativt ny för mjukvaruutvecklingsindustrin, har de grundläggande principerna inom området tillämpats urskillningslöst av mjukvaruutvecklingspionjärer sedan mitten av 1980-talet. De första försöken att förstå och förklara mjukvaruarkitekturen i ett system var fulla av felaktigheter och led av bristande organisation, ofta bara ett diagram över block sammankopplade med linjer. På 1990-talet gjordes ett försök att definiera och systematisera huvudaspekterna av denna disciplin. En första uppsättning designmönster , designstilar, bästa praxis, beskrivningsspråk och formell logik utvecklades under denna tid [6] .
En grundläggande idé för disciplinen mjukvaruarkitektur är idén om att minska systemets komplexitet genom abstraktion och maktdelning. Hittills finns det fortfarande ingen överenskommelse om en tydlig definition av begreppet "mjukvaruarkitektur".
Som en för närvarande utvecklande disciplin utan tydliga regler om det "rätta" sättet att bygga ett system, är design av mjukvaruarkitektur fortfarande en blandning av vetenskap och konst. "Konst"-aspekten är att alla kommersiella system innebär en applikation eller ett uppdrag. Ur perspektivet för en användare av programvaruarkitektur ger programvaruarkitektur vägledning för att flytta och lösa problem relaterade till varje sådan användares specialitet, till exempel en intressent, programvaruutvecklare, mjukvarusupportteam, programvaruunderhållare, programvarudistributionsspecialist, testare, och även slutanvändare. I denna mening sammanför programvaruarkitektur faktiskt olika perspektiv på ett system. Det faktum att dessa flera olika synpunkter kan kombineras i en mjukvaruarkitektur är ett argument för nödvändigheten och ändamålsenligheten av att skapa en mjukvaruarkitektur redan innan mjukvaruutvecklingsstadiet [7] [8] [9] .
Historik
Mjukvaruarkitektur som koncept började med Edsger Dijkstras forskningsarbete 1968 och David Parnassus i början av 1970-talet. Dessa forskare betonade att strukturen i ett mjukvarusystem är viktig och att det är avgörande att bygga rätt struktur. Studiet av detta område har vuxit i popularitet sedan början av 1990-talet med forskningsarbete om arkitektoniska stilar (mönster), arkitekturbeskrivningsspråk, arkitekturdokumentation och formella metoder.
Forskningsinstitutioner spelar en viktig roll i utvecklingen av mjukvaruarkitektur som disciplin. Mary Shaw och David Garlan från Carnegie Mellon University skrev en bok med titeln "Software Architecture: Perspectives on a New Discipline in 1996" där de presenterar programvaruarkitekturkoncept som komponenter, kontakter, stilar och så vidare. Vid University of California forskar Irvine Institute for Software Research främst om arkitektoniska stilar, arkitekturbeskrivningsspråk och dynamiska arkitekturer.
Den första standarden för programvaruarkitektur är IEEE 1471: ANSI/IEEE 1471-2000: Guidelines for Describing Predominantly Software Systems. Det antogs 2007 under namnet ISO ISO/IEC 42010:2007.
Arkitektur beskrivning språk
Arkitekturbeskrivningsspråk (ADLS) används för att beskriva programvarans arkitektur. Flera olika ADLS har utvecklats av olika organisationer, inklusive AADL (SAE-standard), Wright (utvecklad vid Carnegie Mellon University), Acme (utvecklad vid Carnegie Mellon University), xADL (utvecklad vid UCI), Darwin (utvecklad vid Imperial College London) , DAOP-ADL (utvecklat vid universitetet i Malaga) och ByADL (universitetet i L'Aquila, Italien). Gemensamma element för alla dessa språk är begreppen komponent, anslutning och konfiguration. Dessutom, förutom specialiserade språk, används ofta det enhetliga modelleringsspråket UML för att beskriva arkitekturen .
Visningar
En mjukvaruarkitektur innehåller vanligtvis flera vyer som liknar de olika typerna av ritningar inom byggnadskonstruktion. I en ontologi definierad av ANSI/IEEE 1471-2000 är åsikter synpunktsinstanser, där det finns en synvinkel för att beskriva en arkitektur från en given uppsättning intressenters synvinkel.
Den arkitektoniska utsikten består av 2 komponenter:
- Element
- Relationer mellan element
Arkitektoniska vyer kan delas in i tre huvudtyper [10] :
- Modulära vyer (eng. module views ) - visar systemet som en struktur av olika mjukvarublock.
- Komponenter-och-kopplingar (eng. komponent-och-kopplingsvyer ) - visar systemet som en struktur av parallellt löpande element (komponenter) och hur de samverkar (kopplingar).
- Allokering (eng. allocation views ) - visar placeringen av systemelement i externa miljöer.
Exempel på modulära vyer:
- Decomposition (eng. decomposition view ) - består av moduler i sammanhanget "är en undermodul"
- Användning (eng. uses view ) - består av moduler i sammanhanget "använder"-relationen (dvs en modul använder tjänsterna från en annan modul)
- Nivåvy (eng. layered view ) - visar en struktur där moduler relaterade till funktionalitet kombineras i grupper (nivåer)
- Klass / generaliseringsvy (eng. klass / generaliseringsvy ) - består av klasser relaterade genom relationen "ärvt från" och "är en instans"
Exempel på komponent-och-kontakttyper:
- Processvy (eng. process view ) - består av processer kopplade till kommunikation, synkronisering och/eller exkluderingsoperationer
- Parallellvy (eng. concurrency view ) - består av komponenter och kopplingar, där kopplingarna är "logiska flöden"
- Datautbytestyp (eng. shared-data (repository) view ) - består av komponenter och kopplingar som skapar, sparar och tar emot beständig data
- Klient-servervy (eng. client-server view ) - består av interagerande klienter och servrar, samt kopplingar mellan dem (till exempel protokoll och vanliga meddelanden)
Exempel på boendetyper:
- Deployment (eng. deployment view ) - består av programvaruelement, deras placering på fysiska medier och kommunikationselement
- Implementering (eng. implementation view ) - består av programelement och deras motsvarighet till filstrukturer i olika miljöer (utveckling, integration, etc.)
- Arbetsuppgift (eng. arbetsuppgiftsvy ) - består av moduler och en beskrivning av vem som ansvarar för att implementera var och en av dem
Även om flera språk har utvecklats för att beskriva mjukvaruarkitektur, finns det för närvarande ingen överenskommelse om vilken uppsättning åsikter som ska användas som referens. UML-språket skapades som en standard "för modellering av mjukvarusystem (och inte bara)".
Arkitektoniska mönster
Olika arkitektoniska mönster tillämpas för att tillfredsställa det designade systemet med olika kvalitetsattribut. Varje mall har sina egna mål och nackdelar.
Exempel på arkitektoniska mönster:
- Lagermönster. Systemet är uppdelat i nivåer som visas ovanför varandra i diagrammet. Varje nivå kan bara kalla fram nivå 1 under den. Således kan utvecklingen av varje nivå utföras relativt oberoende, vilket ökar systemets modifierbarhet. Nackdelarna med detta tillvägagångssätt är komplikationen av systemet och minskningen av prestanda.
- Mäklare mönster. När det finns ett stort antal moduler i systemet blir deras direkta interaktion med varandra för komplicerad. För att lösa problemet introduceras en mellanhand (till exempel en databuss), genom vilken modulerna kommunicerar med varandra. Således ökas interoperabiliteten för systemmodulerna. Alla nackdelar härrör från närvaron av en mellanhand: det minskar prestandan, dess otillgänglighet kan göra hela systemet otillgängligt, det kan bli ett föremål för attack och en systemflaskhals.
- Mönster "Model-View-Controller" (Model-View-Controller-mönster). Därför att Eftersom kraven för gränssnittet ändras oftast, finns det ett behov av att ändra det ofta, samtidigt som den korrekta interaktionen med data bibehålls (läsa, spara). För att göra detta, i Model-View-Controller-mönstret (MVC) separeras gränssnittet från data. Detta gör att du kan ändra gränssnitt, samt skapa olika versioner av dem. I MVC är systemet uppdelat i:
- Modellen som lagrar data
- En vy som visar en bit data och interagerar med användaren
- En kontroller som förmedlar mellan åsikterna och modellen
MVC-konceptet har dock också sina nackdelar. I synnerhet, på grund av komplikationen av interaktion, minskar systemets hastighet.
- Klient-server-mönster (klient-server-mönster). Om det finns ett begränsat antal resurser som kräver begränsad åtkomst av ett stort antal konsumenter, är det bekvämt att implementera en klient-server-arkitektur. Detta tillvägagångssätt ökar systemets skalbarhet och tillgänglighet. Men samtidigt kan servern bli en flaskhals i systemet, om den inte är tillgänglig blir hela systemet otillgängligt.
Grundläggande ramverk för programvaruarkitektur
Det finns följande ramverk ( engelsk software architecture frameworks ) relaterade till området mjukvaruarkitektur:
- 4+1
- RM-ODP (referensmodell för öppen distribuerad bearbetning)
- Service Oriented Modeling Framework (SOMF)
Arkitekturexempel som Zachman Framework, DoDAF och TOGAF faller under domänen för företagsarkitekturer.
Se även
Anteckningar
- ↑ Kruchten, Philippe . The Rational Unified Process-An Introduction, Addison-Wesley, 1998
- ↑ Rumbaugh, J. , Jacobsen, I. och Booch, G. The Unified Modeling Language Reference Manual. Reading, Mass.: Addison-Wesley, 1999
- ↑ Dokumentera mjukvaruarkitekturer: Views and Beyond, 2010 , P.1.1. Översikt.
- ↑ Dokumentera programvaruarkitekturer: Views and Beyond, 2010 , P.1.2. Arkitektur och kvalitetsegenskaper.
- ↑ Software Architecture:Ordlista Arkiverad 5 januari 2013 på Wayback Machine , Software Engineering Institute
- ↑ Vad är din definition av programvaruarkitektur . resources.sei.cmu.edu. Hämtad 23 oktober 2019. Arkiverad från originalet 28 februari 2020.
- ↑ ISO/IEC/IEEE 42010: Definierar "arkitektur" . www.iso-architecture.org. Hämtad 23 oktober 2019. Arkiverad från originalet 7 april 2017. (obestämd)
- ↑ M. Fowler. Design - Vem behöver en arkitekt? // IEEE-programvara. — 2003-9. - T. 20 , nej. 5 . — S. 11–13 . - doi : 10.1109/MS.2003.1231144 . Arkiverad från originalet den 23 oktober 2019.
- ↑ En introduktion till mjukvaruarkitektur . Hämtad 23 oktober 2019. Arkiverad från originalet 6 maj 2021. (obestämd)
- ↑ Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering). - 3 upplagan (5 oktober 2012). - 2012. - 640 sid. — ISBN 978-0321815736 .
Litteratur
- Paul Clements; Felix Bachmann; Len Bas; David Garlan; James Ivers; Reed Little; Paul Merson; Robert North; Judith Stafford. Dokumentera programvaruarkitekturer: vyer och bortom. - Andra upplagan. - Addison-Wesley Professional, 2010. - ISBN 978-0-13-248861-7 .
- Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, tredje upplagan . Addison Wesley, 2012, ISBN 978-0321815736 (Denna bok, nu i tredje upplagan, täcker vältaligt de grundläggande begreppen inom disciplinen. Temat är centrerat kring att uppnå kvalitetsattribut för ett system.)
Länkar