SOFTWAROVÉ INŽENÝRSTVÍ

Transkript

1 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST II. ARCHITEKTURY SOFTWARE STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

2 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

3 Obsah Část II. Architektura software 1 Úvod Pojetí architektury v malém a velkém.chyba! Záložka není definována. 2.1 Historie pojmu Architektura IS... Chyba! Záložka není definována. 2.2 Vzory architektury... Chyba! Záložka není definována. 2.3 Pojetí architektury v komponentách... Chyba! Záložka není definována. 3 Architektura založená na vrstváchchyba! Záložka není definována. 4 Architektura založená na úrovníchchyba! Záložka není definována. 5 Modulární architektura... Chyba! Záložka není definována. 5.1 Axiomy modulární architektury... Chyba! Záložka není definována. 5.2 Koncepce řídících vazeb v modulárním systémuchyba! Záložka není definována. 5.3 Některá reálná pojetí Modulární architektury... Chyba! Záložka není definována. 6 Jazyk UML a architektura rozsáhlého softwarechyba! Záložka není definována. 7 Architektura klient server... Chyba! Záložka není definována. 8 Distribuovaná objektová architekturachyba! Záložka není definována. 9 Distribuovaná architektura na komponentách.chyba! Záložka není definována. 9.1 Realizační modely komponentové architektury Chyba! Záložka není definována. 10 Servisně orientovaná architektura SOA.Chyba! Záložka není definována Podnikové služby... Chyba! Záložka není definována. 11 Pojetí logické architektury rozsáhlého softwarového systému Modelování logické architektury Proces tvorby logické architektury Úkol A: Průzkum prvků architektury Úkol B: Definice přehledu architektury Úkol C: Dokumentace rozhodnutí o architektuře Literatura... 14

4

5 Část II. Architektura software Učební cíle: Seznámit se 1. se všemi koncepcemi logické architektury software. 2. problematikou zabezpečení jednotlivých koncepcí logické architektury software. Znát 1. základy tvorby Logické architektury. 2. základy pojetí logické, návrhové a fyzické architektury, základy prvotního přístupu k logické architektuře. Umět, mít dovednosti 1. SKUTEČNĚ tvořit Schéma logické architektury pro cílový software problémových domén. 2. Vložit do Schématu Logické architektury potřebnou filosofii funkcionality cílového software. 1 Úvod Ačkoliv na první pohled se mnoho programátorů nezabývá problematikou architektury svých aplikací, přesto jimi vytvořené aplikace jistou architekturu mají, a jde jen o to, tento pojem precisněji definovat. Porozumění podstatě pojmu architektura dá možnost se k její tvorbě cílevědomě postavit a využívat možnosti, které pro software přináší. Architektura software není jen jeho pouhá struktura. Ano, je to sice členění na jisté architektonické jednotky, které je obrazem struktury, ale jde rovněž o vzájemný život těchto jednotek v softwarovém celku. To ovšem vyžaduje vytvoření jistých pravidel, platných pro všechny jednotky, z nichž je software složen: 1. Pravidla pro koncepci jednotek (složení jednotek). 2. Pravidla pro vzájemnou spolupráci jednotek (přechody a vstupní a výstupní interface pro spolupráci). 3. Pravidla pro konzistentnost jednotek (říkající, že dvě jednotky jsou zcela zaměnitelné v sestavě softwarového celku s danou architekturou). Je již alespoň trochu zřejmé, že architektura, postavená na poměrně inteligentních jednotkách, přinese softwarovému celku jisté výhody: 1. Vhodné rozčlenění celkové funkcionality software mezi jednotlivé jednotky, což umožní pečlivější a hlubší propracování dílčích aktivit a méně analytických a programátorských chyb. 2. Snadnější modifikaci funkcionality celku, protože víme kterou jednotku/-y máme modifikovat a kterou/-é ne. 3. Využití distribuce jednotlivých jednotek do operační paměti a jejich spouštění, jen tehdy, kdy jsou potřebné. Co ale úspěšné využití možností cílově budované architektury od programátora vyžaduje? Pečlivou analytickou práci s funkcionalitou software (požadavky na funkcionalitu). Návrh architektury prostřednictvím návrhu architektonických jednotek. Chápání života jednotek v celku ze systémového pohledu. Analytickou práci nad koncepcí a životem architektonických jednotek. Vytvoření jisté deskripce architektury, např. graficky, verbálně, -5-

