Vlastnosti a chování je zapouzdřené v jednotlivých objektech. Každý objekt je schopen reagovat na události.

Objektový přístup k analýze a návrhu IS Autor: Ing. Roman Danel, Ph.D., 2012 Objektově orientovaný přístup k analýze a návrhu IS Objektově orientovaný přístup je založen na objektech. Objekt je struktura, která má definované Vlastnosti (atributy) Chování (metody) Vlastnosti a chování je zapouzdřené v jednotlivých objektech. Každý objekt je schopen reagovat na události. Informační systém z pohledu objektově orientovaného přístupu je chápán jako množina spolupracujících objektů. Objektový přístup lépe odpovídá chování reálného světa. Vlastnosti Zapouzdření (encapsulation) - objekt je pro nás černou skříňkou zajímá nás, co dělá a ne z čeho se skládá. Dědičnost - možnost vytvářet nové instance objektů s možností přidat nové prvky Polymorfismus (vícetvarost) překrývání metod, které jsme zdědili metoda stejného jména může mít trochu jinou funkcionalitu, přestože je tato funkcionalita pojmově blízká. Analogie je pojem otevřít a rozdíl mezi funkcí otevřít dveře a otevřít láhev Genericita možnost vytvářet parametrizovatelné programové moduly Srovnání relačního a objektového modelu Relační model prvky reálného světa se snažíme zobrazit do pevných předem připravených struktur Objektově orientovaný model pro prvky reálného světa vytváříme objekty, které se jim podobají Roman Danel 1

Základní prvky objektového přístupu Objekt Konkrétní prvek vyskytující se v systému, který má definované vlastnosti a chování Třída (Class) Kategorie (skupina) objektů, které mají podobné vlastnosti a stejné nebo podobné chování Atributy (Properties) Slouží k popisu vlastností třídy (objektu). Metody (Methods) Algoritmy definující reakce objektu na vzniklé situace K objektu můžeme přistupovat pouze využitím metod. Instance třídy Daný objekt je instancí určité třídy, tedy jejím konkrétním výskytem. Objekt ze strany třídy dědí atributy a metody. Hierarchie tříd Třídy mají svou hierarchii, založené na dědičnosti. Hierarchii tříd je možné budovat dvěma způsoby: Směr specializace návrh obecných tříd a postupnému odvozování speciálních podtříd Směr generalizace návrh objektů, jejich tříd a postupnému zobecňování Abstraktní třída Z abstraktních tříd se neodvozují konkrétní objekty; slouží k odvozování speciálnějších podtříd (potomků). Neexistuje konkrétní instance této třídy. Rozhraní (interface) Pojmenovaná množina operací, které třída používá ve vztahu k jiným třídám. Vztah mezi třídou a jejím rozhraním říkáme realizace. Roman Danel 2

UML UML neboli Unified Modeling Language je nástroj pro modelování informačních systémů založený na objektově orientovaném přístupu. Je přijat sdružením OMG (Object Management Group) jako standard pro tvorbu informačních systémů. Jedná se o nejrozšířenější objektovou notaci, která je podporována všemi CASE nástroji. Jednou z důležitých charakteristik UML je jeho nezávislost na metodologiích. Možná i z toho pramení jeho široké rozšíření jakožto implementačního jazyka. UML jako prostředek na zachycení popisu prostředí je nezávislý na metodologii používané pro správné provedení analýzy a designu. Diagramy UML UML nabízí k popisu 12 typů diagramů, rozdělených do tří skupin. První skupina diagramů popisuje statickou strukturu aplikace. Druhá skupina popisuje různé aspekty dynamického chování. Třetí slouží k organizaci a správě aplikačních modulů. Statická struktura Dynamické chování Správa modulů diagram tříd (Class Diagram) use case diagram balíčky (Packages) objektový diagram (Object Diagram) komponentový diagram (Component Diagram) diagram nasazení (Deployment Diagram) sekvenční diagram (Sequence Digram) diagram činností (aktivit) (Activity Diagram) diagram spolupráce (Collaboration Diagram) stavový diagram (Statechart Diagram) subsystémy (Subsystems) modely (Models) Diagram komponent a diagram nasazení reprezentují implementační model. Poznámka. UML nezahrnuje DFD diagramy (Data Flow Diagramy), které slouží v strukturované analýze k popisu chování systému. Datové toky a jiné typy diagramů, které nebyly do UML zahrnuty, nezapadají čistě do konsistentního objektově orientovaného paradigmatu. Diagramy aktivit a diagramy spolupráce splňují mnoho z toho, co lidé chtějí od DFD. Diagramy aktivit jsou zároveň vhodné pro modelování workflow. Roman Danel 3

Diagramy pro popis statické struktury Diagram tříd Diagram tříd zachycuje všechny třídy objektů, které se týkají modelovaného systému (tj. celou oblast zájmu řešení) a vztahy mezi těmito třídami (asociace). Třída obsahuje atributy a metody. Jednotlivé atributy a metody mohou mít označenu viditelnost. Je podporována možnost tříd typu interface, template a metatříd. Diagram tříd koresponduje s ERD diagramem v klasickém strukturálním modelování. Vztah (asociace) souvislost mezi dvěma objekty. Jsou dovoleny kvalifikované vztahy, vztahy s hodnotami i N-arní vztahy. Obr. 1. Ukázka diagramu tříd Roman Danel 4

