Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- temata:31-uml:main [2011/03/19 14:59]
sgs
+++ temata:31-uml:main [2016/05/27 17:33] (aktuální)
xpavel27 [Potvrzení]
@@ Řádek 1: / Řádek 1: @@
+~~ODT~~
 =====Jazyk UML=====
-UML operuje s pojmem pohled (view). Pohled systému je projekce systému na je-
+**Definice**: UML je jednotný grafický (vizuální) jazyk pro jednotnou specifikaci, vizualizaci, konstrukci a dokumentaci při objektově orientované analýze a návrhu (OOA&D) i pro modelování organizace (business modelling).
-den z jeho relevantních aspektů. Taková projekce se zaměřuje na příslušný aspekt
-a ignoruje ostatní. Jak jistě vyplývá z podstaty věci, je vhodné vytvářet několik
+**Pozor**, častá chyba, nepatří sem ER diagram!
-různých pohledů na tentýž systém. Pohledy nad systémem jsou pak modelovány
-prostřednictvím vhodných nástrojů (modelů) poskytovaných UML. Můžeme ro-
+UML operuje s pojmem **pohled** (view). Pohled systému je projekce systému na jeden z jeho relevantních aspektů. \\
-zlišit tyto základní pohledy:
+Taková projekce se zaměřuje na příslušný aspekt a ignoruje ostatní. \\
-  *Strukturální pohled (structural view) popisuje vrstvu mezi objekty a třídami, jejich asociace a možné komunikační kanály.
+Jak jistě vyplývá z podstaty věci, je vhodné vytvářet několik různých pohledů na tentýž systém. \\
-  *Pohled chování (behavior view) popisuje, jak systémové komponenty (objekty) interagují, a charakterizuje reakce na vnější systémové operace.
+Pohledy nad systémem jsou pak modelovány prostřednictvím vhodných nástrojů (modelů) poskytovaných UML. \\
-  *Datový pohled (data view) popisuje stavy systémových komponent (objekty) a jejich vazby.
+Můžeme rozlišit tyto základní pohledy:
-  *Pohled rozhraní (interface view) je zaměřeno na zapouzdření systémových částí a jejich potenciální použití okolím systému.
+  * **Strukturální pohled** popisuje vrstvu mezi objekty a třídami, jejich asociace a možné komunikační kanály.
+  * **Pohled chování** popisuje, jak systémové komponenty interagují, charakterizuje reakce na vnější systémové operace.
+  * **Datový pohled** popisuje stavy systémových komponent (objekty) a jejich vazby.
+  * **Pohled rozhraní** je zaměřeno na zapouzdření systémových částí a jejich potenciální použití okolím systému.
 Nabízí několik základních diagramů:
@@ Řádek 15: / Řádek 20: @@
 {{:temata:31-uml:clipboard02.jpg|}}
