Návrh IS - UML Jaroslav Žáček
[email protected] http://www1.osu.cz/~zacek/
UML •
UML není metodikou ani programovacím jazykem, je to pouze vizuální modelovací nastroj pro objektově orientované systémy.
•
S žádnou konkrétní metodikou také není svázán. Lze jej použít se všemi existujícími.
•
Nejlépe adaptováno pro použití s UP/RUP.
•
UML nabízí vizuální syntaxi pro modelování během celého vývojového cyklu (analýza až nasazení).
•
UML je nezávislý na programovacím jazyku. Nejlepší použití je samozřejmě s OO.
Historie •
Do roku 1994 chaos ve světě objektově orientovaných metod (několik jazyků pro vizuální modelování, několik metod).
•
Metody Booch a OMT pro vizuální modelování, Objectory (Jacobson) mezi metodikami.
•
Jedním z prvních pokusů o sjednocení byla metodika Fusion (1994) - do její přípravy nebyli zapojeni tvůrci výše zmíněných metod s největším podílem na trhu (Booch, Jacobson, Rumbaugh). Neujala se.
•
Booch a Rumbaugh se spojili ve firmě Rational Corporation a začali pracovat na tvorbě jazyka UML. UML se stal otevřeným standardem.
•
1996 – OMG navrhlo UML jako standard objektově orientovaného jazyka pro vizuální modelování.
•
1997 standard OMG přijat.
•
UML přebírá to nejlepší, co doposud vzniklo a integruje to dohromady.
Architektura 4+1 2. Konceptuální chování
+1 Procesy, thready, systémy 1. Use Case model
3. Balíčky, subsystémy
4. Model nasazení
Architektura 4+1 a UML
• Statický pohled • Dynamický pohled • Funkční pohled
Modely • Základní modely používané v iterativněinkrementálním vývoji jsou:
• Use Case • Class diagram • Sequence diagram
Use Case
Use Case • Správné použití: • Identifikace funkčních domén. • Identifikace aktorů systému. • Špatné použití: • Funkční dekompozice • Design Use Cases • CRUDL
Class diagram • Statický pohled na systém - třídy a jejich relace
Sequence diagram • Dynamický pohled - vyskytuje se v analýze i v návrhu
Statechart diagram • Změny stavu systému za běhu systému
Activity diagram • Popis podnikových procesů
• Tok řídících procesů přes několik objektů
Component diagram • Fyzický pohled na softwarové komponenty a jejich vazby, vztahy, komunikaci
Deployment diagram •
Jak je softwarový systém nasazen na hardware
Řízení vývoje IS dle UML
Vývoj řízený Use Case Vision
Use-Case Model + Popis + Doplňující spec.
Realizace UC = Spolupracující entity
Analytické třídy
Návrhový model
Use Case Model
Projektový plán Project plan
Phase plan Iteration Plan (current)
Fáze a hlavní milníky Co a kdy
Iterace pro každou fázi Cíle Počet iterací Trvání
Iteration Plan (next)
Road-map - hrubý plán
Detailní plánování
Cíle iterace Software architect
System analyst Priorita (dopad, úroveň rizik) + omezení (business, zdroje) Stakeholders
Outlined Use-Cases + Supplementary
Project planning meeting
Project manager
Project Plan Scénáře + snížení rizik (cíle) pro každou iteraci
<<Use-Case pointing>> Odhadovaná pracnost
Elaboration
Elaboration - implementovány use case/scénáře za účelem snížení rizik a ohodnocení architektury.
Use Cases •
Výběr hotovosti
•
Přiřazené rysy - F1, F2, F3
•
Status: Outlined
•
Priorita: HI
•
•
Riziko: HI
•
Důležitost: HI
Plánovaná verze: v.1.0.
UC - Výběr hotovosti •
Basic Flow
Klíčový a rizikový scénář
1. Zákazník se identifikuje. 2. Systém se zeptá na obnos k vybrání. 3. Zákazník vloží částku. 4. Systém odečte peníze z účtu a vydá je. 5. Zákazník peníze odebere.
•
Alternative flows:
V průběhu iterace je UC konzultován se zákazníkem
•
Zákazník chce potvrzení o transakci.
•
Zákazník peníze neodebere - storno transakce.
Ostatní požadavky? • Systém musí být distribuovaný, proto aby mohl poskytovat bankovní služby daleko od pobočky
• Systém by měl odpovědět na výběr v 90% případů do 10 sec.
Mapa Business procesy
Customer
Needs Vision
Service
Problémová doména Oblast řešení
Features Software Requirements
Budoucí systém
UC - realizace !!!
Analýza: Primárním cílem je definovat/zachytit model problémové domény. Analýza se zaměřuje na to CO dělat. Návrh (Design) se zaměřuje na to JAK to udělat.
UCR: UC realizace popisuje, jak je daný UC realizován modelem spolupracujících objektů.
UC - Výběr hotovosti
Sequence diagram pro Basic Flow scénáře - analytické třídy
Analytické elementy <
>Třída modeluje chování specifické pro jeden nebo více UC
<<E>> Třída modeluje informace uložené systémem a přidružené chování. <> Modeluje komunikaci mezi prostředím systému a vnitřními mechanismy.
Návrh Vývoj v čase
Analytické elementy se většinou vyvinou v několik návrhových elementů (tříd/ subsystémů).
Návrh - sekvenční diagram Abstraktní úroveň -1 identify
validate
CashierInterface analytical class
Návrh - sekvenční diagram „Design contract“ mezi komponentami
Trasovatelnost Vision
Use-Case Model + Popis + Doplňující spec.
Realizace UC = Spolupracující entity
Analytické třídy
Trasovatelnost mezi modely a komponentami
Návrhový model
Testovací scénáře Vision
Use-Case Model + Popis + Doplňující spec.
Co jsou cíle? Jaké jsou omezení? Jaký je scénář?
Test Cases
Test Scripts
Test Case Data a podmínky
Use Case
Scénář
Výběr hotovosti
Basic Flow
10000
Petr S
OK
Storno operace
AF1
-5000
Petr S
OK
Obnos
Uživatel Autorizace
... ... ...
Use Case Driven: reuse popisů scénářů (jednotlivých kroků), počátečních a ukončujících podmínek, atd.
Construction
Construction – implementace zbylých Use Case + refaktoring + návrhové vzory
Construction
Iterace 1
Iterace 2
Transition
Transition – nasazení systému + uživatelské akceptační testy