6 Pochopitelně, velmi jednoduché aplikace je jistě možné oprostit od architektury. Na druhé straně u robustních aplikací, které již vyhovují pojetí rozsáhlých softwarových systémů, se architekturou již musíme pečlivě zabývat. Praxe ukazuje, že architekturou robustných aplikací se musíme zabývat počínaje zpracováním požadavků na funkcionalitu cílového software. Nejen že musíme stanovit mapování požadavků do architektonických jednotek, ale rovněž navrhnout spolupráci jednotek. Tyto analytické práce vedou k tzv. logické architektuře. Nic není naprogramováno, ale je již jistá vize jak to s architekturou robustné aplikace bude vypadat. Dokonce je možné tuto logickou architekturu naprogramovat a použít jako elektronický spustitelný základ pro tzv. návrhovou architekturu a rovněž pro závěr fyzickou (naprogramovanou) a nasazenou architekturu. Aby práce na tvorbě cílového software měla v produkční softwarové firmě jistý řád, často se problematikou funkcionality zabývá architekt požadavků a architekturou zase hlavní softwarový architekt. Více pochopení architektury přinese až vlastní uplatnění objektové metodiky UP (Unified Process), kde budou vysvětleny používané postupy, grafické notace a rozdíly mezi logickou, návrhovou a fyzickou architekturou (viz Část IV. Vývoj objektových aplikací podle metodiky UP). Dnes existují konkrétní vývojové systémy, pro které jsou všechna potřebná architektonická pravidla stanovena a v podpůrném vývojovém software-framework podporována. Často se u prvního přístupu k architektuře cílového software za architektonické jednotky považují podsystémy nebo moduly. Později se obojí zobecňuje zavedením komponenty. Použití podsystémů, nebo modulů vychází z prvního přístupu k architektuře cílového software pod vlivem relevantních vlastností komputerizované problémové domény. Objektové metodiky, které jsou dnes základem pro vývoj cílového software se k problematice architektur staví poměrně zodpovědně. Chápou architekturu teoretičtěji, než běžná praxe. Objektové metodiky chtějí respektovat řádnou gnoseoligii vývoje software a respektují současně poznané typy architektur: LOGICKÁ ARCHITEKTURA NÁVRHOVÁ ARCHITEKTURA FYZICKÁ ARCHITEKTURA ARCHITEKTURA IMPLEMENTAČNÍ, NASAZENÍ. Logická architektura dává programátorovi první postřehy, jak bude cílový software vypadat, zejména po stránce filosofie jeho funkcionality. Návrhová architektura již předkládá podobu cílového software, která je programovatelná. Fyzická architektura již náleží naprogramovanému cílovému software. Architektura implementační již ukazuje jak je cílový software, konstruovaný v souladu s Návrhovou a Fyzickou architekturou osazen na Informační infrastruktuře zákazníka (IIS). Nejblíže se budeme věnovat Logické architektuře. Ostatní architektury probereme v rámci objektové metodiky. Pro postup vývoje komponentové ho charakteru architektur máme Workflow, tj. pracovní postup. -6-