Diagram objektů Objekty jsou instance tříd. Objekty jsou propojeny linky. Název konkrétního objektu se zapisuje před název třídy a odděluje se dvojtečkou. Diagram komponent Diagram komponent představuje znázornění komponent budoucího počítačového systému. Komponenta může být jakákoliv implementace třídy (nebo více tříd). Diagram komponent tedy zachycuje strukturu budoucího systému. Komponenty mají tu výhodu, že, jsou-li dobře navržené, mohou být opakovaně používány v různých projektech. Komponenty se v diagramu komponent znázorňují obdélníkem se dvěma malymi obdélníky položenými přes jeho levou stranu. Komponenty komunikují s okolím přes rozhraní. Jedná se o sadu operací vypovídajících o chování komponenty. Vztah mezi komponentou a jejím rozhraním se nazývá realizace (stejně jako v případě tříd, viz výše). Rozhraní je možné v diagramu komponent znázornit dvěma způsoby, obdobně jako znázornění rozhraní u třídy. První způsob zachycuje rozhraní jako třídu se stereotypem «rozhraní» v názvu. Realizace se pak znázorňuje přerušovanou šipkou s hrotem ve tvaru trojúhelníka. Druhý způsob (zjednodušený) zachycuje rozhraní malým kroužkem. Zde se realizace znázorňuje plnou čarou. Komponenty mohou přes rozhraní spolu komunikovat. Komponenta, která poskytuje své funkce, nabízí exportní rozhraní. Komponenta, která využívá funkce jiné komponenty, používá importní rozhraní. Závislost, tedy vztah mezi komponentou a importovaným rozhraním se znázorňuje přerušovanou šipkou. Existují tři typy komponent, a to rozmísťované, podpůrné a prováděcí. Rozmísťované komponenty tvoří základ spustitelných systémů (např. spustitelných souborů, prvků ActiveX). Z podpůrných komponent se rozmísťované komponenty vytváří. Jsou jimi např. zdrojové soubory. Prováděcí komponenty jsou takové, které vznikají za běhu systému (např. soubory vytvářené za běhu programu, jako uložení stavu práce). Diagram nasazení Zachycuje fyzickou architekturu počítačového systému. Pomocí něho je možné zobrazit počítače a zařízení, znázornit jejich vzájemná připojení a také software, který je na určitém zařízení nainstalován. Hlavním hardwarovým prvkem je uzel, což může být jakýkoliv druh výpočetního prostředku. Uzel může být dvojího druhu, a to procesor, nebo zařízení (např. tiskárna nebo monitor). Procesor, na rozdíl od zařízení, umí spouštět komponentu. Uzel se zakresluje jako kvádr. Odlišení, zda se jedná o procesor nebo zařízení, je možné znázornit např. pomocí stereotypů «procesor» a «zařízení»v uzlu mohou být uvedeny i další informace, jako např. komponenty šířené na uzlu. Mezi uzly mohou existovat různé typy vazeb, jako je spojení, agregace a závislost. Roman Danel 5

Diagramy pro popis dynamického chování Sekvenční diagram Zachycuje časovou sekvenci interakce mezi objekty tříd, ke které dochází při komunikaci (předávání činnosti) v systému. Sekvenční diagram se znázorňuje následovně. Objekty jsou umístěny v horní části diagramu vedle sebe zleva doprava. Směrem dolů od každého objektu směřuje přerušovaná čára, která se nazývá životočára (lifelines). Vykonání operace, kterou má objekt za úkol provádět se označuje jako aktivace a je znázorněna jako úzký obdélníček podél životočáry. Délka obdélníku naznačuje, jak dlouho aktivace trvá. Podél životočáry vertikálně dolů ubíhá čas. Zprávy zasílané mezi objekty (přechody mezi aktivacemi objektů) se znázorňují šipkou. Zprávy dělíme na jednoduché, synchronní a asynchronní. Jednoduchá zpráva představuje přechod řízení z jednoho objektu na druhý. Synchronní zpráva je zpráva, kterou zasílá jeden objekt druhému, poté první objekt čeká na odpověď. Dokud ji nedostane, nebude nic dělat. Pošle-li objekt asynchronní zprávu, nečeká na odpověď, ale pokračuje ve své práci. Jednoduchá zpráva se znázorňuje obyčejnou šipkou, synchronní zpráva se znázorňuje vyplněnou šipkou a asynchronní jako šipka s polovinou hrotu. Sekvenční diagram v UML může být doplněn o účastníka, který sekvenci z vnějšku zahajuje. Tento účastník se pak znázorňuje jako panáček (obdobně jako aktor v use case diagramu). Tento symbol však není součástí symboliky sekvenčních diagramů (využívá se zde tedy vlastnosti pružnosti metodiky UML, jak bylo zmíněno na začátku kapitoly o UML). Instanční sekvenční diagram popisuje pouze jednu instanci use case. Generický sekvenční diagram zachycuje všechny scénáře (instance) daného use case. Sekvenční diagramy obsahují také konstrukty. Podmínky se zapisují do hranatých závorek nad příslušnou šipku. Podmínky pak způsobují selekci ( rozdvojení ) toku řízení. Příslušná zpráva se tedy rozdělí do dvou větví. Každá větev směřuje ke stejnému objektu, avšak tento objekt bude na každou z nich reagovat odlišně. To se znázorní rozdvojením jeho životočáry. Rozdvojené životočáry se později někde spojí. Dalším konstruktem je cyklus (iterace). Uzavírá se také do hranatých závorek, před levou závorku se navíc píše hvězdička. Roman Danel 6

Obr. 2. Příklad sekvenčního diagramu Sekvence může vést k vytvoření nového objektu. Tento nový objekt se znázorní klasickým způsobem, avšak nezakreslí se v sekvenčním diagramu nahoru k dalším (původně existujícím) objektům, ale umístí se níže v diagramu tak, aby jeho pozice odpovídala času vzniku. Zpráva, která vede ke vzniku takového objektu, se pak může označit stereotypem «vytvořit». Objekty mohou i zanikat. V sekvenčním diagramu se to znázorní tak, že na konec jeho životočáry se nakreslí X. Objekt dále může provést operaci, kterou osloví sám sebe. Nazývá se to rekurze. Šipka tedy ukazuje na tu samou aktivace (operaci), ze které vychází. Sekvenční diagram spolu s diagramem spolupráce (Collaboration Diagram) patří do skupiny interakčních diagramů (Interaction Diagrams). Tyto dva diagramy jsou téměř izomorfní - tj. dají se převádět z jednoho tvaru na druhý (často i automatizovaně). Použití sekvenčního diagramu bývá vhodnější v těch případech, kde jsou důležité časové souvislosti interakcí. Objekty si mohou posílat zprávy. Sekvenční diagram zobrazuje jejich časovou posloupnost. Časová osa je svislá (čas běží shora dolů), na vodorovné ose jsou rozmístěny objekty: objekt se zobrazuje stejně, jako v objektovém diagramu (ovšem bez hodnot a atributů) čára života (lifeline) ukazuje, kdy objekt žije - v tomto diagramu všechny objekty existovaly už před posláním první zprávy, a dále existují po dokončení sekvenčního diagramu (resp. nevíme, kdy který objekt zanikne nebo nás to v tuto chvíli nezajímá) aktivita objektu (focus of control) ukazuje, kdy je který objekt aktivní zpráva Roman Danel 7

