Vrstvená SW architektura

1. Vrstvená SW architektura • Vrstvená architektura je jednou z variant dílčí softwarové architektury nabývá při tvorbě SW stále většího významu (základní cíl vrstvené architektury je minimalizace tvorby a údržby SW). • Abstraktnípočítač (1 vrstva SW architektury) • Architektura je tvořena hierarchií abstraktních počítačů (vrstev) Uživatelskávrstva • tvořenatechnologickýmivrstvami následujících typů • agregátová - vytvořítakovoumnožinufunkcí, pomocíkteré se problémvyřešírychle a efektivně • filtrující - odstranínepodstatná a nežádoucíspecifikanižšíchvrstev (odstínění rozdílů v uživatelském rozhraní) • interfaceová- reprezentujeuživatelskérozhraní, je zpřístupněnauživatelůmnadřízenévrstvy

2. Vrstvená softwarová architektura detailněji

3. Vrstvená softwarová architektura • Prvky vrstvy SW architektury • ADT (složen z datovéstruktury a operacínaddatovoustrukturou), kolikfunkcí, tolik ADT • dispečer ADT • dispečervrstvy • tvůrcevrstvy • uživatelvrstvy

4. Vrstvená softwarová architektura

5. Typické vrstvy IS jinak • Z technologického pohledu • Prezentační systém • Aplikace • DBS • OS • Strojový kód • Mikroprogramy, binární logika • Z aplikačního pohledu • Uživatelé • GUI • Aplikace • DB prostředí • OS platforma • HW prostředky

6. Vrstvená softwarová architektura (VA) Základní cíl VA je minimalizace nákladů tvorby a údržby a nákladů užití softwarového systému. Uspořádání funkcí do několika vrstev s tím, že funkce vyšší vrstvy mohou využívat jen funkce vrstev podřízených. Typické vrstvy současných počítačů:

7. Další možné komplexní přístupy k architektuře IS/IT • Architektura 4+1 pohledů • Komponentová architektura • Servisně orientovaná architektura • Modelem řízená architektura

8. Architektura 4+1 pohledů • Definice architektury systému podle IEEE: nejvyšší úroveň koncepce systému v jeho vlastním prostředí. • Architekturasystémumusímítschopnostbýtviděna z různéhoúhlupohledu. • 4+1 pohledy (každý pohled odpovídá modelu v dokumentaci systému). • Spojena s objektovým přístupem.

9. Architektura 4+1 pohledů • Logickýpohled(slovníček, funkce) • logickástrukturasystému z hlediskavýslednéfunkčnosti (co by systém měl vykonávat), • identifikujehlavní (věcné) balíky, subsystémy,třídy a vazbymezinimi, • model perzistentníchinformací (data a funkce), • zajímáanalytika a designera, • zachycuje slovník oblasti problému jako množinu tříd a objektů, • spolu s procesním pohledem představují chování systému.

10. Architektura 4+1 pohledů • Implementačnípohled(Systémová seskupení, správa konfigurace) • popisorganizacestatickýchsoftwarovýchkomponent, modulů (exe, html,dll)vevývojovémprostředí, • rozčlenění do vertikálních a horizontálníchvrstev, • zaměřennarozdělenísystému do menšíchsamostatněrealizovatelnýchkomponent, • zdrojovýkód, datovésoubory, spouštěče, • zajímáprogramátory a SW management, • slouží ke znázornění závislostí mezi komponentami a toho jak konfigurovat spojení těchto komponent.

11. Architektura 4+1 pohledů • Procesnípohled(výkon, škálovatelnost, propustnost) • pohlednachovánísystému • konkurence a paralelismus, propustnost, • automatizovanéúlohy, tolerance chyb, • zotavení z běhovýchchyb, • odezvasystémunavnějšípodněty, • rozšiřitelnostsystému, jehovýkonnost, přípustnost, • zajímásystémovéintegrátory.

