Software arkitektur
Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den
version , der blev gennemgået den 13. maj 2019; checks kræver
8 redigeringer .
Softwarearkitektur er et sæt af de vigtigste beslutninger om organiseringen af et softwaresystem . Arkitektur inkluderer:
- valget af strukturelle elementer og deres grænseflader, ved hjælp af hvilke systemet er sammensat, såvel som deres adfærd inden for rammerne af samarbejdet mellem strukturelle elementer;
- at forbinde udvalgte elementer af struktur og adfærd i stadig større systemer;
- en arkitektonisk stil, der guider hele organisationen – alle elementer, deres grænseflader, deres samarbejde og deres sammenhæng [1] [2] .
Dokumentation af softwarearkitekturen ( SW) forenkler kommunikationsprocessen mellem udviklere, giver dig mulighed for at registrere de truffet designbeslutninger og give information om dem til systemets driftspersonale [3] , genbruge komponenter og projektskabeloner i andre .
Der er ingen generelt accepteret definition af "softwarearkitektur". Så webstedet for Institute of Software Engineering giver mere end 150 definitioner af dette koncept [4] [5] .
Oversigt
Datalogiområdet har siden starten stået over for udfordringer relateret til kompleksiteten af softwaresystemer. Tidligere blev kompleksitetsproblemer løst af udviklere ved at vælge de rigtige datastrukturer, udvikle algoritmer og anvende begrebet magtadskillelse. Selvom udtrykket "softwarearkitektur" er relativt nyt for softwareudviklingsindustrien, er feltets grundlæggende principper blevet anvendt vilkårligt af softwareudviklingspionerer siden midten af 1980'erne. De første forsøg på at forstå og forklare softwarearkitekturen i et system var fulde af unøjagtigheder og led af mangel på organisation, ofte blot et diagram af blokke forbundet med linjer. I 1990'erne var der et forsøg på at definere og systematisere hovedaspekterne af denne disciplin. Et indledende sæt af designmønstre , designstile, bedste praksis, beskrivelsessprog og formel logik blev udviklet i løbet af denne tid [6] .
En grundlæggende idé i disciplinen softwarearkitektur er ideen om at reducere systemets kompleksitet gennem abstraktion og adskillelse af beføjelser. Til dato er der stadig ingen enighed om en klar definition af begrebet "softwarearkitektur".
Som en i øjeblikket udviklende disciplin uden klare regler om den "rigtige" måde at bygge et system på, er softwarearkitekturdesign stadig en blanding af videnskab og kunst. "Kunst"-aspektet er, at ethvert kommercielt system indebærer en applikation eller en mission. Fra perspektivet af en bruger af softwarearkitektur giver softwarearkitektur retning for at flytte og løse problemer relateret til hver enkelt brugers speciale, for eksempel en interessent, softwareudvikler, softwaresupportteam, softwarevedligeholder, softwareimplementeringsspecialist, tester, og også slutbrugere. I denne forstand samler softwarearkitektur faktisk forskellige perspektiver på et system. At disse flere forskellige synspunkter kan kombineres i en softwarearkitektur er et argument for nødvendigheden og hensigtsmæssigheden af at skabe en softwarearkitektur allerede før softwareudviklingsstadiet [7] [8] [9] .
Historie
Softwarearkitektur som koncept begyndte med Edsger Dijkstras forskningsarbejde i 1968 og David Parnassus i begyndelsen af 1970'erne. Disse forskere understregede, at strukturen af et softwaresystem er vigtig, og at opbygningen af den rigtige struktur er kritisk. Studiet af dette felt er vokset i popularitet siden begyndelsen af 1990'erne med forskningsarbejde om arkitektoniske stilarter (mønstre), arkitekturbeskrivelsessprog, arkitekturdokumentation og formelle metoder.
Forskningsinstitutioner spiller en vigtig rolle i udviklingen af softwarearkitektur som disciplin. Mary Shaw og David Garlan fra Carnegie Mellon University skrev en bog med titlen "Software Architecture: Perspectives on a New Discipline in 1996", hvori de fremlagde softwarearkitekturkoncepter såsom komponenter, konnektorer, stilarter og så videre. På University of California forsker Irvine Institute for Software Research primært i arkitektoniske stilarter, arkitekturbeskrivelsessprog og dynamiske arkitekturer.
Den første softwarearkitekturstandard er IEEE 1471: ANSI/IEEE 1471-2000: Guidelines for Describing Predominantly Software Systems. Det blev vedtaget i 2007 under navnet ISO ISO/IEC 42010:2007.
Arkitektur beskrivelse sprog
Arkitekturbeskrivelsessprog (ADLS) bruges til at beskrive arkitekturen af software. Adskillige forskellige ADLS er blevet udviklet af forskellige organisationer, herunder AADL (SAE standard), Wright (udviklet på Carnegie Mellon University), Acme (udviklet på Carnegie Mellon University), xADL (udviklet ved UCI), Darwin (udviklet på Imperial College London) , DAOP-ADL (udviklet ved University of Malaga) og ByADL (University of L'Aquila, Italien). Fælles elementer for alle disse sprog er begreberne komponent, stik og konfiguration. Ud over specialiserede sprog bruges også det forenede modelleringssprog UML ofte til at beskrive arkitekturen .
Visninger
En softwarearkitektur indeholder normalt flere visninger, der ligner de forskellige typer tegninger i bygningskonstruktion. I en ontologi defineret af ANSI/IEEE 1471-2000 er synspunkter synspunkter, hvor der eksisterer et synspunkt til at beskrive en arkitektur fra et givet sæt af interessenters synspunkt.
Den arkitektoniske udsigt består af 2 komponenter:
- Elementer
- Relationer mellem elementer
Arkitektoniske synspunkter kan opdeles i 3 hovedtyper [10] :
- Modulvisninger (eng. module views ) - viser systemet som en struktur af forskellige softwareblokke.
- Components-and-connectors (eng. component-and-connector views ) - viser systemet som en struktur af parallelt kørende elementer (komponenter), og hvordan de interagerer (connectors).
- Allokering (eng. allocation views ) - viser placeringen af systemelementer i eksterne miljøer.
Eksempler på modulære visninger:
- Decomposition (eng. decomposition view ) - består af moduler i sammenhæng med forholdet "er et undermodul"
- Brug (eng. uses view ) - består af moduler i sammenhæng med "bruger"-forholdet (dvs. et modul bruger et andet moduls tjenester)
- Niveauvisning (eng. layered view ) - viser en struktur, hvor moduler relateret til funktionalitet kombineres i grupper (niveauer)
- Klasse / generaliseringsvisning (eng. klasse / generaliseringsvisning ) - består af klasser relateret gennem forholdet "nedarvet fra" og "er en instans"
Eksempler på komponent-og-stiktyper:
- Process view (eng. process view ) - består af processer forbundet med kommunikation, synkronisering og/eller ekskluderingsoperationer
- Parallel visning (eng. concurrency view ) - består af komponenter og stik, hvor stikkene er "logiske flows"
- Dataudvekslingstype (eng. shared-data (repository) view ) - består af komponenter og forbindelser, der opretter, gemmer og modtager vedvarende data
- Client-server view (eng. client-server view ) - består af interagerende klienter og servere, samt forbindelser mellem dem (f.eks. protokoller og almindelige meddelelser)
Eksempler på boligtyper:
- Deployment (eng. deployment view ) - består af softwareelementer, deres placering på fysiske medier og kommunikationselementer
- Implementering (eng. implementeringsvisning ) - består af programelementer og deres overensstemmelse med filstrukturer i forskellige miljøer (udvikling, integration osv.)
- Arbejdsopgave (eng. arbejdsopgavevisning ) - består af moduler og en beskrivelse af, hvem der har ansvaret for at implementere hver af dem
Selvom der er udviklet flere sprog til at beskrive softwarearkitektur, er der i øjeblikket ingen enighed om, hvilket sæt synspunkter der skal bruges som reference. UML-sproget blev skabt som en standard "til modellering af softwaresystemer (og ikke kun)".
Arkitektoniske mønstre
Forskellige arkitektoniske mønstre anvendes for at tilfredsstille det designede system med forskellige kvalitetsegenskaber. Hver skabelon har sine egne mål og ulemper.
Eksempler på arkitektoniske mønstre:
- Lagdelt mønster. Systemet er opdelt i niveauer, som er vist over hinanden i diagrammet. Hvert niveau kan kun kalde niveau 1 under det. Således kan udviklingen af hvert niveau udføres relativt uafhængigt, hvilket øger systemets modificerbarhed. Ulemperne ved denne tilgang er komplikationen af systemet og faldet i ydeevne.
- Mægler mønster. Når der er et stort antal moduler i systemet, bliver deres direkte interaktion med hinanden for kompliceret. For at løse problemet introduceres et mellemled (for eksempel en databus), hvorigennem modulerne kommunikerer med hinanden. Således øges interoperabiliteten af systemmodulerne. Alle ulemper stammer fra tilstedeværelsen af en mellemmand: det reducerer ydeevnen, dets utilgængelighed kan gøre hele systemet utilgængeligt, det kan blive et angrebsobjekt og en flaskehals i systemet.
- Mønster "Model-View-Controller" (Model-View-Controller mønster). Fordi Da kravene til grænsefladen oftest ændres, er der behov for at ændre den ofte, samtidig med at den korrekte interaktion med dataene opretholdes (læse, gemme). For at gøre dette er grænsefladen adskilt fra dataene i Model-View-Controller (MVC) mønsteret. Dette giver dig mulighed for at ændre grænseflader, samt oprette forskellige versioner af dem. I MVC er systemet opdelt i:
- Modellen, der gemmer dataene
- En visning, der viser et stykke data og interagerer med brugeren
- En controller, der formidler mellem synspunkterne og modellen
MVC-konceptet har dog også sine ulemper. Især på grund af komplikationen af interaktion falder systemets hastighed.
- Klient-server-mønster (klient-server-mønster). Hvis der er et begrænset antal ressourcer, der kræver begrænset adgang af et stort antal forbrugere, er det praktisk at implementere en klient-server-arkitektur. Denne tilgang øger skalerbarheden og tilgængeligheden af systemet. Men samtidig kan serveren blive en flaskehals i systemet, hvis den ikke er tilgængelig, bliver hele systemet utilgængeligt.
Grundlæggende rammer for softwarearkitektur
Der er følgende rammer ( engelsk software architecture frameworks ) relateret til området softwarearkitektur:
- 4+1
- RM-ODP (referencemodel for åben distribueret behandling)
- Service Oriented Modeling Framework (SOMF)
Arkitektureksempler såsom Zachman Framework, DoDAF og TOGAF falder ind under domænet for virksomhedsarkitekturer.
Se også
Noter
- ↑ Kruchten, Philippe . The Rational Unified Process-An Introduction, Addison-Wesley, 1998
- ↑ Rumbaugh, J. , Jacobsen, I. og Booch, G. The Unified Modeling Language Reference Manual. Reading, Mass.: Addison-Wesley, 1999
- ↑ Documenting Software Architectures: Views and Beyond, 2010 , P.1.1. Oversigt.
- ↑ Documenting Software Architectures: Views and Beyond, 2010 , P.1.2. Arkitektur og kvalitetsegenskaber.
- ↑ Softwarearkitektur: Ordliste Arkiveret 5. januar 2013 på Wayback Machine , Software Engineering Institute
- ↑ Hvad er din definition af softwarearkitektur . resources.sei.cmu.edu. Hentet 23. oktober 2019. Arkiveret fra originalen 28. februar 2020.
- ↑ ISO/IEC/IEEE 42010: Definition af "arkitektur" . www.iso-architecture.org. Hentet 23. oktober 2019. Arkiveret fra originalen 7. april 2017. (ubestemt)
- ↑ M. Fowler. Design - Hvem har brug for en arkitekt? // IEEE-software. - 2003-9. - T. 20 , nej. 5 . — S. 11–13 . - doi : 10.1109/MS.2003.1231144 . Arkiveret fra originalen den 23. oktober 2019.
- ↑ En introduktion til softwarearkitektur . Hentet 23. oktober 2019. Arkiveret fra originalen 6. maj 2021. (ubestemt)
- ↑ Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice (3. udgave) (SEI Series in Software Engineering). - 3 oplag (5. oktober 2012). - 2012. - 640 s. — ISBN 978-0321815736 .
Litteratur
- Paul Clements; Felix Bachmann; Len bas; David Garlan; James Ivers; Reed Lille; Paul Merson; Robert North; Judith Stafford. Dokumentation af softwarearkitekturer: Udsigter og videre. - Anden version. - Addison-Wesley Professional, 2010. - ISBN 978-0-13-248861-7 .
- Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, tredje udgave . Addison Wesley, 2012, ISBN 978-0321815736 (Denne bog, nu i tredje udgave, dækker veltalende de grundlæggende begreber i disciplinen. Temaet er centreret omkring opnåelse af kvalitetsegenskaber for et system.)
Links