Softvérová architektúra SW architektúra zahŕňa množinu významných rozhodnutí ohľadne organizácie SW systému, okrem iných aj: identifikovanie subsystémov a ich rozhraní, vytvorenie rámca pre komunikáciu a riadenie v systéme. Často sa črtá ešte pred ukončením špecifikácie požiadaviek je vhodným nástrojom na štruktúrovanie špecifikácie požiadaviek „Have an architecture that makes sense before you write 3.5 million lines of code.“ - Patrick Naugton

Príklady Ekonomický informačný systém (FMFI UK) Subsystémy: objednávky a faktúry (inštancie: OF, CP, ZC, DN, PR, ...), telefónne účty, SUMA, úhrady každý subsystém okrem posledných dvoch má vlastnú databázu dáta sú počas behu umiestnené na súborovom serveri Akademický informačný systém (UPJŠ) trojvrstvová architektúra klient – aplikačný server – databázový server

Príklady Informačný systém univerzity subsystémy: Finančný IS Riadenie ľudských zdrojov Študijná agenda Veda a výskum Knižnica Automatizovaný identifikačný systém Stravovanie vzájomné prepojenie: centrálna databáza alebo samostatné systémy ? Počítačové siete – vrstvová architektúra

Miesto architektúry v návrhu vytvorenie architektúry, špecifikácia subsystémov rozdelenie subsystémov na moduly a špecifikácia týchto modulov návrh dátových štruktúr návrh algoritmov subsystém - relatívne nezávislá súčasť systému; skladá sa z modulov modul - užšie spolupracuje s ostatnými modulmi

Popis architektúry Statický model štruktúry Dynamický model (procesy) Popis rozhraní subsystémov Popis dátových tokov medzi subsystémami ...

Výber architektúry … (príklady) …pre výkon: lokalizovať kritické operácie v malom množstve subsystémov s obmedzenou komunikáciou (t.j. skôr väčšie ako menšie subsystémy) …pre bezpečnosť: vrstvová architektúra s chránenými zdrojmi v nižších vrstvách so striktne obmedzeným prístupom …pre spoľahlivosť: opäť, lokalizovať kritické operácie do niekoľko málo subsystémov …pre dostupnosť: redundantné subsystémy s možnosťou výmeny a upgradu bez zastavenia systému …pre udržiavateľnosť: relatívne malé, samostatné subsystémy, ktoré môžu byť ľahko upravované; obmedzenie zdieľaných dátových štruktúr

Štrukturálne modely (ako vyzerá štruktúra systému – „from mud to structure“) Central Repository Model Layered Model Data Abstraction Model Pipes and Filters Model Modely riadenia centralizované modely Call and Return Model The Manager Model decentralizované modely Broadcast Model Interrupt-driven Model existujú doménovo nezávislé a doménovo závislé modely

Central Repository Model Dve základné schémy pre výmenu údajov: centrálna „databáza“, ku ktorej jednotlivé subsystémy pristupujú každý subsystém udržiava svoje vlastné údaje (a komunikujú výmenou správ alebo iným spôsobom) Ak je dát veľa - výhodná býva zdieľaná db príklady: MIS, CAD, CASE, ...

Príklad: CASE Toolset centrálna db môže byť pasívna alebo aktívna (sama upovedomuje príslušné subsystémy pri objavení sa relevantných údajov)

Vlastnosti efektívny spôsob zdieľania veľkého množstva dát komunikujúce strany sa nemusia starať o „druhú stranu“ centrálne riešené zálohovanie, bezpečnosť, prístupové práva, zotavenie (repository manager) viditeľný spôsob výmeny dát (cez dátový model), ľahká integrácia nástrojov podporujúcich tento model musí existovať jednotný dátový model (kompromis) zmeny v modeli sú ťažko realizovateľné jednotlivé moduly môžu mať rôzne požiadavky na zálohovanie, bezpečnosť, zotavenie … nie je jednoduché distribuovať repository na viacero počítačov (otázky redundancie dát, inkonzistencií …)

Layered Model organizuje systém do postupnosti vrstiev, z ktorých každá poskytuje definovanú množinu služieb vrstva N je implementovaná pomocou služieb vrstvy N-1 (alternatívne: pomocou služieb vrstiev 1 až N-1)