12. Architektura 4+1 pohledů • Pohlednasazení(technologie systému, distribuce, doručení, instalace) • navázánísystémunatopologiihardwarových a dalšíchsoftwarovýchkomponent (jakjsouspouštěče a ostatníběhovékomponentymapovány do základníchplatforem a počítačovýchuzlů), • fyzickérozloženíkomponent, nasazení, instalace, laděnívýkonu, • zajímávšechnytvůrcesystému.

13. Architektura 4+1 pohledů • Pohledpřípadůužití(základní požadavky na systém) • speciální role, • klíčovépřípadyužití (use case), • pomáháodhalitzákladnípožadavkynaarchitekturu, • zpětnávazbanavěcnépožadavkypřitestování, • systematickýpřístup k věcnýmpožadavkům, • zajímákoncovéuživatele.

14. Komponentová architektura • Základní myšlenkou komponentových architektur je snaha pojmout tvorbu programu jako skládání jinak do značné míry nezávislých komponent. Tuto myšlenku lze uplatnit jak na úrovni návrhu architektury, tak na úrovni implementace programu. • Na úrovni návrhu architektury je předním přínosem komponent možnost rozdělit řešení do menších, a tak snáze zvládnutelných částí. Při důsledném použití hierarchické dekompozice se pak návrh architektury na nejvyšší úrovni skládá z relativně malého počtu spolupracujících komponent. Běžně používané jednotky dekompozice jako moduly či třídy jsou však zatíženy vazbami na prostředí pro implementaci programu, ve kterém mají další, s dekompozicí nesouvisející funkce. Komponenty takové vazby nemají, a proto jsou jako koncepty pro dekompozici vhodnější.

15. Komponentová architektura • Na úrovni implementace programu je nejviditelnějším rysem komponent podpora opakovaného použití již implementovaných komponent ve větším počtu programů. Takové opakované použití slibuje mnoho výhod, mezi jinými např.: • zvýšení produktivity, neboť opakovaně použitý kód je možné převzít a není třeba vyvíjet nový, • zvýšení kvality programů, neboť opakovaně použitý kód je častěji zkoušen a zjištěné chyby jsou současně odstraněny ve všech programech, ve kterých je kód použit, • zvýšení výkonu programů, neboť opakovaně použitý kód se spíše vyplatí optimalizovat a každá optimalizace se současně projeví ve všech programech, ve kterých je kód použit, • zvýšení schopnosti programů spolupracovat, neboť opakované použití kódu vede k použití stejných formátů dat ve všech programech, ve kterých je kód použit.

16. Komponentová architektura • Komponenta = základníjednotkapoužitelnosti • Je to netriviální, téměřnezávislá, vyměnitelnáčástsystému, kteráposkytujejasnoufunkcionalitu. Komponentafyzickyimplementujesadurozhraní a musísplňovatjimidefinovanéchování. • Rozlišujeme: • spustitelnékomponenty, systémovékomponenty, • vývojářskékomponenty, • věcnékomponenty (business component), • univerzální a dalšíkomponenty.

17. Komponenty • Příklady komponent (spustitelný program, knihovna, textový soubor, tabulka v databázi, ...). • Komponenty vznikají při tvorbě architektury jako samostatně navržené, vyvinuté a otestované části software, integrované do systému. Existují znovupoužitelné komponenty pro řešení častých problémů, vyvinuté v rámci projektu nebo samostatně (standardy JavaBeans, CORBA, ActiveX).

18. Komponenty a vrstvy architektury • Dekompozice návrhu softwarového systému do komponent • horizontální - komponenty stejného typu řeší různé úlohy • vertikální - rozdělení do vrstev • Vrstvy podle typů komponent • vrstva persistence dat (komponenty řešící trvalé uložení dat – operace Insert, Update, Delete, Select) • vrstva obchodní logiky • vrstva GUI a další

