Hlavní menu

Nástroje

UvodDoKomponent / HomePage

View (print) - Edit page | Recent changes - Page history

Updated 28 January 2015, 15:19 by Eduard Chromik

UvodDoKomponent.HomePage History

Hide minor edits - Show changes to output

28 January 2015, 15:19 by Eduard Chromik -
Changed lines 3-4 from:
Tento 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] – což je Eclipse s pluginy pro vývoj Spring a OSGi).
to:
Tento 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í [[http://eclipse.org/ | Eclipse]] (popř. [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] – což je Eclipse s pluginy pro vývoj Spring a OSGi) a Visual Studia (.NET prostředí)
28 January 2015, 14:49 by Eduard Chromik -
Changed line 203 from:
to:
* Introduction to OSGi - Spring DM [[part 1 -> http://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.html ]] [[part 2 -> http://www.javaworld.com/article/2077853/java-se/hello--osgi--part-2--introduction-to-spring-dynamic-modules.html]]
Added lines 209-211:


22 January 2015, 16:21 by PremekBrada -
Changed lines 13-14 from:
Zde pojednáme o "teoretických" základech kommponentového programování a přístupu k designu aplikací. Prakticky jsou aplikace ukázány v kapitolách o jednotlivých technologiích.
to:
Zde 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.
22 January 2015, 15:11 by PremekBrada -
22 January 2015, 15:08 by PremekBrada -
Changed lines 113-119 from:
„Normální“ spojení komponent; v praxi častý způsob realizace je pomocí [[Dependency Injection -> IoC]].

Attach:komp-komp.png
Vnoření komponent – hierarchie

Attach:komp-subkomp.png
to:
* „Normální“ spojení komponent; v praxi častý způsob realizace je pomocí [[Dependency Injection -> IoC]].

Attach:komp-komp.png

* Vnoření komponent – hierarchie

Attach:komp-subkomp.png
Changed lines 123-126 from:
**Nasazení komponenty do frameworku
Attach:comp-fra.png
**Plug-In – rozšíření vnořeného frameworku komponentou
Attach:fra-comp2.png
to:
*Nasazení komponenty do frameworku

Attach:comp-fra.png

*Plug-In – rozšíření vnořeného frameworku komponentou

Attach:fra-comp2.png
Changed lines 132-136 from:
**Vnoření frameworků
Attach:fra-fra.png
**Spojení komponent z různých frameworků
Attach:comp-fra-fra-comp.png
to:

*Vnoření frameworků

Attach:fra-fra.png

*Spojení komponent z různých frameworků

Attach:comp-fra-fra-comp.png

22 January 2015, 15:07 by PremekBrada -
Changed lines 109-110 from:
Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]. V praxi častý způsob kompozice je pomocí [[Dependency Injection -> IoC]].
to:
Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]].
Changed lines 112-114 from:
**„normální“ spojení komponent
to:

„Normální“ spojení komponent; v praxi častý způsob realizace je pomocí [[Dependency Injection -> IoC]].
Changed lines 116-117 from:
**Vnoření komponent – hierarchie
to:
Vnoření komponent – hierarchie
Added line 119:
Added line 121:
22 January 2015, 15:05 by PremekBrada -
Changed lines 80-81 from:
Komponentový 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. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.
to:
Komponentový 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 -> http://www.osgi.org/Specifications/HomePage]].

Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.
Changed lines 94-95 from:
*Jazyky s popisem architektury (ADL) – UML 2.0, SOFA program musí být vytvořen v nějakém progr. jazyce
to:
*Jazyky s popisem architektury (ADL) – UML 2.0, SOFA

U posledních dvou případů musí implementace komponenty být vytvořena v nějakém programovacím jazyce.
Changed lines 100-102 from:
Komponentový 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.

to:
Komponentový 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 -> http://felix.apache.org/]], [[Equinox -> http://eclipse.org/equinox/]] a [[ProSyst mBS -> http://dz.prosyst.com/devzone/OtherFields]], které jsou všechny korektními implementacemi OSGi.

22 January 2015, 14:54 by PremekBrada -
Changed lines 86-87 from:
*Komponenty jako architektonické jednotky – [=UML2.0=], SOFA
to:
*Komponenty jako architektonické jednotky – [=UML 2.0=], SOFA, OSGi
Changed lines 92-93 from:
*Jazyky s popisem architektury (ADL) – UML2.0, SOFA program musí být vytvořen v nějakém progr. jazyce
to:
*Jazyky s popisem architektury (ADL) – UML 2.0, SOFA program musí být vytvořen v nějakém progr. jazyce
22 January 2015, 14:54 by PremekBrada -
Changed lines 65-69 from:
Kontrakty by měly zajistit dobré spojení rozhraní, určit „práva a povinnosti“ obou (všech) stran. 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ší.

!!!!Úrovně kontraktů a interakce:

*syntaktická – typy, pole, metody, …
to:
Kontrakt 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:

*syntaktická – typy, signatury metod
Changed lines 71-74 from:
*chování (průběh) – omezení kompozice, (vnitřní chování)


to:
*chování – stavové nebo procesní modely
*mimo-funkční - kvalitativní vlastnosti (rychlost apod.) daného rozhraní nebo komponenty

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


Deleted lines 81-82:
Dále jsou popisována dvě tato rozdělení.
Added line 83:
Changed lines 86-87 from:
*Komponenty jako architektonické jednotky – UML2.0, SOFA
to:
*Komponenty jako architektonické jednotky – [=UML2.0=], SOFA
Added line 89:
22 January 2015, 14:50 by PremekBrada -
Changed lines 74-93 from:
!!! Formy kompozice komponent

Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]. V praxi častý způsob kompozice je pomocí [[Dependency Injection -> IoC]].

!!!!Vzájemné vztahy komponenty a způsoby jejich znázornění
**„normální“ spojení komponent
Attach:komp-komp.png
**Vnoření komponent – hierarchie
Attach:komp-subkomp.png
!!!!Framework-komponenta
**Nasazení komponenty do frameworku
Attach:comp-fra.png
**Plug-In – rozšíření vnořeného frameworku komponentou
Attach:fra-comp2.png
!!!!Frameworky mezi sebou
**Vnoření frameworků
Attach:fra-fra.png
**Spojení komponent z různých frameworků
Attach:comp-fra-fra-comp.png
to:
Added lines 95-115:

!!! Formy kompozice komponent

Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]. V praxi častý způsob kompozice je pomocí [[Dependency Injection -> IoC]].

!!!!Vzájemné vztahy komponenty a způsoby jejich znázornění
**„normální“ spojení komponent
Attach:komp-komp.png
**Vnoření komponent – hierarchie
Attach:komp-subkomp.png
!!!!Framework-komponenta
**Nasazení komponenty do frameworku
Attach:comp-fra.png
**Plug-In – rozšíření vnořeného frameworku komponentou
Attach:fra-comp2.png
!!!!Frameworky mezi sebou
**Vnoření frameworků
Attach:fra-fra.png
**Spojení komponent z různých frameworků
Attach:comp-fra-fra-comp.png
22 January 2015, 14:49 by PremekBrada -
Changed lines 44-47 from:
Komponenta je package, modul, namespace (dle programovacího jazyka), který sdružuje podobnou funkcionalitu, případně třídy. Implementace komponenty (používané objekty, funkce, data) by měla zůstat skrytá, viditelný by měl být pouze interface, přes který se bude komponenta používat. Tomuto principu se říká black-boxový model a je v reálném světě 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.
to:
_Komponenta_ 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.
Changed lines 58-72 from:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako Isolation of Components. 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í.

Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí 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 (contract – když jedna komponenta používá druhou pomocí rozhraní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.

!!!! Dependency Injection a Inversion of Control

Dependency injection je proces, kdy si objekty definují své závislosti (dependency – odkaz na jiný objekt, s kterým pracují) pouze přes:
* argumenty, se kterými se volá kontruktor,
* argumenty, které se předají nějaké statické tovární metodě (factory – vytváří různé objekty s různou konfigurací)
* properties, které jsou nastaveny objektu potom, co je vytvořený

Dependency objekt, který je vytvořen frameworkem, je po vytvoření přímo předán (injected) objektu, který ho použije. Ve skutečnosti je tedy proces definování závislosti v základě opačný běžnému postupu, protože běžně si objekt/komponenta hledá sama objekt, na kterém závisí. Odtud název Inversion of Control ([=IoC=])

Oba výrazy tedy znamenají prakticky to samé.
to:
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í.

Added line 68:
Changed lines 73-75 from:
!!! Formy kompozice
Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
to:

!!! Formy kompozice komponent

Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]. V praxi častý způsob kompozice je pomocí [[Dependency Injection -> IoC]].
22 January 2015, 14:32 by PremekBrada -
Changed lines 17-20 from:
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á (volají se metody interface) a má kompletně popsanou funkcionalitu (specifikaci, kontrakt), aby volající věděl, co může očekávat.
to:
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.
Changed lines 23-26 from:
!!!! Výhody

Komponenty by měly:
to:
*Výhodou* komponentového přístupu je, že dává možnost
Changed lines 27-29 from:
*zlepšit předvídatelnost chování, …

!!!! Nevýhody
to:
* umožnit i ne-programátorům skládat aplikace z hotových dílů,
*zlepšit předvídatelnost chování software.

*Nevýhodou* pak může být
Changed lines 33-35 from:
*mnoho modelů, frameworků – brzdí rozvoj většího společného trhu,
*komponenty třetích stran se průběžně vyvíjejí, musíme sledovat jejich vývoj.
to:
*existence mnoha modelů, frameworků – brzdí rozvoj většího společného trhu,
*průběžný vývoj komponent třetích stran -- musíme sledovat a aktualizovat.
Added lines 37-39:

