V roce 2008 vyšel český překlad velmi zajímavé knihy
věnované správě softwarových požadavků: "Požadavky
na software" Originál vydal Microsoft Press,
český překlad vydal Computer Press. Na tuto
knihu jsem si vzpomněl, když jsem se začetl do knihy
dvojice autorů Petera Eeles a Petere Crippse „Softwarová
architektura“. Obě pojednávají na téma vývoj
softwaru. Jedna akcentuje zejména vývoj a správu
požadavků, druhá akcentuje proces a postupy
navrhování softwaru. Obě se vyznačují vyváženou
kombinací teorie a praxe, s jasným zaměřením na
pomoc při praktickém projektování softwarových
systémů. Obě jsou psány srozumitelným jazykem, jsou
bohaté na postupy a metody, obě zdůrazňují procesní
přístup. Troufnu si říci, že by obě patřily do
povinné literatury pro řadu profesů z oblasti ICT
a její implementace v businessu.
-
Knihu napsali velmi zkušení autoři:
Peter Eeles
působí v softwarovém průmyslu od roku 1985. Je
vedoucím IT architektem, ve své funkci pomáhá firmám
zlepšovat jejich procesy při vývoji softwaru,
přičemž se zaměřuje a zajímá především o proces
navrhování. Má za sebou poměrně bohatou autorskou
činnost.
Peter Cripps
je IT architektem. Během své kariéry pracoval jako
programátor, softwarový inženýr a procesní inženýr v
mnoha odvětvích. Do oblasti jeho zájmů patří
především návrh postupů pro vývoj dobré softwarové
architektury.
Kniha se zaměřuje na ty úkoly, související
s architekturou, s nimiž se může čtenář setkat
poměrně často a které může použít v mnoha různých
typech organizací, obchodních oblastí, systémů apod.
Obsah:
- Úvod do architektury softwaru
- Architektura, Architekt, Navrhování
- Základy metody
- Dokumentace architektury softwaru
- Opětovně použitelné prvky architektury
- Úvod do případové studie
- Definice požadavků
- Tvorba logické architektury
- Tvorba fyzické architektury
- Za hranicemi základů
- PŘÍLOHA A - Metamodel architektury softwaru
- PŘÍLOHA B - Katalog hledisek
- PŘÍLOHA C - Přehled metody
- PŘÍLOHA D - Kontrolní seznam požadavků na
architekturu
- Přehled pojmů
Podtitulek knihy zní: „ Nepostradatelný průvodce
návrhem softwarové architektury, která funguje“. Kniha
je dobrým rádcem ve všech fázích procesu, jehož
cílem je vývoj softwaru. Dozvíte se, co je
architektura softwaru, jak se projevuje, kdo ji dělá
a jaké jsou její vazby na další části projektů.
Základní orientace autorů, je zaměřena na
zkoumání metody navrhování. Při tom využívají
zejména modelový přístup.
Překlenutí mezery mezi logickou a fyzickou
architekturou systému při výkladu systému, je
pro mnohé autory z dané oblasti obtížným a ne vždy
úspěšně řešeným problémem. O to více si bude čtenář
knihy „Architektura softwaru“ vážit autory zvoleného
přístupu, který v sobě spojuje teoretickou a
praktickou část problému.
Autoři zvolili optimální vztah mezi podrobností
výkladu a jeho srozumitelností. Díky tomu se jim
podařilo vytvořit úplný obrázek architektury
systému. K nejcennějším částem knihy patří
komplexní pohled na roli architekta softwaru,
případně celého týmu architektury systému.
Tato kniha je pozoruhodná zejména tím, že – aniž by
ignorovala teorii – její těžiště leží
v praktických návodech, orientovaných na
navrhování softwaru. Návody a postupy prezentují
autoři formou, která umožňuje jejich okamžité
využití v praktické činnosti. Autoři staví na
svých bohatých zkušenostech v oblasti vývoje
softwaru. Na základě dobře zvolené a systémově
prezentované případové studie, autoři
ilustrují praktické využití myšlenek prezentovaných
v jednotlivých kapitolách knihy.
Existuje řada knih, popisujících určité aspekty
procesu navrhování softwaru. Některé z těchto knih
se věnují například dokumentování architektury
softwaru, jiné zase jejímu vyhodnocování. Každý z
těchto aspektů zapadá do většího celku, neboť
každý z nich představuje důležitý prvek procesu
navrhování softwaru. Jedním z cílů knihy
autorské dvojice P.Eelese a P. Crippse je ukázat
tento větší celek, a to pomocí konsolidovaného
pohledu na všechny aspekty navrhování v kontextu
typického projektu vývoje softwaru.
Autoři sami zdůrazňují, že jejich kniha
nepředepisuje žádný konkrétní způsob pro vývoj
softwaru. Namísto toho popisuje klíčové prvky, s
nimiž se setkáváme v kterémkoliv moderním vývojovém
prostředí v rámci podpory procesu návrhu.
Tato kniha je určena především softwarovým
architektům (či těm, kteří se jimi chtějí stát),
snažícím se pochopit to, jak jejich role zapadá do
celého procesu vývoje softwaru. Může však být
užitečná i pro
specializované
architekty. Vzhledem k zvolenému přístupu prezentace
poznatků, může knihu využít každý, kdo chce
lépe pochopit roli softwarového architekta. Prostudování
knihy může být přínosem pro všechny členy
vývojového týmu, včetně vývojářů samotných, testerů,
business analytiků, projektových manažerů, manažerů
konfigurace a procesních inženýrů. Knihu ocení i
studenti a pedagogové, kteří chtějí získat představu
o rostoucím roli softwarových architektů během
procesu vývoje softwaru.
Kniha může být přínosem pro každého, kdo chce
navrhovat
lepší software,
kdo cítí potřebu prověřit a
zdokonalit základy architektury navrženého projektu
a kdo se che naučit navrhovat architekturu, která se
stane základem úspěšného projektu.
Dvojice autorů nám nabízí
základní postupy nutné pro správný návrh softwarové
architektury a proces tvorby dokumentace a
znovupoužitelných prvků architektury.
Kniha je zhruba rozdělena do tří částí.
První část
je tvořená kapitolami 1 až 5, obsahujícími souhrnný
přehled základních konceptů architektury, roli
architekta a postupy navrhování, dokumentování
architektury softwaru a opakovaně použitelných prvků
architektury.
Druhá část
sestává z kapitol 6 až 9 a její hlavní náplní jsou
kapitoly,
související s případovou studií.
Tyto kapitoly nás na základě ukázkové aplikace
provázejí vhodně vybraným typickým projektem vývoje
softwaru, přičemž naše pozornost je směrována
především k roli architekta. Zvolený přístup výkladu
obsahu těchto kapitol nám umožňuje rychlé čtení a
snadné vyhledání těch témat, která nás zajímají.
Každá kapitola, související s případovou studií, je
uspořádána podle úkolů a činností
V poslední části knihy nacházíme kapitolu 10,
obsahující různá dílčí témata, Zabývají se možnostmi
využití konceptů, popsaných v předcházejících
kapitolách, při navrhování složitých systémů.
V případové studii se autoři zaměřili na roli
architekta
v procesu vzniku softwaru a na obvyklé problémy,
které tento proces mohou provázet. Knihu uzavírá
soubor univerzálních postupů, které lze aplikovat na
většinu dnes vznikajících složitých systémů.
Kniha je
cenným zdrojem informací nejen pro
softwarové architekty, hodnotné informace v ní
najdou i projektoví manažeři, vedoucí vývojových
týmů, programátoři, testeři a analytici.
V knize se čtenář naučí:
- znát vazby architektury na další části
softwarového projektu
- zvládnout roli architekta v typickém projektu
vývoje softwaru
- přesně navrhnout architekturu na základě požadavků
- nasazovat opětovně použitelné prvky architektury
- vytvářet dokumentaci architektury pro další
zainteresované strany
- spolupracovat s dalšími členy vývojového týmu
Vydání této knihy bylo provázeno zpřístupněním
webové stránky:
http://processsoftwarearchitecting.com
na které čtenáři najdou dodatečné informace a jejímž
prostřednictvím mohou i komunikovat s autory.
Stránka je spravována jedním z autorů knihy.
Na webu CPressu (
www.cpress.cz
) najdete nejen výstižnou anotaci knihy, ale
i její podrobný obsah, kopii úvodu ke knize a
vhodně vybranou ukázkovou kapitolu s názvem
„Základy metody“.
Podrobnější charakteristika knihy
Kniha je pozoruhodná nejen svým obsahem, ale i
přístupem k tématu. Ve svaze o přiblížení přístupu
autorů, jsem zvolil kombinaci vlastního hodnocení a
volné citace z textu knihy
Účelem první kapitoly je seznámit čtenáře
s tématy, rozebíranými v následujících částech
knihy.
V druhé kapitole, ještě než se ponoří do
rozboru detailů, se autoři snaží ujasnit (či
definovat) některé základní koncepty, s nimiž
pracují ve zbývajících částech knihy. Těmito
koncepty jsou role architekta, vlastnosti
jednotlivých úloh navrhování, které architekt
provádí, a výsledná architektura. V textu druhé
kapitoly se seznámíme s třemi základními koncepty,
vztahujícími se k tématu této knihy. V závěru
nacházíme pojednání o přínosech navrhování.
Zmíněnými třemi koncepty jsou role architekta,
vlastnosti jednotlivých úloh navrhování, které
architekt provádí, a výsledná architektura.
Role architekta představuje v každém projektu
vývoje softwaru tu největší výzvu. Architekta
považují autoři knihy za technického vedoucího
projektu a z technického hlediska také nese
odpovědnost za technický úspěch či neúspěch celého
projektu.
Velkou pozornost věnují autoři metamodelu
architektury softwaru.
Úplný popis metamodelu, používaného v této knize,
prezentují autoři v příloze A.
Vztahy v tomto metamodelu
zobrazují autoři ve schématu a slovně je vyjadřují
takto:
- Systém má architekturu.
- Systém plní jeden či více cílů.
- Systém má jednoho či více investorů.
- Systém existuje v nějakém prostředí.
- Prostředí ovlivňuje systém.
- Architektura je popsána popisem architektury.
- Popis architektury identifikuje jednoho či více
investorů.
- Popis architektury identifikuje jeden či více
zájmů.
- Popis architektury obsahuje základ.
- Investor má jeden či více zájmů.
- Zájem je důležitý pro jednoho či více investorů.
Tyto hlavní vztahy doplňují autoři dalšími,
vedlejšími vztahy:
- Vývojový projekt je řešen týmem.
- Vývojový projekt následuje vývojový proces.
- Vývojový projekt vyvíjí systém.
- Vývojový proces obsahuje navrhování.
- Firma obsahuje architekta.
- Architekt provádí navrhování.
- Architekt vytváří architekturu.
- Architekt je určitým druhem investora.
- Výsledkem navrhování je architektura.
- Základ odůvodňuje jedno či více rozhodnutí o
architektuře.
- Rozhodnutí o architektuře odpovídá na jeden či
více zájmů.
Navrhování softwaru považují autoři za uznávanou
vědní disciplínu, byť se stále ještě vyvíjí. S tímto
uznáním přichází také důraz na postupy, procesy a
prvky, zaměřený na zvýšení zralosti procesu
navrhování. Jedním z možných způsobů rychlého
zvýšení zralosti je čerpání z již existujících
znalostí. Ačkoliv navrhování softwaru považují
autoři za vědu, vždy je nutné v tomto procesu
vynaložit určitý stupeň kreativity, což je
obzvláště pravdivé ve chvíli, kdy před vámi stojí
úkol navrhnout architekturu pro nějaký zcela nový
systém, pro který dosud neexistuje žádný vzor.
Podle autorů platí, že proces navrhování hraje
klíčovou roli při snižování nákladů, zvyšování
kvality, zajištění včasné dodávky, zajištění dodávky
odpovídající požadavkům a snižování rizik.
- Navrhování řeší otázku systémových kvalit
- Navrhování vede ke shodě
- Navrhování podporuje proces plánování
- Navrhování umožňuje zachování integrity návrhu
- Navrhování pomáhá řídit složitost
- Navrhování vytváří základ pro opětovnou
použitelnost
- Navrhování snižuje náklady na údržbu
- Navrhování podporuje analýzu dopadu
Navrhování architektury softwaru pokrývá mnoho
disciplín
Autoři zdůrazňují skutečnost, že se architekt se
vedle navrhování účastní také mnoha dalších
aspektů vývojového procesu softwaru. V knize se
uvádí následujícíc:
- Architekt se podílí na formulaci požadavků, čímž
například zajišťuje zachycení těch požadavku, které
mají pro architekta zvláštní význam.
- Architekt se účastní procesu prioritizace
požadavků.
- Architekt se účastní implementace, definuje
struktury implementace, které budou použity pro
uspořádání jak zdrojového kódu, tak i výsledných
spustitelných produktů.
- Architekt se účastní testování, čímž si ověří to,
že jím navržená architektura je jak testovatelná,
tak i otestována.
- Architekt je odpovědný za určité prvky vývojového
prostředí, a to především z hlediska definice
určitých standardů a směrnic projektu.
- Architekt pomáhá při definici strategie řízení
konfigurace, neboť struktury řízení konfigurace
^odporující správu verzí) často odrážejí definovanou
architekturu.
Druhá kapitola definuje a vysvětluje
základní koncepty, používané v dalších částech
této knihy: architekturu, architekta a navrhování.
Autoři odpovídají na otázky: co je výsledkem
práce architekta a jaký je vztah role architekta
k ostatním rolím, účastnicím se projektu. Po
definici základních konceptů přesouvá se v knize
pozornost k jejich využití v rámci celého procesu
vývoje softwaru. To je předmětem třetí
kapitoly, nazvané „Základy metody“. Osnova
kapitoly je stručná ( klíčové koncepty, obsah metody
a proces ), ale obsah je bohatý. Třetí kapitola je
v plném znění nabízena ke stažení na webu knihy na
CPressu.
Hlavním cílem třetí kapitoly je nabídnout
přehled klíčových prvků metody, z nichž kniha
vychází. Tato kapitola je základem pro kapitoly
zbývající, neboť v nich se staví na těchto
konceptech. Přehled prvků metody, najdeme v příloze
C „Přehled metody“.
Svoji pozornost přesouvají autoři k aplikaci
obsahu metody, a to z hlediska posloupnosti,
v níž jsou jednotlivé úkoly prováděny. Obsahem
metody se míní role, výsledky práce a úkoly,
tvořící příslušnou metodu. Autoři se postupně
věnují všem třem prvkům obsahu.
Mnohé z rozdílů mezi jednotlivými metodami,
používanými v softwarovém průmyslu, se týkají
především procesu, podle kterého se postupuje,
nikoliv rolí, výsledků práce, činností a prováděných
úkolů. Autoři věnují se věnují postupně všem
třem typům procesu, označovaným jako sériový
proces (proces vodopádu), iterativní proces a agilní
proces. Je zdůrazněn rozdíl mezi obsahem metody
a procesy stanovujícími tento obsah.
Následující dvě kapitoly – kapitola 4
„Dokumentace architektury softwaru“ a
kapitola 5 „Opětovně použitelné prvky architektury“
– se zaměřují na specifické aspekty metody,
zaručující důkladnější a podrobnější diskuzi a
prostupující celým životním cyklem projektu.
Čtvrtá kapitola je věnována dokumentaci
architektury. Za základní smysle dokumentace
architektury softwaru je podle autorů umožnit
komunikaci o vytvořené architektuře. Taková
komunikace je nezbytná především proto, aby
všichni účastníci navržené architektuře porozuměli a
mohli včas přijít se svými připomínkami. Díky ní
může mít celý vývojový tým konzistentní náhled na
vytvářený systém. Čtvrtá kapitola je přednostně
věnována pojednání o různých aspektech popisu
architektury softwaru. Klíčovými koncepty pro
popis architektury jsou hledisko, pohled a model.
Významnou částí čtvrté kapitoly je „Metamodel
prvků“ týkajících se popisu architektury,
zahrnující:
- Popis architektury uspořádaný podle jednoho či
více pohledů.
- Pohled tvořený jedním či více modely.
- Model jako součást jednoho či více pohledů.
- Model jako součást jednoho či více popisů
architektury.
- Pohled řídí se hlediskem.
- Popis architektury s výběrem jedno či více
hledisek.
- Hledisko určující metody pro jeden či více modelů.
- Hledisko pokrývající jeden či více zájmů.
Za naprosto základní pro popis architektury
softwaru považují autoři koncepty, hledisko, pohled
a model.
Tvorba modelů má kromě obecných přínosů
k dokumentování architektury, několik dalších,
specifických přínosů:
- Detekce chyb a opomenutí v brzké fázi životního
cyklu.
- Prozkoumání relativních hodnot různých možností.
- Porozumění dopadům změn. Obsah
- Pomoc pří plánování projektu. Prvky modelu.
Ve čtvrté kapitole nás autoři seznamují s rámcem
popisu architektury, založeným na osvědčených
postupech, používaných při dokumentování
architektury softwaru.
Použití tohoto rámce popisu architektury je názorné
ukázáno v kapitolách, věnovaných případové studii
(kapitoly 6 až 9). Ještě předtím se autoři věnují
dalšímu základnímu konceptu, týkajícímu se
navrhování softwarových systémů: opětovnému použití
již existujících prvků. Toto téma je námětem páté
kapitoly „Opětovné použitelné prvky
architektury“
Dílčími tématy páté kapitoly jsou:
- Zdroje architektury
- Model prvků architektury
- Druhy prvků
- Atributy prvku architektury
- Další úvahy týkající se opětovné použitelnosti
Inspirace pro odvození či navržení architektury
pochází z mnoha zdrojů a liší se v závislosti na
mnoha faktorech, mezi něž patří i původnost systému,
metoda, podle níž architekt postupuje, a samozřejmé
i zkušenosti architekta.
Architekti přijímají různá rozhodnutí
v průběhu celého životního cyklu projektu.
Přitom jejich rozhodnutí mohou vycházet ze
zkušenosti, metody či nějakého jiného prvku.
Rozhodnutí o architektuře jsou mnohdy
informativnější než konečná řešení architektury,
neboť jejich součástí obvykle bývají diskuze o
alternativách a zdůvodnění výběru té či oné volby.
Považování rozhodnutí o architektuře za opětovně
použitelné prvky je novou, formující se disciplínou.
Z tohoto důvodu jsou metody a nástroje, podporující
tyto prvky, ve srovnání s metodami a nástroji
ostatních popisovaných prvků stále ještě relativně
nedokonalé.
Šestá kapitola je nazvána „Úvod do případové
studie“.
Cílem této kapitoly je uvést čtenáře do
problematiky případové studie, kterou v kapitolách 7
až 9 autoři používají jako příklad. V těchto
kapitolách se čtenář postupně seznamuje jak
s podrobnými požadavky, tak i se zvoleným řešením.
Předností případové studie je, že na tomto příkladu
mohou autoři názorné ukázat mnohé výzvy, které
musí architekt řešit na typickém projektu, jako
například:
- Základní funkční požadavky.
- Vývojové kvality.
- Běhové kvality.
- Systémová omezení.
- Opětovně použitelné prvky.
- Integrace aplikací.
- Fyzické rozmístění.
Autoři zdůrazňují význam vize, která
představuje první přiblížení toho, co by aplikace
měla nabídnout, a z tohoto důvodu slouží jako velmi
zásadní vstup při rozhodování o tom, zda
v projektu pokračovat či nikoliv. Je-li rozhodnuto o
pokračování v projektu, tyto informace se často
stávají základem pro vývoj či definici podrobnějších
požadavku. Popisem tohoto procesu se zabývá kapitola
7 „Definice požadavků“.
Sedmá kapitola je celá věnována definici
požadavků.
Osnova kapitoly je sama o sobě výmluvná.
- Souvislost požadavku s architekturou
- Funkční a nefunkční požadavky
- Postupy dokumentování požadavků
- Použití procesu
- Porozumění popisům úkolů
- Definice požadavků: přehled činnosti
Důvodem velké pozornosti tématu definice požadavků,
je potřeba pochopit souvislost požadavků
s architekturou.
Hodně napoví následující výčet výstupů činnosti
Definice požadavků:
- Změnové požadavky
- Funkční požadavky.
- Nefunkční požadavky.
- Seznam prioritizovaných požadavků.
- Protokol RAID.
- Dokument architektury softwaru.
- Požadavky účastníků procesu.
- Kontext systému.
Zvláštní místo přísluší výstupu, který autoři
označují pojmem Koncept systému. Tento výstup
popisuje celý systém jako jedinou entitu či proces,
a identifikuje rozhraní mezi systémem a externími
entitami.
V průběhu životního cyklu projektu dochází k postupnému
upřesňování požadavku, což ještě více zdůrazňuje
potřebu efektivního řízení požadavků a jejich
změn. Řízení požadavků prezentují autoři jako
systematický přístup ke zjišťování, uspořádávání a
dokumentování požadavků na zamýšlený systém
takovým způsobem, že jim rozumí všichni účastníci
procesu (včetně vývojářů). Kromě toho je to i
přístup k vytvoření a následnému udržování shody
mezi zákazníkem a projektovým týmem v otázce
měnících se požadavků na systém.
Autoři upozorňují na to, že celý projekt je často
provázen špatným procesem řízení požadavků, v jehož
důsledku jsou přijímány další požadavky od
účastníků, aniž by probíhala odpovídající diskuze o
jejich dopadech na celý systém.
V sedmé kapitole nám autoři ukázali proces
dokumentování požadavků na systém, vedoucí
k následujícím výstupům: Přehledu pojmů,
Požadavkům investorů, Kontextu systému, Funkčním
požadavkům, Nefunkčním požadavkům a Seznamu
prioritizovaných požadavků. Tyto výstupy jsou
základem pro vývojové činnosti, popsané v kapitole 8
„Tvorba logické architektury“ a kapitole 9 „Tvorba
fyzické architektury“.
Osmá kapitola je věnována tvorbě logické
architektury
V této kapitole se autoři věnují úkolům, jejichž
cílem je připravit logickou architekturu,
realizující ty požadavky, které byly definovány
v kapitole 7 „Definice požadavků“.
V této kapitole se poprvé autoři věnují přechodu
od požadavků k řešení.
Logická architektura představuje základní kámen
přechodu od požadavků k řešení – první krok,
zvažující architekturu způsobem, který je převážně
nezávislý na konkrétní technologii.
Pozoruhodný je výčet výstupů činnosti Tvorba
logické architektury podaný autory:
- Vyhodnocení architektury.
- Rozhodnutí o architektuře.
- Přehled architektury.
- Změnový požadavek.
- Datový model.
- Model nasazení.
- Funkční model.
- Protokol RAID.
- Záznam kontroly.
- Dokument architektury softwaru.
Úkoly, související s logickou architekturou,
považují autoři za nejvýraznější ve fázi
Rozpracování. V rámci této fáze doporučují
autoři zaměřit pozornost především na analýzu těch
požadavků, které mají největší vliv na architekturu.
Teprve ve fázi Zhotovení se třeba věnovat analýze
veškerých zbývajících požadavků. Množství času,
které vyžaduje práce na na logické architektuře, se
během fáze Zhotovení postupně snižuje, neboť
postupně klesá počet požadavků, které je ještě třeba
analyzovat. Důraz se přesouvá směrem k vývoji.
Dalším krokem, kterému se autoři v knize věnují, je
identifikace rizik, souvisejících
s jednotlivými variantami. U každého rizika
doporučují autoři knihy uvádět jeho potenciální
dopad na dodávku projektu. Kromě samotného
konstatování rizik je vhodné také rizika
kvantifikovat, a to z hlediska pravděpodobnosti
jejich skutečného výskytu a případného vlivu na
projekt, pokud se riziko skutečně projeví.
Definice logické architektury považují autoři za
kritickou část celého procesu vývoje softwaru.
Je-li tato činnost provedena dobře, výsledkem je
robustnější a srozumitelnější architektura, jasně
oddělující zájmy jednotlivých prvků systému a
rovnoměrné rozdělující odpovědnosti mezi tyto prvky.
V deváté kapitole je vyložen přechod od
logické architektury, popsané v kapitole 8 „Tvorba
logické architektury“, k tvorbě odpovídající
fyzické architektury. Na rozdíl od svého
logického protějšku fyzická architektura se již
zabývá i všemi produkty a technologiemi, které jsou
následně použity pro podrobný fyzický návrh a
nakonec i pro psaní kódu.
Tvorba fyzické architektury zahrnuje následující
úkoly (činnosti):
- Průzkum prvků architektury
- Definice přehledu architektury
- Dokumentace architektonických rozhodnutí
- Přehled funkčních prvků
- Přehled prvků nasazení
- Ověření architektury
- Ukázka realizovatelnosti architektury
- Podrobné funkční prvky
- Podrobné prvky nasazení
- Validace architektury
- Aktualizace dokumentace architektury softwaru
- Kontrola architektury s investory
V deváté kapitole autoři ukazují na to jak
dva klíčové modely, které byly použity pro popis
architektury systému – Funkční model a Model
nasazení – přecházejí z fáze, kdy
obsahují čistě logické (neboli technologicky
nezávislé) prvky, do fáze, kdy obsahují fyzické
(neboli technologicky specifické) prvky.
Během přechodu od logické architektury k fyzické je
třeba zvážit komponenty, lokality, uzly, spojení
mezi uzly a jednotky nasazení.
Pří přechodu od logické architektury k fyzické
doporučují autoři provedení několika výběrů:
- Výběr technologie.
- Vyber produktů.
- Opětovně použitelné prvky.
- Vývoj na zakázku.
Tvorba fyzické architektury představuje určité
zaměření většinou shodných úkolů, souvisejících
s tvorbou architektury. Jediným rozdílem je důraz na
fyzické, nikoliv na logické, aspekty vyvíjeného
systému.
Autoři zdůrazňují iterativní charakter procesu
vývoje architektury softwaru. Architekt musí
neustále vylepšovat, ověřovat a potvrzovat
architekturu vyvíjeného systému. Současné musí být
schopen dosáhnout i souhlasu ze strany všech
účastníků procesu, kteří se o vyvíjený systém
zajímají. V důsledku získávání dalších a dalších
informací a lepšího chápání požadavků je architekt
schopen se přesunout od čistě koncepčního pohledu na
architekturu k pohledu více fyzickému.
V deváté kapitole autoři ukázali, jakým
způsobem můžeme upravit a dále rozvíjet prvky
logické architektury, a to na základě použití
téhož vzoru procesu pro vytvoření fyzické
architektury, jasně identifikujícího
technologie, produkty a prvky, které mají být
použity pro návrh a sestavení systému
Desátá kapitola knihy, nazvaná „Za
hranicemi základů“ se zabývá jak dalšími
aspekty projektu vývoje softwaru, tak i specifickými
výzvami, souvisejícími s navrhováním systémů ve
složitých prostředích.
Jde o tato významná dílčí témata:
- Architekt a projektový tým
- Architekt a externí vlivy
- Navrhování složitých systémů
V této kapitole se autoři věnují především účasti
architekta s ohledem na aspekty vývoje softwaru,
jimž se nevěnovali v předchozích kapitolách:
testování, konfigurační management, změnové řízení a
vývojové prostředí. Mohou se vyskytnout některé
další složité faktory, vyžadující architektovu
pozornost, jako na příklad rozsáhlost systému,
velikost týmu, jehož práci musí někdo
koordinovat, a distribuovaný vývojový tým –
všem těmto tématům se budeme věnovat dále v této
kapitole. Autoři pozornost i dalším aspektům
projektu vývoje softwaru, přičemž se zaměřují
zejména na účast architekta s ohledem na další
disciplíny a tedy i role v týmu.
Architekt má vzhledem k požadavkům
poměrně různorodou sadu odpovědností. Mezi
nejvýznamnější příspěvky architekta řadí autoři
zajištění názoru technických uživatelů systému (jako
například Systémových administrátorů). Dále se
architekt účastní i prioritizace požadavků.
Kniha se sice nezabývá problematikou podnikové
architektury, autoři vychází z předpokladu, že
pokud si nějaká organizace takovou architekturu
definovala, pak veškeré systémy musí bvt vyvíjeny
v souladu s těmi oblastmi, které podniková
architektura pokrývá.
Principy podnikové architektury vyjadřují:
- Model podniku.
- Model podnikových procesů.
- Podniková pravidla,
- Stávající IT prostředí.
Desátá kapitola doplňuje kapitoly
předcházející, a to o seznámení s tématy, která
překračují hranice základního chápání role
architekta v typickém projektu vývoje softwaru.
Cílem autorů knihy bylo popsat řadu postupů,
které lze částečně nebo úplně využít v procesu
navrhování architektury softwaru. Pokusili se
připravit určitý základ znalostí, které by každý
architekt mel mít.
Kniha obsahuje 4 přílohy:
Příloha A: Metamodel architektury softwaru
Tato příloha obsahuje úplnou definici metamodelu
konceptů, s nimiž jsme v této knize pracovali.
Příloha B: Katalog hledisek
Tato příloha obsahuje přehled všech hledisek,
použitých v této knize. Podrobnějšímu popisu
problematiky hledisek se věnuje kapitola 4
„Dokumentace architektury softwaru. Oproti popisům
hledisek v jednotlivých kapitolách, tato příloha se
věnuje především souladu hledisek.
Autoři uvádějí tabulku, v které nacházíme popis
souladu mezi všemi pohledy rámce popisu
architektury.
Příloha C: Přehled metody
V této příloze najde čtenář souhrnné informace o
metodě, kterou autoři použili při přípravě této
knihv. Přehled základních konceptů, souvisejících
s metodou, pak najdete kapitole 3 „Základy metody“.
Dílčí témata přílohy: role, výstupy. Činnosti,
úkoly, fáze. Zvláštní pozornost věnují autoři fázi
„Přechod“. Fáze Přechodu je tou fází, během
níž má architekt zajistit to. Že software ie
přístupný všem koncovým uživatelům a je jimi také
přijat. Jedná se o tu fázi, během níž je systém
nasazován do prostředí koncových uživatelů za účelem
závěrečného vyhodnocení a testování. Přitom hlavním
cílem je vyladění produktu a vyřešení veškerých
případných problémů, souvisejících s konfigurací,
instalací a použitelností. Na konci této fáze by
mělo být možné projekt ukončit.
Poslední, čtvrtou přílohou je příloha D:
Kontrolní seznam požadavků na architekturu.
Tato příloha obsahuje kontrolní seznam vybraných
požadavků, majících významný vliv na architekturu..
Obsah přílohy je členěn na:
- Funkční požadavky
- Požadavky použitelnosti
- Požadavky spolehlivosti
- Požadavky výkonu
- Požadavky podporovatelnosti
- Omezení
Ačkoliv proces, který autoři popisují, může být
použit pro mnoho různých druhů iniciativ, omezili se
na jedinou případovou studii, díky níž mohou názorně
předvést ty klíčové úkoly, jichž se účastní
softwarový architekt. Autoři jsou přesvědčeni, že
úkoly, popsané v této knize, mohou být přizpůsobeny
potřebám jakékoliv dané situace, a to včetně
rozsahu, v němž je každý úkol prováděn. Autoři
vyjadřují optimismus pokud se týče vývoje vztahu
lidí k navrhování architektury. Spolu s tím, jak se
proces navrhování softwaru stává stále častějším a
obvyklejším, vzrůstá pravděpodobnost, že na něj
většina lidí přestane pohlížet jako na „nějakou
záhadnou sadu postupů“, jimž rozumí pouze
několik vyvolených, a začnou jej považovat za
široce přístupnou sadu dobře definovaných a
vyzkoušených postupů, majících určitý vědecký základ
a těšících se všeobecnému přijetí.
Knihu vřele doporučuji všem, kdo chtějí získat
přehled o navrhování architektury softwaru
doc. Arnošt Katolický,
18. dubna 2011.
|