1
Slezská univerzita v Opavě, FPF Podklady k přednáškám
Studijní obor: IVT Ročník: IV.
Předmět: Projektování IS
Téma: Objektový přístup k vývoji IS (část B)
Vyučující: dr. Dušan Kajzar Školní rok: 2020/2021
Obsah:
1. Diagram tříd (Class Diagram).............................................................................. 2
2. Diagram tříd ve fázi návrhu............................................................................... 19
3. K postupům tvorby diagramu tříd...................................................................... 21
4. Objektový diagram (Object Diagram) ............................................................... 23
5. Diagram kompozitní struktury (Composite Structure Diagram) ....................... 24
6. Diagram balíčků (Package Diagram)................................................................. 26
Kde se nacházíme ?
Obrázek: Schéma modelů objektově orientované analýzy a návrhu IS
Zobrazení struktury systému Zobrazení chování systému
Diagram případů užití
(Use Case Diagram)
Diagram tříd
(Class Diagram)
Diagram stavů
(State Diagram)
Diagram činností - aktivit
(Activity Diagram)
Diagram komponent
(Component Diagram)
Diagram nasazení
(Deployment Diagram)
Diagram objektů
(Object Diagram)
Diagram balíčků
(Package Diagram)
Sekvenční diagram
(Sequence Diagram)
Diagram spolupráce
(Collaboration Diagram)
Diagram přehledu interakcí
(Interaction Overview)
Diagram časování
(Timing Diagram)
Composite Structure
Diagram
Implementační modely
Diagramy interakcí
2
1. Diagram tříd (Class Diagram)
Účel modelu:
 zobrazit vnitřní strukturu systému,
 třídy (objekty) - jejich vlastnosti a vztahy.
Základní pojmy:
 objekt
o konkrétní prvek systému,
o jednoznačně identifikovatelná entita obsahující data + operace s daty,
o součástí objektu - identifikátor, vlastnosti (data), chování (operace),
 třída
o kategorie (zobecnění skupiny) objektů,
o stejné či podobné vlastnosti a chování,
o obsahuje atributy a popis operací (metod),
 vtah třídy a objektu
o třída je „šablona“ k vytváření objektů,
o objekt je konkrétním prvkem dané třídy,
o objekt je instancí (tj. konkrétním výskytem) dané třídy,
o „objekty jsou dělníci systému – vykonávají všechny činnosti“,
o „navrhujeme třídy, pracují však objekty“,
 atributy třídy (objektu)
o položky popisující vlastnosti objektů (charakteristiky),
o hodnoty atributů (stálé a proměnlivé),
 operace (resp. metody) třídy (objektu)
o algoritmy popisující aktivity (akce a reakce) objektu,
 vazby mezi třídami (resp. mezi objekty)
o objekt třídy A může použít operaci či hodnotu objektu třídy B,
o asociace – vazby mezi třídami,
o linky – vazby mezi objekty.
3
Třída v jazyce UML:
Obrázek: Základní grafické znázornění třídy
Obrázek: Grafické znázornění třídy s oddíly
Názvosloví „operace a metoda“:
 názvosloví v literatuře není zcela jednotné (starší, novější),
 v etapě analýzy
o hovoříme o operacích (abstraktní specifikace algoritmu),
 v etapě návrhu
o hovoříme o metodách (konkrétní implementace),
 metoda – je implementací operace,
 operace – může být implementována jednou nebo i několika metodami.
Doplnění podrobností popisu třídy:
 doplnění tzv. adorments (ozdoby),
 analytická úroveň --> návrhová úroveň zobrazení,
 detaily rozpracováváme v závislosti na účelu diagramu,
 např. podrobný popis atributů třídy:
o viditelnost název : typ [násobnost] = počáteční hodnota,
 podrobnosti mohou být implementačně závislé na cílovém jazyce.
Pračka
Pračka nebo
Pračka
značka
typ
série
kapacita
vloženíPrádla()
nastaveníProgramu()
....
atributy
operace (metody)
název třídy
metoda
metoda
...
operace
4
Objekt v jazyce UML:
 popis atributů objektu - název: datový typ = hodnota,
 stav objektu - je určen hodnotami jeho atributů.
