Úvod do UML
Unifikovaný vizuální modelovací jazyk (UML)
Jazyk pro :
· Vizualizaci,
· Konstrukci,
· Specifikaci,
· Dokumentaci
Artefaktů SW systémů
Proč unifikovaný?
· Sjednocení předchozí metody a notace
· Podporuje celý vývojový cyklus
· Podporuje různé aplikační oblasti
· Volnost v použití metodiky
· Nezávislý na cílovém prog. Jazyku a doméně
· Založený na potřebách a zkušenostech a potřebách komunity.
· Reflektuje současné trendy vývoje SW
UML
· Jazyk = syntaxe + sémantika
o Sytaxe – pravidla, jak tvořit výrazy s elementů
o Sématika – jak syntaktickým výrazům přiřadit vývznam
· Není metodika – nepředepisuje, jak postupovat při vývoji SW
UML Historie-
Programovací jazyky
· Simula – třídy, objekt, polymorfismus, dědění
· SmalTalk – virtuální stroj
· C++ - výjimky
· Eifel – garbage collection
Objektové modelovaci jazyky a metodiky
· Booch - OOAD
· Rambauch - OMT
· Jacobson – Objectory
1994 – zahájení vývoje UML – Rational Software (Rumbaugh, Booch)
1995 – notace pro Unified Method 0.8, připojuje se
· Jacobson a model jednání, Rational Unified Process
1995 – UML 1.0 (zabudování připomínek, kooperace)
1996 1997 – UML 1.1 (preciznější sémantika, přijat jako standard OMG)
1999 – UML 1.3 (upřesněná verze 1.1)
2001 – UML 1.4 (komponenty)
2003 – UML 1.5 (diagramy aktivit, sémantika akcí)
2005 – UML 2.0 (nové diagramy, změny)
2006 – UML 2.1 (další snaha o upřesnění sémantiky)
MDD – Model Driven Development
MDD – Model Driven Delelopment
Objekty a UML
UML modeluje systém jako množinu spolupracujících objektů
Statiscká struktura
Jaké druhy objektů jsou důležité
Jaké jsou jejich vztahy
Dynamické chování
Životní cyklus objektu
Interakce objektů pro dosažení cílů
Struktura UML
Stavební bloky-obecné mechanizmy-architektura
Stavební bloky
· Věci (Things)
o Modelovací atomy
· Vztahy
o Pojí věci dohromady
· Diagramy
o Pohledy na významné spojení věcí
o Různé pohledy na modelovaný systém
· Věci
o Strukturální abstrakce – podstatná jména modelu
§ Třídy, rozhraní, spolupráce, případy užití, aktivní třídy, komponenty, uzly
o Absatrakce chování – slovesa modelu
§ Interakce, stavové automaty
o Seskupení
§ Balíčky
· Modely, rámce, podsystémy
o Anotace
§ Poznámky
Vztahy
UML má 13 typů diagramů
Diagramy
Syntaxe diagramu
Společné mechanizmy
· Specifikace
· Ornamenty (adorments)
· Podskupiny
· Mechanizmy rozšířitelnosti
Specifikace
Ornamenty (Adornments)
Podskupiny
Profily UML
· UML pro specifické účely
· UML prfil je kolekce stereotypů, omezeních a označeních dat
o Označené hodnoty a omezení jsou asociovány se stereotypy
Architektura
Organizační struktury softwarového systému)
Co jsou to objekty
· Objekt – znovupoužitelná jednotka skládající se z dat a funkcí zabalených dohromady – Objekt zapouzdřuje data
· Každý objekt – instance nějaké třídy
· Třídy definuje společné rysy (vlastnosti a operace) společné pro všechny instance
· Objekt má:
o Atributy – datová část
o Operace – chování
· Všechny objekty mají:
o Identitu – objekt je jednoznačně identifikovatelný
o Stav – určený aktuálními hodnotami atributů a vazbami na jiné objekty
o Chování - množina operací, které může daný objekt aktuálně provádět
Zapouzdření
· Data schovaní uvnitř objektu
· Přístup pouze pomocí operací
Posílání zpráv
· V OO systémech posílají si objekty zprávy prostřednictvím linků
· Poslání zprávy způsobí vyvolání metody cílového objektu
UML syntaxe objektů
Co jsou to třídy
· Každý objekt je instancí třídy
· Třída definuje typ objektu
· Třídy umožňují modelovat množinu objektů se stejnými vlastnostmi – třída představuje šablonu na objekty:¨
o Stejné atributy
o Stejnou množinu operací
o Obecné různé hodnoty atributů
· Klasifikace (rozdělení na třídy) umožnuje udržet si organizovaný pohled na svět
· Představujte se třídy jako:
o Razítka
o Formičky na cukroví
Třídy a objekty
Objekty – instance tříd
Instance – proces vytvoření objektu
Třídy poskytují metody na vytvoření intance – konstrukce
Konstruktor metoda třídy nikoli objektu
UML natoce třídy
· Třídy pojmenované UpperCamelCase
· Pojmenovávejte jména podstatných jmen
· Nepoužívajte zkratky
Oddíl atributů
Visibility name : type multiplicity = intialValue
Povinné
· Vše kromě jména je volitelné
· initialValue je hodnota, kterou atribut dostane při instanci
o Atributy pojmenované atributy podstatnými jmény
o Nepoužívejte zkratky
· Atribut může mít
o Stereotyp jako prefix
o Seznam tagged values jeho postfix
Viditelnost
Násobnost (multiplicita)
· Umožnuje modelovat kolekce věcí
Oddíl operací
Druhy parametrů
Rozsah platnosti
· Dva druhy rozsahu pro atributy a operace:
Konstrukce objektu
· Třída poskytuje (statické operace) jeden či více konstruktorů
Příklad ClubMemeber
· Každý objekt ClubMeter má svoji kopii atributu membershipNumber
· Atribut numberOfMembers existuje jednou a je sdílen všemi instancemi třídy ClubMember
· Počítání instancí
Co Co je to vztah
· Spojení mezi modelovanými elementy
· Zde:
o Spojení mezi instancemi
o Asociace mezi třídami
§ Agregace
§ Kompozice
§ Asociační třídy
Co je to spojení?
· Spojení sémantická vazba mezi instancemi
· Pomocí spojení objekty komunikují
o Zprávy posílání pomocí spojení
o Zprávy vyvolávají operace
· OO prog. Jazyky implementují spojení jako reference či pointery.
Spojení objektů
Co je to asociace
Syntaxe asociace
Multiplicita
Reflexivní asociace
Hierarchie a sítě
Průchodnost
· Průchodnost vyjadřuje, jakým směrem lze posílat zprávy
· Jaký objekt má odkaz na který
Průchodnost – zásady
· 3 možné způsoby:
o Znázorňuje průchodnost explicitně všude
o Neznázorňuje průchodnost nikde
o Neznázorňuj křížky
§ Obousměrné nemají šipky - standart
§ Jednosměrné mají šipku - standart
Asociace vs Atributy
· Při jednosměrné asociaci s rolí může být nahrazena atributem
· Vyjadřují to samé
· Kdy použít asociaci:
o Cílová třída je důležitá pro model
o Cílová třída je nestandardní
· Kdy použít atribut:
o Cílové třída je standardní nebo primitivní typ
Asociace třídy
· Do person – různé platy v různých zaměstnáních
· Ne do company – různí lidé různé platy
· Plat je vlastnost vlastního vztahu
Syntaxe asociační třídy
· Jedna aociační třída pro jedno spojení
o Má
§ Atributy
§ Operace
o Jako obyčejná třída
o Identifikovaná párem asociujících objektů
Použití
Agregace a kompozice
· Asociace vytvořené při analýze se předělají na agregaci a kompozice
· Třeba doplnit průchodnost, násobnost a jména rolí.
Agregace
· Celek a část nejsou na sobě existenčně závislé
· Části mohou být sdíleny více celky
· Agregace
Kompozice
· Části nejsou sdílené
· Celek je zodpovědný za instrukci a destrukci částí
· V momentě zániku celku zanikají i jeho části
· Kompozice tranzitivní a asymetrická
Generalizace
· Vztah mezi obecným a více specifickým elementem§
· Více specifické elementy konzistentní s obecným, ale obsahuje více informací§
· Instance více specifického elementu použitelná všude, kde je použitelná obecná
Generalizace tříd
Dědění
Dědění
· Podtřídy dědí všechny vlastnosti nadtřídy:
o Atributy
o Operace
o Vztah
o Stereotypy, tagy, omezení
· Podtřída přidává nové prvky
· Podtřída může změnit implementaci operací
Překrývání
· Podtřída často potřebuje změnit chování definované v předkovi
· Při přetížení signatura v potomkovi musí být identická s předkovou
o Jména parametrů nehrají roli
Abstrakce operace
· Abstrakce operace – signatura bez implementace
· Třída abstraktní pokud má nějaké abstraktní operace
· Od abstraktní třídy není možné vytvořit instance
· Potomek abstraktní třídy také abstraktní pokud neimplementuje abstraktní operace.
Polymorfismus
· Polymorfismus = „více forem“
o Polymorfní operac – více implementací
o Shape::draw() and
Shape::getArea ()
Co se stane?
· Každá třída má svou implementace operace draw ()
· Každý objekt realizuje operaci draw() po svém
Příklad – BankAccount
Syntaxe generických tříd
Vnoření třídy
Rozhraní (Interface)
· Speciální druh (abstraktní) třídy
· Specifikuje pojmenovanou množinu vlastností
· Účel – oddělení specifikace funkčnosti od implementace
· Rozhraní definuje kontrakt, který musí implementující klasifikátory realizovat
Kontrakt
Rozhraní specifikuje | Realizující klasifikátor |
Operace | Musí mít operaci se stejnou signaturou a sémantikou |
Atribut | Musí mít veřejné operace pro čtení/modifikace atributu. |
Asociace | Implementující klasifikátory musí mít mezi sebou stejnou asociaci jako rozhraní. |
Omezení | Must support the constraint |
Stereotypy | Má stereotyp |
Tagged value | Má tagged value |
protokol | Realizuje protokol |
Syntaxe poskytovaného rozhraní
· Poskytování rozhraní – klasifikátor ho implementuje
Syntaxe požadovaného rozhraní
· Požadované rozhraní - Klasifikátor používá metody předepsané rozhraní
Rozhraní (Interface)
Konektor sestavení
· Poskytované a požadované rozhraní možné spojit konektor
Porty – organizace rozhraní
· Bod interakce mezi klasifikátorem a rozhraním
· Seskupuje logicky související rozhraní
· Port má typ daný poskytovaným a požadovaným rozhraním
· Může mít jméno
Diagram tříd
Diagram tříd
· Vše předchozí vyjma instancí jsou stavební prvky diagramu tříd
· Diagram tříd nezobrazuje objekty
Diagram objektů
Diagram objektů
· Zachycuje instanci tříd a jejich momentální vztahy v určitém momentu
· Může obsahovat i třídy – vztah instance/třídy
· Umožnuje vyjádřit role zobrazovaných objektů
· Asociace mezi třídami specifikují možné vztahy
Diagram struktury
Diagram struktury
· Ukazuje interní strukturu klasifikátoru včetně jeho bodů interakce s okolím
· Ukazuje konfiguraci a vztahy částí klasifikátoru zajištující jeho chování
· Klasifikátory především
o Třídy
o Komponenty
· V každém autě je jeden motor, dvě přední a dvě zadní kola
· Motor pohání přední kola
· Motor nepohání nic jiného
· V každém člunu je jeden motor a několik lodních šroubů
· Motor pohání lodní šrouby
· Motor nepohání nic jiného
· Totéž pomocí tříd?
· Motor v jednom autě může pohánět kola v jiném autě
· Každý motor pohání kola i lodní šrouby
· Motor může pohánět libovolná dvě kola
Notace
Část (part)
· Instance nějakého klasifikátoru
· Představuje roli
· Vlastnosti
o Jméno role
o Typ (klasifikátor)
o Multiplicitu
· Např. front:wheel[2]
Konektor (Connector)
· Specifikuje instanci vztahu uvnitř klasifikátoru
· Vztah mezi instancemi v rolích
· Rozdíl
o Asociace – vztah mezi klasifikátory
o Konektory – vztah mezi rolemi
· Např. motor pohání přední kola (:powers)
Port
· Bod interakce mezi klasifikátorem a okolím
· Zprávy jsou směrování na instance portů, na vlastní objekty
· Delegace
o Rozpoznání zprávy
o Přesměrování na zodpovědnou část
· Porty vznikají a zanikají spolu s objekty
Kolaborace
· Cíle
o Kdo se na spolupráci podílí
o Jakou při tom hraje roli
o Volitelně: jaké atributy jsou užity při spolupráci
o Nejde o kompletní definici třídy
Komponenty
· Modulární část systému zapouzdřující svůj obsah a jejíž projev je nahraditelný v daném prostředí
· „černá skřínka“ projevující se pomocí požadovaných a poskytovaných rozhraní
· Zastupuje cokoli, z čeho lze vytvořit objekt za běhu systému
Rozhraní and CBD
· Rozhraní jsou klíčová pro component based development (CDB)
· CBD je konstrukce SW výměnných plug-in částí:
o Plug – poskytované rozhraní
o Socket – požadované rozhraní
Co je to komponenta?
· Dle specifikace UML 2.0 modulární část systému zapouzdřující svůj obsah a jejíž projev je nahraditelný v daném prostředí
· Černá skřínka jejíž chování je plně definováno poskytovaným a požadovaným rozhraním
· Nahraditelná jinou komponentou se stejným protokolem
Syntaxe komponenty
· Komponenty mají poskytována a požadována rozhraní, porty a vnitřní strukturu
o Rozhraní delegují zprávy na vnořené části
o Vnořené komponenty znázorněné bud uvnitř nebo vně a je použita relace závislosti.
Komponenty
Diagram komponent
1. Vyjadřují fyzickou (vnitřní) strukturu komponent
a. Přiřazení klasifikátorů (třídy, komponenty,…)
b. Přiřazení artefaktů komponetám
2. Popisují systém jako kompozici komponent
(závislosti mezi komponentami)
Artefakt
· Fyzickým projevem jedné či více komponent
o Zdrojové soubory
o Spustitelné soubory
o Skripty
o Dokumenty
Artefakty a komponenty
· Artefakty jsou fyzickým projevem jedné či více komponent
· Artefakt může obsahovat další artefakty
· Artefakty mohou záviset na dalších artefaktech
Vztahy artefaktů
· Artefakty mohou záviset na jiných artefaktech – důsledek závislosti komponent
Standardní stereotypy artefaktů
Artifact stereotype | semantics |
<<file>> | A fyzický soubor |
<<deployment spec>> | Specifikace nasazení |
<<executable>> | Dokument |
<<library>> | Spustitelný soubor |
<<library>> | Statická nebo dynamicky link, knihovna (DLL) nebo Java Archive (JAR) |
<<script>> | Skript proveditelný pomocí interpretu |
<<source>> | Zkompilovatelný zdrojový soubor |
Stereotypy artefaktů
· Stereotypy definované profilem např. Java
Diagram komponent
· Ukazuje přiřazení artefaktů uzlům resp.
· Ukazuje přiřazení instancí artefaktů instancím uzlů (diagram konkrétního nasazení)
· Uzel
o <<device>> - HW (Server, PC, pokladna
o <<environement>> - SW (OS, www server, aplikační server,….)
· Artefakt
o Obvykle projevem jedné či více komponent
o Fyzickým projevem libovolného prvku UML
§ Zdrojový soubory
§ Spustitelné soubory
§ Skripty
§ Dokumenty
Diagram nasazení vs komponent
· Komponent diagram – komponenty a realizující artefakty
· Deployment diagram artefakty nasazení na uzlech
Uzly – typ
· Uzal představuje typ výpočetního zdroje
o Např. a WinodwsPC
Uzly – instance
· Uzel reprezentuje konkretní instanci výpočetního zdroje
o Např. JimsPC:WindowsPC
Nasazení
· Artefakty nasazení na uzly (typy), instance artefaktů nasazení na instance uzlů
Diagram nasazení
· Hlavní prvky . uzel, komponenty, artefakt
· Hranice mezi použití ikon pro uzel, artefakt, komponentu – neostrá
Diagram nasazení
Vlastní ikony
· Ikona zastupuje uzel s určitým stereotypem
Diagram nasazení
Balíček
· Mechanismu pro spořádání prvků a diagramů do skupin
· Účel
o Mechanismus entity velkých modelů
o Jednotku pro souběžnou práci
o Jednotky pro správu konfigurace
o Poskytující zapouzdření jmenné prostory
· Doporučení
o Seskupit sémanticky příbuzné elementy
o Minimalizace relace napříč balíčky
Syntaxe
Viditelnost prvků v balíčku
· Viditelnost prvků realativní vzhledem k jeho balíčku
o + public – viditelný všem i mimo balíček
o # protected – viditelný zděděným balíčků
o – private – nevidetlný mimo balíček
Balíček
Vnořené balíčky
· Jmenné prostory
o Auta::SportAuta::Porsche
o Atuo::OffRoadAuta::LandRover
o Auta::Octavia
· V rámci balíčku – bez prefixu
Generalizace balíčků
· Potomek dědí veřejné a chráněné prvky
· Potomci mohou přetížit prvky z předka
· Potomci mohou přidat nové prvky
Závislost balíčků-import
· Veřejně importovaného balíčku se stávají veřejnými prvky importujícího
Závislost balíčků – access
· Veřejné prvky importovaného balíčku se stávají soukromými prvky importujícího
· Zobrazují, kdo a jakým způsobem užívá navrhovaný systém
· Cíle tvorbu DPU
o Najít aktéry-uživatele systémy
o Zjistit jak systém používají
o Vymezit hranice systému
Zobecnění případu užití
Relace <<include>>
· Vkládaný prvek je nutný pro existence vkládajícího
· Vkládáný prvek obvykle opakujícíc se rutina
Relace <<extend>>
· Vkládaný prvek je volitelný
· Vkládájící prvek je úplný
Model jednání
· Model jednání =
o Diagram připadu užití +
o Slovní scénář pro každý případ užití
· Realizace USE CASů jako interakce instance klasifikátoru
· Sekvenční diagram
· Diagram komunikace
· Přehledové diagram
· Časové diagram
Hlavní prvky diagramů interakce
· Čáry života (Lifelines)
· Zprávy – komunikace mezi lifelines
Čáry života (Lifelines)
· Jméno – the name used to refer to the lifeline in the interaction
· Selector – logická podmínka určující konkrétní instance
· Typ
Musí být unikátní v rámci diagram
Stejná ikona jako klasifikátor, který ji reprezentuje
Zprávy
· Realizace případů užití jako spolupráce komunikacích instancí tříd
Sekvenční diagramy
· Vstupem pro tvorbu
o Diagram případu užití
o Slovní scénář
o Diagram tříd
· Během tvorby dochází k vytvoření
o Nových metod
o Nových metod tříd
· Kladou důraz na časové hledisko
· Ukazují
o Kdo (instance tříd) se podílí na realizaci
o Jaké zprávy a s jakými parametry si objekty vyměňují
o V jakém pořadí
o Aktivace nejsou povinné
Invarianty stavu a omezení
Kombinované fragmenty
o Operátor říká jak (režim) budou operandy spušteny
o Guard condition – podmínka spuštění daného operandu/ů
Iterace s loop a break
¨
· Stejný účel jako sekvenční diagramy
· Zdůrazňují strukturní hledisko
o Jakým způsobem jsou objekty při spolupráci přivázané
o Čas zachycen pomocí číslování zpráv
Syntaxe
Iterace
Větvení
· Objektově orientované vývojové diagramy
· Popis procesu
· Proces složen z dílčích subprocesů
· Založené na Petriho sítích
· Hra s tokeny
Diagram aktivit
· Nejčastěji použité
o Analýza
§ Průchod USE Casey
§ Scénář z procesního hlediska
o Návrh
§ Popis organizace
o Modelování organizace
§ BMP- modelování firemních procesů
Akční uzel
· Volání akce
· Poslání signálu
· Čekání na signál
Akční uzel – volání akce
· Spuštěn – tokeny na všech vstupních hranách AND
· Po dokončení akce – tokeny na všech výstupních hranách
Diagram aktivit
Řídící uzel
Objektový uzel
· Vyrovnávací paměť
· Takone čeká v uzlu, dokud není příjmut na nějakém výstupu
· Výstupy soupeří – token se neduplikuje
Parametry aktivit
Přídavné uzly
· Zpracování kolekcí
· Módy
o Iterativní
o Paralelní
o Proudový
Signálové uzly
Signálové uzly
· Speciální typ akčních uzlů
· Vyslání
o Asynchronní (nečeká se na odpověď)
o Více vstupů (AND)
· Přijetí
o Příjme se token a čeká se na signál
o Max. jeden vstup
o Jeden výstup
Centrální buffer
· Převod proudu na iteraci
Příklad – doplnění kofeinu
Stavový diagram
· 1 stavový automat pro 1 reaktivní objekt
· Reaktivní objekt
o Reaguje a vnější události
o Životní cyklus jako řada stavů, přechodů a událostí
o Jejich chování důsledkem předchozího chování
· SA popisuje životní cyklus reaktivní objekt
· Reaktivní objekt např.
o Třída
o Systém
o Podsystém
Výstupy a akce
· Při změně stavu automat může generovat výstup
Rozšířené stavové automaty
· Stavy mohou mít proměnné
Trochu teorie
· Rozšíření Mealyho stroj je definován:
o Množinou vstupních signálů (stimulů) (vstupní abeceda)
o Množinou výstupních signálů (výstupní abeceda)
o Množinou stavů
o Množinou přechodu
§ Odkud
§ Kam
§ Stimul
§ Akce
o Množinu proměnných stavu
o Počátečním stavem
o Množinou koncových stavů (pokud se uvažuje)
Vstupní a výstupní akce stavu
Pořadí provádění akcí
Vnitřní přechody
· Nedochází k přechodu do jiného stavu
„Do“ Aktivity
· Spouští paralelní vlákno prováděné dokuk:
o Akce neskončí
o Dojde k přechodu do jiného stavu (signálem)
Podmíněné přechody
· Stimul + podmínka
Podmíněné větvení
Hierarchické stavové automaty
· Stav představuje automat
Skupinové přechody
Samovolný přechod
· Nemá stimul
· Proveden automaticky po skončení vnitřního stavu
Spouštěcí pravidla
· Více přechodů může mít stejný signál
o Vnitřní mají přednost
Pořadí akcí
Historie stavů
· Chceme se vrátit do místa, odkud jsem opustili složený stav
o Hluboká a mělká historie
Orthogonalita
· Entita je současně ve více nezávislých stavech
Sémantika OR
· Automaty v regionech přijímají oba vnější podněty a běží paralelně
Sémantika
· Čeká se na doběhnutí obou automatů
Podmínka na ukončení
Stavový diagram
Příklad
· Zobrazuje tok mezi interakcemi
· Kombinace diagramu aktivit a sekvenčního diagramu
· Vyjádření časových závislostí mezi změnami stavů objektů
