Základní mechanizmy UML

Transkript

1 Unified Mdeling language (UML), ppis jazyka, typy diagramů a způsb jejich pužití při návrhu různých aspektů systému, syntax a sémantika jazyka a jeh symblů. C je UML (Unified mdeling language) - grafický mdelvací jazyk pr vytváření visuálních (grafických) mdelů, specifikaci, vizualizaci, knstrukci a dkumentaci při OO analýze a návrhu (OOAD) - pr mdelvání rganizace (business mdelling) - není mdelvací metdika neříká nic navrhvání SW - UML je tevřený, standardizvaný, průmyslvě užívaný jazyk - pdpra v CASE nástrjích části UML 2.0 specifikace Superstructure definuje zápis a sématiku diagramů a jejich mdelvacích elementů Infrastructure definuje metamdel na němž je pstavena část 1. Object cnstrain language (OCL) - jazyk pr specifikaci vstupních a výstupních pdmínek, invariantů v jedntlivých diagramech. Diagram interchange - ppis XML struktur pr výměnu knkrétních mdelů mezi jedntlivými mdelvacími nástrji. Základní mechanizmy UML Specifikace Každý element by měl být specifikván textem, který ppisuje sémantiku tht elementu. Tat specifikace upřesňuje, blíže ppisuje, udává smysl mdelvanéh elementu. Ppisuje business pravidla elementů (tudíž má největší význam u elementů ppisujících prblémvu dménu). Ozdby (adrnments) Další infrmace známé elementu mdelu. Každý element může být vyjádřen jednduchým tvarem, ale je mžn k němu přidávat i další infrmace - zdby (např. seznam metd, seznam atributů, název bjektu, steretyp,..). Prč je těcht zdb u elementu zbrazen někdy více a někdy méně: mdel vytváříme pstupně : zpčátku máme mál infrmací, které pstupně dplňujeme tvrbu určitéh diagramu sledujeme určité cíle - nechceme v něm zbrazit ty pdrbnsti, které jsu v tmt nepdstatné z hlediska th, c právě chceme zdůraznit (jedn z prvřadých hledisek při tvrbě diagramu je ttiž snadná čitelnst) -1-

2 Pdskupiny (cmmn divisins) Udávají, jak je mžn rzdělvat jedntlivé elementy; první způsb dělení : klasifikátr a instance: bjekt je instance, třída je klasifikátr rzhraní a implementace: prtkl zpráv je rzhraní bjektu abychm pužili (již htvý) bjekt, nemusíme znát jeh implementaci - stačí nám znát jeh rzhraní, vnitřek bjektu může být libvlně změněn Mechanismy rzšiřitelnsti Jazyk UML bsahuje připravené mechanismy umžňující rzšířit jazyk tak, aby vyhvval mmentálním ptřebám. Máme k dispzici tři mechanismy rzšiřitelnsti: mezení (cnstraints) : text ve slžených závrkách {}. Pdmínka či pravidl v tmt textu musí být vždy splněna steretypy (steretypes) : s jejich pmcí lze z existujícíh elementu vytvřit nvý značené hdnty (taggedd values) : umžňuje přidávat nvé vlastnsti k elementům mdelu. Zavedeme ji přidáním názvu s připjenu vlastní hdntu ve slžených závrkách, např. {autr=pavus, verze=0.1} prfily: Prfil UML definuje mnžinu steretypů, značek a mezení, díky nimž lze jazyk UML přizpůsbit knkrétnímu účelu. (např. můžeme mít nějaký prfil mdelvání aplikací pr platfrmu J2EE, jiný prfil pr.net, apd.) Stavební blky UML Mdelvací elementy Strukturální class, interface, cllabratin, active class, cmpnent, nde, (lze si je představit jak pdst. jména UML mdelů) Behavirální interakce, stavvé strje, use case Skupiny balíček (package) Vztahy Relatinships -2-

3 Diagramy struktury systému Diagram tříd -statická struktura systému, ppis typů bjektů a statických vztahů mezi nimi Tři phledy na systém při pužití diagramu tříd: Tipy: Knceptuální kncepty aplikační dmény, bez vztahu k implementaci, jazykvě nezávislá. Specifikační phled na prgram, specifikace rzhraní bez specifikace implementace. Implementační je vidět implementace - hranice nejsu stré, UML pdpruje všechny tři phledy nesnažit se pužít veškeru dstupnu ntaci přizpůsbit phled etapě prjektu: analýza: knceptuální phled návrh: specifikační + implementační kncentrvat se na klíčvé blasti nezabřednut brzy d implementačních detailů Návrhvé relace Agregace Vlná vazba mezi bjekty Typ celek/sučást (celek řídí chd relace, sučást pskytuje služby) Agregvané bjekty mhu být sdílené nezanikají se zánikem celku Celek někdy existuje nezávisle na sučástech, někdy je na nich závislý Sučást může být sdílena více celky Kmpzice Silnější frma agregace -3-

