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?