Kanisová Hana, Müller Miroslav: UML srozumitelně

UML

• UML 2.0 zavádí nové typy diagramů: diagram přehledu spolupráce, diagram načasování, diagramy smíšené struktury atd.
• CASE nástroj vybírat podle podporované metodiky, vývojové techniky, podpory jednotlivých etap SW vývoje, podpory generování databázových skriptů, možnosti konvertovat modely do vývojového prostředí OOP, podpory týmové práce analytiků a designérů (verzování, zamykání atd.).

Požadavky

• Požadavky nejsou součástí jazyka UML, jsou podporovány pouze vazbou na případy užití.
• Správa požadavků = souhrn aktivit vykonávaných při sběru, definici a řízení požadavků na SW systém. Neúspěch správy požadavků a nedostatečné zapojení uživatelů bývají nejčastější příčinou neúspěchu celého projektu.
• Zdroje požadavků: legislativa, požadavky zákazníků, existující systémy uživatelů, pracovní procesy uživatelů, vlastní know-how pro danou problémovou oblast, prostředí zákazníka, HW/SW vybavení zákazníka.
• Požadavek = popis (specifikace) jisté funkce nebo vlastnosti, která by měla být ve vyvíjeném systému implementována, neboli vyjádření přání uživatele. Měl by říkat, CO systém nabídne, nikoliv JAK to zařídí.
• Postup prací s požadavky: 1) identifikace funkčních požadavků, 2) identifikace nefunkčních požadavků, 3) identifikace případů užití + navázání na funkční požadavky, 4) promítnutí nefunkčních požadavků do technické architektury systému.

Procesní modelování

• Nejznámější metodiky využívají procesní modelování jako úvodní krok zahájení analytických prací. Modelování firemních procesů je počáteční fází mnoha SW projektů (hlavně v úvodu je vhodné popsat firemní procesy).
• Firemní proces = sekvence činností vytvářející produkt, který organizace potřebuje pro splnění svých firemních cílů.
• Diagram hierarchie procesů (Process Hierarchy Diagram) řeší procesní rozpad systému, pomáhá zjistit rozsah vyvíjeného systému, jeho modularitu a vzájemné souvislosti jednotlivých firemních procesů na jejich nejvyšší úrovni.
• Diagram procesních vláken (Process Thread Diagram, PTD) mapuje skutečný průběh procesů, slouží pro celkový pohled na podnikový IS.
• Modelování procesů dle nového standardu OMG BPMN (Business Process Modeling Notation) by do budoucna mohlo být obecně uznávaným standardem stejně jako UML. Jazykem BPMN můžeme kromě popisu celého procesního běhu a delegování zodpovědností též vyjádřit vzájemné předávání zpráv mezi procesy a tak umožnit jejich synchronizaci. Notace BPMN je srozumitelná všem zúčastněným stranám – od procesních analytiků přes programátory až po pracovníky, kteří procesy ve firmě realizují.

Případy užití

• Případy užití (typové úlohy) zachycují přesně funkčnost, která bude budoucím IS pokryta, a vymezují tak jednoznačně rozsah prací. Každý případ užití popisuje jeden ze způsobů použití systému, popisuje tedy jednu jeho požadovanou funkčnost. Diagram případů užití by tak měl zachycovat kompletní funkcionalitu, která se bude programovat.
• Aktér = role, ve které vystupuje uživatel v rámci své komunikace se systémem, spouští případ užití. Může se jednat o lidi (fyzické uživatele), ale i o externí systémy (potřebují-li informace z našeho systému) nebo o čas (např. když se v danou dobu v systému automaticky spouští pravidelné zpracování).
• Generalizace (zobecnění) aktérů se nabízí v situacích, kdy dva aktéři spouštějí stejné případy užití a liší se pouze tím, že jeden z nich navíc spouští další případy užití. Tady lze zobecnit aktéry na dalšího aktéra (většinou tzv. abstraktní aktér).
• Identifikace případů užití: 1) Rozdělit komplexní systém podle pohledu jednotlivých aktérů a pro každého z nich rozpracovat případy užití, které vykonává. 2) Diskuse s uživateli. 3) Přes elementární business procesy (EBPs), identifikované v průběhu modelování firemních procesů. 4) Jít podle externích událostí (identifikovat reakce systému).
• Nalezení a popis případů užití je primárním úkolem analytické fáze.
• Scénář případu užití je ideálním výchozím bodem pro tvorbu testovacích scénářů, proto je vhodné dívat se na něj z pohledu testera už při jeho psaní.
• Vazba případů užití na požadavky = vzájemné namapování (přiřazení) požadavků a případů užití, dobré je zejména z kontrolních důvodů, abychom odhalili případné nesrovnalosti, tzn. místa v požadavcích, která nejsou ošetřena případy užití, a obráceně.