Diagram případů užití - Use case diagram Use case diagram (UC diagram) zobrazuje chování systému (nebo jeho části) z hlediska uživatele. Jedná se o popis chování systému z pohledu uživatele. Zachycuje tedy uživatelovy požadavky na systém. Myšlenkou je zapojit uživatele do počátečních fází analýzy a návrhu systému. Zvyšuje to pravděpodobnost, že systém nakonec bude skutečně prospěšný pro ty lidi, pro které prospěšný být má. Pro označení uživatele se používá název aktor (popř. aktér). Činnost systému, jako odezva aktorovi (může to být osoba, jiný systém, hardware, plynutí času), se nazývá use case. Každý případ užití, typová činnost (use case) charakterizuje určité použití systému účastníkem; use case má jméno, může mít textovou specifikaci. Účastník (actor) reprezentuje kohokoliv (či cokoliv) mimo systém, kdo se systémem komunikuje a interaguje (člověk, HW, čidlo, jiný systém, ); jediné, co aktor může, je přijímat nebo předávat do systému informace. Spíše než konkrétního uživatele reprezentuje aktor roli: jeden konkrétní účastník (člověk, technické zařízení, jiný informační systém,...) může být vyjádřen i více aktory (vystupují ve stejné roli), a více různých konkrétních účastníků může být vyjádřeno jedním aktorem (vystupují ve společné roli). Ohraničení (boundary) udává hranice systému/susbsystému (zde videopůjčovna); obecně je to vlastně klasifikátor (systém/subsystém/třída), jehož funkcionalitu pomocí use case popisujeme. Roman Danel 8

Obr. 3. Ukázka USE-CASE diagramu automatizovaná půjčovna V těchto specifikacích by mělo být zejména popsáno: co systém dělá (ale ne jak to dělá) měly by být používány jen pojmy problémové domény jak a kdy činnost začíná a končí kdy má systém interakce s aktorem které údaje jsou měněny jaké kontroly vstupních údajů jsou prováděny základní, alternativní a chybové průběhy způsoby popisu nejsou v UML formalizovány: může to být strukturovaný/formátovaný text, pseudokód,... Diagram use case přehledně popisuje hranici mezi systémem a vnějším světem. Aktoři zpravidla stojí vně systému, zatímco use cases uvnitř. UML používá ve svých diagramech pro znázornění slovně definovaných use case (vzniklých rozhovorem s uživateli) následující notaci. Aktor se kreslí jako panáček, use case jako elipsa. Aktor, Roman Danel 9

který akci (resp. use case) spustil, se zakresluje vlevo, aktor, který obdrží výstup, se zakresluje vpravo. Use cases a aktoři se propojují plnou čarou. Pro odlišení vnějšího světa a systému se systém ohraničuje obdélníkem. Mezi jednotlivými use case mohou existovat vztahy vkládání (include) a rozšiřování (extend). Vztahy mezi use case se znázorňují přerušovanou šipkou. Pro odlišení toho, zda šipka znázorňuje vkládání nebo rozšiřování, se používá stereotypů (např. «vkládá» a «rozšiřuje»). Vkládání umožňuje použít kroky definované jedním use case i ve druhém use case. Rozšiřování znamená vytvoření nového use case přidáním kroků k již existujícímu use case (dalo by se to označit za rozšíření činnosti základního use case). Místa základního use case, kde došlo k rozšíření, se nazývají body rozšíření. I v oblasti use case diagramů může existovat dědičnost. Označuje se to jako zobecňování. Potomek dědí chování a význam svého předka a doplňuje své vlastní chování. Potomka je pak samozřejmě možné použít všude tam, kde lze použít jeho předka. Zobecnění se zakresluje šipkou směřující od potomka k předkovi. Zobecňování je možné použít jak pro use case, tak pro aktora. Pro přehlednost nebo z důvodu vyznačení podsystémů se mohou jednotlivé use case seskupovat. Pro vyjádření skupiny se využívá balíček Stavový diagram (State Diagram) Zachycuje stavy objektu, kterými prochází (nebo lépe řečeno může projít) v průběhu svého životního cyklu v systému. Ke změně stavu může dojít konkrétní událostí nebo i pouhým plynutím času. Každý objekt má svůj počáteční stav a může mít konečný stav (pokud se nebude jednat o perpetum mobile). Stav se znázorňuje obdélníkem se zaoblenými rohy. Podobně jako o znázornění tříd je možné obdélník rozdělit na tři části, a to na název, stavové proměnné a činnosti stavu. Obvyklými činnostmi jsou vstup (co se stane, když se objekt dostane do tohoto stavu), výstup (co se stane, když objekt tento stav opustí) a proveď (co se provede, je-li systém v tomto stavu). Přechody mezi stavy jsou symbolizovány šipkami. Přechody stavů mohou nést další informace. Spouštěcí událost je událost, která způsobí, že k přechodu dojde. Dále se uvádí seznam akcí, které přechod realizuje. Spouštěcí událost se od příslušné akce odděluje lomítkem. Důležitým pojmem jsou podstavy. Jedná se o změny stavu v rámci jednoho stavu. Podstavy mohou byt dvojího druhu, sekvenční (podstavy na sebe navazují, spouštějí se postupně) a souběžné (podstavy probíhají paralelně). Ukládaný stav je takový stav, který si pamatuje, v jakém podstavu se nacházel přesně před tím, než byl opuštěn. Používaná symbolika v UML je písmeno H (z anglického. history) v kroužku se šipkou mířící k ukládanému podstavu. Ukládaný stav se označuje jako hluboký, pokud si pamatuje všechny vnořené podstavy. Pokud si pamatuje pouze podstav v dané úrovni, označuje se jako mělký. Roman Danel 10