Nevýhody (najmä pri striktnej verzii modelu): Príklady: Open Systems Interconnection, Ada Programming Support Environment, niektoré OS Výhody: prehľadnosť jednoduchosť modifikácie, portabilita Nevýhody (najmä pri striktnej verzii modelu): nie je vždy možné systém organizovať týmto spôsobom (isté služby sú potrebné vo všetkých vrstvách) problém s efektívnosťou

Data Abstraction Model Prístup založený na abstraktných dátových typoch skrývajúcich interný stav, ktorý je prístupný len cez definované operácie rozhrania. Komunikácia je spravidla založená na volaní metód; je možné ju distribuovať

Pipes and Filters Model Vhodný, keď aplikácia potrebuje vykonať sériu nezávislých transformácií na prúde dát. Obvyklá implementácia - vložiť jednotlivé transformácie do procesov a tie spojiť prostriedkami OS (pipes). Transformácie majú malý alebo žiadny lokálny stav. Môžu prebiehať sekvenčne (“batch sequential model”) alebo paralelne; môžu byť distribuované. Príklad: kompilátor, dávkové spracovanie platieb ... T1 T2 T3 T4 T5

Výhody: Nevýhody: ľahké znovupoužitie transformácií jednoduché rozširovanie systému pridávaním transformácií pružnosť pri rozhodovaní o sekvenčnom-paralelnom a lokálnom-distribuovanom spracovaní Nevýhody: potreba dohodnutia formátu pre prenášané údaje (buď len medzi komunikujúcimi transformáciami alebo globálne) overhead pri vytváraní a analyzovaní toku dát je to dosť špecifický model (napr. problém s GUI)

Modelovanie riadenia Modely štruktúry neobsahujú informáciu o odovzdávaní riadenia Dva hlavné prístupy k riadeniu: centralizované riadenie Call and Return Model The Manager Model riadenie udalosťami Broadcast Model Interrupt-driven Model

Centralizované riadenie jeden zo subsystémov je určený ako „riadiaci“ Call and Return Model riadenie sa odovzdáva volaním procedúr a návratmi z nich je jeden tok riadenia (thread of control) vhodný pre sekvenčné systémy, jednoduchý na analýzu distribuovateľný (RPC)

Centralizované riadenie 2 The Manager Model jeden subsystém zodpovedá za štartovanie, zastavovanie a koordináciu ostatných procesov (subsystémov alebo modulov, ktoré bežia paralelne s inými procesmi) riadiaci subsystém často beží v nekonečnej slučke („event-loop model“)

Riadenie udalosťami Riadenie sa realizuje udalosťami (generovanými prostredím systému alebo inými subsystémami) Časovanie udalostí nie je (na rozdiel od „bežného vstupu“) ovládané prijímajúcim subsystémom Hlavné modely: Broadcast Model: udalosť je – teoreticky – posielaná všetkým subsystémom, reagujú na ňu tie, ktoré reagovať vedia Interrupt-driven Model: používané výlučne v real-time systémoch – udalosť vo forme prerušenia je zachytená a spracovaná príslušným ovládačom Iné: spreadsheets, expertné systémy

Broadcast Model Subsystémy registrujú záujem o prijímanie istých udalostí – keď tieto nastanú, riadenie sa odovzdá príslušnému subsystému (resp. viacerým) Relatívne jednoduchá evolúcia, jednoduchá distribuovateľnosť Subsystém generujúci udalosť však nevie, či a ktorý príjemca ju spracoval, ťažšie sa dokazuje správnosť

Interrupt-driven Model Vhodný keď sa požaduje okamžitá reakcia na udalosť (hard realtime systémy) Takto postavený systém je zložitý a náročný z pohľadu overovania správnosti.

Iné modely Communicating Processes (message passing) Client-Server Object Request Broker Reflection Microkernel Virtual Machine Model-View-Controller ... Niektorým z týchto modelov sa hovorí aj architektonické vzory.

Doménovo špecifické modely generické modely vznikajú abstrakciou z množiny reálnych systémov, „bottom-up“ ľahšie sa používajú v praxi príklady: kompilátor, RT systém, drivery, ... referenčné modely vznikajú skôr zo štúdia domény, „top-down“ môžu byť použité pre implementáciu, ale často slúžia pre štúdium, porovnávanie implementácií, ... príklady: ISO OSI, CASE, ...