Modelování tříd objektů

• V systémech napsaných pomocí OOP se mnohem více uplatňuje znovupoužitelnost (re-use), která nemá ve strukturálním přístupu (snad s výjimkou funkcí) obdobu: zavádí se třída, dědičnost, komponenty, distribuované objekty aj., které oproti strukturálnímu přístupu zvyšují možnost opakovaného použití. Případné změny se mnohem lépe řeší v objektových systémech, protože každý objekt nese svou odpovědnost za určitou problematiku, a proto není třeba změny provádět na mnoha místech aplikace.
• OOP je definováno třemi základními rysy: dědičností, zapouzdřením a polymorfismem.
• Třída = šablona pro skupinu objektů (instance), popisuje vnitřní strukturu objektu a definuje jeho operace. Modelování tříd je klíčová aktivita OOP – kvalita výsledného systému je pak odrazem kvality modelu tříd. Diagramy tříd zachycují statickou stránku systému, především vztahy mezi třídami.
• Reflexivní asociace = objekt dané třídy si uchovává v sobě odkazy na objekty téže třídy – třída je asociována sama na sebe (např. zaměstnanec X řídí zaměstnance Y).
• Abstraktní třídy = třídy bez instancí, zaváděné pro lepší údržbu kódu.
• Polymorfní třídy = třídy s virtuální (polymorfní) operací – některé objekty mají k dispozici totožná rozhraní realizovaná prostřednictvím operací, ale metody, které se skrývají za těmito operacemi, jsou rozdílné (např. podtřídy FyzOs i PrávOs dědí z abstraktní třídy Osoba operaci VypočítejDaň, ale implementace pomocí metod bude v každém objektu jiná).
• Asociační třídy = třídy umožňující přiřazení atributů, operací a dalších rysů k asociaci, která řeší vztah mezi třídami typu M:N. Asociační třída se v systému chová stejně jako jiné třídy, vlastně řeší situaci, kdy během analýzy identifikujeme atributy či operace, které nelze přiřadit ani jedné třídě.

Model objektové spolupráce

• Modely objektové spolupráce, resp. modely interakce objektů slouží k hledání realizace jednotlivých případů tříd (prostřednictvím tříd).
• Realizace případu užití = třídy, které uskutečňují chování případu užití pomocí vzájemné spolupráce. Jedná se o převod slovního popisu scénáře případu užití na model interakce předem určených tříd.
• Dva základní interakční diagramy: sekvenční diagram a diagram objektové komunikace (též diagram objektové spolupráce).
• Sekvenční diagramy znázorňují spolupráci objektů v čase, zatímco diagramy objektové komunikace kladou důraz na spolupráci objektů, vypovídají o struktuře balíčků, ale nejsou tak přehledné z hlediska časové posloupnosti.
• Úroveň diagramů interakce: 1. stupeň – kreslení tzv. analytické úrovně (pouze objekty business); 2. stupeň – diagramy obsahující i návrh (design) v podobě uživatelských objektů, formulářů (je vidět komunikace uživatele s rozhraním systému a mezi formuláři a objekty business); 3. stupeň – diagramy zahrnují i servisní objekty aplikačního frameworku apod. (= rostoucí složitost, klesající přehlednost).
• Síla diagramů interakce spočívá ve znázornění spolupráce mezi objekty, nejsou však příliš vhodné k popisu detailního chování konkrétních objektů. Na větších projektech zpravidla není možné je kreslit pro všechny případy užití, proto je lepší nakreslit si je alespoň pro klíčové případy užití.

Seskupení tříd

