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

Transkript

1 Jazyk UML VST (Velmi stručný tutorial) verze 1.0 Softwarové inženýrství školní rok Ing. Ladislava Smítková Janků (Praha, )

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

3 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 jankul@cslab.felk.cvut.cz. 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.

4 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.

5 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)

6 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.

7 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í

8 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í

9 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:

10 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:

11 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.

12 Obr. 9: Ukázka stavového diagramu Obr. 10: Ukázka stavového diagramu

13 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]

14 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.

15 Použitá literatura a internetové zdroje [1] Arlow, J., Neustat, I.: UML a unifikovaný proces vývoje aplikací. Computer Press, ISBN: X, Praha [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, [5] Cetus Tutorial, 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, ibm.com/software/rational/uml/ [8] Pressman,R.S.: Software Engineering: A Practitioner's Approach. ISBN , McGraw Hill, [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