beskriver designbeslutninger, der bestemmer de primære adfærdsmæssige og strukturelle egenskaber ved et program (softwaresystem). Strategiske beslutninger vedrører globale, systemdækkende spørgsmål og har de mest omfattende konsekvenser. Strategiske beslutninger omfatter valg af programmeringsparadigme (“objektorienteret programmering”), arkitektonisk stil (“pipes and filters”), applikationsramme (“Microsoft Foundation Classes”), komponentbaserede standarder for softwareudvikling (“Enterprise JavaBeans”) og designprincipper (“universal base class”) samt antagelser, der kan føre til arkitektonisk mismatch (“Softbench Broadcast Message Server forventede, at alle komponenterne havde en grafisk brugergrænseflade”) og lovbestemte regelmæssigheder (“hver klasse i systemet arver fra klasse C”). På grund af de konsekvenser, de medfører, skal strategiske beslutninger træffes tidligt i softwareudviklingsprocessen og bør fastlægges eksplicit, før der udføres et detaljeret design.
I modsætning hertil artikulerer taktiske designstatements designbeslutninger, der vedrører et specifikt modul. Taktiske beslutninger beskriver ofte et mønster af sammenhænge mellem en samling af moduler (objekter, procedurer, klasser osv.) og en anden samling af moduler (objekter, procedurer, klasser osv.). Intuitivt set er taktiske erklæringer “lokale” i den forstand, at deres anvendelsesområde er begrænset til en del af programmet og ikke uden for det. Taktiske beslutninger omfatter valg af designmønstre (“Factory Method”), refaktoriseringer (“Replace Conditional With Polymorphism”) og programmeringsidiomer (“Counted pointer”), og de træffes normalt langt senere end strategiske designbeslutninger i softwareudviklingsprocessen.
Og selv om jeg i store træk er enig i den generelle regel om, at globalt = strategisk og lokalt = taktisk, bør den ikke betragtes som absolut. Det er muligt for et segment af et system at have aspekter, der har stor indflydelse på den overordnede arkitektur (hvilket retfærdiggør Boochs kriterier for betydning). Dette er grunden til, at jeg ikke er af den opfattelse, at funktionelle krav er design og ikke-funktionelle krav er arkitektur.
Arnon Rotem-Gal-Oz, arkitekturchef hos Nice Systems, identificerer flere aspekter af arkitektur i sin præsentation “Software Architecture”. Arkitektur omfatter de vigtigste komponenter i et system, deres relationer og interaktioner. Data og adfærd for disse hovedkomponenter er kun relevante for arkitekturen ud fra et synspunkt om interaktionerne mellem disse komponenter. Ligesom Booch karakteriserer Rotem-Gal-Oz arkitekturen som værende de dele af systemet, der er vanskeligst at ændre. Ligesom Eden, Kazman og Hirshfeld definerer han arkitektur som de designbeslutninger, der skal træffes tidligst i processen.
Værdien af strategiske, grundlæggende designbeslutninger burde være indlysende. Da disse aspekter af systemet er både vanskelige og dyre at ændre, bør der være et betydeligt incitament til at træffe optimale valg. Som bemærket af Kevlin Henney i “What is Software Architecture?” på developerFusion:
Spørgsmålet er ikke, om et system har en arkitektur eller ej, men om dets arkitektur er god eller ej. Alle systemer har en arkitektur, uanset om den er tilsigtet eller utilsigtet, eksplicit eller implicit, god eller dårlig – selv systemer uden arkitektur har en arkitektur!
Når vi har sat arkitektur i forbindelse med ændringsomkostningerne, har vi en enkel måde at evaluere arkitektonisk kvalitet på. Det er ikke sådan, at en god arkitektur gør et system billigt at skabe; det er sådan, at det også er billigt at udvikle det. Med andre ord er en god arkitektur en arkitektur, hvor betydningen af designbeslutninger er minimeret. Man kan frit ændre mange aspekter af et system uden at være bange for, at sådanne ændringer er udfordrende, dyre eller skaber en kaskade af fejl. En god arkitektur er derfor en bæredygtig arkitektur.
I betragtning af disse designbeslutningers kritiske betydning giver det ikke meget mening at overlade dem til tilfældighederne. Det er usandsynligt, at en bæredygtig, fleksibel arkitektur opstår organisk. Der vil være behov for tilstrækkelig planlægning og koordinering fra en person i arkitektrollen (uanset om rollen er fuldtids- eller deltidsansat). Lokaliserede designbeslutninger kan derefter træffes inden for denne ramme på en decentraliseret måde.”
Fiktivt hører jeg folk, der stadig rejser det agile mantra mod Big Design/Requirements Up Front. Sagen er, at Agile Manifestet aldrig har sagt, at man bevidst skal begrave hovedet i sandet med hensyn til formålet med systemet. Det var et push-back mod at bruge måneder på analyse uden at der kommer andet end dokumenter ud, men målet var at nå en mellemvej. Ingen har nogensinde sagt “no design up-front” eller “no requirements up-front”.
(Udi Dahan fra “A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function