Flexibilní obchodní procesy

Rychlost a flexibilita nejsou ve vývojářské práci založené na skládání komponent žádnými kouzly jsou výsledkem s...


Rychlost a flexibilita nejsou ve vývojářské práci založené na skládání
komponent žádnými kouzly jsou výsledkem správně definovaného postupu. Základní
předpoklad ovšem spočívá v chápání obchodního procesu jako řady dílčích procesů
a elementárních služeb. Jednotlivé částečné procesy nebo služby jsou v takovém
případě reprezentovány příslušnými komponentami. Tyto jsou poté volně
propojovány dohromady a vzájemně komunikují prostřednictvím co nejštíhlejších
rozhraní. Klíčem k úspěchu vývojářské práce s podporou komponent jsou
následující tři iterativní kroky: identifikace komponent, jejich specifikace
pomocí popisu jejich rozhraní a návrh architektury, která umožní optimální
integraci jednotlivých komponent.
Komponenty lze získávat různými způsoby. Na výběr je vlastní vývoj, vývoj na
zakázku, nákup hotových komponent či tzv. wrapping starých systémů a jejich
"naroubování" na aplikace nebo na virtuální služby poskytované v rámci
internetu. V každém případě jsou základem pro získání či přípravu komponent
jejich přesná specifikace a architektura. Ať už si komponenty vytváříte ve své
firmě, nebo práci zadáte někomu jinému, vše jde mnohem snadněji, když jsou
rozhraní a architektura specifikovány s pomocí jednotných jazykových prostředků.
Za tímto účelem je k dispozici v současnosti už prakticky všeobecně přijatý či
respektovaný standard, který má podobu jazyka Unified Modeling Language (UML).
Jazyk UML v dnešní podobě však nenabízí žádné vlastní výrazové prostředky pro
samotnou specifikaci komponent. Takzvané diagramy komponent (component
diagrams) předepsané jazykem UML pokrývají pouze problematiku spojenou
implementací a zabalením jednotlivých komponent, takzvané diagramy nasazení
(deployment diagram) pak popisují jejich distribuci. Potěšitelné je, že jazyk
UML nabízí prostřednictvím stereotypů a tzv. tagged values definované možnosti
rozšíření.
Cílem vývojářské práce založené na použití komponent je pokud možno optimálně a
pružně podporovat obchodní procesy. Možnosti snadné implementace IT řešení lze
dosáhnout pouze dobrým sladěním modelování obchodních procesů na jedné straně a
vývojem založeným na podpoře komponent na straně druhé. Přitom je nutné nejprve
dosáhnout vyšší flexibility vlastních obchodních procesů a poté nově
strukturované procesy vyjádřit v podobě IT řešení.
Celý proces se odlišuje od zavedených postupů vývoje softwaru. Ve středu jeho
zájmu totiž nestojí vlastní vývoj, nýbrž specifikace jednotlivých komponent,
která je předpokladem pro následnou prezentaci komponent navenek. Zároveň
předpokládá jasné oddělení specifikace od implementace a vymezuje rámec pro
dobře definovanou a zapouzdřenou funkčnost. Důležité přitom je, že všechny fáze
komponentově orientovaného vývoje jsou založeny na použití jednotných, průběžně
se vyvíjejících standardů UML. Díky tomu jsou jednotlivé systémové prvky
přenositelné mezi různými fázemi vývoje. Zdokumentovaná a vysvětlená podoba
specifikace komponent otevírá každému oddělení IT dostatečný prostor k tomu,
aby si mohlo zvolit jednu z početných možností pořizování, doplňování nebo
výměny komponent.o