Obr. 4. Příklad stavového diagramu Diagram obsahuje stavový stroj (state machine). Stavový stroj vyjadřuje stavy určitého objektu a přechody mezi těmito stavy. Diagram může obsahovat: stav (state) : situace, kdy modelovaný objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost - např. ve stavu narozený splňuje objekt podmínku, že mu není dosud 18 roků a čeká, až dosáhne plnoletosti přechod (transition) spojení mezi dvěma stavy; objekt přejde z prvního stavu do druhého stavu (za splnění určitých podmínek) rozloučení ukazuje přechod do téhož stavu (něco význačného se stane, ale stav se nezmění) počáteční, finální stav: zvláštní pseudostavy pro počátek a konec automatu Stavový stroj je graf stavů a přechodů (mezi těmito stavy), který popisuje reakce objektu (přesněji: reakce instance klasifikátoru) na obdržení události. Stavový stroj může být připojený ke klasifikátoru (např. use case, class), nebo ke collaboration či k metodě. Element, ke kterému je připojen stavový stroj, se nazývá vlastník (owner) stavového stroje. Celý stavový stroj je vlastně složený stav (composite state), který je rekurzivně dekomponován na substavy. Nejspodnější (listové) stavy již nemají substavy. Stavový stroj může mít reference na jiný stavový stroj použitím stavového substroje (submachine state). Ve stavovém stroji může být v jeden okamžik aktivních více stavů. Roman Danel 11

Co je to přechod? Pro vysvětlování podrobností o stavech musíme vědět, co je to přechod: Přechod (transition) je relace ve stavovém stroji mezi dvěma stavy, kde objekt v prvním stavu přejde do druhého stavu tehdy, když nastane specifikovaná událost (event) a jsou splněny specifikované podmínky (guards), přičemž se provede specifikovaný efekt (effect - action nebo activity). Přechod je nepřerušitelný. Přechod může mít jeden nebo více zdrojových stavů a jeden nebo více cílových stavů. Co je to stav? Stav (state) - situace, kdy modelovaný objekt splňuje nějakou podmínku, provádí nějakou operaci nebo čeká na událost. Stavy jsou obsaženy ve stavovém stroji, který popisuje, jak se vyvíjí objekt v čase dle svých reakcí na události. Stavy mohou být jednoho z druhů: jednoduchý (simple state) kompozitní (composite state) pseudostav - je uzel (vertex), který má formu stavu, ale má speciální chování. Pseudostav definuje detaily přechodu Obr. 5. Prvky stavového diagramu Diagram aktivit (činností) Activity Diagram Diagram aktivit se používá pro popis dynamických aspektů systému. Jde o jakýsi flowchart - znázorňuje tok řízení z aktivity do aktivity. Používá se také k modelování obchodních (business) procesů a workflow. Diagram aktivit zachycuje sekvence činností objektů, nezabývá se tím, který objekt provádí danou akci. Diagram činností představuje sekvenční popis činností tak, jak postupně probíhají v systému. Vzniká rozšířením stavového diagramu. Diagram činností zachycuje především činnosti znázorněné ve stavovém diagramu. Činnosti se znázorňují jako obdélníky se zaoblenými rohy. Po dokončení každé činnosti následuje automatický přechod na další činnost, což se zachytí šipkou. Začátek a konec diagramu činností se, podobně jako ve stavovém diagramu, znázorňuje pomocí kroužků. Mnohdy je nutné rozhodnout, jaká činnost se bude vykonávat na základě určitých podmínek. Dochází tedy k větvení diagramu. Znázornit se to dá dvěma způsoby. Buď vychází možné cesty přímo z Roman Danel 12

některé činnosti, nebo se větvení znázorní pomocí malého kosočtverce, ze kterého pak větvené šipky vychází. Podmínky se uvádějí u větví (šipek) v hranatých závorkách. Někdy je potřeba rozdělit tok událostí do dvou větví, které se budou provádět paralelně a později se zase spojí. Událost, kde dochází k větvení, a událost, kde se větve sbíhají, se označuje silnou příčnou čarou. V průběhu sekvence činností je možné zasílat signály. Přijetí signálu způsobí to, že se začne vykonávat další (jiná) činnost. Zaslání signálu se v diagramu činností znázorňuje pětiúhelníkem ve tvaru šipky, přijetí signálu pětiúhelníkem ve tvaru šipky s hrotem šipky dovnitř. Přijetí a zaslání signálu se propojuje přerušovanou šipkou. Z výše uvedeného je patrné, že se diagram činností podobá klasickému vývojovému diagramu. V digramu činností je možné znázornit, který objekt odpovídá za kterou činnost. K tomu slouží prostředky pro zobrazení rolí. Diagram se rozdělí do oddílů, které se nazývají paralelní dráhy. Každá paralelní dráha je nadepsaná jménem role a obsahuje činnosti vykonávané danou rolí. V diagramech činností je možné podle notace použít i symboly z jiných typů diagramů, jako jsou např. objekty (činnost směřuje k objektu, který ji vykoná). Tyto jiné prvky se znázorňují stejně jako v mateřských diagramech. Takovéto diagramy činností se pak označují jako hybridní. Diagram činností je možné použít k popsání procesů. Některé nástroje ho však nevyužívají (jako např. Select Enterprise v6) a nabízí jiný modelový nástroj na popis procesů. Diagramy stavů a diagramy aktivit jsou si podobné (oba ukazují sekvenci stavů, které nastávají v čase, a ukazují podmínky způsobující přechody mezi stavy). Rozdíl mezi těmito diagramy je však v tom, že diagram stavů se soustřeďuje na stavy objektu (tj. objektu provádějícího výpočet či objektu, se kterým je výpočet prováděn), kdežto d. aktivit se zaměřuje na stav samotného výpočtu (stav procesu, algoritmu,...), kde může být účastno i více objektů, a kde jsou znázorněny řídící a informační toky mezi prvky diagramu. Obr. 6. Prvky diagramu aktivit Roman Danel 13

