Jiří Mašek BIVŠ V Pra r ha

Transkript

1 Jiří Mašek BIVŠ Praha 2008

2 Procesvývoje IS

3 Unifiedprocess(UP)

4 Iterace vývoje

5 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ů

6 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

7 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

8 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)

9 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í

10 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.

11 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

12 Procesní modelování Procesní hierarchie rozpad procesů Modely podnikových procesů - detailní popis

13 Procesní hierarchie Proces zpodrobně n v tomto diagramu Listový proces Proces zpodrobně n v jiném diagramu

14 Procesní hierarchie -pokračování Proces zpodrobňující jiný diagramu

15 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)

16 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

17 Diagram případu užití

18 Aktéři případů užití

19 Model tříd (ClassModel) Třída Atribut Vazba Operace

20 Datové modelování Logický model (entity) Fyzický model (tabulky) Realizace fyzického modelu (DDL skripty)

21 Termíny Logický Entita Atribut UID Vazba Fyzický Tabulka Sloupec PK Cizí klíč Constraint

22 Tvorba datového modelu Identifikace datových entit (třídy) Definice vazeb Definice atributů Kardinality vazeb Normalizace Dekompozice vazeb M:N Vlastnosti Atributů

23 Normalizace databáze K čemu slouží Jaké jsou normy 0NF 5NF Příklad normalizace Důvody denormalizace složitost dotazů, rychlost vyhodnocení

24 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.

25 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é).

26 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í).

27 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.

28 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.

29 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).

30 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.

31 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ř , /435, Jan Novák, M, OP4, 03789/03, apod.)

32 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

33 Kardinalita vazeb 1 : 1 1 : * (= 0..*) 1 : : 1..* 1 : 1:3

34 Příkldaddatového modelování Zjednodušený systém pro evidenci půjček

35 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.

36 Identifikace datových entit Čerpání Způsob ovl. Historie kurzu Půjčka Účet Země Klient Měna

37 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

38 Zjednodušený datový model Půjčka

39 Dekompozice vazby M : N M : N 1 : M, N : 1

40 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

41 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.

42 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

43 Ukázka DM v MS Access

44 Část datového modelu Půjčka C_uctu Kod_klienta C_pobocky Druh_účtu Kod_oboru Kod_vysledovky Zustatek_na_uctu Běžný Běžný 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á INTERINVEST Praha s.r.o. Josef Balda Ocelář ská 3 Prah a Střed očesk ý Je pro Má Josef Novák Josef Novák Na palouč ku 5 Stra koni ce Jihoč eský Má Půjčka Je pro Fortes Renata Čapková Příluck á 52 Zlín Zlínsk ý 44

45 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]=" ")); Výsledek zpracování dotazu: Rodné číslo nebo IČO Název_klienta Adresa Město PSČ INTERINVEST Praha s.r.o. Ocelářská 3 Praha 38700

46 Literatura Hana Kanisová, Miroslav Muller, UML srozumitelně, Brno 2007, ISBN Jim Arlow, Ila Neustadt, UML2 a unifikovaný proces vývoje aplikací, Computer Press, Brno 2007, ISBN