Task: Návrh architektury

Identifikování cílů architektury

Úloha návrh architektury by měla být provedena prostřednictvím několika dílčích kroků, přičemž prvním z nich je identifikace cílů architektury. Architekt by měl neustále spolupracovat se zbytkem projektového týmu a s jeho pomocí identifikovat cíle a požadavky, které by měla architektura řešení podpořit. Pro každou iteraci by měly být vybrány ty, jejichž implementace má nejvyšší prioritu.

Nalezení omezení architektury

Zároveň je nutné identifikovat i omezení, která musí zvolené architektonické řešení respektovat. Specifikováno by mělo být, i jakým způsobem budou tato omezení respektována, přičemž veškerá rozhodnutím musí být řádně odůvodněna. Seznam omezení by měl být pravidelně revidován, aby nedošlo opomenutí žádného z nově identifikovaných faktorů.

Identifikování klíčových abstrakcí a jejich vztahů

Dalším z dílčích kroků při návrhu architektury je identifikace klíčových abstrakcí a jejich vztahů. Abstrakce, označované spíše jako tzv. byznys třídy, jsou objekty, na základě kterých je možné modelovat problémovou doménu vyvíjeného softwarového systému a které by měly jednoznačně označovat určitý pojem reálného obchodního světa, jako je například zákazník, objednávka apod. Jedná se tedy v podstatě o vytvoření prvotního konceptuálního (doménového, analytického) modelu tříd. [Arlow, 2008] [Rejnková, 2009]

Určení možností znovupoužití

V rámci návrhu architektury by měly být dále identifikovány možnosti znovupoužití již existujících komponent, aplikací apod. Znovupoužití je jednou z důležitých předností softwarového vývoje, kterým je možné ušetřit nejen práci ale i celkové náklady na vývoj. Především objektově orientované jazyky nabízejí řadu prostředků podporujících znovupoužití, nicméně klíčová je z tohoto hlediska zejména identifikace prvků, které je možné opakovaně použít, která je prováděná zkušenými architekty a vývojáři.

Rozčlenění systému do dílčích částí

Dalším z dílčích kroků návrhu architektury je definice přístupu k rozčlenění vyvíjeného systému do dílčích částí, což snižuje komplexnost a usnadňuje jeho vývoj. Kromě vymezení jednotlivých částí je také vhodné navrhnout harmonogram, na základě kterého budou jednotlivé části implementovány a integrovány. Pokud je to nutné, měla být upravena strategie nasazení jednotlivých částí a integrovaného řešení do provozu, která je popisována v Konfiguračním plánu.

Definice rozhraní

Dále je nutné definovat veškerá rozhraní, kterými by měl systém disponovat, aby byl schopen komunikovat se všemi požadovanými externími systémy. Nejdříve by v rámci tohoto dílčího kroku mělo proběhnout základní zmapování externích systémů, na které by měla navazovat vlastní definice rozhraní. Jejich popis nemusí být příliš podrobný a měl by být zaměřen především a na informace, které jsou prostřednictvím rozhraní předávány.

Popis architektonických mechanismů

Součástí návrhu architektury by měla být i identifikace a stručný popis základních architektonických mechanismů, respektive technických služeb, které by systém měl poskytovat, jako je např. řízení transakcí, zálohování dat apod. Nejprve by měl být vytvořen jednoduchý seznam těchto mechanismů, které jsou stručně charakterizovány, bez toho aby bylo popisováno, jakým způsobem budou implementovány. Architektonické mechanismy mohou být určeny buď přímo, na základě zkušeností s určitým typem řešení, nebo mohou být odvozeny z detailních, obvykle nefunkcionálních, požadavků (jako je výkon nebo bezpečnost) na vyvíjené řešení.

Ověření vzájemné konzistence prvků architektury

Potom, co jsou navrženy jednotlivé prvky architektury, je nutné ověřit jejich vzájemnou konzistenci, přičemž hlavní pozornost by měla být věnována tomu, zda podporují veškeré požadavky na vyvíjený softwarový systém. Závěrečné zhodnocení by mělo být prováděno celým projektovým týmem a mělo by vycházet z vypracovaného Popisu architektury.