7 1 Pojetí logické architektury rozsáhlého softwarového systému metodická kapitola Cíle: Znát (umět vysvětlit): 1. Pojetí termínu architektura software. 2. Pojetí logické, návrhové a fyzické architektury software. 3. Proč je architektura software jednou z jeho relevantních charakteristik? 4. Přístup k modelování logické architektury podle publikace [EelCrip011]. Dovednosti (umět prakticky): 1. Realizovat prvotní přístup k logické architektuře na základě relevantních vlastností problémové domény a sestrojit Prvotní schéma logické architektury. 2. Sestavit seznam klíčových rozhodnutí a otázek o architektuře. Klíčová slova: Architektura software, logická, návrhová a fyzická architektura, prvotní přístup k logické architektuře, opakovatelně využitelné prvky logické architektury, Prvotní schéma logické architektury Architektura rozsáhlého software je jedním z relevantních atributů software. Pochopitelně, cesta, která vede k jejímu modelování a realizaci je poměrně dlouhá a silně závislá na procesech-požadavcích výchozí problémové domény. Je to v souladu s věhlasnými objektovými metodikami (např. RUP, UP, Select Perspective, ), které jsou postaveny na dominanci zpracování požadavků zákazníka. Procesem postupného modelování architektury, v známých objektových metodikách, dospějeme k tzv. logické architektuře, která se musí převést na základě zvolené metody na tzv. návrhovou architekturu. Návrhová architektura se realizuje prostřednictvím zdrojového kódu ve zvoleném programovacím jazyku a vzniká tak architektura fyzická. Sémantika všech tří úrovní je konzistentní a týká se to rovněž vytvořených modelů, resp. diagramů. Rozdíl je ovšem v tom, že návrhový model je velmi blízko implementační fyzické realizaci architektury cílového software a rovněž fyzická architektura souvisí s jejím nasazením v informační infrastruktuře zákazníka. Stačí, vyslovíme-li několik význačných charakteristik jednotlivých modelů architektury: Logická architektura vychází z požadavků problémové domény a je nezávislá na informačních technologiích. Jelikož není možné neuvažovat o architektuře cílového software, je logická architektura prostředkem přechodu od požadavků k návrhovému modelu architektury a potom ke konstrukci fyzické architektury cílového software. Návrhová architektura sice vychází z logické architektury, ale vzniká pod vlivem uplatnění zvoleného modelu informační technologie. Návrhová architektura je potom snadno převoditelná do formy zdrojového kódu. Pojetí všech tří architektur a zejména logické architektury, je uvedeno v publikaci [EelCrip011]. Některé pozoruhodné skutečnosti z této knihy, týkající se zejména logické architektury, jsou diskutované v následujícím textu a řešené ve fázi ZAHÁJENÍ klasických pokročilých objektových metodik vývoje software. Návrhová architektura nebude zde rozvíjena, ale bude o ní mluveno až ve fázi ROZPRACOVÁNÍ zmíněných metodik. Co vše potřebujeme znát pro zahájení a pokračování ve vývoji logické architektury jako vstupy procesu tvorby logické architektury? Jsou to následující skutečnosti: -7-

8 Pojetí podnikové architektury 1. Stávající IT prostředí (informační infrastruktura) zákazníka. Procesy jako funkční požadavky, jejich priority a členění do známých procesních setů. Nefunkční požadavky. Pojmový model podniku obsahující procesy a zpracovávaná data (např. klasický procesní diagram, nebo objektový model tříd). Podniková pravidla nebo podmínky týkající se života podniku (tedy zejména podnikových procesů/služeb). Kontext organizačních součástí podniku (v souladu s jeho architekturou) a vazby na okolí podniku. Znalost uvedených skutečností evokuje správný názor, že logická architektura cílového software by měla zmíněné skutečnosti jaksi odrážet. Např. logická architektura může být postavena na podnikových podsystémech, na jejich částech, na procesních setech, na procesních podsetech, na organizačních jednotkách, nebo na vymezených skupinách podnikových dat. Nejčastěji je ovšem používána procesní platforma. Toto je prvotní přístup, tedy obecná problematika odvozování logické architektury cílového software z kvalit problémové domény. Kde se dovíme zmíněné skutečnosti o podniku? Zjistíme je v provádění stanovených úkolů Úvodní studie (pro strukturované metodiky), nebo fáze ZAHÁJENÍ objektových metodik. Za výsledek procesu modelování logické architektury považujeme: Vyhodnocení kvality vstupů a jejich vlivu na architekturu cílového software. Rozhodnutí o logické architektuře, jaká bude a zdůvodnění proč takovou musí být. Přehled architektury - prvotní model vycházející: z Prvotního schématu logické architektury, z pozdějšího funkčního modelu na komponentách, tj. finálních architektonických jednotkách, z dat a procesů versus komponenty, ze života komponentrozhraní, z nasazení architektury v uzlech informační infrastruktury podniku. Změnová kontrola logické architektury (jak architektura odolává změnám v podniku, zejména v jeho podnikové architektuře). Výsledný dokument o logické architektuře. 1.1 Modelování logické architektury Kniha [Hofm, 05] se zabývá několika přístupy k odvozování logické architektury cílového software. Již dříve uvedený prvotní přístup je v knize rovněž uvažován. Uveďme tři z nich bez hlubší charakteristiky: 1. Přístup na základě atributů celkové kvality problémové domény Attribute Driven Design (ADD). 2. Metoda 4 pohledů od firmy Siemens. 3. Přístup objektových metodik (RUP-Rational Unified Process, UP-Unified Process a dalších), které vycházejí z dominance procesů-požadavků. 1 Architektura podniku je koherentní celek principů, metod a modelů, které jsou použity v návrhu a realizaci: podnikové organizační struktury, business procesů, podnikového informačního systému a podnikové informační infrastruktury. -8-

