articulează deciziile de proiectare care determină proprietățile comportamentale și structurale primare ale unui program (sistem software). Deciziile strategice abordează preocupări globale, la nivelul întregului sistem și au cele mai multe consecințe. Deciziile strategice includ alegerea paradigmei de programare („programare orientată pe obiecte”), a stilului arhitectural („țevi și filtre”), a cadrului de aplicare („Microsoft Foundation Classes”), a standardelor de inginerie software bazate pe componente („Enterprise JavaBeans”) și a principiilor de proiectare („clasă de bază universală”), precum și a ipotezelor care pot duce la nepotrivire arhitecturală („Softbench Broadcast Message Server se aștepta ca toate componentele să aibă o interfață grafică cu utilizatorul”) și a regularităților guvernate de lege („fiecare clasă din sistem moștenește din clasa C”). Din cauza consecințelor pe care le antrenează, deciziile strategice trebuie luate la începutul procesului de dezvoltare a software-ului și ar trebui stabilite în mod explicit înainte de efectuarea oricărei proiectări detaliate.
În schimb, declarațiile de proiectare tactică articulează deciziile de proiectare care se referă la un modul specific. Deciziile tactice descriu adesea un model de corelații între o colecție de module (obiecte, proceduri, clase etc.) și o alta. Intuitiv vorbind, declarațiile tactice sunt „locale” în sensul că domeniul lor de aplicare este limitat la o anumită parte a programului și nu în afara acestuia. Deciziile tactice includ alegerea modelelor de proiectare („Factory Method”), refactorizările („Replace Conditional With Polymorphism”) și idiomurile de programare („counted pointer”) și, de obicei, sunt luate mult mai târziu decât deciziile strategice de proiectare în procesul de dezvoltare a software-ului.
Deși sunt de acord, în linii mari, cu regula generală de global = strategic și local = tactic, aceasta nu ar trebui să fie considerată un absolut. Este posibil ca un segment al unui sistem să aibă aspecte care influențează puternic arhitectura globală (justificând criteriile de semnificație ale lui Booch). Acesta este motivul pentru care nu sunt de părere că cerințele funcționale sunt proiectare și cele nefuncționale sunt arhitectură.
Arnon Rotem-Gal-Oz, manager de arhitectură la Nice Systems, identifică mai multe aspecte ale arhitecturii în prezentarea sa „Software Architecture”. Arhitectura cuprinde componentele majore ale unui sistem; relațiile și interacțiunile acestora. Datele și comportamentul acestor componente majore sunt relevante pentru arhitectură doar din punctul de vedere al interacțiunilor dintre aceste componente. Ca și Booch, Rotem-Gal-Oz caracterizează arhitectura ca fiind cele mai greu de schimbat părți ale sistemului. La fel ca Eden, Kazman și Hirshfeld, el definește arhitectura ca fiind deciziile de proiectare care trebuie luate cel mai devreme în proces.
Valoarea deciziilor de proiectare strategică, fundamentală, ar trebui să fie evidentă. Deoarece aceste aspecte ale sistemului sunt atât dificil și costisitor de schimbat, ar trebui să existe un stimulent considerabil pentru a face alegeri optime. După cum notează Kevlin Henney în „What is Software Architecture?” pe developerFusion:
Problema nu este dacă un sistem are sau nu arhitectură, ci dacă arhitectura sa este bună sau nu. Toate sistemele au arhitectură, fie că este intenționată sau accidentală, explicită sau implicită, bună sau rea – chiar și sistemele „fără arhitectură” au arhitectură!
După ce am corelat arhitectura cu costul schimbării, avem un mod simplu de a evalua calitatea arhitecturii. Nu înseamnă că o arhitectură bună face ca un sistem să fie ieftin de creat; înseamnă că este, de asemenea, ieftin de evoluat. Cu alte cuvinte, o arhitectură bună este cea în care importanța deciziilor de proiectare este minimizată. Aveți libertatea de a schimba multe aspecte ale unui sistem fără teama că astfel de schimbări sunt dificile, costisitoare sau creează o cascadă de erori. O arhitectură bună este, prin urmare, una durabilă.
Datorită criticii acestor decizii de proiectare, nu prea are sens să le lăsăm la voia întâmplării. Este puțin probabil ca arhitectura durabilă și flexibilă să apară organic. Va fi necesară o planificare și o coordonare suficientă din partea unei persoane cu rol de arhitect (indiferent dacă acest rol este cu normă întreagă sau cu jumătate de normă). Deciziile de proiectare localizate pot fi apoi luate în acest cadru într-o manieră descentralizată.
Ocazional aud oameni care încă mai ridică mantra agile împotriva Big Design/Requirements Up Front. Chestia este că Manifestul Agile nu a spus niciodată să îți îngropi intenționat capul în nisip în ceea ce privește scopul sistemului. A fost o împotrivire față de a petrece luni întregi în analiză fără să iasă nimic altceva decât documente, dar scopul era să se ajungă la o cale de mijloc. Nimeni nu a spus niciodată „fără design în față” sau „fără cerințe în față”.
(Udi Dahan din „A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function
(Forma urmează funcția)