+====Časti UML ====
+  * ** Prvky **
+  * Strukturní: třída, případ užití, komponenta
+  * Chování: interakce, stav
+  * Seskupování: modul, balíček, podsystém (angl. package)
+  * Doplňkové: komentáře a poznámky
+  * **Vztahy**
+  * Asociace (spojení mezi prvky)
+  * Závislost (změna v jednom prvku ovlivní jiný závislý prvek)
+  * Agregace, Kompozice (vyjádření dekompozice prvku na podčásti)
+  * Generalizace (vztah mezi obecnějším a specifičtějším prv-kem)
+  * Realizace (vztah mezi předpisem a jeho uskutečněním deklarace/instanciace)
+  * **Mechanizmy**
+  * Specifikace – textový popis jednotlivých elementů
+  * Ozdoby – volitelné doplňky elementů
+  * Podskupiny – různé způsoby „vidění světa“ (klasifikátor, instance, rozhraní, implementace)
+=== Asociacia ===
+  * slouží k zachycení vztahů a informací mezi třídami z několika různých perspektiv
+  * vyjadruhe identifikaci vztahu mezi třídami - Asociace má svůj název
+  * vyjadruje násobnost vztahu - kolik instancí třídy A může být svázáno s instancí třídy B
+  * Určení jakou roli hraje objekt ve vztahu (např. zaměstnanec, zaměstnavatel apod.)
+  * Asociace se graficky znázorňuje čárou mezi asociovanými třídami.
+  * Násobnost a role se uvádějí u čáry blíže k objektu, ke kterému se váží.
+  * Stupeň asociace – kolik tříd se podílí (participuje) v jedné asociaci
+    * 2 (binární)
+    * 3 (ternální)
+  * Povýšení asociace na třídu. V objektově orientovaném návrhu lze asociaci povýšit na třídu.
+    * V případech, kdy chceme asociaci přiřadit parametry, které nelze přiřadit objektu v asociaci.
+    * Jiným případem povýšení je eliminace vícenásobných asociací.
+{{ temata:31-uml:asociace1.png?400 }}
+{{ temata:31-uml:asociace2.png?400 }}
+== Agregace ==
+  * vyjadřuje slabší vztah mezi objektem reprezentujícím celek a objekty reprezentující části celku.
+  * příklad: Vztah firma-zaměstnanci
+  * objektu reprezentujícímu celek se říká agregační objekt (seskupený)
+  * jeho částem pak konstituční objekty (tvořící).
+  * seskupený objekt může existovat bez svých konstitučních objektů
+  * agregace bývají homeometrické (tj. konstituenti patří do téže třídy).
+{{ temata:31-uml:agregace.png?300 }}
+== Kompozice ==
+  * vyjadřuje silnější vztah mezi objektem reprezentujícím celek a objekty reprezentující části celku
+  * Příklad: člověk - orgány
+  * Objektu reprezentujícímu celek se říká kompozitní (složený) objekt
+  * jeho částem pak komponentní (složkové) objekty.
+  * Složený objekt nemůže existovat bez svých komponent.
+  * Složený objekt většinou řídí životní dráhu svých komponent
+  * Komponentní objekt může být součástí pouze jedné kompozice.
+  * Implicitní násobnost každé složky je 1.
+  * Kompozice bývají heterometrické (tj. komponenty patří do různých tříd).
+{{ temata:31-uml:kompozice.png?400 }}
+== Generalizacia ==
+  * zachycuje vazbu mezi třídami, kterou již známe – dědičnost.
+  * Zobrazuje se šipkou s prázdným trojúhelníkem.
+  * Existuje vícenásobná dědičnost
+{{ temata:31-uml:zobecneni.png?400 }}
+== Zavislost ==
+  * vyjadřuje jiné různé vztahy mezi objekty či třídami.
+  * Typ závislosti se v diagramech označuje pomocí stereotypů
+    * «use» - objekt třídy A (klient) sice neobsahuje objekt třídy B (dodavatel), tedy není jeho složkou, ale přesto jej potřebuje.
+    * «instantiate» – klient je instancí dodavatele
+    * «trace» – obecná vazba mezi elementy, které jsou na různé úrovni abstrakce (analýza/návrh)
+    * «refine» – upřesnění, např. dvě třídy, jedna z nich je optimalizovaná na výkon
+    * «friend» – řízené narušení zapouzdření,klient má přístup k privátním prvkům dodavatele
+    * «bind» – u generický tříd zobrazuje navázání objektu na generický parametr <T>
+{{ temata:31-uml:use.png?300 }}
+== Realizacia ==
+  * je vztah mezi třídou a rozhraním, který říká, že třída implementuje všechny operace z daného rozhraní.
+  * Libovolný objekt pracující s tímto rozhraním pak umí pracovat i s jeho implementačními třídami
+  * Rozhraní je specifický typ třídy, která slouží pouze jako závazná definice chování, neobsahuje implementaci.
+{{ temata:31-uml:realizace.png?300 }}
 ====UML v etapách vývoje softwaru ====
-===1. Specifikace požadavků===
+=== 1.Specifikace požadavků ===
+  * **Vyuzivaju sa**
   *diagramy případů užití
   *detaily případů užití
@@ Řádek 22: / Řádek 109: @@
   *slovníky pojmů