Obrázek: Grafické znázornění objektu
Anonymní objekt:
Obrázek: Libovolný (anonymní) objekt třídy „Pračka“
Relace (vztah) „třída -> objekt“:
 říkáme, že objekt je instancí (konkrétním výskytem) dané třídy,
 <<instantiate>> - jedná se o speciální případ relace závislosti,
 objekt „dědí“ atributy a operace (metody) dané třídy,
 atributy objektu nabývají konkrétních hodnot.
Obrázek: Vztah třída - objekt dané třídy
mojePračka : Pračka
značka = Romo
typ = 842.1R
série = A236985458
kapacita = 5 kg
mojePračka : Pračka
značka: String = „Romo“
typ: String = „842.1R“
série: String = „A236985458“
kapacita: Integer = 5 (kg)
:Pračka :Pračkanebo jednodušeji
JanHoráček : Student
<<instantiate>>
Student
5
Tři pilíře objektového programování:
 dědičnost,
 polymorfismus,
 zapouzdření.
Dědičnost a hierarchie tříd:
 jde o vztah generalizace a specializace mezi třídami,
 vzniká vztah nadtřída a podtřída,
 potomci (podtřídy)
o dědí - atributy, operace, relace, omezení,
o mohou – přidávat charakteristiky, stávající předefinovat.
Obrázek: Grafické znázornění vztahu zobecnění (resp. dědičnosti)
K použití dědičnosti:
 myšlenkové procesy - zobecnění (generalizace) a specializace,
 jde o vztah mezi obecnějším prvkem a prvkem přesněji specifikovaným,
 jde o vysoký stupeň závislosti mezi prvky,
 platí zákon o nahraditelnosti
o obecnější prvek lze nahradit speciálnějším typem,
o spec. typ má tytéž atributy a metody, může mít i další navíc,
 platí různá pravidla a doporučení, např.
o podtřídy by neměly reprezentovat role, nýbrž speciální druh třídy,
o podtřída „je druhem“ (čeho) – nikoliv „je rolí“ (jiným stavem téhož),
 dědění od více předků – podporováno pouze v C++.
Zaměstnanec
Učitel SprávníZaměstnanec
6
Polymorfismus (mnohotvárnost):
 potomci mohou změnit definici zděděných operací,
 polymorfní operace - mají více implementací,
 díky polymorfismu - objekty různých tříd mohou reagovat na stejné zprávy
různým způsobem.
Obrázek: "Překrytí" operace zavřít() ve třídě TC
K polymorfismu operací:
 překrývání operací je nutné u abstraktních operací (viz dále),
 překrývání konkrétních operací se obecně považuje za špatné (!)
o v podstatě tím ignorujeme existující implementaci,
o otázka bezpečnosti (skryté vedlejší efekty),
 uznávaný způsob překrytí operace
o pokud daná operace zavolá operaci nadtřídy a pak vykoná něco navíc
(přidá vlastní chování),
 v jazyce Java
o klíčové slovo „final“ - zamezení překrytí operace u potomků (!)
TA
zavřít()
TB
zavřít()
TC
zavřít()
O2 : TCO1: TB
7
Zapouzdření atributů a operací:
 ukrytí atributů resp. operací uvnitř objektu,
 „neviditelné“ zvenku.