Diagram spolupráce - Collaboration Diagram Diagram spolupráce a sekvenční diagram (sequence diagram) patří do skupiny interakčních diagramů (interaction diagrams). Tyto dva diagramy jsou téměř izomorfní - tj. dají se převádět z jednoho tvaru na druhý (často i automatizovaně). Použití diagramu spolupráce bývá vhodnější v těch případech, kde chceme zdůraznit strukturální aspekty spolupráce, tj. kdo s kým komunikuje - jsou méně vhodné pro zdůraznění časových souvislostí interakcí. Diagram spolupráce zachycuje interakci mezi objekty v systému. Je podobný sekvenčnímu diagramu, ale interakci mezi objekty zachycuje odlišným způsobem. Oba typy diagramů obsahují stejné informace a je možné převést sekvenční diagram na diagram spolupráce a naopak. Odlišnost tkví v tom, že sekvenční diagram klade důraz na pořadí jednotlivých událostí, diagram spolupráce spíše zdůrazňuje uspořádání spolupracujících objektů. Diagram spolupráce je rozšíření diagramu objektů. Kromě vztahů mezi jednotlivými objekty zachycuje také zprávy, které si objekty zasílají. Zpráva se znázorňuje jako šipka vedle asociační čáry. Zpráva může obsahovat parametry, ty se zapisují do závorek. U zpráv je možné vyjádřit, v jakém pořadí se zasílají. Zachytí se to číslem před názvem zprávy odděleném dvojtečkou. Pokud jsou v diagramu dvě stejné zprávy (např. po použití podmínek), odliší se od sebe dalším číslem za tečkou (např. 1.1 a 1.2). V diagramu spolupráce je možné znázornit změny stavu objektu. Stav se u objektu zapisuje do hranatých závorek. Pokud se objekt dostane do jiného stavu, zakreslí se do diagramu jako novy objekt s novým stavem. Oba stavy objektu se spojí přerušovanou šipkou, která se označí např. stereotypem «stane se». Je opět možné využít podmínky a cykly, obdobně jako v diagramu sekvencí. Zapisují se před název zprávy do hranatých závorek. Pro diagram spolupráce platí obdobné o použití účastníka, co bylo o této problematice uvedeno u sekvenčního diagramu (viz výše). Nově vytvořený objekt se zakreslí jako existující objekt, zpráva k tomuto novému objektu se označí stereotypem «vytvořit». Zpráva od jednoho objektu může být směřována více objektům téže třídy najednou. V diagramech spolupráce se tento fakt zachytí tak, že u cílového objektu se zakreslí více obdélníků za sebou (pro znázornění, že existuje více složek, více objektů). U zprávy se pak přidá cyklus s názvem např. všichni. Zpráva může být také požadavkem, aby cílový objekt něco provedl a vrátil výsledek. V diagramu se to znázorní tak, že se u zprávy zapíše <název proměnné> := <název operace s operandy>. Pravá strana výrazu se nazývá signatura zprávy. Aktivní objekt je objekt, který řídí interakce s více objekty. Může zasílat zprávy pasivním objektům nebo komunikovat s dalšími objekty. Aktivní objekt se znázorňuje tlustším obdélníkem. Někdy je potřeba zachytit v diagramu spolupráce synchronizaci zaslání zprávy. Jedná se tedy o případ, kdy objekt zašle příslušnou zprávu pouze tehdy, jestliže došlo k odeslání jiných vybraných Roman Danel 14

zpráv (tj. objekt synchronizuje odeslání své zprávy s odesláním jiných zpráv). V diagramu se to znázorní tak, že místo označení pořadí zprávy se před zprávu zapíší čísla zpráv, které musí předcházet, a oddělí se od zprávy lomítkem. Doporučuje se v analýzách používat jak diagram sekvencí, tak diagram spolupráce. Podle něj diagram spolupráce znázorní vztahy mezi objekty, zatímco diagram sekvencí pořadí jednotlivých interakcí v čase (viz výše). Budoucímu uživateli modelů to pak pomůže se lépe zorientovat v dané problematice. Roman Danel 15