Kompilátor Komponenty: lexikálna analýza tabuľka symbolov syntaktická analýza sémantická analýza optimalizácia generovanie kódu Tieto komponenty môžu byť usporiadané rôznymi spôsobmi podľa všeobecných architektonických modelov.

Referenčný model ISO OSI Application

Špecifická oblasť: real-time systémy RT systém je systém, ktorého kritérium pre správnosť je: správne výsledky dodané v určenom čase. “Mäkký” RT systém - funkčnosť je v prípade zdržania obmedzená “Tvrdý” RT systém - v prípade zdržania nefunkčný RT systémy monitorujú a riadia svoje prostredie, sú nevyhnutne spojené s hardvérovými zariadeniami: senzory - zbierajú údaje z prostredia aktuátory - ovplyvňujú prostredie

Základná schéma “sensor-system-actuator”

Architektúra RT systémy musia na isté druhy stimulov definovaným spôsobom odpovedať. Časové limity pre odpovede sú pre jednotlivé druhy stimulov rôzne, čomu sa musí prispôsobiť aj architektúra týchto systémov. Klasické sekvenčné spracovanie je často nepostačujúce. Architektúra pozostáva z paralelne bežiacich procesov/threadov (na 1 alebo viacerých procesoroch), často pod správou jednoduchého operačného systému (real-time executive)

Real-Time Executive

Real-time executive Obsahuje spravidla tieto komponenty: hodiny reálneho času obsluha prerušení scheduler (výber procesu - podľa priority, plánovanej dĺžky behu, deadline) správa zdrojov (pamäť, procesor(y)) Pri systémoch s nepretržitou prevádzkou: configuration manager fault manager

Špecifická oblasť: distribuované systémy V minulosti bežala väčšina veľkých systémov na mainframoch s terminálmi. Hlavné skupiny dnes: PC systémy bežiace na osobnom počítači (na pracovnej stanici) - programy typu Office, grafické programy, … “Vložené” (embedded) systémy, ktoré sú súčasťou iných zariadení - domáce spotrebiče, auto, … Distribuované systémy, ktoré bežia na voľne spojenej skupine procesorov (počítačov) spojených sieťou - sieť bankomatov, rezervačné systémy, groupware, ... Hranice medzi kategóriami sa postupne stierajú.

Vlastnosti distribuovaných systémov Prínosy: zdieľanie prostriedkov otvorenosť paralelné spracovanie škálovateľnosť odolnosť voči výpadku Ťažkosti: zložitosť (pochopenie, overenie: správnosti, výkonu, ...) bezpečnosť (autenticita, integrita, dôvernosť) údržba (rôzne verzie OS na jednotlivých počítačoch) nedeterminickosť všeobecné problémy paralelného spracovania (synchronizácia, ...) Typické architektúry: klient-server distribuované objektové architektúry

Middleware Komponenty v distribuovaných systémoch môžu byť napísané v rôznych jazykoch a bežať na rôznych platformách, s rôznou reprezentáciou údajov a komunikačnými protokolmi Softvér zabezpečujúci vzájomné prepojenie - middleware Príklady: prístup k databázam (ODBC, JDBC, ...), transakčné monitory, object request brokery, konvertory dát, „messaging“ systémy ...

Model „klient-server“ Aplikácia je modelovaná ako množina služieb poskytovaných servermi pre klientov Klient pozná identitu servera/serverov, server nepozná vopred klientov

Príklad – typicky používané rozdelenie v business systémoch: Návrh rozdelenia úloh medzi klientov a servery by mal odrážať logickú štruktúru aplikácie Príklad – typicky používané rozdelenie v business systémoch: Prezentačná vrstva - komunikácia s používateľom Aplikačná vrstva - funkčnosť špecifická pre danú aplikáciu Dátová vrstva - správa a údržba údajov

2-vrstvová architektúra „Tenký klient“ - výhoda: nižšie nároky na HW klienta (nemusí to byť ani vždy plne funkčné PC), ľahšia údržba „Tučný klient“ - výhoda: odľahčenie servera

3-vrstvová architektúra Lepšia škálovateľnosť - spočiatku môže byť aplikačný a dátový server na 1 počítači, neskôr môže byť vytvorený jeden alebo viacero samostatných aplikačných serverov. Príklad: aplikačný server realizovaný na webserveri, pristupujúci k databáze cez SQL Multi-tier: napríklad „integračný server“ (integrácia údajov z viacerých databáz)

