Jazyk UML VST (Velmi stručný tutorial) verze 1.0

Jazyk UML VST (Velmi stručný tutorial) verze 1.0

Softwarové inženýrství školní rok 2004­2005 

Ing. Ladislava Smítková Janků (Praha, 24.5.2005)

Obsah Obsah Obsah....................................................................................................................................................2 1 Co je to UML.....................................................................................................................................3 2 Diagram případů užití........................................................................................................................4 3 Diagram tříd a diagram objektů.........................................................................................................5 4 Diagram spolupráce ..........................................................................................................................6 5 Diagram sekvencí (Sekvenční scénáře).............................................................................................7 6 Stavový diagram................................................................................................................................9 7 Diagram aktivity (činnosti)..............................................................................................................13 8 Diagram komponent a diagram nasazení.........................................................................................14 Použitá literatura a internetové zdroje................................................................................................15

1 Co je to UML Pár slov úvodem Dostává se vám do ruky velmi stručný tutorial jazyka UML sepsaný na žádost studentů předmětu X36SIN   a   36SI   v   letním   semestru   2004/2005.   Vzhledem   k   nejednoznačnosti   českých   výrazů používaných v českých překladech odborné literatury, uvadím v závorkách vždy výrazy anglické. To by mělo umožnit studentům  snadnější orientaci v anglicky psaných materiálech.  Jedná se o první verzi tutorialu – případné připomínky nebo upozornění zasílejte prosím mailem na adresu [email protected]. 

Co je to UML? UML (Unified Modeling Language) je grafický jazyk pro objektově orientovanou analýzu a návrh softwaru. Jinými slovy, jedná se o jazyk, kterým vývojář popisuje architekturu vyvíjeného softwarového systému ze všech hledisek důležitých pro analýzu a návrh. Protože se jedná o grafický jazyk, jsou konstrukty tohoto jazyka také grafické. Nazýváme je diagramy.  Vývojář používá standardně definované grafické prvky jazyka. Proto jsou jím vytvořené konstrukty (diagramy) srozumitelné každému, kdo zná syntaxi a sémantiku daného grafického jazyka. Místo složitého a často nejednoznačného slovního popisu použije analytik nebo vývojář grafický jazyk s jednoznačně definovanými prvky a konstrukty, které mají jednoznačný význam. 

2 Diagram případů užití Diagram případů užití (Use case diagrams)  slouží ke zmapování skupin uživatelů (uživatelských rolí) a ke zmapování způsobů používání systému každou skupinou uživatelů, tj. ke zmapování sady akcí,   které   každá   skupina   uživatelů   bude   se   systémem   provádět   nebo   od   systému   očekává   (z pohledu externího pozorovatele).  Diagram případů užití slouží: • zadavatelům a budoucím uživatelům systému, aby zjistili, jaké akce nebo uživatelské role ještě nespecifikovali • vývojářům, aby věděli, jaké uživatelské role a akce je třeba navrhnout a implementovat • vývojářům,   aby   vůbec   měli   možnost   se   dohodnout   se   zadavatelem.   Pro   uživatele/ zadavatele totiž není vždy snadné formulovat, jak bude systém využívat.  • generování testů Diagram případů užití obsahuje tyto prvky: účastník (actor) komunikace (communication) případ užití (use case)

Obr.1: Prvky diagramu případů užití dle [6]

Obr.2: Ukázka diagramu případů užití dle [6] Účastníky lze zobecňovat a lze vytvářet jejich hierarchie. 

3 Diagram tříd a diagram objektů UML je jazyk pro návrh objektově orientovanou analýzu a návrh. U OOP (objektově orientované paradigma)   je   základním   stavebním   kamenem   pro   reprezentaci   dat   a   operaci   nad   nimi  třída. Diagram   tříd   (Class   Diagram)  popisuje   strukturu   jednotlivých   tříd   a   vztahy   mezi   třídami.   Z předchozích   kurzů   programování   víte,   že   s   OOP   souvisí   následující   koncepty:   dědičnost   a zobecnění, asociace, agregace, vazby, závislosti, viditelnost, násobnost, abstraktní třída, rozhraní (zopakujte si). Všechny tyto vlastnosti je možné v diagramu tříd znázornit. Diagram objektů je obdobnýů narozdíl od diagramu tříd znázorňuje interakci mezi konkrétními instancemi – objekty. Diagram tříd je statický diagram – znázorňuje, které třídy spolu interagují, ale neříká nic o tom, jak tato interakce probíhá. Lze jej chápat jako datový model vyvíjené softwarové aplikace. V jazyce UML se třída znázorňuje jako obdélník rozdělený na tři části: název třídy, atributy a metody. Asociace se znázorňuje pomocí čáry spojující dvě třídy. Agregace je označena kosočtvercem (diamond). Zobecnění (generalizce) je označena trojúhelníkem/šipkou směřujícím k nadřazené třídě. 