Šablony (Design Patterns) Jazyk UML nabízí mechanismus pro vytváření tříd, který je analogický vytváření objektů. Umožňuje vytvořit tzv. parametrizovanou třídu. Ta vzniká přiřazením hodnot části atributů dané třídy. Parametrizovaná třída se v pravém horním rohu označí rámečkem s přerušovaným okrajem. Ten obsahuje parametry, kterým se přiřazuje hodnota. V deklaraci se znázorní jako parametry bez hodnoty, v této chvíli je třída šablonou pro jinou třídu. Jestliže se jim pak určitá hodnota přiřadí, stane se třída onou jinou třídou. Rámeček také obsahuje písmeno T. Jedná se o klasifikátor udávající, že třída je šablonou pro vytváření jiných tříd. Parametrizaci lze rozšířit na kterýkoliv klasifikátor UML. Každá šablona popisuje množinu vzájemně souvisejících objektů a tříd. Hlavním důvodem pro jejich používání je jejich znovupoužitelnost. Strukturu jazyka UML je možné rozdělit do více vrstev. Nejnižší vrstvou je vrstva uživatelských objektů. Obsahuje konkrétní instance (výskyty) jednotlivých konkrétních prvků (např. dané objekty), které jsou zachyceny v další vrstvě. Druhou vrstvou je modelová vrstva, která obsahuje konkrétní prvky modelované oblasti (např. konkrétní třídy). Třetí vrstva definuje jazyk pro specifikaci modelu (např. co jsou třídy a asociace). Nazývá se metamodelová vrstva. Poslední, čtvrtá vrstva (metametamodelová) definuje, co patří do metamodelu. Tato vrstva tedy určuje, co (jaké obecné prvky) do daného modelu patří (např. se jedná o třídu). Vrstvu metamodelu můžeme popsat pomocí tří balíčků, a to základ, prvky chování a správa modelu. Balíček základ se skládá z jádra, datových typů, mechanismů rozšíření a doplňkových prvků. Jádro definuje prvky potřebné pro sestavení modelu v UML. Každá z definovaných položek je buď abstraktní (nelze vytvořit její instanci), nebo konkrétní (lze vytvořit její instanci). Z hlediska mechanismů rozšíření jsou důležité stereotypy (jejich zápis viz Další prvky UML). Stereotypy vytvářejí instance nové metatřídy. Existující prvek UML lze tedy požít jako základ pro nově vytvářený prvek, což vede ke značné flexibilitě. Stereotypů existuje velká řada, jejich seznam je uveden níže. Balíček prvky chování se zabývá modelováním chování systému. Skládá se z balíčků spolupráce, use case (udává koncepty diagramu use case) a stavových automatů (udává koncepty stavového diagramu a diagramu činností). Balíček spolupráce popisuje klasifikátory a jejich asociace spolupracující při plnění určitého úkolu. Roman Danel 16

Další prvky UML Balíčky Balíčky umožňují uspořádat prvky diagramu do skupiny (např. pro účely znázornění podsystému). Jméno prvku se pak píše za jméno balíčku odděleného dvěma dvojtečkami. Poznámky Poznámka k prvku diagramu. Stereotypy Stereotypy umožňují použití existujících prvků UML a vytvoření z nich nových. Pro jeho označení se používají francouzské lomené uvozovky. Příkladem může být třída «rozhraní», která má pouze operace, nemá vlastnosti. Pro další studium diagramů UML lze využít např. http://uml.czweb.org/index.html Nedostatky UML Neschopnost UML poskytovat prostředky pro návrh user interface a datových modelů. Například Activity diagram v UML neumožňuje zachytit místo pro uložení informací, podobně jako to umí diagram DFD (data flow diagram). Nedostatečností UML v oblasti datového modelování je to, že UML neposkytuje vhodné prostředky pro datové modelování, a proto se navrhuje rozšíření notace UML pomocí vhodných stereotypů, což jsou prostředky jazyka UML pro jeho vlastní rozšiřování. Soubor určitých stereotypů, které rozšiřují UML pro určitou oblast užití, se nazývá UML extensions. Roman Danel 17

Ostatní objektově orientované metodiky Booch Jedná se o jednu z vůbec nejstarších metodik OOAD, jejímž autorem je Grady Booch. Tato metodika je asi nejsilnější ve fázích designu, implementace a nasazení IS. Metodika Booch je výrazně ovlivněna programovacími jazyky Ada a zejména C++, s kterým se nejčastěji používá. Pro modelování statické stránky systému používá Booch diagramy tříd a diagramy objektů, pro modelování dynamiky zase diagramy interakce, stavové diagramy a nakonec diagramy modulů, diagramy procesů a kategorie tříd. Některé z nástrojů vhodných pro implementační fáze si později našly cestu v obměněné podobě i do množiny UML. Ve skutečnosti však nejsou stěžejními prostředky a jejich používání není zdaleka tak intenzivní, jako používání ostatních. Metodika Booch postrádá některé fundamentální prostředky pro analýzu, což ji činí poměrně nevhodnou pro aktivity typu BPR a vůbec pro použití mimo rámec tvorby SW systémů. Spolu s OMT byla ve své době pravděpodobně nejvíce používanou objektovou metodikou, nicméně nutno podotknout, že podle nejrůznějších odhadů dohromady nesdílely více než 40 procent trhu. Object Modelling Technique Hlavním návrhářem Object Modeling Technique je James Rumbaugh. OMT je vlastně reprezentantem oněch smíšených metodik, které za svůj základ vzaly ER diagram a rozšířily ho o nezbytné objektové rysy. V prvních verzích obsahovala OMT navíc ještě DFD diagramy, které však byly později vypuštěny. Ve druhé verzi přebrala OMT Use Case modelování z metodiky Objectory/OOSE, které je používáno především v analýze pro vymezení hranic systému a interakci systému s vnějším okolím. Na rozdíl od metodiky Booch se jako víceméně vhodné jeví i použití OMT ve fázi analýzy. Zkrácený životní cyklus je rozdělen do etap analýzy, systémového návrhu, objektového návrhu a implementace. OMT používá tři základní modely. Objektový (využití diagramů tříd vycházejícího z ERD), dynamický (zejména stavové diagramy vytvářené pro jednotlivé třídy) a funkcionální (právě tolik diskutované DFD). Vzhledem ke svému původu jsou nástroje OMT používány i pro datové modelování. Možná, že právě kvůli svým kořenům ležícím v klasické strukturované analýze se OMT stala patrně nejrozšířenější objektovou metodikou vůbec a výraznou měrou ovlivnila své následníky. OMT zaujímá asi největší podíl mezi vývojáři CASE nástrojů, kde zejména ve spojení s notací UML suveréně dominuje. Kromě jiného se OMT stala základem pro jednu z českých variant, tzv. OOMT, která má svůj původ na VŠE, kde byla vyvíjena pod vedením P. Drbala. Objectory/Object-Oriented Software Engineering Z původně firemní metodiky Objectory (název vznikl spojením slov object a factory ) vytvořené Ivarem Jacobsonem se nakonec stal uznávaný prostředek pro business modelování. Zjednodušením Objectory vznikla metoda OOSE, která je určena především pro tvorbu počítačově orientovaných systémů. Jádro Objectory/OOSE tvoří Use Case modelování, které slouží jako sjednocující prostředek mezi všemi fázemi vývoje IS včetně testování. Celá metodika byla detailně popsána v knize Object- Roman Danel 18