4 Sučásti nemhu existvat mim celek Sučást patří právě jednmu celku Celek dpvídá za pužití svých sučástí Za předpkladu, že dpvědnst za sučásti přejde na jiný bjekt, může celek sučásti uvlnit. Je-li zničen celek, musí zničit své sučásti (neb přenést dpvědnst na jiný bjekt) Dědičnst tříd Ptmci dědí Atributy Operace Relace Omezení Ptmci mhu ke zděděnému fndu přidat nvu charakteristiku Realizace rzhraní Diagram kmpnent - prpjení kmpnent - kmpnenta je část systému, která realizuje specifikvaná rzhraní - kmpnenta je mdulární nahraditelná část systému, která zapuzdřuje svůj bsah (stav a chvání) Diagram nasazení Mapuje SW artefakty na fyzické uzly. Diagramy chvání (behavirální) Mdelvání případů užití Use case diagram (UC diagram) zbrazuje chvání systému (neb jeh části) z hlediska uživatele. Vychází z funkčních pžadavků na systém. pstup při mdelvání: Aktéři najít hranice systému (za kteru funkčnst je systém zdpvědný a za kteru již není) najít aktéry najít případy užití diagramy + scénáře Aktér specifikuje rli, kteru si může vnější entita (sba, HW zařízení, jiný infrmační systém) přisvjit. Akteři definují hranice systému. Při identifikaci aktérů zjišťujeme: Kd neb c pužívá systém? V jakých rlích se přitm nachází? Kd instaluje/nasazuje systém? -4-

5 Kd systém udržuje? Které jiné systémy tent systém využívají? Spuští se nějaká událst v závislsti na čase? (např. zálhvání apd.) Případy užití Případ užití je nějaká činnst, kteru aktéři se systémem prvádějí. Případy užití jsu vždy inicivány aktérem. Scénáře případů užití POZOR! Scénáře případů užití jsu nedílnu sučástní mdelu. Samtné diagramy (bez scénářů) nemají ptřebnu vypvídací hdntu. Struktura scénáře: název identifikátr stručný ppis seznam primárních aktérů seznam sekundárních aktérů Vstupní pdmínky Hlavní scénář, ppisuje jedntlivé interakce mezi systémem a aktérem Alternativní scénáře Výstupní pdmínky (např. Kniha byla zapůjčena, byl deslán příkaz k výdeji) Relace include vs. relace extend include vyčleňuje splečné krky něklika případů užití d samstatnéh případu užití klientský případ užití je bez ddavatelskéh neúplný extend umžňuje rzšířit případ užití nvé chvání bázvý případ užití neví rzšiřujícím; má pr něj jen tzv. místa rzšíření; je úplný i bez rzšiřujících rzšiřující bývá zpravidla bez bázvéh neúplný Diagram aktivit - ppis dynamických aspektů systému - tk řízení z aktivity d aktivity - mdelvání bchdních (business) prcesů a wrkflw - sustřeďuje se spíše na prces výpčtu než na bjekty účastnící se výpčtu - akce, partitins, bjektvé uzly, hrana, tk, pčáteční a kncvý uzel Stavvý diagram - zalžen na state machine - vyjadřuje stavy určitéh bjektu a přechdy mezi těmit stavy -5-

6 - přechd je relace mezi dvěma stavy, kde bjekt v prvním stavu přejde d druhéh stavu na ppud nějaké událsti, pkud jsu splněny specifikvané pdmínky (guards), přičemž se prvede specifikvaný efekt sekvenční diagram - vhdný pr zdůraznění časvé pslupnsti interakcí - bjekty si psílají zprávy (synchrnní a asynchrnní) - lze řídit tk pmcí blků lp (while, fr), alt (if, else), pt(if), par (paralelní zpracvání) diagram kmunikace - pdbný jak sekvenční diagram, ale zdůrazňuje strukturální aspekty splupráce (kd s kým kmunikuje) - nezdůrazňují časvu pslupnst interakcí - uzly, kmunikační cesty, zprávy -6-