Výber architektúry Tenký klient Tučný klient 3-vrstvová architektúra tradičné systémy, kde je ťažké oddeliť aplikačnú od dátovej vrstvy výpočtovo intenzívne aplikácie (kompilátor) so žiadnou alebo nevýznamnou dátovou vrstvou Tučný klient ak je aplikačná vrstva realizovaná štandardným balíkom (napr. Excel) na klientovi výpočtovo náročné spracovanie údajov (napr. vizualizácia dát) relatívne stabilná funkčnosť v prostredí so zabezpečenou údržbou systému 3-vrstvová architektúra veľké aplikácie so stovkami/tisíckami používateľov aplikácie, kde sa štruktúra údajov aj aplikačná logika môže meniť aplikácie využívajúce údaje z viacerých databáz

Model „distribuované objekty“ Všeobecnejší prístup - stierajú sa rozdiely medzi klientami a servermi (aj keď na úrovni individuálnych interakcií tento rozdiel je prítomný) Základným komponentom je objekt poskytujúci služby cez definované rozhranie Pružnosť, otvorenosť, škálovateľnosť, rekonfigurovateľnosť. Middleware (broker): CORBA, DCOM, Java RMI

CORBA CORBA (Common Object Request Broker Architecture) je prostriedok pre komunikáciu v distribuovanom heterogénnom prostredí. uľahčuje písanie distribuovaných aplikácií umožňuje interoperabilitu komponentov písaných rôznymi vývojármi v porovnaní s „čistým“ TCP/IP je ako Java so strojovým kódom Štandard skupiny OMG (Object Management Group), www.omg.org Vývoj od začiatku 90-tych rokov

Komunikácia v architektúre CORBA Základný princíp: Objekt a volá metódu objektu b. zaznamy = b.vyhladaj (“Novák”) ORB zabezpečuje: prenesenie (a prípadnú konverziu) informácie o tom, ktorý objekt je volaný (b), ktorá z jeho metód je volaná (vyhladaj), aké sú hodnoty parametrov (“Novák”) spustenie metódy vyhladaj objektu b prenesenie výsledku odovzdanie výsledku objektu a v prípade potreby zabezpečuje aktiváciu a deaktiváciu objektu b

Ako sa odkazuje na objekty – Object References Object Reference je smerník na objekt Programátor ho vidí takto (v Jave): TelefonnyZoznam b = ...; ... = b.vyhladaj („Novak“); V C++: TelefonnyZoznam_var b = ...; ... = b->vyhladaj („Novak“); Programátor volajúceho kódu nemusí vedieť, kde sa volaný objekt nachádza, v akom jazyku je napísaný a či vôbec v existuje ako objekt v pamäti (môže byť spustený na požiadanie). Musí vedieť, aké operácie môže volať (musí poznať rozhranie).

Object References 2 „V skutočnosti“ Object Reference vyzerá asi takto: IOR:0195fd7a1400000049444c3a5065726d417263686976653a312e300001000000000000002c000000010100000f0000003135382e3139352e31362e3231310000020400000c00000035e85e768504522700000001 Type ID: "IDL:TelefonnyZoznam:1.0" Profiles: 1. IIOP 1.0 158.195.16.211 1026 0x35e85e768504522700000001 IOR je Interoperable Object Reference, štandardizovaný formát pre smerník na objekt Host Port Object Key

Typická programová realizácia Sú definované napojenia (bindings) na tieto jazyky: C, C++, Smalltalk, Ada, COBOL, Java. Okrem statického rozhrania existuje možnosť dynamických volaní, dokonca dynamického prijímania volaní.

Príklad IDL interface Count { void set_value (in long value); long get_value (); void increment (); void decrement (); }; Jazyk IDL, jazykové napojenia, API pre ORB, ako aj protokol pre komunikáciu medzi jednotlivými ORB sú štandardizované.

Object Management Architecture

CORBA services CORBA facilities Naming Security Trader Transaction Event Notification Persistence Externalization Properties Query Collections Relationship Concurrency Life Cycle Time Change Management Licensing CORBA facilities common: System management, User interface, ... domain-specific: insurance, banking, telecommunications, ...

Literatúra Ian Sommerville: Software Engineering, 6th Edition, Pearson Education, 2001 (kapitoly 10, 11, 13)