Slovníček pojmů: třída (class)  abstraktní třída (abstract class) zobecnění (generalization) jméno role (role name) násobnost (multiplicity) směr asociace (navigability) asociace (association) jméno třídy (class name) atributy (attributes) metody, operace (operations)

4 Diagram spolupráce  Diagramy spolupráce (Collaboration diagrams) patří mezi diagramy interakce. Diagram spolupráce znázorňuje vztahy mezi objekty a zprávy, které si objekty posílají. Kvůli přehlednosti se každá zpráva zakresluje jednou, i když se ve skutečnosti může vyskytnout i vícekrát. Na rozdíl od diagramů sekvencí (sekvenčních scénářů), které také patří mezi diagramy interakce, diagramy spolupráce znázorňují časový rozměr pouze číslováním zpráv mezi objekty. Diagramy spolupráce popisují role objektů v systému.  V diagramu spolupráce je   každý objekt znázorněn obdélníkem. Objekty jsou navzájem spojeny asociačními čarami. Zprávy zasílané mezi objekty se znázorňují pomocí šipek. Šipka směřuje k cílovému objektu a je popsána názvem zprávy. Zpráva obvykle informuje cílový objekt o tom, že má   vykonat   nějakou   operaci.   Za   názvem   zprávy   se   uvádějí   závorky,   do   kterých   se   vpisují parametry.  Pořadí zpráv v čase se znázorňuje číslem zprávy. Číslo zprávy se uvádí před jménem zprávy.  V diagramu spolupráce se objekty znázorňují jako obdélníky, do kterých je vepsán název třídy nebo objektu nebo obojí.  Diagram spolupráce obsahuje tyto prvky: objekt (object) zpráva (message) iterace (iteration) pořadí zprávy (sequence number)

Obr. 4: Ukázka diagramu spolupráce dle [6] V diagramu spolupráce je možné zachytit i změny stavu objektu. Každému stavu objektu odpovídá samostatný   obdélník.   Vzájemně   jsou   stavy   téhož   objektu   propojeny   čárkovanou   šipkou.   Šipka směřuje   ke   stavu   objektu,   do   kterého   objekt   přechází.   Do   diagramu   spolupráce   lze   znázornit   i vytvoření nového objektu nebo více objektů stejné třídy.  

5 Diagram sekvencí (Sekvenční scénáře) Diagramy sekvencí (Sekvenční scénář e, Sequential scenario) patří mezi tzv. scénáře interakce.  Popisují interakci mezi jednotlivými objekty, moduly systému apod. Sekvenční scénáře popisují spolupráci mezi objekty v kontextu času. Na každou interakci mezi objekty lze pohlížet jako na sekvenci akcí v čase. Sekvenční scénáře zachycují právě takovéto sekvence akcí v čase v rámci interakce dvou a více objektů. Čas v těchto diagramech plyne směrem dolů. Sekvenční scénáře obsahují tyto prvky: objekt (object), jinak to také může být komponenta, modul, apod. zpráva (message) iterace (iteration) podmínka (condition) vytvoření (creation) vymazání (deletion) označení aktivace (activation bar) linie existence („života“) objektu, komponenty apod. (lifeline) Zpráva zaslaná jedním objektem druhému objektu vede od linie života jednoho objektu k linii života jiného objektu. Objekt může zaslat zprávu i sám sobě. Každá zpráva může být buď jednoduchá, synchronní nebo asynchronní. Každý typ zprávy reprezentuje jiná šipka (jednoduchá zpráva = jednoduchá šipka, synchronní zpráva = plná šipka, asynchronní zpráva, poloviční šipka).