oriented Software Engineering: Use Case Driven Approach, která se posléze stala jednou z biblí objektového programování. Ve spojení s Objectory se též poprvé začalo hovořit o objektových technologiích jako vhodném prostředku pro Business Process Reengineering. Zásadní prací na toto téma se stala další Jacobsonova kniha The Object Advantage: Business Process Reengineering with Object Technology. Samotná metodika, ač vcelku známá a úspěšná se moc neprosadila. Byla a stále je spíše inspirací pro ostatní metodiky, které z ní převzaly zejména techniky Use Case modelování. Možné příčiny, proč nebyla tato metodika více používána lze spatřovat jednak v nedostatku CASE nástrojů, zejména však ve faktu, že trvalo dlouhá léta, než se tato metodika plně otevřela světu. Zpočátku se za její nasazení platily značné částky, které mohly odradit vysoké procento případných zájemců. Namísto OOSE tak světu dominovala dvojice Booch+OMT, která má na rozdíl od OOSE svůj původ v zámoří. Object-oriented Process, Environment and Notation Metodikou, tentokrát již opravdu plnohodnotnou, usilující o vítězství v Call for Proposal byla též OPEN. Své kořeny má tato metodika v projektu COMMA (Common Object Methodology Metamodel Architecture), jehož cílem bylo vytvořit metamodely většiny metodik a metod OOAD, na jejichž základech měl být poté vystavěn univerzální metodický prostředek. Klíčovými postavami, které se zasloužili o vytvoření a rozšíření OPEN jsou Brian Henderson-Sellers, Meilir Page Jones, Ian Graham a Donald Firesmith jakožto i osoby organizované v konsorciu OPEN. Některá z těchto jmen jsou dobře známa i mezi uživateli klasických strukturovaných metodik. OPEN tvoří doporučená notace OML (OPEN Modeling Language), pro kterou existuje i zjednodušená verze OML light, jež je svým způsobem protipólem výše zmíněné notaci UML, dále odpovídající proces a definovaný životní cyklus tvorby IS, použité metriky atd. Pokud jde o diagramy zaváděnými OML, existuje jich celá řada. Samozřejmě jsou většinou striktně odděleny na ty, které slouží pro modelování statické a naopak na ty, používané při modelování dynamické stránky systému. Do první kategorie spadají například kontextové diagramy pro zobrazení hranic a spolupracujících částí systému, diagramy hladin pro rozklad systému ve vertikálním směru a rozdělení aplikace na dílčí celky, diagramy konfigurací pro znázornění SW a HW celků a jejich spolupráce, dále například diagramy hierarchií dědičnosti, diagramy nasazení apod. Dynamická stránka systému je zpracovávána prostřednictvím diagramů případů užití, diagramů spolupráce, sekvenčních diagramů, stavových diagramů apod. Komplexnost OML je porovnatelná s rozsahem notace UML. OPEN proces obsahuje popis doporučeného životního cyklu tvorby IS, v rámci něhož jsou nástroje OML používány. Jak proces, tak i notace jsou vytvořeny pokud možno tak, aby mohly být libovolně záměnné. Je tedy možné používat OPEN proces s notací UML a naopak například notaci OML spolu s procesem definovaným metodikou Catalysis. I přes některé zjevné výhody oproti UML se OML a celá metodika OPEN moc neprosadila. Jak už to tak bývá, není to zapříčiněno technickými nedostatky, ale především obchodní politikou. Za OPEN stojí poměrně úzké konsorcium jednotlivých odborníků (i když pravda, že co jméno to pojem) Roman Danel 19

kterému se bohužel nepodařilo prosadit svůj výtvor především mezi producenty CASE nástrojů. Zejména to je ten hlavní důvod, proč se OPEN výrazněji neprosadila. Coad-Yourdon Jméno Ed Yourdon je těm, kteří se orientují již delší dobu v problematice tvorby IS asi dostatečně známé. Klasická Yourdonova strukturovaná analýza patří dnes již mezi legendární a osvědčené prostředky. Především Peter Coad nese zásluhu na vytvoření objektové metodiky Coad/Yourdon, kterou řadíme spíše do druhé generace (i když toto zařazení může být sporné) metodik OOAD. Metodika se vyznačuje především svojí jednoduchostí, kvůli které byla často používána pro výuku objektového modelování. Coad/Yourdon rozděluje systém do několikavrstvého modelu, jehož první vrstvou je vrstva subjektů následovaná vrstvou tříd/objektů, vrstvou struktury, atributů a služeb. Kromě tohoto členění je možné provádět i rozklad podle zaměření jednotlivých participujících objektů. Oddělující se tedy například objekty tvořící vrstvu zajišťující interakci s uživatelem (Human Interaction Layer), dále klíčová vrstva problémové oblasti (Problem Domain Layer), která de facto reprezentuje modelovaný problém, vrstva datových objektů apod. Tyto vrstvy si můžeme představit jako jednotlivé průsvitky, které na sebe můžeme poskládat, čímž dostaneme výslednou podobu objektového systému. Toto logické členění je do jisté míry obdobou hitu dnešních dnů logického (nikoli fyzického) modelu trojvrstvé architektury. Coad/Yourdon není, jakožto extrémně jednoduchá metodika příliš použitelná pro komplexní systémy, které kladou velký důraz na dynamické chování. Na druhou stranu byla nasazována pro tvorbu aplikací klient/server, kde se mohl dokonale uplatnit vrstvový model. Shlaer/Mellor Na rozdíl od ostatních metodik stojí přístup Shlaer/Mellor ke tvorbě IS na trochu odlišných principech. Zatímco OMT, Booch apod. využívají tzv. evoluční přístup, kdy se většinou střídají fáze analýzy / designu / implementace / validace s postupným zjemňováním a rozpracováváním, v metodě S/M (autory jsou Sally Shlaer a Stephen Mellor) použito odlišné schéma. Odděleně je navrhnuta obecná, na konkrétní problematice nezávislá, architektura systému sestávající se de facto ze dvou částí. Na jedné straně máme klasické koncepty jako prostředky perzistence, datové struktury apod., na druhé straně máme přesně vymezená pravidla, jak rozčlenit aplikaci mezi tyto obecné koncepty. Takovýto model softwarové architektury je nakonec provázán s výsledky analýzy problémové oblasti, která probíhá obdobně jako při nasazení ostatních metodik. Oddělení SW architektury od problémové oblasti může usnadnit dosažení maximální možné míry znovupoužitelnosti a tím i zvýšení efektivity práce, což je zároveň asi největším přínosem při nasazení této metodiky. Výše popsané principy tvoří dohromady filosofii tzv. rekurzivního translačního vývoje, který je do jisté míry protipólem onomu zmíněnému evolučnímu přístupu. Nejčastěji a nejúspěšněji je metodika Shlaer/Mellor používána pro vývoj systémů pracujících v reálném čase. Roman Danel 20