Obrázek: Soukromé a veřejné prvky objektu
Viditelnost atributů a operací (metod):
 + ... public - viditelné veřejně,
 - ... private - veřejně neviditelné,
 # ... protected - viditelné pouze pro nejbližší podtřídy dané třídy,
 ~ ... package - viditelné pouze v rámci tříd téhož balíčku,
 viditelnost je implementačně závislá vlastnost (C++, Java, VBasic, C#, ...).
Obrázek: Zobrazení viditelnosti atributů a operací
Televizor
+ značka:
+ program:
- vysílač:
+ zapnout()
+ vypnout()
- kalibrace()
+ program()
.....
Poznámka:
např. doplnění
popisu atributů
soukromé atributy a jejich hodnoty
(soukromá data objektu)
soukromé operace
veřejné operace
veřejné atributy a jejich hodnoty
(veřejná data objektu)
objekt A
8
Vazby (relace) mezi třídami a objekty:
 zasílání zpráv - volání veřejné operace jiného objektu,
 mezi třídami - asociace,
 mezi objekty - linky.
Obrázek: Grafické znázornění vazby mezi třídami a mezi objekty
Znázornění průchodnosti relace:
Role v asociaci:
Obrázek: Grafické znázornění rolí v asociaci
Více asociací mezi třídami:
Obrázek: Grafické znázornění dvou asociací mezi třídami
hraje za
Hráč Mužstvo
hraje za
J. Novák Spartak Vlkovice
zaměstnavatelzaměstnanec
pracuje pro
Programátor Vývojová firma
zaměstnanec zaměstnavatel
zaměstnává
pracuje proProgramátor
zaměstnanec zaměstnavatel
Vývojová firma
A B
X
9
Omezující podmínky v asociaci:
Obrázek: Grafické znázornění omezení v asociaci
Násobnost (kardinalita) asociace:
Obrázek: Grafické znázornění vztahu 1:1
Povinnost, volitelnost vazeb:
 vazba povinná a volitelná,
 viz přehled výše – 1 : 0..*, 1 : 1..*
{v pořadí}
obsluhujeProdavač Zákazník
{nebo}
použije k cestě
Nákupčí
Služební autopoužije k cestě
Veřejný prostředek
11 vlastníZaměstnanec Sl.průkaz
1 * znamená 1:M
1 3 znamená 1:3
1 1..* znamená 1:1 nebo 1:M
1 0..* znamená 1:0 nebo 1:M
1 0,1 znamená 1:0 (volitelná vazba) nebo 1:1
1 12..18 znamená 1:12 až 1:18
1 3..7, 10..12 znamená 1: (3 až 7), nebo 1: (10 až 12)
* * znamená M:N
10
Kvalifikovaná asociace:
Obrázek: Kvalifikovaná asociace
Kvalifikátory asociací:
 specifikují jedinečný objekt (z množiny objektů) cílové strany,
 znázorňují způsob vyhledávání konkrétního objektu cílové strany,
 hodnota kvalifikátoru (např. „ID člena“) určuje jednoznačně daný objekt
(jednoznačný klíč).
N-ární asociace (stupeň asociace):
 asociace binární – viz ukázky výše,
 asociace unární (reflexivní), ternární.
Obrázek: Unární (reflexivní) asociace
Obrázek: Ternární asociace
*1 je navštěvovánKlub ČlenID člena
veze
1..5
1
cestující
řidič
Uživatel auta
vyzvedává si
1 1
1
Návštěvník Kabát
Šatna
*1 je navštěvovánKlub Člen
11
Poznámka k n-árním asociacím (pro n>=3):
 v diagramu tříd návrhové úrovně - převést na binární asociace.
Asociační třída:
 převádí vazbu M:N na dvě vazby 1:M,
 např. Firma (M) – (N) Osoba,
 na ... Firma (1) – (M) Smlouva (N) – (1) Osoba,
 jde o konstrukci analytické úrovně zobrazení diagramu tříd,
 v diagramu tříd návrhové úrovně – nahradit klasickou třídou.
Obrázek: Grafické znázornění asociační třídy
Obrázek: Převod asociační třídy na klasickou třídu a dvě relace
Abstraktní třída:
 obsahuje aspoň jednu abstraktní operaci
o tj. operaci bez konkrétní implementace,
o bez algoritmu provedení,
 v tomto smyslu je třída neúplná
o instance (objekty) takové třídy nelze vytvořit (!),
 slouží pouze k odvozování podtříd (potomků),
o s tím, že algoritmy operací se popíší až u jednotlivých typů potomků,
má smlouvu
uzavřená s
Programátor Vývojová firma
Smlouva Vedoucí
* *
*
Smlouva
RodCislo
IČOFirmy
Číslo smlouvy 1
1
Vývojová firma
Vedoucí
* 1
Programátor
*
12
 jde o určitý druh dohody mezi rodičem a potomkem,
o kterou konkrétní potomci musí implementovat,
o tj. dodržet název operace, parametry a typy jejich hodnot, typ návratové
hodnoty, ...
 označení abstraktní třídy
o název třídy – kurzívou,
o nebo popisem <<abstract>>.
Obrázek: Grafické znázornění abstraktní třídy "Třída A"
Abstraktní operace třídy:
 nemají implementaci, slouží jako „držitelé prostoru“,
 implementace operace je přenechána potomkům třídy,
 označení abstraktní operace – kurzívou,
 např. nakreslitTvar(), urcitObsah() ... pro čtverec, kruh, trojúhelník,
 nebo vypocetUroku() ... pro různé druhy účtů apod.
Konkrétní třída:
 musí implementovat všechny zděděné abstraktní operace.
Závislost mezi třídami:
 vazba mezi dvěma prvky, v níž změna jednoho prvku (dodavatele) se promítá
do druhého prvku (klienta),
Třída A
Třída B Třída C
Abstraktní
třída
dodavatel funkcionalityklient (uživatel funkcionality)
SystémX
zobrazOkno()
Okno<< use >>
Operace třídy SystémX potřebuje hodnotu z třídy Okno
13
 klient (uživatel dodávané funkcionality) do určité míry závisí na dodavateli,
 základní typy závislosti
o užití (use) - klient využívá některou službu či hodnotu dodavatele,
o abstrakce - dodavatel je určitým zobecněním klienta,
o oprávnění - dodavatel uděluje klientovi oprávnění k něčemu.
Agregace tříd:
 vyjadřuje vztah „je částí“,
 jeden objekt (celek) využívá služeb jiných objektů (svých součástí),
 součást poskytuje služby, reaguje na požadavky celku,
 celek ví o svých součástech, ale součást nemusí vědět nic o celku.
Součást agregace:
 může existovat ve více celcích,
 může existovat nezávisle na celku,
 objekt nemůže být součástí sama sebe (přímo ani nepřímo).
Tranzitivnost agregace:
 relace agregace je tranzitivní.
0..*1PrintServer Tiskárna
1111
Počítač
Klávesnice Myš Skříň PC Monitor
1
A B C
14
Omezení v agregaci:
Obrázek: Omezení agregace - vztah "nebo"
Kompozice (silná agregace):
 každá součást patří jen jednomu celku,
 součást kompozice nemůže existovat mimo celek,
 např. „strom a jeho listy“,
 celek má výhradní odpovědnost za své součásti,
 je-li celek zrušen
o musí zrušit i své součásti,
o nebo je převést k jinému celku.
Obrázek: Kompozice - složenina
Kompozice a atributy třídy:
 prvky kompozice v podstatě odpovídají atributům třídy,
 atributy třídy lze chápat jako vztah kompozitní relace,
 doporučení – primitivní nebo jinak nezajímavé kompozitní prvky redukovat
na atributy třídy celku.
{nebo}
Sestava S
Složka A Složka B Složka C Složka D
0..*
1
A
B
Kniha
Obal Listy
1
1 0..*
15
Kontext (vyznačení kontextu prvků):
 seskupení logicky souvisejících prvků,
 jde o vyznačení užší logické souvislosti prvků.
Obrázek: Seskupení tříd – znázornění kontextu
Vnořená třída:
 je deklarována uvnitř jmenného prostoru obklopující třídy,
 instance vnořených tříd mohou být vytvářené instancí vnější třídy,
 využití v oblasti návrhu – jak má být nějaká funkce implementována.
Obrázek: Znázornění vnořené třídy MouseEvent
Obrázek: Znázornění vnořené třídy pomocí kotvy
Třída 1 Třída 2
Třída 3
Třída 4
Třída 5
kontext K
Frame MouseEvent
Frame
MouseEvent
16
Rozhraní (interface):
 pojmenovaná třída veřejných operací,
 tj. operací (metod), které zpřístupňujeme jiným třídám.
Obrázek: Rozhraní – zápis ve formě třídy
Obrázek: Rozhraní - zápis ve formě „lízátka“
Vlastnosti rozhraní:
 definuje služby poskytované danými třídami,
 jiné třídy využívají těchto operací ve vztazích k daným třídám,
 deklaruje kontrakt k určeným třídám, který má být realizován,
 definuje signaturu a sémantiku operací, jejich omezení, parametry
(ale nic více),
o odděluje tak specifikaci funkčnosti od implementace,
o nespecifikuje žádnou formu implementace,
 je základem pro komponentovou tvorbu systému,
 pokud jazyk nepodporuje rozhraní – použijte abstraktní třídu.
Obrázek: Zpřístupněné a požadované rozhraní
Dodací list
Evidence
Faktura
Objednávka
<< rozhraní >>
Evidence
zaeviduj ()
vytiskni ()
....
Dodací list
Faktura
Objednávka
A
rozhraní pro přístup
ke třídě A
napojení na jiné
rozhraní
17
Obrázek: Využití služeb rozhraní
Využití služeb rozhraní:
 třídy Objednávka, Dodací list, Faktura
o nabízejí služby třídě SprávceDokladů,
 třída SprávceDokladů
o „rozumí“ protokolu definovanému rozhraním „Evidence“,
o „ví“, že tyto položky lze zaevidovat, vytisknout, ...
Realizace (implementace) rozhraní:
 realizace – konkrétní vztah mezi třídou a jejím rozhraním,
 jde o implementaci dohody, která je předepsána rozhraním,
 rozhraní musí být realizováno (implementováno) těmi třídami, které dané
rozhraní vystavují (v našem příkladu - Objednávka, DodacíList, Faktura).
Obrázek: Vazba subsystémů přes rozhraní
Hledání rozhraní:
 vyčlenit skupiny operací, které by šlo použít i jinde, které se opakují ve více
třídách, mají v systému stejnou roli,
 hledat závislosti mezi komponentami – zvážit řešení přes rozhraní.
<<subsystém>>
Grafické
prostředí
Správce
Zákazníků
Správce
Účtů
Správce
Dokladů
<<subsystém>>
Aplikační
logika
Evidence
SprávceDokladů
Objednávka
Dodací list
Faktura
18
Přehled probraných vazeb mezi třídami (od nejtěsnější počínaje):
 dědičnost,
 kompozice,
 agregace,
 závislost,
 běžná asociace.
Stereotypy (významové popisy):
 např. <<rozhraní>>, <<use>>, ...
 slouží k popisu grafických prvků
o větší názornost,
o resp. jde o nové prvky vzniklé na základě grafických znaků UML.
Šablony (template):
 umožňují tvorbu parametrizovaných tříd - tříd s parametry,
 např. několik různých tříd se liší pouze v datových typech atributů,
v typech návratových hodnot operací apod.,
 pak lze využít třídu s parametry
o tj. místo uvedení skutečných typů atributů, typů návratových hodnot
operací apod.
o -> uvedeme parametry (zástupné symboly),
 parametry jsou při vytvoření třídy nahrazeny skutečnými hodnotami,
 podporováno pouze v C++.
19
2. Diagram tříd ve fázi návrhu
Analytický a návrhový model:
Obrázek: Mezi analytickým a návrhovým modelem je vztah závislosti
Poznámka:
 srovnejte s 3-úrovňovou architekturou zobrazení systému,
 koncepční, logická (technologická), fyzická (implementační).
Během fáze návrhu upřesňujeme:
 popisy tříd (adorments – „ozdoby“),
 popisy relací (asociací) mezi třídami (násobnost, role, volitelnost, ...),
 převody:
o n-ární relace (n>=3) --> binární,
o asociační třídy --> třídy, ...
 úprava konstrukcí, které programovací jazyk podporuje (resp. nepodporuje).
Doplnění tzv. návrhových tříd:
 fáze tvorby analytických tříd --> fáze tvorby návrhových tříd,
 návrhové třídy lze získat:
o z problémové domény – např. rozklad analytické třídy na několik
podrobných tříd návrhových,
o z domény řešení - třídy pro uchování mezivýsledků, protokolování akcí
uživatelů, ...
 návrhová třída obsahuje:
o kompletní sadu atributů – název, typ, implicitní hodnoty, viditelnost,
o převod operací specifikovaných v analytické třídě na úplnou sadu metod.
<<trace>>Analytický
model
Návrhový
model
20
Zásady pro návrhové třídy:
 úplnost, jednoduchost, soudržnost, minimalizace vazeb na jiné třídy
(bez těsných vazeb),
 snažit se o omezení množství relací mezi třídami,
 těsné vazby mezi třídami balíčku jsou v pořádku (soudržnost balíčku).
Upřesnění asociací v návrhovém modelu:
 asociace 1:1
o vyjadřují silný vztah mezi třídami,
o mohou vyjadřovat kompozici s vazbou „celek : část“ = „1:1“,
o uvažujeme i o sloučení do 1 třídy resp. i o atributu třídy,
 asociace M:1
o mohou vyjadřovat agregaci „celek (M) – součást (1)“,
o tj. součást může být zahrnuta ve více celcích,
 asociace 1:N
o možné použití pole,
o resp. třídy kolekce (obsahují metody pro práci s prvky kolekce),
o nezdokonalujte zbytečně relace typu 1:N – přenechejte to programátorům,
 asociace typu M:N
o převod do normálních tříd, agregací, kompozic resp. závislostí,
o převod na dvě asociace typu 1:N,
 obousměrné asociace
o převod do dvou jednosměrných (asociací, agregací, kompozic, závislostí),
 asociační třídy
o nemají podporu v žádném programovacím jazyce,
o převod do podoby normální třídy,
 kolekce prvků
o možný popis v jazyku OCL (Object Constraint Language),
o Bag – unordered, nonunique,
o Set – unordered, unique,
o OrderedSet – ordered, unique,
o Sequence – ordered, nonunique.
21
Doporučení k informační hodnotě modelu:
 dbát na čitelnost modelu,
 většina diagramů není určena pro ty, kteří je vytvářejí,
 číst model – tak, jak je skutečně napsán (!).
3. K postupům tvorby diagramu tříd
Rámcový postup tvorby diagramu tříd:
1) identifikace základních tříd + základních atributů a metod,
2) průběžná tvorba slovníku dat – popis prvků a jejich významu,
3) identifikace vazeb - asociací, agregací, operací,
4) doplňování - dalších tříd, atributů a metod tříd, vazeb,
5) vytvoření hierarchie tříd,
6) ověřování úplnosti modelu
o Skutečně řeší tento model požadované úkoly? Nechybí v něm něco? ...
o obdobně jako např. ověření úplnosti ERD (viz tam),
7) upřesňování modelu pomocí iterací,
8) seskupení tříd do SW modulů.
Metody (techniky) hledání tříd:
 analýza textu (podstatná jména, slovesa),