Obr. 5: Sekvenční scénář  dle [6] Implicitně se v UML používají sekvenční scénáře pro popis interakce mezi objekty. Pokud popisují

interakci mezi moduly, komponentami apod., bývá rozumné na tuto skutečnost v doprovodném textu upozornit. Je také zřejmé, že „neobjektové“ scénáře neobsahují vytvoření a vymazání objektu apod.  Oproti tomu scénáře interakce mezi objekty mohou zachytit aktuální stavy jednoho či více objektů. 

Ukázky sekvenčních scénářů:

Obr. 6: Ukázka sekvenčního scénář e přihlašování

6 Stavový diagram Stavové   diagramy   (Statechart   diagrams)  spolu   s  diagramy   aktivity   (Activity   diagrams,   někdy překládáno také jako diagramy činnosti) popisují dynamiku vyvíjeného systému. Stavové diagramy popisují změny objektů v čase. Stavový diagram popisuje všechny stavy a podmínky přechodů mezi jednotlivými stavy.  Základním   prvkem   stavového   diagramu   je   stav.   K   jeho   označení   používáme   obdélník   nse zaoblenými rohy, který obsahuje název stavu. Tento obdélník může být rozdělen na 3 části: název, stavové proměnné a činnosti, které se vážou k danému stavu. Stavové diagramy obsahují následující prvky: počáteční stav (initial state) koncový stav (final state) stav (state) akce (action) přechod (transition) událost (event) podmínka (guard) aktivita (activity) Stavový   diagram   popisuje   chování   systému   pomocí   sady   stavů   a   přechodů   mezi   těmito   stavy. Systém se může nacházet v různých stavech. Ke každému stavu se může/nemusí vázat jedna nebo více   akcí.   Přechod   do   jiného   stavu   je   definován   pomocí   přechodu   (tj.   akce   označované   jako „přechod“, „transition“, která způsobí přechod systému z jednoho stavu do jiného). Scénář končí v koncovém stavu (final state). Značení dle normy je uvedené v následující ukázce:

Obr. 7: Ukázka stavového diagramu dle [6] Speciální   značení   nabízí   UML   pro   vyjádření   souběžnosti   (concurrency)   a   asynchronity (asynchrony) ve stavových diagramech.  Setkáme se s těmito prvky: složený stav (composite state) vlákno (thread) větvení (fork) spojení (join) podstav (substate) Ukázka je na následujícím obrázku: 

Obr. 8: Ukázka stavového diagramu dle [6] Ukázky studentských prací: Úloha Záměrem tohoto projektu je vytvoření informačního systému elektronického obchodu. Systém bude umožňovat prodej zboží přes internet: jeho zobrazování zákazníkům podle různých kritérií, vedení skladové evidence, evidence zákazníků a napojení na účetní program. E­obchod budou využívat jak zákazníci   pro   nákup   zboží   a   informování   o   jeho   dostupnosti,   tak   zaměstnanci   dle   svých přístupových práv nastavených v závislosti na jejich pozici ve firmě.  Návrh ř ešení: Základem systému je serverová stanice. Na té běží operační systém Linux, webový server Apache a databázový server MySQL. Stanice je připojena do sítě internetu i lokální sítě. V lokální síti jsou zapojeny   další   pracovní   stanice  sloužící   zaměstnancům   ke   komunikaci  se   systémem   a  laserová tiskárna pro tisk faktur. Celý systém je založen na použití PHP skriptů pro generování dynamických stránek   obchodu   a   administrace   umožňujících   interaktivní   komunikaci   uživatele   se   systémem. Systém   bude   mít   všechna   data   uložená   v   databázi.   Stránky   budou   rozdělené   do   dvou   značně nezávislých částí a to stránek katalogu, které se budou starat o zobrazování zboží, košík a generaci objednávky a stránek admistračních, které budou zajišťovat funkce nabízené zaměstnancům.  Veškerá   komunikace   zákazníků   nebo   prodavačů   se   serverem   probíhá   přes   protokol   http   nebo zabezpečený https.

Obr. 9: Ukázka stavového diagramu

Obr. 10: Ukázka stavového diagramu

