Projektování informačních systémů 5
Příprava prováděcího projektu, strukturované a objektové metody analýzy a návrhu
Doc. Mgr. Petr Suchánek, Ph.D.
Doc. RNDr. Ing. Roman Šperka, Ph.D.
Převzato od: Ing. Dominik Vymětal, DrSc.
Příprava prováděcího projektu začíná detailní analýzou
oAnalýza a návrh probíhá různými způsoby
oVždy však zahrnuje analýzu požadavků uživatele
oNávrh probíhá s využitím různých přístupů
nBPM + návrh
nZnámé metodologie
nAgilní metodiky
nHodnotové přístupy k modelování
nMetodiky SW firem
n
2
>
Základní pojmy
oMetodika, metodologie
nDoporučený souhrn přístupů, zásad, postupů, metod, technik atd. pro tvůrce IS
nKdo co a proč
oMetoda určuje co je třeba dělat v určité fázi
nPřístupy jako funkční, datový, objektový
nŘeší postup v určité fázi
oTechnika – přesné postupy
oNástroj – prostředek uskutečnění určité činnosti
nDiagramy, atd.
3
>
Zdroj:Lenertová
4
Zdroj:Lenertová
5
Detailní analýza požadavků na nový systém
oCíl:
nNa základě firemní strategie a cílů projektu definovat detailní požadované funkce
oForma:
nWorkshopy s řízenou moderací a dokumentací
oÚčastníci:
nDle témat jednotlivé specializované dílčí týmy
nK integraci je nutné dílčí týmy koordinovat (úloha projektového manažéra)
oVýstup:
nPodklady pro návrh databáze
nPodrobná specifikace funkcí a prací
nPodklady pro cílový koncept řešení
Principy analýzy a návrhu
oAnalýza a návrh systému se řídí několika principy:
nPrincip abstrakce – vyvoláno nutností pracovat se zvládnutelnými úseky (částmi)
nTop down hierarchie
nPrincip tří architektur
nAgregace – specializace – generalizace
nPrincip modelování (formální zjednodušené zobrazení systému/reality)
n
nVíce o principech zde
7
>
Popis očekávané reality
oJe základem pro tvorbu nového sytému
oKonkrétní forma – model
nZnázornění stávajícího nebo vytvářeného systému
nSpecifikace struktury a chování systému
nSpecifikace omezení a vazeb na okolí
oTři nutné předpoklady
nNotace – způsob zápisu modelu systému
nProces – způsob použití notace
nNástroj – tool k dokumentování našeho modelu
oForma
nTop down kaskáda – viz princip top-down hierarchie ne vždy možná
nIterační a přírůstkový cyklus
Základní přístupy k zobrazení očekávané reality
oStrukturované
nČlení projekt na definované substruktury
nProbíhají více či méně ex post balancováním funkčního a datového modelu
nData Flow Diagram (DFD), Entity Relationship Diagram (ERD), State Transition Diagram (STD), Data
Dictionary a Process Specification
oObjektové
nPrincip je ve spojení dat a služeb – objekty volají metody jiných objektů
nZapouzdřenost chování a dědičnost
n
Strukturované přístupy k zobrazení reality – základní charakteristika
oČlení projekt na malé dobře definované aktivity, určují jejich posloupnost a vazby (dekompozice)
oPoužívají techniky modelů a diagramů
oPoužívají balancování funkčního a datového modelu
oSvou názorností umožňují zapojení i méně zkušených pracovníků
oMetodologie a metody
nYourdon Structured Analysis (YSA) – klasika a základ pro další, Jacksonova strukturní metoda,
SSADM
oTechnika
nChenův model ERA pro modelování dat jako základ strukturovaných CASE TOOLS, Jacksonovy strukturní
diagramy
oNástroj
nDFD a další diagramy, možnost nástrojů CASE pro strukturované metody
Více o strukturovaném návrhu zde
Yourdon Structured Method YSM
oV 80. letech Yourdon vyvinul metodu Yourdon Structured Method (YSM), která je založená na
funkčních strukturách. Metoda podporuje 2 fáze ve vývoji SW: analýza a návrh. YSM zahrnuje 3
diskrétní kroky: studie proveditelnosti, základní modelování a implementační modelování. Dále
nabízí další modely:
oModel chování: chování systému muže být popsáno 3 způsoby: funkčně, dynamicky a vztahově.
oProcessor environment model (PEM): popisuje alokaci výpočtových funkcí v hardwaru procesoru.
oSoftware environment model (SEM): definuje softwarovou architekturu a její dopady na každý
procesor.
oCode organizational model (COM): znázorňuje modulární strukturu každého úkolu.
Yourdon Structured Method YSM II
oYSM pokrývá : Analýzu požadavků, Specifikaci systému, Konstrukci systému, Implementaci
oVytváří 4 nezávislé modely
nDatový : statický pohled na realitu, nejčastěji se používá ERA
nFunkční: diagramy struktury funkcí, diagramy datových toků DFD a slovní popisy funkcí
nModel řízení: Diagram stavů a přechodů (State transition diagram) a řídící toky v DFD – popis jak
se mají k sobě chovat funkce systému
nModel struktury programového systému (patří již do System design)
oIntegrace z pohledu informací je zajištěna pomocí Data Dictionary DD
Jacksonovy diagramy
13
Hierarchické stromové struktury
>
Strukturovaná dekompozice v projektu IS
oV projektu IS se uplatňují zejména 2 hlediska:
nDekompozice funkční
oVe fázi plánování jde o stanovení základních nových funkcí IS a jejich vazeb , detailní plán
vzniká na základě konceptu řešení
nDekompozice předmětová
oJde v podstatě o stanovení prvků HW a infrastruktury, které se projekt týká
oPožadavek soudržnosti a jednoduchosti
oNesmí se narušit celistvost systému,
oDekompozice končí u samostatně řešitelných úloh
Strukturované metodologie - SSADM
oSSADM – typický představitel strukturovaných metodologií
oPoužívala se jako standard pro vládní projekty ve Velké Británii
oSSADM (Structured Systems Analysis and Design Metology)
nAnalýza
nSpecifikace uživatelských a systémových požadavků
nVýběr technických možností
nNávrh struktury dat a procesů
nFyzický návrh
nNástroje SSADM se u různých autorů doporučení liší.
oSSADM používá 3 pohledy na DATA
nLogické datové struktury - informace a jejich vazby
nDiagramy datových toků
nŽivotní cykly entit
Zdroj: Sochor
Příklad životního cyklu entity Zákazník
16
SSADM
>
Zdroj : Lenertová
17
Zdroj : Lenertová
18
Datový model ERA (Chen)
oObjekty, vztahy mezi objekty a vlastnosti objektů (vztahů)
oEntita – předmět našeho zájmu.
nTyp – student
nVýskyt - student OXiiiiiii
nMá definici, popis, jak vzniká a zaniká
oVztah – důležité vztahy mezi entitami
nNásobnost - binární až n-ární (kolik entit je vztahem spojeno)
např. ředitel-řídí-podnik je binární ale ředitel, náměstkové-vedení podniku je n-ární vztah
nKardinalita – má vazbu na výskyty 1:1, 1:n, n:m (1:1 na každé straně je jen jeden výskyt např.
děkan-řídí-fakulta)
nOdvoditelnost – hledáme ty vztahy, které se nedají odvodit z jiných vztahů
nParcialita – vztah totální (musí existovat vždy), parciální
ERA
20
Entita
Entita
Relace
Atribut
Atribut
>
Chenův model ERA II
oAtributy
n jsou podrobnosti (vlastnosti) objektů nebo vztahů, které v modelu zkoumáme
nAtributy
oIdentifikační ( např. rodné číslo)
oParciální – nemusí mít hodnotu (např. č. pasu)
oOpakované (např. jazykové vlastnosti)
oKonceptuální schéma
nTextová část (podrobné verbální popisy případně s logickými vztahy
nGrafická část (všechny entity, vztahy mezi entitami, identifikační atributy)
nKvantifikace (počty výskytů, počty opakování, frekvence přístupů, minimální, maximální a průměrné
počty)
ERA – definice jinak
oEntita
nObecná
nSilná/kmenová/základní (nezávislá na jiných entitách)
nSlabá / popisná (existenčně závislá na jiných)
nVazební / asociativní (realizuje vazbu)
oVztah
nN-ární / polyární
nBinární
nKardinalita (max a min počet výskytů v určitém vztahu 1:1, 1:N, M:N)
nVolitelnost / parcialita (vztah se nemusí týkat všech výskytů entity např. 0:N)
nVýlučnost
nExterní id / slabý vztah (nestačí vlastní atributy, je nutná externí identifikace)
ERA – definice jinak II
oAtribut
nJednoduchý
nSložený
nZákladní
nOdvoditelný
oKlíč
nPrimární
nCizí ( je to klíč, který je primárním v jiné entitě, slouží pro vyjádření vztahů v datovém modelu
na technologické nebo implementační úrovni)
nAlternativní
nSekundární / nejednoznačný (atributy důležité pro přístup, další třídění atd.)
Entity
Entita
A
Entity
1:N
M:N
Entity
Entity
Atributy vztahu
Identifikační atribut
Podmíněný atribut
B
1: N
Externí identifikace entity A
Částečná externí identifikace
entity B
Násobnost a kardinalita – např.
Entita 1
Vztah 1: n
Entita 2
Vedoucí
řídí
Pracovník
Účet
skládá
Položka
Vlak
veze
Vůz
Lékař
léčí
Pacient
Tajemník
Proděkani
Děkan
Vedení
fakulty
Normální formy
o1. normální forma – atributy obsahují pouze atomické hodnoty. ( příklad: 1 osoba a 2 tel. čísla)
– rozdělit.
o2. normální forma – každý neklíčový atribut je závislý na celém primárním klíči
o3. normální forma – všechny neklíčové atributy jsou vzájemně nezávislé
o
26
>
Postup přípravy ER diagramu
oVýběr hlavních objektů (entit)
oDefinice vztahů mezi entitami (včetně kardinalit)
oPřidání atributů entitám (zejména identifikátory)
oDefinice hierarchie (hledají se vztahy mezi generalizací a specializací )
oOdstranění tranzitivních vztahů (těch, které se dají odvodit z jiných)
oOdstranění nadbytečných entit
oOvěření úplnosti
oVýsledek – konceptuální schéma datové základny
o
o
o
27
>
Implementace datové základny
oKonceptuální schéma nebere do úvahy, v jakém prostředí má být systém zaveden.
oProto jsou nutné následující kroky:
nVolba prostředí (databázový SW, HW, …)
nTvorba logické struktury datové základny
nVytvoření fyzické struktury datové základny
oDůležité otázky pro implementaci:
nZpůsob práce s daty (client-server , on line, dávka, řízeno událostmi…)
nPřístupové metody a frekvence ( klíče, sekvenční, metody hledání)
nPočty záznamů každého typu
nSoučasné přístupy a očekávané doby odezvy,
nPožadavky na bezpečnost a omezení uživatelů
nOdvoditelné atribut (počítaná pole) a jejich podíl
nNutné kompromisy v čistotě návrhu (duplicitní tabulky, pole…)
Logická a fyzická struktura dat
oLogická struktura
nJe implementací konceptuálního modelu
nAbstrakce vztahů mezi daty
oLineární, stromová, relační struktura
oVýskyty, četnost vztahů,
oZde též bereme do úvahy potřeby na HW
oFyzická struktura
nZavedení reálných (testovacích ) dat do struktur
nTest splnění požadavků uživatele na data a vlastnosti jejich poskytování
nÚpravy fyzických dat, případně změny v logických strukturách
Funkční analýza FSD
oTop Down přístup
k hierarchii funkcí
oDynamické hledisko
(posloupnost funkcí a
podmínky řízení
jejich pořadí) – zpravidla text nebo tabulka
Obchodní případ
Registrace
objednávky
Realizace dodávky
ze skladu
Fakturace
a účtování
Zavedení
objednávky
Kontrola
Bonity
zákazníka
Disponibilita na skladě
Jacksonův SD
Diagram toku dat DFD
oObsahuje:
nDatové prvky
nFunkce (procesy, transformace)
nData store – systém uchovávání dat
nTerminátory – prvky okolí, které jsou zdrojem, nebo cílem datových toků
nSpojení DFD a top down principu se často používá u velkých návrhů
Externí terminátor
funkce
Uložení dat
Zdroj : Lenertová
32
State transition diagram STD
Diagram přechodů a stavů STD
Stav 2
Stav 1
Směr přechodu
Podmínka
Akce
Prázdný displej
Zobrazená strana
PgDn
Vypiš stránku
ESC
Konec výpisu
Vypiš stránku
Záznamy nalezeny
Vztahy mezi nástroji I
oDFD a DD
nKaždý datový tok a data store musí být definován v DD (vztah k ontologii)
oSpecifikace procesu a DFD + DD
nKaždý odkaz na data ve specifikaci procesů k DFD: Musí použít název dle DD
oNebo mít název lokálních dat dle DD
oVztahy DFD ke specifikaci procesů
nKaždý proces který už není rozepsán na nižší úroveň DFD musí být popsán ve specifikaci procesů
nKaždý specifikovaný proces musí být obsažen v některém DFD nejnižší úrovně
nKaždému výstupnímu toku z procesu musí odpovídat WRITE a každému vstupnímu zase READ
Vztahy mezi nástroji II
oVztahy DD+DFD ke specifikaci procesů
nKaždý datový prvek v DD musí být použit ve specifikaci procesů, nebo DFD případně při popisu
jiného datového prvku
oVztahy ER diagramu + DFD ke specifikaci procesů
nKaždý Data store v DFD musí být v ERD zastoupen jako objekt nebo vztah nebo kombinace obojího
nDatové prvky v DD popisují jak data v ERD tak data v DFD, to znamená že data v DD musí být v DFD i
ER diagramu
nSpecifikace procesů musí obsahovat operace CREATE a DELETE pro každý objekt a vztah uvedený v ER
diagramu
nAtributy každého objektu musí být nastaveny některým procesem v DFD
oVztahy mezi DFD a STD
nKaždý řídící proces v DFD musí mít svůj STD
nKaždá podmínka v STD odpovídá vstupnímu řídícímu toku v DFD a naopak
nKaždá akce v STD odpovídá výstupnímu řídícímu toku v DFD a naopak
Objektové přístupy k zobrazení reality – základní charakteristika
nPrincip je ve spojení dat a služeb
nMetodologie a metody
oYourdon/Coad OOA/OOD (Yourdon&Coad Prentice Hall 1990)
oObject Modelling Technique OMT (James Rumbaugh „Object oriented Modelling and Design
Prentice-Hall 1991) viz dále Rational Rose a Select
nNástroj např. UML
nObjektové metody však nenahrazují plně strukturované přístupy , stále jsou důležité diagramy
procesních a datových toků
Objektově orientované metodologie
oOOA/OOD
nAnalýza : 5 vrstev – subjekty (problémové oblasti), objekty, struktury, atributy, služby
nDesign: definuje třídy v problémové oblasti, třídy lidské interakce, třídy správy systému, třídy
správy dat (přístupu k databázím)
oOMT (Object Modeling Technique)
nFáze vývoje systému : analýza, systémový design, objektový design, implementace a testování
nObjektový model: definice tříd a jejich vztahů,atributů a metod
Statická struktura systému
nDynamický model: změny stavů objektů – stavové diagramy STD, mapa událostí, diagram událostí
(reakce systému na vstupy)
nFunkční model : popisuje co systém dělá, ne jak to dělá – obdoba DFD
nModel jednání - obdoba Use case – specifikace a určení hranic systému
o
Souvislosti modelů
38
Zdroj: Řepa
>
Objektové technologie
oZákladním pojmem objektově orientované technologie je objekt.
nZákladní myšlenka objektového přístupu spočívá v tom, objekt zahrnuje také činnosti, které jsou s
objektem svázány. Spojení datových struktur s algoritmy nazýváme zapouzdření (angl.
ENCAPSULATION) a činnosti zapouzdřené do objektu označujeme jako metody (angl. METHODS).
nObjekty se společnými vlastnostmi tvoří tzv. třídy (angl. CLASSES).
nKonkrétní výskyt určitého druhu objektu se nazývá jeho instance
39
>
Objektové metody – definice I
oTřída
nZobecnění reálných objektů
nPopisná charakteristika : atribut (omezení)
nAbstraktní – nemá instance objektů
oMetoda
nPopisuje chování objektů dané třídy
nPopisná charakteristika: příznak
oZávislost
nPokud jedna třídy využívá jinou třídu např.metoda „zobraz menu“ u jedné třídy volá objekty z třídy
„menu“
oRozhraní
nSkupina operací určující chování třídy a její vztah k jiným třídám
nVztah mezi třídou a rozhraním : realizace
Objektové metody – definice II
oViditelnost (zapouzdření)
nVeřejná, private, protected
oDědičnost
nKaždý objekt dědí atributy a metody třídy do které patří i její nadtřídy, pokud existuje
nJeden rodič – jednoduchá dědičnost
nŽádný rodič – základní třída
nŽádny potomek – listová třída
oAsociace – vzájemný vztah objektů
nJednosměrné i obousměrné
nROLE – každá třída má v asociaci roli
nLINK – vazba – instance asociace
nAGREGACE – objekt je agregací objektů jiných tříd
Objektové technologie II
oDůsledek pojmu Třída: dědičnost
nNový objekt určité třídy dědí všechny vlastnosti této třídy. Hovoříme o rodičovském
objektu , o odvozeném objektu, který dědí ( INHERITS) všechny atributy a metody svého předka.
Potomek však může být rodičem pro další objekt.
nPolymorfismus – určitou vlastnost, metodu sdílí celá hierarchie ale lze ji na určité úrovni
upravit, přizpůsobit.
n
42
>
Zapouzdřenost
oStriktně rozlišujeme vnějšek a vnitřek třídy
nVnitřní atributy, metody a rozhraní nejsou z vnějšku viditelné
nVnějškem třídy se rozumí komunikace mezi objekty
oZákladní výhody objektových metod. Proč?
nMáme-li příliš složitý problém, snažíme se jej rozložit
nRozkládáme tedy problém na nižší objekty, třídy
oJaký je zde rozdíl oproti strukturované metodě?
nStrukturované metody – jednotlivé dekompozice dle
pohledů.
nObjektově – celek včetně metod, atributů a dědičností
n
n
43
>
Princip rozhraní se zapouzdřením
44
Atributy
Atributy
Metody
Metody
Komunikace
Zapouzdření a rozhraní
Rozhraní: množina informací, které o sobě třída zveřejní
Public Interface Moje_Rozhraní { }
…
Public Class Moje_Třída implements Moje_Rozhraní { }
>
Postup
oProvede se dekompozice až do tříd
oDefinují se třídy a jejich rozhraní
oPak se jde dovnitř tříd
oKdyž se ukáže, že je třeba rozhraní dodefinovat, provede se iterace s případnou úpravou tříd a
rozhraní
oPoznámka:
nTřídy v různých metodikách mohou být ekvivaletní objektům v UML.
45
>
Abstrakce
46
Zdroj: Řepa
>
Generalizace a specializace
oGeneralizace
nObjekt vyšší úrovně je nositelem společných vlastností
nTento objekt je nadtypem svého podtypu
nJednotlivé podtypy jsou navzájem disjunktní
oSpecializace
nPředstavuje zjemnění třídy do podtřídy
n
47
>
Záměna výskytů za jejich abstrakce
oZobecněním – generalizací provádím abstrakci a definici vyšší úrovně
oPříklad:
nMáme nastavená pravidla jak tvořit obchodní zakázky
nKaždá zakázka tím získává určité atributy
nKaždá zakázka je zpracovávána v podstatě stejným způsobem
nZobecnění pro všechny zakázky daného typu – generalizace
nVýsledek : třída zakázek definující pravidla týkající se výskytů všech zakázek daného typu.
48
>
Příklad generalizace
49
>
Jiný příklad
oČlověk
nSkládá se
oKostry
oSvalů
oVnitřních orgánů atd.
nAvšak: tato statická definice nic neříká o funkcích jednotlivých orgánů
nSrdce pohání krev
nKrev se okysličuje v plicích
nAtd.
oJeště vyšší úroveň generalizace: třída savců atd.
n
50
>
Modely používané v OO metodikách
oModel tříd a stavový model
nPopisuje objektový pohled na realitu
oProcesní model
nKlíčové procesy a jejich produkty
oFunkční model
nKlíčové funkce
oStruktura technologie
oProcesně-technologický
nUmístění logických komponent na fyzických komponentách
51
>
Modely při objektovém návrhu IS
52
>
Děkuji za pozornost.
Otázky?