decyzje projektowe, które określają podstawowe właściwości behawioralne i strukturalne programu (systemu oprogramowania). Decyzje strategiczne odnoszą się do globalnych, ogólnosystemowych problemów i niosą ze sobą najbardziej konsekwentne implikacje. Decyzje strategiczne obejmują wybór paradygmatu programowania („programowanie obiektowe”), stylu architektonicznego („rury i filtry”), frameworka aplikacji („Microsoft Foundation Classes”), standardów inżynierii oprogramowania opartych na komponentach („Enterprise JavaBeans”) i zasad projektowania („uniwersalna klasa bazowa”), jak również założenia, które mogą prowadzić do niedopasowania architektonicznego („Serwer Softbench Broadcast Message Server oczekiwał, że wszystkie komponenty będą miały graficzny interfejs użytkownika”) i prawidłowości rządzących prawem („każda klasa w systemie dziedziczy po klasie C”). Ze względu na konsekwencje, jakie ze sobą niosą, decyzje strategiczne muszą być podejmowane na wczesnym etapie procesu tworzenia oprogramowania i powinny być ustalone explicite, zanim zostanie wykonany jakikolwiek szczegółowy projekt.
Z kolei taktyczne deklaracje projektowe artykułują decyzje projektowe, które dotyczą konkretnego modułu. Decyzje taktyczne często opisują wzorzec korelacji między jednym zbiorem modułów (obiektów, procedur, klas itp.) a innym. Intuicyjnie rzecz biorąc, deklaracje taktyczne są „lokalne” w tym sensie, że ich zakres jest ograniczony do pewnej części programu, a nie poza nią. Decyzje taktyczne obejmują wybór wzorców projektowych („Factory Method”), refaktoryzację („Replace Conditional With Polymorphism”) i idiomy programistyczne („counted pointer”), i zazwyczaj są podejmowane znacznie później niż strategiczne decyzje projektowe w procesie tworzenia oprogramowania.
Although I broadly agree with the general rule of global = strategic and local = tactical, it should not be considered an absolute. Jest możliwe, aby jeden segment systemu miał aspekty, które silnie wpływają na ogólną architekturę (uzasadniając kryteria istotności Boocha). Jest to powód, dla którego nie wyznaję poglądu, że wymagania funkcjonalne to projekt, a niefunkcjonalne to architektura.
Arnon Rotem-Gal-Oz, kierownik ds. architektury w Nice Systems, identyfikuje kilka aspektów architektury w swojej prezentacji „Architektura oprogramowania”. Architektura obejmuje główne komponenty systemu, ich relacje i interakcje. Dane i zachowanie tych głównych komponentów są istotne dla architektury tylko z punktu widzenia interakcji między tymi komponentami. Podobnie jak Booch, Rotem-Gal-Oz charakteryzuje architekturę jako najtrudniejszą do zmiany część systemu. Podobnie jak Eden, Kazman i Hirshfeld, definiuje architekturę jako decyzje projektowe, które muszą być podjęte najwcześniej w procesie.
Wartość strategicznych, fundamentalnych decyzji projektowych powinna być oczywista. Ponieważ te aspekty systemu są zarówno trudne, jak i kosztowne do zmiany, powinna istnieć znacząca zachęta do dokonywania optymalnych wyborów. Jak zauważył Kevlin Henney w „What is Software Architecture?” na developerFusion:
Problemem nie jest to, czy system ma architekturę, czy nie, ale czy jego architektura jest dobra, czy nie. Wszystkie systemy mają architekturę, zamierzoną lub przypadkową, wyraźną lub ukrytą, dobrą lub złą – nawet systemy „bez architektury” mają architekturę!
Po powiązaniu architektury z kosztem zmiany, mamy prosty sposób na ocenę jakości architektury. Nie chodzi o to, że dobra architektura sprawia, że system jest tani w tworzeniu; chodzi o to, że jest również tani w ewolucji. Innymi słowy, dobra architektura to taka, w której znaczenie decyzji projektowych jest zminimalizowane. Można swobodnie zmieniać wiele aspektów systemu bez obawy, że takie zmiany będą wymagające, kosztowne lub stworzą kaskadę błędów. Dobra architektura jest zatem zrównoważona.
Zważywszy na krytyczność tych decyzji projektowych, nie ma sensu pozostawiać ich przypadkowi. Zrównoważona, elastyczna architektura raczej nie powstanie w sposób organiczny. Konieczne będzie odpowiednie planowanie i koordynacja ze strony osoby pełniącej rolę architekta (niezależnie od tego, czy jest to rola pełnoetatowa czy niepełnoetatowa). Lokalne decyzje projektowe mogą być następnie podejmowane w tych ramach w sposób zdecentralizowany.
Od czasu do czasu słyszę ludzi wciąż podnoszących mantrę agile przeciwko Big Design/Wymaganiom z góry. Rzecz w tym, że Agile Manifesto nigdy nie powiedział, aby celowo chować głowę w piasek w odniesieniu do celu systemu. Był to odwrót od spędzania miesięcy na analizach, z których nie wychodzi nic poza dokumentami, ale celem było osiągnięcie środkowej płaszczyzny. Nikt nigdy nie powiedział „żadnego projektowania z góry” lub „żadnych wymagań z góry”.
(Udi Dahan z „A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function