Návrh řešení IS Vývoj informačních systémů
Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel IS a jaký provozovatel IS jaký čas se ušetří jaké prostředky se ušetří jaké nové služby bude možné realizovat Kolik to bude stát a kdo to zaplatí investice provoz systému Dá se převzít nebo modifikovat již existující řešení? Jaká bude kooperace a kompatibilita s jinými systémy Jaké požadavky budou na systém kladeny v budoucnu
Popis problému (strukturovaný) Účel projektovaného systému prvky systému - podstatné znaky, odlišení od okolí, vztah k již existujícím systémům funkce (procesy) systému a typy řešených úloh Kdo budou uživatelé systému, dodavatelé a odběratelé informací návrh možných alternativ řešení a výběr té, která se bude realizovat (vymezení hranic projektu)
Specifikace požadavků Výstupem bude zdokumentovaný popis vlastností, služeb nebo omezení IS: Funkční požadavky: co a jak má IS dělat Ostatní požadavky: pro koho a s jakým omezením (bezpečnost, cena, datový rozsah, ) Specifikace stanoví požadavky, ale neobsahuje návrh řešení ani neřeší obchodní vztahy mezi zadavatelem a řešitelem
Obvyklé požadavky na IS Výstupy Jaké služby (informace, odpovědi na dotazy) Jaké produkty mají být výstupem Vstupy (zdroje) Vstupní data, informace Zadávání požadavků, dotazů Procesy Jaké mají běžet procesy (např. Získávání, zpracování, zaznamenávání, konverze, třídění, vyhledávání, uložení, přenos, zpřístupnění) informací
Praktická poznámka Při formulaci požadavků je třeba dbát na to, aby bylo možné zkontrolovat jejich splnění (při oponenturách, při předávání systému). Vhodné je současně s formulací každého požadavku na funkcionalitu definovat: jeho uživatele, vazbu na ostatní požadavky jeho relativní významnost (např. priorita nebo rozdělení požadavků podle důležitosti na povinné, žádoucí a vhodné) míru rizika, vyplývající např. z technické náročnosti řešení.
Osvědčilo se pro stanovení požadavků zformulujte otázky, na něž má systém poskytovat odpovědi pojmenujte problémy, které má systém pomoci vyřešit určete procesy (činnosti), jež má systém podporovat
Data Jaký objem dat má procházet systémem? Jaká bude velikost BZ systému? Jak často budou data vstupovat do systému a jak často budou vystupovat? Jaký formát mají mít data pro vstupy a výstupy? Jaké jsou požadavky na utajení? S jakým stupněm přesnosti mají být prováděny výpočty? Která data mají být uchovávána?
Fyzické prostředí Kde má systém fungovat? Jedná se o jedno nebo o více míst? Jsou nějaká omezení či požadavky na prostředí, např. teplota, vlhkost vzduchu, prašnost, magnetická interference? Jsou nějaká omezení na OS, multiprocessing, síťové vlastnosti?
Okolí systému, V/V Přicházejí vstupy z jednoho nebo z více okolních systémů? Jaké formáty? Odcházejí výstupy do jednoho nebo do více dalších systémů? Jaké formáty? Je předepsáno časování? Je předepsáno médium, resp. protokoly, kterých má být použito pro uložení a přenos dat?
Materiální a lidské zdroje Existuje závazný harmonogram vývoje? Jaký materiál, personál nebo jiné zdroje jsou požadovány k návrhu, vytvoření, užívání a správě systému? Jaké znalosti a dovednosti musí mít vývojáři? Kolik fyzického prostoru zabere systém? Jaké jsou požadavky na energii, vytápění nebo klimatizaci? Je stanoven limit finanční částky, již lze věnovat na vývoj, na hardware a na software?
Bezpečnost Musí být přístup k systému nebo k informacím kontrolován (sledován)? Jaké budou bezpečnostní strategie? Jaké budou požadavky na utajení a integritu dat? Jak často se bude systém zálohovat? Musí být záložní kopie uloženy na odděleném místě? Mají být přijata opatření proti ohni, vodě nebo loupeži?
Kvalitativní požadavky Jaké požadavky jsou stanoveny na spolehlivost, dostupnost, správu, bezpečnost systému? Jak mají být charakteristiky systému demonstrovány okolí? Má systém detekovat a izolovat chyby? Jaký je předepsaný průměrný čas mezi dvěma zhrouceními systému? Je stanoven časový limit k restartu systému po zhroucení?
(pokrač.) Bude systém schopen akceptovat dodatečné změny v návrhu? Budou se v průběhu správy systému pouze opravovat chyby nebo také zlepšovat systém? Jaká měřítka efektivnosti budou uplatněna na využívání zdrojů a čas odezvy? Uvažuje se o přenesení systému z jednoho místa na druhé nebo z jednoho typu počítače na jiný?
Požadavky na dokumentaci Jaké množství dokumentace je požadováno? Má být online, písemná nebo obojí? Pro jaké skupiny uživatelů jsou jednotlivé typy dokumentace určeny?
Analýza a návrh IS Jakmile je korektně dokončen strukturovaný popis problému, lze přikročit k návrhu řešení. Návrh může mít vcelku libovolnou formu. Osvědčilo se použití Konceptuálního modelu Logického modelu
Konceptuální model datový model (ERA diagram) diagram datových toků diagram tříd
Logický model logická - fyzická struktura dat pro konkrétní software a hardware slovník dat (data dictionary) např. schéma relační databáze a definice integritních omezení
Definování komponent IS Use case diagram Diagram aktivit Diagram tříd Datový model (ERA diagram) Stavový diagram
Use Case model Zobrazení dynamické (funkční) struktury systému z pohledu uživatele. Slouží k definici chování systému, aniž by musel nutně specifikovat jeho vnitřní strukturu. Definuje soubor scénářů pro používání systému. Každý scénář obsahuje sekvenci (posloupnost) událostí, které v jeho rámci probíhají (včetně případných variant) popis interakce (komunikace) mezi uživatelem (aktorem) a systémem
Základní bloky Use Case Případ užití, scénář, činnost Aktor, účastník Vazba, asociace mezi aktorem a činností
Diagram aktivit Reprezentuje strukturu (dynamiku) procesů v systému, především jeho vnitřní chování. Zobrazuje řídící toky (přechody) mezi aktivitami systému. Od jednoho počátečního bodu po jeden nebo více koncových bodů Zobrazuje pořadí aktivit.
Základní bloky start konec přechod rozhodování větvení a spojování
Diagram tříd Zobrazení statické struktury systému prostřednictvím tříd a vztahů mezi nimi. Třída (class) sdružuje objekty se společnými vlastnostmi a chováním (sdílejí stejné atributy, operace, vztahy a sémantiku) Atribut charakterizuje vlastnost objektu Operace (metoda) objektu definuje jeho chování
Zvláštní druhy funkcí objektu constructor: vytvoření instance třídy, tj. objektu (CREATE) get: čtení hodnoty atributu (READ) set: editace hodnoty atributu (UPDATE) destructor: zničení objektu (DELETE)
Viditelnost atributů - private (soukromý) pouze pro danou třídu # protected (chráněný) pouze pro danou třídu a její dětské třídy nebo objekty * package pouze pro objekty obsažené ve stejném balíčku (package) + public (veřejný) pro všechny objekty
Typy tříd Model: objekty reprezentované třídou obsahují a zpracovávají data View: tyto objekty aktoři k interakci se systémem Controller: definují způsob reakce uživatelského rozhraní na uživatelský vstup
Asociace Obecný vztah mezi prvky modelu, specifikuje spojení mezi jejich instancemi
Agregace vyjadřuje vztah celek jeho část
Kompozice silnější vazba než agregace - zrušením kontejneru automaticky zrušíme i obsažený element; daný element může být součástí právě jednoho kontejneru
Dědičnost (generalizace) třída - potomek dědí atributy a operace třídy předka Vedle toho může mít potomek ještě své specifické vlastnosti zděděné vlastnosti mohou být v potomkovi modifikovány
Závislost změna jednoho (nezávislého) elementu ovlivní druhý (závislý) element
Realizace souhrn všech veřejně přístupných metod dané třídy umožňuje vícenásobné využití operací, aniž bychom museli zavádět dědičnost mezi třídami
Násobnost (multiplicita, kardinalita) vztahů v diagramu tříd 0..* 0 nebo více 0..1 0 nebo 1 1..* 1 nebo více 5,10,25 5 nebo 10 nebo 25
Datový model (ERA diagram) E = Entity R = Relationship A = Attribute V softwarovém inženýrství používá pro abstraktní a konceptuální znázornění dat
Entita Entita se dá definovat jako věc schopná samostatné existence a je jednoznačně identifikovatelná. Entita může být fyzicky existující objekt, nebo událost, nebo může jít o pojem. Správnější by bylo, rozlišovat entitní typ a jeho instanci. V praxi se to ale nedělá.
Vztah Vztah (relationship) zachycuje, jakým způsobem jsou dvě nebo více entit vztažené mezi sebou. Vztahy se označují slovesy, spojujícími dvě nebo více podstatných jmen. Vztahy se zobrazují jako kosočtverce propojené čárami vedoucími ke každé entitě vztahu.
Atribut Jak entity, tak i vztahy mohou obsahovat atributy. Atributy se zobrazují jako elipsy propojené čarou s jejich vlastnící entitou. Každá entita musí mít nejméně tolik atributů, aby byla za všech okolností jednoznačně identifikovatelná, jde o tzv primární klíč.
Příklad ERA diagramu
Stavový diagram Popisuje stav objektu a povolených přechodů mezi těmito stavy, případně popisuje celý životní cyklus objektu. Definuje podmínky, za kterých dochází k přechodu mezi stavy. Stav = hodnota nějakých atributů (tzv. stavové atributy)
Základní bloky start konec stav přechod větvení, spojová- ní
Nástroje CASE CASE jsou softwarové nástroje, které podporují tvorbu softwaru V minulosti to byl každý program, který poskytuje podporu při návrhu, údržbě softwaru, nebo procesu vývoje softwaru (softwarového projektu). Podle této definice CASE nástroj je i překladač, editor, ladící prostředek...
(pokrač.) Nyní jsou to především systémy integrovaných nástrojů, které pokrývají více než jednu fázi životního cyklu softwaru. CASE nástroje vznikly jako prostředek pro zmírnění softwarové krize. Umožňují menšímu počtu programátorů" vytvářet více programů". Takto vytvořené programy by měly být spolehlivější, snadněji modifikovatelné a udržovatelné.
Problémy s CASE nástroji Podcenění školení a potřeby adaptace současných softwarových procesů Neopodstatněný optimizmus (CASE vyřeší všechny problémy). CASE prostředek v rukách slabého softwarového inženýra mu umožní vytvářet více špatného softwaru. Zatím je nedostatečná integrace CASE prostředků. CASE prostředky jsou drahé a je potřeba s tím počítat.
Děkuji za pozornost.