o podstatná jména v zápise zadání – jsou kandidáty na třídy nebo atributy,
o slovesné fráze – jsou kandidáty na operace nebo asociace,
 odpovědnost tříd (k čemu třída slouží) => vazby mezi třídami,
o metoda CRC (Class, Responsibilities, Collaborators),
o metoda RUP – pomocí stereotypů boundary, control, entity.
22
Štítek metody CRC:
Pomocný diagram odpovědností tříd:
 tj. znázornění spolupráce třídy A s jinými třídami při plnění úkolů.
Shrnutí doporučeného postupu tvorby diagramu tříd:
 vycházíme ze zápisu požadavků na vyvíjený IS (ze specifikace IS),
 provádíme tzv. analýzu textu specifikace zadání IS,
 podstatná jména v zápise - představují kandidáty na třídy a atributy,
 slovesné fráze - jsou kandidáty na operace, asociace, agregace,
 souběžně s vytvářením diagramu tříd - i potřebné popisy (slovník dat),
 průběžně doplňujeme popis tříd - další atributy a operace,
 třídy seskupujeme - vytváříme hierarchii tříd,
 tvorba diagramu tříd - probíhá iteračním postupem,
o celý diagram tříd doplňujeme a upravujeme,
o i pomocí informací z dalších souběžně vytvářených modelů,
o až do návrhové úrovně zobrazení,
 ověříme úplnost diagramu tříd
