Komponentové systémy
definice, vývojový proces, dokumentace rozhraní
© R. Ošlejšek and B. Bühnová
Fakulta informatiky MU
oslejsek@fi.muni.cz
PA103: OO metody IS © R. Ošlejšek, FI MU 2Jaro 2015
Inspirace světem mechanických komponent
• Automobily sestavené z
motoru, převodovky, kol, brzd, ...
• Počítače sestavené z procesoru,
pamětí, grafické karty, monitoru, ...
• Audio sestavy, sestavené z
reproduktorů, subbuferu, …
Mnoho výhod:
• Možnost rychlého sestavení celku bez znalosti vnitřního fungování jednotlivých
komponent (příklad počítače) – díky standardizovaným rozhraním
• Možnost konfigurace celku výměnou jedné z komponent (např. paměti u počítače)
• … a mnoho dalších
Motivace – Mechanické komponenty
PA103: OO metody IS © R. Ošlejšek, FI MU 3Jaro 2015
Je možné stejné výhody přenést ze světa mechanických komponent
do světa software?
• Nákup softwarových komponent od různých výrobců
• Jejich propojování bez vědomí „co je uvnitř“ do funkčních systémů
• Bezpečný upgrade jednotlivých komponent
Pokud ano, co to obnáší?
Jaké to s sebou nese možné komplikace a problémy?
Existuje už dnes podpora takového vývoje?
Motivace – Softwarové komponenty
PA103: OO metody IS © R. Ošlejšek, FI MU 4Jaro 2015
• Definice softwarové komponenty
• Charakteristiky SW komponent
– Společné s mechanickými komponentami
– Odlišné od mechanických komponent
– Komponenta vs. objekt/třída
• Middleware pro komponentové systémy
– Komponentové frameworky
– Komponentové modely
• Komponentový vývoj
– Základní business pohled
– Komplexní vývojářský pohled
– Vývojářské modely a role
– Dokumentace rozhraní komponent
• Quality of Service (QoS)
• Service Level Agreement (SLA)
Přehled přednášky
PA103: OO metody IS © R. Ošlejšek, FI MU 5Jaro 2015
A reusable software component is a logically cohesive, loosely coupled module that
denotes a single abstraction. [Booch 1987]
Software components are defined as prefabricated, pretested, self-contained,
reusable software modules – bundles of data and procedures – that perform specific
functions. [Meta Group 1994]
A software component is a software element that conforms to a component model
and can be independently deployed and composed without modification according
to a composition standard. [Heineman & Councill 2001]
A software component is a unit of composition with contractually specified interfaces
and explicit context dependencies only. A software component can be deployed
independently and is subject to composition by third parties. [Szyperski 2002]
A component represents a modular piece of a logical or physical system whose
externally visible behaviour can be described much more concisely than its
implementation. Components do not depend directly on other components but on
interfaces that components support. [UML 2.0 Standard 2004]
Definice Softwarové komponenty
PA103: OO metody IS © R. Ošlejšek, FI MU 6Jaro 2015
Komponentové systémy (Component-Based Systems) jsou konkrétní realizací
softwarových architektur, kdy:
1. Moduly = black-box komponenty komunikující výhradně skrz publikovaná rozhraní
2. Konektory = spoje a kanály zajišťující komunikaci a spolupráci zkompilovaných
modulů (komponent) implementovaných často odlišnými prostředky a nezávisle
na sobě
3. Nasazení = mapování modulů a konektorů na hardwarové (nebo softwarové)
zdroje
• Např. síťové linky, fyzické zdroje a servery v případě hardwarových zdrojů
• Např. komponentový framework či middleware v případě softwarových zdrojů
Vazba na softwarové architektury
PA103: OO metody IS © R. Ošlejšek, FI MU 7Jaro 2015
• Zapouzdření
• Rozhraní a služby na nich
– Jediný přístupový bod k
funkcionalitě komponent
• Anonymita klienta i serveru
– Komponenta při obsluze/vyslání požadavku nezná iniciátora/příjemce požadavku
• Připravenost k okamžitému použití
– Netřeba kompilovat po zapojení do systému
• Black-box znovupoužitelnost
• Snadná vyměnitelnost
– Systém je možné jednoduše konfigurovat výměnou stávajících komponent
• Jazyková nezávislost
– Každá komponenta může být implementována v jiném jazyce
Charakteristiky – Společné s mech. komponentami
PA103: OO metody IS © R. Ošlejšek, FI MU 8Jaro 2015
• Hierarchická struktura (vnitřních komponent)
– I komponenta složená z podkomponent může být skládána s dalšími komponentami – vzniká tak
hierarchická architektura
• Instanciovatelnost
– Vznik „nových komponent“ za běhu
• Dynamičnost
– Možnost změny komunikačního partnera za běhu
• Vysoká míra složitosti a variability
– Tudíž i obtížná standardizovatelnost
• Vliv (předem neznámých) fyzických zdrojů
– Extra-funkční parametry komponenty nelze odhadnout v době implementace
• Silná závislost na vnitřním stavu
– Odlišné chování v závislosti na historii
• Závislost na běhovém prostředí - middlewaru
Charakteristiky – Odlišné od mech. komponent
PA103: OO metody IS © R. Ošlejšek, FI MU 9Jaro 2015
Komponenta (vs. objekt/třída):
• Spustitelná běhová jednotka
• Definovaná rozhraními (IDL)
• Typicky složena z více tříd/objektů (hierarchicky)
• Bez viditelného zdrojového kódu (black-box/grey-box)
• Vyvinuta odděleně od ostatních komponent (pro znovupoužitelnost)
– Propojení výhradně přes rozhraní, bez přímých referencí (na rozdíl od balíků apod.)
• Kompilaci předchází zasazení do kontextu
• Závislost na běhovém prostředí (middlewaru)
Black box view
– poskytovaná a požadovaná rozhraní, (neúplná) textová dokumentace
Grey box view
– poskytované a požadované služby, architektura vnitřních komponent a jejich vnitřních
komponent (až na úroveň primitivních komponent, tvořených přímo kódem)
Čím se liší komponenta od objektu/třídy?
PA103: OO metody IS © R. Ošlejšek, FI MU 10Jaro 2015
Objekt/třída (vs. komponenta):
• Návrhová jednotka
• S viditelným zdrojovým kódem (white-box)
• Typicky navržena pro konkrétní systém
• Zasazení do kontextu (ostatních tříd) předchází kompilaci
White box view = zdrojový kód
Čím se liší komponenta od objektu/třídy?
PA103: OO metody IS © R. Ošlejšek, FI MU 11Jaro 2015
Instanciovatelnost a replikace komponent
• Kam fyzicky nasadit nově vzniklou komponentu?
• Kam ji umístit v hierarchii komponent?
Interoperabilita
• Vzájemná kompatibilita komunikujících komponent
• Kompatibilita typů v signatuře volajícího (např. int) a volaného (např. real)
• Generování a použití adaptorů a wrapperů
Nahraditelnost komponenty
• Otázka korektnosti nahrazení stávající komponenty novou (rekonfigurace systému)
• Nová komponenta by neměla
– Požadovat více
– Nabízet méně
• Nejen mezi implementacemi, ale i nahrazení specifikace implementací (při hledání komponenty
realizující návrh)
Příklady zajímavých problémů
PA103: OO metody IS © R. Ošlejšek, FI MU 12Jaro 2015
Middleware obecně
Middleware is a name for the set of software that sits between various operating systems and a higher, distributed
programming platform. [Szyperski 2002]
• Např. J2EE nebo .NET
Komponentové frameworky
A component framework is a software entity that supports components conforming to a certain standards and
allows instances of these components to be plugged into the component framework. The component framework
establishes environmental conditions for the component instances and regulates the interaction between
component instances. [Szyperski 2002]
• Např. EJB pro J2EE, nebo COM/COM+ pro .NET
• Konkrétní typ middlewaru pro komponentové systémy
Komponentové modely
A component model defines specific representation, interaction, composition, and other standards for software
components. [Heineman & Councill 2001]
• Např. EJB pro J2EE, nebo COM/COM+ pro .NET
• Na rozdíl od komponentových frameworků, které implementují běhové prostředí, zde jde spíše o sadu standardů.
Middleware pro komponentové systémy
PA103: OO metody IS © R. Ošlejšek, FI MU 13Jaro 2015
Základní představitelé:
• Komerční komponentové modely
– CCM/CORBA, EJB/J2EE, COM/.NET
– Spjaté s komponentovými frameworky pro praktickou realizaci komp. systémů
• Akademické komponentové modely
– Fractal, KobrA, PCM, SOFA, Darwin, Wright, Koala, ACME, …
– Spjaté nejčastěji s analytickými nástroji pro ověření korektnosti či predikci kvality komponentových
systémů
Existující modely mají různé pohledy na následující:
• Co se rozumí komponentou
• Jak jsou popsána rozhraní/služby
• Jak jsou komponenty skládány dohromady
Komponentové modely
PA103: OO metody IS © R. Ošlejšek, FI MU 14Jaro 2015
Run-time vs. design-time jednotka
• Run-time – implementovaný modul, pro realizaci konkrétní funkcionality
[COM/.NET, Fractal]
• Design-time – návrhový prvek, pro ohodnocení kvality navrhované komponenty
[KobrA, SOFA, PCM]
Dynamický vs. statický prvek
• Dynamický – možnost vytváření instancí za běhu
[EJB, CCM, Darwin]
• Statický – analogie mechanických komponent, komponenty pevně dané
[Wright, SOFA]
Stavový vs. bezstavový prvek
• Stavový – komponenta má vnitřní stav (paměť), analogie atributů u objektu
[CCM, EJB, KobrA]
• Bezestavový – komponenta nemá vnitřní paměť, její reakce na příchozí požadavky nejsou ovlivněny historií
[SOFA, Wright, WS]
Co se rozumí komponentou
PA103: OO metody IS © R. Ošlejšek, FI MU 15Jaro 2015
Signatury vs. protokoly vs. vstup/výstupní podmínky vs. popis chování
• Signatury – název, typy vstupních argumentů, výstupní typ
[EJB, COM/.NET, CCM]
• Protokoly – posloupnosti validních posloupností volání služeb
[PCM, SOFA, Wright]
• Vstupní/výstupní podmínky – podmínky platící před voláním a po provedení služby
[KobrA]
• Popis chování – strukturovaný (zjednodušený) popis implementace služby
[SOFA, PCM]
Tomuto tématu bude věnována zvláštní pozornost dále
Jak jsou popsána rozhraní/služby
PA103: OO metody IS © R. Ošlejšek, FI MU 16Jaro 2015
Synchronně vs. asynchronně
• Synchronně – volání služeb, volající čeká než je volání zpracováno
[Darwin, SOFA]
• Asynchronně – zasílání zpráv, volající nečeká než je zpráva zpracována
[EJB, COM/.NET, CCM]
Jednoúrovňové vs. víceúrovňové skládání
• Jednoúrovňové – složení komponent tvoří přímo systém
[EJB, COM/.NET, CCM]
• Víceúrovňové (hierarchické) – složení komponent tvoří opět komponentu, která může být dále skládána s jinými
komponentami
[Fractal, SOFA, Koala, ACME]
Jednoduché vs. násobné propojení mezi komponentami
• Jednoduché – každé rozhraní je napojeno na maximálně jednu protistranu
[SOFA]
• Násobné – jedno poskytované rozhraní může být napojeno na více požadovaných rozhraní, a naopak
[EJB, Fractal]
Jak jsou komponenty skládány dohromady
PA103: OO metody IS © R. Ošlejšek, FI MU 17Jaro 2015
Komponentový vývoj
Základní business pohled:
• Vzájemně nezávislé fáze vývoje komponent a sestavování systému.
PA103: OO metody IS © R. Ošlejšek, FI MU 18Jaro 2015
Knihovny komponent
• Urychlení vývoje
• Snížení rizika (ověřené komponenty)
Znovupoužitelnost komponent
• Nižší náklady
• Vyšší kvalita
Udržovatelnost
• Srozumitelnost
• Konfigurovatelnost
• Jazyková nezávislost
• Flexibilita, snadnost výměny
Výhody komponentového vývoje
PA103: OO metody IS © R. Ošlejšek, FI MU 19Jaro 2015
Komponentový vývoj
Komplexní vývojářský pohled:
• Fáze vývoje komponent
• Fáze sestavení systému
• Fáze nasazení systému na fyzické/logické zdroje
• Fáze ohodnocení kvality systému
Jednotlivé fáze vývoje probíhají relativně nezávisle
• Vývojář komponenty neví, do jakého kontextu bude komponenta architektem zasazena, ani na jaké
zdroje bude nasazena
• Architekt sestavující systém nezná implementaci komponent ani jejich budoucí nasazení
Vzájemná komunikace probíhá jen skrz modely dokumentující jejich výstupy → vznik
nezávislých vývojových modelů, pod zodpovědností oddělených vývojářských rolí
PA103: OO metody IS © R. Ošlejšek, FI MU 20Jaro 2015
Vývojářské modely a role
[Reussner et al.]
PA103: OO metody IS © R. Ošlejšek, FI MU 21Jaro 2015
Role: Komponentový vývojář
• Implementace a dokumentace jednotlivých komponent (zejména jejich rozhraní a omezení na
komunikaci skrz ně)
Model: Specifikace komponenty
• Popis vnitřní struktury a rozhraní vyvinutých komponent
UML:
• Diagram tříd/objektů pro primitivní komponenty
• Komponentový diagram pro složené komponenty
V obou případech
• Interakční diagramy (interakce mezi třídami/komponentami)
• Diagram aktivit (chování služby nabízené na rozhraní)
• Stavové diagramy (stavy komponenty)
Komponentový vývojář (Component Developer)
PA103: OO metody IS © R. Ošlejšek, FI MU 22Jaro 2015
Příklad – Specifikace komponenty
Příklad specifikace komponenty z pohledu chování služeb nabízených na rozhraní
(anotovaný diagram aktivit):
PA103: OO metody IS © R. Ošlejšek, FI MU 23Jaro 2015
Role: Softwarový architekt
• Sestavení komponent do celkového systému na základě popisu jejich rozhraní
• Specifikace vnějších rozhraní systému (pro komunikaci s uživateli i externími systémy) delegací vnitřních
rozhraní
• Dokumentace použitých konektorů
Model: Model sestavení systému
• Statická struktura a dynamický procesní model architektury
UML:
• Komponentový diagram
• Sekvenční diagramy
(interakce mezi komponentami)
Softwarový architekt (Software Architect)
PA103: OO metody IS © R. Ošlejšek, FI MU 24Jaro 2015
Jednoduchý příklad:
Příklad – Model sestavení systému
PA103: OO metody IS © R. Ošlejšek, FI MU 25Jaro 2015
Složitější př. modelu sestavení systému
PA103: OO metody IS © R. Ošlejšek, FI MU 26Jaro 2015
Role: Expert pro nasazení systému
• Volba fyzických zdrojů (včetně jejich parametrů)
• Návrh fyzické architektury systému
• Mapování softwarových komponent na zvolené zdroje
Model: Model nasazení systému
• Statický model mapování systémových komponent na rozvržené zdroje
UML:
• Diagram nasazení
Expert pro nasazení systému (Deployer)
PA103: OO metody IS © R. Ošlejšek, FI MU 27Jaro 2015
Příklad – Model nasazení systému
PA103: OO metody IS © R. Ošlejšek, FI MU 28Jaro 2015
Role: Doménový expert
• Vyjasnění očekávaných scénářů používání systému
• Specifikace sekvencí volání systému, očekávaných argumentů těchto volání
• Odhadnutí očekávaného počtu souběžných uživatelů
Model: Model používání systému
• Popis sekvencí volání systémových služeb uživatelem
• Informace o počtu uživatelů
UML:
• Sekvenční diagram (interakce mezi
aktérem a komponentami na rozhraní systému)
Doménový expert (Domain Expert)
PA103: OO metody IS © R. Ošlejšek, FI MU 29Jaro 2015
Příklad 1: Příklad 2:
Příklad – Model používání systému
PA103: OO metody IS © R. Ošlejšek, FI MU 30Jaro 2015
Role: QoS analytik
• Volba kvalitativních atributů k ohodnocení
• Provedení analýzy – ohodnocení jednotlivých kvalitativních kritérií celkové architektury na základě modelů
dodaných všemi rolemi
• Interpretace výsledků – impuls k modifikaci architektury
Model: Model ohodnocení kvality služeb
• Formální model obsahující informace z předchozích
modelů
• Částečně generovaný automaticky
• Podklad pro automatizovanou analýzu kvality
systému
Prostředky:
• Finite Automata (FA)
• Markov Chains (MC)
• Layered Queuing Networks (LQN)
QoS analytik (QoS Analyst)
PA103: OO metody IS © R. Ošlejšek, FI MU 31Jaro 2015
Význam:
• Anotace rozhraní komponent dostatečným množstvím informací pro jejich použití
Typy informací:
• Signatury služeb – název, typy vstupních argumentů, výstupní typ
• Protokoly doporučeného použití služeb – UML sekvenční diagramy
• Vstupní a výstupní podmínky – formální/neformální popis
• Strukturovaný popis chování služeb – UML aktivity diagramy
• Garantované kvality služeb – Quality of Service (QoS), Service Level Agreement (SLA)
Dokumentace rozhraní komponent
PA103: OO metody IS © R. Ošlejšek, FI MU 32Jaro 2015
Týkají se nefunkčních (extra-funkčních) kvalitativních atributů, jako např:
• Výkonnost (performance) – propustnost, doba odezvy, efektivita využití zdrojů
• Spolehlivost (reliability) – bezchybný provoz, dostupnost, robustnost, zotavitelnost
• Bezpečnost (security) – důvěrnost, integrita, dostupnost
Způsob specifikace
• Minimální a maximální hodnota
• Průměrná (average) a střední (mean) hodnota
• Pravděpodobnostní rozložení možných hodnot
Garantované kvality služeb
PA103: OO metody IS © R. Ošlejšek, FI MU 33Jaro 2015
Garantovaná kvalita služby:
• Anotace rozhraní s informací o kvalitě každé služby
• Vyjádřeno pro každý sledovaný kvalitativní atribut
Naivní přístup: anotace konkrétní služby service() nabízené komponentou ve stylu…
• Garantovaná doba odezvy max. 10 ms v 99.9% případů.
• Spolehlivost (bezchybný provoz) 99.9% v rámci každého volání služby.
Problém:
• Těžko mohu garantovat konkrétní čísla, když předem nevím, jaké kvality mohu předpokládat od požadovaných
(externích) služeb, jak budou rychlé, spolehlivé,…
Quality of Service (QoS)
PA103: OO metody IS © R. Ošlejšek, FI MU 34Jaro 2015
Garantovatelné kvality služby závisí na:
• Implementaci služby
• Kvalitě požadovaných (externích) služeb
• Zdrojích, na kterých je komponenta nasazena
• Způsobu použití služby
Kontext komponenty/služby
PA103: OO metody IS © R. Ošlejšek, FI MU 35Jaro 2015
Kontext služby Service1():
• Implementaci služby (Component Developer 1)
• Požadované služby (Software Architect, Component Developer 2)
• Zdroje kde je služba nasazena (System Deployer)
• Použití služby (Domain Expert)
Příklad kontextu komponenty/služby
PA103: OO metody IS © R. Ošlejšek, FI MU 36Jaro 2015
Kvality z pohledu KLIENTA SLUŽBY
Pokud je celý kontext známý – typicky v případě služeb na rozhraní (uzavřeného) systému se známým
profilem použití:
• Garantovaná doba odezvy max. 10 ms v 99.9% případů.
• Spolehlivost (bezchybný provoz) 99.9% v rámci každého volání služby.
Pokud je část kontextu neznámá – typicky v případě jednotlivých komponent:
• Assume-Guarantee specifikace – předpoklad na kontext, garance kvality služby
• Parametrizovaná specifikace – neznámé informace nahrazeny parametry
Kvality z pohledu ARCHITEKTA – neváží se na konkrétní službu, ale na zdroje systému, komponenty
nebo systém jako celek
• Zatížení (resource utilization) konkrétního CPU nepřesáhne 90%.
• Zatížení CPU1 a CPU2 je rovnoměrně rozloženo.
• Konkrétní CPU je dostupné (available) 99.9% v rámci každého měsíce
Typy QoS specifikace
PA103: OO metody IS © R. Ošlejšek, FI MU 37Jaro 2015
Specifikace spolehlivosti /Rel/ Service1():
• Assumptions:
– Rel CPU ≥ 94.33%; Y ≤ 3 v 80% případů
– Rel Service2() ≥ 93.77%; Rel Service3() ≥ 96.13%
• Guarantee:
– Rel Service1() ≥ 88.81%
Příklad – Assume-Guarantee specifikace
PA103: OO metody IS © R. Ošlejšek, FI MU 38Jaro 2015
Problém Assume-Guarantee specifikace:
• Nerealistické předpokládat znalost všech assumptions
• Silná závislost na přesnosti assumptions → hrozí výrazné zkreslení
Parametrizovaná specifikace:
• Neznámé informace o kontextu nahrazeny parametry
• Výsledek – kompletní sada modelů jednotlivých součástí kontextu
• Sensitivity analysis pro odhalení závislosti výsledku na konkrétních předpokladech
Příklad – Parametrizovaná specifikace
PA103: OO metody IS © R. Ošlejšek, FI MU 39Jaro 2015
The SLA records a common understanding about services, priorities, responsibilities, guarantees, and
warranties.
The SLA may specify the levels of availability, serviceability, performance, operation, or other
attributes of the service, such as billing.
Charakteristiky:
• Komplexnější než QoS – pohled na službu ve stylu SOA, kdy za využití služby platím, a proto chci jisté
garance
• Často doprovázeno penalizacemi poskytovatele v případě nedodržení SLA
• Inspirováno call centry a service desk systémy
• Častější uplatnění v SOA než v CBSE
Service Level Agreement (SLA)
PA103: OO metody IS © R. Ošlejšek, FI MU 40Jaro 2015
• Definice softwarové komponenty
• Charakteristiky SW komponent
– Společné s mechanickými komponentami
– Odlišné od mechanických komponent
– Komponenta vs. objekt/třída
• Middleware pro komponentové systémy
– Komponentové frameworky
– Komponentové modely
• Komponentový vývoj
– Základní business pohled
– Komplexní vývojářský pohled
– Vývojářské modely a role
– Dokumentace rozhraní komponent
• Quality of Service (QoS)
• Service Level Agreement (SLA)
Shrnutí
PA103: Object-oriented Methods for Design of Information Systems IS © R. Ošlejšek, FI MU 41Jaro 2015
Questions?