artikulerar designbeslut som bestämmer de primära beteendemässiga och strukturella egenskaperna hos ett program (programvarusystem). Strategiska beslut behandlar globala, systemövergripande frågor och har de mest omfattande konsekvenserna. Strategiska beslut omfattar valet av programmeringsparadigm (”objektorienterad programmering”), arkitektonisk stil (”pipes and filters”), tillämpningsram (”Microsoft Foundation Classes”), komponentbaserade standarder för programvaruteknik (”Enterprise JavaBeans”) och designprinciper (”universell basklass”), liksom antaganden som kan leda till arkitektonisk missmatchning (”Softbench Broadcast Message Server förväntade sig att alla komponenter skulle ha ett grafiskt användargränssnitt”) och lagstyrda regelbundenheter (”alla klasser i systemet ärver från klass C”). På grund av de konsekvenser de medför måste strategiska beslut fattas tidigt i mjukvaruutvecklingsprocessen och bör fastställas explicit innan någon detaljerad design utförs.
I motsats till detta artikulerar taktiska designuttalanden designbeslut som rör en specifik modul. Taktiska beslut beskriver ofta ett mönster av korrelationer mellan en samling moduler (objekt, procedurer, klasser etc.) och en annan. Intuitivt sett är Tactical statements ”lokala” i den meningen att deras räckvidd är begränsad till en viss del av programmet och inte utanför det. Taktiska beslut omfattar valet av designmönster (”Factory Method”), refaktoriseringar (”Replace Conditional With Polymorphism”) och programmeringsidiom (”Counted pointer”), och fattas vanligen mycket senare än strategiska designbeslut i programvaruutvecklingsprocessen.
Och även om jag i stort sett håller med om den allmänna regeln om att globalt = strategiskt och lokalt = taktiskt, bör den inte betraktas som en absolut regel. Det är möjligt att ett segment av ett system har aspekter som starkt påverkar den övergripande arkitekturen (vilket motiverar Boochs kriterier för betydelse). Detta är anledningen till att jag inte anser att funktionella krav är design och icke-funktionella är arkitektur.
Arnon Rotem-Gal-Oz, arkitekturansvarig på Nice Systems, identifierar flera aspekter av arkitektur i sin presentation ”Software Architecture”. Arkitektur omfattar de viktigaste komponenterna i ett system, deras relationer och interaktioner. Data och beteende hos dessa huvudkomponenter är endast relevanta för arkitekturen ur synvinkeln av samspelet mellan dessa komponenter. Liksom Booch karakteriserar Rotem-Gal-Oz arkitekturen som de svåraste delarna av systemet att ändra. Liksom Eden, Kazman och Hirshfeld definierar han arkitektur som de designbeslut som måste fattas tidigast i processen.
Värdet av strategiska, grundläggande designbeslut borde vara uppenbart. Eftersom dessa aspekter av systemet är både svåra och kostsamma att ändra bör det finnas betydande incitament för att göra optimala val. Som Kevlin Henney påpekar i ”What is Software Architecture?” på developerFusion:
Frågan är inte om ett system har en arkitektur eller inte, utan om dess arkitektur är bra eller inte. Alla system har en arkitektur, vare sig den är avsiktlig eller oavsiktlig, uttalad eller underförstådd, bra eller dålig – även system som inte har någon arkitektur har en arkitektur!
När vi har relaterat arkitektur till förändringskostnader har vi ett enkelt sätt att utvärdera arkitektonisk kvalitet. Det är inte så att en bra arkitektur gör det billigt att skapa ett system, utan att det också är billigt att utveckla det. Med andra ord är en bra arkitektur en arkitektur där betydelsen av designbeslut minimeras. Det är fritt fram att ändra många aspekter av ett system utan att behöva vara rädd för att sådana ändringar är utmanande, kostsamma eller skapar en kaskad av buggar. En bra arkitektur är därför hållbar.
Med tanke på hur kritiska dessa konstruktionsbeslut är är det föga meningsfullt att lämna dem åt slumpen. Det är osannolikt att hållbar, flexibel arkitektur uppstår organiskt. Det kommer att krävas tillräcklig planering och samordning från någon i arkitektrollen (oavsett om rollen är på hel- eller deltid). Lokaliserade designbeslut kan sedan fattas inom detta ramverk på ett decentraliserat sätt.
Enstaka gånger hör jag människor som fortfarande lyfter fram det agila mantrat mot Big Design/Requirements Up Front. Saken är den att Agile Manifesto aldrig sa att man medvetet ska sticka huvudet i sanden när det gäller systemets syfte. Det var en push-back mot att spendera månader i analys utan att något annat än dokument kommer ut, men målet var att nå en medelväg. Ingen har någonsin sagt ”ingen design up-front” eller ”inga krav up-front”.
(Udi Dahan från ”A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function