o „Bude IS vytvořený dle daného modelu řešit požadované úkoly?“
Název třídy: BankovníÚčet
Odpovědnosti:
- udržovat zůstatek
- ....
Spolupracovníci:
Banka
Referent
....
Třída A
Odpovědnost za
úkol č. 1
Odpovědnost za
úkol č. 2
Odpovědnost za
úkol č. 3
Třída B
Třída C
Třída D
Třída E
Třída F
23
4. Objektový diagram (Object Diagram)
Charakteristika diagramu:
 v podstatě jde o snímek části běžícího systému v konkrétním okamžiku,
 jsou v něm zachyceny aktuální objekty a vazby v daném okamžiku.
Obrázek: Fragment diagramu tříd
Obrázek: Fragment objektového diagramu
členčlen
předseda
sekretářka
čajovnaOrion : StudentskýKlub Jarda : Osoba
Tomáš : OsobaMirka : OsobaDalibor : Osoba
je členemStudentskýKlub Osoba
24
5. Diagram kompozitní struktury (Composite Structure Diagram)
Diagram kompozitní struktury (Composite Structure Diagram):
 slouží ke znázornění vnitřní struktury strukturovaných klasifikátorů,
 strukturované klasifikátory - agregace, kompozice, strukturované třídy.
Jednoduchý příklad agregace a kompozice:
Příklad složitější kompozice:
 zobrazena v Diagramu tříd,
 podle Arlow, Neustadt: UML2 a unifikovaný proces vývoje aplikací.
