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.5million 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

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)

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

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)

Operatingsystem

Database system

Object management

Version management

• 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:– ľ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)

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram

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

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses

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ť

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4

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.

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

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.

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symboltable

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefinition

Symboltable

Outputdefinition

Pretty-printer

Editor

Optimizer

Codegenerator

Repository

Referenčný model ISO OSI

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

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”

Real-timecontrol system

ActuatorActuator ActuatorActuator

SensorSensorSensor SensorSensorSensor

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)

Dataprocessor

Actuatorcontrol

Actuator

Sensorcontrol

Sensor

Stimulus Response

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

Network

SC1SC2

CC1 CC2 CC3

CC5 CC6CC4

Servercomputer

Clientcomputer

s1, s2 s3, s4

c5, c6, c7

c1 c2 c3, c4

c8, c9 c10, c11, c12

• 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:

Presentation layer

Application processinglayer

Data managementlayer

• 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

Thin-clientmodel

Fat-clientmodel Client

Client

Server

Data managementApplicationprocessing

Presentation

Server

Datamanagement

PresentationApplication processing

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)

Client

Server

Datamanagement

PresentationServer

Applicationprocessing

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

Software bus

o1 o2 o3 o4

o5 o6

S (o1) S (o2) S (o3) S (o4)

S (o5) S (o6)

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

Objekt a(proces PA)

Objekt b(proces PB)

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

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

Objekt a Objekt b

Stub pre B

ORBruntime

Skeletonpre B

ORBruntime

B.idl

Typická programová realizácia

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

Príklad IDL

Object Management Architecture

Object Request Broker

Common Object Services (CORBAservices)

Naming Persistence Life Cycle Properties ...

Common Facilities(CORBAfacilities)

ApplicationObjects

...System mgmt...... ...

CORBA services• 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)