UML a komponenty: Pro moderní vývoj
Vývoj založený na využívání komponent by měl postupovat ruku v ruce s
restrukturalizací obchodních procesů. Je třeba se vyvarovat funkčně
rozčleněných a vzájemně těsně propojených úloh se složitými rozhraními, a
naopak se zaměřit na volně provázané procesy s orientací na služby.
Přitom je zapotřebí zajistit bezproblémovou komunikaci mezi lidmi zodpovědnými
za modelování procesů a vývojáři komponent. Za tímto účelem nabízí jazyk UML
vhodné podpůrné komunikační nástroje, a to v podobě diagramů aktivit (activity
diagrams) a případů použití (use case diagrams).
Jakým způsobem lze tedy k obchodnímu procesu nalézt odpovídající komponenty IT
řešení? Vzhledem k tomu, že komponenty jsou definovány prostřednictvím svých
rozhraní, přizpůsobuje se i hledání podle rozhraní potenciálních komponent, a
to následovně:
Poté, co je v podobě diagramů aktivit popsán obchodní proces, lze identifikovat
ty aktivity, které mají být počítačově podporovány tyto aktivity jsou
promítnuty do případů použití. S pomocí případů použití a jejich vyobrazení v
use case diagramech lze upřesňovat interakci uživatele se systémem. Každý
případ použití vyvozený z obchodního procesu odpovídá jedné službě pro jednoho
uživatele a tím pádem také jednomu systémovému rozhraní. Sémanticky vzájemně
úzce související služby lze v daném případě připojit k jednomu rozhraní.
Případy použití jsou v praxi konkretizovány většinou v textové podobě.
Předlohy, které vyžadují popis činností podle vzoru "Uživatel provede systém
provede uživatel provede systém provede...", jsou zde velmi užitečné. Každý
krok typu "systém provede" totiž odpovídá jedné operaci systémového rozhraní.
Tímto způsobem nalezená rozhraní jsou dále modelována jako třídy. Samo se
nabízí opatřit takovou třídu stereotypem, který je obsažen v jazyce UML.
Operace systémového rozhraní pracují zpravidla s typickými (obchodními)
objekty. To znamená, že z případů použití a často také z předem namodelovaných
aktivit lze odvodit obchodní třídy pro případové oblasti. Pro zdůraznění
specifikačního charakteru této práce se doporučuje modelovat třídy jako třídy
určitého stereotypu. Obchodní třídy jsou definovány prostřednictvím svých
atributů, jinými slovy prostřednictvím jimi poskytovaných informací. Kromě toho
jsou znázorněny v rámci diagramů tříd, což usnadňuje orientaci v jejich
vzájemných vztazích.
Obchodní třídy a jejich obchodní logika jsou ukryty za definicí příslušných
rozhraní. Na rozdíl od výše zmíněných systémových rozhraní jde v tomto případě
o tzv. obchodní rozhraní (business interface). Jedno nebo několik rozhraní typu
business interface jsou přiřazeny jedné komponentě. Důležité přitom je, aby
práci s jednou obchodní třídou měla na starosti pouze jedna komponenta a aby se
kompetence vzájemně nepřekrývaly.

Rozčlenění komponent
Definováním systémových rozhraní a rozhraní typu business interface lze
identifikovat první komponenty. V dalším kroku pak jde o stabilizaci tohoto
výsledku a o podrobnější specifikaci jednotlivých komponent za účelem jejich
přípravy.
Nyní již nic nestojí v cestě nasazení diagramů aktivit, případů použití a
obchodních tříd bez nutnosti dalšího členění. Avšak vzhledem k tomu, že jde o
specifikaci komponent, měly by být výsledky práce jasně strukturovány. Cílem
přitom je, aby jednotlivé komponenty byly vymodelovány jako uzavřené jednotky,
které navenek prezentují pouze přesně definované vlastnosti (artefakty) a
vyznačují se jasně stanovenými závislostmi. Díky takovéto struktuře je položen
základ pro správu konfigurací a výměnu dat v rámci distribuovaných projektů.
Jazyk UML chápe jako základní strukturalizační prostředek tzv. balíky
(package). Proto je pro každou komponentu vytvořen příslušný package.
Podstatnou vlastností vývoje založeného na použití komponent je oddělení
specifikace komponenty od její implementace. Aby byl tento rys na první pohled
zřejmý, měl by být každý package reprezentující komponentu rozdělen do dvou
"podbalíků" (subpackage): pro artefakty specifikace, respektive implementace.
Na otázku, který balík slouží jakému účelu, lze odpovědět s pomocí stereotypů:
Kontejner pro celou komponentu tvoří balík stereotypu "Component". Subpackage
pro specifikaci lze zaopatřit například stereotypem "Comp Spec", jeho
implementaci pak označit "Implementation". Nalezená systémová rozhraní a
rozhraní typu business interface patří v souladu s tímto členěním také do
subpackage "Comp Spec".