-**Diagramy případů užití (use case diagram)**
+== Diagramy případů užití ==
-Znázornnují hranice systému, jeho účastníky, interakci mezi nimi a akce, které mohou provádět.
+  * **Info**
+  * Používají se pro zachycení požadavků – případů užití a jejich účastníků.
+  * Každý případ užití má svůj název, jednoznačný identifikátor a specifikaci.
+  * Znázorňujú hranice, účastníkov, interakcie medzi aktérmi a prípady použitia
+  * Zobecniť môžeme
+    * zobecnění účastníka = student,ucitel > uzivateľ
+    * zobecnění případu užití = najdiCD, najdiKnihu > najdiProdukt
+  * relace «include»
+    * tato relace vyjadřuje situaci, kdy jeden případ užití zahrnuje v sobě jeden či více jiných případů užití.
+    * vložený případ se musí vždy použít
+  * relace «extend»
+    * Tato relace vyjadřuje situaci, kdy jeden případ užití může rozšiřovat funkcionalitu jiných případů užití.
+    * Oproti relaci include, případ v relaci extend je nepovinný.
-{{:temata:31-uml:clipboard04.jpg|}}
+{{ :temata:31-uml:clipboard04.jpg }}
-**detaily případů užití**
+== Detaily případů užití ==
-Slouží pro konkretizaci jednotlivých případů užítí. Neexistuje standard zobrazeni, ale používá se tabulka, která obsahuje vstupní podmínky, výstupní podmínky a tok událostí.
+  * **Info**
+  * Samotné diagramy případů užití pouze ukazují, jaké akce je možné v systému vykonávat a kdo je může vykonávat.
+  * V mnoha případech je však tato informace málo konkrétní, nedá se z ní poznat co vše se děje a za jakých podmínek.
+  * Pro konkretizaci (specifikaci) případu užití existuje Detail případu užití.
+  * Každá specifikace případu užití má své vstupní podmínky, tok událostí a výstupní podmínky.
+  * Pro jeho zobrazení neexistuje standard, většinou se však používá tabulka
-{{:temata:31-uml:clipboard01.jpg|}}
+{{ :temata:31-uml:clipboard01.jpg?400 }}
-===2. Analýza===
+=== 2. Analýza ===
+  * **Vyuzivaju sa:**
   *diagramy analytických tříd
   *realizace případů užití (diagramy interakce)
@@ Řádek 41: / Řádek 147: @@
   *objektové diagramy
