wiki.valek.net

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 13. Komponentový vývoj ======

Co je komponenta a jaké znáte specifikace pro komunikaci mezi komponentami. Principy výstavby programového systému z komponent. Podpora vývoje komponent v moderních prostředcích pro vývoj programových systémů.
===== Úloha =====
**Předpoklady:**
Jste vedoucím vývojového týmu pro rozsáhlý projekt  a řešíte problém vztahu objektů a komponent

**Zadání:   ** 
  * Určete, zda má vůbec smysl rozlišovat pojmy objekt a komponenta
  * Specifikujte základní rozdíly mezi objektem a komponentou
  * Může být komponenta vytvořena neobjektovým způsobem?
  * Určete místo komponent v objektových metodikách vývoje programových systémů

===== Teorie =====
Komponenta – kus znovupoužitelného kódu se specifikovanou a jasně zdokumentovanou funkcionalitou, definující jedno nebo případně i více komunikačních rozhraní, obsahujících metody, pomocí kterých lze komponentu ovládat. Měla by být univerzálně použitelná, tozn. parametrizovatelná, nicméně ne zase příliš, aby nebyla moc těžkopádná a dala se nějak rozumně používat. Komponenta musí být jasně identifikována svým identifikátorem a to i v případě, že je volána ve více instancích.

Komponentové programování je zatím nejnovější forma programování a vychází z toho, že některé části kódu se častěji opakují a je velmi pravděpodobné, že takový problém řešil už někdo před námi a pravděpodobně i lépe. Proto je lepší komponentu koupit místo vyrábět (lze přirovnat k jisté formě outsourcingu).

Do vnitřku komponenty není vidět, je utajen, jasné je pouze jedno nebo více rozhraní, která musí být co nejpodrobněji zdokumentována. Komponenty mají tu výhodu, že mohou běžet i na jiných, vzdálených počítačích, nezávisle na aplikaci, která je volá, navíc nejsou závislé ani na jazyku a platformě počítačů, které je volají. Klienti mohou jet na např. pod Windows, nicméně komponenty třeba na Linuxu, atd. Při vývoji lze komponentu přepsat nebo skládat (primárně v COMu) i z jiných komponent a v tom případě lze definovat dvě formy propagace rozhraní: containment – rozhraní vnitřní komponenty je skryto nebo aggregation – rozhraní je propagováno ven. Komponenta by neměla vědět, kdo jí používá, z jaké platformy je volána a mělo by jí to být jedno. Zároveň by měla bez problémů umožňovat, aby byla volána paralelně, opakovaně, najednou.

ORB – object request broker – rozhraní, pomocí kterého mohou být aktivovány vzdálené komponenty a s nimi komunikováno. Všechny komponentové technologie dnes dokážou komunikovat i jako inprocess, tozn. přímo – v zájmu zrychlení činnosti.

Komponentových architektur existuje více. Jednak jde o architekturu COM+ firmy Microsoft, která je přítomna v systémech Windows. V současné době ale Microsoft podporuje spíše platformu .NET a komponenty v ní vyrobené. Naštěstí .NET obsahuje nástroje, jak z něj lze volat COM a naopak. COM+ jsou binární architektury, neexistuje u nich ORB (resp, je schován ve Windows). .NET je postaven na tzv. řízeném kódu. Další architekturou je CORBA, což je obecná komponentní architektura skupiny OMG. Další jsou javovské EJB jakožto součást J2EE. Ty jsou umístěny v kontajneru, který zajišťuje jejich volání, správu paměti, bezpečnost, předávání zpráv a další služby. Mezi komponenty lze svým způsobem zařadit i webovské služby, i když ty se principiálně poněkud odlišují tím, že zpravidla nemáme šanci ovlivnit jejich umístění.

Princip je v podstatě následující – klient má v sobě funkci, která vytvoří na základě známého rozhraní komponenty tzv. proxy, což je objekt, který emuluje rozhraní komponenty tak, jako by byla vnitřní instancí objektu. Při jejím volání se ale data serializují a jsou odesílána na příslušný server, kde sedí komponenta, na stub, což je vlastně rozhraní, které to unmarshalluje – ztransformuje data do podoby vhodné pro volaný objekt a zavolá jej, stejnou cestou ale obráceně pošle zase odpověď.

U komponent se můžeme setkat s problémem verzování, kdy je stará fungující komponenta nahrazena novou s novou funkcionalitou – nemusí to fungovat. Pokud se nemění funkcionalita, ale pouze výkon, nebývá problém. Pokud se mění obojí, můžeme novou buď pojmenovat jinak, ale musí se znovu naimplementovat nebo tzv. verzovat, tozn. vložit i starý kód, což je trochu „přes koleno“.

Podpora komponent ve vývojových nástrojích je velmi slušná, většina nástrojů dokáže komponenty vizuálně zařadit do vytvářeného kódu, na základě jejich IDL (textového popisu rozhraní) dokáže obvykle automaticky vygenerovat příslušnou třídu v programu, atd. Na druhou stranu komponentové technologie bývají chápány jako enterptise oblast a jsou obvykle obsaženy ve vyšších verzích SW.
===== Praxe =====

Objekt je něco jiného – objekt je v rámci jednoho jazyka a jednoho prostředí (i když už taky ne, v .NET se dokážou volat i napříč jazyky). Nicméně při kompilaci objektově orientovaného kódu zůstanou objekty integrální součástí kódu, zatímco komponenty jsou samostatné, jsou schopny samostatné existence a to na jiném stroji, než běží klient a dokonce třeba i na jiné platformě. Na druhou stranu, mnoho vlastností je společných.

Komponenta může být vytvořena i neobjektově, v COM+ a CORBA není stanoveno, že musí být napsaná v neobjektovém prostředí, nicméně obojí mají objektové rysy (polymorfismus…). U CORBy je obsaženo v IDL např. Každopádně, stejně, způsob objektového přístupu ke komponentám je této technologii bližší a tím i jednodušší.

Podle mého názoru komponenta sice není to samé co objekt, má k němu ale velmi blízko a z hlediska implementace (proxy) se od objektu nijak neliší. Proto je podle mě bezproblémů možné v objektových metodikách tyto dvě věci nerozlišovat a nástroje pro popis objektů ([[statnice:slovnik:erd|ERD]] diagramy) používat i pro komponenty.