1
VIKBB38 Teoretické základy
projektování informačních systémů
blok II., KISK FF MU
Jan Matula, jan.matula@fpf.slu.cz
Informační Systém
• systém umožnující komunikaci a transformaci informací časove,
prostorově i co do formy tak, aby byly lépe využity
než v původním stavu (systém, který přidává hodnotu k
zpracovávaným či komunikovaným informacím)
• speciální typ komunikačního média, jehož cílem je
odstranit bariéry v přístupu k informacím
• účelové uspořádání vztahu a informačních toků mezi
informačními zdroji, lidmi a technologickými prostředky
spolu s procesy zpracování a komunikace informací
• model reálného světa, jehož základními prvky jsou
informace
Typické problémy řešené IS
• potřeba informací (pro poznání, pro rozhodování, pro
realizaci určité činnosti)
• složitost (complexity)
• znovu-použitelnost (reusability)
• automatizace
• komunikace
• bezpečnost, spolehlivost, minimalizace rizik…
Obecný model IS
Základní cíle IS
• získávání informací - receptor
• ukládání informací (jejich fixace v prostoru
a čase) - paměť
• transformace (zpracování) informací -
procesor
• přenos informací - efektor
Prvky IS
subsystém 1 – lidé
• tvůrci (autoři) informací
• uživatelé informací (klienti)
• zpracovatelé, správci, zprostředkovatelé informací
subsystém 2 – informace
1. informace jako ekonomický zdroj
• IS jako jeden z pomocných subsystému organizace (instituce, firmy),
zaměřený na podporu její činnosti
• provozovatel: každá obchodní i neobchodní organizace
2. informace jako komodita (zboží)
• IS jako "produkční" systém organizace (instituce, firmy), jejímž
základním produktem či službou jsou informace (v tom případe i tato
organizace musí mít vlastní IS zaměřený na podporu vlastního řízení)
• provozovatel: sektor informačních služeb, informační průmysl
Prvky IS
subsystém 3 - prostředky umožňující práci s
informacemi (informační infrastruktura)
• jazyky
• informační a komunikační technologie (hardware počítače
a periférie, sítové prvky, software)
• pracovní postupy, techniky a metody
• materiální zabezpečení (budovy...)
Typy IS z hlediska zpracování informací
Životní cyklus IS – viz. obr.
Automatizovaný IS
• informační systém fungující s podporou
informačních a komunikačních technologií
• automatizace procesu
• digitalizace datové základny
Typy IS
1. Informacní systémy organizací (informace jako
ekonomický zdroj)
podnikové informační systémy (BIS - business information
system, enterprise information system)
2. Veřejné informační systémy (informace jako
ekonomická komodita)
TV, rozhlas, tisk, zpravodajské agentury, knihovny,
informační instituce
Typy IS
3. Státní informační systém
informační systémy státní správy a samosprávy, informační
systémy veřejné správy (GIS - government information
system)
4. Osobní informační systém
informační systém jednotlivce
IS organizací
Podnikový informační systém
• informační systém, provozovaný v kontextu konkrétní
organizace
• účel: správa informací a znalostí a jejich integrace do
podnikových procesu za podpory informacních a
komunikačních technologií
• obsažené informace jsou chápány jako jeden z
ekonomických zdrojů (aktiv) organizace
IS organizací
1. podpora řídících a administrativních funkcí (slouží
vnitřním funkcím organizace)
• řízení: definování strategických cílů, plánování, příprava
rozpočtu
• administrativa: správa a optimalizace firemních zdrojů zaměstnanců
a jejich činností, inventářů materiálu,
přístrojů a vybavení, prostor, financí
1. podpora řídících a administrativních
funkcí
• systémy na podporu provozu (chodu) firmy - provozní,
transakcní IS - ERP - enterprise resources planning
• systémy na podporu rozhodování - MIS - management
IS, EIS - executive IS, BI - business intelligence
• systémy na podporu plánování - APS - advanced
planning and scheduling, SCM - supply chain
management, HR - human resources
• systémy řízení vztahů se zákazníky - CRM - customer
relationship management
2. podpora činností a služeb organizace
(podporují účel, kvůli kterému organizace
existuje)
• CA (computer aided) technologie (CAD, CAM, CIM, CASE...)
• e-byznys
• kancelářské systémy (office automation)
• systémy pro tvorbu a správu dokumentu (DTP - desktop
publishing, DMS - document management system)
• workflow management
• automatizované knihovnické systémy, dokumentografické
systémy
• expertní systémy
• GIS - geografické informacní systémy
Vývojová klasifikace IS
Typologie IS
Průzkumové IS (Information Retrieval Systems)
definované jako množinu lidí, technologií a procedur
(software), které pomáhají vyhledávat údaje, informace a
poznatkové zdroje
lokalizované částečně v knihovnách nebo mimo ně.
Informace o dostupných zdrojích jsou získávány, ukládány,
vyhledávány a zpřístupňovány dle potřeb
uživatelů.
Typologie IS (pokračování)
Informační systémy pro podporu rozhodování
(Decision Support Systems)
jsou systémy se specifickými funkcemi orientovanými na
pomoc manažerům při řešení problémů a v rozhodovacích
procesech. Zahrnují lidi, procedury, software a účelové
databáze.
Pomáhají identifikovat faktory, které vytváří
problémy; poskytují možné cesty řešení problémů;
pomáhají vybírat možnosti, které jsou k dispozici k řešení
problémů.
Obr. DSS
Typologie IS (pokračování)
Expertní systémy (Expert Systems)
jsou specifickým druhem informačních systémů, které
pomoci software poskytují služby, které se očekávají od
expertů. Jsou naprogramované imitovat myšlenkové
postupy expertů a připravit návrhy rozhodnutí na výběr
nejlepších partikulárních řešení problémových situací.
Typologie IS (pokračování)
Manažerské informační systémy
(Management Information Systems)
zahrnují lidi, technologie a procedury, které slouží na
organizační plánování, operační a řídící přístup a využívání
lidských a materiálních zdrojů.
Obr. MIS
Typologie IS (pokračování)
Systémy na přímé řízení technologických procesů.
Jsou to systémy pracujíce v on-line-real-time (OLRT)
režimu určené na přímé řízení technologických procesů,
např. prostřednictvím NC strojů (numeric control)
připojených na počítače.
Integrováním přímého řízení procesů s organizací výroby,
zásobovaní a expedice vznikají integrované výrobní
informační systémy (Computer Integrated Manufacturing –
CIM).
Typologie IS (pokračování)
Informační systémy pro podporu vrcholového řízení
(EIS – IS), které zabezpečují vrchol řídící pyramidy, slouží
především vrcholovému managementu podniku. Jsou to
„osobní“ IS pro manažery na úrovni strategického
plánování. Na rozdíl od MIS se EIS zajímá o informace z
okolí podniku (technické inovace, trh, banka, konkurence
apod.). EIS umožňují přístup k externím datům a sumarizují
interní podnikové informace do nejvyšší úrovně agregace.
Obr. EIS
Srovnání MIS & DSS
Obr. EIS a jeho propojení na DIS a FIS
přes IS
Podpůrné IS
Kancelářské IS (Office Automation – OA)
Obsahují textové procesory, faxy, kopírovací přístroje,
zařízení na optické čtení dokumentů, el. Poštu apod.
Podpůrné IS
Útvarové systémy (Departmental Systems – DS)
Jsou často spojením TPS, DSS a OA, ale jejich rozsah je
redukovaný na určitý útvar nebo místo.
Dokumentografické (DIS) a faktografické (FIS) IS
zpracovávají a poskytují odborné a vědecké informace
sloužící k podpoře strategického rozhodování a plánování.
Nejčastěji existují propojení z EIS na DIS nebo FIS přes
informační portály.
Dělení IS dle obsahu výstupu
• agregované zprávy pro management (typické pro
transakční IS),
• zprávy na vyžádání (Manažerské IS),
• nformace pro rozhodování (IS na podporu rozhodování),
• hodnocení, rady, vysvětlení (expertní systémy),
• klíčové indikátory na řízení a strategické rozhodování v
podnicích (exekutivní IS),
• adresy, příp. plné texty dokumentů (dokumentografické
IS),
• fakta, souvislosti, sémantické mapy (znalostní a
zpravodajské IS).
Typologie IS dle Vickeryho
• anglický informační vědec B. C. Vickery chápe IS jako
propojení zdrojů a příjemců informací.
Dělení IS dle jejich vztahu k systému
řízení
TZPIS
20. 10. 2012 – úvod do terminologie,
rekapitulace, rozšíření termínů, architektura
databází
Úvod do terminologie - pokračování
Systém řízení báze dat (SŘBD) lze chápat jako souhrn
procedur a datových struktur, které zajišťují nezávislost
databázových aplikací na detailech vytváření, výběru, uchování,
modifikaci a zabezpečení ochrany databází na fyzických
paměťových strukturách počítače.
Pro práci s daty SŘBD podporují zejména tyto funkce:
• vytvoření báze dat (CREATE),
• vkládání dat (INSERT),
• aktualizace dat (UPDATE),
• rušení dat (DELETE),
• výběr z báze dat (SELECT).
Dále je podporována tvorba formulářů (vstupních obrazovek,
Forms), výstupních sestav (Reports) a aplikačních programů.
Úvod do terminologie
Data
• údaje, které mají určitou vypovídací schopnost. Mohou
být určitým způsobem uspořádány (seřazeny, např. podle
velikosti, chronologicky atd.) a jsou uživateli k dispozici v
různých formách (tabulky, grafy, zvukové signály, grafická
forma atd.). Data jsou obvykle rozdělena na dílčí údaje
(atributy) o dané množině objektů (entit), na základě
nichž lze získat určitou informaci, která může vést k
rozhodovacímu procesu.
Úvod do terminologie
Záznam
• je souhrn údajů (atributů) o dané části objektu, které jsou
uloženy v položkách (polích, Fields) charakterizovaných
názvem a datovým typem. Význam pojmu záznam (Record) a
položka lze snadno ukázat na bázi dat STUDENT.
Abychom mohli u každého studenta zaznamenat potřebné
údaje, musí mít záznam 5 položek, které mohou mít tyto názvy:
• identifikační číslo,
• jméno,
• příjmení,
• datum narození,
• bydliště,
• pohlaví.
Úvod do terminologie
Datové typy
• každá položka musí být určitého datového typu. Obecně
akceptované jsou tyto typy dat :
• Textový typ - textový řetězec, zpravidla do max. délky
255 znaků.
• Číselné typy - pro uložení celých a reálných čísel s
pevnou i plovoucí desetinnou tečkou.
• Logický typ - slouží k uložení logické hodnoty Ano/Ne
(True/False, Yes/No).
• Memo - pro uložení textu proměnné délky.
• Datumový typ - pro uložení datumu nebo datumu a času.
Úvod do terminologie
Model
• je souhrn pravidel pro reprezentaci logické organizace dat
v databázi.
• Základní typy modelů: hierarchický, síťový, relační,
objektový.
KONCEPTUÁLNÍ MODEL je formalizovaný popis zájmové
reality. Popisuje fakta o reálném světě, která jsou v čase
neměnná nebo se mění pouze málo. Nejedná se o popis
dat v počítači. Důvodem zavedení konceptuálního
schématu je odstranit náhlý přechod od zájmové reality
přímo k logickému schématu báze dat.
Relační model – rozšíření
• byl popsán v roce 1970 Dr. Coddem. V současnosti je
tento model nejčastěji využíván u komerčních SŘBD.
Relační databázový model má jednoduchou strukturu.
Data jsou organizována v tabulkách, které se skládají z
řádků a sloupců. Všechny databázové operace jsou
prováděny na těchto tabulkách.
Relační model - rozšíření
Dr. Codd definoval jako minimalisticky relační ty systémy,
které splňují tyto dvě vlastnosti:
1. Databáze je chápana uživatelem jako množina relací a
nic jiného.
2. V relačním SŘBD jsou k dispozici minimálně operace
selekce, projekce a spojení, aniž by se vyžadovaly
explicitně předdefinované přístupové cesty pro realizaci
těchto operací.
12 pravidel pro relační SŘBD
Dále definoval Dr. Codd dalších 12 pravidel pro relační SŘBD:
1) Informační pravidlo
Všechny informace v relační databázi jsou vyjádřeny explicitně
na logické úrovni jediným způsobem - hodnotami v tabulkách.
2) Pravidlo jistoty
Všechna data v relační databázi jsou zaručeně přístupná
kombinací jména tabulky s hodnotami primárního klíce a
jménem sloupce.
3) Systematické zpracování nulových hodnot
Nulové hodnoty jsou plně podporovány relačním SŘBD pro
reprezentaci informace, která není definována a to nezávisle na
datovém typu.
12 pravidel pro relační SŘBD
4) Dynamický on-line katalog založený na relačním modelu
Popis databáze je vyjádřen na logické úrovni stejným způsobem jako
zákaznická data, takže autorizovaný uživatel muže aplikovat stejný
relační jazyk ke svému dotazu jako uživatel pri práci s daty.
5) Obsáhlý datový podjazyk
Relační systém muže podporovat několik jazyků a různých módu
použitých při provozu terminálu. Nicméně musí být nejméně jeden
příkazový jazyk s dobře definovanou syntaxí, který obsáhle podporuje
definici dat, definici pohledů, manipulaci s daty jak interaktivně, tak
programem, integritní omezení, autorizovaný přístup k databázi,
transakční příkazy apod.
6) Pravidlo vytvoření pohledů
Všechny pohledy, které jsou teoreticky možné, jsou také systémem
vytvořitelné.
12 pravidel pro relační SŘBD
7) Schopnost vkládání, vytvoření a mazání
Schopnost zachování relačních pravidel u základních i
odvozených relací je zachována nejen při pohledu na data,
ale i při operacích průniku, přidání a mazání dat.
8) Fyzická datová nezávislost
Aplikační programy jsou nezávislé na fyzické datové
struktuře.
9) Logická datová nezávislost
Aplikační programy jsou nezávislé na změnách v logické
struktuře databázového souboru.
12 pravidel pro relační SŘBD
10) Integritní nezávislost
Integritní omezení se musí dát definovat prostředky relační
databáze nebo jejím jazykem a musí být schopna uložení v
katalogu a nikoliv v aplikačním programu.
11) Nezávislost distribuce
Relační SŘBD musí být schopny implementace na jiných
počítačových architekturách.
12) Pravidlo přístupu do databáze
Jestliže má relační systém jazyk nízké úrovně, pak tato
úroveň nemůže být použita k vytváření integritních
omezení a je nutno vyjádřit se v relačním jazyce vyšší
úrovně.
ARCHITEKTURA DATABÁZÍ
U databází rozlišujeme 3 základní architektury:
• Centrální architektura
• Architektura file – server
• Architektura klient - server
Centrální architektura
• data i SŘBD jsou uložena v centrálním počítaci.
Tato architektura je typická pro terminálovou síť, kdy se po
síti přenáší vstupní údaje z terminálu na centrální počítač
do příslušné aplikace, výstupy z této aplikace se přenáší na
terminál. Protože aplikační program i vlastní zpracování
probíhá na centrálním počítači, který může zpracovávat
více úloh, mají odezvy na dotazy určité zpoždení.
Obr. Centrální architektury
Architektura file - server
• Tato metoda souvisí zejména s rozšířením osobních
počítačů a sítí LAN. SŘBD a příslušné databázové
aplikace jsou provozovány na jednotlivých počítačích,
data jsou umístěna na file-serveru a mohou být sdílena.
Aby nedocházelo ke kolizím při přístupu více uživatelů k
jedněm datům, musí SŘBD používat vhodný systém
zamykání (položek nebo celých tabulek).
Architektura file - server
Komunikace uživatele se systémem probíhá následujícím
způsobem:
• uživatel zadá dotaz,
• SŘBD příjme dotaz, zasílá požadavky na data file-
serveru,
• file-server posílá bloky dat na lokální počítač, kde jsou
data zpracovávána podle zadaného dotazu (vyhledávání,
setřídění atd.),
• výsledek dotazu se zobrazí na obrazovce osobního
počítače.
Obrázek architektury file - server
Architektura klient - server
V podstatě je založena na lokální síti (LAN), personálních
počítačích a databázovém serveru. Na personálních
počítačích běží program podporující např. vstup dat,
formulaci dotazu atd.
Dotaz se dále předává pomocí jazyka SQL (Structured
Query Language) na databázový server, který jej vykoná a
vrátí výsledky zpět na personální počítač. Databázový
server je tedy nejvíce zatíženým prvkem systému a musí
být tvořen dostatečně výkonným počítačem.
Architektura klient - server
Komunikace probíhá tímto způsobem:
• uživatel zadává dotaz (buď přímo v SQL nebo musí být do
tohoto jazyka přeložen),
• dotaz je odeslán na databázový server,
• databázový server vykoná dotaz,
• výsledek dotazu je poslán zpět na vysílací počítač, kde je
zobrazen.
Architektura klient - server
Architektura klient-server redukuje přenos dat po síti, protože
dotazy jsou prováděny přímo na databázovém serveru a na
personální počítač jsou posílány pouze výsledky.
Např.: pokud je mezi 10 000 záznamy pouze 100 záznamů,
které splňují podmínku dotazu, pak na personální počítač putuje
pouze těchto 100 záznamů. V případě architektury file-server je
však nutné poslat všech 10 000 záznamů na personální počítač,
tam se teprve provede dotaz a zpracuje nalezených 100
záznamů.
Architektura klient-server vyhovuje i náročným aplikacím a je
využívána většinou renomovaných databázových firem.
Obrázek architektury klient - server
DISTRIBUOVANÁ DATABÁZE
Distribuovaná databáze je množina databází, která je
uložena na několika počítačích. Uživateli se však jeví jako
jedna velká databáze.
Distribuovanou databázi charakterizujeme 3 vlastnostmi:
• Transparentnost
• Autonomnost
• Nezávislost na počítačové síti
DD - TRANSPARENTOST
• Z pohledu klienta se zdá, že všechna data jsou
zpracovávána na jednom serveru v lokální
databázi. Uživatel používá syntakticky shodné
příkazy pro lokální i vzdálená data, nespecifikuje
místo uložení dat, o to se stará distribuovaný
SŘBD.
DD - AUTONOMNOST
• S každou lokální bází dat zapojenou do distribuované
databáze je možno pracovat nezávisle na ostatních
databázích.
• Lokální databáze je funkčně samostatná, propojení do
jiné části distribuované databáze se v případe potřeby
zřizují dynamicky.
• V distribuované databázi neexistuje žádný centrální uzel
nebo proces odpovědný za vrcholové řízení funkcí celého
systému, což výrazně zvyšuje odolnost systému proti
výpadkům jeho částí.
DD – NEZÁVISLOST NA POČ. SÍTI
Jsou podporovány různé typy architektur
lokálních i globálních počítačových sítí
(LAN, WAN). V jedné distribuované databázi
tedy mohou být zapojeny počítače i
počítačové sítě různých architektur, pro
komunikaci se používá jazyk SQL.
TEORETICKÉ ZÁKLADY
PROJEKTOVÁNÍ IS
20.10.2012
Princip rozlišovacích úrovní, princip tří architektur, princip
modelování.
Druhy přístupů k analýza a návrhu IS - Strukturovaný
přístup, Objektově orientovaný přístup.
Analýza a návrh IS
• Myšlenkové postupy ABSTRAKCE a KONKRETIZACE
využíváme v průběhu celého procesu analýzy a návrhu
IS.
Na myšlenkových postupech A a K jsou založeny principy:
• Princip rozlišovacích úrovní;
• Princip tří architektur;
• Princip modelování.
Princip rozlišovacích úrovní
• Založen na zobrazení vyvíjeného systému na
určité podrobnosti rozlišení detailů.
• V případě nejhrubší rozlišovací úrovně je IS
znázorněn jako jeden prvek spolupracující s
okolím – principem zobrazení je popis vazeb
systému s okolím.
• Jde o víceúrovňové zobrazení systému (od
rozlišovací úrovně „0“ až po úroveň „N“, na které
vidíme detaily rozpracované do potřebné úrovně
pro řešení problému.
Princip tří architektur
• Úzce souvisí s principem rozlišovacích úrovní.
• Veškerá zobrazení vyvíjeného IS jsou rozdělena do tří
rozlišovacích úrovní – kategorií (vrstev podrobnosti) = tzv.
VRSTVENÁ ABSTRAKCE SYSTÉMU.
1. Vrstva – KONCEPTUÁLNÍ (esenciální)
2. Vrstva – TECHNOLOGICKÁ (logická)
3. Vrstva – IMPLEMENTAČNÍ (fyzická)
Princip tří architektur
1. Vrstva zobrazení systému – KONCEPTUÁLNÍ
Zobrazení systému na hrubé rozlišovací úrovní – tj.
zobrazení systému a jeho vazem na okolní systémy, dále
zobrazení systému s viditelnými subsystémy a vazbami
mezi nimi.
S takovéhoto zobrazení je patrné, které subsystémy
fungují jako rozhraní mezi IS a okolím, resp. Které
subsystémy zpracovávají VSTUPY a VÝSTUPY systému
vzhledem k okolí.
ÚČELEM zobrazení 1. vrstvy je odpověď na otázku CO
je obsahem systému?
Princip tří architektur
2. Vrstva zobrazení systému – TECHNOLOGICKÁ
Zobrazení systému, která zviditelňují, JAK je obsah
systému realizován?
Je zde zohledněna organizace dat (souborový systém,
relační databázový systém, apod.) a architektura
systému (např.: klient/server).
Zobrazení není zatíženo implementačními specifiky (tj.
konkrétní realizace za pomoci prostředků ICT).
Princip tří architektur
3. Vrstva zobrazení systému – IMPLEMENTAČNÍ
Detaily konkrétní implementace (např. vlastnosti plynoucí
z konkrétního databázového systému).
Z této vrstvy je patrné ČÍM je systém realizován.
Princip tří architektur je aplikován v průběhu celého
procesu analýzy a návrhu IS – vznikají MODELY
vyvíjeného IS na jednotlivých úrovní ABSTRAKCE.
V jednotlivých etapách vývoje IS jde o snahu zpracovat
model IS v požadované vrstvě.
Princip modelování
• V podstatě jde o TVORBU MODELU vyvíjeného IS.
• MODELOVÁNÍ = účelové zjednodušené zobrazení systému za
pomoci vhodných (např. grafických) prostředků.
• MODELOVÁNÍ = ABSTRAKTNÍ obraz reality.
• MODEL = formalizovaný prostředek pro znázornění vyvíjeného
IS, prostředek komunikace mezi odborníky, analytiky a uživateli
IS. Znázorňuje strukturu systému (strukturu procesů, dat, atd.)
na zvolené rozlišovací úrovni. Umožňuje optimalizaci struktury
systému vzhledem ke zvoleným kritériím. Dále umožňuje
simulaci s studium provedených změn systému a jejich vliv na
subsystémy a okolí systému.
Charakteristika modelu
• Model formulován jako systém (tzn. znázorňuje prvky a
jejich vzájemné vazby),
• Hraniční prvky realizují vazby s okolím systému (VSTUPY,
VÝSTUPY),
• Obsah modelu je objektivní – každý prvek modelu
odpovídá objektu reálného světa (tzv. pomocný prvek),
• uspořádání prvků modelu odpovídá uspořádání prvků
části reálného světa, který model znázorňuje.
Analyzované dimenze IS
• funkční
(popis procesů, datových toků a vazeb mezi subsystémy)
• datová
(popis druhů dat, se kterými bude IS pracovat)
• řídící
(popis časových souvislostí systémových akcí)
• organizačně-technologická
(popis a znázornění organizace práce s IS, popis zamýšlených
provozních technologií, které bude IS realizovat)
• systémově-technologická
(popis realizace implementačně závislých systémových funkcí a
jejich časové návaznosti)
Druhy přístupu k analýze a návrhu IS
V průběhu historického vývoje se vyprofilovaly dva
základní přístupy k analýze a návrhu IS:
• STRUKTUROVANÝ přístup (70. léta 20. stol.),
• OBJEKTOVĚ ORIENTOVANÝ přístup (90. léta 20. stol.).
Strukturovaný přístup
• Pojem „strukturovaný přístup“ odráží myšlenkový
postup „strukturování“ (problematiky i předmětu
zkoumání).
• V průběhu analýzy a návrhu IS potřebujeme
zobrazit dva hlavní aspekty vyvíjeného IS:
1) PROCESY probíhající v systému
2) DATA, se kterými systém pracuje a která
produkuje.
MODELY
STRUKTUROVANÝ PŘÍSTUP – charakteristické
(na rozdíl od přístupu objektového) relativně
samostatné zobrazení datových struktur systému
v jednom modelu; datových toků a procesů
zpracovávajících data v jiném modelu.
Metody strukturované systémové analýzy jsou
plně v souladu s principy obecné teorie systémů
Funkční struktura
• Metoda analýzy funkční struktury je jednou ze základních
metod strukturované analýzy používaná především
k popisu struktury systému. Jedná se o metodu grafickou,
která slouží k zachycení hierarchické dekompozice
systému na subsystémy a prvky pomocí stromových
diagramů.
Informační toky
• Grafická metoda, která formou hierarchicky uspořádaných
síťových diagramů vyjadřuje dekompozici systému na
subsystémy a prvky a současně dovoluje zachytit
informační vazby mezi těmito prvky.
• Vhodná metoda pro studium strukturálních vlastností
systému.
• Základními aktivními prvky jsou funkční prvky neboli
funkce, prvky zajišťující transformaci vstupní informace na
výstupní.
• Aktivní prvky lze dále rozlišovat na prvky příslušné
k popisovanému systému a prvky, které lze považovat
vzhledem k popisovanému systému za vnější.
Informační toky
• Pasivní prvky představují paměti. Jedná se o prvky, které jsou
schopny uchovat uloženou informaci. V případě softwarově
orientovaných systémů mohou být realizovány například
soubory nebo databázemi, v oblasti nesoftwarových systémů
například protokoly, seznamy nebo záznamovými knihami.
• Významnou složkou diagramu informačních toků jsou
informační vazby mezi prvky systému – informační toky.
Obsah informačního toku nemůže být s ohledem na požadavek
přehlednosti diagramu vyjádřen zcela detailně.
• Metoda informačních toků vyjadřuje formou hierarchicky
uspořádaných síťových diagramů dekompozici systému na
subsystémy a prvky a současně zachycuje informační vazby
mezi těmito prvky.
• Na vrcholu této hierarchie stojí tzv. kontextový diagram, který
vyjadřuje začlenění systému do souvislostí okolního světa.
Informační toky
Subsystém 2
Prvek 1
Prvek 3Prvek 1
Prvek 22
Prvek 21
Prvek 3
Systém
Subsystém
2
Prvek 2
Prvek 21 Prvek 22
Prvek 1
Paměť
Kontextový diagram
Datové struktury
• Metoda analýzy funkční struktury a metoda informačních
toků neposkytují vhodné a dostatečné prostředky pro
analýzu datové složky systému. Jak vazby mezi prvky
systému popsané informačními toky, tak i pasivní prvky
systému mohou představovat složité a rozsáhlé datové
struktury.
• Jedním z prostředků datové analýzy je popis datových
struktur. Analýza datových struktur umožňuje pomocí
hierarchických stromových diagramů postupné rozčlenění
informačních toků nebo paměťových prvků. Všechny
prvky tohoto diagramu představují obecně chápané
bloky informace – datové položky.
Datové struktury
• Na analýzu struktury dat bezprostředně navazuje detailní
datová analýza, která je prostředkem k podrobnému
popisu elementárních datových položek – listových
prvků hierarchického stromového diagramu.
• Detailní datová analýza umožňuje přiřadit každé
elementární položce datové struktury datový element,
který určuje formu uložení informace. Pro datové
elementy je možno specifikovat například typ, rozsah
nebo výčet možných hodnot.
Datové struktury
Prvek 1
Prvek 22
Prvek 3
Informační
tok 2122
Datová
položka 2
Datová
položka 11
Datová
položka 12
Datové
pole 1
Paměť
Paměť
Datové
pole 2
Datová
položka 21
Datová
položka 22
Datová
položka 1
Prvek 21
ER model
• ER model – model entit a jejich vzájemných vztahů.
• Vhodný pro analýzu systému v případě, kdy složitost
systému spočívá spíše ve složitosti struktury dat než ve
složitosti jeho funkčních složek.
• ER model zachycuje formou síťového grafu objekty
reálného světa a vztahy mezi nimi. Množiny objektů
reálného světa mající shodné vlastnosti se nazývají
entitami, vztahy mezi nimi pak relacemi. Entity mohou být
blíže specifikovány množinou atributů, které mají shodný
význam jako datové elementy užívané při detailní datové
analýze.
ER model
• Relace mezi entitami jsou specifikovány kardinalitou a
těsností vazby. ER modely se využívají pro tvorbu modelů
dat na logické neboli konceptuální úrovni, tedy modelů dat
nezávislých na jejich fyzické realizaci prostřednictvím
specifického databázového systému.
ER model
ER model
Metody popisu chování
• Popis chování systému je v obecném slova smyslu jeho
algoritmizací.
• Algoritmus chování je však v určitých případech nutné nebo
účelné podrobněji popsat již ve fázi analýzy. Metody popisu
chování umožňují ve fázi analýzy zachytit algoritmickou složku
systému, avšak abstrahují od konkrétního způsobu realizace,
který je předmětem fáze návrhu.
• Metody jsou založeny na grafickém vyjádření nebo na vhodné
kombinaci grafického vyjádření a formalizovaného textového
popisu. Obvykle je pomocí grafických prostředků zachycena
základní struktura algoritmu, která je pro specifikaci algoritmu
na detailní úrovni doplněna relativně krátkými sekvencemi
příkazů zapsanými formalizovaným jazykem.
Metody popisu chování
• Klasickým grafickým prostředkem zápisu algoritmu je
vývojový diagram. Díky své jednoduchosti získal oblibu
v nejrůznějších oblastech, které daly vzniknout jeho
různým modifikacím. Nejjednodušší varianta zachycuje
základní strukturu algoritmu pomocí vzájemně
propojených elementů představovaných bloky a
podmínkami. Detailní specifikace algoritmu je obsahem
příslušných elementů a je vyjádřena formalizovaným
jazykem.
Vývojový diagram
Z
Akce 1
+
Podmínka 1
–
Akce 2
K
Akce 3
Metody popisu chování
• Metody popisu chování jsou obvykle velmi příbuzné
metodám užívaným při tvorbě programů.
• Při nedodržení určitých pravidel mohou konstrukce
zachycené pomocí vývojových diagramů odporovat
zásadám strukturovaného programování, a tím mohou
znesnadňovat případnou následnou programovou
realizaci.
• Mezi metody, které podporují a dodržují zásady
strukturovaného programování, patří metoda grafického
zápisu algoritmů podle Jacksona, označovaná jako
Jacksonovy diagramy. Základní struktura algoritmu je
popsána hierarchickým stromovým diagramem, detailní
specifikace je obsahem příslušných elementů a je
vyjádřena formalizovaným jazykem.
Jacksonův diagram
Metoda stavových diagramů
• grafická metoda popisu chování použitelná pro vyjádření
jednodušších algoritmů nebo pro popis algoritmů na
hrubé úrovni.
• Systém je popsán SÍŤOVÝM GRAFEM, jehož uzly
znázorňují stav systému a hrany naznačují možné
přechody mezi stavy s vyjádřením podmínek přechodu a
akcí s přechodem spojených.
• Akce a stavy systému pouze symbolicky označují funkce
a jejich účinky. Algoritmickou náplň akcí je však nutné
popsat s využitím jiných prostředků.
Stavový diagram
Stav 1
Stav 2 Stav 3
P
K K
Událost 1 (Podmínka 1)
Akce 1
U2 (P2)
A2
U3 (P3)
A3
U4 (P4)
A4
U5 (P5)
A5
U6 (P6)
A6
Stavový diagram
Metoda sekvenčních funkčních grafů
• Metoda sekvenčních funkčních grafů představuje
grafickou metodu popisu chování systému vyhovující
nejobecnějším nárokům na popis algoritmu. Základy
metody jsou postaveny na principech Petriho sítí.
• Metoda funkčních kroků a přechodů byla poprvé
uveřejněna v roce 1977 pod názvem GRAFCET (Graphe
Fonctionnel de Commande Etape-Transition). V současné
době se však s touto metodou lze setkat častěji pod
názvem SFC (Sequential Function Chart).
Metoda sekvenčních funkčních grafů
• Metoda sekvenčních funkčních grafů využívá k popisu
systému obdobně jako metoda stavových diagramů síťový
graf.
• Zásadní rozdíl však spočívá v tom, že uzlem síťového
grafu není stav systému, ale krok algoritmu, respektive
akce s daným krokem spojená. Přechod z kroku do kroku
je vázán podmínkou přechodu a aktivitou kroků této
podmínce bezprostředně předcházejících. Síťový graf
tedy zachycuje základní strukturu algoritmu, detailní popis
je pak obsahem akcí spojených s dílčími kroky.
Sekvenční funkční graf
K1
K2
K3 K4
K7 K8
K9
K5 K6
K2
Akce 1
A2
A3 A4
A5 A6
A8A7
A9
Podmínka 1
P2
P3
P4 P5
P6 P7
P8
P9
TEORETICKÉ ZÁKLADY
PROJEKTOVÁNÍ IS
20.10.2012
Objektově orientovaný přístup - Diagram Use case,
Sekvenční diagram, Diagram spolupráce, Diagram tříd,
Stavový diagram, Diagram aktivit, Diagram nasazení
Objektově orientovaný přístup
• Historicky mladší technika navazující na strukturovaný
přístup.
• Přístup je založen na OBJEKTECH, jakožto strukturách,
které mají definované vlastnosti (ATRIBUTY) a své
chování (operace, které daný objekt může provádět).
• Vlastnosti i operace jsou „zapouzdřené“ v jednotlivých
objektech.
• IS je chápán jako MNOŽINA spolupracujících OBJEKTŮ.
• Každý OBJEKT je schopen reagovat na události, které na
něj působí jako IMPULS.
Objektově orientovaný přístup
Objektově orientovaný přístup
• umožňuje lepší využití kódu než knihovny procedur.
• možnost znovupoužití.
• lze využít prostředky pro okenní rozhraní systémů.
• dávkové úlohy jsou interaktivní (objekt reaguje na více
podnětů)
Objekt
Struktura objektu:
1) VNITŘNÍ PAMĚŤ
2) METODY OBJEKTU
3) JINÉ OBJEKTY
4) SCHOPNOST PŘIJMOUT A ZPRACOVAT ZPRÁVU Z
VNĚJŠKU
Objektově orientované modelování
• způsob nazírání na IS pomocí abstrakce reálného světa.
Základním stavebním prvkem je objekt (entita), která
v sobě zahrnuje jak datovou strukturu popisující určitou
entitu, tak i pravidla chování této entity.
Vizuální modelování (OOM)
Vlastnosti
• “Informace v obrázcích”
• Prostředek komunikace (pohledy, modely, diagramy)
• Zachycuje obchodní procesy, věcnou problematiku, architekturu
systému
• Je podporováno silnou notací a objektovými metodologiemi
Metodologie
• Booch, Coad,Yourdon
• OMT (Object Modeling Technik), Rumbaugh
• OOSE (Object-Oriented Software Technik)
• Jacobson (scénáře)
• EFEM (Extrémní efektivní modelování)
Vizuální modelování (OOM)
• Modely vytváříme pro pochopení komplexnosti systému
jako celku.
Za pomocí modelů lze:
• vizualizovat stávající nebo vytvářený systém,
• specifikovat strukturu nebo chování systému,
• získat základ pro konstrukci systému,
• dokumentovat rozhodnutí o systému.
Objekty
Charakteristické vlastnosti objektů:
• Jedinečnost – znamená, že každý objekt je rozlišitelnou
entitou, i když má jinak stejné kvalitativní i kvantitativní
charakteristiky. K rozlišení se používá identifikační číslo.
• Zatřiditelnost – objekty se stejnou datovou strukturou
(atributy) a chováním (operacemi) jsou seskupovány do tříd.
• Mnohotvárnost – znamená, že stejně označená operace se
může chovat rozdílně a dávat rozdílné výsledky pro různé třídy
objektů.
• Dědičnost – je sdílení atributů a operací mezi třídami
založenými na hierarchických vztazích. Třída může být
definována poměrně široce a potom ji lze následně zjemňovat
do podtříd. Každá podtřída pak zahrnuje vlastnosti své
nadřazené třídy.
Objektově orientované modelování
• Založeno na principech, které vyjadřují podstatu objektového přístupu.
4 principy OOP:
• Zobecnění – představuje zaměření na podstatné vnitřní aspekty objektů
a ignoruje jeho nepodstatné vedlejší vlastnosti. To znamená, že klade
důraz na to, co objekt je, a co by měl dělat, a ne na to, jak by to měl
dělat.
• Zapouzdření – znamená oddělení externích aspektů objektu, které jsou
dostupné ostatním objektům, od interních implementačních detailů
objektu, zakrytých ostatním objektům. To znamená, že implementace
objektů může být změněna, aniž by se to dotklo aplikací, ze kterých je
objekt použit.
• Sdílení – je umožněno dědičností datových struktur a chováním mezi
několika podobnými třídami bez redundance. To umožňuje opakované
použití již navržených a ověřených programů v dalších aplikacích.
• Spolupůsobení – jednoznačnost, zatřiditelnost, mnohotvárnost a
dědičnost charakterizují hlavní proud objektově orientovaných jazyků.
Každý z těchto aspektů může být izolován, ale dohromady působí
symetricky.
Výhody a nevýhody OOP a tradiční
analýzy
Výhodou tradičních popisů IS oproti OOP bylo, že jejich
osvojení bylo relativně snadnější, neboť jejich rozsah od
zadání softwarové úlohy až po bezprostřední zadání
programových dat a procedur byl řešen nezávisle na
pochopení funkcí reálného podnikového systému jako
celku a jeho potřeb nejen informačních.
Nevýhody objektového přístupu
• Zavedení nového vyjadřovacího prostředku a nového
způsobu myšlení, což je dosti náročné pro lidi,
zúčastněné na procesu modelování, a později pak i na
programování.
• Používání počítačové podpory pomocí vhodného CASE,
bez níž nelze provést kvalitní analýzu i relativně malého
systému. To opět vyžaduje zvládnutí práci s daným CASE
(Computer Aided System Engineering).
• Technologickou kázeň s tím nutně spojenou.
Výhody OOP
• Možnost vysledovat na modelu vnitřní vztahy prvků
v podnikovém systému a vytvářet software pro
„poskytovatele služeb“, tj. pro prvky podniku, které
poskytují své služby jiným podnikovým prvkům.
• Takto vytvářený software může být opakovatelný,
zejména při použití knihoven standardizovaných tříd.
• Možnost vytvářet software podstatně pružnější vzhledem
k proměnlivým potřebám podniku. Z hlediska programů je
to dáno tím, že dříve byly strukturované programy
vytvářeny podle pevné struktury potřeb podniku v době
jejich vzniku, bez snadné možnosti změn.
Historie OOP
• O OOM se začíná hovořit v 2. pol. 80. let 20. stol.
• Na počátku 90. let již existovala řada metod, nástrojů a
technik založených na OOP.
• Snaha o integraci jednotlivých metod a o unifikaci OOP 
Grady Booch & James Rumbaugh publikovali v r. 95
metodu s názvem Unified Method (vycházela z metod
Booch a OMT).
Historie OOP
• V r. 95 se k autorům Unified Method Jacobson (autor
metody Objectory/OOSE).
• Vznikají další verze Unified Method.
• Ukazuje se, že se jen těžko podaří prosadit jednotné
postupy a doporučení a ucelenou OO metodu vývoje IS.
Historie OOP - UML
• Přejmenováním Unified Method na Unified Modeling
Language (UML) vznikl nástroj – grafický jazyk pro tvorbu
modelů IS použitím OOP.
• UML byl přijat sdružením OMG (Object Management
Group – sdružení usilující o unifikovaný rozvoj OOp) jako
doporučený standard notace pro tvorbu modelů IS.
UML
• V současnosti je UML nejrozšířenější objektovou notací.
• Zahrnuje několik druhů modelů (diagramů) IS a grafických
vyjadřovacích prostředků pro jejich konstrukci.
• UML dnes podporují všechny CASE nástroje pro
objektovou analýzu a návrh IS, OOM začleňují UML mezi
své výrazové prostředky.
UML
V současnosti UML poskytuje:
• pravidla pro pojmenování, rozsah platnosti, rozsah
viditelnosti, omezení, prezentaci modelu,
• různé specifikace,
• rozšiřitelnost jako jsou stereotypy, dodané hodnoty.
UML
Definice:
UML je standardní jazyk pro vizualizaci, specifikaci,
konstrukci a dokumentaci prvků projektu, ve kterém hraje
významnou roli vývoj software.
Stavební kameny:
• artefakty (prvky),
• vztahy,
• diagramy.
UML – skupiny ARTEFAKTŮ
Týkající se struktury systému
• tvoří statickou část modelu,
• třídy, rozhraní, use case, komponenta.
Týkající se chování systému
• tvoří dynamickou část modelu,
• interakce, stavy, aktivity.
Týkající se organizace systému
• package.
Týkající se vysvětlení účelu
• popis, anotace, poznámka.
UML - VZTAHY
Agregace (závislost)
• jeden prvek závisí na druhém.
Asociace
• propojení prvků.
Dědičnost
• specializace/generalizace
UML - DIAGRAMY
Grafická reprezentace obsahu modelu
• zachycení prvků a jejich vztahů.
Pohled na systém z různých perspektiv.
Různé typy diagramů
• Diagram užití (use case), tříd, objektů, sekvenční, spolupráce, stavový,
aktivit, komponent, nasazení, balíčků (package).
UML - DIAGRAMY
1. Diagram Use case
2. Sekvenční diagram
3. Diagram spolupráce
4. Diagram tříd
5. Stavový diagram
6. Diagram aktivit
7. Diagram nasazení
Diagram Use case
• jeho vypracování je obsahem use case analýzy,
zachycuje funkcionalitu systému z pohledu uživatele,
popisuje chování systému z hlediska uživatele.
Prvky diagramu use case:
Aktor (vymezením aktorů specifikujeme okolí systému a
vymezíme jeho hranice).
Use case (případ užití, typ jednání, funkcionalita,systému,
kterou využívá aktor),
Vztahy (mezi aktorem a use case, mezi use case,
výjimečně mezi aktory).
Diagram Use case
Aktor = kdokoliv nebo cokoliv mimo systém, kdo nějak
komunikuje a interaguje se systémem.
• zachycení okolí systému,
• prvky aktivně komunikující se systémem:
• uživatelé
• jiné softwarové systémy
• čas
Diagram Use case
Use case (typ jednání, případ užití)
jakákoliv funkčnost, která dává měřitelnou hodnotu
uživatelům tohoto systému.
reprezentuje ucelenou funkcionalitu problémové domény
Diagram Use case
Typy vztahů v UCD:
1) Vztah mezi AKTOREM a USE CASE – aktor
komunikuje se systémem (vyvolává a účastní se USE
CASE)
2) Vztahy mezi USE CASE
Use case mohou vzájemně spolupracovat (slouží pro
zjednodušení modelu a podobá se dekompozici).
Vztahy mezi USE CASE
Dva typy vztahů mezi use case:
• Vazba include (dříve uses)
povinný vztah, oba spojené use case se musí povinně
provést, použijeme tam, kde se část use case v
navrhovaném systému může opakovat.
• Vazba extends
rozšiřující vztah, za jistých podmínek se vykonávají oba
use case, použijeme pro volitelné chování, pro chování za
specifických podmínek, pro chování podle volby aktora.
Popis USE CASE - scénář
• Stručná charakteristika (1 - 3 věty)
• Scénář:
• nutné podmínky před spuštěním,
• nutné podmínky po ukončení,
• tok událostí - sekvence akcí.
• Jeden scénář “HAPPY DAY” (obsahuje základní tok
událostí a subtoky).
• Ostatní scénáře jsou alternativní, chybové.
Scénář (tok událostí) pro Use Case Př.:
Evidence rezervace (půjčovna CD)
Předpoklady
Tento Use Case začne, když člen
nemůže být uspokojen, protože
dané CD není momentálně na
skladě, nebo daný titul není v
půjčovně k dispozici.
Hlavní tok
Tento Use Case začíná, když člen
předloží asistentovi svoje
identifikační číslo a název titulu,
který si chce zarezervovat. Asistent
zkontroluje existenci člena v
databázi členů (A-1), zkontroluje,
zda titul existuje v databázi titulů
(A-2) a zkontroluje, zda jsou
všechny kopie daného titulu
zapůjčeny (A-3).
Pokud má někdo kopii zapůjčenu
déle než 10 dní, je upomenut o
navrácení (S-1). Je založen
záznam o rezervaci této kopie pro
daného člena. Je vytištěn doklad o
rezervaci titulu.
Subtoky
S-1: Asistent vyhledá všechny členy, který
mají půjčený daný titul a zkontroluje
délku jejich půjčky. Pro ty, kteří mají
půjčku delší než 10 dnů, vytiskne
upomínku.
Alternativní toky
A-1 : Je vloženo špatné ID člena, nebo
člen neexistuje. Asistent může opakovat
vstup ID nebo vložit údaje o členu (bude
řešeno v Use Case Přidání nového
člena), nebo ukončit Use Case.
A-2 : Je vložen špatný titul, nebo titul
neexistuje v půjčovně. Asistent ukončí
Use Case (není založena rezervace) a
vytiskne objednávku na daný titul (Use
Case Objednání materiálu).
A-3 : Asistent zjistí kdo má půjčené kopie
a vloží rezervaci pro člena.
Use case diagram
Informace o use case:
• jde o vizualizaci funkcionality, další informace musím
spravovat v textové podobě,
• use case musí mít tyto náležitosti (jméno, popis – účel,
kdo a co jej používá, související use case, hlavní a
alternativní scénář, nepovinně poznámky).
Význam use case diagramu
• zachycení požadavků na systém,
• vizualizace a organizace požadavků ve standardní formě,
• pro nalezení objektů, tříd a zodpovědností z popisu
scénářů.
Use case diagram
Sekvenční diagram UML
• Zachycuje interakci mezi objekty, zachycuje zasílání zpráv
mezi objekty v rámci systému.
• Zachycuje dynamické chování s orientací na čas.
Vlastnosti sekvenčního diagramu:
• Objekty sekvenčního diagramu spolu komunikují pomocí
zasílání zpráv.
• Popisuje jeden průchod zpráv systémem.
• Nemá přímé výrazové prostředky pro smyčky, větvení a
podmínky.
• Pro jednoduché případy použiji poznámky.
• Složité případy řeším separátními diagramy.
Sekvenční diagram
Diagram spolupráce UML
Vlastnosti diagramu spolupráce:
• Ukazuje tytéž informace jako sekvenční diagram s
ohledem ne na čas, ale na propojení mezi objekty.
• Slouží pro pozdější určení vztahů mezi objekty:
• datové vztahy - dány distribucí informací,
• komunikační vztahy - dány spoluprací mezi objekty
Diagram spolupráce UML
Diagram tříd UML
• Třída je abstrakce objektů, které mají společné
chování a o kterých nás zajímají stejné informace.
• V OOP je to šablona pro instance objektů.
• Statický pohled na modelovaný systém.
• Vytváří se v etapě analýzy a postupně se zpřesňuje,
je základem pro implementaci a nástrojem pro
dokumentaci.
Diagram tříd UML - Třída
Třídy vyhledáváme analýzou problémové domény
(podstatná jména ze scénářů).
Třída je zapouzdřením určitého chování a určitých
informací.
Zapouzdření je koncept, který dává ve třídě dohromady to,
co spolu souvisí a dává nějaký smysl.
Obsahem třídy je:
Jméno,
Atributy,
Operace.
Diagram tříd UML –Operace,
atributy
Operace třídy
• Operace, které třída definuje, představují její chování
nebo také zprávy, kterým třída rozumí.
• Zdrojem pro hledání operací jsou především scénáře use
case analýzy.
Atributy třídy
• Atributy třídy jsou informace, které o třídě uchováváme.
• Zdrojem pro atributy třídy jsou věcné znalosti o dané
problematice a analýza podrobných požadavků uživatelů.
• Atributy třídy by měly být atomické a nedělitelné.
Vztahy mezi třídami
Třídy nejsou v systému osamocené, jejich objekty ke svému
chování potřebují využít schopností jiných objektů. Třídy mezi
sebou sdílí informace.
Asociace (“Slabá” vazba mezi třídami), např. čtenář a kniha
• Neříká nic jiného, než to, že dvě třídy mají mezi sebou vztah,
tedy že o sobě vědí.
• Defaultně obousměrná vazba.
• Může být definováno jméno asociace, role a násobnost (kolik
instancí třídy existuje vůči jiné třídě).
Agregace (volná vazba mezi třídami), např. počítač a periferní
zařízení
• Představuje vztah skládání celku z částí, celek odpovídá za
vytvoření a zrušení částí, je to vztah celku k jedné části,
definujeme násobnost, jméno a role ne.
Vztahy mezi třídami
Kompozice (nejsilnější forma asociace, velmi pevná vazba
mezi třídami), např. faktura a řádek faktury, třída se skládá z
jiných závislých tříd
• Třídy tvoří hierarchii
Dědičnost (nejsilnější forma vazby mezi dvěma a více třídami).
• Generalizace/specializace
• Potomek dědí celou specifikaci svých předků (atributy i
operace).
• Viditelnost prvků určuje, jak jsou děděny (public a protected
jsou v potomkovi přístupné, private ne).
• Vztah mezi třídou a speciálním případem této třídy.
• Rozlišuje, co je stejné a co jiné.
Vztahy mezi třídami
• Rekurzivní asociace (asociace na sebe sama).
• Asociativní třída (atributy asociace)
• Pokud sama asociace nese určité informace, které nemohou být
atributy ani jedné z asociovaných tříd.
• Hovoříme o „link class“.
• Může mít atributy i operace.
• Např. vztah mezi osobou (jméno, rcislo), firmou (název) je vazba s
asociativní třídou pracovní poměr (datum nástupu, funkce, plat).
Diagram tříd
Stavový diagram UML
Dynamické chování systému je modelováno pomocí diagramů
aktivit i stavových diagramů
Stavový diagram
• Používá se k modelování životního cyklu jednoho objektu.
Hovoříme o objektech s výrazným dynamickým chováním
nověji reaktivní objekty.
• Stavový diagram modeluje chování systému napříč všemi use
casy. Znázorňuje, jak se stavy objektu mění v závislosti na
událostech, které se ho dotýkají
• Stav objektu je dán hodnotami jeho atributů.
• Stav objektu může ovlivňovat jeho chování.
• Stav objektu je zachycen na stavovém diagramu jako stav
jednoho objektu jedné třídy bez vazeb na jiné objekty nebo jiné
třídy.
Stavový diagram
Diagram aktivit UML
• Použití pro modelování systémů pracujících v reálném čase,
systémů pro řízení technologických procesů, nebo paralelních
procesů a jejich synchronizaci.
• Další použití pro znázornění složitého scénáře a doplnění
sekvenčního diagramu.
• Jsou zvláštním případem stavových diagramů, kde stavy jsou
vyjádřeny jako akce a kde přechody jsou spouštěny
automaticky po ukončení předchozích akcí nebo aktivit.
Používají obvykle pouze malou podmnožinu bohaté syntaxe
stavových diagramů UML.
• Lze používat symbolů rozhodování (tzv. hodnocení přechodů),
symbolů rozvětvení (jeden vstup několik výstupů), spojení (více
vstupů jeden výstup), plavecké dráhy – swimlanes pro
specifikace osob, oddělení nebo tříd zodpovědných za aktivitu.
Diagram aktivit
Diagram nasazení
• Etapa Nasazení (implementační etapa) je proces přiřazení
artefaktů (soubory, skripty, DB tabulky, modely UML) uzlům
(např. PC, server, prostředí zpracování).
• Diagram nasazení umožňuje modelovat distribuci SW systému
na fyzickém HW. Ukazuje fyzický hardware na němž bude
softwarový systém (komponenta) spuštěn a také způsob, jak je
SW na tomto HW nasazen.
Diagram nasazení ukazuje:
• Uzly – typy HW, na nichž bude systém spuštěn (osobní PC,
server).
• Relace – typy spojení mezi uzly (komunikační kanál, který
slouží k přenosu informací, např. HTTP).
• Komponenty – typy komponent nasazených na určité uzly
(modul IS, MS Word).
Diagram nasazení
145
Děkuji za pozornost.