1. 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

2. 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

3. 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

4. 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

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

6. 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

7. Š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

8. 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, ...

9. 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)

10. 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í …)

11. 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)

12. 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

13. 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ť

14. 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

15. 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)

16. 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

17. 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)

18. 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“)

19. 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

20. 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ť

21. 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.

22. 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.

23. 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, ...

24. 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.

27. Referenčný model ISO OSI
Application

28. Š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

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

30. 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)

31. Real-Time Executive

32. 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

33. Š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ú.

34. 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

35. 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 ...

36. 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

37. 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

38. 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

39. 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)

40. 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

41. 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

42. 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),
Vývoj od začiatku 90-tych rokov

43. 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

44. 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).

45. Object References 2 „V skutočnosti“ Object Reference vyzerá asi takto:
IOR:0195fd7a c3a d a312e c f e e31362e c e85e
Type ID: "IDL:TelefonnyZoznam:1.0"
Profiles:
1. IIOP x35e85e
IOR je Interoperable Object Reference, štandardizovaný formát pre smerník na objekt
Host
Port
Object Key

46. 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í.

47. 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é.

48. Object Management Architecture

49. 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, ...

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