Kniha
Obal Listy
1 111
Počítač
Klávesnice Myš Skříň
PC
Monitor
vypůjčovatelé
10..*
11
0..*zápůjčky katalog0..*
zapůjčenáKniha
0..*
Zápůjčka
Vypůjčovatel Knihovník
VypůjčovatelStudent VypůjčovatelZaměstnanec
1
1..*1
[max. počet
vypůjčených knih = 4]
[max. počet
vypůjčených knih = 8]
[přihlášen nejvýše
1 knihovník]
VedoucíKnihovny
Kniha
25
Příklad složitější kompozice:
 zobrazena Diagramem kompozitní struktury,
 podle Arlow, Neustadt: UML2 a unifikovaný proces vývoje aplikací.
:Vedoucí Knihovny
:Knihovník [1..*]
přihlášenýKnihovník : Knihovník [0..1]
stud. :VypůjčovatelStudent
[0..*]
zam.:VypůjčovatelZaměstnanec
[0..*]
0..* 0..*
stud_Zápůjčka
:Zápůjčka [0..4] 1 1
:Kniha [0..*] zam_Zápůjčka
:Zápůjčka [0..8]
26
6. Diagram balíčků (Package Diagram)
Balíček (Package):
 mechanismus UML pro logické seskupování prvků podle významu