9 O posledním přístupu budeme později mluvit podrobněji (viz fáze ZAHÁJENÍ a ROZPRACOVÁNÍ metodik RUP/UP). Modelování logické architektury je součástí fáze ZAHÁJENÍ a pokračuje do fáze ROZPRACOVÁNÍ. Finálním nástrojem pro modelování logické architektury v metodice UP jsou UML grafické notace komponent a deskripce života komponent v logické architektuře. Často se pro návrh logické architektury používá na začátku koncept založený na podsystémech, např. procesních, pro jisté oblasti života podniku. To může být prvotní, velmi hrubé schéma logické architektury (např. ve fázi ZAHÁJENÍ metodiky UP). Podsystém je potom chápán jako sada souvisejících součástí, do kterých se promítají procesy-požadavky přes případy užití, a tak vznikne poněkud detailnější schéma logické architektury. Logickou architekturu můžeme převést na logické využití komponent, za které považujeme již zmíněné moduly/podsystémy. Zaznamenáme-li v předchozím schématu logické architektury život zmíněných komponent (naznačení spolupráce), dojde k dalšímu užitečnému zjemnění pojetí logické architektury. Přidáme-li verbální deskripce funkcionality komponent, jejich rozhraní (poskytovaných a požadovaných) a zakreslíme-li schéma nasazení logické architektury v uzlech informační infrastruktury podniku, mohli bychom získané poznatky o logické architektuře považovat za užitečné pro její převod do architektury návrhové. 1.2 Proces tvorby logické architektury Publikace [EelCrip011] se zabývá v podstatě celým procesem tvorby architektury cílového software. Tvorba je rozdělena do tří podprocesů: podprocesy pro tvorbu logické architektury, návrhové architektury a fyzické architektury. Abychom se příliš nevzdálili od pracovních postupů jednotlivých fází objektových metodik, vybereme z knihy [EelCrip011] jen některé myšlenky, protože uvedená kniha ne zcela jasně je navzájem spojuje. Proces tvorby logické architektury, který budeme sledovat je popsán na základě úkolů a kroků, tak jak ukazuje Obrázek 10-1 aktivitního diagramu. Na druhé straně, tyto úkoly nejsou v rozporu s později použitou metodikou UP. Pokusíme se teď naznačit, co se pod jednotlivými úkoly/kroky procesu tvorby logické architektury myslí. Jak se tyto úkoly odrazí v metodice UP zjistíme až v Části IV. Vývoj objektových aplikací podle metodiky UP. Jisté je, že prvotní přístup k architektuře cílového software je ve fázi ZAHÁJENÍ metodik RUP a UP postaven právě na logické architektuře. Pro čtenáře bude jistě užitečný příklad modelování logické architektury cílového komputerizačního software jednoduché domény Evidence soukromých zbraní v ČR, který bude uveden později v Část IV. Scénář fáze ZAHÁJENÍ na doméně SSZ v ČR. Ve vysvětlování metodiky UP se dovíme, že problematika logické architektury se začíná řešit již ve fázi ZAHÁJENÍ a poté řešení pokračuje velmi široce ve fázi ROZPRACOVÁNÍ, kde se důsledně rozpracuje návrhová architektura. Ve fázi KONSTRUKCE se problematika architektury soustřeďuje jen na dokončení návrhové architektury a potom na její fyzickou realizaci v programovacím systému. Ve fázi ZAVEDENÍ se potom řeší nasazení fyzické architektury na informační infrastruktuře zákazníka. V softwarovém projektu, který je pro řízení vývoje software IS ustanoven a který využívá zmíněnou metodiku, je za architekturu zodpovědný hlavní architekt. Pochopitelně, je-li komputerizovaná problémová doména rozsáhlá, potom v projektu figurují rovněž datový architekt, procesní architekt, architekt infrastruktury a aplikační architekt. Velmi užitečný je následující metamodel vývoje logické architektury. -9-