• Problém dekompozice rozsáhlých systémů OOP řeší tvorbou seskupení tříd (packages). Seskupení tříd se používá pro třídy, jejichž objekty spolu logicky souvisí, komunikují mezi sebou a jsou tak schopny poskytnout ucelený balík služeb (rozhraní). Např. výskyt vazeb typu kompozice, generalizace je vodítkem k uspořádání analytických tříd do seskupení.
• Seskupení tříd a návrh jejich rozhraní je nezbytné při komponentovém vývoji IS, typicky pro modelování webových služeb.

Stavové diagramy

• Stavové diagramy zachycují chování systému pomocí možných stavů, které může nabývat konkrétní objekt. Jedná se tedy o model chování objektu napříč všemi případy užití. Zároveň znázorňují, jak se stavy objektu mění v závislosti na událostech.
• Stav = konkrétní situace, která nastala v životě objektu, kdy objekt vyhovuje nějaké podmínce, realizuje konkrétní operaci nebo třeba jen čeká na nějakou událost.
• Přechod = změna stavu objektu vyvolaná událostí. Přechod lze považovat za akci, která proběhne rychle a nepřerušovaně (zatímco stav za aktivitu, která představuje přerušovaný a po jistou dobu trvající proces).
• Událost = stimul, výjimečná akce, proběhne v jistém čase a nemá trvání, příčina přechodu.
• Složené sekvenční stavy, tedy diagram stavů rozlišující nadstavy a jejich substavy, nabízí možnost vyjádřit vyšší úroveň stavu pro více stavů nižší úrovně současně.
• Souběžné stavové diagramy jsou pokročilou technikou modelování nezávislých sad chování objektů (další možností je modelování na více diagramech).
• Využití stavových diagramů je hlavně v případě objektů se složitým životním cyklem – pro třídy se složitým chováním (jako kontrola ostatních modelů).

Diagramy aktivit

• Diagram aktivit zobrazuje tok aktivit, které podporují jak sekvenční, tak paralelní chování, může být asociován k libovolnému elementu a popsat tak jeho chování.
• Akce jsou dále nedělitelné, nepřerušitelné, okamžité, s jedním vstupním a jedním výstupním přechodem.
• Hodnocení přechodu (nebo také rozhodnutí, decision, kosočtverec) = logická podmínka, která podmiňuje konkrétní přechod. Do hodnocení vstupuje pouze jeden vstupní přechod (s definovanou podmínkou), počet výstupních přechodů není omezen (jejich podmínky musí být definovány tak, aby současně byla splněna pouze jedna z nich). Rozvětvení přechodu na několik současně běžících vláken, která se následně opět spojí, umožňuje modelovat paralelní chování.
• Plavecké dráhy umožňují specifikovat zodpovědnost objektů za konkrétní aktivity. Diagram je třeba upravit do vertikálních pruhů, vzájemně oddělených čarami. Každá z drah pak reprezentuje zodpovědnost konkrétní třídy, oddělení či osoby. U složitějších diagramů však může být problém s rozvržením.
• Největší silou diagramů aktivit je, že podporují paralelní chování, jsou proto dobré k lepšímu porozumění business procesům nebo případů užití. Jejich velkou nevýhodou je, že dostatečně jasně neznázorní vazby mezi akcemi a objekty (ani plavecké dráhy nejsou tak bezprostřední jako kupř. diagramy interakce).

Datové modelování