(z hlediska podnikových procesů),
 vytváří vlastní jmenný prostor s jednoznačnými názvy prvků,
 v programovacích jazycích
o Java ... package,
o C# ... namespace,
 balíčky mohou vytvářet hierarchii.
Balíček - seskupování prvků:
 balíčky mohou obsahovat (seskupovat) - třídy, případy užití.
Balíček jako jmenný prostor:
 úplný název prvku – včetně „cesty“,
 název_balíčku_1:: název_balíčku_2:: název_prvku
Knihovní systém
Uživatelé
Knihovník
Pravidla
Vypůjčovatel
Balíček B1
třídy
Balíček B2
případy užití
27
Diagram balíčků (Package Diagram) znázorňuje:
 strukturu vnitřku balíčků,
 a hierarchickou strukturu vazeb mezi balíčky.
Balíčky vnořené:
 je vhodné použít symbol kotvy.
Viditelnost prvků:
 určení, zda prvky jsou viditelné vně balíčku,
 prvek vnitřního balíčku
o vidí veřejné členy vnějšího balíčku,
 prvek vnějšího balíčku
o nevidí žádné členy vnitřního balíčku - pokud na nich není závislý pomocí
<<access>>, <<include>>.
Hierarchie (zobecňování) balíčků:
 odvozené balíčky dědí prvky od svých předků,
 mohou překrývat rodičovské prvky,
 obdobně, jako dědění tříd.
