Sammanfattning av denna webbsida: Denna rekommenderade praxis behandlar aktiviteter för skapande, analys och upprätthållande av arkitekturer i programvaruintensiva system, och inspelning av sådana arkitekturer i termer av arkitektoniska beskrivningar. Ett konceptuellt ramverk för arkitektonisk beskrivning upprättas. Innehållet i en arkitektonisk beskrivning definieras. Bilagor ger en grund för nyckelbegrepp och terminologi, förhållandet till andra standarder och exempel på användning. Nyckelord: arkitektur, arkitektur, programvaruintensiva system, intressentfrågor, systemintressent, synvinkel IEEE Standarder dokument utvecklas inom IEEE Societies och Standards Coordinating Committees av IEEE Standards Association (IEEE-SA) Standards Board. Utskottens ledamöter tjänar frivilligt och utan ersättning. De är inte nödvändigtvis medlemmar av institutet. De standarder som utvecklats inom IEEE är eniga om den breda sakkunskapen inom institutet och de verksamheter utanför IEEE som har visat intresse för att delta i utvecklingen av standarden. Det är helt frivilligt att använda en IEEE-standard. Förekomsten av en IEEE-standard innebär inte att det inte finns några andra sätt att producera, testa, mäta, köpa, marknadsföra eller tillhandahålla andra varor och tjänster med anknytning till IEEE-standardens tillämpningsområde. Den ståndpunkt som uttrycktes vid den tidpunkt då en standard godkändes och utfärdades kan dessutom komma att ändras till följd av utvecklingen av den senaste tekniken och synpunkter från användare av standarden. Varje IEEE-standard ska ses över minst vart femte år för översyn eller bekräftelse. När ett dokument är mer än fem år gammalt och inte har bekräftats är det rimligt att dra slutsatsen att dess innehåll, även om det fortfarande är av ett visst värde, inte helt återspeglar det nuvarande tekniska läget. Användarna uppmanas att kontrollera att de har den senaste utgåvan av någon IEEE Standard. Kommentarer till översynen av IEEE-standarder välkomnas från alla berörda parter, oavsett medlemskap i IEEE. Förslag till ändringar i dokumenten bör vara i form av en föreslagen ändring av texten, tillsammans med lämpliga stödjande kommentarer. Tolkningar: Ibland kan det uppstå frågor om betydelsen av delar av standarder eftersom de hänför sig till specifika tillämpningar. När IEEE får kännedom om behovet av tolkningar kommer institutet att vidta åtgärder för att utarbeta lämpliga svar. Eftersom IEEE-standarderna utgör ett samförstånd mellan alla berörda intressen är det viktigt att se till att varje tolkning också har fått en sammanfallande intressebalans. Därför kan IEEE och medlemmarna i dess organisationer och standardiseringskommittéer inte ge något omedelbart svar på tolkningsförfrågningar utom i de fall då ärendet tidigare har behandlats formellt. Kommentarer till standarder och förfrågningar om tolkningar bör riktas till: Sekreterare, IEEE-SA Standards Board 445 Hoes Lane P.O. Fält 1331 Piscataway, NJ 08855-1331 USA IEEE är den enda enhet som kan tillåta användning av certifieringsmärken, varumärken eller andra beteckningar för att ange överensstämmelse med de material som anges här. Tillstånd att kopiera delar av någon enskild standard för internt eller personligt bruk beviljas av Institute of Electrical and Electronics Engineers, Inc., förutsatt att lämplig avgift betalas till Copyright Clearance Center. För att betala licensavgiften, vänligen kontakta Copyright Clearance Center, Kundtjänst, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Tillstånd att kopiera delar av någon enskild standard för undervisning klassrum kan också erhållas via Copyright Clearance Center. Observera: Man bör uppmärksamma möjligheten att tillämpningen av denna standard kan kräva användning av ämnen som omfattas av patenträttigheter. Genom att offentliggöra denna standard tar man inte ställning till förekomsten eller giltigheten av några patenträttigheter i samband med detta. IEEE ska inte vara ansvarigt för att identifiera patent för vilka en licens kan krävas enligt en IEEE-standard eller för att genomföra undersökningar om den rättsliga giltigheten eller omfattningen av de patent som kommer till dess kännedom. Man har länge insett att "arkitektur" har ett starkt inflytande över ett systems livscykel. Tidigare var hårdvarurelaterade arkitektoniska aspekter dominerande, medan programvarurelaterad arkitektonisk integritet, när den existerade, ofta skulle offras först under systemutvecklingen. Idag är programvaruintensiva system genomträngande. Kostnaden för programvaruutveckling och programvarusystemens ökande komplexitet har förändrat den relativa balansen. Programvarutekniken mognar snabbt. Bruket av systemutveckling kan ha stor nytta av att följa arkitektoniska föreskrifter. Arkitekturbegreppen har dock inte konsekvent definierats och tillämpats inom de programvaruintensiva systemens livscykel. Trots betydande industri- och forskningsverksamhet på detta område finns det ingen enhetlig, accepterad ram för kodifiering av arkitektoniskt tänkande, vilket underlättar en gemensam tillämpning och utveckling av tillgängliga och framväxande arkitektoniska metoder. IEEE Architecture Planning Group (APG) bildades i augusti 1995 för att tillgodose detta behov. Den APG chartrades av IEEE Software Engineering Standards Committee (Sesc) för att ange en riktning för att införliva arkitektoniskt tänkande i IEEE-standarder. Resultatet av APG:s överläggningar var att rekommendera en IEEE-aktivitet med följande mål: -Att definiera användbara termer, principer och riktlinjer för en konsekvent tillämpning av arkitektoniska föreskrifter för system under hela deras livscykel -att utarbeta arkitektoniska föreskrifter och deras förväntade fördelar för programvaruprodukter, system och aggregerade system (dvs. system av system) -att tillhandahålla en ram för kolilektion och beaktande av arkitektoniska attribut och tillhörande information för användning i IEEE-standarder -att tillhandahålla en användbar färdplan för att införliva arkitektoniska föreskrifter i generering, revidering och tillämpning av IEEE-standarder I april 1996 skapade SESC arbetsgruppen för arkitektur (AWG) för att genomföra dessa rekommendationer. iv Upphovsrättsskyddat © 2000 IEEE. Alla rättigheter förbehållna. Vid den tidpunkt då denna rekommenderade praxis slutfördes hade arbetsgruppen för arkitektur följande sammansättning.  Denna rekommenderade praxis behandlar den arkitektoniska beskrivningen av programvaruintensiva system. Ett programvaruintensivt system är alla system där programvara bidrar med viktiga influenser till design, konstruktion, installation och utveckling av systemet som helhet. Tillämpningsområdet för denna rekommenderade praxis omfattar de produkter av systemutveckling som samlar in arkitektonisk information. Detta inkluderar arkitektoniska beskrivningar som används för följande: a) Uttryck av systemet och dess utveckling b) Kommunikation bland systemets intressenter c) Utvärdering och jämförelse av arkitekturer på ett konsekvent sätt d) Planering, förvaltning och genomförande av verksamheten i systemutveckling e) Uttryck av de bestående egenskaperna och stödjande principerna i ett system för att vägleda godtagbar förändring f) Verifiering av ett systemgenomförandes överensstämmelse med en arkitektonisk beskrivning g) Inspelning av bidrag till kunskapen om programvaruintensiv systemarkitektur Syftet med denna rekommenderade praxis är att underlätta uttryck och kommunikation av arkitekturer och därigenom lägga en grund för kvalitets- och kostnadsvinster genom standardisering av element och metoder för arkitektonisk beskrivning. Trots betydande insatser för att förbättra tekniska metoder och teknik fortsätter mjukvaruintensiva system att medföra oerhörda risker och svårigheter i sin design, konstruktion, installation och utveckling. De senaste försöken att ta itu med dessa svårigheter har fokuserat på den tidigaste perioden för beslutsfattande och utvärdering av konstruktion, som i allt högre grad kallas systemutvecklingsnivå. Fraserna arki- tectural nivå och arkitektur används i stor utsträckning, om oprecis,. Deras användning återspeglar acceptansen av en arkitektonisk metafor i analys och utveckling av mjukvaruintensiva system. En viktig förutsättning för denna metafor är att viktiga beslut kan fattas tidigt i systemutvecklingen på ett sätt som liknar det tidiga beslutsfattandet i utvecklingen av civila arkitekturprojekt. Många innovationer är resultatet av denna uppmärksamhet på den arkitektoniska nivån, bland annat arkitektoniska beskrivningsspråk och tillhörande verktyg och miljöer; arkitektoniska ramar, modeller och mönster; och tekniker för arkitektonisk analys, utvärdering och arkitekturbaserad återanvändning. Även om dessa insatser skiljer sig avsevärt åt när det gäller viktiga aspekter, finns det tillräckligt med gemensamma åtgärder för att motivera utvecklingen av en rekommenderad praxis för att kodifiera deras gemensamma delar. Dessa innovationer sker och mognar snabbt inom många forsknings- och tillämpningsgemenskaper och återspeglar olika intressen, influenser, insikter och intentioner. Det råder allmän enighet om betydelsen av den arkitektoniska nivån av systemutveckling och att denna nivå består av ett tidigt beslutsfattande om övergripande utformningsstruktur, mål, krav och utvecklingsstrategier. Det har dock ännu inte framkommit någon tillförlitlig enighet om en exakt definition av ett systems arkitektur, dvs. hur det ska beskrivas, vilka användningar en sådan beskrivning kan tjäna, eller var och när den ska definieras. Gränserna och sambanden mellan arkitektoniska trender och praktiker, och mellan arkitektonisk teknik och annan teknik, är ännu inte allmänt erkända. I sådana situationer är framsteg ofta beroende av medlande inflytande. Potentiella användare av arkitektoniska metoder och teknik behöver en referensram för att ta itu med beslut om genomförande och antagande. Teknikutvecklare behöver en referensram för att kommunicera de motiverande koncepten med sin teknik, och för att samla och uppskatta feedback från tidig adoption. I detta syfte är syftet med denna rekommenderade praxis att återspegla allmänt accepterade trender i praxis för arkitektonisk beskrivning och att tillhandahålla en teknisk ram för vidareutveckling på detta område. Dessutom fastställs en begreppsmässig ram för begrepp och referensramar inom vilken framtida utveckling av systemarkitekturteknik kan användas. Denna rekommenderade praxis kodifierar de delar som det råder enighet om, särskilt användningen av flera synpunkter, återanvändningsbara specifikationer för modeller inom synfältet och arkitekturens förhållande till systemsammanhanget. Den huvudsakliga användarklassen för denna rekommenderade praxis omfattar intressenter inom systemutveckling och utveckling, inklusive följande: -De som använder, äger och förvärvar systemet (användare, operatörer och förvärvare, eller kunder) -De som utvecklar, beskriver och dokumenterar arkitekturer (architects) -De som utvecklar, levererar och underhåller systemet (architects, designers, programmerare, utvecklare, testare, domäningenjörer, kvalitetssäkring personal, konfigurationsledning personal, leverantörer, och projektledare eller utvecklare) -De som övervakar och utvärderar system och deras utveckling (huvudinformationsansvariga, revisorer, och oberoende bedömare) En sekundär klass av användare av denna rekommenderade praxis omfattar de som deltar i den företagsomfattande infrastrukturverksamheten som spänner över flera systemutvecklingar, inklusive metodologer, process- och processförbättringsingenjörer, forskare, producenter av standarder, verktygsbyggare och utbildare.  En arkitektonisk beskrivning överensstämmer med denna rekommenderade praxis om beskrivningen uppfyller kraven i klausul 5. Denna rekommenderade praxis skall användas i samband med följande publikationer. När följande standarder ersätts av en godkänd översyn ska översynen tillämpas.  I denna standard gäller följande termer och definitioner.  En organisation som upphandlar ett system, en programvaruprodukt eller en programvarutjänst från en leverantör. (Inköparen kan vara köpare, kund, ägare, användare eller köpare.) Personen, teamet eller organisationen som ansvarar för systemarkitekturen. Verksamhet för att definiera, dokumentera, underhålla, förbättra och certifiera ett korrekt genomförande av en arkitektur. En samling produkter för att dokumentera en arkitektur. Den grundläggande organisationen av ett system förkroppsligat i dess komponenter, deras relationer till varandra och till miljön, och de principer som styr dess utformning och utveckling. En ram som innehåller processer, aktiviteter och uppgifter som rör utveckling, drift och underhåll av en programvaruprodukt, som spänner över systemets livslängd från definitionen av dess krav till dess att dess användning upphör. En samling komponenter organiserade för att utföra en specifik funktion eller uppsättning funktioner. 3.8 systemintressent: En individ, ett team eller en organisation (eller klasser av sådana) med intressen i eller intressen i förhållande till ett system. Representation av ett helt system ur ett relaterat perspektiv.  En specifikation av konventionerna för konstruktion och användning av en vy. Ett mönster eller mall för att utveckla individuella vyer genom att fastställa syfte och publik för en vy och tekniker för dess skapande och analys. Genom denna klausul införs en begreppsram, eller referensram, för arkitektonisk beskrivning. I ramverket fastställs termer och begrepp som hänför sig till innehåll och användning av arkitektoniska beskrivningar. Dessa termer och begrepp kommer att användas i efterföljande klausuler. I denna rekommenderade praxis omfattar begreppet system individuella tillämpningar, system i traditionell bemärkelse, delsystem, system, produktlinjer, produktfamiljer, hela företag och andra intressegrupper. Ett system bebor en miljö. Ett systems miljö kan påverka det systemet. Miljön, eller sammanhanget, bestämmer inställningen och omständigheterna för utveckling, operationella, politiska och andra influenser på det systemet. Miljön kan omfatta andra system som interagerar med systemet av intresse, antingen direkt via gränssnitt eller indirekt på andra sätt. Miljön bestämmer de gränser som definierar omfattningen av systemet av intresse i förhållande till andra system. Ett system har en eller flera intressenter. Varje berörd part har vanligtvis intressen i eller intressen i förhållande till detta system. Bekymmer är de intressen som hänför sig till systemets utveckling, funktion eller andra aspekter som är kritiska eller på annat sätt viktiga för en eller flera intressenter. Bekymren omfattar systemöverväganden som prestanda, tillförlitlighet, säkerhet, distribution och utvecklingsförmåga. Ett system finns för att utföra ett eller flera uppdrag i sin omgivning. Ett uppdrag är en användning eller operation för vilken ett system är avsett av en eller flera intressenter för att uppfylla vissa mål. Varje system har en arkitektur, i termer av denna rekommenderade praxis. En arkitektur kan registreras genom en arkitektonisk beskrivning (se figur 1 ). Denna rekommenderade praxis skiljer arkitekturen i ett system, som är begreppsmässigt, från särskilda beskrivningar av denna arkitektur, som är konkreta produkter eller artefakter. Arkitekturbeskrivningar är föremål för denna rekommenderade praxis. Inom den begreppsmässiga ramen för denna rekommenderade praxis, är en arkitektonisk beskrivning organiserad i en eller flera komponenter som kallas (architectural) vyer. Varje vy tar upp en eller flera av systemets berörda parters farhågor. Termen vy används för att hänvisa till uttrycket av ett systems arkitektur med avseende på en särskild synvinkel. NOTE-Denna rekommenderade praxis använder inte termer som funktionell arkitektur, fysisk arkitektur, och teknisk arkitektur, som ofta används informellt. Inom den begreppsmässiga ramen för den rekommenderade praxis, skulle ungefärliga motsvarigheter av dessa informella termer vara funktionell syn, fysisk syn, och teknisk syn, respektive. Annan information, som inte ingår i någon konstituerande vy, kan visas i en AD, som ett resultat av en organisations dokumentation praxis. Exempel på sådan information är systemöversikten, systemsammanhanget, systemets intressenter och deras centrala frågor samt den arkitektoniska logiken. En synpunkt fastställer de konventioner genom vilka en vy skapas, avbildas och analyseras. På så sätt stämmer en uppfattning överens med en ståndpunkt. Utgångspunkten avgör vilka språk (inklusive noteringar, modell eller produkttyper) som ska användas för att beskriva vyn och eventuella tillhörande modelleringsmetoder eller analystekniker som ska vara Copyright © 2000 IEEE. Alla rättigheter förbehållna. tillämpas på dessa framställningar av åsikten. Dessa språk och tekniker används för att ge resultat som är relevanta för synpunkterna. En arkitektonisk beskrivning väljer en eller flera synpunkter för användning. Urvalet av synpunkter kommer vanligtvis att baseras på hänsyn till de intressenter som AD riktar sig till och deras farhågor. En synpunktsdefinition kan ha sitt ursprung i en AD, eller också kan den ha definierats på annat håll. En synpunkt som definieras på annat håll hänvisas i denna rekommenderade praxis som ett bibliotek synpunkt. En vy kan bestå av en eller flera arkitektoniska modeller. Varje sådan arkitektonisk modell utvecklas med hjälp av de metoder som fastställts genom dess tillhörande arkitektoniska synsätt. En arkitektonisk modell kan delta i mer än en vy. NOTE-I ett komplext system, ADs kan utvecklas för komponenter i systemet, liksom för systemet som helhet. I detta fall kan det vara så att en AD kommer att ha en uppfattning som motsvarar en viss ståndpunkt och en annan AD kommer att ha en uppfattning som motsvarar samma ståndpunkt. Även om det system som beskrivs av dessa två åsikter har hela delen relation, är detta inte ett exempel på flera åsikter som motsvarar en synpunkt. AD anses vara separata även om de är relaterade till de system som de beskriver. ANMÄRKNING – Figur 1 ger en informativ sammanfattning av de nyckelbegrepp som införs genom denna rekommenderade praxis och deras inbördes samband. Figuren presenterar dessa begrepp inom ramen för en arkitektur för ett visst system och en tillhörande arkitektonisk beskrivning. Detta är inte att anta eller kräva att ett system bara har en arkitektur eller att det bara finns en arkitektonisk beskrivning av den arkitekturen. I figuren representerar rutor klasser av saker. roll kan valfritt namnges med en etikett. Rollen från A till B ligger närmast B och vice versa. Till exempel kan rollerna mellan SYSTEM och MILJÖ läsas: Ett SYSTEM bebor en MILJÖ, och en MILJÖ påverkar ett SYSTEM. I figuren, roller är en-till-en om inte annat anges. En roll kan ha en mångfald, t.ex., en roll märkt med "1..*" används för att beteckna många, Som i en en-till-många eller många-till-många association.  Linjer som förbinder lådor representerar samband mellan saker. En förening har två roller (en i varje riktning Intressenter har olika roller när det gäller att skapa och använda arkitektoniska beskrivningar. Bland intressenterna finns kunder, användare, arkitekt, utvecklare och utvärderare. Två viktiga roller bland intressenterna är förvärvaren (eller klienten) och arkitekten. Arkitekten utvecklar och upprätthåller en arkitektur för ett system för att tillfredsställa förvärvaren. Arkitekten kan arbeta utifrån krav som ställs av en förvärvare eller kan vara ansvarig för att framkalla och utveckla krav som en del av arkitekturutvecklingen. Förvärvarens roll kan fyllas av en köpare, kund, ägare, användare eller köpare (se IEEE/EIA Std 12207.0 − 1996 3 ). Arkitektens roll kan fyllas av olika personer, team eller organisationer under arkitekturens hela livscykel. Arkitekten dokumenterar arkitekturen för systemets intressenter i form av en arkitektonisk beskrivning. I denna form hjälper arkitekturen till att vägleda systemets utvecklare. Arkitektverksamhet bidrar till utveckling, drift och underhåll av ett system från dess ursprungliga koncept till dess att det går i pension från användning. Som sådan är arkitektverksamhet bäst förstådd i ett livscykelsammanhang, inte bara som en enda aktivitet vid ett tillfälle i den livscykeln. Arkitektering handlar om att utveckla tillfredsställande och genomförbara systemkoncept, upprätthålla integriteten hos dessa systemkoncept genom utveckling, certifiera inbyggda system för användning och säkerställa dessa systemkoncept genom operativa och evolutionära faser. Detaljerade systemtekniska aktiviteter, såsom detaljerade kravdefinitioner och gränssnittsspecifikationer och arkitektisering av större delsystem är uppgifter som vanligtvis följer utvecklingen av systemarkitekturen. Denna rekommenderade praxis varken förutsätter eller föreskriver en specifik livscykelmodell – en livscykelmodell ska väljas separat av användarna av den rekommenderade metoden. Scenarierna i 4.3.1–4.3.4 är avsedda att ge förslag på olika användningsområden för den rekommenderade metoden inom en systemlivscykel. För nya systemkonstruktioner, i de fall då användaren och förvärvaren är identiska, utförs arkitektarbete som svar på användarens vision för systemet, systemmålen och intressenternas behov och begränsningar. De viktigaste intressenterna är användare och systemutvecklare. Den arkitektoniska beskrivningen kan användas under hela livscykeln för att förutsäga lämpligheten för användning av ett system vars arkitektur överensstämmer med den arkitektoniska beskrivningen. Dessutom kommer AD normalt att utvecklas under hela livscykeln, och kan därmed fungera som ett sätt att bedöma förändringar i systemet. 3 Information om hänvisningar finns i klausul 2. Upphovsrättsskyddat © 2000 IEEE. Alla rättigheter förbehållna.  I detta scenario samverkar arkitekturen, de levererade systemen och de berörda parterna. En inledande arkitektur utarbetas som svar på nuvarande och förväntade användarbehov med hjälp av nuvarande och uppskattad teknisk kapacitet. De första systemen levereras med hjälp av denna arkitektur. I takt med att arkitekturen utvecklas som svar på nya intressenters behov, levereras systemen baserat på den arkitektur som rådde vid tidpunkten för utvecklingen. På samma sätt kommer antalet berörda parter i systemen och arkitekturen att förändras allteftersom arkitekturen utvecklas. För evolutionära system används den arkitektoniska beskrivningen för systemutveckling och utvärdering, men dess användning och utveckling är samtidig. Intressentbehoven omprövas med varje iteration av arkitekturen; AD används för att vägleda varje system när det rör sig genom utveckling, och lämpliga AD-versioner används för att utvärdera varje system vid leverans. Arkitekturer som utvecklats enligt detta scenario kommer naturligtvis att betona flexibilitet och anpassningsförmåga starkare än enskilda systemarkitekturer. Arkitektoniska beskrivningar för föränderliga system kommer vanligtvis att utvecklas i ett iterativt mönster, eller rytm, av versionsförändringar. Arkitekturutvecklingen kommer normalt att utföras av utvecklaren som en del av den övergripande aktiviteten att utveckla en sekvens av system. Arkitekturen kan också etableras av förvärvaren som ett sätt att organisera förvärv och utveckling av en sekvens av system. Detta tillvägagångssätt är ett sätt att utveckla en produktlinjearkitektur. Utvecklingen av arkitekturen kommer normalt att sponsras av förvärvaren som en del av den övergripande verksamheten för sekventiell utveckling eller, när det gäller kommersiell-off-the-shälf-programvara, distribution av system. Ett tredje scenario uppstår när systemutvecklingen har ägt rum utan en arkitektonisk beskrivning, eller när AD, och kanske arkitekten, inte längre är tillgängliga. Det inbyggda systemet kommer att ha en arkitektur (eftersom varje system har en arkitektur, oavsett om den är känd eller inte) men det kommer att sakna en arkitektonisk beskrivning. I detta fall kan en AD skapas genom en back-engineering ansträngning. Med hjälp av denna rekommenderade praxis konstrueras först en arkitektonisk beskrivning av det befintliga systemet. Denna AD används sedan för att utveckla ett nytt system, för att styra underhålls- eller utvecklingsaktiviteter, eller för att etablera en evolutionär arkitektur som i scenarierna ovan (se 4.3.1 och 4.3.2). I vissa fall behövs en ny AD eftersom den ursprungliga beskrivningen inte ger synpunkter som är nödvändiga senare i ett systems livscykel. Syftet med utvärderingen är att fastställa kvaliteten på en arkitektonisk beskrivning och att förutsäga kvaliteten på system vars arkitektur överensstämmer med den arkitektoniska beskrivningen. Kvaliteten på en arkitektonisk beskrivning avser dess förmåga att tillgodose behoven och oron hos de intressenter för vilka den byggdes. Sådana frågor omfattar vanligen begriplighet, konsekvens, fullständighet och analys av beskrivningen. Förutsägelse av kvaliteten på de system som följer av den arkitektoniska beskrivningen omfattar bland annat genomförbarhet, effektivitet och tillförlitlighet. För att utvärdera en arkitekturs överensstämmelse med en arkitektonisk beskrivning krävs en process för omvänd konstruktion en arkitektonisk beskrivning från ett genomförande (se 4.3.3).  Arkitekturbeskrivningar är tillämpliga på en mängd olika användningsområden, av en mängd olika intressenter, under hela livscykeln. Dessa användningar inkluderar, men är inte begränsade till följande: OBS -Denna rekommenderade praxis anger inte ett leveransformat för en arkitektonisk beskrivning. En AD skall innehålla följande information om AD som helhet: Den detaljerade formen och innehållet i motsvarande informationsposter skall bestämmas av den använda organisationen. Dessa artiklar valdes för att göra det möjligt för användarna att uppfylla kraven i IEEE/EIA Std 12207.0-1996. En AD ska identifiera de intressenter som arkitekten har beaktat vid utformningen av det arkitektoniska konceptet för systemet. De problem som identifierats bör åtminstone omfatta följande: -Syftet med eller uppdragen med systemet – Lämpligheten hos systemet för att utföra sina uppdrag – Möjligheten att bygga systemet – Riskerna för systemutveckling och drift för användare, förvärvare och utvecklare av systemet –Hållbarhet, driftskompatibilitet och valbarhet hos systemet Den specifika avsikten med begreppen uppdrag, lämplighet och genomförbarhet kommer att variera från system till system. En AD ska ytterligare specificera de problem som identifierats i samband med systemet av intresse. En AD ska identifiera de synpunkter som valts ut för användning där. e) Källan, för ett bibliotek synpunkt (källan kan inkludera författare, datum, eller hänvisning till andra dokument, som bestäms av den använda organisationen). En observationsspecifikation kan innehålla ytterligare information om arkitektoniska metoder i samband med användning av synpunkten, enligt följande: -Formell eller informell konsekvens och fullständighetstester som ska tillämpas på modeller som utgör en tillhörande vy -Utvärderings- eller analysteknik som ska tillämpas på modellerna -Heuristik, mönster, eller andra riktlinjer för att hjälpa till vid syntesen av en tillhörande vy Viewpoint specifikationer kan införlivas genom hänvisning (t.ex. till en lämplig rekommenderad praxis eller tidigare definierad praxis). En AD ska innehålla en motivering för valet av varje synpunkt. Motiveringen ska ta upp i vilken utsträckning de berörda parterna och de farhågor som krävs i 5.2 omfattas av de synpunkter som valts ut enligt denna klausul. OBS! Den rekommenderade praktiken kräver inte att några särskilda synpunkter väljs ut genom en arkitektonisk beskrivning. Motiveringen för valet av synpunkter visar dock att de valda synpunkterna omfattar den minsta uppsättning berörda parter och de farhågor som krävs i 5.2. Varje berörd part och varje fråga som identifierats i en AD i enlighet med 5.2 ska behandlas med minst ett av de synpunkter som valts ut i enlighet med 5.3. En intressent eller intressent kan behandlas med mer än en synpunkt i en arkitektonisk beskrivning. 1-Det är tänkt att genom valet av lämpliga synpunkter, en AD kan uppnå överensstämmelse med andra utvecklings- eller arkitekturstandarder. 2-Bilagorna C och D innehåller exempel på synpunkter och specifikationer för synpunkter. En AD ska innehålla en eller flera arkitektoniska vyer. Varje vy i en AD ska motsvara exakt en synpunkt, som valts i enlighet med 5.3. Varje vy i en AD ska överensstämma med specifikationen av dess motsvarande ståndpunkt. Varje vy ska omfatta: a) En identifierare och annan inledande information, såsom den definieras av den använda organisationen b) Representation av systemet konstruerat med de språk, metoder och modellering eller analytiska tekniker som hör till den tillhörande synvinkeln c) Konfigurationsinformation, såsom den definieras av den använda organisationen En arkitektonisk vy kan bestå av en eller flera arkitektoniska modeller. Upphovsrättsskyddat © 2000 IEEE. Alla rättigheter förbehållna. 11 En AD ska registrera alla kända inkonsekvenser bland sina arkitektoniska åsikter. En AD bör innehålla en analys av konsekvensen i alla sina arkitektoniska synsätt. En AD ska innehålla en motivering för de arkitektoniska begrepp som valts. En AD bör ge belägg för beaktandet av alternativa arkitektoniska begrepp och den logiska grunden för de val som görs. När AD beskriver ett system som pre-existerar utvecklingen av AD, ska motiveringen för den äldre systemarkitekturen presenteras, om den är känd. Ett kort exempel visar hur de normativa kraven i klausul 5 kopplar samman varandra. För att göra anspråk på överensstämmelse med denna rekommenderade praxis måste arkitekten ta fram en arkitektonisk beskrivning som uppfyller kraven i 5.1 till 5.6. Underavsnitt 5.1 kräver att AD innehåller grundläggande dokumentinformation. Senast 5,2 måste AD identifiera arkitektoniskt relevanta intressenter och farhågor. Till exempel måste en intressent vara systembyggaren, och en av intressenternas farhågor kan vara systemets input/output-beteende. Denna rekommenderade praxis ställer endast minimala krav på de frågor som valts ut och därmed anses vara arkitektoniska. Den använda organisationen och arkitekten måste göra det centrala valet av vad som är viktigt att ta itu med. Underavsnitt 5.3 kräver att en uppsättning synpunkter väljs, definieras och analyseras för täckning och att motiveringen anges för urvalet. Arkitekten kan därför välja en beteendemässig synpunkt som skulle beskriva systemets input/output beteende. Arkitekten skulle också vara skyldig att definiera vilka språk eller modeller som kommer att användas för att beskriva systemets beteende under den synpunkten. Ingen begränsning görs på det språk eller den modelleringsteknik som används, men den måste uttryckligen anges i enlighet med 5.3. Underavsnitt 5.4 kräver att den resulterande arkitekturen representeras genom en eller flera vyer. Arkitekten kommer att konstruera en beteendemässig syn på systemet, och denna beteendemässig syn måste överensstämma med den beteendemässiga synpunkt som tidigare definierats. Underavsnitt 5.5 kräver att alla kända inkonsekvenser mellan eller mellan vyer (t.ex. mellan beteendevyn som tillhandahålls och en strukturell vy) anges i den arkitektoniska beskrivningen. Slutligen måste AD, i enlighet med 5.6, innehålla en motivering till arkitektens arkitektoniska beslut och val. ANMÄRKNINGAR: 1-Det material som rör 5.2 och 5.3, intressenterna, intressen och synpunkter, bör vara lätt att återanvända element för aktiva arkitektorganisationer. Det är troligt att sådana organisationer kommer att anta gemensamma uppsättningar av synpunkter och bilaga B (information) Denna rekommenderade praxis använder sig av tre termer, arkitektur, syn och synsätt, som återspeglar samförstånd i samhället, men ändå används på olika sätt som skiljer sig från vissa nuvarande användningsområden. I denna bilaga diskuteras villkoren för att klargöra de grundläggande begreppen i den rekommenderade praxisen.
Dessutom överensstämmer metoden med IEEE:s rekommenderade praxis för arkitektoniska beskrivningar (IEEE-Std-1471 REF ).
IEEE Recommended Practice for Architectural Description of Software-Intensive Systems