a program (szoftverrendszer) elsődleges viselkedési és szerkezeti tulajdonságait meghatározó tervezési döntéseket fogalmazza meg. A stratégiai döntések globális, a rendszer egészét érintő kérdésekkel foglalkoznak, és a legkövetkezetesebb következményekkel járnak. A stratégiai döntések közé tartozik a programozási paradigma (“objektumorientált programozás”), az architekturális stílus (“csövek és szűrők”), az alkalmazási keretrendszer (“Microsoft Foundation Classes”), a komponensalapú szoftverfejlesztési szabványok (“Enterprise JavaBeans”) és a tervezési elvek (“univerzális alaposztály”) kiválasztása, valamint olyan feltételezések, amelyek architekturális eltérésekhez vezethetnek (“A Softbench Broadcast Message Server elvárta, hogy minden komponensnek legyen grafikus felhasználói felülete”) és törvényszerűségek (“a rendszerben minden osztály a C osztályból örököl”). Az általuk hordozott következmények miatt a stratégiai döntéseket a szoftverfejlesztési folyamat korai szakaszában kell meghozni, és kifejezetten meg kell határozni, mielőtt bármilyen részletes tervezésre sor kerülne.
Ezzel szemben a taktikai tervezési utasítások olyan tervezési döntéseket fogalmaznak meg, amelyek egy adott modulra vonatkoznak. A taktikai döntések gyakran a modulok (objektumok, eljárások, osztályok stb.) egy csoportja és egy másik csoportja közötti összefüggések mintáját írják le. Intuitív értelemben a taktikai utasítások “lokálisak” abban az értelemben, hogy hatókörük a program egy bizonyos részére korlátozódik, nem pedig azon kívülre. A taktikai döntések közé tartozik a tervezési minták (“Factory Method”), a refaktorálások (“Replace Conditional With Polymorphism”) és a programozási idiómák (“counted pointer”) kiválasztása, és általában sokkal később születnek, mint a stratégiai tervezési döntések a szoftverfejlesztési folyamatban.
Noha nagyjából egyetértek a globális = stratégiai és a helyi = taktikai általános szabállyal, azt nem szabad abszolútnak tekinteni. Lehetséges, hogy egy rendszer egy szegmense olyan szempontokkal rendelkezik, amelyek erősen befolyásolják a teljes architektúrát (ami igazolja Booch jelentőségi kritériumait). Ez az oka annak, hogy nem tartom azt a véleményt, hogy a funkcionális követelmények a tervezés, a nem funkcionálisak pedig az architektúra.”
Arnon Rotem-Gal-Oz, a Nice Systems architektúra menedzsere “Software Architecture” című előadásában az architektúra számos aspektusát azonosítja. Az architektúra magában foglalja a rendszer fő komponenseit; azok kapcsolatait és kölcsönhatásait. E fő komponensek adatai és viselkedése csak a komponensek közötti kölcsönhatások szempontjából releváns az architektúra szempontjából. Boochhoz hasonlóan Rotem-Gal-Oz is úgy jellemzi az architektúrát, mint a rendszer legnehezebben megváltoztatható részeit. Edenhez, Kazmanhoz és Hirshfeldhez hasonlóan ő is úgy definiálja az architektúrát, mint azokat a tervezési döntéseket, amelyeket a folyamat legkorábban kell meghozni.
A stratégiai, alapvető tervezési döntések értékének nyilvánvalónak kell lennie. Mivel a rendszer ezen aspektusait nehéz és költséges megváltoztatni, jelentős ösztönzőnek kell lennie az optimális döntések meghozatalára. Ahogy Kevlin Henney megjegyezte a developerFusion-on a “What is Software Architecture?” című cikkében:
A kérdés nem az, hogy egy rendszernek van-e architektúrája, hanem az, hogy az architektúrája jó-e vagy sem. Minden rendszernek van architektúrája, legyen az szándékos vagy véletlen, explicit vagy implicit, jó vagy rossz – még az “architektúra nélküli” rendszereknek is van architektúrája!
Az architektúra és a változtatás költségeinek összekapcsolásával egyszerű módunk van az architektúra minőségének értékelésére. Nem arról van szó, hogy a jó architektúra olcsóbbá teszi a rendszer létrehozását; hanem arról, hogy a rendszer fejlesztése is olcsó. Más szóval, a jó architektúra az, amelyben a tervezési döntések jelentősége minimálisra csökken. A rendszer számos aspektusát szabadon megváltoztathatjuk anélkül, hogy attól kellene tartanunk, hogy az ilyen változtatások kihívást jelentenek, költségesek vagy hibák kaszkádját idézik elő. A jó architektúra ezért fenntartható.
A tervezési döntések kritikusságát tekintve nincs sok értelme a véletlenre bízni őket. A fenntartható, rugalmas építészet valószínűleg nem alakul ki organikusan. Elegendő tervezésre és koordinációra lesz szükség az építész szerepét betöltő valakitől (függetlenül attól, hogy a szerep teljes vagy részmunkaidős). A lokális tervezési döntéseket aztán ezen a kereten belül decentralizált módon lehet meghozni.
Egyszer hallom, hogy az emberek még mindig az agilis mantrát emlegetik a Big Design/Requirements Up Front ellen. A helyzet az, hogy az Agilis Kiáltvány soha nem mondta, hogy szándékosan dugjuk homokba a fejünket a rendszer célját illetően. Ez egy visszalökés volt az ellen, hogy hónapokat töltsünk elemzéssel anélkül, hogy bármi más, csak dokumentumok jönnének ki, de a cél az volt, hogy egy középutat érjünk el. Soha senki nem mondta, hogy “nincs tervezés előre” vagy “nincsenek követelmények előre”.
(Udi Dahan from “A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function