19. Komponenty a vrstvy architektury • Počet vrstev (typicky 2-5 vrstev), příliš velký počet vrstev má za následek: • složitou a nepřehlednou architekturu, • mnoho vazeb a závislostí, • příliš malé komponenty, • snížení výkonu. • Tříúrovňová architektura v komponentovém přístupu umožňuje dobře definovat odpovědnost komponent, umožňuje separátní vývoj v týmu a oddělení komponent na samostatné uzly (procesory).

20. Komponenty a vrstvyarchitektury • uživatelské rozhraní • vizuální objekty v aplikaci - okna, ovládací prvky,… • pouze zobrazuje data - ergonomie uživatelského rozhraní, ošetření reakcí uživatele, vícejazyčnost • obchodní logika • logika informačního systému, algoritmické zpracování dat, logický model tříd systému • přístup k datům (objektové a relační db)

21. Výhody komponentové architektury • Přehledná architektura: • rozdělení odpovědnosti, • komunikace pomocí rozhraní, • řešení komplexnosti. • Zrychlení vývoje: • sestavování systémů z nakoupených komponent, • oddělený vývoj balíků komponent. • Oddělené testování: • samostatné testování komponent, • integrační testy.

22. Architektura orientovaná na služby SOA • Nový přístup k řešení architektury IS/IT, který využívá všech silných stránek předchozích přístupů a přidává koncept opakovatelné používaných komponent – služeb s přesně definovaným chováním a rozhraními na okolí, tj. webových služeb. • Zavádí se pojem katalog služeb (seznam všech služeb, které jsou v daném řešení k dispozici a je možné je kombinovat). • Hlavním rysem je flexibilita při návrhu konkrétního řešení, tj. aby při změně obchodního požadavku na fungování IS stačilo v katalogu najít služby a jejich kombinací rychle dodat uživatelům požadovanou funkcionalitu. Komponenty lze z katalogu vyvolat opakovaně – snížení nákladů. • Viz obr.

23. Architektura orientovaná na služby SOA • Implementace SOA • 1. krok : Definice základních stavebních kamenů – služeb. Služby ze základní vrstvy jsou pak zpřístupněny uživatelům přes vrstvu tzv. veřejných služeb (bankomaty, veřejný portál, SMS brána), tedy služby GUI nebo B2B rozhraní.

24. Architektura orientovaná na služby SOA • Implementace SOA • 2. krok: Implementace vrstvy technologických služeb. Integrační HUB zde zajišťuje výměnu dat mezi rezervačním a finančním systémem. Takto navržená architektura může zvýšit výkon celého systému oddělením integračních a prezentačních služeb

25. Architektura orientovaná na služby SOA • Implementace SOA • 3. krok: Procesní vrstva umožňuje snadnou implementaci složitých podnikových procesů, které v sobě mohou zahrnovat složitá rozhodovací kritéria nebo podmíněné spouštění nejrůznějších podsystémů a aplikací. Nová služba v tomto příkladu může obsahovat různé podmínky (nabídka slev na letenky), nebo verifikaci platby s bankou.

26. Architektura založená na modelech • MDA je přístup společnosti OMG Object Management Group, který vychází z myšlenky, že změny v oblasti SW resp. podniku se liší v závislosti na úrovni abstrakce. Na nižších úrovních jsou změny častější a zásadnější. Z toho vyplývá, že dopady neustálých změn v technologiích a společnosti vůbec je možné omezit jen na nižší vrstvy modelu a v případě potřeby přepracovat jen ty části, kterých se změna dotýká. • Původně bylo toto paradigma vytvořeno pro vývoj software a byly popsány tři modely: Počítačově nezávislý model (Computer Independent Model, CIM), Platformově nezávislý model (Platform Independent Model, PIM) a Platformově specifický model (Platform Specific Model, PSM) se vztahem ke komponentní technologii. • Později se však princip soustředil na vrstvu počítačově nezávislou, ve které jsou obsaženy podnikové aspekty společnosti. Nové verze MDA nyní obsahují tři úrovně abstrakcí se vzájemnými vztahy podle následujícího obrázku.