Tento text vychází z práce F.Bachman a kol [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Technical Concepts of Component-Based Software Engineering, 2nd Edition]]. Doporučeno přečíst pro podrobnější pochopení problematiky.
Deleted lines 41-42:
Základy dle [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachmana]]. Doporučeno přečíst pro podrobnější pochopení problematiky.
22 January 2015, 14:26 by PremekBrada -
Changed lines 3-4 from:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] – což je Eclipse s pluginy pro vývoj Spring a OSGi).
to:
Tento 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] – což je Eclipse s pluginy pro vývoj Spring a OSGi).
Changed lines 7-8 from:
Autory tutoriálu jsou členové [[http://relisa.kiv.zcu.cz/ | výzkumné skupiny spolehlivych sw architektur]] na Katedře informatiky.
to:
Autory tutoriálu jsou členové [[http://relisa.kiv.zcu.cz/ | výzkumné skupiny spolehlivých softwarových architektur]] na Katedře informatiky.
Changed lines 17-18 from:
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ů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy – specifikace, jimž říkáme Komponentové modely.
to:
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_.
20 January 2015, 10:41 by PremekBrada -
Changed lines 7-8 from:
Autory tutoriálu jsou členové *výzkumné skupiny sw komponent* na Katedře informatiky.
to:
Autory tutoriálu jsou členové [[http://relisa.kiv.zcu.cz/ | výzkumné skupiny spolehlivych sw architektur]] na Katedře informatiky.
04 January 2015, 20:59 by Eduard Chromik -
Changed lines 182-184 from:
* [[CoSi -> http://www.kiv.zcu.cz/research/groups/dss/projects/cosi.html]], náš vlastní komponentový framework

to:
* [[CoSi -> https://www.assembla.com/wiki/show/cosi/Tutorial_examples]], náš vlastní komponentový framework

04 January 2015, 20:35 by Eduard Chromik -
Changed lines 7-8 from:
Autory tutoriálu jsou členové [[výzkumné skupiny sw komponent -> http://www.kiv.zcu.cz/research/groups/dss/projects/sacco.html]] na Katedře informatiky.
to:
Autory tutoriálu jsou členové *výzkumné skupiny sw komponent* na Katedře informatiky.
22 December 2014, 14:48 by Eduard Chromik -
Changed lines 37-38 from:
%width=100px%Attach:bachmann.png
to:
%width=400px%Attach:bachmann.png
22 December 2014, 14:47 by Eduard Chromik -
Changed lines 37-38 from:
%width=90px%Attach:bachmann.png
to:
%width=100px%Attach:bachmann.png
22 December 2014, 14:47 by Eduard Chromik -
Changed lines 37-38 from:
to:
%width=90px%Attach:bachmann.png
22 December 2014, 14:38 by Eduard Chromik -
Deleted lines 37-38:
http://www.bauml.cz/content/bachmann00.png
29 March 2011, 14:38 by Lukas Holy -
Changed line 91 from:
**Plug-In – rozšíření vnořeného frameworku komponentou ??? rozdíl od předchozí
to:
**Plug-In – rozšíření vnořeného frameworku komponentou
29 March 2011, 14:38 by Lukas Holy -
Changed line 92 from:
Attach:fra-comp.png
to:
Attach:fra-comp2.png
28 March 2011, 14:33 by Snajberk -
Changed lines 161-162 from:
*Procesy??? – kvalitní proces -> kvalitní produkt (?)
to:
*Procesy – předpokládá se, že kvalitní proces vytvoří kvalitní produkt
28 March 2011, 14:31 by Snajberk -
Changed lines 66-69 from:
??? Tento objekt je po vytvoření předán (injected).

??? Tento proces je však v základě opačný, odtud název Inversion of Control ([=IoC=])
to:

Dependency objekt, který je vytvořen frameworkem, je po vytvoření přímo předán (injected) objektu, který ho použije. Ve skutečnosti je tedy proces definování závislosti v základě opačný běžnému postupu, protože běžně si objekt/komponenta hledá sama objekt, na kterém závisí. Odtud název Inversion of Control ([=IoC=])
Changed line 75 from:
!!!!Úrovně ???čeho???:
to:
!!!!Úrovně kontraktů a interakce:
Changed lines 101-102 from:
Komponentový model specifikuje, co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy ???čeho???, požadované služby, atd. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.
to:
Komponentový 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. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.
Changed lines 135-136 from:
Architektura je gray-boxový model ???čím se liší od black-box???, který popisuje aplikaci. Určuje 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).
to:
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.
Changed lines 143-144 from:
Ve fázi sestavení jsou všechny komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou ???komponentu??? (aplikaci), 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).
to:
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).
22 March 2011, 15:51 by Pavel Herout -
Changed lines 17-18 from:
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ů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy - specifikace, jimž říkáme Komponentové modely.
to:
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ů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy – specifikace, jimž říkáme Komponentové modely.
Changed line 33 from:
*mnoho modelů, frameworků - brzdí rozvoj většího společného trhu,
to:
*mnoho modelů, frameworků – brzdí rozvoj většího společného trhu,
Changed line 62 from:
Dependency injection je proces, kdy si objekty definují své závislosti (dependency - odkaz na jiný objekt, s kterým pracují) pouze přes:
to:
Dependency injection je proces, kdy si objekty definují své závislosti (dependency – odkaz na jiný objekt, s kterým pracují) pouze přes:
22 March 2011, 15:49 by Pavel Herout -
Changed lines 3-4 from:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] - což je Eclipse s pluginy pro vývoj Spring a OSGI).
to:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] – což je Eclipse s pluginy pro vývoj Spring a OSGi).
Changed lines 46-47 from:
Třetí strana (kdokoliv, kdo komponentu používá) má k dispozici pouze -- viditelný interface a specifikaci komponenty.
to:
Třetí strana (kdokoliv, kdo komponentu používá) má k dispozici pouze – viditelný interface a specifikaci komponenty.
Changed lines 58-59 from:
Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí 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 (contract -- když jedna komponenta používá druhou pomocí rozhraní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.
to:
Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí 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 (contract – když jedna komponenta používá druhou pomocí rozhraní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.
Changed line 64 from:
* argumenty, které se předají nějaké statické tovární metodě (factory -- vytváří různé objekty s různou konfigurací)
to:
* argumenty, které se předají nějaké statické tovární metodě (factory – vytváří různé objekty s různou konfigurací)
Changed lines 77-80 from:
*syntaktická -- typy, pole, metody, …
*sémantická -- rozsahy, pre- a postconditions a invarianty
*chování (průběh) -- omezení kompozice, (vnitřní chování)
to:
*syntaktická – typy, pole, metody, …
*sémantická – rozsahy, pre- a postconditions a invarianty
*chování (průběh) – omezení kompozice, (vnitřní chování)
Changed line 87 from:
**Vnoření komponent -- hierarchie
to:
**Vnoření komponent – hierarchie
Changed lines 102-105 from:
Komponentový model specifikuje co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy, požadované služby, atd. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.

Dále jsou zmíněna dvě tato rozdělení.
to:
Komponentový model specifikuje, co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy ???čeho???, požadované služby, atd. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.

Dále jsou popisována dvě tato rozdělení.
Changed lines 107-108 from:
*Komponenty jako třídy - JavaBeans
*Komponenty jako objekty - .NET
to:
*Komponenty jako třídy – JavaBeans
*Komponenty jako objekty – .NET
Changed lines 112-113 from:
*OOP jazyky - JavaBeans
*Jazyky s mapováním na IDL - .NET
to:
*OOP jazyky – JavaBeans
*Jazyky s mapováním na IDL – .NET
Changed lines 118-119 from:
Komponentový 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řízují běh a komunikaci komponent, případně další podpůrné služby. V mnoha ohledech jsou komponentové frameworky jako operační systémy, ačkoliv pracují na mnohem vyšší úrovni abstrakce.
to:
Komponentový 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.
Changed lines 128-137 from:
Aby byla snížena složitost (komplexnost) aplikace, tak se na začátku této fáze rozdělí 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řili celou aplikaci.

Design aplikace je obvykle popisován pomocí UML (Unified Modeling Language). Vytvořený model komponenty 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í interfacy jako množinu metod s parametry. Některé mohou být navíc použity i k definici properties, kontant, struktur a výjimek. Tyto jazyky mohou dále definovat i architekturu a framy (vysvětlení níže).

Architektura je gray-boxový model, který popisuje aplikaci. Určuje 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).
to:
Aby 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 gray-boxový model ???čím se liší od black-box???, který popisuje aplikaci. Určuje 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).
Changed lines 140-141 from:
Druhá 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 (produkt description language). Může generovat třídy, prázdné metody, interfacy. Zkompilovaný kód tvoří komponentu, která je ve vývoji dále použivána.
to:
Druhá 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.
Changed lines 144-147 from:
Ve fázi sestavení jsou všechny komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou komponentu (aplikaci), 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.
to:
Ve fázi sestavení jsou všechny komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou ???komponentu??? (aplikaci), 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.
Changed lines 152-153 from:
Komponenty jsou rozděleny do deployment units, 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.
to:
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.
Changed lines 162-163 from:
*Procesy – kvalitní proces -> kvalitní produkt (?)
to:
*Procesy??? – kvalitní proces -> kvalitní produkt (?)
Changed lines 189-191 from:
* [[Crnkovic: Component Models -> http://www.idt.mdh.se/kurser/cdt501/2002/lectures/04-chapter-Component-Models-ADL.pdf]] - jedna přednáška z předmětu [[Advanced Topics in Component-Based Software Engineering -> http://www.idt.mdh.se/kurser/cdt501/2010/index.htm]]

to:
* [[Crnkovic: Component Models -> http://www.idt.mdh.se/kurser/cdt501/2002/lectures/04-chapter-Component-Models-ADL.pdf]] – jedna přednáška z předmětu [[Advanced Topics in Component-Based Software Engineering -> http://www.idt.mdh.se/kurser/cdt501/2010/index.htm]]

22 March 2011, 15:39 by Pavel Herout -
Changed lines 56-59 from:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako Isolation of Components. Implementace komponent je neveřejná (black-box) a je skrytá za popsaným interfacem - rozhraním. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není definována v rozhraní. Implementace komponenty je tedy "izolovaná".

Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí 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 (contract - když jedna komponenta používá druhou pomocí rozhraní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.
to:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako Isolation of Components. 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í.

Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí 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 (contract -- když jedna komponenta používá druhou pomocí rozhraní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.
Changed lines 62-64 from:
Dependency injection je proces, kdy si objekty definují své závislosti (dependency - jiný objekt, s kterým pracují) pouze přes:
* argumenty s kterými se volá kontruktor
* argumenty, které se předají nějaké factory metodě (factory vytváří různé objekty s různou konfigurací)
to:
Dependency injection je proces, kdy si objekty definují své závislosti (dependency - odkaz na jiný objekt, s kterým pracují) pouze přes:
* argumenty, se kterými se volá kontruktor,
* argumenty, které se předají nějaké statické tovární metodě (factory -- vytváří různé objekty s různou konfigurací)
Changed lines 66-69 from:
Tento objekt je po vytvoření předán (injected).

Tento proces je však v základě opačný, odtud název Inversion of Control ([=IoC=])
to:
??? Tento objekt je po vytvoření předán (injected).

??? Tento proces je však v základě opačný, odtud název Inversion of Control ([=IoC=])
Changed lines 74-80 from:
Kontrakty by měly zajistit dobré spojení rozraní, určit „práva a povinnosti“ obou (všech) stran. 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 domluvili, kdy kontrakt vyprší.

!!!!Úrovně:
*Syntaktická - typy, pole, metody…
*Sémantická - Rozsahy, pre- a postconditions a invarianty
*Chování (průběh) - omezení kompozice, (vnitřní chování)
to:
Kontrakty by měly zajistit dobré spojení rozhraní, určit „práva a povinnosti“ obou (všech) stran. 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ší.

!!!!Úrovně ???čeho???:
*syntaktická -- typy, pole, metody, …
*sémantická -- rozsahy, pre- a postconditions a invarianty
*chování (průběh) -- omezení kompozice, (vnitřní chování)
Changed line 84 from:
!!!!Komponenty mezi sebou
to:
!!!!Vzájemné vztahy komponenty a způsoby jejich znázornění
Changed line 87 from:
**Vnoření komponent - hierarchie
to:
**Vnoření komponent -- hierarchie
Changed line 92 from:
**Plug-In – rozšíření vnořeného frameworku komponentou
to:
**Plug-In – rozšíření vnořeného frameworku komponentou ??? rozdíl od předchozí
22 March 2011, 13:08 by Pavel Herout -
Changed lines 40-41 from:
Základy dle [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachmana]]. Doporučeno přečíst, pro podrobnější pochopení problematiky.
to:
Základy dle [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachmana]]. Doporučeno přečíst pro podrobnější pochopení problematiky.
Changed lines 44-50 from:
Komponenta je package, modul, namespace (dle programovacího jazyka), který sdružuje podobné funkce, třídy. Implementace komponenty (používané objekty, funkce, data) by měla zůstat skrytá, viditelný by měl být pouze interface, přes který se bude komponenta používat. Tomuto principu se říká black-boxový model a je v reálném světě 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í platí:

* neprůhledná implementace funkcionality
to:
Komponenta je package, modul, namespace (dle programovacího jazyka), který sdružuje podobnou funkcionalitu, případně třídy. Implementace komponenty (používané objekty, funkce, data) by měla zůstat skrytá, viditelný by měl být pouze interface, přes který se bude komponenta používat. Tomuto principu se říká black-boxový model a je v reálném světě 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í:

* skrytá/neveřejná implementace funkcionality
Changed lines 56-57 from:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako Isolation of Components. Implementace komponent je neprůhledná (black-box) a je skrytá za popsaným interfacem - rozhraním. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není definována v rozhraní. Implementace komponenty je tedy "izolovaná".
to:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako Isolation of Components. Implementace komponent je neveřejná (black-box) a je skrytá za popsaným interfacem - rozhraním. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není definována v rozhraní. Implementace komponenty je tedy "izolovaná".
22 March 2011, 13:02 by Pavel Herout -
Changed lines 17-22 from:
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ů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy - specifikace, jimž říkáme Komponentový model.

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 rozhranní (interface) přes které se komponenta používá (volají se metody interface) a má kompletně popsanou funkcionalitu (specifikaci), aby volající věděl, co může očekávat.

Toto byly základní pojmy o kterých se budeme bavit více do hloubky v následujících kapitolách.
to:
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ů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy - 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á (volají se metody interface) a má kompletně popsanou funkcionalitu (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.
Changed lines 25-30 from:
Komponenty by měly

*Urychlit vývoj aplikace
*Zlevnit cenu softwaru, např. díky znovupoužití existujících, otestovaných,… komponent (třetích stran)
*Zlepšit předvídatelnost chování, …
to:
Komponenty by měly:

*urychlit vývoj aplikace,
*zlevnit cenu softwaru, např. díky znovupoužití existujících, otestovaných,… komponent (třetích stran),
*zlepšit předvídatelnost chování, …
Changed lines 32-35 from:
*Režie přechodu na komponentový vývoj
*Mnoho modelů, frameworků - brzdí rozvoj většího společného trhu
*Komponenty třetích stran se vyvíjejí, musíme sledovat jejich vývoj.
to:
*režie přechodu na komponentový vývoj,
*mnoho modelů, frameworků - brzdí rozvoj většího společného trhu,
*komponenty třetích stran se průběžně vyvíjejí, musíme sledovat jejich vývoj.
22 March 2011, 12:58 by Pavel Herout -
Changed lines 3-4 from:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] - což je Eclipse s pluginy pro vývoj spring a osgi).
to:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] - což je Eclipse s pluginy pro vývoj Spring a OSGI).
Changed lines 13-14 from:
Zde pojednáme o "teoretických" základech kommponentového programování a přístupu k designu aplikací. Prakticky jsou ukázané v kapitolách o jednotlivých technologiích.
to:
Zde pojednáme o "teoretických" základech kommponentového programování a přístupu k designu aplikací. Prakticky jsou aplikace ukázány v kapitolách o jednotlivých technologiích.
22 March 2011, 12:57 by Pavel Herout -
Changed lines 3-4 from:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] - což je Eclipse s pluginy pro vývoj spring a osgi).
to:
Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] - což je Eclipse s pluginy pro vývoj spring a osgi).
23 February 2011, 14:57 by Lukas Holy -
Changed lines 178-179 from:
* Vlastní (KIV) prezentace o komponentách Attach:Komponentove-modely-a-architektury.pdf
to:
* [[Vlastní (KIV) prezentace o komponentách -> http://wiki.kiv.zcu.cz/uploads/UvodDoKomponent/Komponentove-modely-a-architektury.pdf]]
23 February 2011, 14:56 by Lukas Holy -
Changed lines 178-179 from:
* TODO vlastni prezentace nase
to:
* Vlastní (KIV) prezentace o komponentách Attach:Komponentove-modely-a-architektury.pdf
21 February 2011, 11:00 by PremekBrada -
Changed lines 36-37 from:
!! [[#pojmy]] Základní pojmy
to:
! [[#pojmy]] Základní pojmy
Changed lines 100-101 from:
!!! Komponentový model
to:
!! Komponentový model
Changed lines 120-121 from:
!! [[#proces]] Proces vývoje komponent
to:
! [[#proces]] Proces vývoje komponent
Changed lines 168-169 from:
!! [[#zdroje]] Klíčové zdroje informací
to:
! [[#zdroje]] Klíčové zdroje informací
21 February 2011, 10:59 by PremekBrada -
Changed lines 102-105 from:
Komponentový model je vlastně vlastní filosofie, či pohled na komponentově orientované softwarové inženýrství. Specifikuje co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy, požadované služby, atd. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií. Takových rozdělení může být také mnoho. Dále jsou zmíněny dvě tato rozdělení.
to:
Komponentový model specifikuje co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy, požadované služby, atd. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií.

Dále jsou zmíněna dvě tato rozdělení.
Added line 110:
Deleted line 115:
Added line 191:
Deleted lines 192-226:

! Praktická část

V praktické části, která je součástí každého popisovaného modelu lze vždy najít:
* tutoriál, jak vytvořit prázdný projekt (někdy spojené s následujícím bodem)
* návod na jednoduchou [=HelloWorld=] aplikaci
* implementaci Message printer (viz. níže)
* implementaci Parkoviště (viz. níže)


Tyto příklady jsou převzaty [[https://www.assembla.com/wiki/show/cosi/Tutorial_examples | z projektu CoSi]].

!! Message printer

Nejdříve opravdu jednoduchá aplikace:

* "server" komponenta, která exportuje službu na rozhranní [=IMsgGen=], které má jednu metodu @@String getMsg()@@
* "client" komponenta, která importuje tuto službu a vytiskne zprávu na standardní výstup


!! Parkoviště

Jako další je zde trochu komplexnější příklad, s následujícím scénářem: u dálnice je tabule, která motoristy informuje o tom, kolik je ještě volných míst na parkovišti. Auta, autobusy a náklaďáky přijíždí a odjíždí přes bránu, která pouští pouze v případě, že se na parkoviště daný typ vozidla vejde - auto spotřebuje jedno místo, autobus 2 místa, náklaďák 4.


Komponentový model má následující komponenty (rovněž znázorněny v diagramu níže):
* "Brana" která náhodně generuje příjezdy/odjezdy a volá "Parkoviste", aby si je zpracovalo
* "Parkoviste" které přes události oznamuje kolik je volných míst, které se nastavují přes metody volané "Branou"
* "Tabule" vypisuje kolik je volných míst
* "[=KonfiguraceZarizeni=]" poskytuje konfiguraci ostatním komponentám - "frekvence" pro "Branu" a "kapacita" pro "Parkoviste"


https://www.assembla.com/spaces/cosi/documents/cNiLQuHYyr3QHfeJe5afGb/download?filename=parkoviste-diagram.png

----
21 February 2011, 10:49 by PremekBrada -
Changed lines 11-12 from:
! Úvod do komponent
to:
! [[#uvod]] Úvod do komponent
Changed lines 15-16 from:
!! Proč komponentově orientované programování
to:
!! [[#proc]] Proč komponentově orientované programování
Changed lines 24-27 from:
*Měly by urychlit vývoj aplikace
to:

Komponenty by měly

*Urychlit vývoj aplikace
Changed lines 36-37 from:
!! Základní pojmy
to:
!! [[#pojmy]] Základní pojmy
Changed lines 54-57 from:
!!! Komponentové rozhranní (interface)

Rozhranní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí a co pro to potřebuje. Rozhranní může být popsáto buď programovacím jazykem, nebo pomocí IDL -- Interface definition language. Díky rozhranní může být mezi dvěmi komponentami navázána komunikace (contract - když jedna komponenta používá druhou pomocí rozhranní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.
to:
!!! Komponentové rozhraní (interface)

Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako Isolation of Components. Implementace komponent je neprůhledná (black-box) a je skrytá za popsaným interfacem - rozhraním. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není definována v rozhraní. Implementace komponenty je tedy "izolovaná".

Rozhraní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí 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 (contract - když jedna komponenta používá druhou pomocí rozhraní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.

!!!! Dependency Injection a Inversion of Control

Dependency injection je proces, kdy si objekty definují své závislosti (dependency - jiný objekt, s kterým pracují) pouze přes:
* argumenty s kterými se volá kontruktor
* argumenty, které se předají nějaké factory metodě (factory vytváří různé objekty s různou konfigurací)
* properties, které jsou nastaveny objektu potom, co je vytvořený
Tento objekt je po vytvoření předán (injected).

Tento proces je však v základě opačný, odtud název Inversion of Control ([=IoC=])

Oba výrazy tedy znamenají prakticky to samé.
Added line 75:
Added line 83:
Changed lines 117-118 from:
!! Proces vývoje komponent
to:
!! [[#proces]] Proces vývoje komponent
Changed lines 163-182 from:
!! Důležité zásady

!!! Isolation of Components

Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako black-box model. Implementace komponent je skrytá za svým interfacem. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není v interfacu. Implementace komponenty je tdy "izolovaná".

!!! Dependency Injection a Inversion of Control

Dependency injection je proces, kdy si objekty definují své závislosti (dependency - jiný objekt, s kterým pracují) pouze přes:
* argumenty s kterými se volá kontruktor
* argumenty, které se předají nějaké factory metodě (factory vytváří různé objekty s různou konfigurací)
* properties, které jsou nastaveny objektu potom, co je vytvořený
Tento objekt je po vytvoření předán (injected).

Tento proces je však v základě opačný, odtud název Inversion of Control ([=IoC=])

Oba výrazy tedy znamenají prakticky to samé.

!! Klíčové zdroje informací
to:


!! [[#zdroje]] Klíčové zdroje informací
21 February 2011, 10:19 by PremekBrada -
Added lines 7-8:
Autory tutoriálu jsou členové [[výzkumné skupiny sw komponent -> http://www.kiv.zcu.cz/research/groups/dss/projects/sacco.html]] na Katedře informatiky.
21 February 2011, 10:13 by PremekBrada -
Added lines 170-171:
* TODO vlastni prezentace nase
20 December 2010, 16:28 by Lukas Holy -
Changed line 81 from:
Komponentový model je vlastně vlastní filosofie, či pohled na komponentově orientované softwarové inženýrství. Specifikuje co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy, požadované služby, atd.
to:
Komponentový model je vlastně vlastní filosofie, či pohled na komponentově orientované softwarové inženýrství. Specifikuje co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy, požadované služby, atd. Komponentových modelů je mnoho a proto je dobré je rozdělit do různých kategorií. Takových rozdělení může být také mnoho. Dále jsou zmíněny dvě tato rozdělení.
20 December 2010, 16:23 by Lukas Holy - Pridani klasifikace komp.modelu
20 December 2010, 16:21 by Lukas Holy - Pridani klasifikace komp.modelu
Changed lines 82-86 from:
!!!!Kategorie založené na sémantice
*Třídy - JavaBeans
*Objekty - .NET
*Architektonické jednotky – UML2.0, SOFA
!!!!Kategorie založené na syntaxi
to:
!!!!Kategorie založené na sémantice:
*Komponenty jako třídy - JavaBeans
*Komponenty jako objekty - .NET
*Komponenty jako architektonické jednotky – UML2.0, SOFA
!!!!Kategorie založené na syntaxi:
20 December 2010, 16:19 by Lukas Holy - Pridani klasifikace komp.modelu
Changed lines 82-91 from:
to:
!!!!Kategorie založené na sémantice
*Třídy - JavaBeans
*Objekty - .NET
*Architektonické jednotky – UML2.0, SOFA
!!!!Kategorie založené na syntaxi
*OOP jazyky - JavaBeans
*Jazyky s mapováním na IDL - .NET
*Jazyky s popisem architektury (ADL) – UML2.0, SOFA program musí být vytvořen v nějakém progr. jazyce

20 December 2010, 16:15 by Lukas Holy - Pridani certifikace
Changed lines 126-130 from:
Frameworky
Komponenty
Systémy – složení frameworků a komponent
Procesy – kvalitní proces -> kvalitní produkt (?)
to:
*Frameworky
*Komponenty
*Systémy – složení frameworků a komponent
*Procesy – kvalitní proces -> kvalitní produkt (?)
20 December 2010, 16:15 by Lukas Holy - Pridani certifikace
20 December 2010, 16:12 by Lukas Holy - Pridani certifikace
20 December 2010, 16:12 by Lukas Holy - Pridani certifikace
Added lines 121-132:
!!! Certifikace

Někdo důvěryhodný vydá prohlášení o certifikovaném subjektu.

Certifikovat je možné (subjekty certifikace):
Frameworky
Komponenty
Systémy – složení frameworků a komponent
Procesy – kvalitní proces -> kvalitní produkt (?)

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á.
20 December 2010, 16:05 by Lukas Holy -
Changed lines 62-63 from:
Rozdělení viz Bachmann
* [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
to:
Rozdělení viz [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
20 December 2010, 16:04 by Lukas Holy -
Added lines 62-63:
Rozdělení viz Bachmann
* [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
20 December 2010, 16:02 by Lukas Holy -
Changed line 65 from:
**'''Vnoření komponent - hierarchie'''
to:
**Vnoření komponent - hierarchie
Changed line 68 from:
**'''Nasazení komponenty do frameworku'''
to:
**Nasazení komponenty do frameworku
Changed line 70 from:
**'''Plug-In – rozšíření vnořeného frameworku komponentou'''
to:
**Plug-In – rozšíření vnořeného frameworku komponentou
Changed line 73 from:
**'''Vnoření frameworků'''
to:
**Vnoření frameworků
Changed line 75 from:
**'''Spojení komponent z různých frameworků'''
to:
**Spojení komponent z různých frameworků
20 December 2010, 16:01 by Lukas Holy -
Changed line 63 from:
**'''„normální“ spojení komponent'''
to:
**„normální“ spojení komponent
20 December 2010, 16:01 by Lukas Holy -
Changed line 65 from:
**Vnoření komponent - hierarchie
to:
**'''Vnoření komponent - hierarchie'''
Changed line 68 from:
**Nasazení komponenty do frameworku
to:
**'''Nasazení komponenty do frameworku'''
Changed line 70 from:
**Plug-In – rozšíření vnořeného frameworku komponentou
to:
**'''Plug-In – rozšíření vnořeného frameworku komponentou'''
Changed line 73 from:
**Vnoření frameworků
to:
**'''Vnoření frameworků'''
Changed line 75 from:
**Spojení komponent z různých frameworků
to:
**'''Spojení komponent z různých frameworků'''
20 December 2010, 16:00 by Lukas Holy -
Changed lines 62-63 from:
*Komponenty mezi sebou
**„normální“ spojení komponent
to:
!!!!Komponenty mezi sebou
**'''„normální“ spojení komponent'''
Changed line 67 from:
*Framework-komponenta
to:
!!!!Framework-komponenta
Changed line 72 from:
*Frameworky mezi sebou
to:
!!!!Frameworky mezi sebou
20 December 2010, 15:59 by Lukas Holy -
Changed line 64 from:
Attach:komp-komp.png
to:
Attach:komp-komp.png
Changed line 66 from:
Attach:komp-subkomp.png
to:
Attach:komp-subkomp.png
Changed line 69 from:
Attach:comp-fra.png
to:
Attach:comp-fra.png
Changed line 71 from:
Attach:fra-comp.png
to:
Attach:fra-comp.png
Changed line 74 from:
Attach:fra-fra.png
to:
Attach:fra-fra.png
Changed lines 76-77 from:
Attach:comp-fra-fra-comp.png
to:
Attach:comp-fra-fra-comp.png
20 December 2010, 15:56 by Lukas Holy -
Changed line 71 from:
Attach:fra-komp.png
to:
Attach:fra-comp.png
Changed lines 76-77 from:
Attach:komp-fra-fra-komp.png
to:
Attach:comp-fra-fra-comp.png
20 December 2010, 15:55 by Lukas Holy -
Changed line 64 from:
Attach:Component-Component
to:
Attach:komp-komp.png
Added line 66:
Attach:komp-subkomp.png
Added line 69:
Attach:comp-fra.png
Added line 71:
Attach:fra-komp.png
Added line 74:
Attach:fra-fra.png
Changed lines 76-77 from:
to:
Attach:komp-fra-fra-komp.png
20 December 2010, 15:50 by Lukas Holy -
Added line 64:
Attach:Component-Component
20 December 2010, 15:40 by Lukas Holy - Doplneni obsahu 1
Changed lines 15-16 from:
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 zniklo několik různých pohledů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy - specifikace, jimž říkáme Komponentový model.
to:
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ů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy - specifikace, jimž říkáme Komponentový model.
Added lines 21-30:
!!!! Výhody
*Měly by urychlit vývoj aplikace
*Zlevnit cenu softwaru, např. díky znovupoužití existujících, otestovaných,… komponent (třetích stran)
*Zlepšit předvídatelnost chování, …

!!!! Nevýhody
*Režie přechodu na komponentový vývoj
*Mnoho modelů, frameworků - brzdí rozvoj většího společného trhu
*Komponenty třetích stran se vyvíjejí, musíme sledovat jejich vývoj.
Changed lines 51-52 from:
Rozhranní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí a co pro to potřebuje. Rozhranní může být popsáto buď programovacím jazykem, nebo pomocí IDL -- Interface definition language. Díky rozhranní může být mezi dvěmi komponentami navázána komunikace (contract - když jedna komponenta používá druhou pomocí rozhranní).
to:
Rozhranní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí a co pro to potřebuje. Rozhranní může být popsáto buď programovacím jazykem, nebo pomocí IDL -- Interface definition language. Díky rozhranní může být mezi dvěmi komponentami navázána komunikace (contract - když jedna komponenta používá druhou pomocí rozhranní). Verze rozhraní je třeba rozlišovat a kontrolovat, jelikož každá verze komponenty může mít jiné rozhraní.

!!! Kontrakty komponent a interakce

Kontrakty by měly zajistit dobré spojení rozraní, určit „práva a povinnosti“ obou (všech) stran. 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 domluvili, kdy kontrakt vyprší.
!!!!Úrovně:
*Syntaktická - typy, pole, metody…
*Sémantická - Rozsahy, pre- a postconditions a invarianty
*Chování (průběh) - omezení kompozice, (vnitřní chování)

!!! Formy kompozice
*Komponenty mezi sebou
**„normální“ spojení komponent
**Vnoření komponent - hierarchie
*Framework-komponenta
**Nasazení komponenty do frameworku
**Plug-In – rozšíření vnořeného frameworku komponentou
*Frameworky mezi sebou
**Vnoření frameworků
**Spojení komponent z různých frameworků
20 September 2010, 09:56 by PremekBrada -
Added lines 119-123:

!! Doplňkové zdroje

* [[Crnkovic: Component Models -> http://www.idt.mdh.se/kurser/cdt501/2002/lectures/04-chapter-Component-Models-ADL.pdf]] - jedna přednáška z předmětu [[Advanced Topics in Component-Based Software Engineering -> http://www.idt.mdh.se/kurser/cdt501/2010/index.htm]]
10 September 2010, 09:55 by PremekBrada -
Added lines 9-12:
! Úvod do komponent

Zde pojednáme o "teoretických" základech kommponentového programování a přístupu k designu aplikací. Prakticky jsou ukázané v kapitolách o jednotlivých technologiích.
Changed lines 105-106 from:
Komponenty
to:
Komponenty obecně
Added lines 113-114:
Technologie
04 June 2010, 11:38 by PremekBrada -
Added line 101:
Komponenty
Changed lines 103-105 from:
* [[Bachmann et al: Technical Concepts -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
to:
* [[Bachmann et al: Technical Concepts, vol. II -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
* [[Crnkovic et al: Building Reliable Component-Based Software Systems -> http://www.amazon.com/Building-Reliable-Component-Based-Software-Systems/dp/1580533272/]]
Changed lines 108-111 from:
* Spring IoC
* OSGi, Spring DM

to:
* [[Spring IoC -> http://static.springframework.org/spring/docs/2.5.x/reference/beans.html]]
* [[OSGi -> http://www.osgi.org/Specifications/HomePage]], [[Spring DM -> http://www.springsource.org/osgi]]
* [[CoSi -> http://www.kiv.zcu.cz/research/groups/dss/projects/cosi.html]], náš vlastní komponentový framework
04 June 2010, 11:15 by PremekBrada -
Added lines 99-110:
!! Klíčové zdroje informací

* [[Clemens Szyperski: Component Software, 2nd edition. -> http://www.amazon.com/Component-Software-Beyond-Object-Oriented-Programming/dp/0201745720/]]
* [[Bachmann et al: Technical Concepts -> http://www.sei.cmu.edu/library/abstracts/reports/00tr008.cfm]]
* [[Fowler: Dependency injection -> http://martinfowler.com/articles/injection.html]]

* Spring IoC
* OSGi, Spring DM


----
22 December 2009, 15:53 by Snajberk -
Changed lines 83-84 from:
!!! Izolace komponent (Isolation of Components)
to:
!!! Isolation of Components
Changed lines 95-96 from:
Tento proces je v základě opačný, odtud název Inversion of Control ([=IoC=])
to:
Tento proces je však v základě opačný, odtud název Inversion of Control ([=IoC=])

Oba výrazy tedy znamenají prakticky to samé.
22 December 2009, 15:52 by Snajberk -
Changed lines 73-74 from:
V této fázi mohou být rovněž nastaveny hodnoty properties jednotlivých komponent - defaultní konfigurační data. Informace přidané k aplikaci v průběhu této fáze mají podobu XML souboru, nazývaného assembly descriptor.
to:
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.
Changed lines 77-79 from:
Poslední fáze na cestě k běžící aplikaci je fáze nasazení. Zde jsou konfigurační hodnoty z assembly descriptoru upraveny individuálním potřebám a deployment units jsou nakonfigurovány. Deployment unit je sada komponen, které mají stejnou hodnotu u parametru lokace, který určuje na kterém serveru bude komponenta běžet. Informace, které byly přidány v této fázi jsou opět zapsány ve formě XML souboru, který nazýváme deployment descriptor.

to:
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, 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.
22 December 2009, 15:47 by Snajberk -
Changed lines 57-58 from:
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í jinde 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řili celou aplikaci.
to:
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řili celou aplikaci.
Changed lines 71-77 from:
Ve fázi sestavení jsou primitivní a existující (reused) komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou komponentu (aplikaci), zatímco potomci každého uzlu reprezentují pod-komponenty skládané komponenty, reprezentované rodičovským uzlem. Listy stromu reprezentují buď primitivní komponenty, nebo existující komponenty, které jsou znovu použity (reused).

Informace, která může být reprezentována vnitřním listem, jak propojit interfacy komponenty s interfacy jejích pod-komponent. V závislosti na komponentovém modelu, je tato informace vytvořena v průběhu vývojové fáze, využívaje architektury aplikace, nebo je vytvořena v průběhu této fáze.

V této fázi mohou být rovněž nastaveny hodnoty properties, aby byly poskytnuty defaultní konfigurační data. Informace vytvořené v průběhu této fáze mají podobu XML souboru, nazývaného assembly descriptor.

to:
Ve fázi sestavení jsou všechny komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou komponentu (aplikaci), 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. Informace přidané k aplikaci v průběhu této fáze mají podobu XML souboru, nazývaného assembly descriptor.
22 December 2009, 15:42 by Snajberk -
Changed lines 67-68 from:
Druhá fáze je vývojová. V této fázi je vyvíjen kód pro primitivní (jednoduché) komponenty. Většina komponentových modelů může generovat nějaký zdrojový kód přímo z popisu komponenty (produkt description language), aby bylo kde začít. Můýe generovat buď základní třídy a jejich podtřídy, nebo třídy s prázdnými metodami. Zkompilovaný zdrojový kód, společně s popisem tvoří primitivní (jednoduchou) komponentu.
to:
Druhá 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 (produkt description language). Může generovat třídy, prázdné metody, interfacy. Zkompilovaný kód tvoří komponentu, která je ve vývoji dále použivána.
22 December 2009, 15:38 by Snajberk -
Changed lines 53-62 from:
!!! Fáze návrhu

Na začátku této fáze je aplikace rozdělena do množství komponent s dostatečně popsanou funkcionalitou, aby byla snížena složitost aplikace. Pro každou komponentu jsou pak definovány služby, které bude poskytovat a které bude požadovat.

Tento postup je rekurzivně opakován, dokud nejsou navrhované komponenty buď jednoduché a tudíž mohou být snadno implementovány použitím programovacího jazyka (jednoduché komponenty), nebo již existují jinde a tudíž mohou být použity znovu (reused). Design aplikace je obvykle vytvářen pomocí UML (Unified Modeling Language) nástrojů. Dle vytvořeného modelu jsou komponenty popsány. Pro tento účel je zde řada jazyků - description languages. Většina z nich jsou mutace, nebo rozšíření IDL (Interface Description Language).

Díky těmto jazykům jsou definovány interfacy jako množina volatelných metod s parametry. Některé description languages mohou být rovněž použity k definování vlastností (properties), konstant, struktur a výjimek. CDL (Component Description Language)může dále nadefinovat frame a architekturu. Frame je skupina několika interfaců, kde každý z nich se používá pro poskytování, nebo je vyžadován. Architektura je gray-boxový popis komponenty, deklarující buď fakt, že komponenta je primitivní (jednoduchá), nebo definující jak je komponenta složena z pod-komponent na první úrovni, kde se považují komponenty jen jako framy.

!!! Fáze vývoje
to:
!!! Návrhová fáze

Aby byla snížena složitost (komplexnost) aplikace, tak se na začátku této fáze rozdělí 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í jinde 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řili celou aplikaci.

Design aplikace je obvykle popisován pomocí UML (Unified Modeling Language). Vytvořený model komponenty 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í interfacy jako množinu metod s parametry. Některé mohou být navíc použity i k definici properties, kontant, struktur a výjimek. Tyto jazyky mohou dále definovat i architekturu a framy (vysvětlení níže).

Architektura je gray-boxový model, který popisuje aplikaci. Určuje 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).

!!! Vývojová fáze
22 December 2009, 15:21 by Snajberk -
Changed lines 41-42 from:
Komponentový model je souhrn typů komponent, jejich rozhranní a dodatečně specifikací povolených typů komunikace (patterns of interaction) mezi komponentami jednotlivých typů.
to:
Komponentový model je vlastně vlastní filosofie, či pohled na komponentově orientované softwarové inženýrství. Specifikuje co je to komponenta, jak probíhá komunikace mezi komponentami, jak se komponenty skládají, jaké jsou povolené typy, požadované služby, atd.
Changed lines 45-46 from:
Komponentový 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) určených k podpoře a uplatnění komponentového modelu. V mnoha ohledech jsou komponentové frameworky jako operační systémy , ačkoliv pracují na mnohem vyšší úrovni abstrakce.
to:
Komponentový 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řízují běh a komunikaci komponent, případně další podpůrné služby. V mnoha ohledech jsou komponentové frameworky jako operační systémy, ačkoliv pracují na mnohem vyšší úrovni abstrakce.
Changed lines 49-50 from:
V tradičním komponentově orientovaném vývojovém procesu, tak jak je obvykle popsán, můžeme identifikovat několik rozdílných etap na cestě od nápadu k běžící aplikaci. V závislosti na konkrétním komponentovém modelu mohou být některé z těchto etap více, či méně rozsáhlé, či úplně chybět.
to:
V 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.
22 December 2009, 15:13 by Snajberk -
Changed lines 21-22 from:
Představení základních pojmů. [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachman00]]
to:
Základy dle [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachmana]]. Doporučeno přečíst, pro podrobnější pochopení problematiky.
Changed lines 25-30 from:
Komponenta je softwarový package nebo modul, který sdružuje podobné funkce. Každá komponenta má svůj vlastní interface, který je viditelný okolnímu světu. Všechno, co není součástí interfacu (objekty, funkce a data použité pro implementaci), by mělo zůstat skryté. Tento postup nazýváme black-boxem. Ačkoliv je black-boxová komponenta jen ideální vzor, který je ve skutečnosti nedosažitelný, je tento pojem používán. Definice softwarové komponenty není ustálená, ale obecně platí platí:

* neprůhledná implementace funkcionality
* je skládána třetí stranou (third-party)
* odpovídá komponentovému modelu
to:
Komponenta je package, modul, namespace (dle programovacího jazyka), který sdružuje podobné funkce, třídy. Implementace komponenty (používané objekty, funkce, data) by měla zůstat skrytá, viditelný by měl být pouze interface, přes který se bude komponenta používat. Tomuto principu se říká black-boxový model a je v reálném světě 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í platí:

* neprůhledná implementace funkcionality
* je používána třetí stranou (third-party)
* odpovídá komponentovému modelu
22 December 2009, 15:01 by Snajberk -
Changed lines 9-12 from:
!! Proč komponenty

V posledních deseti letech získaly komponenty významnou roli v procesu vývoje softwaru. Ačkoliv bylo představeno několik rozdílných specifikací (označovány jako komponentové modely), co to vlastně softwarová komponenta doopravdy je, základní myšlenka je stále víceméně stejná. Základním kamenem komponentově orientovaného přístupu je dělení kódu aplikace do několika samostatných částí (nazýváme je komponentami), s definovanou funkcionalitou (nazýváme ji specifikací) a se sjednocenými přístupovými body (nazýváme je rozhranní[interfaces]). Toto byly základní pojmy o kterých se budeme bavit více do hloubky v následujících kapitolách.
to:
!! 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 zniklo několik různých pohledů / filosofií na tuto problematiku, z kterých pak vznikly jejich rozsáhlé popisy - specifikace, jimž říkáme Komponentový model.

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 rozhranní (interface) přes které se komponenta používá (volají se metody interface) a má kompletně popsanou funkcionalitu (specifikaci), aby volající věděl, co může očekávat.

Toto byly základní pojmy o kterých se budeme bavit více do hloubky v následujících kapitolách.
22 December 2009, 14:45 by Snajberk -
Changed lines 73-79 from:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako black-box model. Implementace komponent je skrytá za svým interfacem. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není v interfacu.

!!! [=IoC=]

Inversion of Control je nejtypičtějším vzorem (design pattern) v komponentových systémech. Základní koncept [=IoC=] (rovněž známé jako dependency injection) je v tom, že si objekty nevytvářím, ale pouze specifikuji druh a parametry objektu a někdo (něco) jiný pro mě tyto objekty vytvoří.

to:
Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako black-box model. Implementace komponent je skrytá za svým interfacem. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není v interfacu. Implementace komponenty je tdy "izolovaná".

!!! Dependency Injection a Inversion of Control

Dependency injection je proces, kdy si objekty definují své závislosti (dependency - jiný objekt, s kterým pracují) pouze přes:
* argumenty s kterými se volá kontruktor
* argumenty, které se předají nějaké factory metodě (factory vytváří různé objekty s různou konfigurací)
* properties, které jsou nastaveny objektu potom, co je vytvořený
Tento objekt je po vytvoření předán (injected).

Tento proces je v základě opačný, odtud název Inversion of Control ([=IoC=])
22 December 2009, 13:33 by Snajberk -
Changed lines 75-79 from:
!!! [IoC]

Inversion of Control je nejtypičtějším vzorem (design pattern) v komponentových systémech. Základní koncept [IoC] (rovněž známé jako dependency injection) je v tom, že si objekty nevytvářím, ale pouze specifikuji druh a parametry objektu a někdo (něco) jiný pro mě tyto objekty vytvoří.

to:
!!! [=IoC=]

Inversion of Control je nejtypičtějším vzorem (design pattern) v komponentových systémech. Základní koncept [=IoC=] (rovněž známé jako dependency injection) je v tom, že si objekty nevytvářím, ale pouze specifikuji druh a parametry objektu a někdo (něco) jiný pro mě tyto objekty vytvoří.

22 December 2009, 13:32 by Snajberk -
Changed lines 64-67 from:
!!! Deployment Stage

The last stage on the way to a running application is the deployment stage. In this stage, the configuration values in the assembly descriptor are customized according to the individual needs and the deployments units are configured. A deployment unit is a set of components with the same value of the location parameter, defining a reference to a server where the component will be run. The information entered during the assembly stage is again written in a form of an XML file, called the deployment descriptor.
to:
!!! Fáze nasazení

Poslední fáze na cestě k běžící aplikaci je fáze nasazení. Zde jsou konfigurační hodnoty z assembly descriptoru upraveny individuálním potřebám a deployment units jsou nakonfigurovány. Deployment unit je sada komponen, které mají stejnou hodnotu u parametru lokace, který určuje na kterém serveru bude komponenta běžet. Informace, které byly přidány v této fázi jsou opět zapsány ve formě XML souboru, který nazýváme deployment descriptor.

22 December 2009, 13:27 by Snajberk -
Changed lines 55-62 from:
!!! Assembly Stage

In the assembly stage, the primitive and the reused components are assembled into an assembly tree. The root of the tree represents the entire component (application), while the children of each node represent subcomponents of a composed component represented by the parent node. The leaves of the tree represent either primitive components or existing components that are reused.

The information that can be represented by the inner leaves is how to interconnect the interfaces of the component with the interfaces of the subcomponents. Depending on the component model, this information is created during the development stage using an architecture element, or it is created during the assembly stage.

Also, the property values can be set during this stage to provide the component with default configuration data. The information created during the assembly stage has a form of an XML file, called the assembly descriptor.
to:
!!! Fáze sestavení

Ve fázi sestavení jsou primitivní a existující (reused) komponenty sestaveny do assembly tree. Kořen stromu reprezentuje celou komponentu (aplikaci), zatímco potomci každého uzlu reprezentují pod-komponenty skládané komponenty, reprezentované rodičovským uzlem. Listy stromu reprezentují buď primitivní komponenty, nebo existující komponenty, které jsou znovu použity (reused).

Informace, která může být reprezentována vnitřním listem, jak propojit interfacy komponenty s interfacy jejích pod-komponent. V závislosti na komponentovém modelu, je tato informace vytvořena v průběhu vývojové fáze, využívaje architektury aplikace, nebo je vytvořena v průběhu této fáze.

V této fázi mohou být rovněž nastaveny hodnoty properties, aby byly poskytnuty defaultní konfigurační data. Informace vytvořené v průběhu této fáze mají podobu XML souboru, nazývaného assembly descriptor.

Changed lines 70-71 from:
!!! Separace komponent (Isolation of Components)
to:
!!! Izolace komponent (Isolation of Components)
22 December 2009, 13:15 by Snajberk -
Changed lines 43-46 from:
!!! Etapa návrhu

Na začátku této etapy je aplikace rozdělena do množství komponent s dostatečně popsanou funkcionalitou, aby byla snížena složitost aplikace. Pro každou komponentu jsou pak definovány služby, které bude poskytovat a které bude požadovat.
to:
!!! Fáze návrhu

Na začátku této fáze je aplikace rozdělena do množství komponent s dostatečně popsanou funkcionalitou, aby byla snížena složitost aplikace. Pro každou komponentu jsou pak definovány služby, které bude poskytovat a které bude požadovat.
Changed lines 51-54 from:
!!! Development Stage

The second stage is the development stage. In this stage, source codes for the primitive components are developed. Most of the component models can generate some source code from the component description to start-up with, either in the form of base classes that may be subclassed, or the a form of classes with empty method bodies. The compiled source code, along with a description file, constitutes a primitive component.
to:
!!! Fáze vývoje

Druhá fáze je vývojová. V této fázi je vyvíjen kód pro primitivní (jednoduché) komponenty. Většina komponentových modelů může generovat nějaký zdrojový kód přímo z popisu komponenty (produkt description language), aby bylo kde začít. Můýe generovat buď základní třídy a jejich podtřídy, nebo třídy s prázdnými metodami. Zkompilovaný zdrojový kód, společně s popisem tvoří primitivní (jednoduchou) komponentu.
22 December 2009, 11:25 by Snajberk -
Changed lines 45-52 from:


At first, in the design stage, the application is split into multiple components with well-described functionality in order to decrease the complexity. For each component, there are defined services that component provides and it will require from the surrounding environment.

This approach is repeated recursively, until the designed components are either simple and therefore can be easily implemented using a programming language (primitive components), or are already existing elsewhere and therefore can be reused. The design usually made in a Unified Modeling Language (UML) tool. Based on the created model, the component description is written. For this purpose, a variety of different description languages are used. The most of them are mutations or extensions of the Interface Description Language (IDL).

Using the description languages, interfaces are defined as sets of callable methods with parameters. Some of the description languages can also be used to define properties, constants, structures, and exceptions. The Component Description Language (CDL) can furthermore define frames and architectures. A frame is a group of multiple interfaces, where each of them is used either as a provision or as a requirement. An architecture is a "gray-box description of a component", declaring either the fact that the component is primitive or defining how the component is composed of subcomponents at the first level, considering the subcomponents only as frames.
to:
Na začátku této etapy je aplikace rozdělena do množství komponent s dostatečně popsanou funkcionalitou, aby byla snížena složitost aplikace. Pro každou komponentu jsou pak definovány služby, které bude poskytovat a které bude požadovat.

Tento postup je rekurzivně opakován, dokud nejsou navrhované komponenty buď jednoduché a tudíž mohou být snadno implementovány použitím programovacího jazyka (jednoduché komponenty), nebo již existují jinde a tudíž mohou být použity znovu (reused). Design aplikace je obvykle vytvářen pomocí UML (Unified Modeling Language) nástrojů. Dle vytvořeného modelu jsou komponenty popsány. Pro tento účel je zde řada jazyků - description languages. Většina z nich jsou mutace, nebo rozšíření IDL (Interface Description Language).

Díky těmto jazykům jsou definovány interfacy jako množina volatelných metod s parametry. Některé description languages mohou být rovněž použity k definování vlastností (properties), konstant, struktur a výjimek. CDL (Component Description Language)může dále nadefinovat frame a architekturu. Frame je skupina několika interfaců, kde každý z nich se používá pro poskytování, nebo je vyžadován. Architektura je gray-boxový popis komponenty, deklarující buď fakt, že komponenta je primitivní (jednoduchá), nebo definující jak je komponenta složena z pod-komponent na první úrovni, kde se považují komponenty jen jako framy.
22 December 2009, 11:05 by Snajberk -
Added lines 45-46:

Changed lines 75-79 from:
!!! IoC

Inversion of Control je nejtypičtějším vzorem (design pattern) v komponentových systémech. Základní koncept IoC (rovněž známé jako dependency injection) je v tom, že si objekty nevytvářím, ale pouze specifikuji druh a parametry objektu a někdo (něco) jiný pro mě tyto objekty vytvoří.

to:
!!! [IoC]

Inversion of Control je nejtypičtějším vzorem (design pattern) v komponentových systémech. Základní koncept [IoC] (rovněž známé jako dependency injection) je v tom, že si objekty nevytvářím, ale pouze specifikuji druh a parametry objektu a někdo (něco) jiný pro mě tyto objekty vytvoří.

22 December 2009, 11:04 by Snajberk -
Changed lines 67-72 from:
!! Important Principles

!!! Isolation of Components

The basic principle of CBSE is Isolation of components, it should be also named as black-box model. Implementation of component is hidden behind its interface. There is no possibility to call a functionality not present in interface.
to:
!! Důležité zásady

!!! Separace komponent (Isolation of Components)

Základní princip komponentového softwarového inženýrství (CBSE) je separace komponent, rovněž nazývaná jako black-box model. Implementace komponent je skrytá za svým interfacem. Neexistuje žádný způsob, jak zavolat funkcionalitu, která není v interfacu.
Changed lines 75-77 from:
Inversion of Control is the most typical design pattern for component systems. The basic concept of the IoC (sometimes also known as dependecy injection) is that you do not create your objects but you specify what kind of objects are you handling and somebody else will create this objects for you.

to:
Inversion of Control je nejtypičtějším vzorem (design pattern) v komponentových systémech. Základní koncept IoC (rovněž známé jako dependency injection) je v tom, že si objekty nevytvářím, ale pouze specifikuji druh a parametry objektu a někdo (něco) jiný pro mě tyto objekty vytvoří.

22 December 2009, 10:58 by Snajberk -
Changed lines 39-44 from:
!! Component Development Process

In the traditional component-oriented development process, as it is usually described, we can identify multiple distinct stages on the path from an idea to a running application. Depending on a concrete component model, some of these stages can be more or less extensive or missing.

!!! Design Stage
to:
!! Proces vývoje komponent

V tradičním komponentově orientovaném vývojovém procesu, tak jak je obvykle popsán, můžeme identifikovat několik rozdílných etap na cestě od nápadu k běžící aplikaci. V závislosti na konkrétním komponentovém modelu mohou být některé z těchto etap více, či méně rozsáhlé, či úplně chybět.

!!! Etapa návrhu
22 December 2009, 10:52 by Snajberk -
Changed lines 37-38 from:
Component framework is an implementation of a component model. One framework is able to implement more models than only one. A component framework provides a variety of runtime services to support and enforce the component model(s). In many respects component frameworks are like special-purpose operating systems, although they operate at much higher levels of abstraction.
to:
Komponentový 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) určených k podpoře a uplatnění komponentového modelu. V mnoha ohledech jsou komponentové frameworky jako operační systémy , ačkoliv pracují na mnohem vyšší úrovni abstrakce.
22 December 2009, 10:43 by Snajberk -
Changed lines 21-26 from:
Komponenta je softwarový package nebo modul, který sdružuje podobné funkce. Každá komponenta má svůj vlastní interface, který je viditelný okolnímu světu. Všechno, co není součástí interfacu (objekty, funkce a data použité pro implementaci), by mělo zůstat skryté. Tento postup nazýváme black-boxem. Ačkoliv je black-boxová komponenta jen ideální vzor, který je ve skutečnosti nedosažitelný, je tento pojem používán.

An individual component is software package or module, that encapsulates a set of related functions. Each component has its own interface, which is visible for surrounding world. Everything, what is not part of interface (objects, functions and data used for implementation) should be hidden. We call this principle the black-box model. Although black-box model of components is only ideal pattern, which is unreachable in the real world, this term is widely used. Definition of software component is not stable, but this general compliance exists:

Pro softwarovou komponentu platí:
to:
Komponenta je softwarový package nebo modul, který sdružuje podobné funkce. Každá komponenta má svůj vlastní interface, který je viditelný okolnímu světu. Všechno, co není součástí interfacu (objekty, funkce a data použité pro implementaci), by mělo zůstat skryté. Tento postup nazýváme black-boxem. Ačkoliv je black-boxová komponenta jen ideální vzor, který je ve skutečnosti nedosažitelný, je tento pojem používán. Definice softwarové komponenty není ustálená, ale obecně platí platí:
Changed lines 27-36 from:
!!! Component Interface

Component interface is part (layer) of component, which is visible from other world. It describes, what component can and what it needs for. Interface can be described either by programming language or by IDL -- Interface definition language. On the basis of interfaces of two components deployed in one environment, a contract can be established.

!!! Component Model

A component model is the set of component types, their interfaces, and, additionally, a specification of the allowable patterns of interaction among component types.

!!! Component Framework
to:
!!! Komponentové rozhranní (interface)

Rozhranní je část komponenty, která je viditelná ostatním. Popisuje, co komponenta umí a co pro to potřebuje. Rozhranní může být popsáto buď programovacím jazykem, nebo pomocí IDL -- Interface definition language. Díky rozhranní může být mezi dvěmi komponentami navázána komunikace (contract - když jedna komponenta používá druhou pomocí rozhranní).

!!! Komponentový model

Komponentový model je souhrn typů komponent, jejich rozhranní a dodatečně specifikací povolených typů komunikace (patterns of interaction) mezi komponentami jednotlivých typů.

!!! Komponentový framework
18 December 2009, 11:39 by Snajberk -
Added lines 21-22:
Komponenta je softwarový package nebo modul, který sdružuje podobné funkce. Každá komponenta má svůj vlastní interface, který je viditelný okolnímu světu. Všechno, co není součástí interfacu (objekty, funkce a data použité pro implementaci), by mělo zůstat skryté. Tento postup nazýváme black-boxem. Ačkoliv je black-boxová komponenta jen ideální vzor, který je ve skutečnosti nedosažitelný, je tento pojem používán.
Changed lines 25-30 from:
Software component is:

* an opaque implementation of functionality
* third-party composition
* conformant with a component model
to:
Pro softwarovou komponentu platí:

* neprůhledná implementace funkcionality
* je skládána třetí stranou (third-party)
* odpovídá komponentovému modelu
18 December 2009, 11:30 by Snajberk -
Changed lines 13-14 from:
!! Basic terms
to:
!! Základní pojmy
Changed lines 17-20 from:
Imagination of basic terms. From [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachman00]]

!!! Component
to:
Představení základních pojmů. [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachman00]]

!!! Komponenta
18 December 2009, 11:29 by Snajberk -
Changed lines 9-12 from:
!! Motivation

In the last ten years, software components gained a significant role in the software development process. Although several different specifications (usually referred to as component models) of what a software component actually is were introduced, the basic idea behind the scene is more or less the same. The main idea of the component-oriented approach is splitting the code of an application into several, well-formed pieces (usually called components), with well-defined functionality (usually called specification) and with unified access points (usually called interfaces). These terms are fundamental and we will describe them deeply in the next subsection.
to:
!! Proč komponenty

V posledních deseti letech získaly komponenty významnou roli v procesu vývoje softwaru. Ačkoliv bylo představeno několik rozdílných specifikací (označovány jako komponentové modely), co to vlastně softwarová komponenta doopravdy je, základní myšlenka je stále víceméně stejná. Základním kamenem komponentově orientovaného přístupu je dělení kódu aplikace do několika samostatných částí (nazýváme je komponentami), s definovanou funkcionalitou (nazýváme ji specifikací) a se sjednocenými přístupovými body (nazýváme je rozhranní[interfaces]). Toto byly základní pojmy o kterých se budeme bavit více do hloubky v následujících kapitolách.
17 December 2009, 16:40 by Snajberk -
Changed line 84 from:
* návod na jednoduchou HelloWorld aplikaci
to:
* návod na jednoduchou [=HelloWorld=] aplikaci
Changed line 95 from:
* "server" komponenta, která exportuje službu na rozhranní IMsgGen, které má jednu metodu @@String getMsg()@@
to:
* "server" komponenta, která exportuje službu na rozhranní [=IMsgGen=], které má jednu metodu @@String getMsg()@@
Changed lines 108-110 from:
* "KonfiguraceZarizeni" poskytuje konfiguraci ostatním komponentám - "frekvence" pro "Branu" a "kapacita" pro "Parkoviste"

to:
* "[=KonfiguraceZarizeni=]" poskytuje konfiguraci ostatním komponentám - "frekvence" pro "Branu" a "kapacita" pro "Parkoviste"

17 December 2009, 16:39 by Snajberk -
Added line 103:
Changed lines 105-113 from:
* ""

The component model has these components, shown also on diagram below:
* "gate" which generates arrivals/departures (random), calling parking lot's svc to register these arrivals/departures
* "parking lot" which announces via events how many places are free, setting the count according to the service methods called
* "board" above the motorway which tells how many places are free
* "pannel" which controls the whole system
* "configuration" library component providing also configuration parameters ("frequency" for gate, "capacity" for parking lot)
to:
* "Brana" která náhodně generuje příjezdy/odjezdy a volá "Parkoviste", aby si je zpracovalo
* "Parkoviste" které přes události oznamuje kolik je volných míst, které se nastavují přes metody volané "Branou"
* "Tabule" vypisuje kolik je volných míst
* "KonfiguraceZarizeni" poskytuje konfiguraci ostatním komponentám - "frekvence" pro "Branu" a "kapacita" pro "Parkoviste"

17 December 2009, 16:34 by Snajberk -
Changed lines 80-81 from:
!! Praktická část
to:
! Praktická část
Changed lines 91-92 from:
!!! Message printer
to:
!! Message printer
Changed lines 99-103 from:
!!! Parkoviště


Next a more complex thingy. The scenario is as follows: above motorway there is a board announcing how many places are free at our parking lot. Cars, buses and trucks enter and leave the lot via gate, being allowed entry only if there is space for the given type of vehicle on the parking lot - car takes 1 space, bus 2 spaces, truck 4 spaces. Parking lot announces the remaining capacity for the board to display.
to:
!! Parkoviště

Jako další je zde trochu komplexnější příklad, s následujícím scénářem: u dálnice je tabule, která motoristy informuje o tom, kolik je ještě volných míst na parkovišti. Auta, autobusy a náklaďáky přijíždí a odjíždí přes bránu, která pouští pouze v případě, že se na parkoviště daný typ vozidla vejde - auto spotřebuje jedno místo, autobus 2 místa, náklaďák 4.

Komponentový model má následující komponenty (rovněž znázorněny v diagramu níže):
* ""
17 December 2009, 16:30 by Snajberk -
Changed lines 80-81 from:
!! Používané příklady
to:
!! Praktická část

V praktické části, která je součástí každého popisovaného modelu lze vždy najít:
* tutoriál, jak vytvořit prázdný projekt (někdy spojené s následujícím bodem)
* návod na jednoduchou HelloWorld aplikaci
* implementaci Message printer (viz. níže)
* implementaci Parkoviště (viz. níže)

17 December 2009, 16:26 by Snajberk -
Changed lines 82-83 from:
Tyto příklady jsou převzaty [[https://www.assembla.com/wiki/show/cosi/Tutorial_examples | z projektu CoSi]], který je prezentován v angličtině, proto přikládám i zadání v angličtině.
to:
Tyto příklady jsou převzaty [[https://www.assembla.com/wiki/show/cosi/Tutorial_examples | z projektu CoSi]].
Changed lines 86-95 from:

First a really simple application:

* "server" component which exports a [=IMsgGen=] service with one method String getMsg()
* "client" component which imports this service and prints message on standard output


!!! Parking lot

to:
Nejdříve opravdu jednoduchá aplikace:

* "server" komponenta, která exportuje službu na rozhranní IMsgGen, které má jednu metodu @@String getMsg()@@
* "client" komponenta, která importuje tuto službu a vytiskne zprávu na standardní výstup


!!! Parkoviště

17 December 2009, 16:23 by Snajberk -
Changed lines 5-6 from:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech ([[Spring | 1.]], [[Osgi | 2.]], [[SpringDM | 3.]], [[DeclarativeServices | 4.]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
to:
Na této úvodní stránce jsou definovány základní pojmy komponentového světa. V následujících čtyřech částech ([[Spring | 1.]], [[Osgi | 2.]], [[SpringDM | 3.]], [[DeclarativeServices | 4.]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
17 December 2009, 16:08 by Snajberk -
Added lines 9-79:
!! Motivation

In the last ten years, software components gained a significant role in the software development process. Although several different specifications (usually referred to as component models) of what a software component actually is were introduced, the basic idea behind the scene is more or less the same. The main idea of the component-oriented approach is splitting the code of an application into several, well-formed pieces (usually called components), with well-defined functionality (usually called specification) and with unified access points (usually called interfaces). These terms are fundamental and we will describe them deeply in the next subsection.

!! Basic terms

http://www.bauml.cz/content/bachmann00.png

Imagination of basic terms. From [[http://www.sei.cmu.edu/publications/documents/00.reports/00tr008.html | Bachman00]]

!!! Component

An individual component is software package or module, that encapsulates a set of related functions. Each component has its own interface, which is visible for surrounding world. Everything, what is not part of interface (objects, functions and data used for implementation) should be hidden. We call this principle the black-box model. Although black-box model of components is only ideal pattern, which is unreachable in the real world, this term is widely used. Definition of software component is not stable, but this general compliance exists:

Software component is:

* an opaque implementation of functionality
* third-party composition
* conformant with a component model

!!! Component Interface

Component interface is part (layer) of component, which is visible from other world. It describes, what component can and what it needs for. Interface can be described either by programming language or by IDL -- Interface definition language. On the basis of interfaces of two components deployed in one environment, a contract can be established.

!!! Component Model

A component model is the set of component types, their interfaces, and, additionally, a specification of the allowable patterns of interaction among component types.

!!! Component Framework

Component framework is an implementation of a component model. One framework is able to implement more models than only one. A component framework provides a variety of runtime services to support and enforce the component model(s). In many respects component frameworks are like special-purpose operating systems, although they operate at much higher levels of abstraction.

!! Component Development Process

In the traditional component-oriented development process, as it is usually described, we can identify multiple distinct stages on the path from an idea to a running application. Depending on a concrete component model, some of these stages can be more or less extensive or missing.

!!! Design Stage

At first, in the design stage, the application is split into multiple components with well-described functionality in order to decrease the complexity. For each component, there are defined services that component provides and it will require from the surrounding environment.

This approach is repeated recursively, until the designed components are either simple and therefore can be easily implemented using a programming language (primitive components), or are already existing elsewhere and therefore can be reused. The design usually made in a Unified Modeling Language (UML) tool. Based on the created model, the component description is written. For this purpose, a variety of different description languages are used. The most of them are mutations or extensions of the Interface Description Language (IDL).

Using the description languages, interfaces are defined as sets of callable methods with parameters. Some of the description languages can also be used to define properties, constants, structures, and exceptions. The Component Description Language (CDL) can furthermore define frames and architectures. A frame is a group of multiple interfaces, where each of them is used either as a provision or as a requirement. An architecture is a "gray-box description of a component", declaring either the fact that the component is primitive or defining how the component is composed of subcomponents at the first level, considering the subcomponents only as frames.

!!! Development Stage

The second stage is the development stage. In this stage, source codes for the primitive components are developed. Most of the component models can generate some source code from the component description to start-up with, either in the form of base classes that may be subclassed, or the a form of classes with empty method bodies. The compiled source code, along with a description file, constitutes a primitive component.

!!! Assembly Stage

In the assembly stage, the primitive and the reused components are assembled into an assembly tree. The root of the tree represents the entire component (application), while the children of each node represent subcomponents of a composed component represented by the parent node. The leaves of the tree represent either primitive components or existing components that are reused.

The information that can be represented by the inner leaves is how to interconnect the interfaces of the component with the interfaces of the subcomponents. Depending on the component model, this information is created during the development stage using an architecture element, or it is created during the assembly stage.

Also, the property values can be set during this stage to provide the component with default configuration data. The information created during the assembly stage has a form of an XML file, called the assembly descriptor.

!!! Deployment Stage

The last stage on the way to a running application is the deployment stage. In this stage, the configuration values in the assembly descriptor are customized according to the individual needs and the deployments units are configured. A deployment unit is a set of components with the same value of the location parameter, defining a reference to a server where the component will be run. The information entered during the assembly stage is again written in a form of an XML file, called the deployment descriptor.

!! Important Principles

!!! Isolation of Components

The basic principle of CBSE is Isolation of components, it should be also named as black-box model. Implementation of component is hidden behind its interface. There is no possibility to call a functionality not present in interface.

!!! IoC

Inversion of Control is the most typical design pattern for component systems. The basic concept of the IoC (sometimes also known as dependecy injection) is that you do not create your objects but you specify what kind of objects are you handling and somebody else will create this objects for you.

17 December 2009, 16:06 by Snajberk -
Changed lines 9-35 from:
to:
!! Používané příklady

Tyto příklady jsou převzaty [[https://www.assembla.com/wiki/show/cosi/Tutorial_examples | z projektu CoSi]], který je prezentován v angličtině, proto přikládám i zadání v angličtině.

!!! Message printer


First a really simple application:

* "server" component which exports a [=IMsgGen=] service with one method String getMsg()
* "client" component which imports this service and prints message on standard output


!!! Parking lot


Next a more complex thingy. The scenario is as follows: above motorway there is a board announcing how many places are free at our parking lot. Cars, buses and trucks enter and leave the lot via gate, being allowed entry only if there is space for the given type of vehicle on the parking lot - car takes 1 space, bus 2 spaces, truck 4 spaces. Parking lot announces the remaining capacity for the board to display.

The component model has these components, shown also on diagram below:
* "gate" which generates arrivals/departures (random), calling parking lot's svc to register these arrivals/departures
* "parking lot" which announces via events how many places are free, setting the count according to the service methods called
* "board" above the motorway which tells how many places are free
* "pannel" which controls the whole system
* "configuration" library component providing also configuration parameters ("frequency" for gate, "capacity" for parking lot)

https://www.assembla.com/spaces/cosi/documents/cNiLQuHYyr3QHfeJe5afGb/download?filename=parkoviste-diagram.png
17 December 2009, 16:01 by Snajberk -
Changed lines 5-6 from:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech ([[Spring | 1. Spring]], [[Osgi | 2. OSGi]], [[SpringDM | 3. Spring DM]], [[DeclarativeServices | 4. Declarative Services]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
to:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech ([[Spring | 1.]], [[Osgi | 2.]], [[SpringDM | 3.]], [[DeclarativeServices | 4.]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
17 December 2009, 16:00 by Snajberk -
Changed lines 5-6 from:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech ([[Spring | 2]], [[Osgi | 3]], [[SpringDM | 4]], [[DeclarativeServices | 5]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
to:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech ([[Spring | 1. Spring]], [[Osgi | 2. OSGi]], [[SpringDM | 3. Spring DM]], [[DeclarativeServices | 4. Declarative Services]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
17 December 2009, 16:00 by Snajberk -
Changed lines 5-6 from:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech (2, 3, 4, 5) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
to:
V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech ([[Spring | 2]], [[Osgi | 3]], [[SpringDM | 4]], [[DeclarativeServices | 5]]) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.
17 December 2009, 15:58 by Snajberk -
Changed lines 9-10 from:
[[Navigation]]
to:
17 December 2009, 15:56 by Snajberk -
Changed lines 1-12 from:
TBD úvodní slovo proč je to tu a co tu hledat


!! Teoretický úvod do komponent

(include)
KomponentTutorialTeorie1

!! Praktické seznámení s několika komponentovými frameworky

KomponentTutorial
to:
!! Úvod

Tento tutoriál byl napsán, aby vám pomohl začít s komponentami. 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í [[http://eclipse.org/ | Eclipse]] (nebo [[http://www.springsource.com/products/sts | SpringSource Tool Suite]] - což je Eclipse s pluginy pro vývoj spring a osgi).

V této úvodní části jsou popsány základní koncepty každého komponentového systému. V následujících čtyřech částech (2, 3, 4, 5) jsou popsány konkrétní komponentové modely, jejichž použití je následně předvedeno v příslušném komponentovém frameworku.

(:include Navigation :)

[[Navigation]]
17 December 2009, 15:15 by PremekBrada -
Deleted line 0:
Changed lines 7-8 from:
to:
KomponentTutorialTeorie1
17 December 2009, 15:05 by PremekBrada -
Changed lines 1-4 from:
Teoretický úvod do komponent: [KomponentTutorialTeorie1]

Praktické seznámení s několika komponentovými frameworky: [KomponentTutorial]
to:

TBD úvodní slovo proč je to tu a co tu hledat


!! Teoretický úvod do komponent

(include)

!! Praktické seznámení s několika komponentovými frameworky

KomponentTutorial
17 December 2009, 14:44 by PremekBrada -
Changed line 6 from:
Patří do KategorieProjekty, KategorieNavody
to:
Patří do Main/KategorieProjekty, Main/KategorieNavody
17 December 2009, 14:44 by PremekBrada -
Added lines 4-6:

----
Patří do KategorieProjekty, KategorieNavody
16 December 2009, 10:03 by Snajberk -
Changed lines 1-2 from:
http://bauml.cz/
http://ul408p05-kiv.fav.zcu.cz/wiki/index.php?title=Hlavn%C3%AD_strana
to:
Teoretický úvod do komponent: [KomponentTutorialTeorie1]

Praktické seznámení s několika komponentovými frameworky: [KomponentTutorial]
15 December 2009, 10:23 by PremekBrada -
Added lines 1-2:
http://bauml.cz/
http://ul408p05-kiv.fav.zcu.cz/wiki/index.php?title=Hlavn%C3%AD_strana