• I přes náznaky objektových databází drtivá většina systémů stále používá (a používat bude) relační databázové stroje, proto se bez techniky datového modelování neobejdeme.
• Logický datový model (diagram entit) je nezávislý na implementaci, zatímco fyzický datový model již zohledňuje zvolenou relační databázi.
• Typy vazeb: 1:1, 1:N, M:N. (M:N lze použít pouze v počátcích analýzy, později musí být převedena na 1:N).
• Primární klíč (PK) = jednoznačný identifikátor výskytu entity (zpravidla ID).
• Alternativní klíč (AK) = jeden nebo více atributů, rovněž jednoznačných, ale nebyly vybrány jako PK (možná alternativa PK).
• Cizí klíč (FK) = atribut v dané entitě, který je zároveň PK jiné entity.
• Důležité kroky analýzy: 1) identifikace entit, 2) identifikace klíčů, 3) určování vazeb, 4) vytvoření datového modelu.
• Normalizace datového modelu (neboli relační datová analýza) = oddělení logického a fyzického návrhu dat pomocí přesných matematických operací s cílem odstranit dvojznačnosti a redundance dat a zpřehlednit databázi. Ne vždy je ale normalizace nejlepší cestou, jak dosáhnout lepší rozšiřitelnosti a výkonnosti databáze (např. datové sklady), vždy záleží na způsobu práce s daty.
• Relace = dvourozměrné datové pole složené ze sloupců (kategorií dat – domén) a řádků (hodnot, jakých kategorie dat nabývají). Tabulka je relací tehdy, nemá-li žádné dva řádky stejné, na pořadí řádků a sloupců nezáleží, sloupce jsou jednoznačně pojmenované a relace má alespoň jeden sloupec definovaný jako PK.
• Mapování diagramu tříd: 1) mapování tříd na tabulky (atributy jako sloupce, instance jako řádky); 2) mapování asociací (1:1 většinou jako jedna tabulka, 1:N jako definice FK v detail tabulce odkazující na příslušný řádek master tabulky, M:N jako rozklad na vazbu 1:N pomocí vazební tabulky s vlastním PK a s minimálně dvěma FK z master tabulek); 3) mapování dědičnosti (jako 1:1, zahrnutím do nadtřídy nebo rozpuštěním do podtříd).

Metodika Select Perspective

• Metodika Select Perspective = výchozí metodika pokrývající celý cyklus projektu (kromě UML i vizuální modelovací techniky BPM a datové modelování).
• Klíčové principy: 1) iterativní vývoj založený na případech užití, 2) paralelní vývoj, 3) orientace na komponentový vývoj, 4) aktivní podpora rozdílných typů projektů.

Komponentový vývoj

• Vývoj založený na komponentách (Component Based Development, CBD) má být dle vizí předních IT odborníků příští hlavní vlnou ve vývoji SW.
• Komponenta = spustitelná část kódu, která poskytuje souhrn daných služeb formou černé skříňky (black-box), její služby jsou dostupné pouze prostřednictvím konzistentního, publikovaného rozhraní, komponenta musí být schopná spojení s jinými komponentami (k formování větších celků).
• Struktura komponent: 1) specifikace (popis funkcionality), 2) implementace (zdrojový kód zajišťující provádění vyspecifikovaných vlastností), 3) spustitelný kód (binární soubory, knihovny) a samozřejmě 4) komunikační rozhraní.

Koncept MDA

• Cílem MDA (Model Driven Architecture) je zjednodušení, a tím i zlevnění údržby a rozvoje aplikací. Jasně definuje, co je analytický model, co je návrhový model a jak provádět jejich transformaci. Popis aplikace na různých úrovních abstrakce usnadňuje soudržné promítání změn v aplikaci, přínosem je i standardizace návrhu.
• CIM (Computation Independent Model) = model nezávislý na PC zpracování (model firemních procesů vytvářený procesními analytiky).
• PIM (Platform Independent Model) = platformově nezávislý model řešení dané problémové oblasti na základě konkrétních požadavků uživatelů, cílem je vyřešit koncepční otázky aplikace (snahou analytiků je vyjádřit, co má aplikace vykonávat, čili řešení na obecné úrovni, nikoliv jak to má dělat).
• PSM (Platform Specific Model) = platformově specifický model řešení, který oproti PIM obsahuje již specifické prvky řešení pro zvolenou cílovou platformu (podklad pro vlastní implementaci aplikace).
• Code = kód aplikace, výsledná realizace řešení, model konkrétní realizace na dané platformě.

Analýza webových služeb pomocí UML

• Webové služby (Web Services, WS) jsou postaveny na modelu založeném převážně na komponentách. Pro každý případ užití se vytváří sekvenční diagram jen na úrovni výměny zpráv prostřednictvím svých rozhraní, navrhují se parametry operací rozhraní jako budoucí webové služby (ponesou informace ve formátu XML). Dále se rozhodne, které služby se nakoupí a které se vyvinou. Analyzují se služby, které se budou vyvíjet, a na závěr se vytváří řešení z dodaných a vyvinutých služeb.