10 A B C Obrázek 10-1: Proces tvorby logické architektury (převzato a upraveno z [EelCrip011], str. 167) Úkol A: Průzkum prvků architektury software Znalost procesní charakteristiky celé problémové domény, nebo jen jejího výseku, pomůže provést průzkum, jestli již existují nějaké opětovně využitelné prvky architektury 2, které bychom mohli využít. Opakovatelně využitelné prvky architektury se člení na prvky využitelné v logické architektuře a návrhové architektuře. Protože nás zajímá jen logická architektura, tak uvedeme jen prvky v ní použitelné: Opakovaně se vyskytující proces požadavek/podsystém/modul, nebo komponenta objevující se rovněž v jiné problémové doméně. Opakovaně využitelný vzor logické architektury. Je to vzor, který již byl využit v jiné problémové doméně. Např. u podniku je komputerizace orientována jen na problematiku personalistiky a my známe skupiny procesů a jejich osazení jednotlivými procesy. Hledání potom orientujeme na prověření, jestli náhodou neexistuje služba ve formě komponenty pro jednu nebo více skupin personálních procesů. Jestliže jsou pro komputerizaci problémové domény, nebo její části, předepsány jisté principy týkající se architektury, tak je nutné na ně brát ohled. Např. platí princip, že průzkum existence opakovaně využitelných prvků architektury musí být proveden jako první a musí být vyhotovena příslušná zpráva o výsledku Úkol B: Definice přehledu architektury Následující obrázek ilustruje vstupy a výstupy tohoto úkolu, jehož cílem je vytvořit tzv. Přehled architektury. 2 Za opětovně použitelné prvky architektury považujeme již existující prvky, opakovaně využitelné pro logickou nebo návrhovou architekturu nově tvořeného software. -10-

11 Procesy-funkční požadavky Nefunkční požadavky Principy podn. architektury Výsledky kontextové analýzy Slovník pojmů Vstup Definice přehledu architektury Výstup Přehled architektury Obsah Přehledu architektury: Přehled architektury je spíše schematický a doplněn potřebnou verbální deskripcí. Představuje prvotní odvození architektury z procesů-požadavků problémové domény. Analýzu procesů, jejich seskupení do skupin/množin/podsystémů musíme ovšem provést jako první. Důležité je, že musíme mít procesní model domény, resp. její části. Schéma, které se musí v Přehledu architektury vytvořit je souhrnem obdélníků, které jsou pospojovány závislostními spojnicemi. Spojnice většinou nejsou interakčního charakteru. Jde o seskupení funkcionalit (daných procesy-požadavky) uvedených v obdélnících. Seskupení funkcionality jsou následujících typů: do skupiny/množiny/oblasti procesů, do podsystémů nebo modulů, do komponenty. V prvotním schématu pro logickou architekturu použijeme jen jeden typ seskupení funkcionalit. Budou to podsystémy. Spojnice označují ze začátku jen jisté souvislosti. Jsou to souvislosti, které jsme objevili mezi skupinami/množinami/oblastmi procesů, nebo mezi podsystémy /moduly. Spojnice se dále upřesňují, což souvisí rovněž s upřesňováním logické architektury. Podsystémy se chápou jako možné sady souvisejících částí (s mapováním 1:1, 1:N). Schéma doplníme tak, aby dalo první obraz architektury cílového software, např. je načrtnuta komunikace s klienty a závislosti prvků schématu. 1 Hrubý přehled funkčních prvků, funkční model Cílem je nalezení základních funkčních prvků a jejich mapování do podsystémů/modulů, později do finálních komponent a tak vytvořit první představu o funkčním modelu problémové domény. Např. A B C D E Obrázek 10-2: První představa o funkčním modelu. Jednotlivé podsystémy by měly být později identifikované a rovněž identifikované závislosti mezi nimi. Závislosti můžeme kreslit pomocí relace <<využívá>> -11-

12 Následující příklad může sloužit jako vzorový pro získání hrubého funkčního modelu domény. Příklad 10-1: Ze znalosti funkcionality problémové domény Evidence soukromých zbraní v ČR, viz Část IV -5, můžeme poznat následující skupiny/moduly/podsystémy procesů a souvislosti mezi nimi. 1. Správa zbraní a Průkazů zbraní. 2. Správa majitelů zbraní. 3. Správa ZP. 4. Správa klientů. 5. Statistiky a vyhledávání. Pro naši doménu SSZ v ČR má schéma Prvotního pohledu na problémovou doménu následující tvar: Správa soukromých zbraní na teritoriu ČR Statistiky a vyhledávání Správa MZP Správa ZP Správa klientů Správa zbraní a PZ Obrázek 10-3: Prvotní pohled na problémovou doménu. Sestavíme Model hrubé funkční - procesní závislosti v problémové doméně: Správa zbraní a průkazů zbraní <<využívá>>. 7 Statistiky a vyhledávání <<využívá>>. 2 4 <<využívá>>. 1 <<využívá>>. Správa majitelů zbraní <<využívá>>. 3 5 Správa zbrojních <<využívá>> průkazů <<využívá>>.. <<využívá>>. 6 Správa klientů Obrázek 10-4: Příklad hrubého funkčního modelu problémové domény s relací <<využívá>>. Můžeme tedy sestavit schematický přehled architektury, který bude doplněn o další -12-