Sestavení řešení
Specifikace oblastí řešení začíná u rozhraní jednotlivých komponent. Toto lze
provádět zcela nezávisle na možných programovacích jazycích, což se doporučuje
zejména v situacích, kdy dosud nepadlo rozhodnutí v otázce platformy pro
vytváření komponent (CORBA, DCOM, J2EE). Pokud je však platforma již známa, lze
s využitím výrazových prostředků zvoleného prostředí dosáhnout cíle mnohem
rychleji. Prostředí CORBA a COM nabízejí jazyky pro popis rozhraní, které jsou
zcela nezávislé na programovacích jazycích, zatímco platforma J2EE se důsledně
přidržuje programovacího jazyka Java.
Podrobné specifikace rozhraní zahrnují jak popisy dat, s nimiž rozhraní
pracují, tak i definice nabízených operací. K popisu zmíněných dat i definic
slouží atributy a metody tříd rozhraní. Nejdůležitějším pomocným prostředkem
jsou v této fázi diagramy interakcí jazyka UML. Vzhledem k tomu, že svůj účel
plní oba typy diagramů interakcí collaboration i sequence diagram, musejí se
členové projektového týmu shodnout na společné volbě.
Následuje výčet nejdůležitějších činností, na které je při modelování interakcí
třeba brát zvláštní zřetel:
optimalizace volání operací se zvláštním zřetelem na výkonnost
definice smysluplných datových typů (izolované definování vlastností nemá v
případě distribuovaných aplikací smysl)
jasné definování zodpovědnosti
důsledné rozčlenění jednotlivých komponent (definování vzájemně nezávislých
základních komponent nebo dodržování struktury vrstev)
jednotlivé komponenty by mělo být možné aplikovat v co možná nejrozmanitějších
souvislostech, tj. nezávisle na typu klientů (vyvstává tak potřeba definovat
vhodné vzory pro sdělování informací).

Dokončení popisu
Poté, co jsou specifikována data, s nimiž rozhraní pracuje, a jeho operace, měl
by být popis rozhraní završen definováním tzv. preconditions a postconditions,
popřípadě invariant. Preconditions a postconditions definují kontrakty na
operační úrovni, invarianty popisují tzv. omezení (Constraint) na úrovni typů.
Platforma UML nabízí pro tento účel speciální popisný jazyk Object Constraint
Language (OCL). Vzhledem k tomu, že služby zodpovědné za provádění operací
zpravidla pracují s daty trvalého charakteru, je součástí specifikace operace
také transakční mód.
Jakmile jsou specifikována rozhraní jednotlivých komponent, může být popsána
také systémová architektura celého IT řešení, tj. sestavena hierarchická
struktura a definovány vzájemné závislosti jednotlivých komponent na úrovni
systému. K tomuto účelu se nabízejí package diagramy jazyka UML. Rozhraní
komponent lze zviditelnit s pomocí tzv. lollipop notace. Pro zobrazení
vzájemných závislostí slouží stereotypizované vztahy Dependency. Přitom je
třeba rozlišovat mezi dvojím druhem závislostí: Vztahy typu "use" specifikují,
které rozhraní serveru je využíváno klientem. Vztahy typu "implement" dávají na
vědomí, že daný balík obsahuje implementaci rozhraní serveru.
Testování závislostí
Na systémové úrovni jsou vytvořeny diagramy popisující architekturu systému. V
balíku komponent jsou orientovány package diagramy tak, aby ukazovaly na
všechny komponenty, které jsou danou komponentou používány.
Ke specifikaci komponent samozřejmě patří také dosud "volné", bez vztahu ke
struktuře balíků založené diagramy aktivit (activity diagrams), případy použití
a obchodní třídy, které nemají žádný vztah ke struktuře prvků typu package.
Tyto "volné" prvky by měly být dodatečně začleněny do package typu Comp Spec,
jehož služby popisují. Tímto krokem je završeno shrnutí všech prvků sloužících
pro definici komponenty do jednoho balíku. Tento package je do sebe uzavřenou
jednotkou s minimem definovaných závislostí což je ideální stav pro vytváření
verzí a jejich distribuci. Na systémové úrovni zůstávají pouze přehledové
diagramy.
Výše popsaná podoba specifikace komponent obsahuje všechny informace, kterých
je zapotřebí k implementaci zmíněných rozhraní.
Komponenty se vyznačují jednou důležitou vlastností jsou nezávislé na místě
použití. Standardizovaný middleware typu DCOM, CORBA či J2EE jim dokáže
poskytnout nezbytné komunikační služby vzhledem k této skutečnosti vyžaduje
každá komponenta jistou "integrační vrstvu". V této vrstvě dochází k nezbytné
konverzi parametrů a v souladu s konvencemi charakteristickými pro použitý
middleware jsou také ošetřovány chybové stavy. Tato integrační vrstva je
objektově orientovaná. Kdyby byla specifikována rozhraní v rámci jazyka pro
popis rozhraní, bylo by pomocí překladače možné vygenerovat kostru pro zmíněnou
integrační vrstvu. Skutečná implementace by měla probíhat ve zvláštních třídách
odděleně od integrační vrstvy.
Popis, která třída implementuje jaká rozhraní, je realizován pomocí
implementačních vztahů jazyka UML. Všechny soubory, které k dané komponentě
patří jako součásti balíku, jsou znázorněny v diagramu komponent. Fyzické
umístění komponent pak může být podle potřeby popsáno v diagramech použití.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.