7 Diagram aktivity (činnosti) Diagramy   aktivity  (Activity   diagrams,   někdy   překládáno   také   jako  diagramy   činnosti)  spolu   se stavovými diagramy popisují dynamiku vyvíjeného systému. Diagram aktivity popisuje jednotlivé kroky operace nebo procesu. Úzce souvisí se stavovými diagramy.  Diagram   aktivity   podává   zjednodušený   přehled   jednotlivých   kroků   procesu.   Každá   činnost   je reprezentována oválem (obdélníkem se zaoblenými rohy, který je ale podstatně užší, než je tomu v případě grafického prvku stavu). Po dokončení každé činnosti následuje přechod na další činnost. Tento přechod je v diagramu znázorněn šipkou. Činností může být i čekání. Začátek a konec se označuje podobně jako ve stavovém diagramu (plný kroužek, plný kroužek s bílým okrajem).  Diagramy aktivity obsahují následující prvky: aktivita, činnost (activity) větvení, rozhodování (branch) začátek (start) konec (end) sloučení (merge) větvení pro modelování souběžných cest (fork) spojení (join) podmínka (guard expression) Při větvení rozlišujeme, zda se jedná o větvení na základě rozhodování (platné PIN, neplatné PIN) nebo zda se jedná o souběžné cesty. Podmínka rozhodování se uvádí v hranatých závorkách.

Obr. 11: Ukázka diagramu aktivity dle [6]

8 Diagram komponent a diagram nasazení Diagramy komponent (Component diagrams) a diagramy nasazení (Deployment diagrams) popisují fyzickou architekturu navrhovaného systému.  Komponenta je označení pro fyzicky existující část softwaru systému – nejčastěji se jedná o modul; může   to   však   být   také   datový   soubor,   dynamicky   linkovaná   knohovna,   spustitelný   soubor, dokument,   apod.   Komponenta   může   být   implementací   více   tříd.   Každá   komponenta   má   své rozhraní.  Při   modelování   se   setkáváme   se   třemi   typy   komponent:  rozmisťované   komponenty, podpůrné   komponenty   a   prováděcí   komponenty.  Mezi   rozmisťované   komponenty   patří   např. dynamicky   linkované   knihovny  (DLL)  nebo  spustitelné   soubory.  Rozmisťované   komponenty   se vytváří z podpůrných komponent. Prováděcí komponenty jsou generovány za běhu systému.

Obr. 12: Ukázka diagramu nasazení a diagramu komponent (spojeny) dle [6] Schmuller [10] uvádí následující důvody pro používání diagramu komponent: •

předvedení struktury hotového systému zákazníkovi,

•

podpora vývojářů – aby věděli co a s čím budou dělat,

•

podpora tvorby dokumentace – aby autoři dokumentace věděli, o čem psát,

•

podpora a usnadnění opakovaného použití komponent.

Diagramy nasazení  se používají ke znázornění hardware a rozmístění jednotlivých softwarových komponent na hardware. Hlavním hardwarovým prvkem je uzel (node).  Uzel je reprezenotván 3D hranolem nakresleném v perspektivě. Uzel může být dvojího typu: procesor a zařízení. procesor je schopen spustit komponentu. Zařízení není schopno pustit komponentu. Uzly se často v diagramech spojují s komponentami. 

Použitá literatura a internetové zdroje [1]   Arlow, J., Neustat, I.: UML a unifikovaný proces vývoje aplikací. Computer Press, ISBN: 80­ 7226­947­X, Praha 2003.  [2]   Drbal: Objektově­orientované metodiky a techniky. Skripta VŠE, Praha 1997  [3]   Chlapek, Řepa: Materiály ke strukturované analýze. Skripta VŠE, Praha 1997  [4] UML Resource page, www.uml.org [5] Cetus Tutorial, http://www.cetus­links.org/oo_uml.html#oo_uml_tutorials [6] Miller, R: Practical UML™: A Hands­On Introduction for Developers, Borland´s Tutorial [7] UML Resource Center, http://www­306.ibm.com/software/rational/uml/ [8]   Pressman,R.S.: Software Engineering: A Practitioner's Approach. ISBN 0­07­707936­1, McGraw­Hill, 1992.  [9]   Richta, Sochor: Softwarové inženýrství I. Skripta ČVUT­FEL, Praha 1996,1998  [10] Schmuller, J: Myslíme v jazyku UML, Grada, Praha 2001