Další doporučená literatura

Transkript

1 Informační systémy a technologie Ivana Rábová Ústav informatiky Tel: rabova@mendelu.cz Další doporučená literatura Rábová I.: IS/IT (úvodní kurz), nyní e-learningová podpora v UIS Rábová I.: Diagramy UML a Rational Rose Basl, Blažíček: Podnikové informační systémy Chlapek, Řepa, Stanovská: Techniky a nástroje vývoje IS Pour a kol.: Informační systémy a elektronické podnikání Voříšek: Strategické řízení informačního systému a systémová integrace Rábová: Podnikové informační systémy a technologie jejich vývoje Základní pojmy Základní pojmy Informace jsou data, kterým jejich uživatel přisuzuje určitý význam a které uspokojují konkrétní objektivní informační potřebu svého příjemce. Informace tedy vznikají z dat až v okamžiku jejich užití. (Informace představuje vypovídací schopnost dat, vzniká zpracováním dat a je cílem tohoto zpracování.) Definice systému Systém je komplex prvků nacházejících se ve vzájemné interakci, Bertalanfy. Systém je účelově definovaná množina prvků a vazeb mezi nimi, které společně určují jeho vlastnosti. Pohledy na informaci Syntaktický pohled (vnitřní struktura informace, souvislost mezi znaky, které ji utváří) Sémantický pohled (obsahový význam informace bez ohledu na vztah k jejímu příjemci) Pragmatický pohled (význam informace pro příjemce, její praktické využití) Informační pyramida (od dat o reálném světě přes informace a znalosti po podnikové vize) Základní pojmy Základní pojmy Informační systém (IS) je komplex informací, lidí, použitých informačních technologií, organizace práce, řízení chodu systému (zabezpečuje propojení na prostředí) a metod sloužících ke sběru, přenosu, uchování a dalšímu zpracování dat za účelem tvorby a prezentace informací. IS Je nějakým způsobem organizován a začleněn do organizační struktury podniku, má určité ekonomické charakteristiky a musí být určitým způsobem řízen jak v době jeho budování tak v době jeho fungování. Aplikační software (ASW) je systém, jehož cílem je počítačová podpora částí informačních systémů (ERP). Obsah IS můžeme vyměřit těmito hlavními charakteristikami: Funkcemi, funkcionalitou IS (hierarchicky uspořádaný souhrn všech operací s daty). Procesy, které podporuje. IS by měl v co největší míře podporovat optimalizaci podnikových procesů (procesní řízení firmy). Daty, datovými zdroji, které jsou předmětem zpracování v rámci funkcí a procesů IS. Jiný přístup Každý IS se skládá ze tří částí: Lidé (osoby, které vyvíjí aktivity spojené s IS a jeho zabezpečením), data (předmět zpracování v IS) a technologie (soubor nástrojů, metod a znalostí, které slouží k činnostem, které IS plní, tj. sběr, přenos, prezentace a uchování dat, SŘBD, OS, Aplikační server) 1

2 Základní pojmy Informační technologie (IT) chápeme jako souhrn technických a programových prostředků včetně jejich metodického a znalostního zázemí, sloužících ke zpracování a poskytování informací. IS/IT (IS/ICT) V běžném životě oba pojmy splývají IS reprezentuje potřebu informací, zatímco IT(ICT) uspokojení této potřeby. ICT Informační a komunikační technologie Základní pojmy Tvorba IS je vývoj programového vybavení včetně hardwarového pozadí, bezpečnostních mechanismů či pracovních postupů a doporučení. Tvorba IS je podpořena metodikou. Cílem metodiky je formalizovat postupy, definovat odpovědnosti a pravidla komunikace. Základem každého IS je správně navržená struktura dat. Informační strategie je dokument průběžně teoreticky ověřovaný a modifikovaný, jehož úkolem je stálá integrace IS/ICT s globální strategií podniku. Základní pojmy Systémová integrace je komplexní služba s cílem vytvořit a provozovat IS v podniku metodou integrace různých produktů a služeb. Systémový integrátor je subjekt schopný poskytovat tuto službu související s analýzou, implementací a údržbou IS. Outsourcing je svěření tvorby a především údržby a provozu IS specializované firmě. Outsourcing je zajišťování činností spojených s informatikou dodavatelsky, tedy formou externích služeb (Outsourcing rozvoje IS, provozu IS a totální outsourcing). Trendem je outsourcing i jiných procesů než podporujících provoz IS. Vliv informatiky na řízení podniku Spektrum produktů a služeb v nabídce se rozšiřuje. Informatika nabízí nové prostředí pro rozvoj vazeb podniku s jeho okolím. Technologie e-business podporuje překročení tradičních hranic trhu a teritorií a posiluje pozice zákazníka. Dodavatelé zvažují trvalou péči o zákazníka na základě jeho potřeb ale i potřeb jeho zákazníka (provázanost obchodních vztahů), potřeba vytvořit komunikační kanály se zákazníkem a pokusit se převzít jeho běžné provozní starosti (kontrola zásob na skladu, správa dodávaných zařízení, atd.). Zákazník dostává na jednom místě maximum služeb a produktů, které požaduje (tzv. integrace služeb). IS jsou postaveny na lidech na jejich schopnostech a znalostech (knowledge management). Trendy IS 1. Trendy globálního ekonomicko - společenského významu (Velký vliv na rozvoj IT má samozřejmě rozvoj komunikací, internet, vývoj technologií pro přenos hlasu a dat po telefonních linkách, přestože postupně spousta internetových firem zkrachovala, podíl a vliv Internetu a těchto firem na rozvoj a chápání e-commerce a IT je obrovský.) Vytváření mezipodnikových komunikačních sítí. Možnosti sdílení logistických, finančních a dalších služeb. Silná konkurence, porovnatelnost cen, porovnatelnost nabídky produktů a služeb. Nové prodejní kanály (mobilní služby, internet, ebusiness). Nové možnosti marketingu. Lepší možnosti outsourcingu informačních služeb (ASP). 2. Trendy se vztahem k ekonomice, řízení a organizaci podniku (viz dále) 3. Trendy v ASW (aplikační software), (viz dále) Trendy IS 4. Trendy v oblasti ICT (viz dále) 5. Trendy v oblasti metod a nástrojů vývoje IS/ICT (objekty, CASE systémy, standardy, probíhá odklon od klasického vodopádového vývoje IS/IT (etapy: specifikace požadavků, analýza, návrh, implementace a zavedení) a přechází se k inkrementálnímu vývoji IS), vznikají tzv. agilní metodiky vývoje IS. 6. Trendy v organizaci a řízení IS/ICT (systémová integrace a outsourcing, vznik útvarů informatiky, manažerů informatiky a dalších nových funkcí) Pozn. : Současné 4 klíčové oblasti IT průmyslu (HW, SW, IT služby, telekomunikační vybavení) 2

3 Ad 2. Trendy mající vztah k ekonomice, řízení a organizaci podniku Sílící podpora obchodní činnosti (ebusiness, ebanking) Vliv na změny v organizačních strukturách (procesní řízení) Vznik virtuálních týmů Vznik datových skladů Rozvoj znalostních systémů Význam systémů podnikové inteligence - přesun priorit ke strategickému řízení Outsourcing Nákup služeb (místo nákupu licencí se management rozhodne nakoupit služby což bude znamenat mimo jiné technologické změny a větší nároky na provoz aplikací po internetu) Ad 3. Trendy v ASW Aplikační software (aplikační programové vybavení) - systém, jehož cílem je počítačová podpora částí informačních systémů. Individuální ASW- specifické aplikační systémy pro individuálního zákazníka (organizaci) dle jeho požadavků. Technologicky orientovaný ASW - OIS Trendem OIS je workgroup computing (groupware) a podpora workflow. Věcně orientovaný ASW TASW (typový ASW) TASW vlastnosti: modulový princip architektury, vysoká parametrizace, komplexnost a vysoká vnitřní složitost, vnitřní integrace s OIS, integrace datové základny. Ad 3. Trendy v ASW ERP Řešení IS v podniku lze realizovat třemi základními způsoby resp. jejich kombinacemi: Vývojem specializovaného jednoúčelového SW. Nákupem a instalací TASW. Komplexními projekty založenými na výběru velkých aplikačních SW, customizací a dořešením těch modulů, které chybí nebo neodpovídají potřebám zákazníka. ERP (Enterprise Resource Planning) je IS, který umožňuje účelně a efektivně řídit všechny klíčové podnikové zdroje. Patří mezi TASW. Vlastnosti: Vlastnosti TASW (viz předchozí snímek) plus Schopnost automatizovat a integrovat klíčové podnikové procesy. Sdílet společná data a zpracovávat je v rámci celé organizace. Vytvářet a zpřístupňovat informace v reálném čase. Zpracovávat historické údaje. Trendem v ERP je spojení s CRM, SCM a BI, podpora e podnikání Ekonomické systémy ERP na českém trhu Třídění dle : cenové hladiny výkonu (rychlost) funkčního horizontu aplikace velikosti dodavatelské firmy a dostupnosti servisu know-how konzultantů centralizované- decentralizované řešení zkušenosti ze specifických oblastí hospodářství reference flexibilita robustnost rychlost případných úprav spolehlivost perspektivnosti řešení (technologie) Ekonomické systémy na českém trhu Velcí hráči SAP R3 BAAN IV Oracle Financials JDE Edwards Střední třída Microsoft Business Solution Navision a MBS Axapta, MBS CRM QI JBA (UK ) K2 (tuzemsko) Helios (Red, Orange, Green) Nižší třída JKR Pohoda Cígler SW Money Abra Gold Business 602 ESO Vision 32 Karat Merlin (FEIS) a další 3

4 ERP na českém trhu Ad 4. Trendy v oblasti ICT Otevřené systémy, které jsou standardizovány mezinárodními organizacemi a konsorcii (např. W3C, IEEE, ISO, OMG, ), členy takových skupin jsou často velcí a významní hráči na IT trhu (IBM, Microsoft, SUN, Oracle..), je možné odebírat a přidávat další funkce. Třívrstvá architektura ASW (prezentační, aplikační a datová vrstva). Distribuované zpracování založené na klient -server architektuře. Grafické a multimediální uživatelské rozhraní. Od ISP k ASP (Internet System Providing, Aplication Service Providing), kdy uživatel řeší potřeby automatizace svých činností prostřednictvím pronájmu aplikací jako služby od ASP operátora za poplatek. Proč dochází k nespokojenosti ze strany uživatelů Náklady na zavádění jsou vysoké a většinou překročí plánovanou částku. Realizace IS je pomalá a termíny nebývají dodrženy. Přínosy IS bývají v rozporu s očekáváními (nebylo dosaženo plánovaných cílů). Provoz IS je nákladný, těžko se přizpůsobuje rychlým změnám ve společnosti. Kritické faktory úspěchu a rizika při zavádění IS/IT 1. Chybně postavená globální strategie podniku, nerespektování vlastnických a organizačních změn v podniku 2. Podcenění významu konkurenceschopnosti podniku 3. Budování IS/IT bez jednotné koncepce, nedůsledné řízení projektu a podcenění role IS/IT managementem 4. Zanedbá se stav lidí a rozsah změn před zavedením nového IS/IT 5. Chybně se odhadne časová a finanční náročnost případně provozní nároky 6. Nevhodně se zvolí syst. integrátor případně sepíše smlouva Výhody nasazení metod návrhu Zvyšuje se kvalita produktu a zjednodušuje se plánování a řízení. Usnadňuje se komunikace mezi analytiky, návrháři a programátory a zadavateli IS. Snižují se náklady a odstraňuje se závislost na jednotlivých osobách. Dokumentace je tvořena systematicky a jednotně. Stupně standardizace metod vývoje IS Podniková úroveň Národní úroveň Mezinárodní úroveň Standardy de iure (SSADM, UML) Standardy de facto (metody podporované CASE systémy). 4

