articuleren ontwerpbeslissingen die de primaire gedrags- en structuureigenschappen van een programma (softwaresysteem) bepalen. Strategische beslissingen hebben betrekking op globale, systeembrede belangen en hebben de meest consequente implicaties. Strategische beslissingen omvatten de keuze van het programmeerparadigma (“objectgeoriënteerd programmeren”), de architectuurstijl (“pijpen en filters”), het toepassingskader (“Microsoft Foundation Classes”), op componenten gebaseerde software-engineeringnormen (“Enterprise JavaBeans”), en ontwerpprincipes (“universele basisklasse”), alsmede veronderstellingen die kunnen leiden tot architectonische mismatch (“de Softbench Broadcast Message Server verwacht dat alle componenten een grafische gebruikersinterface hebben”) en door de wet beheerste regelmatigheden (“elke klasse in het systeem erft van klasse C”). Wegens de gevolgen die zij dragen, moeten de Strategische besluiten vroeg in het softwareontwikkelingsproces worden genomen en zouden uitdrukkelijk moeten worden vastgesteld alvorens enig gedetailleerd ontwerp wordt uitgevoerd.
In tegenstelling daarmee, articuleren de Tactische ontwerpverklaringen ontwerpbesluiten die op een specifieke module betrekking hebben. Tactische beslissingen beschrijven vaak een patroon van correlaties tussen een verzameling modules (objecten, procedures, klassen, enz.) en een andere. Intuïtief gesproken zijn Tactische uitspraken “lokaal” in die zin dat hun bereik beperkt is tot een deel van het programma en niet daarbuiten. Tactische beslissingen omvatten de keuze van ontwerppatronen (“Factory Method”), refactorings (“Replace Conditional With Polymorphism”), en programmeeridioom (“counted pointer”), en worden gewoonlijk veel later genomen dan strategische ontwerpbeslissingen in het software-ontwikkelingsproces.
Hoewel ik het in grote lijnen eens ben met de algemene regel van globaal = strategisch en lokaal = tactisch, moet deze niet als absoluut worden beschouwd. Het is mogelijk dat één segment van een systeem aspecten heeft die de totale architectuur sterk beïnvloeden (hetgeen Boochs criteria voor belangrijkheid rechtvaardigt). Dit is de reden dat ik niet de opvatting huldig dat functionele eisen ontwerp zijn en niet-functionele architectuur.
Arnon Rotem-Gal-Oz, architectuur manager bij Nice Systems, benoemt in zijn presentatie “Software Architectuur” verschillende aspecten van architectuur. Architectuur omvat de belangrijkste componenten van een systeem; hun relaties en interacties. Gegevens en gedrag van deze hoofdcomponenten zijn alleen relevant voor de architectuur vanuit het oogpunt van de interacties tussen deze componenten. Evenals Booch karakteriseert Rotem-Gal-Oz de architectuur als de moeilijkst te veranderen onderdelen van het systeem. Evenals Eden, Kazman, en Hirshfeld, definieert hij de architectuur als de ontwerpbeslissingen die het vroegst in het proces moeten worden genomen.
De waarde van strategische, fundamentele ontwerpbeslissingen zou duidelijk moeten zijn. Aangezien deze aspecten van het systeem zowel moeilijk als kostbaar te veranderen zijn, zou er een aanzienlijke stimulans moeten zijn om optimale keuzes te maken. Zoals Kevlin Henney opmerkt in “What is Software Architecture?” op developerFusion:
Het gaat er niet om of een systeem architectuur heeft of niet, maar of de architectuur goed is of niet. Alle systemen hebben architectuur, opzettelijk of onopzettelijk, expliciet of impliciet, goed of slecht – zelfs “geen architectuur”-systemen hebben architectuur!
Nu we architectuur in verband hebben gebracht met de kosten van verandering, hebben we een eenvoudige manier om de kwaliteit van de architectuur te evalueren. Het is niet zo dat een goede architectuur een systeem goedkoop maakt om te maken; het is zo dat het ook goedkoop is om te evolueren. Met andere woorden, een goede architectuur is een architectuur waarin het belang van ontwerpbeslissingen tot een minimum wordt beperkt. Je bent vrij om veel aspecten van een systeem te veranderen zonder de angst dat zulke veranderingen een uitdaging vormen, duur zijn of een cascade van bugs veroorzaken. Een goede architectuur is daarom een duurzame architectuur.
Gezien de kriticiteit van deze ontwerpbeslissingen, heeft het weinig zin om ze aan het toeval over te laten. Duurzame, flexibele architectuur zal waarschijnlijk niet organisch tot stand komen. Er zal voldoende planning en coördinatie nodig zijn van iemand in de rol van architect (ongeacht of de rol voltijds of deeltijds is). Binnen dat kader kunnen dan decentraal gelokaliseerde ontwerpbeslissingen worden genomen.
Af en toe hoor ik mensen nog steeds de agile mantra opwerpen tegen Big Design/Requirements Up Front. Het Agile Manifest heeft echter nooit gezegd dat je je kop in het zand moet steken als het gaat om het doel van het systeem. Het was een tegendruk tegen maandenlang analyseren zonder dat er iets anders uitkwam dan documenten, maar het doel was om een middenweg te vinden. Niemand heeft ooit gezegd “geen ontwerp vooraf” of “geen vereisten vooraf”.
(Udi Dahan van “A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function