Jiří Mašek BIVŠ Praha 2008
Procesvývoje IS
Unifiedprocess(UP)
Iterace vývoje
Rysy CASE nástrojů Podpora metodických přístupů modelování Integrační mechanismy propojení modelů Podpora etap vývoje Generování databázových skriptů Konvertování modelů do vývojového prostředí OO programovacích jazyků Reverse engineering Podpora týmové spolupráce (role, zamykání,...) Nástroje pro řízení projektů
Koncept MDA Vznik 2001 OMG ObjectManagement Groupwww.omg.org, též rozvíjí UML Standardizace modelů 4 úrovně modelů CIM - nezávislý na počítačovém zpracování PIM obecná koncepce aplikace PSM model závislý na platformě Code realizace modelu
Transformace modelů CIM > PIM Podnikové procesy -> akce uživatele v aplikaci PIM > PSM Pomocí návrhového vzoru vytvořen model závislý na platformě Přidané objekty jsou označeny PSM > Code Generování kódu Reverse engineering (Code > )PSM > PIM
Analýza IS v nástrojích CASE Definice požadavků Procesní modelování Případy užití (Use case model) Objektové třídy (Class model) Sekvenční model (Object Sequence Diagrams) Stavové diagramy (State Diagrams)
Analýza požadavků Katalog požadavků Funkční požadavky na funkčnost systému Nefunkční specifikují určité vlastnosti, omezující podmínky (odezva, použitá technologie atd... ) Později mapování na případy užití
Katalog požadavků Informace o požadavku: Kód Název Popis Priorita Původce Vlastník Stav Nadřízený požadavek Odkaz na soubor atd.
Zdroje požadavků Požadavky zákazníků písemné, získané konzultacemi,... Pracovní postupy, pravidla Legislativa dané oblasti Existující systémy zákazníka Vlastní znalosti a zkušenosti analytika HW a SW vybavení zákazníka Prostředí zákazníka
Procesní modelování Procesní hierarchie rozpad procesů Modely podnikových procesů - detailní popis
Procesní hierarchie Proces zpodrobně n v tomto diagramu Listový proces Proces zpodrobně n v jiném diagramu
Procesní hierarchie -pokračování Proces zpodrobňující jiný diagramu
Procesní (Pool) Proces v notaci BPMN Plavecká dráha (Lane) Počáteční událost (Start event) Vložený subproces Krok procesu (Task) Tok procesu (Sequece flow) Koncová událost (End event) Brána (Gateway)
Případy užití Použití systému aktérem aktér je iniciátorem Sadou scénářů 1 hlavní, alternativní Vyjadřuje co má být implementováno, nikoli jak Nepředstavují funkční hierarchii
Diagram případu užití
Aktéři případů užití
Model tříd (ClassModel) Třída Atribut Vazba Operace
Datové modelování Logický model (entity) Fyzický model (tabulky) Realizace fyzického modelu (DDL skripty)
Termíny Logický Entita Atribut UID Vazba Fyzický Tabulka Sloupec PK Cizí klíč Constraint
Tvorba datového modelu Identifikace datových entit (třídy) Definice vazeb Definice atributů Kardinality vazeb Normalizace Dekompozice vazeb M:N Vlastnosti Atributů
Normalizace databáze K čemu slouží Jaké jsou normy 0NF 5NF Příklad normalizace Důvody denormalizace složitost dotazů, rychlost vyhodnocení
0NFnultá normální forma Tabulka je v nulté normální formě právě tehdy, existuje-li alespoň jedno pole, které obsahuje více než jednu hodnotu.
1NFprvní normální forma Tabulka je v první normální formě, jestliže lze do každého pole dosadit pouze jednoduchý datový typ (jsou dále nedělitelné).
2NFdruhá normální forma Tabulka je ve druhé normální formě, jestliže je v první a navíc platí, že existuje klíč a všechna neklíčová pole jsou funkcí celého klíče (a tedy ne jen jeho částí).
3NFtřetí normální forma Tabulka je ve třetí normální formě, jestliže každý neklíčový atribut není transitivně závislý na žádném klíči schématu, neboli je-li ve druhé normální formě a zároveň neexistuje jediná závislost neklíčových sloupců tabulky.
BCNFBoyce-Coddovanormální forma Tabulka je v Boyce-Coddověnormální formě, jestliže pro každou netriviální závislost X-->Y platí, že X obsahuje klíč schématu R.
4NFčtvrtá normální forma Tabulka je ve čtvrté normální formě, je-li ve třetí a Tabulka je ve čtvrté normální formě, je-li ve třetí a popisuje pouze příčinnou souvislost (jeden fakt).
5NFpátá normální forma Tabulka je v páté normální formě, pokud je ve čtvrté a není možné do ní přidat nový sloupec (skupinu sloupců) tak, aby se vlivem skrytých závislostí rozpadla na několik dílčích tabulek.
Atributy entit Atributem entity budeme rozumět název záznamu informace, která charakterizuje popisovanou entitu. Příkladem atributů jsou např.: Číslo klienta, Rodné číslo příp. IČO Jméno (název) klienta Pohlaví Číslo pobočky, na které je klient veden Číslo půjčky Jistina. Výskytem atributůpak budeme rozumět jeho skutečnou hodnotu (číslo, text, ) který je fyzicky zapsán v SW systému. (Např. 3578974, 181028/435, Jan Novák, M, OP4, 03789/03, 270.000 apod.)
Vlastnosti atributů Datový typ Text, Celá čísla, Desetinná čísla, Logický,... Délka Povinnost Unikátnost Zda tvoří UID Datová doména šablona typu a délky
Kardinalita vazeb 1 : 1 1 : * (= 0..*) 1 : 0..1 1 : 1..* 1 : 1:3
Příkldaddatového modelování Zjednodušený systém pro evidenci půjček
Identifikace datových entit Klienti banky mohou mít účty v různých měnách Klientem banky může být jak tuzemský, tak subjekt z jiné země, který prokáže svou totožnost pomocí platného dokladu. Podmínkou je, že klient má u banky otevřený alespoň jeden účet. Půjčku s bankou projednává klient, její čerpání je sledováno pomocí zvláštního účtu pro čerpání půjčky. Klient může mít několik půjček. Účty je možno ovládat různými způsoby. Pro výpočet úroků v jiných měnách je nutno sledovat historii kursu měny.
Identifikace datových entit Čerpání Způsob ovl. Historie kurzu Půjčka Účet Země Klient Měna
Identifikace vazeb Čerpání x Způsob ovl. Historie kurzu Země x Půjčka x Účet Měna x Klient x x x x
Zjednodušený datový model Půjčka
Dekompozice vazby M : N M : N 1 : M, N : 1
Převod DM do schématu SŘBD Každá entitase překlopí do SŘBD jako tabulka se jejím jménem. (V relačních SŘBD se tabulka matematicky definuje jako relace, dále jen relace) Vazby(relationships) mezi relacemi Vazby M:N se převedou na M:1 x 1:N Vazby 1:N mezi silnými relacemi se pak vyjádří pomocí cizího klíče tj.primárníklíč master relace se zapíše jako cizí klíč do detail relace Vazby 1:N (mezi silnou a slabou relací) se vyjádří pomocí vícesložkového klíče tj. primární klíč silné relace + klíč slabé relace ve slabé relaci
Převod DM do schématu SŘBD -pokračování Názvy atributůjsou pak názvy sloupců takto vzniklé relace. Minimální jednoznačná podmnožina názvu sloupců se určí klíčem relace. V jednotlivých řádcích relace jsou pak zapsány výskytyatributůtj. alfanumerické, příp. logické hodnoty.
Dotazovací jazyk SQL Existuje řada dotazovacích jazyků pro relační SŘBD. Nejznámější je SQL (Structured Query Language). Základní strukturou je tzv. tvar SELECT A 1,.,A n Uvede se seznam atributů FROM R 1,..,R m Uvede se seznam relací, nad kterými je dotaz definován) WHERE P Příklad: Obsahuje obecně formuli zahrnující jména atributů a podmínku výběru) SELECT Jm_klienta FROM KLIENT WHERE Kód_klienta = IČO
Ukázka DM v MS Access
Část datového modelu Půjčka C_uctu Kod_klienta C_pobocky Druh_účtu Kod_oboru Kod_vysledovky Zustatek_na_uctu 123456789 26170485 181 Běžný 78 3534 55400 234567891 580742450 182 Běžný 75 3534 0 Má Účet Je pro Rodné číslo nebo IČO Název_klienta Jméno kontaktní osoby Příjmení kontaktní osoby Adresa Měst o Kraj Používá Čerpání půjčky Klient Má 26170485 INTERINVEST Praha s.r.o. Josef Balda Ocelář ská 3 Prah a Střed očesk ý Je pro Má 58074245 Josef Novák Josef Novák Na palouč ku 5 Stra koni ce Jihoč eský Má Půjčka Je pro 60699477 Fortes Renata Čapková Příluck á 52 Zlín Zlínsk ý 44
Jednoduchý dotaz v SQL vygenerovaný v MS Access SELECT KLIENT.Kód_klienta, KLIENT.Název_klienta, KLIENT.Adresa, KLIENT.Město, KLIENT.PSČ FROM KLIENT WHERE (([KLIENT]![Kód_klienta]="26170485")); Výsledek zpracování dotazu: Rodné číslo nebo IČO Název_klienta Adresa Město PSČ 26170485 INTERINVEST Praha s.r.o. Ocelářská 3 Praha 38700
Literatura Hana Kanisová, Miroslav Muller, UML srozumitelně, Brno 2007, ISBN 80-251-1083-4 Jim Arlow, Ila Neustadt, UML2 a unifikovaný proces vývoje aplikací, Computer Press, Brno 2007, ISBN 978-80-251-1503-9