5 Efektivnost zavádění IS Náklady a přínosy Efektivnost je účinnost prostředků vložených do nějaké činnosti hodnocená z hlediska užitečného výsledku této činnosti. Zatímco výdaje do IS jsou viditelné, přínosy jsou neviditelné, nelze tedy prokázat konzistentní vztah mezi výdaji na IS a ukazateli úspěšnosti podniku. Pro určování efektivnosti se používají základní (náklady a výnosy) a doplňkové ukazatele a rovnice pro dobu návratnosti. Náklady Jednorázové Náklady na vývoj IS (dočasné vybavení pracovišť, konzultace, cestovné..) Náklady na investice (HW, SW, realizace sítě ) Náklady na vlastní implementaci IS (konverze dat, školení pracovníků ). Pravidelné roční Stálé (odpisy, mzdy, energie, údržba SW, HW..) Variabilní (cestovné, penále, doprava, kurzy ). Druhové členění nákladů Náklady a přínosy Náklady na HW Počítače Periferní zařízení Komunikační technika Náklady na SW Operační systémy Databázové systémy Síťový SW Aplikační SW Náklady na pracovníky Projektanti a vývojoví pracovníci Systémová správa (DB a sítě) Technici a provozní personál Pracovníci přípravy dat Náklady na služby Servis HW, vývoj a údržba aplikace, komunikační služby, externí zpracování některých agend, outsourcing IS Náklady na režii Energie, platy pro správu IS/IT, náklady na materiál Přínosy Kvantifikovatelné Jednorázové (prodej projektu IS) Roční (zvýšení výroby, zvýšení odbytu, snížení nákladů, úspora pracovníků, nižší skladové zásoby..). Nekvantifikovatelné Zjednodušení a urychlení přístupu k informacím Kvalitnější evidence Přesnější zpracování informací Zlepšení jména firmy, efektivnější práce, kvalitnější vztah se zákazníkem Systemizace ukazatelů přínosů IS/IT (podle Molnára) Příklady přínosu IS Provádíme z různých hledisek a klasifikujeme na ukazatele: finanční (měřené v peněžních jednotkách) a nefinanční (měřené jinými fyzikálními jednotkami jako jsou počet, čas apod.), kvantitativní (měřitelné nějakou kardinální stupnicí) a kvalitativní (měřitelné nějakou ordinární pořadovou stupnicí či logickou hodnotou splněno nesplněno ), přímé (u kterých můžeme prokázat jednoznačný příčinný vztah k dosaženému přínosu) a nepřímé (u kterých musíme stanovit nějaké zástupné ukazatele vyjadřující změnu), krátkodobé (projevující se obyčejně do půl roku po implementaci IS/IT) a dlouhodobé (projevující se později, někdy až za více let), absolutní (vyjádřené nějakou měřitelnou hodnotou) a relativní (vyjádřené bezrozměrným poměrovým číslem). zkrácení průběžné doby vývoje a výroby snížení počtu reklamací zvýšení počtu zákazníků zvýšení podílu na trhu snížení doby prostoje výrobního zařízení zkrácení doby obsluhy zákazníka rozšíření výrobního sortimentu zlepšení dobrého jména podniku spokojenost zákazníků zvýšení zákaznické věrnosti flexibilita podniku, kreativita v přijímání nových produktů, služeb zlepšení pracovního prostředí 5

6 Doba návratnosti Náklady a přínosy Doba návratnosti T N = (N j P j )/(P r -N r ) kde N j - jednorázové náklady na realizaci IS P j jednorázový přínos IS P r pravidelný roční přínos IS N r pravidelný roční náklad na provoz IS nebo ROA Return of Assets, který stanovíme podle vzorce pro rentabilitu celkového kapitálu podle vzorce Roční zisk po zdanění + úroky ROA = x 100 Celkový kapitál Doba návratnosti T N = (N j P j )/(P r -N r ) kde N j - jednorázové náklady na realizaci IS P j jednorázový přínos IS P r pravidelný roční přínos IS N r pravidelný roční náklad na provoz IS. 6

7 Architektura IS/IT - definice Architektura IS/IT - vlastnosti Architektura IS/IT je grafické a písemné vyjádření celkové koncepce IS/IT, která v sobě zahrnuje základní představu o: struktuře IS v návaznosti na organizační strukturu podniku, funkcích, které bude IS zabezpečovat v návaznosti na procesy podniku, provozu a bezpečnosti celého systému, vazbách na okolí. Architektura softwarového systému je koncept systému v jeho prostředí a vyznačuje se: vysokou úrovní abstrakce, obsahuje strukturu a organizaci důležitých komponent systému, obsahuje popis rozhraní pro interakci komponent. Architektura IS/IT - význam Koho zajímá architektura Vytváří relativně stabilní rámec řešení IS/IT. Je významným komunikačním prostředkem mezi tvůrci a vedením podniku. Zajišťuje stabilitu vývoje IS/IT při rychlém technologickém vývoji IT. Význam ekonomický - minimalizuje náklady na chybně zadané projekty a rekonstrukce. Zainteresované osoby, analytici požadavků, manažeři projektu, návrháři, architekti, implementátoři, testeři, externí pracovníci. Dvojí pojetí architektury Klasický pohled Rozlišujeme dvě úrovně architektury IS - globální architektura a dílčí architektury. Moderní pohled komponentová architektura (architektura 4+1 pohledů), MDA (Model Driven Architecture), SOA (Service Oriented Architecture) a další. Další přístupy architektura služeb IS/IT, aplikační architektura, architektura technologická, architektura řízení IS/IT. Globální a dílčí architektura IS/IT Globální architektura - hrubý návrh IS/IT, vize budoucího stavu IS/IT, která zachycuje jednotlivé komponenty IS/IT a jejich vzájemné vazby, obsahuje základní stavební bloky IS/IT, kde blok představuje množinu informačních služeb (funkcí), které slouží na podporu jednoho nebo více podnikových procesů. Pozn.: Alternativní pohled : množina informačních služeb pro různé skupiny uživatelů - veřejnost, partneři, zákazníci, zaměstnanci U globální architektury rozlišujeme vertikální dimenzi (vychází z obvyklého členění managementu do tří úrovní a jde tedy o hierarchické uspořádání z hlediska práv a povinností lidí v IS) a horizontální dimenzi (z hlediska podnikových útvarů - výroba, účetnictví, marketing ). 1

8 Globální a dílčí architektura IS/IT Globální a dílčí architektura IS/IT Dílčí architektury jsou detailnější návrhy IS/IT. Na základě globální architektury se navrhují tyto dílčí architektury: funkční, procesní, datovou, technologickou, softwarovou, hardwarovou, (detailněji příště). Návrh dílčích architektur je zakončen vymezením vazeb mezi těmito architekturami. Funkční architektura Softwarová architektura Aplikační architektura Globální architektura - architektura inf. služeb Procesní architektura Technologická architektura Datová architektura Hardwarová architektura Dílčí architektury IS/IT Globální architektura stavební bloky Globální architektura dle služeb poskytovaných podnikovým procesům Externí DB a informační služby Zákazníci EIS BI strategické řízení (EIS) Dodavatelé Banky Pojišťovny Státní správa: - finanční úřad - celnice - ČSÚ - atd. EDI Celopodnik.analýzy Finance Obchod Výroba Zdroje MIS Správa, lidské zdroje, marketing, legislativa, jakost Finanční řízení: analýzy, plánování, modelování, zdroje Hlavní kniha Pokladna Závazky PAM Pohledávky Majetek Controlling MTZ Nákup Sklady Prodej Přeprava TPS OIS Extranet, EDI SCM lidské zdroje organizace ekonomika obchod APS CRM hlavní předmět činnosti - jádro ERP taktické řízení (MIS) operativní řízení a provoz (TPS) Osobní informatika, OIS, intranet Provoz: komplexní řízení zakázek a komplexní řízení výroby Konstrukce - CAD TPV - technologie Kapacitní plánování Operativní řízení výroby Dílenské řízení výroby Služby: - montáže, - servis Globální architektura dle skupin uživatelů TPS (Transaction Processing System) Je operativní částí IS, operace jsou závislé na charakteru podniku, nejspecifičtější blok IS. Jeho úkolem je pořizovat a aktualizovat data, udržovat evidence, poskytovat základní přehledy o činnosti podniku, zde se tvoří data pro ostatní vrstvy podnikového IS. 2

9 Vlastnosti TPS MIS (Management IS) Je důkladně vypracován na základě standardizovaných postupů. Je robustní, spolehlivý, s rychlou odezvou, (k provozu se používají spolehlivé a odzkoušené IT). Datové modely jsou jednoduché. Provádí rutinní funkce. Typy TPS např. CIM (Computer Integrated Manufactoring), CIS (Customer IS, dnes CRM), RIS (Reservation IS), GIS (Geografic IS), MRP (Material Requirements Planning), především některé úlohy z ERP (Enterprise Resource Planning). Určen pro řízení podniku na taktické úrovni. Podobný i pro podniky různých typů. Procesy jsou integrovány do tří linií: obchodně - logistická (nákup, prodej, MTZ, sklady...) finančně - účetní (účetnictví, majetek, pokladna, mzdy ) průřezová (organizace a správa, personalistika, marketing, legislativa ) DSS (Decision Support System) Určeny pro manažerské plánování všeho druhu (pro úroveň operativního a taktického řízení). Ideální nástroje pro odhady, optimalizační a simulační úlohy, úlohy z operačního výzkumu a statistiky. Data z MIS spojená s grafikou. EIS (Executive IS) Určen pro strategické řízení podniku. Získává data z ostatních úrovní IS a z externích zdrojů, data agreguje a vytváří časové řady a vzájemné vazby, trendy, prognózy. Je zaměřen na delší časový úsek do minulosti i budoucnosti. Vyznačuje se specifickými nároky na prezentaci informací, na využití multimédií, na složité algoritmy pro nejrůznější analýzy stavů a prognóz. Umožňuje permanentní aktualizaci svých modelů z dostupných interních i externích zdrojů v zadaných časových intervalech. Pracuje s historickými daty možnost vysledovat vývojové tendence data mining. Uchovává údaje o stejném objektu vzniklé v různých časech možnost hodnocení kvality. Často je založen na technologii datawarehouse. EIS Pro tvorbu EIS se využívají specializované SW nástroje, pracující s OLAP technologií (On Line Analytical Processing). Základem je uložení dat v n-dimenzionální databázi 1. dimenze ekonomické ukazatel (zisk, obrat.. ) 2. dimenze čas 3. dimenze zvolený pohled (typy zákazníků, teritoria, závody..) Dva typy EIS Systémy řízené obrazovkou - uživatelé pracují s připravenými obrazovkami. Systémy řízené daty - uživatelé sami propojují své požadavky s datovým skladem a tvoří si obrazovky. Systémy EIS jsou součástí řešení podnikové inteligence viz speciální přednáška. 3

10 OIS (Office IS) Blok orientovaný na podporu kancelářských prací a týmové práce. Hlavním úkolem je vytvářet, modifikovat a přenášet data administrativního charakteru v písemné a grafické podobě. Zvyšuje produktivitu a výkonnost administrativních pracovníků. např. MS OFFICE nebo DIP- Bezpapírová kancelář. Dále veškeré editory, DTP (DeskTop Publishing), tabulkové procesory, PowerPoint aplikace, plánovací kalendář, řízení projektů (MS Project), sledování úkolů, sledování pošty (došlá a odešlá), WWW - internet Systémy pro správu dokumentů DIP (Document Image Processing) Je skupina produktů sloužící k elektronickému zpracování firemních papírových dokumentů tak, aby je byly schopny zpracovávat běžné kancelářské IS. K takto vytvořeným dokumentům pak je možno připojovat data z Wordu, Excelu,.., i AutoCADu. Tato data je možno dále uložit, případně zpracovat (snadno je vyhledat, analyzovat, umožnit okamžitý přístup k záznamům). ECM (Enteprise Content Management) Enterprise Content Management (ECM) is the strategies, methods and tools used to capture, manage, store, preserve, and deliver content and documents related to organizational processes. ECM tools and strategies allow the management of an organization's unstructured information, wherever that information exists. Někdy také DMS (Document Management System) EDI (Electronic Data Interchange) Je technologie elektronické výměny obchodních dokumentů (strukturovaných dat) na základě dohodnutých standardů mezi IS jednotlivých obchodních partnerů pomocí elektronických prostředků. Je to jeden z nástrojů provádění el. obchodu. Základní norma u nás - ISO 9735 známá jako UN/EDIFACT (EDI for Administration, Commerce and Transport). Je to standard standardů, zastřešuje standardy pro jednotlivé prům. obory. EDI Skládá se ze tří modulů: datové rozhraní v ERP systému - propojení aplikací (normální import/export do účetnictví, aktivní brána do IS), SW pro překlad zpráv - konvertor (převod dat vlastního formátu do tzv. inhouse formátu, pokud možno strukturovaného dle standardu), komunikační modul pro zajištění výměny dokladů s protistranou (důležité kritérium, Internet, modem). další komponentou je SW pro elektronický podpis a archiv dokladů. Více na Obecná struktura EDI systému Základní typy EDI řešení Výměna zpráv mezi koncovými subjekty tzv. end-to-end, každá z komunikujících stran musí mít konvertor a také komunikační software pro připojení do datové sítě, standardně je používaná síť x.400. Tento způsob zobrazuje. 4

