Objektová analýza a projektování IS. Projektování IS Projektování IS je hledání vnitřní (abstraktní) struktury a vnějších vztahů reálného (existujícího.

Prezentace na téma: "Objektová analýza a projektování IS. Projektování IS Projektování IS je hledání vnitřní (abstraktní) struktury a vnějších vztahů reálného (existujícího."— Transkript prezentace:

1 Objektová analýza a projektování IS

2 Projektování IS Projektování IS je hledání vnitřní (abstraktní) struktury a vnějších vztahů reálného (existujícího nebo požadovaného) systému a jeho modelování tak, aby šlo: Projektování IS je hledání vnitřní (abstraktní) struktury a vnějších vztahů reálného (existujícího nebo požadovaného) systému a jeho modelování tak, aby šlo: –Účelně organizovat datovou základnu firmy (transakční systémy). –Sledovat, ukládat a interpretovat co neobjektivnější obraz o stavu a vývoji firmy (operativní a taktické řízení). –Z informací získávat znalosti a zpětně působit na chování firmy žádoucím směrem (strategické řízení). Projektování IS vychází z reálně existujících elementů (zákazník, objednávka) a jejich vztahů. Tyto prvky se popíšou, formalizují a uspořádají pomocí modelování. Projektování IS vychází z reálně existujících elementů (zákazník, objednávka) a jejich vztahů. Tyto prvky se popíšou, formalizují a uspořádají pomocí modelování.

3 Charakteristika projektování IS a význam modelování pro projekt Základními myšlenkovými postupy jsou analýza a syntéza. Základními myšlenkovými postupy jsou analýza a syntéza. Základními nástroji projektování IS je systémová analýza a modelování. Základními nástroji projektování IS je systémová analýza a modelování. Modelování je vyjádření různých pohledů na systém standardizovanými a formalizovanými prostředky. Modelování je vyjádření různých pohledů na systém standardizovanými a formalizovanými prostředky. Modelování SW je tvorba obrazu budoucího systému, která má za účel jeho úplné pochopení všemi účastníky. Modelování SW je tvorba obrazu budoucího systému, která má za účel jeho úplné pochopení všemi účastníky. Proč modelování? Proč modelování? –Usnadnění komunikace v týmu se zákazníkem. –Diverzifikace a koordinace práce. –Přehled o aktuálním stavu projektu. –Generování částí/prototypů výsledného produktu. –Vytváření dokumentace. –Případně testování modulů.

4 Princip tří architektur Princip hierarchické abstrakce Definuje modelování jako postupnou tvorbu tří typů architektur (logických úrovní modelu, architektur modelů IS), každá úroveň má jinou: Definuje modelování jako postupnou tvorbu tří typů architektur (logických úrovní modelu, architektur modelů IS), každá úroveň má jinou: –Míru abstrakce –Logiku –Hloubku popisu. Konceptuální úroveň – CO? Konceptuální úroveň – CO? Technologická úroveň – JAK? Technologická úroveň – JAK? Fyzická úroveň – ČÍM? Fyzická úroveň – ČÍM?

5 Abstraktní oblouk Abstraktní myšlení je neodmyslitelná vlastnost člověka. Každý člověk jej však má v různé míře a jednotlivé obory vyžadují jeho různou míru. Abstraktní myšlení je neodmyslitelná vlastnost člověka. Každý člověk jej však má v různé míře a jednotlivé obory vyžadují jeho různou míru. Abstraktní myšlení má vždy tři hlavní fáze: Abstraktní myšlení má vždy tři hlavní fáze: –Nahrazení velkého množství konkrétních prvků jedním nebo několika abstraktními pojmy. –Přepracování abstraktních pojmů podle našich požadavků a pro náš účel. –Aplikace abstraktních pojmů na velké množství konkrétních situací. Celku říkáme abstraktní oblouk – z konkrétna přes abstraktno do konkrétna. Tento postup se běžně aplikuje na výstavbu přehrad, definice organizace podniku i na projektování informačních systémů. Budeme se zde zabývat objektovým pohledem na řešení problémů v oblasti informačních systémů. Celku říkáme abstraktní oblouk – z konkrétna přes abstraktno do konkrétna. Tento postup se běžně aplikuje na výstavbu přehrad, definice organizace podniku i na projektování informačních systémů. Budeme se zde zabývat objektovým pohledem na řešení problémů v oblasti informačních systémů.

6 Abstrakce Záměna konkrétních objektů za abstraktní pojmy (třídy) Záměna konkrétních objektů za abstraktní pojmy (třídy) –Z provozních důvodů je významné to, že místo abychom se zabývali stovkami či tisíci konkrétních prvků, zabýváme se jen několika abstraktními pojmy. Práce s abstraktními pojmy je těžší oproti práci s konkrétními prvky, jestliže je však konkrétních prvků hodně, celková režie je menší při použití abstrakce. Toto (snížení nákladů) je vlastně jediným ospravedlněním existence objektového přístupu. Charakteristika tříd pomocí dat a procesů Charakteristika tříd pomocí dat a procesů –Různá odvětví lidské činnosti používají různé prostředky k vyjádření abstrakcí, například matematika používá, kromě jiného, rovnice. Informatika řeší široké spektrum problémů, od úklidu odpadků až po meziplanetární lety. K tomu bylo třeba nalézt vhodný prostředek pro vyjádření abstrakce, který by však měl blízko k realizaci. Takovým přímo „zázračným” prostředkem je koncept tříd (abstrakta) a objektů (konkrétna). Třída je charakterizována hodnotami (atributy) a chováním (metodami). Atributy popisují statické vlastnosti třídou representovaných konkrétních jevů (statičnost v této souvislosti neznamená neměnnost, ale to, že atribut nemůže měnit sám sebe ani jiné prvky třídy). Metody popisují funkčnosti třídou representovaných konkrétních jevů i jejich chování navenek (mohou měnit atributy své třídy i atributy jiných tříd, ve složitějších případech mohu měnit i jiné metody). Dá se říci, že metody určují proměnlivost atributů a jiných tříd v čase.

7 Třídy Rozdíly mezi projektovými a implementačními třídami Rozdíly mezi projektovými a implementačními třídami –Při naivním pohledu je projekční třída obdélníček s názvem a výčtem atributů a metod. Není tomu tak. Tříd je několik druhů (analytické, návrhové, implementační), každý druh má jiné vlastnosti a jiný popis. Například implementační třída (část programu) má metody napsány ve tvaru procedur, tj. jako posloupnost příkazů, které plně určují její funkčnost. Oproti tomu analytická třída má jen název metody a (většinou) její parametry, funkčnost musí být vyjádřena jinými prostředky. –Logickou integrální součásti projektové třídy musí být upřesnění (descriptions, constraints). Jsou to slovní popisy, které určují smysl a efekty jednotlivých prvků. Mnoho je určeno již názvy a kontextem, ale ne vše.

8 Zapouzdřenost objektů Zapouzdřenost znamená, že striktně rozlišujeme vnitřek a vnějšek třídy (objektu). Rozlišujeme vnitřní (z vnějšku neviditelné) atributy a metody a rozhraní třídy - atributy a metody viditelné z vnějšku. Vnějškem třídy (objektu) rozumíme mezi objektovou komunikaci. Rozlišujeme vnitřní (z vnějšku neviditelné) atributy a metody a rozhraní třídy - atributy a metody viditelné z vnějšku. Vnějškem třídy (objektu) rozumíme mezi objektovou komunikaci. Základní premisa tvorby složitých systémů je tato: Jestliže problém je příliš složitý, aby šel zvládnout jako celek, rozložme jej na větší množství jednodušších problémů, které lze jednotlivě zvládnout. Jestliže problém je příliš složitý, aby šel zvládnout jako celek, rozložme jej na větší množství jednodušších problémů, které lze jednotlivě zvládnout. Poznámka: Jiný způsob zvládnutí složitých problémů vlastně neexistuje. Podobně systém N rovnic o N neznámých určitými úpravami změníme na N rovnic o jedné neznámé. Poznámka: Jiný způsob zvládnutí složitých problémů vlastně neexistuje. Podobně systém N rovnic o N neznámých určitými úpravami změníme na N rovnic o jedné neznámé. Schématicky to můžeme popsat takto: jestliže jsme složitý řešený problém rozdělili na N tříd, pak vzniklo 2N+1 jednodušších problémů: Schématicky to můžeme popsat takto: jestliže jsme složitý řešený problém rozdělili na N tříd, pak vzniklo 2N+1 jednodušších problémů: –N rozhraní ustavených tříd (rozhraní je množina veřejných (z vnějšku viditelných) atributů a metod); –jeden systém komunikace mezi třídami; –N vnitřků tříd (tj. definice vnitřních (soukromých) atributů a metod).

9 Zapouzdřenost objektů Poznámka 1 Skutečně složité systémy nelze uspokojivě vyřešit jednou úrovní takového rozkladu (buď by byla příliš složitá komunikace mezi třídami nebo by byly příliš složité vnitřky některých tříd). Nic však nebrání tomu, aby se tento rozklad použil několikrát (hierarchicky). V praxi se však zavedla (snad z historických důvodů) rozdílná terminologie pro jednotlivé úrovně. Celý složitý systém se dělí na podsystémy (ovšem podsystém je charakterizován svou funkčností a rozhraním podobně jako třída), ty se zase dělí na podsystémy a teprve podsystémy nejnižší úrovně se vytvářejí z tříd. Při realizaci se vytvářejí třídy, z nich se skládají podsystémy nejnižší úrovně, z nich složitější podsystémy - až se složí systém. Skutečně složité systémy nelze uspokojivě vyřešit jednou úrovní takového rozkladu (buď by byla příliš složitá komunikace mezi třídami nebo by byly příliš složité vnitřky některých tříd). Nic však nebrání tomu, aby se tento rozklad použil několikrát (hierarchicky). V praxi se však zavedla (snad z historických důvodů) rozdílná terminologie pro jednotlivé úrovně. Celý složitý systém se dělí na podsystémy (ovšem podsystém je charakterizován svou funkčností a rozhraním podobně jako třída), ty se zase dělí na podsystémy a teprve podsystémy nejnižší úrovně se vytvářejí z tříd. Při realizaci se vytvářejí třídy, z nich se skládají podsystémy nejnižší úrovně, z nich složitější podsystémy - až se složí systém. Poznámka 2 V praxi se obvykle používá tento postup: V praxi se obvykle používá tento postup: –Nejdříve se definují třídy a jejich rozhraní. –Pak se vytvoří systém komunikace mezi třídami. –Samozřejmě při tvorbě komunikace mezi třídami se musí občas změnit rozhraní tříd či některé třídy dodefinovat, čili probíhá iterace těchto dvou kroků. Tomu se říká analýza. Pak nastupuje design - návrh: –Definují se vnitřní metody a atributy, obvykle to je svázáno s následnou definicí podrobnějších tříd (jedna analytická třída se rozpadne na několik designových tříd). –Nastupuje realizace: –Realizace tříd (tj. realizace všech jejich atributů a metod). –Spojování tříd do podsystémů a těch do celkového systému, této fázi realizace se obvykle říká integrace.

10 Metodika obecně Chceme-li řešit složitý problém, musíme si nejdříve rozmyslet, co a jak budeme dělat. A právě metodika je formalizovaný předpis, jak si to rozmyslet. Nemůžeme dělat vše najednou - psát řešení a současně si ujasňovat, co vlastně chceme řešit, nemůžeme po napsání řešení přemýšlet, jak to vlastně budeme řešit. Právě proto je abstraktní oblouk členěn na čtyři základní části – viz obrázek. Určit zadání. Uživatel definuje zadání, to však (kupodivu) nestačí. Je zapotřebí, aby zadání dotvořil informatik. Uživatel je odborník ve své profesi, pohlíží na celou úlohu ze svého pohledu a mnoho problémů nevidí. Určit logiku řešení a dotvořit zadání. Na základě zadání určíme, co budeme řešit. Nejprve musíme určit CO budeme řešit a teprve až to je jasné, budeme přemýšlet JAK! Jinak dostaneme systém, který sice funguje, řeší však něco jiného, než je zapotřebí. Naplánujeme si realizaci. Na základě logiky řešení určujeme jak budou jednotlivé věci řešeny a kdy budou řešeny. Realizace. Nakonec systém realizujeme. Je na nás, na kapacitě našeho mozku a na složitosti úlohy, jestli všechny fáze dokumentujeme pomocí modelů, nebo jestli je provádíme pouze ve své mysli. Pokud pracujeme v týmu, je rozumná dokumentace nutná.

11 Více pohledů na totéž Při tvorbě velkých a složitých systémů nelze celek zvládnout najednou, musíme jej rozložit na více menších problémů. Jedním ze způsobů vyrovnání se s touto problematikou je rozdělení celého problému na menší díly, ty řešit samostatně a jednotlivá dílčí řešení integrovat do řešení celého velkého systému. Jestliže se však zabýváme řešením (relativně) malých částí, velmi dobře řešíme závislosti uvnitř jedné části, avšak ztrácíme ze zřetele závislosti probíhající celým systémem (mezi jednotlivými částmi). Zanedbání takových globálních závislostí může způsobit těžko opravitelné chyby. Při tvorbě velkých a složitých systémů nelze celek zvládnout najednou, musíme jej rozložit na více menších problémů. Jedním ze způsobů vyrovnání se s touto problematikou je rozdělení celého problému na menší díly, ty řešit samostatně a jednotlivá dílčí řešení integrovat do řešení celého velkého systému. Jestliže se však zabýváme řešením (relativně) malých částí, velmi dobře řešíme závislosti uvnitř jedné části, avšak ztrácíme ze zřetele závislosti probíhající celým systémem (mezi jednotlivými částmi). Zanedbání takových globálních závislostí může způsobit těžko opravitelné chyby. Lepší způsob, jak velký celek rozdělit na menší části a nezanedbat přitom tyto globální závislosti, je uvádění více pohledů na tentýž systém. Praxe vyvinula mnoho různých pohledů na systém, určitý přehled přes možnosti dávají „modely“, které jsou uváděny v grafických jazycích - například UML má 8 typů modelů, což naznačuje, že existuje alespoň osm různých pohledů na systém, které jsou zavedeny v praxi. Podle typu závislostí, kterým se chceme věnovat, vybereme příslušný model. Lepší způsob, jak velký celek rozdělit na menší části a nezanedbat přitom tyto globální závislosti, je uvádění více pohledů na tentýž systém. Praxe vyvinula mnoho různých pohledů na systém, určitý přehled přes možnosti dávají „modely“, které jsou uváděny v grafických jazycích - například UML má 8 typů modelů, což naznačuje, že existuje alespoň osm různých pohledů na systém, které jsou zavedeny v praxi. Podle typu závislostí, kterým se chceme věnovat, vybereme příslušný model.

12 Více pohledů na totéž Rozdělení problému na části je realizační přístup, tj. táhne se od analýzy přes design až do implementace - ve svých důsledcích vede k tomu, že se nejdříve vytvářejí jednotlivé třídy, jejichž objekty jsou pak spojeny v systém. Rozdělení problému na části je realizační přístup, tj. táhne se od analýzy přes design až do implementace - ve svých důsledcích vede k tomu, že se nejdříve vytvářejí jednotlivé třídy, jejichž objekty jsou pak spojeny v systém. Oproti tomu pohledy jsou nástrojem analýzy - neprojevují se v implementaci přímo. V zásadě se to dělá tak, že je jeden pohled základní (obvykle statický – model tříd), všechny ostatní pohledy (modely) jsou pracovní. Běžně to znamená, že s modelem pracuji tak dlouho, dokud nejsem v jistém smyslu uspokojen (model již nepřináší nic nového). Pak poznatky z tohoto modelu promítnu do základního modelu. Znamená to, že globální závislosti zjištěné v pomocném modelu se promítnou jako atributy, metody nebo rozhraní jednotlivých tříd. Oproti tomu pohledy jsou nástrojem analýzy - neprojevují se v implementaci přímo. V zásadě se to dělá tak, že je jeden pohled základní (obvykle statický – model tříd), všechny ostatní pohledy (modely) jsou pracovní. Běžně to znamená, že s modelem pracuji tak dlouho, dokud nejsem v jistém smyslu uspokojen (model již nepřináší nic nového). Pak poznatky z tohoto modelu promítnu do základního modelu. Znamená to, že globální závislosti zjištěné v pomocném modelu se promítnou jako atributy, metody nebo rozhraní jednotlivých tříd.

13 Modely Model tříd je centrálním modelem většiny projektovaných systémů. Téhož aparátu se také používá při tvorbě datového modelu (namísto ERD notace), kontextového modelu (popisuje okolí vytvářeného systému), pojmového modelu (úvodního intuitivního modelu) a i objektového modelu (ve smyslu modelu instancí tříd), který se spíše používá v pedagogice než v projektování. Model tříd je centrálním modelem většiny projektovaných systémů. Téhož aparátu se také používá při tvorbě datového modelu (namísto ERD notace), kontextového modelu (popisuje okolí vytvářeného systému), pojmového modelu (úvodního intuitivního modelu) a i objektového modelu (ve smyslu modelu instancí tříd), který se spíše používá v pedagogice než v projektování. Model jednání popisuje interakci s vytvářeným systémem a jeho bezprostřední okolí. Často to bývá výchozí model projektování. Model jednání popisuje interakci s vytvářeným systémem a jeho bezprostřední okolí. Často to bývá výchozí model projektování. Přechodový model (stavový) je hodně starý prostředek. Slouží k plnému popisu dynamiky určitého systému. Protože se jedná o úplný popis, nemůže být popisovaný systém příliš velký - většinou slouží k popisu tříd. Přechodový model (stavový) je hodně starý prostředek. Slouží k plnému popisu dynamiky určitého systému. Protože se jedná o úplný popis, nemůže být popisovaný systém příliš velký - většinou slouží k popisu tříd. Model spolupráce popisuje průběh dynamiky mezi instancemi tříd (mezi objekty) - soustředí se na vazby mezi instancemi (kdo s kým). Model spolupráce popisuje průběh dynamiky mezi instancemi tříd (mezi objekty) - soustředí se na vazby mezi instancemi (kdo s kým).

14 Modely Interakční model (Sequence model) soustředí pozornost na časovou posloupnost impulsů (událostí). Interakční model (Sequence model) soustředí pozornost na časovou posloupnost impulsů (událostí). Diagram aktivit, (Activity diagram) je universální prostředek pro popis dynamických modelů - jak pro vlastní popis procesů, tak pro popis vztahů mezi procesy a třídami. Používá se pro zápis „business“ procesů (procesů vně vytvářeného systému), scénářů (scénářů komunikace mezi vytvářeným systémem a jeho vnějškem) i libovolných procesů uvnitř i vně systému. Diagram aktivit, (Activity diagram) je universální prostředek pro popis dynamických modelů - jak pro vlastní popis procesů, tak pro popis vztahů mezi procesy a třídami. Používá se pro zápis „business“ procesů (procesů vně vytvářeného systému), scénářů (scénářů komunikace mezi vytvářeným systémem a jeho vnějškem) i libovolných procesů uvnitř i vně systému. Model komponent určuje stavební vztahy - vztahy mezi technickými částmi systému, například mezi zdrojovými programy a exekutivními částmi. Model komponent určuje stavební vztahy - vztahy mezi technickými částmi systému, například mezi zdrojovými programy a exekutivními částmi. Model rozmístění (Deployment model) určuje vztah mezi softwarovými prvky systému a hardwarovými prvky - zjednodušeně popisuje rozmístění vytvářeného systému na počítače. Model rozmístění. Model rozmístění (Deployment model) určuje vztah mezi softwarovými prvky systému a hardwarovými prvky - zjednodušeně popisuje rozmístění vytvářeného systému na počítače. Model rozmístění.

15 Asociace (opakování) Vyjadřuje fakt, že objekty jsou mezi sebou ve vzájemném vztahu. Asociace mezi dvěma objekty mohou být jednosměrné i obousměrné. Směr asociace se znázorňuje vybarveným trojúhelníkem u názvu asociace. Každá třída hraje v asociaci určitou roli. Role se zapisují na konce asociace ke třídám, s nimiž souvisejí. Asociaci může být přiřazeno určité pravidlo, omezující podmínka. Je pak umístěna ve složených závorkách. Násobnost asociace vyjadřuje, kolik objektů jedné třídy se vztahuje ke kolika objektům druhé třídy. Konkrétní počet se zapisuje konkrétním číslem (popř. intervalem), neurčitý počet (N) se značí také hvězdičkou. Jestliže jsou dvě třídy ve vztahu 1:0 nebo 1:1, je druhá třída pro první třídu volitelná (nepovinná). Kvalifikátor u třídy určuje, podle jakého atributu se v asociaci vyhledává (např. ve vazbě 1:M kvalifikátor říká, podle kterého atributu se konkrétní objekt ve vazbě z M objektů druhé třídy vyhledá). Znázorňuje se v obdélníku vedle třídy, kde se vyhledávání provádí, z něho pak pokračuje asociační čára. Asociace může být tzv. reflexivní. Jedná se o asociaci mezi jednou a tou samou třídou. Nastává to v případech, kdy objekt třídy může “hrát” více rolí. Asociace může mít atributy a metody, jedná se pak o asociační (vazební) třídu. Asociační třída je spojena s asociací čárkovanou čarou. Vyjadřuje fakt, že objekty jsou mezi sebou ve vzájemném vztahu. Asociace mezi dvěma objekty mohou být jednosměrné i obousměrné. Směr asociace se znázorňuje vybarveným trojúhelníkem u názvu asociace. Každá třída hraje v asociaci určitou roli. Role se zapisují na konce asociace ke třídám, s nimiž souvisejí. Asociaci může být přiřazeno určité pravidlo, omezující podmínka. Je pak umístěna ve složených závorkách. Násobnost asociace vyjadřuje, kolik objektů jedné třídy se vztahuje ke kolika objektům druhé třídy. Konkrétní počet se zapisuje konkrétním číslem (popř. intervalem), neurčitý počet (N) se značí také hvězdičkou. Jestliže jsou dvě třídy ve vztahu 1:0 nebo 1:1, je druhá třída pro první třídu volitelná (nepovinná). Kvalifikátor u třídy určuje, podle jakého atributu se v asociaci vyhledává (např. ve vazbě 1:M kvalifikátor říká, podle kterého atributu se konkrétní objekt ve vazbě z M objektů druhé třídy vyhledá). Znázorňuje se v obdélníku vedle třídy, kde se vyhledávání provádí, z něho pak pokračuje asociační čára. Asociace může být tzv. reflexivní. Jedná se o asociaci mezi jednou a tou samou třídou. Nastává to v případech, kdy objekt třídy může “hrát” více rolí. Asociace může mít atributy a metody, jedná se pak o asociační (vazební) třídu. Asociační třída je spojena s asociací čárkovanou čarou. Vazba (link) Vazba (link) –Jedná se o instanci asociace, jinými slovy o vazbu mezi objekty.

16 Agregace (opakování) Během návrhu se asociace upřesňují do podoby agregace resp. kompozice (celek/součást). Během návrhu se asociace upřesňují do podoby agregace resp. kompozice (celek/součást). Agregace je zvláštním typem asociace. Znázorňuje složení objektů jedné třídy z objektů jiných tříd (objekt je agregací objektů jiných tříd). Znázorňuje se kosočtvercem na konci čáry (u agregované třídy). Agregace je volnou vazbou mezi objekty (počítač a periferní zařízení). Agregace je zvláštním typem asociace. Znázorňuje složení objektů jedné třídy z objektů jiných tříd (objekt je agregací objektů jiných tříd). Znázorňuje se kosočtvercem na konci čáry (u agregované třídy). Agregace je volnou vazbou mezi objekty (počítač a periferní zařízení). Silnějším typem agregace je kompozice (složenina). U kompozice existuje komponenta (tj. objekt, který tvoří součást agregace/kompozice) pouze uvnitř složeného objektu. Jinými slovy, tato komponenta může patřit pouze jednomu celku. Kompozice se znázorňuje vyplněným kosočtvercem na konci čáry. Silnějším typem agregace je kompozice (složenina). U kompozice existuje komponenta (tj. objekt, který tvoří součást agregace/kompozice) pouze uvnitř složeného objektu. Jinými slovy, tato komponenta může patřit pouze jednomu celku. Kompozice se znázorňuje vyplněným kosočtvercem na konci čáry. Dva prvky agregace mohou být vůči sobě ve vztahu “nebo”. Znamená to, že třída agregující tyto třídy se pak skládá pouze z jedné z nich. Vztah “nebo” se znázorní čárkovanou čarou mezi agregačními čarami. Dva prvky agregace mohou být vůči sobě ve vztahu “nebo”. Znamená to, že třída agregující tyto třídy se pak skládá pouze z jedné z nich. Vztah “nebo” se znázorní čárkovanou čarou mezi agregačními čarami. Příklad kompozice je strom a jeho listy, objednávka a její řádky. Příklad kompozice je strom a jeho listy, objednávka a její řádky.

17 Objektová analýza a návrh Vyvíjela se postupně ze strukturovaného návrhu, nejprve integrací datového a procesního modelu do objektového modelu (Yordon). Vyvíjela se postupně ze strukturovaného návrhu, nejprve integrací datového a procesního modelu do objektového modelu (Yordon). Základním myšlenkovým postupem se stala identifikace objektů jako reálných elementů a vztahů mezi nimi (Booch, Jacobson, Rumbaugh). Základním myšlenkovým postupem se stala identifikace objektů jako reálných elementů a vztahů mezi nimi (Booch, Jacobson, Rumbaugh). Nejznámější objektové programovací jazyky jsou Java, C#, PHP5, Smalltalk,… Nejznámější objektové programovací jazyky jsou Java, C#, PHP5, Smalltalk,… Postavena na principu, že každý systém Postavena na principu, že každý systém –se skládá ze samostatně existujících objektů, které mezi sebou komunikují pomocí zpráv ale jinak jsou navzájem uzavřené, –vykazuje chování, které je odezvou na událost.

18 Objektová analýza a návrh Základním prvkem je objekt jako entita reality, které integruje jak informace sama o sobě (atributy) tak i své chování (metody) a komunikuje s ostatními objekty pomocí zpráv. Základním prvkem je objekt jako entita reality, které integruje jak informace sama o sobě (atributy) tak i své chování (metody) a komunikuje s ostatními objekty pomocí zpráv. Vlastnostmi objektů pak jsou zapouzdření, dědičnost a polymorfismus, které s obecným principem abstrakce umožňují opakované použití komplexních softwarových komponent (re-use). Synergie metod a dat způsobuje, že objekt je jako celek mohutnější, výkonnější a efektivnější než samotné metody a data, ze kterých se skládá. Vlastnostmi objektů pak jsou zapouzdření, dědičnost a polymorfismus, které s obecným principem abstrakce umožňují opakované použití komplexních softwarových komponent (re-use). Synergie metod a dat způsobuje, že objekt je jako celek mohutnější, výkonnější a efektivnější než samotné metody a data, ze kterých se skládá. Typický je přírůstkový přístup k vývoji systému (oproti vodopádovému), který je umožněn zapouzdřením objektů a subsystémů. Typický je přírůstkový přístup k vývoji systému (oproti vodopádovému), který je umožněn zapouzdřením objektů a subsystémů.

19 Základní charakteristiky objektově orientovaného vývoje SW Znovu-použitelnost SW artefaktů (třídy, komponenty, subsystémy, …) díky jejich zapouzdření a komunikaci přes definované rozhraní. Znovu-použitelnost SW artefaktů (třídy, komponenty, subsystémy, …) díky jejich zapouzdření a komunikaci přes definované rozhraní. Komponentový styl vytváření systémů. Komponentový styl vytváření systémů. Snadnější údržba a rozvoj. Snadnější údržba a rozvoj. Implementace i ve vysoce nehomogenním prostředí – snadnější integrace systémů díky vyžadování principu komunikace přes rozhraní. Implementace i ve vysoce nehomogenním prostředí – snadnější integrace systémů díky vyžadování principu komunikace přes rozhraní. Relativně nižší náklady u větších IS díky znovupoužitelnosti (reuse). Relativně nižší náklady u větších IS díky znovupoužitelnosti (reuse).

20 Metodiky a CASE (konkrétní) Metodiky (viz přiložený dokument) Metodiky (viz přiložený dokument) –BOOCH –OMT –JACOBSON –COAD a YOURDON –SELECT PERSPECTIVE –RATIONAL UNIFIED PROCESS –FUSION CASE CASE –SELECT ENTERPRISE 6 –RATIONAL ROSE 2002 –ORACLE DESIGNER 9 –POWER DESIGNER 9 –ENTERPRISE ARCHITECT

21 Specifikace požadavků Specifikace požadavků je 1. fáze návrhu IS a je nástrojem poznání potřeb budoucího uživatele. Specifikace požadavků je 1. fáze návrhu IS a je nástrojem poznání potřeb budoucího uživatele. Cílem je vymezit systém z hlediska požadavků na funkcionalitu, technologie, bezpečnost atd. Je to základ pro veškeré práce na projektu. Cílem je vymezit systém z hlediska požadavků na funkcionalitu, technologie, bezpečnost atd. Je to základ pro veškeré práce na projektu. Modelování podnikových procesů Specifikace požadavků zákazníka Analýza a návrh Implementace Poznání reality Nové potřeby Návrh řešení Realizace

22 Získávání požadavků Zdroje požadavků Zdroje požadavků –Základem jsou interview s pověřenými zástupci zadavatele (předem si připravit otázky, vše zaznamenat, výsledek nechat podepsat). –Studium podnikových norem zákazníka (BPM). –Studium standardů problémových domén. –Vlastní zkušenosti projektanta. Výsledkem je oboustranně schválený dokument. Výsledkem je oboustranně schválený dokument.

23 Specifikace požadavků Při analýze požadavků je nutno zvážit Při analýze požadavků je nutno zvážit –Zaměření věcných činností –Okolí podniku –Legislativu –Strategické plány –Omezení zdrojů (personální, technické, finanční) –Termínová omezení –Rozdělení požadavků na funkční a nefunkční

24 Nefunkční požadavky Požadavky na kvalitu Požadavky na kvalitu Požadavky na použité technologie Požadavky na použité technologie Požadavky na organizaci projektu Požadavky na organizaci projektu Požadavky na formu a obsah dokumentace Požadavky na formu a obsah dokumentace

25 Modelování nefunkčních požadavků Nefunkční požadavky je třeba zaznamenat a neustále je promítat do návrhu řešení Nefunkční požadavky je třeba zaznamenat a neustále je promítat do návrhu řešení Použít katalogový záznam Použít katalogový záznam –Identifikační číslo –Datum poslední změny –Kdo ho požaduje, kdo ho přijímá –Priorita požadavků –Stručný název požadavku –Detailní popis požadavku –Návaznost na další požadavky –Komplexnost/složitost požadavku Např. podpora hotového produktu, po dobu 5 let, data uložená v ORACLE, Odezva systému do 3s u všech operací, provoz na Windows, realizace kontrolních dnů každý měsíc, … Např. podpora hotového produktu, po dobu 5 let, data uložená v ORACLE, Odezva systému do 3s u všech operací, provoz na Windows, realizace kontrolních dnů každý měsíc, …

26 Zásady specifikace požadavků Nepodceňovat žádný požadavek. Nepodceňovat žádný požadavek. Rozlišovat mezi požadavkem a způsobem řešení. Rozlišovat mezi požadavkem a způsobem řešení. V každém požadavku vyjmenovat vše co se požaduje. V každém požadavku vyjmenovat vše co se požaduje. Popsat každý požadavek. Popsat každý požadavek. Nepoužívat technologické pojmy. Nepoužívat technologické pojmy. Formalizovat požadavky. Formalizovat požadavky.