27. Počítačově Nezávislý Model • (CIM) • Podnikový model • Doménový model • Podnikové požadavky Mapování • Platformově Nezávislý Model • (PIM) • BPMN Model nezávislý na provádění workflow • UML model nezávislý počítačové platformě Mapování • Platformově Závislý Model • (PSM) • UML model pro určitou platformu (J2EE) Architektura založená na modelech

29. Volba typového aplikačního SW • je velmi odpovědná činnost a vůbec ne jednoduchá – obzvláště u ASW, se kterým nejsou žádné zkušenosti (ani dobré, ani špatné). Jaká tedy zvolit kritéria při výběru software? K základním lze zařadit: • funkčnost – tj. plnění požadovaných funkcí, • provozovatelnost (v různém prostředí, např. aplikace pro prostředí Windows XP nejsou provozovatelné v prostředí OS UNIX), • spolehlivost (ošetření chyb uživatele, žádné nedefinovatelné zastavení), • ochranu dat, • otevřenost a modularitu (pro perspektivní rozšíření funkcí), • náročnost na obsluhu (příjemné uživatelské prostředí), • kvalitu servisních služeb, • přijatelnou dobu řešení úloh, • cenu.

30. Charakteristiky ASW • Předmětem našeho zájmu by měl být komplexní projekt založený na výběru velkých ASW, jejich customizaci a integraci s eventuálním dořešením a implementací těch částí, které TASW nepokrývá nebo neodpovídá požadavkům zadavatele. Moderní charakteristiky TASW • Produkt a jeho tvůrce – obsahová orientace firmy, personální struktura, počet pracovníků vývojářů nebo post implementační podpory, cenová nabídka, možnosti přizpůsobení SW jazykové nebo legislativní (podle referencí u jiných zákazníků). • Architektura a funkcionalita – oblasti pokrytí funkcemi systému, vazby mezi moduly, datová rozhraní, možnost připojení jiného systému, správa a monitorování provozu, on line dokumentace atd.

31. Charakteristiky ASW • Provozní prostředí – vymezení SŘBD, orientace na OS, orientace na HW pokud existuje. • Služby– údržba ASW, hot –line, projekční služby (analýza, úpravy, prototypy, customizace, testování integrací – kdo, jak, za jak dlouho, za kolik), školící služby, konzultační služby, monitorovací služby, optimalizace konfigurací). • Další vlastnosti ASW – možnosti customizace, jazykové prostředí, dokumentace ASW, audit ASW, ISO 9000.

32. Kategorie SW z hlediska požadavků na kvalitu • Entusiastické pgmy: SW pro vlastní potřebu, uživatelem je sám tvůrce, SW malý požadavky na kvalitu nejsou vysoké. • Komerční balíčky: kancelářské pgmy, hry, antivirové pgmy, utility. Požadavky na vyšší kvalitu z důvodu distribuce mezi zákazníky. Selhání způsobí ekonomické ztráty. • Podnikové systémy: (ERP) nároky na kvalitu ještě vyšší. Vztah mezi zákazníkem a výrobcem nebo dodavatelem užší. • SW kritický pro zdraví a životy lidí: (v nemocnicích, letecké dopravě, jaderných elektrárnách…). Selhání nezpůsobí jen zvýšení nákladů ale i lidské nebo společenské ztráty.

33. Vlastnosti SW produktu (jiný zdroj) Tyto atributy bychom měli požadovat od dobrého SW produktu: • Jednoduchost (pro uživatele), odolnost (vůči chybám) a stálost (vzhledem k pracovním postupům a dokladům) • Udržovatelnost • Provozní spolehlivost • Výkonnost • Použitelnost • Respektování zákonů a zvyklostí