11 Základní typy EDI řešení Základní typy EDI řešení Výměna zpráv prostřednictvím VAN operátora VAN je síť s přidanou hodnotou. Konvertor a komunikační software v tomto případě stále zůstávají na straně klienta, stejně tak i správa a vedlejší náklady. VAN operátor zajišťuje hlavně distribuce standardních zásilek a zpráv. Část EDI řešení tedy přebírá VAN operátor, ten také funguje jako dodavatel konvertoru a komunikačního softwaru. Zpracování a výměna zpráv prostřednictvím poskytovatele EDI služeb vychází z modelu VAN operátora s tím rozdílem, že poskytovatel EDI zajišťuje také převod zpráv, tzn. konvertor a komunikační software si již nemusí zajišťovat klienti, ale právě tento prostředník. Podstatné je, že pro většinu firem odpadl problém složitosti systému a tudíž se stal nejvíce používaný. Ovšem stále nevýhodný zůstává poměr mezi výkonem a cenou, tudíž si tento systém mohou dovolit spíše větší firmy. Jde o výhodné řešení i pro malé společnosti, díky EDI poskytovateli není potřeba žádný konvertor, ani speciální software. 5

12 Potřeba informace v podniku (pozn.) Dílčí architektury IS 1. Procesní architektura Cílem návrhu procesní architektury je co nejrychlejší reakce podniku na externí události při nízké spotřebě podnikových zdrojů. Východiskem návrhu procesní architektury je určení klíčových externích událostí, které představují podstatné vazby podniku s okolím. Nástrojem je kontextový diagram, na něj navazuje hrubé schéma procesů a vazeb, které se v další fázi ještě detailizují. Procesní architektura je návrhem budoucího stavu procesů ve firmě a nástrojem mohou být i procesní diagramy. Dílčí architektury IS 2. Funkční architektura Navazuje na architekturu procesní. Je to návrh hierarchického rozpadu požadovaných funkcí a služeb IS. Nejnižší úroveň funkční hierarchie, která je viditelná uživatelům, popisuje elementární funkce (transakce), které mají uživatelé IS/IT ještě k dispozici. Nástrojem je DFD a slovní popis funkcí (minispecifikace). Dílčí architektury IS 3. Datová architektura Je návrhem datové základny IS. Vychází z analýzy potřebných datových objektů a jejich vazeb. Na základě datové architektury se navrhují datové entity, jejich vazby a atributy. Nástrojem je entitně-relační diagram, ERD. Je finalizována návrhem datových souborů a jejich fyzickým uložením. Dílčí architektury IS Pozn. Pro formalizované definování logické struktury dat se často využívá Backus-Naurovy syntaxe v následující podobě identifikátor struktury = logická struktura Syntaktické znaky používané pro specifikaci logické struktury mají následující význam + logická spojka "a" (and), {X} X je opakující se substruktura, [X] X=X1 X2 X a je variantní substruktura a znak " " představuje logickou spojku "nebo" (X) X je nepovinná substruktura. Dílčí architektury IS 3. Datová architektura Grafická část ERD obsahuje dva základní prvky: entity a vazby. Entita jako abstrakce množiny prvků se stejnou logickou strukturou (musí mít název) Vazby definují souvislost mezi objekty Vazby unární, binární, n-ární Vazby supertyp/subtyp Příklad logické struktury datového toku: OBČAN=Příjmení+Jméno+Rod.číslo+{DÍTĚ}+(Telefon)+[MUŽ ŽENA], kde DÍTĚ, MUŽ a ŽENA jsou substruktury, jejichž obsah se definuje stejným způsobem. 1

13 Dílčí architektury 4. Softwarová architektura Je definována množinou programových jednotek - modulů a vazeb mezi těmito moduly. Vazby jsou dány voláním modulů a předávanými daty. Každý modul je popsán funkcemi, které zajišťuje, V/V a řídícími daty, algoritmem přechodu vstupních dat na výstupní, vývojovým prostředím (pgmovací jazyk), provozním prostředím (OS, SŘBD,..). Softwarová architektura Existují čtyři typy SW architektur: Lineární - cílová fce systému je dosažena sekvenčním uspořádáním elementárních funkcí, využívá se zřídka. Hierarchická - vazby jednotlivých funkcí systému jsou reprezentovány stromovým grafem, každá elementární funkce je využita vždy právě v jedné funkci vyšší úrovně, přehledná ale nákladná architektura. Síťová - neplatí závazná pravidla podřízenosti a nadřízenosti, nedefinuje žádná pravidla pro vztahy mezi jednotlivými částmi, kterákoliv komponenta může využívat služeb jiných komponent. Předností je otevřenost pro přidávání nových funkcí (flexibilita). Je vhodnější pro tvorbu rozsáhlého systému než předchozí hierarchická architektura. Softwarová architektura Vrstvená - funkce jsou uspořádány do několika vrstev tak, že funkce vyšší vrstvy mohou využívat pouze funkcí podřízených vrstev. Silně vrstvená architektura - je povoleno používat jen funkcí vrstvy bezprostředně podřízené. Slabě vrstvená architektura - vyšší funkce může využívat i funkcí nižších než bezprostředně podřízených vrstev. Softwarová architektura Použití: Univerzálně jsou použitelné pouze vrstvená a síťová architektura. Lineární a hierarchická pouze pro specifické aplikace. Síťová je preferována v případech, kdy dáváme přednost nízkým nákladům provozu před nízkým nákladem tvorby, údržby a užití. V ostatních případech je vhodnější vrstvená architektura. Vrstvená architektura je vhodná zejména pro použití v distribuované nebo kooperativní technologické architektuře. Dílčí architektury 5. Hardwarová architektura Dílčí architektury 6. Technologická architektura Určuje typy, počty a vzájemné vazby hardwarových komponent. Rozhoduje o technologickém řešení aplikace. Propojuje SW, HW a datovou architekturu a definuje způsob zpracování jednotlivých aplikací, vnitřní stavbu aplikací a uživatelské rozhraní aplikací. Klasifikace technologické architektury podle metody zpracování, podle uspořádání PC, podle vrstev. 2

14 Typy technologické architektury Podle metody (režimu) zpracování (určuje, jakými podněty jsou jednotlivé funkce aplikace startovány, jaká je doba odezvy funkcí a jaký vztah má zpracování funkcí k fcím reálného světa) Dávkové zpracování - Interaktivní zpracování - Řízené událostmi - V reálném čase - Technologické architektury podle metody zpracování Dávkové (jednotlivé požadavky na zpracování a související vstupní data jsou shromážděna v dávce před odstartováním aplikace, která po svém spuštění zpracuje najednou všechny shromážděné požadavky Př.: sběr a doručování poštovních zásilek, účetní závěrka) Výhody (snadná programová realizace, malé nároky na počítačové zdroje) Nevýhody (dlouhá a nezaručená doba odezvy bez komunikace s uživatelem) Interaktivní (uživatel je v přímém kontaktu s počítačem a jeho požadavky na zpracování jsou vyřizovány okamžitě a s garantovanou dobou odezvy a jsou realizovány jednou transakcí) Výhody (uživatelsky příjemnější) Nevýhody (náročné na tvorbu, náročné na potřebu počítačových zdrojů) Technologické architektury podle metody zpracování Aplikace řízené událostmi (startovány událostmi (datové, časové, mimořádné), které nastávají v reálném světě) Př. automatické vystavení objednávky (datová), pravidelné automatické odesílání údajů (časová) Výhody (zvyšují automatizaci a tím obvykle i efektivnost podnikových procesů). Aplikace pracující v reálném čase Př. přímé řízení strojů a celé výrobní linky počítačem Typy technologické architektury Podle uspořádání PC (z hlediska rozmístění) Centralizované zpracování (1 hlavní počítač, na který jsou napojeny neinteligentní terminály) Decentralizované zpracování (samostatné počítače bez vazeb) Distribuované zpracování (několik serverů s připojenými koncovými stanicemi) Kooperativní zpracování (distribuované + Internet) Typy technologické architektury Podle vrstev (vrstva datová, funkční a prezentační nebo komunikační), základní rozdíl mezi následujícími architekturami je v tom, zda jsou tyto vrstvy odděleny do samostatných programů, či nikoliv. monolitická architektura všechny vrstvy jsou řízeny jedním programem dvouvrstvá architektura - lehký nebo těžký klient, třívrstvá architektura (typická architektura pro celopodikové rozlehlé aplikace dynamického charakteru). Výhody třívrstvé architektury Vyšší pořizovací ale nižší provozní náklady Menší údržba Neexistují redundantní údaje Neexistuje redundantní podniková logika Jednoduché přizpůsobení potřebám zákazníka Jednoduchý a rychlý a bezpečný přechod na vyšší verze vysoká flexibilita Každou vrstvu lze udržovat samostatně Každá vrstva může být vyvíjena v jiném vývojovém prostředí Ideální pro tvorbu otevřených, distribuovaných a flexibilních IS 3

15 Třívrstvá architektura pozn. 3 vrstvy z pohledu WEB Databáze Aplikační (business logika) Windows klient nebo Browser klient Klient/server architektura Speciální případ vrstvené architektury. Princip je umožnit více uživatelům pracovat nad společnými daty a rozložit zpracování na více počítačů. Podoby klient/server architektury Distribuovaná prezentace Distribuovaná data Distribuovaná data a aplikační logika Internet a Intranet Viz obr. Architektura IS/IT Architektura IS/IT Další dimenze architektury: organizační personální metodická ekonomická Architektura může obsahovat dále vazby mezi bloky (každá vazba je určena obsahem, formátem, periodicitou..). Architektura IS/IT by měla podporovat následující vlastnosti IS/IT: strategická orientace, adekvátní funkční spektrum, integrovanost, otevřenost, jednoduchost, flexibilita, udržovatelnost, efektivní provozuschopnost: přijatelná doba odezvy, funkční spolehlivost, bezpečnost dat před výpadkem systému, ochrana dat před neautorizovaným užitím. 4

16 Architektura IS/IT Základním problémem v řešení IS/IT je najít takové vztahy mezi jednotlivými architekturami, které povedou ke zvýšení kvality a výkonu celého IS. Chyby nejčastěji znamenají: neúměrnou složitost systému, prodlužování vývoje a řešení systému, prodlužování doby odezvy, snižování flexibility vzhledem k novým uživatelským požadavkům, snižování spolehlivosti, zvyšování rizika výpadů... 5

17 Vrstvená SW architektura Vrstvená softwarová architektura detailněji Vrstvená architektura je jednou z variant dílčí softwarové architektury nabývá při tvorbě SW stále většího významu (základní cíl vrstvené architektury je minimalizace tvorby a údržby SW). Abstraktní počítač (1 vrstva SW architektury) Architektura je tvořena hierarchií abstraktních počítačů (vrstev) Uživatelská vrstva tvořena technologickými vrstvami následujících typů agregátová - vytvoří takovou množinu funkcí, pomocí které se problém vyřeší rychle a efektivně filtrující - odstraní nepodstatná a nežádoucí specifika nižších vrstev (odstínění rozdílů v uživatelském rozhraní) interfaceová - reprezentuje uživatelské rozhraní, je zpřístupněna uživatelům nadřízené vrstvy Vrstvená softwarová architektura Vrstvená softwarová architektura Prvky vrstvy SW architektury ADT (složen z datové struktury a operací nad datovou strukturou), kolik funkcí, tolik ADT dispečer ADT dispečer vrstvy tvůrce vrstvy uživatel vrstvy Typické vrstvy IS jinak Vrstvená softwarová architektura (VA) Z technologického pohledu Prezentační systém Aplikace DBS OS Strojový kód Mikroprogramy, binární logika Z aplikačního pohledu Uživatelé GUI Aplikace DB prostředí OS platforma HW prostředky Základní cíl VA je minimalizace nákladů tvorby a údržby a nákladů užití softwarového systému. Uspořádání funkcí do několika vrstev s tím, že funkce vyšší vrstvy mohou využívat jen funkce vrstev podřízených. Typické vrstvy současných počítačů: aplikace (ASW) presentační systém databázový systém operační systém strojový kód mikroprogramy binární logika technického vybavení 1

