Systemarkitekturen er systemets grundlæggende organisering , legemliggjort i dets elementer , deres forhold til hinanden og med miljøet, såvel som de principper, der styrer dets design og udvikling [1] :3 .
Begrebet arkitektur er stort set subjektivt og har mange modstridende fortolkninger; i bedste fald afspejler det udviklingsteamets overordnede syn på resultaterne af systemdesign. [2] :27 Der er mange definitioner af arkitektur. En samling af definitioner, hovedsageligt relateret til softwarearkitektur , er samlet på webstedet for Software Engineering Institute ved Carnegie Mellon University [3] .
På nuværende tidspunkt er der en stærk tendens til at betragte arkitektonisk og ikke-arkitektonisk design som forskellige aktiviteter; Der gøres forsøg på at definere dem som separate praksisser, men disse typer design er stort set "sammenflettet". Arkitektoniske beslutninger ses som mere abstrakte, konceptuelle og globale end konventionelle designbeslutninger; de er rettet mod succes for hele missionen og på systemets højeste niveau strukturer [4] :272 .
Andre definitioner af systemarkitekturEfterhånden som kompleksiteten af de opgaver, der blev løst, steg, opstod behovet for at strukturere systemer. Imidlertid har praktiserende læger fundet udtrykket "struktur" utilstrækkeligt til at beskrive alle aspekter af systemet [4] :272 .
Udtrykket "arkitektur" i systemteknik blev introduceret af professor Eberhardt Rechtin fra University of Southern California i begyndelsen af 1990'erne . Han mente, at efterhånden som systemer blev mere komplekse, var deres "høj-niveau design" (eller "konceptuelle design"), som det blev forstået i disse år, ikke nok til at lede ingeniører og designere til at skabe nøjagtige og effektive designs. Han studerede arkitektoniske principper i bygning for at forstå, hvordan komplekse systemer (f.eks. bygninger) skabes og designes [6] :223 .
Rekhtin forklarer begrebet systemarkitektur som følger:
Essensen af arkitektur er strukturering. Strukturering kan betyde at omdanne form til funktion , udvinde orden fra kaos eller transformere en klients delvist dannede ideer til en brugbar konceptuel model [6] :223-224 .
Begreberne "arkitektur" og "arkitektonisk design" har været i brug i omkring 30 år, især inden for softwareteknik og problemområder som raket og rum [4] :272 .
For en mere detaljeret beskrivelse af arkitekturprincipperne introducerer ISO/IEC/IEEE 42010-2011 standarden følgende begreber [7] :2 .
Systems Engineering Body of Knowledge (SEBoK) opdeler arkitektur i logisk og fysisk [4] :269 .
Den logiske arkitektur understøtter systemets funktion gennem hele dets livscyklus på det logiske niveau. Den består af et sæt relaterede tekniske koncepter og principper. Den logiske arkitektur er repræsenteret ved metoder svarende til tematiske grupper af beskrivelser og omfatter som minimum en funktionel arkitektur, en adfærdsarkitektur og en tidsmæssig arkitektur.
Funktionel arkitektur . Den funktionelle arkitektur er et sæt af funktioner og deres underfunktioner, der bestemmer de transformationer, som systemet udfører, når det opfylder sit formål.
Adfærdsarkitektur . Adfærdsarkitektur er en aftale om funktioner og deres underfunktioner, samt grænseflader (input og output), som bestemmer rækkefølgen af udførelse, betingelser for kontrol eller dataflow, niveauet af ydeevne, der er nødvendigt for at tilfredsstille systemkrav. Adfærdsarkitektur kan beskrives som en samling af indbyrdes forbundne scenarier, funktioner og/eller driftsformer.
Midlertidig arkitektur . Tidsmæssig arkitektur er en klassificering af systemfunktioner, som opnås i overensstemmelse med frekvensniveauet for dets udførelse. Den tidsmæssige arkitektur omfatter definitionen af synkrone og asynkrone aspekter af funktioner. Overvågningen af beslutninger, der finder sted inden for systemet, følger den samme tidsmæssige klassifikation [4] :287 .
Målet med fysisk arkitekturdesign er at skabe en fysisk, konkret løsning, der er i overensstemmelse med den logiske arkitektur og opfylder de specificerede systemkrav.
Når først den logiske arkitektur er defineret, skal de specifikke fysiske elementer, der understøtter de funktionelle, adfærdsmæssige og tidsmæssige egenskaber, samt de forventede egenskaber af systemet afledt af de ikke-funktionelle systemkrav, identificeres.
En fysisk arkitektur er en systematisering af de fysiske elementer (systemelementer og fysiske grænseflader), der implementerer de designede løsninger til et produkt, en tjeneste eller en virksomhed. Det er designet til at opfylde kravene til systemet og elementerne i den logiske arkitektur og implementeres gennem systemets teknologiske elementer. Systemkrav er fordelt på tværs af både logiske og fysiske arkitekturer. Systemets globale arkitektur evalueres gennem systemanalyse og bliver, efter at alle krav er opfyldt, grundlaget for implementeringen af systemet [4] :296 .
En arkitektur kan fanges ved hjælp af en fuld arkitekturbeskrivelse (AO) (se figur). ISO/IEC/IEEE 42010-2011-standarden foreskriver en sondring mellem et systems konceptuelle arkitektur og en af beskrivelserne af den arkitektur, som er et bestemt produkt eller artefakt.
I komplekse systemer kan AO udvikles ikke kun til systemet som helhed, men også til systemets komponenter. To forskellige konceptuelle AO'er kan omfatte grupper af beskrivelser, der vil svare til den samme beskrivelsesmetode. Selvom systemerne beskrevet af disse to beskrivelsesgrupper vil være relateret som helhed og del, er dette ikke et eksempel på flere beskrivelsesgrupper svarende til én metode. Disse AO'er betragtes som adskilte, selvom de er forbundet gennem de systemer, de beskriver [7] :3 .
Den konceptuelle tilgang definerer termer og begreber relateret til indholdet og anvendelsen af AO. Figuren viser hovedbegreberne og deres sammenhænge. Alle begreber er defineret i sammenhæng med en specifik systemarkitektur og tilhørende arkitekturbeskrivelse. Det skal ikke antages, at der kun er én arkitektur for et system, eller at denne arkitektur kun er repræsenteret af én arkitekturbeskrivelse.
På figuren repræsenterer boksene enhedsklasserne.
Linjerne, der forbinder rektanglerne, repræsenterer forholdet mellem enheder. Kommunikation omfatter to roller (en i hver retning). Hver rolle kan valgfrit navngives med en etiket. En rolle rettet fra A til B er [mærket] tættere på B og omvendt. For eksempel kan rollerne mellem "system" og "miljø" læse "systemet" bor i "miljøet" og "miljøet" påvirker "systemet". I figuren har roller en aritet på 1:1, medmindre andet er angivet. En rolle kan have flere ariteter, for eksempel bruges en rolle betegnet som "1..*" til at betegne mange, som i en-til-mange eller mange-til-en relationer. Romben (ved slutningen af kommunikationslinjen) angiver forholdet mellem en del af helheden. For eksempel er "beskrivelsesgrupper" en del af "arkitektonisk beskrivelse". Denne notation er lånt fra UML.
Lad os overveje hver komponent i den konceptuelle ordning mere detaljeret. I forbindelse med den betragtede ordning, strækker systemet sig til individuelle softwareapplikationer, systemer i traditionel forstand, undersystemer, systemer, produkter, produktfamilier, organisationer som helhed og andre interessegrupper.
Systemet lever i et eller andet miljø. Miljøet i et bestemt system kan påvirke dette system. Dets miljø eller kontekst definerer miljøet og omstændighederne for udvikling, drift, politiske og andre påvirkninger på et givet system. Et sådant miljø kan omfatte andre systemer, der interagerer med målsystemet, enten direkte gennem grænseflader eller indirekte på andre måder. Et sådant miljø definerer de grænser, der definerer emnet for målsystemet i forhold til andre systemer.
Hvert system har en eller flere interessenter . Hver interessent deltager normalt i systemet eller har en interesse i systemet. Interesser involverer at tage højde for aspekter af systemet som ydeevne, pålidelighed, sikkerhed, distribution og evnen til at udvikle sig.
Ethvert system eksisterer for at implementere en eller flere missioner i sit miljø.
I den konceptuelle tilgang er en arkitektonisk beskrivelse organiseret som en eller flere arkitektoniske beskrivelsesgrupper.
Den arkitektoniske beskrivelse vælger en eller flere passende beskrivelsesmetoder, der skal anvendes. Valget af beskrivelsesmetoder er normalt baseret på overvejelser og interesser hos de interesserede parter, som AO er rettet til. Definitionen af beskrivelsesmetoden kan forekomme sammen med AO'en, eller den kan defineres separat. En beskrivelsesmetode defineret separat fra AO kaldes en biblioteksbeskrivelsesmetode.
En beskrivelsesgruppe kan bestå af en eller flere arkitektoniske beskrivelser. Hver sådan arkitektonisk beskrivelse er udviklet ved hjælp af de etablerede arkitektoniske beskrivelsesmetoder, der passer til den. En arkitektonisk beskrivelse kan indgå i mere end én gruppe af beskrivelser [7] :4-6 .
Der er tre typer beskrivelsesgrupper: funktionel, logisk og fysisk. Hver af grupperne er beregnet til at beskrive deres egne synspunkter og deres tilsvarende kompleksitetsniveau [6] :224 .
Beskrivelse funktionel gruppeDenne gruppe giver en bruger- eller operatørvisning, der inkluderer produkter relateret til operativsystemets faser, scenarier og opgaveflows. Informationsstrømmen kan ses fra et brugerperspektiv, og brugergrænseflader er også beskrevet. Eksempler på produkter, der kan inkluderes i denne beskrivelse, vil være funktionelle data eller grafik, scenariebeskrivelser (herunder brugen af casestudier), opgaveflowdiagrammer, organisationsdiagrammer og informationsflowdiagrammer [6] :224 .
Logisk gruppe af beskrivelserDenne gruppe giver et overblik fra lederens eller kundens synspunkt. Den logiske visning omfatter produkter, der definerer systemets grænser med dets miljø og funktionelle grænseflader med eksterne systemer, såvel som systemets hovedfunktioner og adfærd, informationsstrømme, interne og eksterne datasæt, interne og eksterne brugere og interne funktionelle grænseflader . Eksempler på produkter omfatter funktionelle flowblokdiagrammer (FFBD), kontekstdiagrammer, N²- diagrammer , IDEF0 -diagrammer, rutediagramdata og forskellige interessenter - karakteristiske produkter (inklusive forretningsafhængige produkter) [6] :224 .
Fysiske gruppebeskrivelserDenne gruppe giver et overblik fra designeres synspunkt. Inkluderer:
Produktet kan indeholde fysiske blokdiagrammer på et ret højt detaljeringsniveau, databasetopologier , dokumentstyringsgrænseflader og standarder. Alle de tre gruppetyper skal være til stede i hver arkitekturbeskrivelse [6] :224 .
Arkitektoniske beskrivelser i løbet af livscyklussen kan anvendes forskelligt af alle interessenter. Sådanne applikationer omfatter, men er ikke begrænset til, følgende: