Hlavní menu
Nástroje |
ÚvodTento tutoriál byl napsán, aby vám pomohl začít s komponentově orientovaným programováním. Neposkytne vám kompletní popis komponentového světa, ale poskytne vám základní znalosti potřebné pro další studium. Součástí tohoto tutoriálu je jak teoretický základ, tak praktické ukázky. Aby byl začátek co nejjednodušší, příklady jsou popisovány v prostředí Eclipse (popř. SpringSource Tool Suite – což je Eclipse s pluginy pro vývoj Spring a OSGi) a Visual Studia (.NET prostředí) Na této úvodní stránce jsou definovány základní pojmy komponentového světa. V následujících čtyřech částech (1., 2., 3., 4.) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku. Autory tutoriálu jsou členové výzkumné skupiny spolehlivých softwarových architektur na Katedře informatiky. NavigaceÚvod do komponentZde pojednáme o "teoretických" základech komponentového programování a přístupu k designu aplikací. Prakticky jsou aplikace ukázány v kapitolách o jednotlivých technologiích. Proč komponentově orientované programováníV posledních deseti letech získává tento styl na důležitosti. Můžeme se setkat s pojmy jako Component-based Software Engineering (CBSE), nebo Component-based Development (CBD). V průběhu let vzniklo několik různých pohledů na tuto problematiku, z kterých pak vznikly popisy konkrétních způsobů jak komponenty programovat, spojovat a využívat – specifikace, jimž říkáme komponentové modely. Základní myšlenka je však stále víceméně stejná. Aplikaci postupně dělíme na menší, samostatné a kompletní části, kterým říkáme komponenty. Implementace komponenty není vidět, místo toho je k dispozici její rozhraní (interface) přes které se komponenta používá (npř. se volají metody interface) a které má kompletně popsanou specifikaci (kontrakt), aby volající věděl, co může očekávat. Toto byly základní pojmy, které budeme v následujících kapitolách popisovat do větší hloubky. Výhodou komponentového přístupu je, že dává možnost
Nevýhodou pak může být
Základní pojmyTento text vychází z práce F.Bachman a kol Technical Concepts of Component-Based Software Engineering, 2nd Edition. Doporučeno přečíst pro podrobnější pochopení problematiky.  KomponentaKomponenta je softwarový balík, který poskytuje ucelenou, samostatně užitečnou funkčnost. Tento balík je možné samostatně distribuovat a nasadit do provozního prostředí. Aplikace se vytvářejí na základě principu kompozice z více komponent. Implementace komponenty je obvykle v objektovém jazyce a představuje ji jeden nebo několik málo balíků, modulů nebo jmenných prostorů (dle programovacího jazyka). Implementace, tj. používané objekty, funkce, data, by měla zůstat skrytá, viditelné by mělo být pouze rozhraní (interface), přes které se bude komponenta používat. Tomuto principu se říká black-box model; v reálném světě je v čisté podobě téměř nedosažitelný (i ze zkompilovaného kódu se dá vždy něco získat). Třetí strana (kdokoliv, kdo komponentu používá) má k dispozici pouze viditelný interface a specifikaci komponenty. Konkrétní definice softwarové komponenty se liší v závislosti na modelu, ale obecně platí:
Komponentové rozhraní (interface)Základní princip komponentového softwarového inženýrství (CBSE) je oddělení veřejné a interní části komponent, založený na zásadě skrývání informace (information hiding). Implementace komponent je neveřejná (black-box) a je skrytá za popsaným rozhraním. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není definována v rozhraní. Implementace komponenty je tedy "izolovaná", což znamená, že komponenta nesmí záviset na svém okolí jinak, než jak explicitně deklaruje v rozhraní. Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí (poskytuje) a co pro to potřebuje. Rozhraní může být popsáto buď programovacím jazykem, nebo pomocí IDL – Interface definition language. Díky rozhraní může být mezi dvěmi komponentami navázána komunikace, pokud obě strany dodržují kontrakt v něm definovaný - tedy že klientská komponenta používá servisní tak, jak tato deklaruje. Obvykle je třeba rozlišovat a kontrolovat verze rozhraní, jelikož každá verze komponenty může mít jiné rozhraní. Kontrakty komponent a interakceKontrakt definuje „práva a povinnosti“ obou (všech) stran interakce tak, aby zajistil dobré spojení spolupracujících komponent. Úrovně kontraktů a interakce se rozlišují na následující typy:
Kontrakty se mohou zúčastněnými stranami vyjednávat a teoreticky se mohou měnit za běhu. Teoreticky je také možné, aby se zúčastněné strany předem domluvily, kdy kontrakt vyprší. Komponentový modelKomponentový model specifikuje, co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy komponent, požadované služby, atd. Jde tedy o abstraktní definice struktur a pravidel, jako je tomu například u specifikací OSGi. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií. Kategorie založené na sémantice:
Kategorie založené na syntaxi:
U posledních dvou případů musí implementace komponenty být vytvořena v nějakém programovacím jazyce. Komponentový frameworkKomponentový framework je implementací komponentového modelu. Jeden framework může implementovat více modelů, než jen jeden. Komponentový framework poskytuje množství služeb (runtime services), které obvykle zařizují běh a komunikaci komponent, případně další podpůrné služby. V mnoha ohledech jsou komponentové frameworky podobné operačním systémům, ačkoliv pracují na mnohem vyšší úrovni abstrakce. Příkladem frameworků a jejich vztahu ke komponentovým modelům jsou projekty Felix, Equinox a ProSyst mBS, které jsou všechny korektními implementacemi OSGi. Formy kompozice komponentRozdělení viz Bachmann et al: Technical Concepts, vol. II. Vzájemné vztahy komponenty a způsoby jejich znázornění
 Framework-komponenta
 Frameworky mezi sebou
 Proces vývoje komponentV komponentově orientovaném vývojovém procesu můžeme identifikovat několik fází vývoje od nápadu až k běžící aplikaci. V závislosti na konkrétním komponentovém modelu pak mohou být některé z těchto fází více, či méně rozsáhlé, či úplně chybět. Návrhová fázeAby byla snížena složitost (komplexnost) aplikace, rozdělí se aplikace na začátku této fáze na několik logických celků (komponent), které mají jasně popsanou funkcionalitu. Pro každou komponentu jsou pak definovány služby, které bude poskytovat a které bude požadovat. Tento postup se postupně opakuje, dokud nejsou dílčí komponenty primitivní (dostatečně jednoduché k implementaci – neskládá se z dalších komponent), nebo již existují (ty se mohou skládat i z několika primitivních komponent) a tudíž mohou být použity znovu (reused). Výsledkem pak je množství primitivních komponent, které se postupně skládají a vytvářejí větší, komplexnější komponenty, aby nakonec vytvořily celou aplikaci. Design aplikace je obvykle popisován pomocí UML (Unified Modeling Language). Vytvořený model komponenty však UML nepopisuje dostatečně, proto se používají další jazyky tzv. description languages. Většina z nich jsou mutace, nebo rozšíření IDL (Interface Description Language). Tyto jazyky definují rozhraní jako množinu metod s parametry. Některé mohou být navíc použity i k definici properties, konstant, struktur a výjimek. Tyto jazyky mohou dále definovat i architekturu a framy (vysvětlení níže). Architektura je hierarchický model, který popisuje aplikaci. Určuje mimo jiné, zda je použitá komponenta primitivní (neskládá se z dalších komponent), nebo zda se skládá z dílších komponent (pod-komponent), čemuž říkáme frame (kostra, rámec). Uživatel komponenty, která není primitivní, má možnost vidět všechny vnořené komponenty. Implementační detaily jsou však skryty. Vývojová fázeDruhá fáze je vývojová. V této fázi je vyvíjen kód pro primitivní komponenty. Většina komponentových modelů nabízí možnost generovat část zdrojového kódu na základě popisu komponenty (product description language). Může generovat třídy, prázdné metody a rozhraní. Doplněný a následně zkompilovaný kód tvoří komponentu, která je ve vývoji dále použivána. Fáze sestaveníVe fázi sestavení jsou všechny komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou aplikaci (nebo kořenovou komponentu), zatímco potomci každého uzlu reprezentují komponenty, ze kterých je jejich rodičovský uzel složen. Listy stromu jsou pak komponenty, které jsou použity pro sestavení – nově vytvořené, či znovu používané (reused). V této fázi mohou být rovněž nastaveny hodnoty properties jednotlivých komponent – defaultní konfigurační data, která mají podobu XML souboru, nazývaného assembly descriptor. Fáze nasazeníPoslední fáze vedoucí k fungující aplikaci. Zde jsou konfigurační hodnoty obsažené v assembly descriptoru upraveny individuálním potřebám. Komponenty jsou rozděleny do deployment units (DU), dle toho, na jakém serveru bude komponenta běžet (na jeden server jedna deployment unit, pokud je jen jeden server, tak patří všechny komponenty do jedné deployment unit), a dále jsou tyto DU nakonfigurovány, opět v podobě XML souboru, který nazýváme deployment descriptor. CertifikaceNěkdo důvěryhodný vydá prohlášení o certifikovaném subjektu. Certifikovat je možné (subjekty certifikace):
Certifikace je důležitá například pro predikci výsledku kompozice (výsledných vlastností celku). Bez možnosti predikce takového výsledku je hodnota certifikace (zvláště částí) málo hodnotná. Klíčové zdroje informacíKomponenty obecně
Technologie
Doplňkové zdroje
Patří do KategorieProjekty, KategorieNavody |