18 Další možné komplexní přístupy k architektuře IS/IT Architektura 4+1 pohledů Komponentová architektura Servisně orientovaná architektura Modelem řízená architektura Architektura 4+1 pohledů Definice architektury systému podle IEEE: nejvyšší úroveň koncepce systému v jeho vlastním prostředí. Architektura systému musí mít schopnost být viděna z různého úhlu pohledu. 4+1 pohledy (každý pohled odpovídá modelu v dokumentaci systému). Spojena s objektovým přístupem. Logický pohled Procesní pohled Use case pohled Implementační pohled Pohled nasazení Architektura 4+1 pohledů Architektura 4+1 pohledů Logický pohled (slovníček, funkce) logická struktura systému z hlediska výsledné funkčnosti (co by systém měl vykonávat), identifikuje hlavní (věcné) balíky, subsystémy, třídy a vazby mezi nimi, model perzistentních informací (data a funkce), zajímá analytika a designera, zachycuje slovník oblasti problému jako množinu tříd a objektů, spolu s procesním pohledem představují chování systému. Implementační pohled (Systémová seskupení, správa konfigurace) popis organizace statických softwarových komponent, modulů (exe, html, dll) ve vývojovém prostředí, rozčlenění do vertikálních a horizontálních vrstev, zaměřen na rozdělení systému do menších samostatně realizovatelných komponent, zdrojový kód, datové soubory, spouštěče, zajímá programátory a SW management, slouží ke znázornění závislostí mezi komponentami a toho jak konfigurovat spojení těchto komponent. Architektura 4+1 pohledů Architektura 4+1 pohledů Procesní pohled (výkon, škálovatelnost, propustnost) pohled na chování systému konkurence a paralelismus, propustnost, automatizované úlohy, tolerance chyb, zotavení z běhových chyb, odezva systému na vnější podněty, rozšiřitelnost systému, jeho výkonnost, přípustnost, zajímá systémové integrátory. Pohled nasazení (technologie systému, distribuce, doručení, instalace) navázání systému na topologii hardwarových a dalších softwarových komponent (jak jsou spouštěče a ostatní běhové komponenty mapovány do základních platforem a počítačových uzlů), fyzické rozložení komponent, nasazení, instalace, ladění výkonu, zajímá všechny tvůrce systému. 2

19 Architektura 4+1 pohledů Pohled případů užití (základní požadavky na systém) speciální role, klíčové případy užití (use case), pomáhá odhalit základní požadavky na architekturu, zpětná vazba na věcné požadavky při testování, systematický přístup k věcným požadavkům, zajímá koncové uživatele. Komponentová architektura Základní myšlenkou komponentových architektur je snaha pojmout tvorbu programu jako skládání jinak do značné míry nezávislých komponent. Tuto myšlenku lze uplatnit jak na úrovni návrhu architektury, tak na úrovni implementace programu. Na úrovni návrhu architektury je předním přínosem komponent možnost rozdělit řešení do menších, a tak snáze zvládnutelných částí. Při důsledném použití hierarchické dekompozice se pak návrh architektury na nejvyšší úrovni skládá z relativně malého počtu spolupracujících komponent. Běžně používané jednotky dekompozice jako moduly či třídy jsou však zatíženy vazbami na prostředí pro implementaci programu, ve kterém mají další, s dekompozicí nesouvisející funkce. Komponenty takové vazby nemají, a proto jsou jako koncepty pro dekompozici vhodnější. Komponentová architektura Komponentová architektura Na úrovni implementace programu je nejviditelnějším rysem komponent podpora opakovaného použití již implementovaných komponent ve větším počtu programů. Takové opakované použití slibuje mnoho výhod, mezi jinými např.: zvýšení produktivity, neboť opakovaně použitý kód je možné převzít a není třeba vyvíjet nový, zvýšení kvality programů, neboť opakovaně použitý kód je častěji zkoušen a zjištěné chyby jsou současně odstraněny ve všech programech, ve kterých je kód použit, zvýšení výkonu programů, neboť opakovaně použitý kód se spíše vyplatí optimalizovat a každá optimalizace se současně projeví ve všech programech, ve kterých je kód použit, zvýšení schopnosti programů spolupracovat, neboť opakované použití kódu vede k použití stejných formátů dat ve všech programech, ve kterých je kód použit. Komponenta = základní jednotka použitelnosti Je to netriviální, téměř nezávislá, vyměnitelná část systému, která poskytuje jasnou funkcionalitu. Komponenta fyzicky implementuje sadu rozhraní a musí splňovat jimi definované chování. Rozlišujeme: spustitelné komponenty, systémové komponenty, vývojářské komponenty, věcné komponenty (business component), univerzální a další komponenty. Komponenty Komponenty a vrstvy architektury Příklady komponent (spustitelný program, knihovna, textový soubor, tabulka v databázi,...). Komponenty vznikají při tvorbě architektury jako samostatně navržené, vyvinuté a otestované části software, integrované do systému. Existují znovupoužitelné komponenty pro řešení častých problémů, vyvinuté v rámci projektu nebo samostatně (standardy JavaBeans, CORBA, ActiveX). Dekompozice návrhu softwarového systému do komponent horizontální - komponenty stejného typu řeší různé úlohy vertikální - rozdělení do vrstev Vrstvy podle typů komponent vrstva persistence dat (komponenty řešící trvalé uložení dat operace Insert, Update, Delete, Select) vrstva obchodní logiky vrstva GUI a další 3

20 Komponenty a vrstvy architektury Počet vrstev (typicky 2-5 vrstev), příliš velký počet vrstev má za následek: složitou a nepřehlednou architekturu, mnoho vazeb a závislostí, příliš malé komponenty, snížení výkonu. Tříúrovňová architektura v komponentovém přístupu umožňuje dobře definovat odpovědnost komponent, umožňuje separátní vývoj v týmu a oddělení komponent na samostatné uzly (procesory). Komponenty a vrstvy architektury uživatelské rozhraní vizuální objekty v aplikaci - okna, ovládací prvky, pouze zobrazuje data - ergonomie uživatelského rozhraní, ošetření reakcí uživatele, vícejazyčnost obchodní logika logika informačního systému, algoritmické zpracování dat, logický model tříd systému přístup k datům (objektové a relační db) Výhody komponentové architektury Přehledná architektura: rozdělení odpovědnosti, komunikace pomocí rozhraní, řešení komplexnosti. Zrychlení vývoje: sestavování systémů z nakoupených komponent, oddělený vývoj balíků komponent. Oddělené testování: samostatné testování komponent, integrační testy. Architektura orientovaná na služby SOA Nový přístup k řešení architektury IS/IT, který využívá všech silných stránek předchozích přístupů a přidává koncept opakovatelné používaných komponent služeb s přesně definovaným chováním a rozhraními na okolí, tj. webových služeb. Zavádí se pojem katalog služeb (seznam všech služeb, které jsou v daném řešení k dispozici a je možné je kombinovat). Hlavním rysem je flexibilita při návrhu konkrétního řešení, tj. aby při změně obchodního požadavku na fungování IS stačilo v katalogu najít služby a jejich kombinací rychle dodat uživatelům požadovanou funkcionalitu. Komponenty lze z katalogu vyvolat opakovaně snížení nákladů. Viz obr. Architektura orientovaná na služby SOA Implementace SOA 1. krok : Definice základních stavebních kamenů služeb. Služby ze základní vrstvy jsou pak zpřístupněny uživatelům přes vrstvu tzv. veřejných služeb (bankomaty, veřejný portál, SMS brána), tedy služby GUI nebo B2B rozhraní. Architektura orientovaná na služby SOA Implementace SOA 2. krok: Implementace vrstvy technologických služeb. Integrační HUB zde zajišťuje výměnu dat mezi rezervačním a finančním systémem. Takto navržená architektura může zvýšit výkon celého systému oddělením integračních a prezentačních služeb 4

21 Architektura orientovaná na služby SOA Implementace SOA 3. krok: Procesní vrstva umožňuje snadnou implementaci složitých podnikových procesů, které v sobě mohou zahrnovat složitá rozhodovací kritéria nebo podmíněné spouštění nejrůznějších podsystémů a aplikací. Nová služba v tomto příkladu může obsahovat různé podmínky (nabídka slev na letenky), nebo verifikaci platby s bankou. Architektura založená na modelech MDA je přístup společnosti OMG Object Management Group, který vychází z myšlenky, že změny v oblasti SW resp. podniku se liší v závislosti na úrovni abstrakce. Na nižších úrovních jsou změny častější a zásadnější. Z toho vyplývá, že dopady neustálých změn v technologiích a společnosti vůbec je možné omezit jen na nižší vrstvy modelu a v případě potřeby přepracovat jen ty části, kterých se změna dotýká. Původně bylo toto paradigma vytvořeno pro vývoj software a byly popsány tři modely: Počítačově nezávislý model (Computer Independent Model, CIM), Platformově nezávislý model (Platform Independent Model, PIM) a Platformově specifický model (Platform Specific Model, PSM) se vztahem ke komponentní technologii. Později se však princip soustředil na vrstvu počítačově nezávislou, ve které jsou obsaženy podnikové aspekty společnosti. Nové verze MDA nyní obsahují tři úrovně abstrakcí se vzájemnými vztahy podle následujícího obrázku. Architektura založená na modelech Počítačově Nezávislý Model (CIM) Podnikový model Doménový model Podnikové požadavky Mapování Platformově Nezávislý Model (PIM) BPMN Model nezávislý na provádění workflow UML model nezávislý počítačové platformě Mapování Platformově Závislý Model (PSM) UML model pro určitou platformu (J2EE) Volba typového aplikačního SW je velmi odpovědná činnost a vůbec ne jednoduchá obzvláště u ASW, se kterým nejsou žádné zkušenosti (ani dobré, ani špatné). Jaká tedy zvolit kritéria při výběru software? K základním lze zařadit: funkčnost tj. plnění požadovaných funkcí, provozovatelnost (v různém prostředí, např. aplikace pro prostředí Windows XP nejsou provozovatelné v prostředí OS UNIX), spolehlivost (ošetření chyb uživatele, žádné nedefinovatelné zastavení), ochranu dat, otevřenost a modularitu (pro perspektivní rozšíření funkcí), náročnost na obsluhu (příjemné uživatelské prostředí), kvalitu servisních služeb, přijatelnou dobu řešení úloh, cenu. Charakteristiky ASW Předmětem našeho zájmu by měl být komplexní projekt založený na výběru velkých ASW, jejich customizaci a integraci s eventuálním dořešením a implementací těch částí, které TASW nepokrývá nebo neodpovídá požadavkům zadavatele. Moderní charakteristiky TASW Produkt a jeho tvůrce obsahová orientace firmy, personální struktura, počet pracovníků vývojářů nebo post implementační podpory, cenová nabídka, možnosti přizpůsobení SW jazykové nebo legislativní (podle referencí u jiných zákazníků). Architektura a funkcionalita oblasti pokrytí funkcemi systému, vazby mezi moduly, datová rozhraní, možnost připojení jiného systému, správa a monitorování provozu, on line dokumentace atd. 5

22 Charakteristiky ASW Provozní prostředí vymezení SŘBD, orientace na OS, orientace na HW pokud existuje. Služby údržba ASW, hot line, projekční služby (analýza, úpravy, prototypy, customizace, testování integrací kdo, jak, za jak dlouho, za kolik), školící služby, konzultační služby, monitorovací služby, optimalizace konfigurací). Další vlastnosti ASW možnosti customizace, jazykové prostředí, dokumentace ASW, audit ASW, ISO Kategorie SW z hlediska požadavků na kvalitu Entusiastické pgmy: SW pro vlastní potřebu, uživatelem je sám tvůrce, SW malý požadavky na kvalitu nejsou vysoké. Komerční balíčky: kancelářské pgmy, hry, antivirové pgmy, utility. Požadavky na vyšší kvalitu z důvodu distribuce mezi zákazníky. Selhání způsobí ekonomické ztráty. Podnikové systémy: (ERP) nároky na kvalitu ještě vyšší. Vztah mezi zákazníkem a výrobcem nebo dodavatelem užší. SW kritický pro zdraví a životy lidí: (v nemocnicích, letecké dopravě, jaderných elektrárnách ). Selhání nezpůsobí jen zvýšení nákladů ale i lidské nebo společenské ztráty. Vlastnosti SW produktu (jiný zdroj) Tyto atributy bychom měli požadovat od dobrého SW produktu: Jednoduchost (pro uživatele), odolnost (vůči chybám) a stálost (vzhledem k pracovním postupům a dokladům) Udržovatelnost Provozní spolehlivost Výkonnost Použitelnost Respektování zákonů a zvyklostí 6

23 Manažerské aplikace systémy Business Intelligence (BI) V podmínkách současného řízení firem nabývají stále větší důležitosti IS, které nepracují s primárními daty, ale s daty, která jsou nějak upravena a předzpracována. Za manažerské systémy jsou považovány bloky architektury, zpracovávající a prezentující značné množství transformovaných primárních dat, pocházejících ze základních transakčních systémů. MIS (také RIS), EIS, DSS jsou vytvořeny pro podporu potřeb manažerského výkaznictví, firemních analýz a rozborů, potřeb modelování, které vyžadují odlišné mechanismy práce s daty. Pracuje se zde s vybranými nebo upravenými daty, které se tak stávají nositeli komplexních informací o podnikových procesech v podniku. CRM a SCM jsou specializované manažerské aplikace. Datový sklad je srdcem dnešních firemních manažerských aplikací. Technologie zpracování dat v IS Cílem systémů BI je poskytnout různým úrovním managementu podklady pro kvalifikované rozhodování. Definice: BI je sada procesů, aplikací a technologií, jejichž cílem je účinně a účelně podporovat rozhodovací procesy ve firmě. Podporují analytické a plánovací činnosti podniků a organizací a jsou postaveny na principech multidimenzionálních pohledů na podniková data ( Základní platformou pro vývoj a implementaci vrstev bloku BI jsou následující dvě technologie: OLTP - On Line Technological Processing, technologie relačních databází provozujících údržbu nebo pořizování primárních dat (pro transakční systémy), OLAP - On Line Analytical Processing, zajišťují propojení dat s řídícími mechanismy firmy a analytickými potřebami řídících složek, hovoříme o vicekriteriální analýze dat (pro manažerské aplikace). OLAP technologie se vyskytuje v několika modifikacích MOLAP, ROLAP, HOLAP, DOLAP. Skupiny systémů BI Pohledy na manažerské aplikace RIS (Reporting Information System) Jsou vhodné pro operativní řízení základních funkcí firmy, poskytují sumární sestavy např. pro účetnictví (výsledovka, rozvaha, hlavní kniha, saldokonto atd., standardní reporting a ad hoc reporting). DSS (Decision Support System) Systémy podporující analýzu dat, plánování, modelování, návrh, přípravu podkladů pro strategické řízení, provádí se specializované analýzy nad většími objemy dat, jsou problémově orientované, jsou vhodné pro taktické řízení. EIS (Executive Information System) Jsou určeny nejvyššímu managementu firmy, vyznačují se jednoduchým ovládáním a velkými grafickými možnostmi (grafy, tabulky, mapy, obrázky). Systémy jsou flexibilní k primárním datům a své výstupy prezentují podle okamžité potřeby manažera. Funkční pohled veškeré funkce těchto aplikací musí podporovat rozhodovací proces a proces vyhodnocování informací. Z funkčního pohledu plní následující požadavky: Poskytují souhrnné přehledy nad primárními daty. Umožňují různou hladinu detailu. Informaci umí zobrazit graficky a znakově. Umí provádět statistické vyhodnocování, ad hoc dotazy. Umí modelovat jevy s výhledem do budoucnosti. Umí provádět citlivostní analýzu vlivu jednotlivých faktorů na zkoumaný jev. Pohledy na manažerské aplikace Pohledy na manažerské aplikace Technologický pohled Vyznačují se použitím multidimenzionálních databázových prostředků (OLAP technologie) a mají větší nároky na používané technické vybavení. Technologickou architekturou je nejčastěji třívrstvá architektura klient/server. Umí pracovat s daty různých formátů. Mají vysokou úroveň grafického uživatelského rozhraní. Provozní pohled Co do velikosti méně rozsáhlé aplikace, pracující s daty definovanými v jiných částech IS. Provádějí se však komplikované práce spíše analytického než rutinního charakteru. Dodávají se hotové manažerské aplikace s nabídkou servisu včetně dokumentace. 1

24 Multidimenzionální databáze Jejím obsahem jsou předpřipravená data tj. vybraná, agregovaná, transformovaná z TPS vrstvy. Jde o vícerozměrný prostor, kde je možné adresovat libovolnou buňku nebo podprostor, ten může obsahovat buď hodnotu dat, nebo funkci pro výpočet hodnoty dat podle dotazu uživatele. Multidimenzionální databáze a repozitory (metadata) je to popis skladu pomocí slovníku dat a schémat skladu a definice odvozování dat - algoritmy, definice transformací a převodů, dotazů, sestav, indexů, podpora systémových akcí jako archivace, bezpečnost,obnovení. Architektura BI V rámci obecné koncepce architektury BI lze identifikovat následující vrstvy Vrstva pro extrakci, transformaci, čištění a nahrávání dat Vrstva pro ukládání dat Vrstva pro analýzy dat Prezentační vrstva Vrstva oborové znalosti Komponenty pro analýzy dat (vrstva pro analýzy) zahrnují Reporting (zaměřené na standardní nebo ad hoc dotazy nad DB) Systémy na technologii OLAP (pokročilé a dynamické analytické úlohy) Dolování dat (sofistikovaná analýza velkého množství dat) Reporting OLAP technologie Z hlediska typů výstupních zpráv se v BI rozlišují tři základní typy reportů Start up vztahují se k základním aktivitám uživatelů, zahrnují běžné denní zprávy pro uživatele General reports společné výstupy pro více uživatelů, shrnutí za oblasti řízení, za podnik jako celek. Event driven reports systém je pořizuje automaticky podle zvláštních kritérií a situací (při dosažení úvěrových limitů, limitních stavů zásob, atd.) W. Codde (1983) a jeho 12 (+6) principů pro podporu manažerské práce jednodušším zpracováním dat: Multidimenzionální koncept dat Přístup k primárním datům Vnitřní architektura klient/server Zpracování nenormalizovaných dat Uložení výsledků OLAP mimo zdrojová data Intuitivní operace s daty atd. OLAP technologie se vyskytuje v několika modifikacích MOLAP, ROLAP, HOLAP, DOLAP. OLAP technologie OLAP technologie 2

25 Dolování dat Datový sklad - Datawarehouse Data mining - dolování dat Definice Je analýza souborů dat velkých objemů získaných pozorováními za účelem původně nepředpokládaných vztahů mezi nimi a takto získaná data agregovat novým způsobem a srozumitelně je prezentovat. Umožňuje pomocí speciálních algoritmů automaticky objevovat v datech strategické informace (prediktivní informace). Proces odhalování závislostí, vzorů a trendů proséváním velkých objemů dat s využitím statistických a matematických technik. Např. generalizace a sumarizace dat, hledání závislostí, klasifikace a shlukování dat, statistická analýza, detekce změn a odchylek, vyhledávání podobnosti... Techniky Rozhodovací stromy, neuronové sítě, genetické algoritmy, clustering a klasifikace. Datawarehousing je proces vytváření souborů dat sloužících k podpoře rozhodování. Z praktického hlediska jde o rozsáhlou soustavu nástrojů, programů, algoritmů, umožňujících extrakce dat z provozních a jiných databází, převody a standardizace dat, jejich odvozování a vyhodnocování, rychlé výběry a prezentace pro různé typy rozhodování. Dvě jména spojená s DW, dva přístupy k budování DW Bill Inmon (jednoúrovňová architektura, jednorázové vybudování celkového řešení), Ralph Kimpbal (dvouúrovňová architektura, nezávislé vytváření jednotlivých datových tržišť pro specifické útvary podniku). Datový sklad - Datawarehouse Datawarehouse (DW) je předmětově orientovaná, integrovaná, v čase organizovaná a trvale uložená kolekce dat sloužící pro podporu rozhodování předmětově orientovaná - data dávají info o specifickém předmětu (nákup, obchod) ne o operacích, které probíhají, integrovaná - data se berou z různých zdrojů a ukládají do, koherentního celku, v čase organizovaná - spojuje data se stejnou časovou periodou, je uložena historie dat, trvale uložená - data jsou ukládána v DW nastálo, jsou pouze přidávána, nikoli odstraňována. Datový sklad - Datawarehouse Datové tržiště (Data Mart - DM) menší rozsah než DW, data jsou zaměřena na jedno oddělení, divizi, pobočku, snadněji se ovládají. Často se týkají speciální aplikační domény a mohou mít různou konceptuální strukturu. Používají se pro systémy DSS. Kde je vhodné zavést DW? tam, kde je velké množství dat, tam, kde je složitá struktura dat, tam, kde se dá předpokládat, že poroste množství dat. Vybudování DW je záležitost finančně nákladná, proces trvá řadu měsíců, často spojen také s BPR. Datové sklady jsou budovány v bankách pojišťovnách, velkých podnicích, budují se postupně i v SME. Datový sklad - Datawarehouse Zdroje dat Datový sklad - Datawarehouse Tři komponenty DW provozní databáze - data jsou agregována, odvozována z nich jiná data, a ta ukládána do DW, minulá provozní data - jsou to data, která aktualizací provozních databází mizí, ručně vkládaná data - data o budoucnosti (odhady, vývoje, trendy), data z externích zdrojů - předpisy, trh s akciemi, data o konkurenci, data z Internetu a externích IS. Int Int. Int. Ext. Import a příprava dat DW Využití a prezentace dat Sest. Výstup Form. Tab. 3

26 Komponenty DW Komponenty DW 1. Import a příprava dat (ETL Extraction, Transformation and Loading) probíhá v pravidelných časových intervalech a realizují se tyto činnosti: standardizace dat, filtrace dat, čištění, kondenzace, extrakce, opatření dat časovým údajem, příp. aktualizace a její datum. 2. Vlastní datový sklad obsahuje vnitřně standardizovaná data, se kterými lze snadno manipulovat, vybírat, odvozovat, měnit pohledy, obsahuje málo primárních dat, data časově označena, fyzická struktura přizpůsobena rychlému výběru dat, data se z DW jen čtou (ne aktualizace a mazání). 3. Využití a prezentace dat nástroje pro datové analýzy a rozbory, nástroje pro předdefinované sestavy, nástroje pro rychlé ad hoc dotazy, nástroje typu data mining. Další manažerské aplikace Další manažerské aplikace CRM (Customer Relationschip Management) Řízení vztahů se zákazníky Přístup k zákazníkovi jako manažerská metoda, podpořená produktem IS/IT. Hlavním úkolem je poskytovat informace pro řízení nebo změnu vlastní podnikatelské činnosti firmy. Zpracovávají se znalosti o zákaznících, co, kdy, proč nakupují ve kterém teritoriu, co zákazníkovi nejlépe vyhovuje, jak stimulovat zákazníka, jak předpovídat jeho budoucí chování atd. Nasazení CRM v podniku je proces tvořený několika etapami: Tradiční CRM (firma vybuduje centrální databázi zákazníků pro všechna oddělení firmy). Pokročilé CRM (nainstaluje se speciální IS/IT produkt analytického charakteru podporující současně marketing nebo obchodování). Aktualizované CRM (zavedou se kontaktní centra a jejich integrace s aplikacemi CRM a ostatními komponentami IS/IT firmy a někdy i s IS jiných obchodních partnerů). Funkční CRM (fungující integrace všech produktů ERP včetně CRM pro úspěšný marketing, řízení obchodu včetně realistických prognóz, odvozování zkušeností z jednotlivých obchodních případů). Další manažerské aplikace ROLAP Následující dva typy manažerských aplikací slouží pro podporu a řízení výroby a logistiky ve firmě: APS (Advance Planning and Scheduling) Systémy pro pokročilé plánování a řízení výroby Určeny pro tvorbu dílenských výrobních plánů, pro řešení vysokých zásob, nespolehlivých dodávek, slouží především pro optimalizaci plánování v rámci jedné firmy. SCM (Supply Chain Management) Řízení dodavatelských řetězců Soustřeďují se na koordinaci několika výrobních jednotek v rámci dodavatelského řetězce, jejich výsledkem je optimalizace dodávek z pohledu času a nákladů na vyřízení této dodávky. 4

27 ROLAP Na co hledá BI odpovědi? Kdo jsou naši nejlepší dodavatelé nebo nejlukrativnější zákazníci? Jací zákazníci pravděpodobně budou lukrativní, kdy a do jaké míry? Jaké jsou základní příčiny problémů s kvalitou produktu a jak je můžeme ekonomicky minimalizovat? Jaké faktory mají přímý vliv na naše hospodářské výsledky? Realizace BI Aplikace BI může být v podniku zavedena dvěma postupy V rámci ERP, kdy se využívají předem připravené analytické moduly Jako specializovaný software v rámci projektu s následujícími etapami: Specifikace zadání Analýza BI řešení a posouzení datových zdrojů Modelování a návrh datového skladu a technologické platformy (specifikace komplexních nároků na SW a HW) Návrh transformací ETL (definice transformací a pravidel mezi produkčními daty a analytickými daty) Implementace řešení BI (programování, testování, customizace, zaškolení, dokumentace,..) 5

28 Softwarové inženýrství Softwarová krize Definice (Fritz Bauer, 1968): Softwarové inženýrství je zavedení a používání řádných inženýrských principů tak, abychom dosáhli ekonomické tvorby softwaru, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. Ekonomická tvorba SW: Zahrnuje vhodné sestavení vývojového týmu, vhodnou volbu správného vývojového nástroje, zvážit, zda vyvinout nebo koupit knihovnu, komponentu, nalézt společnou řeč se zadavatelem, zvážit budoucí údržbu a rozšiřování programu. Vznik v 70. létech, první aplikace umožňující interakci s uživatelem, produkty šité na míru, první chyby, nedokončené projekty, 80. léta masivní rozvoj softwarového inženýrství, silný nástup metodik, OO přístupu, standardizace, rozvoj produktových řad, komponent, architektur a modelů 1997 je softwarové inženýrství uznáno jako obor s certifikátem v USA. Charakteristickým znakem SW krize bylo neúnosné prodlužování a prodražování projektů, nízká kvalita programů a jejich špatná údržba a inovace. Příčiny proč došlo ke krizi: Špatná komunikace Nesprávný přístup Nesprávné odhady Špatné plánování Nízká produktivita práce Neznalost základních pravidel Podcenění hrozeb a rizik Nezvládnuté technologie Program, produkt, systém? Vývoj IS/IT Program SW výrobek splňující nějakou konkrétní funkci (přesná definice: pod pojmem program budeme chápat smysluplnou posloupnost příkazů vložených do počítače, která má předem stanovený význam, která sleduje nějaký plán a jejímž výsledkem je provedení nějakého úkolu nebo výpočtu). Softwarový produkt podobný jako program, v průběhu jeho vývoje byly uplatněny některé inženýrské techniky, např. analýza, testování, existuje dokumentace, uživatelská podpora či nápověda. Programový systém soubor navzájem propojených SW produktů pro uplatnění v některé oblasti, obsahuje interakci s okolím. Hranice mezi těmito třemi pojmy není ostrá ani vymezená. Softwarové inženýrství vychází z pěti principů 1. princip modelování 2. princip iterace 3. princip strukturování 4. princip životního cyklu 5. princip automatizace Všechny tyto základní principy tvoří komplex metodologií pro řízení a výstavbu IS. Základní pojmy Metodika (metodologie) - doporučený souhrn etap, přístupů, zásad, postupů, metod, technik a nástrojů pro tvůrce IS, určuje kdo, kdy, co a jak má dělat během vývoje a provozu IS Metoda - určuje CO je třeba dělat v určité fázi, je spojená s přístupem Technika - určuje JAK dosáhnout výsledku, je přesnější a konkrétnější než metoda Nástroj - je svázán s technikou, je to prostředek k uskutečnění nějaké činnosti, ČÍM dosáhnout výsledku Životní cyklus softwarového díla Začíná prvotním nápadem něco řešit nebo vylepšit pomocí IS/IT v souladu s informační strategií podniku, končí likvidací produktu a výměnou za jiný. ŽC SW obsahuje zhruba tyto etapy: Specifikace problému Analýza Návrh Implementace Zavedení a testování produktu, dokumentace Provoz, údržba a rozvoj produktu 1

29 Modely ŽC Modely určují postup při tvorbě SW a zvolená podoba modelu je závislá na osobnosti manažera projektu a charakteru celého týmu. Modely jsou jádrem metodik a určují posloupnosti aktivit v metodikách. Model vodopád, Model spirálový, Model prototyp, Model iterativní a přírustkový. Vodopádový model životního cyklu Vodopádový model životního cyklu (není to metodika), pro rozsáhlé projekty je nevhodný, přinesl však základní členění softwarového procesu a jejich logickou posloupnost, ve své době převratný, dnes má stále zvuk. Všechny podstatné fáze jsou prováděny ve stanoveném pořadí s žádnými nebo minimálními iteracemi. Viz obr. Fáze vodopádového životního cyklu Definice problému (výsledkem je dokument Úvodní studie, tj. hrubý, základní, přibližný popis požadavků na systém) Analýza a specifikace požadavků (výsledkem je dokument Specifikace požadavků, existuje standard pro specifikaci požadavků IEEE , dokument je odsouhlasen a podepsán zákazníkem) Návrh a tvorba architektury obsahuje tyto podfáze Určení implementačního prostředí, vývojového nástroje, pgmovacího jazyka, technologií Vytvoření architektury systému, logické rozdělení na subsystémy a další funkční celky Namapování logického návrhu do fyzické struktury Definice chování modulů, specifikace práce s daty Implementace (naprogramování návrhu) Integrace a testování Provoz a údržba (nekončící proces úprav, oprav, vylepšování a ladění aplikace). Spirálový model životního cyklu Barry Boehm (1985) Do procesu vývoje zavádí klíčové koncepty, iterativní přístup a opakovanou a důslednou analýzu rizik. Model náleží do skupiny riziky řízených přístupů (v závislosti na výsledcích rizikových analýz se rozhoduje o dalším směru vývoje, na konkrétním postupu). Spirála ukazuje jakými kroky vyvíjený produkt prochází, velikost spirály (radiální rozměr) ukazuje časové a finanční náklady. Základní pojmy jsou rizika, prototyp, plánování a cyklický iterativní vývoj. Spirálový model životního cyklu Spirálový model životního cyklu Vývoj složený z jednotlivých cyklů (všechny obsahují povinné plánování, ověření a analýzu rizik) 1. cyklus - nalezení globálních rizik, zpracování základního konceptu a rozhodnutí o použitých metodách 2. cyklus - konstrukce a ověření specifikace požadavků 3. cyklus - vytvoření a ověření detailního designu 4. cyklus - implementace, testování a integrace Viz obr. Z tohoto modelu se vyvinuly další modely např. model Win- Win 1994 (je detailnější, obsahuje konkrétní náplň). V současnosti se již spirálový model nevyvíjí, na základě těchto principů ale vzniká mnoho dalších propracovaných metodologií, např. Rational Unified Process, obecně iterativní metoda vývoje (viz dále a také Doplněk k přednášce 5). 2

30 Model prototypování Prototyp IS je dočasná verze systému, která ukazuje základní rysy systému, který bude později implementován Prototyp musí být vytvořen rychle - speciální prostředky Na prototypu se odzkouší schůdnost, účinnost řešení, obrazovky atd. Používají se RAD nástroje (Rapid Application Development) Model prototypování Sběr a analýza požadavků Rychlý návrh Vylepšení návrhu Vytvoření prototypu prototypu Typy prototypu Ilustrativní prototyp (důraz je kladen na vzhled a uživatelské rozhraní, vhodný při dialogu se zákazníkem, RAD nástroje, vyhazovací prototyp) Funkční prototyp ( implementuje se jádro systému, minimální počet funkcí a postupně se přidávají, tzv. vývojový prototyp) Ověřovací prototyp (implementuje se jen část systému aby se ověřilo, zda vyhovuje požadavkům nebo technologii) Vyhodnocení prototypu zákazníkem Specifikace systému Návrh a implementace systému Model prototyp Prototyp je částečnou implementací produktu, nebo části produktu, v logické nebo fyzické formě, která prezentuje všechna vnější rozhraní. Kritickým faktorem úspěšného prototypování je rychlost obrátky při návrhu a tvorbě prototypů. Většinou se tento model hodí při vývoji menších systémů a na úrovni subsystémů. Model prototypování Iterativní metoda vývoje Jiná klasifikace prototypů Podle toho co prozkoumává Prototyp chování (např. prototyp UI, storyboard prototyp na výkresu) Prototyp struktury vysvětluje architektonické nebo technologické souvislosti Podle výsledků a pozdějšího využití Výzkumný prototyp (Exploratory Prototyp), aby vývojář pochopil chování nebo technický požadavek, většinou vyhazovací prototyp Evoluční prototyp (Evolutionary Prototyp), je přepracováván a vylepšován do finálního produktu Proof of Concept Prototyp (prototyp dokazující koncept vyhazovací, pouze se jím dokáže, že řešení je možné nebo že algoritmus existuje a může být realizován.) Vodopádový životní cyklus vývoje SW platí pouze za těchto předpokladů: požadavky budou stálé systém lze navrhnout na papíru integrace se dá provést v krátkém čase integrace nevnese nové chyby do systému Pro současné velké projekty v období neustálých změn je vhodnější iterativní metoda, kde iterace = malý vodopád. Iterativní metoda vývoje Obecně platí: první iterace odhalí největší rizika, každá iterace produkuje spustitelnou verzi, každá iterace obsahuje integraci a testování. Výhody iterativní metody včasná eliminace rizik jednodušší řízení (a akceptovatelnost) změn znovupoužití školení týmu během celého projektu lepší kvalita produktu První hrubé rozdělení životního cyklu je na fáze, každá fáze má několik iterací, a každá fáze končí milníkem. Iterativní metoda vývoje Fáze počátek (asi 10% celkového času) vize projektu definice obchodního případu definice rozsahu projektu milník Rozsah projektu (souhlas zadavatele s rozsahem systému a odhadem nákladů, porozumnění požadavkům, definice rizik a priorit) elaborace (asi 30% celkového času) funkční požadavky základní linie architektury plán pro další fáze a další iterace milník Architektura (stabilní architektura, její popis, model use case, dodatečné požadavky, revidovaný seznam rizik a priorit, plán pro zbytek projektu). 3

31 Iterativní metoda vývoje Fáze konstrukce (asi 50% celkového času) výroba produktu tzv. beta verze příprava nasazení milník Úvodní funkčnost (funkční a stabilní verze systému, pokrytí požadavků, eliminace rizik, uživatelská dokumentace) zavedení (asi 10% celkového času) nasazení produktu do rutinního provozu výroba médií a dokumentace instalace školení a podpora milník Nasazení produktu (systém v rutinním provozu, vyškolení uživatelé, fungující podpora, vyladěný výkon, vyhodnocení projektu a doporučení jak dál) Iterativní metoda vývoje Každá iterace obsahuje Základní pracovní postupy: správa požadavků analýza a návrh implementace testování vyhodnocení plánu. Podpůrné pracovní postupy řízení projektu konfigurace prostředí konfigurační řízení. Další pracovní postupy (pouze v první nebo poslední iteraci) obchodní modelování úvodní plánování dodání. RUP RUP Konkrétní metodika založená na iterativní metodě Klíčové pojmy Iterativní vývoj SW Správa a řízení požadavků Použití komponentové architektury Vizuální modelování Průběžné zjišťování a ověřování kvality SW Řízení změn Elementy metodiky Pracovníci a role Aktivity Artefakty Pracovní procesy Viz obr. RUP Pozn. Unified Software Development Process je podobná RUP, ale je bezplatně dostupná. Agilní metodiky vývoje SW Agilní metodiky vývoje SW Cílem těchto metodik je zajistit vytvoření SW produktu rychleji a efektivněji a snáze tak splnit požadavky dnešní doby. Základní principy Iterativní a inkrementální vývoj s krátkými iteracemi Důraz na přímou, osobní komunikaci v týmu Nepřetržité sepětí se zadavatelem resp. uživatelem Rigorózní, opakované průběžné automatizované testování. Nejsilnější důraz je zde kladen na zdrojový kód. Vhodné pro projekty s nejasným, nečistým nebo často se měnícím zadáním. Skupina moderních metodik, které vycházejí z toho, že jedinou cestou, jak prověřit správnost navrženého systému, je rychle ho (nebo jeho část) navrhnout, předložit zákazníkovi k vyzkoušení a mít zpětnou vazbu. Usnadnit změnu je mnohem efektivnější než se snažit jí zabránit a je třeba se učit reagovat na nepředvídatelné události. Dává se přednost: individualitám a komunikaci před procesy a nástroji, provozuschopnému SW před obsažnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, reakci na změnu před plněním plánu. 4

32 Agilní metodiky vývoje SW Manifest agilního vývoje Dokument se základními principy Konkrétní metodiky Extrémní programování SCRUM Developmet Process Crystal metodiky (princip síly komunikace a lehkosti produktu, metodiky se vyvíjí na míru projektu) Testy řízený vývoj Adaptive Software Development (ASD) Feature Driven Development (FDD) Agilní metodiky vývoje SW Extrémní programování (XP) 5 základních hodnot XP (komunikace, jednoduchost, zpětná vazba, odvaha a respekt). 12 základních postupů (např. malé verze, jednoduchý návrh, párové programování, nepřetržitá integrace, atd.) 4 základní činnosti (testování, psaní kódu, poslouchání a navrhování). Vhodná metodika pro menší týmy, kteří pracují na měnících se nebo nejasných zadáních, nebo tam, kde je jednoduchá zpětná vazba. 5

33 Metodologie strukturované analýzy - princip Ve strukturovaném přístupu obecně hovoříme o principu tří úrovní: 1. Analýza systému - výsledek této fáze odpovídá konceptuálnímu modelu (model reality) CO 2. Design systému (konstrukce) - výsledkem je technologický model JAK 3. Implementace systému - generováním kódu vznikne implementační model ČÍM Metodologie strukturované analýzy Konceptuální model obsahuje : Datový model Funkční model Model vnějšího chování Model řízení Technologický model obsahuje: Model pgmové struktury Model logických datových struktur Návrh obrazovek a komunikace Implementační model obsahuje: Fyzický model databáze Programový text - vygenerovaný kód viz obrázek Horizontální a vetikální integrace!!! Metodologie strukturované analýzy Metodologie strukturované analýzy Metodologie strukturované analýzy (klasické z historie) Strukturovaná analýza dle De Marca Historicky první popsaná metodologie, jejíž myšlenky jsou platné dodnes, zařadil strukturovanou analýzu jako 2. etapu ŽC IS, vstupem je souhrn uživatelských požadavků. Logické modelování Gane/Sarson Metoda založena na tvorbě DFD, nově použit ERD). Yourdonova moderní strukturovaná analýza Provádí se dekompozice na základě událostí, objevuje se nový model - esenciální model systému, který obsahuje jak model okolí (nástrojem kontextový diagram), tak model chování systému (nástrojem je DFD). Metodologie SSADM (Structured Systems Analysis and Design Method) Je striktněji formulována než jiné, obsahuje velmi podrobný postup a popis jednotlivých kroků včetně kontrol a předepsaných výstupů před přechodem na další krok. Vychází z datového modelu (ten se v čase nemění a tvoří základ architektury) a vytváří tři základní modely: model entit (Logical Data Structure, LDS), model funkční (DFD) a životní cyklus entity (ELH). 1