Class, Responsibility, Collaborators Class-Responsibility-Collaborators zaujímá mezi ostatními metodikami výhradní postavení. Někdo by možná mohl zpochybnit její zařazení do kategorie metodik, neboť je často používána pouze jako nástroj pro dílčí problémy spojené s tvorbou objektových systémů. Hlavní přínos tkví především v jejím použití pro nalezení objektů participujících v modelovaném systému. Vůbec problém nalézt vhodné objekty je jednou z fundamentálních otázek, které musí být uspokojivě řešeny. Bohužel zatím neexistuje univerzální, efektivní a formálně popsatelný postup, jak toho dosáhnout. K dosažení tohoto cíle se často používá Use Case modelování spojené s tvorbou dynamických modelů, při jejichž tvorbě se objekty postupně vynořují. Nicméně některé metodiky, které Use Case modelování vůbec neberou v potaz (např. Booch) se často omezují pouze na vágní slovní doporučení, jak si při hledání objektů počínat. Jednou z možných metod nalezení objektů může být například lexikální analýza, jejíž úspěšnost se ovšem pohybuje okolo 20%. Právě tehdy může být úspěšně použita CRC (nebo metody a metodiky z ní vycházející, jako je OBA). Její použití spočívá v tvorbě a používání indexových karet (fyzické papírové karty libovolného formátu), které mají doporučený vzhled. Každá karta představuje samostatný objekt (resp. třídu), ke kterému je posléze přiřazena zodpovědnost (responsibility) a dále ke každé zodpovědnosti objektu jsou přiřazeny objekty, který na zajištění konkrétní zodpovědnosti spolupracují (collaborators). Objekty se tedy postupně vynořují právě jako jedinci z řad spolupracujících objektů. Celá dynamika objektového systému pro zajištění konkrétního scénáře může být následně simulována například v rámci pracovního workshopu řešitelského týmu. Z popisu je vidět, že se jedná o extrémně jednoduchý, ale vcelku efektivní (a v neposlední řadě i efektní) nástroj. Při podrobnějším pohledu je zřejmé, že se jedná o postup téměř identický s Use Case modelováním. S rostoucí složitostí se samozřejmě stává obhospodařovávání velkého množství karet oříškem, který může být vyřešen používáním podpůrného CASE nástroje. Na druhou stranu se tím ztrácí možnost sáhnout si přímo na objekt. CRC se nejvíce hodí pro výuku objektového přístupu, pro kterýžto účel byla také původně svými autory vytvořena (Ward Cunningham, Rebecca Wirfs-Brock). CRC se stala mj. inspirací pro metodiku RDD (Responsibility-Driven Design) a metodu OBA. Business Object Notation Jedná se o poměrně mladou a jednoduchou metodiku uvedenou poprvé K. Waldenem a J. M. Nersonem v roce 1994. Právě její nenáročnost je často oceňována jako velká výhoda proti nadměrně komplexním metodikám ostatním. Business Object Notation (dříve Better Object Notation) je výrazně ovlivněna objektovým jazykem Eiffel, který je díky své jednoduchosti, konzistentnímu návrhu a silným výrazovým prostředkům používán především pro tvorbu systémů, jejichž klíčovou vlastností je bezpečnost a spolehlivost. BON zohledňuje některé pokročilé objektové technologie, jakým je například princip kontraktu apod. Na druhou stranu kvůli své jednoduchosti neobsahuje některé prostředky, které jsou již považovány za téměř nezbytnou součást jakékoliv objektové metodiky. BON obsahuje poměrně slabé nástroje pro modelování dynamiky systému, paralelismu apod. BON je vedle Coad/Yourdon velmi vhodná pro výuku objektového modelování. Roman Danel 21

Business Object Relation Modeling BORM je metodika částečně českého původu, která byla svými autory (J.Polák, V.Merunka, R. Knott) od roku 1993 vyvýjena pod záštitou grantového programu VAPPIENS (Various Programming Paradigms in Integrated Environments), později s podporou Deloitte&Touche. Na rozdíl od jiných metodik BORM neodděluje striktně statický a dynamický pohled, naopak podporuje jejich koexistenci v rámci jednoho modelu. Důležité je však vůbec celé směřování této metodiky, která je orientována spíše více směrem k BPR a business modelování obecně než směrem k tvorbě SW, i když i v této oblasti byla používána, především pak ve spojení se systémy postavenými nad Smalltalkem. BORM vychází částečně z metodiky Coad/Yourdon, z které přejímá vrstvový model a metody OBA používané při počátečních analytických fázích. V nedávné době také začaly být některé z nástrojů této metodiky implementovány do metacase systému MetaEdit+, čímž se této metodice otevírá cesta do světa. Business Object Relation Modeling je mj. používána při výuce objektových technologií na některých českých univerzitách, jmenovitě na fakultách PEF ČZU a FEL ČVUT. Roman Danel 22