13 nezbytné prvky logické architektury (Řízení a komunikace s klienty, Řízení výstupních sestav a Báze dat), což dále objasní cestu k návrhové architektuře. Schéma, které to ilustruje, nazveme pracovně Prvotním schématem logické architektury. a) Prvotní schéma logické architektury: Komunikace s klienty Správa výstupních sestav Správa zbraní a průkazů zbraní (ZP) Správa statistiky a vyhledávání BD Správa majitelů zbraní Správa zbrojních průkazů (ZP) Správa klientů Obrázek 10-5: Prvotní schéma logické architektury pro doménu Evidence soukromých zbraní v ČR. b) Deskripce schématu: Systém potřebuje centrální řízení komunikace s klienty, které umožní nejen autentizaci a autorizaci, ale i organizaci plnění jejich požadavků. Klienti mohou spouštět jednotlivé podsystémy. Veškerá informace podsystémů je uložena v bázi dat. Podsystém Řízení statistiky nebude využívat ostatní podsystémy (jak je ve funkčním modelu), ale jen jejich data z báze dat-bd. Podsystém Řízení výstupních sestav bude organizovat výstup podle připravených výstupních šablon v podsystému Řízení statistiky. 2 Přehled prvků nasazení Zde uvažujeme o informační infrastruktuře (IT prostředí pro nasazení) problémové domény a identifikujeme lokality, v kterých bude cílový software nasazen, a pochopitelně uvažujeme o výpočetních uzlech, které se v daných lokalitách nacházejí. Můžeme načrtnout, jaké podsystémy budou v uzlech nasazeny. Zavedení komponentového pojetí 3 Zavedení komponentového pojetí Jak již bylo načrtnuto, můžeme Prvotní schéma logické architektury dále upravovat, zejména jeho převedením na ilustraci komponent (finálních architektonických jednotek): Podsystémy mapujeme na komponenty. Stanovíme spolupráci komponent (nabízená a požadovaná rozhraní). Můžeme již nakreslit Diagram prvotního přístupu k nasazení komponent v informační infrastruktuře. -13-

14 Uvedenou úpravu můžeme provést, protože jsme již o architektuře koncepce Distribuovaná architektura, postavené na komponentách již poučeni. Jaká je geneze dalšího využití diagramu Prvotní schéma logické architektury? Počítá se s tím, že komponenty budou později (ve fázi ZAHÁJENÍ), jakoby formálně naplněny případy užití, později (ve fázi ROZPRACOVÁNÍ) jakoby formálně naplněny Diagramy realizačních analytických tříd a souvisejícími Sekvenčními diagramy. Jestliže se toto naplnění (opět ve fázi ROZPRACOVÁNÍ) provede návrhovou formou Diagramů analytických tříd a souvisejících Sekvenčních diagramů, vznikne Návrhová architektura. Nakonec budou komponenty již reálně naplněny zdrojovým kódem návrhových tříd a souvisejících Sekvenčních diagramů (ve fázi KONSTRUKCE) a vznikne Fyzická architektura. 4 Ukázka koncepce architektury Je v objektových metodikách RUP a UP dokumentována tzv. Spustitelným architektonickým modelem software, což je tzv. komponentové klišé, které je sice postaveno na spustitelných, ale většinou prázdných komponentách. Pozoruhodné je to, že toto klišé se již nezahazuje, ale neustále se přetvářídoplňuje na Fyzickou architekturu, a je snahou jeho koncepci příliš neměnit. S tímto postupem se jistě setkáme v obou zmíněných objektových metodikách Úkol C: Dokumentace rozhodnutí o architektuře Cílem tohoto úkolu je zaznamenat veškerá provedená a plánovaná klíčová rozhodnutí o architektuře. Všechny dosud provedené práce v souvislosti s architekturou Vstup Dokumentace rozhodnutí o architektuře Výstup Rozhodnutí o architektuře Sestaví se soupis otázek spojených s architekturou, charakterizují se možnosti, vybere se preferovaná možnost a toto rozhodnutí se dokumentuje v dokumentu Rozhodnutí o architektuře. Jedna z otázek se soustřeďuje na vyřešení pozice podnikových pravidel (pravidla víceméně spojená s podnikovými procesy) v architektuře cílového software. To vše budeme řešit ve fázi ZAHÁJENÍ a fázi ROZPRACOVÁNÍ metodiky UP. Uvedené myšlenky počátečního přístupu k architektuře cílového software nám ukázaly, jak vyjít od požadavků a relevantních vlastností problémové domény a kráčet k logické architektuře. Tyto myšlenky jistě využijeme v metodice UP. Poznámka Modelování logické architektury cílového software může ve fázi ZAHÁJENÍ končit již u Prvotního schématu logické architektury. Potom ovšem do komponentové podoby musí být převedeno ve fázi ROZPRACOVÁNÍ. Shrnutí kapitoly: Kapitola podává pojetí logické architektury a prvotní přístup k ní. V kapitole se využívá postupu, který je navržen v publikaci [EelCrip011]. Začíná se zhodnocením vlivu relevantních vlastností problémové domény na logickou architekturu. Provede se průzkum prvků architektury, které by se daly v logické architektuře využít. V přehledu architektury se Σ -14-