34 Metodologie vývoje IS - trendy Trendy v oblasti metodik a metodologií 1. Nahrazování vodopádového postupu iterativním. 2. Pronikání objektových metod, metodik a nástrojů. 3. Globalizace analýzy (BPR). 4. Posun od tzv. hard k soft metodikám (viz agilní metodiky). 5. Vznik nových metodik pro implementaci a přizpůsobení TASW specifickým podmínkám v podniku (ACCELERATEDSAP). 6. Nové kategorizace metodik. Metodologie vývoje IS - Euromethod Euromethod Cíle: Pomoci vzájemnému porozumění zákazníků a dodavatelů na mezinárodním trhu. Pokus o pojmové sladění různých metod vývoje IS. Snaha o zlepšení kvality a efektivnosti procesu vývoje IS. Popis Eurometody je tvořen několika vzájemně provázanými dokumenty (příručka zákazníka, příručka dodavatele, příručka plánů dodávek, příručka propojení metod, případová studie). Princip: Viz obrázek Metodologie vývoje IS - Euromethod Metodologie vývoje IS - závěr Pozn. Zatímco hlavním předmětem zájmu firemních metodik je specifický postup vývoje IS podporován příslušným produktem CASE, státem a mezinárodním společenstvím podporované metodiky se snaží integrovat jednotlivé vyvíjené a vzájemně související systémy tak, aby dohromady tvořily systém, ne jednotlivé nespolupracující počítačově zpracovávané agendy. Metodiky jsou specifickým zbožím k zakoupení v podobě tištěných publikací, hypertextových souborů, školení, kurzů... Metodologie vývoje IS - závěr Moderní kategorizace metodik Kritérium Zaměření metodiky (globální a projektové metodiky) Kritérium Rozsah metodiky (podle fází ŽC, rolí a dimenzí) Kritérium Váha metodiky (PARTS Precision, Accuracy, Relevance, Tolerance, Scale) Kritérium Typ řešení (nové řešené, integrace nového řešení, upgrade, implementace TASW, outsourcingové řešení Kritérium Doména (řešení BI, ERP, CRM, SCM, WorkFlow, e-commerce, ) Kritérium Přístup k řešení (strukt., objekt., RAD, ) Základní dělení na dva hlavní proudy Rigorózní (přesně definované procesy, činnosti a artefakty) a Agilní metodiky (přesně definují spíše principy a praktiky). Pozn. CMM - Capability Maturity Model Metodiky hodnocení softwarových procesů jsou založeny na přesvědčení, že kvalita procesu určuje kvalitu produktu, a proto popisují postupy, které umožňují hodnotit úroveň zralosti procesů při vývoji software. Nejznámější z těchto metodik je Model zralosti (Capability Maturity Model). Úroveň zralosti (vyspělosti) je vymezený soubor charakteristických znaků, stanovený a přijímaný jako srovnávací základna pro hodnocení dosaženého daného stupně procesní vyspělosti. Každá úroveň představuje výchozí stav pro další průběžné zlepšování. Dosažení vyšší z vrstev vyšší úrovně znamená uplatnění určitých zásad ve fungování procesů organizace, jejichž výsledkem je procesní způsobilost a vyspělost organizace. Byl vytvořen pro měření vyspělosti organizace a jejich procesů, v SW inženýrsví se používá pro měření kvality SW procesů. 2

35 CMM model vyspělosti SW procesů CMM 1. Počáteční úroveň (initial) Softwarové procesy jsou náhodné a chaotické. Organizace na této úrovni zralosti nemají stabilní prostředí pro vývoj a údržbu software, reagují pouze na vzniklé problémy. Schopnost softwarových procesů na úrovni 1 nelze předpovídat, protože se procesy neustále mění a výsledky jsou ovlivněny schopnostmi a kvalifikací jednotlivců. 2. Opakovatelná úroveň (repeatable) Organizace na této úrovni zralosti mají definovány a zavedeny postupy řízení projektu. Cílem úrovně 2 je zavedení efektivního řízení softwarových procesů. Efektivní softwarový proces je dokumentován, vyžaduje se jeho plnění, lidé jsou pro něj vyškoleni, je měřitelný a je možné jej zlepšovat. Manažeři sledují náklady, plán a funkcionalitu, problémy jsou identifikovány ihned při vzniku, jsou definovány projektové standardy a dohlíží se na jejich dodržování. Schopnost softwarových procesů na úrovni 2 může být definována jako disciplinovaná. CMM CMM Definovaná úroveň (defined) Organizace na této úrovni zralosti má definovány, dokumentovány a standardizovány procesy pro řízení i softwarově inženýrské činnosti, které jsou navzájem integrovány v rámci celé organizace. Je definován Standardní softwarový proces organizace, který je potom přizpůsobován na podmínky jednotlivých projektů. Tím vzniká Softwarový proces projektu. Zaměstnanci i manažeři jsou vyškoleni pro plnění rolí v procesech. Schopnost softwarových procesů na úrovni 3 může být definována jako standardní a konzistentní, protože jak činnosti inženýrské, tak činnosti řízení jsou stabilní a opakované. 5. Optimalizovaná úroveň (optimizing) Organizace na této úrovni zralosti má vytvořeny podmínky pro kontinuální zlepšování procesů. Organizace identifikuje slabé a silné stránky procesů předem ve snaze zabránit vzniku problémů. Data o efektivnosti softwarových procesů jsou využívána pro analýzy přínosů nových technologií a navrhovaných změn. Schopnost softwarových procesů na úrovni 5 může být definována jako kontinuálně se zlepšující. 4. Řízená úroveň (managed) Organizace na této úrovni zralosti má stanoveny detailní metriky softwarových procesů i kvality produktu. Data z projektů se uchovávají v databázi a analyzují. Kontrola projektů je zajištěna odhalováním odchylek od definovaných mezí. Schopnost softwarových procesů na úrovni 4 může být definována jako predikovatelná, protože proces je měřitelný a operuje v rámci měřitelných mezí. Pozn. Metodologie v praxi Navision Poz. Metodologie v praxi AcceleratedSAP 3

36 Pozn. Metodologie v praxi AcceleratedSAP Internetové webové aplikace a projekty Složení vývojového týmu (navíc webdesignéři, grafici, flash programátoři, reklamní textaři, experti na aktivní marketing, website ) Požadovaná rychlost vývoje (často rozhodují dny), je-li možné koupit hotovou aplikaci, téměř vždy se to vyplatí. Předpokládaná budoucnost webové aplikace postupem času se budou vyvíjet, rozšiřovat, vylepšovat, měnit vzhled i funkce. Jiný přístup k testování (testování rozvržení, grafiky, barev, rozlišení,.. testování okem). Internetové webové aplikace a projekty Hlavní cíle webových aplikací Kvalitní obsah Snadné používání Častá aktualizace obsahu Minimální doba potřebná ke stažení Uspokojení potřeby zákazníka (musí poskytnout to, co zákazník chce a hledá). Metodiky vývoje webových aplikací Jenifer Flaming WebWAVE Development Process WebWAVE Ongoing Development Process (pro správu a údržbu webu), obsahuje 3 fáze: vyhodnocování, modernizace a údržba. Nebo také CASE (Computer Aided Software Engineering) Je kategorie počítačových prostředků, které podporují : práci tvůrců IS včetně plánování projektu, řízení procesu vývoje IS (dokumentace a okamžitá informace o stavu a obsahu vyvíjeného IS), integraci a konzistenci návrhu IS (na základě definovaných integritních pravidel), testování a nasazení aplikace. Jádrem je centrální depozitář (Systémová Encyklopedie) centrální databáze pro uchovávání info o všech objektech IS, vložená info je použitelná ve všech dalších krocích. CASE Výstupem CASE je: standardní dokumentace modelů, generované pgmové kódy, popisy databáze, prototypová řešení, možnost Reverse Engineering (zpětné generování abstraktních popisů z konkrétního kódu). Funkce a vlastnosti CASE Konzistentní ovládací prostředí, systémová encyklopedie, prostředky pro verifikaci konzistence a kompletnosti dat včetně podpory normalizace datových struktur, obsahuje textový editor, OLE, obsahuje prostředky prototypingu včetně simulace vstupů a výstupů, obrazovek, funkčních kláves CASE Existují různá hlediska pro dělení CASE podle podporovaných etap ŽC IS: Integrované - podporují celý životní cyklus IS Specializované (Upper, Middle a Lower CASE podle toho, pro jakou fázi ŽC IS jsou určeny viz dále) podle podporovaných metodologií: SDM, YSM, SSADM, některé CASE jsou úzce svázány s firemní metodologií, jiné univerzální. podle modelů: strukturované hybridní objektové podle podporovaných databázových platforem. 4

37 CASE CASE Specializované CASE PreCASE podporuje tvorbu globální strategie. UpperCASE podporuje specifikaci požadavků, modelování organizace podniku a procesů a podporuje definici klíčových informačních toků. Hlavní nástroje jsou DFD a ERD bez podrobností, základní diagramy OOM (Objektově orientované modelování). MiddleCASE podporuje podrobnou specifikaci požadavků a vlastní návrh systému. Hlavní nástroje jsou DFD, ERD, detailnější diagramy OOM, prostředky pro prototypy, generátory sestav, obrazovek. LowerCASE podpora kódování, testování a údržby, reverzního inženýrství. PostCASE podporuje organizační inženýrství (zavedení, provoz a údržbu). 5

38 Objektově orientovaný přístup (úvod) Objektově orientovaný přístup (úvod) Proč objekty? Objektový přístup umožňuje lepší využití kódu než knihovny procedur, možnost znovupoužití. Elegantně se zvládnou prostředky pro okenní rozhraní systémů. Dávkové úlohy se staly interaktivními (objekt reaguje na více podnětů, na každý jinak). Metodický faktor (mnoho dřívějších doporučení je nyní skryto v definici tříd a objektovém přístupu). Definice Objekt je cokoliv, jakákoliv věc, stavební jednotka, která modeluje nějakou část světa (člověk, tiskárna, kamera, faktura, hotelový pokoj, pacient, diagnoza, ) Objekty (pohromadě jsou zde uzavřena data i jejich vlastnosti a chování) jednoho systému jsou propojené vazbami a působí na sebe navzájem. Objekt v OOP Objekt v OOP Základní vlastnosti objektu struktura objektu Objekt obsahuje 1. vnitřní paměť (má vlastnost něco si pamatovat) - atributy objektu, zvenčí je objektu nepřístupná, je jeho soukromou záležitostí, co si objekt pamatuje a jak. Představuje stav objektu. Stav objektu se mění podle chování objektu. Stav objektu je definován hodnotami všech atributů v daný okamžik. 2. metody objektu (procedury a funkce, obecněji posloupnost kódu pgmu, které vykonávají nějakou činnost nad vnitřní pamětí). Opět zvnějšku neviditelné a nepřístupné. Představuje chování objektu, schopnost objektu něco dělat. 3. jiné objekty, kterým je schopen poslat zprávy a tak řídit jejich činnost. 4. schopnost přijmout a zpracovat zprávu (požadavek) zvnějšku. Každý objekt obsahuje tzv. protokol zpráv v rozhraní (přiřazení zprávy metodě objektu). Každá zpráva může mít vstupní a výstupní parametry, jediná možnost, jak spolupracovat s objektem, je poslat mu zprávu. Lze také říci, že zpráva slouží k vybírání údajů z objektů resp. k zapisování údajů do objektů, také ke spouštění dalších operací. Protokol je množina všech zpráv, které je možné objektu poslat. Bez znalosti protokolu uživatelé s objekty nemohou pracovat, nevědí, co objekty umějí udělat. Obr. 2x obecný objekt Objekt v OOP - zprávy Zpráva je komunikační jednotka mezi dvěma objekty, která umožňuje, aby funkce SW aplikace byla výsledkem spolupráce skupiny objektů. Zprávy jsou tvořeny kombinací řídících a datových toků. Typy zpráv Konstruktor pro tvorbu objektů. Destruktor pro rušení objektů. Modifikátor pro modifikaci stavu objektů. Selektor vrací info o stavu objektu. Iterátor pro prohlížení obsahu datové struktury. Typy přenosu zpráv Jednoduchý přenos Synchronizovaný přenos Asynchronní přenos Objekt v OOP- odvozené vlastnosti Odvozené vlastnosti objektu Používání abstrakce Existence objektů Definování tříd objektů Zapouzdření (nejdůležitější princip OOP) Ukrývání implementace Komunikace objektů Polymorfismus Dědičnost 1

39 Objekt v OOP- odvozené vlastnosti Objekt v OOP- pohledy Abstrakce (proces vytváření jednoduché reprezentace složité reality). Objekty a třídy (objekt má atributy, chování, vztahy s jinými objekty, třída je abstrakce objektů se stejnými vlastnostmi). Zapouzdření (encapsulating) data a funkce s nimi pracující jsou spojeny do jednoho objektu, data jsou skryta před ostatními objekty a lze k nim přistupovat pouze pomocí metod objektu. Výhody: data jsou chráněna před narušením zvenku, ostatní objekty nemusí znát vnitřní strukturu dat, realizace změny v datech je jednodušší, projeví se jen v jedné třídě. Ukrývání implementace (možnost používat metody objektů bez znalosti jejich implementace). Pozn. OO programátor je buď tvůrce třídy nebo klientský programátor. Na objekt se díváme dvěma pohledy a) objekt, který použijeme v programu již jako hotový, naprogramovaný, zajímají nás veřejná data a operace, b) objekt, který máme za úkol zhotovit nebo opravit. Ad a) zajímá nás popis zpráv a co se voláním těchto zpráv děje, tedy zajímáme se o chování objektu (pro klientské programátory). Ad b) zajímají nás všechny vlastnosti, objekt musíme otevřít a zpracovat jeho vnitřek, vždy na úrovni, kde je to třeba (pro programátory tvůrce). Objekt v OOP- odvozené vlastnosti Objekt v OOP- odvozené vlastnosti Komunikace objektů (aby existovala, musí mít jeden objekt přístup k druhému musí mít odkaz na druhý objekt). Dědičnost (vlastnost tříd viz dále). Polymorfismus (stejná zpráva může vyvolávat různé operace) Pokud mají různé objekty shodné protokoly, nemusí to znamenat, že mají stejnou datovou strukturu a stejné metody. Objekty různých tříd mají metodu se stejným jménem, přičemž její implementace se v jednotlivých třídách může lišit. Tj. dva různé objekty mohou přijmout tutéž zprávu a každý z nich na základě této zprávy vyvolá jinou metodu (operace zobraz vyvolaná zasláním zprávy jednou zobrazí text a jednou obrázek). Jinými slovy jedna zpráva - dva různé objekty - dvě různé metody - dvojí reakce na tutéž zprávu. Třída v OOP - vlastnosti Třída je předpis pro budoucí objekt (abstrakce), ale samotnou realizací pro řešení analytického problému je objekt jako instance třídy. Merunka: Třída objektů slouží k tomu, abychom mohli strukturu dat a množinu metod patřících jednomu druhu objektu jednoduše popsat společně pro všechny objekty, které do daného druhu patří. Na třídy v OOP vlastně nahlížíme jako na popis toho, jaké druhy objektů v systému potřebujeme. Pro každou třídu pak definujeme, jakou budou mít její objekty strukturu a metody. Platí: objekt je instance třídy, objekt přebírá vlastnosti třídy, třída má deklaraci, výčet atributů, metody, objekt má hodnoty atributů a nemůže mít jiné metody než jeho třída. Třída v OOP - vlastnosti Dědičnost - sdílení kódu je znovupoužitelnost na úrovni deklarace třídy, dědění je vztah mezi třídami nikoli mezi jejich objekty, třída, ze které se dědí je předek (nadtřída), třída, která dědí je potomek (podtřída). odvozená třída obsahuje všechny datové položky třídy předka a kopíruje rozhraní předka, tj. zprávy, které můžeme poslat objektům předka můžeme poslat i objektům potomka. Objekty potomka dědí i chování předka, ale chceme-li, aby potomek měl jiné chování, můžeme přidat novou metodu nebo změnit metodu předka překrytím, zastíněním overriding viz předchozí obr. existují dva projevy dědění: generalizace (navrhnu objekty (třídy), k nim rodiče), specializace (navrhnu třídu, z ní potomky). 2