Klub XY
+Údaje
+ČlenKlubu
+Pravidla
-Podmínky
Knihovní systém
Uživatelé
Knihovník
Pravidla Vypůjčovatel
28
Závislost balíčků:
 existuje několik typů závislostí mezi balíčky,
o např. <<use>>, <<import>>, <<access>>, ...
 <<use>>
o prvek klientského balíčku používá veřejný prvek z dodavatelského
balíčku (bez bližší specifikace závislosti),
 <<import>>
o sloučení jmenných prostorů,
o veřejné prvky dodavatele se stanou součástí (veřejnými prvky) jmenného
prostoru klienta,
 <<access>>
o klient má přístup k veřejným prvkům dodavatele,
o jmenné prostory zůstávají oddělené,
 <<trace>>
o znázornění historického vývoje, klient je vyšším vývojovým stupněm
(vyšší verzí) dodavatele – v podstatě jde o relaci mezi modely,
Dodavatel Klient
<< use >>
Dodavatel Klient
<<import >>
Dodavatel Klient
<<access >>
+Cena
+Trh
+Položka
Produkt
Hotel
+Auto
+Položka
...
PůjčovnaAut
+Hotel
+TypPokoje
- ČísloPokoje
29
o např. analytický model <--- návrhový model,
 <<merge>>
o sloučení - obsah klientského balíčku je rozšířen o obsah dodavatele,
o prvky stejného názvu jsou sloučeny (v tzv. rozšířené klientské prvky),
o použití v meta-modelování (modely modelů pro danou řešenou oblast).
Tranzitivita závislostí:
 relace založené na <<import>> jsou tranzitivní,
 relace založené na <<access>> nejsou tranzitivní.
Proces tvorby balíčků:
 proces tzv. architektonické analýzy,
 proces, kterým dělíme logicky související třídy do balíčků,
 následně balíčky rozdělujeme do vrstev (hierarchie),
 cílem je minimalizace vazeb uvnitř modelovaného systému,
minimalizace závislostí mezi balíčky,
 viz obrázek – balíčky obecné vrstvy (SprávaÚčtů, SprávaInventáře)
lze používat v několika různých aplikacích.
Obrázek: Architektonická analýza
Analytický
model
Návrhový
model
<<trace >>
<<.....>> <<.....>>A B C
Prodej Produkty
SprávaÚčtů SprávaInventáře
specifická
vrstva aplikace
obecná vrstva
aplikace
30
Poznámky a doporučení:
 analytické balíčky vytváříme až po určité době vývoje diagramu tříd
o po jeho dozrání, usazení,
 balíčky sdružují sémanticky příbuzné prvky, soudržná seskupení tříd,
 zdroje informací pro tvorbu balíčků jsou
o model případů užití (Use Case diagram)
o a podnikový (business) proces,
 případ užití (funkcionalita systému)
o může mířit skrz několik balíčků,
 dbát na vysokou soudržnost jednotlivých balíčků
o snaha o minimalizaci vazeb mezi balíčky,
o přesouvat třídy, přidávat a odstraňovat balíčky,
 vyhýbat se cyklickým závislostem mezi balíčky
o raději pak sloučit balíčky, vytvořit balíček se společnými prvky,
 udržovat přehledný a srozumitelný model
o omezovat zbytečné vnořování,
o „rozumný“ počet tříd v balíčku.