UML a jeho použití v procesu vývoje Jaroslav Žáček
[email protected]
Různé pohledy na modelování
Různé pohledy na modelování
Unified Modeling Language • 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 slouží pro modelování čehokoliv, podporuje různé aplikační domény (od real-time systémů až po expertní systémy). • UML je nezávislý na programovacím jazyku. Nejlepší použití je samozřejmě s OO jazyky jako je Smalltalk, Java nebo C#. Vhodný ale i pro hybridní jazyky (C++ nebo Visual Basic).
Historie •
V roce 1994 vyvstal problém - máme několik OO metod a k většině existuje vizuální reprezentace
•
Metody Booch a OMT pro vizuální modelování, metodika Objectory (Jacobson)
•
První pokus o sjednocení - metodika Fusion (1994) - nebyly do ní zapojeny nejrozšířenější metodiky na trhu->neujala se.
•
Booch a Rumbaugh se spojili v Rational Corp. a začali tvořit jazyk UML. Ten 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 je souhrn toho nejlepšího, co tehdy bylo dostupné, integruje vše do jednoho standardu.
Architektura 4+1 Statický Dynamický Funkční -> Use Case
Standard UML • UML 2.0 Superstructure - popisuje UML pro uživatele (diagramy) • UML 2.0 Infrastructure - metamodel definující modely UML (popsán pomocí MOF) • UML 2.0 Object Constraint Language - jazyk specifikující vstupní a výstupní podmínky • UML 2.0 Diagram Interchange - XML struktura pro výměnu modelů mezi CASE nástroji
Dostupné modely UML 2.0:
UML 1.x: •
Use Case diagram
•
Class diagram
•
Class diagram
•
Component diagram
•
Object diagram
•
Composite structure diagram
•
Sequence diagram
•
Deployment diagram
•
Statechart
•
Object diagram
•
Activity diagram
•
Package diagram
•
Component diagram
•
Activity diagram
•
Deployment diagram
•
State Machine diagram
•
Use case diagram
•
Communication diagram
•
Interaction overview diagram
•
Sequence diagram
•
Timing Diagram
Modely při vývoji SW
• Use Case • Class diagram • Sequence diagram
Struktura UML
Use Case • Hranice systému • Aktoři • Use Cases (identifikované společně a aktory) • Relace, vazby Nejčastější chyby ?
Use Case - vazby
Class diagram
Statický pohled: •
Objekty, třídy, atributy, datové typy, omezení, ...
•
Jejich relace (uses, gen/spec, agregace)
Class diagram
Sequence diagram
Dynamický pohled: • Popisuje chování jak v analýze, tak v návrhu.
Sequence diagram Analýza
Statechart diagram
• Změny stavu systému (stavy tříd) v průběhu existence/ běhu systému
Activity diagram
• Popis business 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 systém fyzicky nasazen na hardware, prostředí
DD - univerzitní IS
UML v procesu vývoje
Vývoj řízený UC (UC Driven)
Vision
Use-Case Model + Popis + Doplňující spec.
Realizace UC = Spolupracující entity
Analytické třídy
Návrhový model
Vše v jedné iteraci
Use Case model
Dvě úrovně plánování Project plan
Iterační Plán (současný)
Fáze a hlavní milníky Co a kdy
Road-map (nezapomínat na milníky) Iterační Plán (příští)
Jemný, detailní plá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
UC realizace
UC realizace - detail
UC realizace popisuje, jak je daný UC realizován modelem spolupracujících objektů.
UC realizace - detail
Návrh
Vývoj v čase
Analytické elementy se většinou vyvinou v několik návrhových elementů (třída či subsystém)
Návrh - sekvenční diagram „Design contract“ mezi komponentami
Vývoj řízený UC
Vision
Use-Case Model + Popis + Doplňující spec.
Realizace UC = Spolupracující entity
Analytické třídy
Trasovatelnost (Tracebility) mezi modely a komponentami
Návrhový model
Testy jsou také UC driven
Vision
CO jsou cíle/ omezení/ Scénáře?
Use-Case Model + Popis + Doplňující spec.
Test Cases
Test Scripts
Test Cases Data a podmínky Use Case
Scénář Hodiny
Uživatel
Výstup
Reportuj čas
BF
5
user
OK
Reportuj čas
AF#1
4
user
Chybové hlášení
...
...
...
...
...
Use Case Driven: znovupoužití (reuse) popisů scénářů (jednotlivých kroků), počátečních a ukončujících podmínek, atd.
Construction
Implementace zbylých Use Case + refaktoring + návrhové vzory
Construction
Iterace 1
Iterace 2
Rezervace Management
UML a podpora nasazení
SW komponenta
Diagram komponent
UML a podpora nasazení HW uzel Komunikační kanál
Diagram nasazení
Shrnutí potřebnosti UML pro vývoj V zásadě platí, že pokud chceme omezit modelování na minimum, měly by nás zajímat alespoň následující modely: • Use case model (+ scénáře) – na specifikaci požadavků a pochopení potřeb bychom moc šetřit neměli, jelikož se jedná o nejzásadnější část procesu tvorby software, vše ostatní vychází ze správného pochopení potřeb. • Diagram tříd – reprezentuje statickou strukturu, statický pohled na systém/komponentu. • Sekvenční diagram – reprezentuje chování systému či komponenty a tudíž zachycuje dynamickou stránku systému.
Spustitelné modely? Executable UML (exUML, xUML) • Je přímo zaměřen na tvorbu spustitelných modelů . • Nepředepisuje žádnou konkrétní syntax. • Pro každý vytvořený model je potřeba definovat akce umožňující spuštění modelu. • Zatím neexistuje žádná smysluplná praktická implementace obecného spustitelného modelu.
Kritika UML • Příliš obsáhlý jazyk - široký a složitý, redundantní, nepoužívané konstruktory (hlavně v UML 2.0). • Snaha uspokojit všechny potřeby (golden hammer) obecný modelovací jazyk pro implementační i doménovou oblast. • Snaha UML 2.0 Action semantics být tzv. Turing complete pro automatické generování (hlavně MDA architektura). • Některé modely nejsou z jejich povahy syntakticky kompletní.