40 Specifikace třídy Další pojmy v OOP Specifikace třídy obsahuje Jméno třídy Atributy třídy Operace, které jsou platné pro všechny objekty třídy. Viditelnost atributů a operací Private - neviditelné, důsledně zapouzdřené části třídy Protected - viditelné pouze z dané třídy odvozeným objektům Public jsou viditelné všem objektům třídy Zpráva - požadavek, který jeden objekt posílá druhému. Link - spojení mezi objekty, realizováno tak, že procedura jednoho objektu volá proceduru druhého objektu. Asociace - spojení mezi třídami, které může a nemusí být realizováno linkem - zobecnění linku. Každý objekt má svou identitu. Každý objekt má odpovědnost za svou činnost. Objekt má chování znamená, že objekt vlastní metody, které toto chování zajistí. Objektově-orientovaný přístup obecně Objektově-orientovaný přístup obecně Výhody: znovupoužitelnost a snadná lokalizace změn a chyb, oddělení detailů od celku, rozšiřitelnost a sémantická bohatost, snadnější popis rozhraní s vnějškem, snazší definování celého systému, zdůrazňujeme to, co objekt je a ne jak je užit - objektové aplikace bývají stabilnější. Nevýhody: objektově-orientovaný kód není efektivní, nová metodika si vyžádá zaškolení pracovníků, neexistují efektivní nástroje pro OOA. OOA Object Oriented Analysis vychází z objektově-orientovaného programování, pohled na svět jako na soustavu spolupracujících objektů kvalitativní změna myšlení při návrhu systémů, blízké přirozenému lidskému chápání, překonání semantické mezery objekty v pojetí uživatelů a pgmátorů znamenají totéž. Naučit se objektově programovat znamená naučit se objektově myslet. Prakticky objektově myslet znamená prakticky používat nějakou školu objektového modelování. Pgmátor si nejprve musí svůj pgm nějak představit a namalovat a teprve poté může tvořit kód (Kraval). Vizuální modelování Vlastnosti Informace v obrázcích Prostředek komunikace (modely, diagramy) Zachycuje obch. procesy, věcnou problematiku, architekturu systému Je podporováno silnou notací a metodologiemi Metodologie Booch, Coad,Yourdon OMT (Object Modeling Technik), Rumbaugh OOSE (Object-Oriented Software Engineering) Jacobson (scénáře Use Case) Modely vytváříme proto, že nejsme schopni plně pochopit komplexní systém jako celek. Model je zjednodušení reality. Díky modelům vizualizujeme stávající nebo vytvářený systém, specifikujeme strukturu nebo chování systému, získáváme základ pro konstrukci systému a dokumentujeme rozhodnutí o systému. UML Unified Modeling Language UML poskytuje pravidla pro pojmenování, rozsah platnosti, rozsah viditelnosti, omezení, provedení modelu různé specifikace rozšiřitelnost jako jsou stereotypy, dodané hodnoty přestože je nejčastěji spojován s modelováním OO SW díky rozšířením má mnohem širší využití, je to pouhá notace, syntaxe (standard pro zobrazení a popis modelů), nikoliv metodika modelování. Součásti UML Definice notace UML (syntaxe) Metamodel UML (sémantika) Jazyk OCL pro popis omezení v modelech Specifikace převodu do výměnných formátů (CORBA, IDL, XML) 3

