Softvérová architektúra

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 millionlines 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 Návrh: • 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)

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ť

T1 T2 T3 T4 T5 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 ...

Vý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ú.

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, ...) Vlastnosti distribuovaných systémov • 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

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 • 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): • TelefonnyZoznamb = ...;... = 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

Naming Security Trader Transaction Event Notification Persistence Externalization Properties Query Collections Relationship Concurrency Life Cycle Time Change Management Licensing CORBA services 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)

Softvérová architektúra