15 sestrojí Prvotní schéma logické architektury. Buď ještě ve fázi ZAHÁJENÍ dojde k převodu Prvotního schématu logické architektury do komponentové podoby, anebo se to provede až ve fázi ROZPRACOVÁNÍ (krok Architektonický návrh). V této fázi rovněž dojde k tvorbě Spustitelného architektonického modelu, který bude ilustrovat běh cílového software na komponentách a bude dále dopracováván. Nakonec se logická architektura verbálně dokumentuje v tzv. Rozhodnutí o architektuře. Pojmy k zapamatování: logická, návrhová a fyzická architektura software, Prvotní schéma logické architektury, Spustitelný architektonický model, Rozhodnutí o architektuře. Testy a otázky: 1. Jaké je pojetí logické, návrhové a fyzické architektury? 2. V čem tkví přístup k logické architektuře podle publikace [EelCrip011]? Kde se začíná v tomto přístupu? 3. Jaký mají význam hrubý funkční model problémové domény, Prvotní schéma logické architektury a Rozhodnutí o architektuře? Úkoly k zamyšlení: 1. Zamyslete se, pro koho může být významné spojení problematiky logické architektury s pojetím komponent již ve fázi ZAHÁJENÍ a pro koho až ve fázi ROZPRACOVÁNÍ (krok Architektonický návrh). 2. Co si představujete pod Spustitelným architektonickým modelem a k čemu slouží? 2 Literatura [EelCri, 2011] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN [WoMa, 2006] [Erl, 2006] [KrŽe, 2004] [Tan, 2007] [ArNeu, 2007] [Som, 2010] [wiksof] [Kač, 2000] [Hofm, 05] WOODS, D., MATTERN, T.: Enterprise SOA. Designing IT for Business Innovation. O'REILLY, Tokyo. ISBN ERL, T.: Service-oriented Architecture. A Field Guide to Interacting XML and Web Services. Prentice Hall, USA, ISBN Král, J., Žemlička, M.: Architektury orientované na služby jako nové paradigma: mýty, problémy, výzvy, přínosy. In: Sborník z konference Systems Integration Praha, Vysoká škola ekonomická. Tanenbaum, A. S.: Distributed Systems. Principles and Paradigms. Printice Hall, Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Brno: Computer Press, ISBN Sommerville, I. Software Engineering (the 9 th edition). London: Publisher PEARSON, ISBN 10: Kačmár, D.: Programujeme v COM a COM+. Computer Press, Praha, ISBN Hofmeister, CH.: Generalizing a Model of Software Architecture Design -15-

16 [RuJaBo, 99] [Če-Va-Zi, 06] from five Industrial Approaches. Proceedings of the 5th Working IEEE/IFIP Conferences on Software Architecture (WICSA5). Washington, DC: IEEE Computer Society, Rumbaugh, J., Jacobson, I., Booch, G.: The unified Modeling Language. Reference Manual. Amsterdam: ADDISON-WESLEY, ISBN X. Bock, H.: The Definition Guide to Net Beans Platform. Brno: Computer Press, ISBN