41 UML Unified Modeling Language UML Unified Modeling Language 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 UML předměty (thinks), vztahy (relationship), diagramy (diagrams). UML skupiny artefaktů Týkající se struktury systému tvoří statickou část modelu, třídy, rozhraní, use case, komponenty. 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 popisy, anotace, poznámky. UML Unified Modeling Language UML Unified Modeling Language UML - vztahy Agregace (závislost) jeden prvek závisí na druhém. Asociace propojení prvků. Dědičnost specializace/generalizace. UML - diagram Grafická reprezentace obsahu modelu zachycení prvků a jejich vztahů. Pohled na systém z různých perspektiv. Různé typy diagramů Diagram případů užití (use case), tříd, složené struktury, objektů, sekvenční, komunikační, stavový, aktivit, komponent, nasazení, balíčků (package), zjednodušené interakce a časování. Jednotlivé typy diagramů odpovídají pohledům na navrhovaný systém. Statické a dynamické pohledy, pohled uživatele, pohled technologický. Use case diagram UML Use case diagram UML 1. Diagram Use case (UCD, diagram případů užití) 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. 3 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), Vztah (mezi aktorem a use case, mezi use case, výjimečně mezi aktory). 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é - role jiné softwarové systémy čas Use case (typ jednání, případ užití) Profesor Student jakákoliv funkčnost, která dává měřitelnou hodnotu uživatelům tohoto systému, aktorům, reprezentuje ucelenou funkcionalitu problémové domény. Údržba kurzu Rozvrh kurzu Údržba seznamu 4

42 Use case diagram UML Student Systém placení 3 typy vztahů v UCD 1. Vztahy mezi aktorem a use case -aktor komunikuje se systémem, využívá daný use case (vyvolává a účastní se use case). Údržba studijního plánu Seznam studentů v kurzu Správce Údržba rozvrhu Profesor Use case diagram UML 2. Vztahy mezi use case Use case mohou vzájemně spolupracovat ( slouží pro zjednodušení modelu a podobá se dekompozici). Rozeznáváme 3 typy vztahů mezi samotnými use case: Vazba include 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 extend 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. Vazba gen/spec Pro zobecnění nebo odvození funkcionality v rámci Use Case 3. Vztahy mezi aktory Vazba gen/spec pro zobecnění resp. odvození typů aktorů Use case diagram UML Popis use case Stručná charakteristika (1-3 věty), používají se slova z problémové domény ne technologické a odborné výrazy z IT. 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 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 UML Use case diagram UML (půjčovna CD) Informace o use case V diagramu jde pouze o vizualizaci funkcionality, ostatní 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 zaznamenání uživatelů systému, zachycení požadavků na systém, pro kontrolu a akceptaci 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ářů, pro testování, řízení projektu... Přidání nového člena Asistent Evidence rezervace Vyřazení člena Evidence zápůjčky Navýšení účtů Správce Přidání a vyřazení inventáře Zrušení nevyzvednutých nových titulů rezervací Přidání a vyřazení Výpis dlouhodobých dodatečných kopií výpůjček Člen Vyhledávání informací Čas 5

43 Sekvenční diagram UML Sekvenční diagram UML (půjčovna CD) 2. Diagram sekvenční 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. Diagram komunikace UML Diagram tříd UML 3. Diagram komunikační Ukazuje tytéž informace jako sekvenční diagram, s ohledem ne na čas, ale na propojení mezi objekty, jaké zprávy si objekty vyměňují. Slouží pro pozdější určení vztahů mezi objekty datové vztahy - dány distribucí informací, komunikační vztahy - dány spoluprací mezi objekty. 4. Diagram tříd 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 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. Třída obsahuje jméno atributy operace. 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é. 6

44 Diagram tříd UML - 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. 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é. Diagram tříd UML (půjčovna CD) 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). Stavový diagram UML Stavový diagram UML (objekt Titul v půjčovně CD) Chování systému je modelováno především pomocí diagramů aktivit i stavových diagramů 5. 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. Diagram aktivit UML Diagram aktivit (tvorba filmů) 6. Diagram aktivit 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. 7