-**Analytické třídy**
+== Analytické třídy ==
+  * **Info**
+  * mapují pojmy problémové domény na abstraktní entity modelu – třídy.
+  * není návrhová třída, tj. analytická třída slouží pouze pro identifikaci entit v řešené problematice a vztahů mezi nimi
+  * Během etapy návrhu jsou analytické třídy upřesňovány do jedné či více návrhových tříd.
+  * Obsahuje
+    * jen nejpodstatnější atributy a operace
+    * minimální množinu odpovědností
+    * minimum vazeb na jiné (analytické) třídy
+{{ :temata:31-uml:analyticke.png?400 }}
+== Objektove diagrami ==
+  * **Info**
+  * Objektové diagramy patří mezi diagramy dynamické.
+  * Zachycují konkrétní instance tříd a jejich vazby v určitém čase či podmínce
+  * Vazby mezi objekty se mohou v průběhu měnit
+{{ :temata:31-uml:ads.jpg }}
+== Analytické balíčky ==
+  * **Info**
+  * souvisejí s dekompozicí problému
+  * umožňují souběžnou práci na více částech (balíčcích) v etapě návrhu
+  * seskupují sémanticky související elementy a definují hranice tohoto seskupení.
+  * Více balíčků můžeme řešit souběžně.
+    * poskytuje zapouzdření prostoru jmen
+    * definuje viditelnost zapouzdřených elementů
+  * mohou obsahovat:
+    * případy užití
+    * analytické třídy
+    * realizace případů užití
+    * další balíčky
+{{ :temata:31-uml:balicky.png?400 }}
+==Diagramy interakce - Diagram spolupráce==
+  * **Info**
+  * Diagramy interakce zahrnují
+    * diagramy spolupráce, které zdůrazňují strukturálí relace mezi objekty
+    * sekvenční diagramy které zdůrazňují časově orientovanou posloupností předávání zpráv mezi objekty, bývají přehlednější.
+{{ :temata:31-uml:spoluprace.png?400 }}
+== Diagramy interakce - Sekvenční diagramy==
+  * **Info**
+  * Reprezentují časově orientovanou posloupnost předávání zpráv mezi objekty
+  * bývají přehlednější než diagramy spolupráce
+  * uživatelé (zákazník) jim lépe porozumí.
+  * Ukončení života objektu je znázorněno křížem na konci časové osy objektu
+  * umožňují definovat omezení (constraints) či význačný stav objektu.
+{{ :temata:31-uml:aa.jpg }}
+== Diagramy aktivit ==
+  * **Info**
+  * Diagramy aktivit reprezentují OO diagramy toků a lze je připojit k libovolnému modelovanému elementu (třída, balík, apod.)
+  * Diagram aktivit je zvláštním případem stavového automatu, který je určen především na modelování manažerských procesů.
+  * Diagram aktivit obsahuje počátek a konec, stavy aktivity a přechody mezi stavy.
+{{ :temata:31-uml:sda.jpg }}
+===3. Návrh===
+  * **Vyuzivaju sa**
+  * analytických třídy
+  * stavové diagramy
+  * návrhové podsystémy
+==Návrhové třídy==
+  * **Info**
+  * Specifikace návrhových tříd je na takovém stupni, že je lze přímo implementovat.
+  * Jedná se o upřesnění analytických tříd.
+  * Využití tříd z doménového řešení (knihovny, vrstva aplikačního serveru, GUI, . . . ).
+{{ :temata:31-uml:navrhove.png?400 }}
+==Stavové diagramy==
+  * **Info**
+  * stavové automaty
+  * speciálni případ stavového automatu je diagram aktivit (modelování manažerských procesů, účastní se více objektů)
+  * stavový diagram – modelování životního cyklu jednoho reaktivního objektu
+  * **Reaktivní objekt**
+  * reaguje na vnejší události
+  * životní cyklus je modelován jako řada stavů, přechodů a událostí.
+  * Chování je důsledkem předchozího chování (následný stav závisí na aktuálním stavu).
+  * Stavové diagramy mohou modelovat dynamické chování reaktivních objektu:
+    *třídy
+    *případy užití
+    *podsystémy
+    *systémy
- mapují pojmy problémové domény na abstraktní entity modelu – třídy. Analytická třída není návrhová třída, tj. analytická třída slouží pouze pro identifikaci entit v řešené problematice a vztahů mezi nimi. Během etapy návrhu jsou analytické třídy upřesňovány do jedné či více návrhových tříd.
+{{ :temata:31-uml:dasa.jpg?300 }}
-Analytická třída
-  *obsahuje jen nejpodstatnější atributy a operace
-  *obsahuje minimální množinu odpovědností
-  *obsahuje minimum vazeb na jiné (analytické) třídy
-**Analytické balíčky**
+===== Potvrzení =====
-Analytické balíčky souvisejí s dekompozicí problému – umožňují souběžnou práci na více částech (balíčcích) v etapě návrhu. Analytické balíčky seskupují sémanticky související elementy a definují hranice tohoto seskupení. Více balíčků můžeme řešit souběžně. Balíček také poskytuje zapouzdření prostoru jmen (tj. názvy elementů musí být v rámci balíčku jedinečná, mezi balíčky však může docházet k duplicitám) a definuje viditelnost zapouzdřených elementů – veřejné (public), soukromé
+<doodle single login|31>
-(private) a chráněné (protected). Analytické balíčky mohou obsahovat
+^ OK ^ !!! ^
-  *případy užití
+</doodle>
-  *analytické třídy
-  *realizace případů užití
-  *další balíčky
-**Diagramy interakce**
+{{tag>george IUS2}}
+~~DISCUSSION~~

temata/31-uml/main.1300543152.txt.gz · Poslední úprava: 2011/03/19 14:59 autor: sgs

Zobrazit stránku Starší verze

Zpětné odkazy Nahoru