UP - fáze rozpracování (Elaboration) I J. Zendulka (s využitím obrázků a tabulek z knihy C.Larmana)
Obsah Případová studie NextGen POS Podstata fáze rozpracování Model domény Systémový diagram sekvencí Kontrakty operací
© J.Zendulka 2008
UP - fáze rozpracování I
2
Neformální specifikace (1)
© J.Zendulka 2008
UP - fáze rozpracování I
3
Neformální specifikace (2)
© J.Zendulka 2008
UP - fáze rozpracování I
4
První iterace fáze rozpracování
© J.Zendulka 2008
UP - fáze rozpracování I
5
Obsah Případová studie NextGen POS Podstata fáze rozpracování Modely domény Systémový diagram sekvencí Kontrakty operací
© J.Zendulka 2008
UP - fáze rozpracování I
6
Typické aktivity a artefakty fáze zahájení (1)
Krátký seminář k požadavkům. Pojmenování většiny aktérů, cílů a případů použití. Většina případů použití stručně popsána, 10 až 20 % detailně. Většina nejrizikovějších a nejvlivnějších nefunkčních požadavků je identifikována. Je vytvořena první verze Vize a Doplňující specifikace Vytvořen seznam rizik.
© J.Zendulka 2008
UP - fáze rozpracování I
7
Typické aktivity a artefakty fáze zahájení (2)
Byly vytvořeny potřebné prototypy pro ověření uskutečnitelnosti (např. Swing na displeji s dotykovou obrazovkou). Byly vytvořeny potřebné prototypy už. rozhraní pro objasnění funkčních požadavků. Byla učiněna rozhodnutí o nákupu, vývoji či znovupoužití komponent (např. daňový kalkulátor). Je navržena možná architektura na vysoké úrovni a základní komponenty (např. dvouvrstvá architektura klient-server, databáze Oracle). Vytvořen plán prvé iterace. Vytvořen seznam nástrojů, které se použijí.
© J.Zendulka 2008
UP - fáze rozpracování I
8
Úkoly fáze rozpracování Naprogramovat a otestovat základ a rizikové části architektury. Určit a stabilizovat většinu požadavků. Snížit či odstranit hlavní rizika. Odhadnout celkový plán a zdroje. Pozn.: UP rozumí „rizikovým“ významný z hlediska podnikatelské hodnoty. Vzniká „prototyp architektury“ (ale ne ve smyslu prototypování), také „spustitelná architektura/architektonická verze (baseline)“.
© J.Zendulka 2008
UP - fáze rozpracování I
9
Klíčové myšlenky a osvědčené praktiky
Krátké, časově ohraničené iterace. Brzké zahájení programování. Návrh, implementace a testování základních a rizikových částí architektury. Včasné, časté a realistické testování. Úpravy na základě zpětné vazby od testerů, uživatelů a vývojářů. Detailní popis většiny případů použití a dalších požadavků využitím seminářů v jednotlivých iteracích.
© J.Zendulka 2008
UP - fáze rozpracování I
10
Postupná implementace případů použití 1
2
3
...
Use Case Use Case Use Case Process Sale Process Sale Process Sale
A use case or feature is often too complex to complete in one short iteration. Therefore, different parts or scenarios must be allocated to different iterations.
Use Case Process Rentals Feature: Logging
© J.Zendulka 2008
UP - fáze rozpracování I
11
Artefakty fáze rozpracování (mimo započatých ve fázi zahájení)
© J.Zendulka 2008
UP - fáze rozpracování I
12
Obsah Případová studie NextGen POS Podstata fáze rozpracování Model domény (Domain Model) Systémový diagram sekvencí Kontrakty operací
© J.Zendulka 2008
UP - fáze rozpracování I
13
Vliv modelu domény na další artefakty Sample UP Artifact Relationships Domain Model Business Modeling
Sale
Sales LineItem
1..*
1
date ...
... ...
quantity
the domain objects, attributes, and associations that undergo state changes
conceptual classes – terms, concepts attributes, associations
elaboration of some terms in the domain model
Use-Case Model
Requirements
Process Sale
Operation: enterItem(…)
1. Customer arrives ... 2. ... 3. Cashier enters item identifier. 4....
Post-conditions: -... Operation Contracts
Cashier: … Item ID: … ... Glossary
Use Case Text
conceptual classes in the domain inspire the names of some software classes in the design
Design Model : Register
Design
: ProductCatalog
: Sale
enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) ...
© J.Zendulka 2008
UP - fáze rozpracování I
14
Podstata Ukazuje koncepty (proto také konceptuální model) dané aplikační domény, ne softwarové objekty. Je nepovinný, ale může být užitečný (má vliv na softwarové objekty vrstvy domény v modelu návrhu). Má podobu diagramu tříd. Je třeba se vyvarovat nadměrného úsilí na tvorbu dokonalého modelu domény (typické pro model vodopád). Pozn.: Je specializací Objektového modelu podniku (BOM – Business Object Model) v RUP.
© J.Zendulka 2008
UP - fáze rozpracování I
15
Vztah modelu domény a datového modelu
Různé věci (oba někdy „konceptuální“): Model
domény – ukazuje konceptuální třídy, které tvoří slovník domény. Někdy také „vizuální slovník“. Datový model – ukazuje perzistentní data, která budou někde uložena.
Motivace – pochopení pojmů domény, použití pro jména softwarových objektů vrstvy domény.
© J.Zendulka 2008
UP - fáze rozpracování I
16
Vztah modelu domény a modelu návrhu UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.
Sale
Payment
1
Pays-for
1 date time
amount inspires objects and names in
This reduces the representational gap.
Sale This is one of the big ideas in object technology.
Payment amount: Money
1
Pays-for
getBalance(): Money
1
date: Date startTime: Time getTotal(): Money ...
UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.
© J.Zendulka 2008
UP - fáze rozpracování I
17
Postup tvorby modelu domény 1.
Najdi konceptuální třídy. Strategie: a)
b) c)
2. 3.
Použij, příp. modifikuj existující modely (publikované „vzory analýzy“ „vzory datových modelů atd.). Použij seznam kategorií. Identifikuj jmenné fráze.
Zakresli je jako třídy v diagramu tříd. Přidej asociace a atributy.
© J.Zendulka 2008
UP - fáze rozpracování I
18
Použití seznamu kategorií Vytvoření seznamu kandidátních tříd na základě obecných kategorií. Př)
Kategorie obchodní transakce položka transakce kde transakce uložena …
© J.Zendulka 2008
Příklad prodej, platba položkaTransakce účetníKniha …
UP - fáze rozpracování I
19
Použití identifikace jmenných frází Slovní rozbor (lingvistická analýza). Př)
© J.Zendulka 2008
UP - fáze rozpracování I
20
Doporučení pro třídy
Prodej Používej náčrty třídy. Není nutná dokonalost, ale lze použít i nástroje pro kreslení. Výstupy (zprávy, např. Účet) zahrň, jsou-li podstatné (např. uplatnění slevy). Častá chyba – třída vs. atribut (např. Let a Cíl). Často mohou být užitečné „popisné třídy“ (popisují něco jiného, např. Položka a PopisZboží).
© J.Zendulka 2008
UP - fáze rozpracování I
21
Asociace Užitečné pro pochopení informačních požadavků řešených scénářů. Doporučení:
Znázorňujeme,
je-li třeba tuto informaci pamatovat po nějakou dobu (Prodej – PoložkaProdeje). Vyvarovat se mnoha asociací, nejde o úplnost. Hlediskem není, zda budou implementovány v SW. © J.Zendulka 2008
UP - fáze rozpracování I
22
Částečný model pro NextGen POS Records-sale-of
Ledger
Product Description
Product Catalog
Contains 1
1
1..*
1 Recordsaccountsfor
0..1 Sales LineItem
1 Used-by
Describes
*
*
Store
Item
Stocks 1
1
*
1..*
1..* Contained-in
1
Logscompleted
1
*
Sale
Houses
1..* Register
Captured-on 0..1 1
Paid-by 1 CashPayment
© J.Zendulka 2008
1
1
Is-for
1
3 Works-on
1
1
Customer
Cashier
UP - fáze rozpracování I
23
Atributy
Užitečné pro pochopení informačních požadavků řešených scénářů. Doporučení: Znázorňuj, je-li třeba pamatovat hodnotu. Může být užitečné ukázat i odvozené atributy (v UML uvozené’/’). Atributy by měly být datových typů, ne složité koncepty. Ne atributy reprezentující cizí klíče, ale asociace).
© J.Zendulka 2008
UP - fáze rozpracování I
24
Částečný model pro NextGen POS Records-sale-of
Ledger
Product Description
Product Catalog
Contains 1
1
1..*
1 1
Recordsaccountsfor
0..1 Sales LineItem
itemID description price
Used-by
Describes
*
*
Store
Item
Stocks quantity
1 1..*
Contained-in
name address 1
Logscompleted
1
1..*
Houses
Register
Captured-on 1 0..1
dateTime / total
*
1..*
*
Sale
1
id 1
1 Paid-by 1 CashPayment
1
Is-for
3 Works-on
1
1
Customer
Cashier
amountTendered
© J.Zendulka 2008
id
UP - fáze rozpracování I
25
Obsah Případová studie NextGen POS Podstata fáze rozpracování Model domény Systémový diagram sekvencí (SSD) Kontrakty operací
© J.Zendulka 2008
UP - fáze rozpracování I
26
Vliv SSD na další artefakty Sample UP Artifact Relationships Domain Model Sale
Business Modeling
Sales LineItem
1..*
1
date ...
... ...
quantity
Vision
Use-Case Model Process Sale Process Sale
use case names
Cashier
Requirements
Use Case Diagram
1. Customer arrives ... 2. Cashier makes new sale. 3. ... parameters and return value details
Use Case Text
Glossary
system events : System Operation: enterItem(…) Post-conditions: -...
: Cashier
system operations
make NewSale()
Supplementary Specification
enterItem (id, quantity) System Sequence Diagrams
Operation Contracts starting events to design for
: Register
Design
Design Model
: ProductCatalog
: Sale
enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity )
© J.Zendulka 2008
UP - fáze rozpracování I
27
NextGen POS: scénář procesu Sale system as black box the name could be "NextGenPOS" but "System" keeps it simple the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML external actor to system
Process Sale Scenario
:System
: Cashier makeNewSale a UML loop interaction frame, with a boolean guard expression
loop
[ more items ] enterItem(itemID, quantity)
description, total
endSale return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned
© J.Zendulka 2008
total with taxes
makePayment(amount)
a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism
change due, receipt
UP - fáze rozpracování I
28
Podstata Ukazuje vstupní (generované aktérem, vyžadující nějakou systémovou operaci) a výstupní události systému. Diagram sekvence v UML. Pro konkrétní scénář ukazuje aktéry, generované události a jejich pořadí. Kreslí se pro hlavní úspěšný scénář každého případu použití a časté nebo komplikované alternativy.
© J.Zendulka 2008
UP - fáze rozpracování I
29
Vztah SSD a případu použití Process Sale Scenario : Cashier
:System
makeNewSale Simple cash-only Process Sale scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. ...
loop
[ more items ] enterItem(itemID, quantity)
description, total
endSale
total with taxes
makePayment(amount)
change due, receipt
© J.Zendulka 2008
UP - fáze rozpracování I
30
Obsah Případová studie NextGen POS Podstata fáze rozpracování Model domény Systémový diagram sekvencí Kontrakty operací
© J.Zendulka 2008
UP - fáze rozpracování I
31
Vliv kontraktů operací na další artefakty Sample UP Artifact Relationships Domain Model Sale
Business Modeling
1..*
1
date ...
Sales LineItem
... ...
quantity
Vision
Use-Case Model Process Sale Process Sale
use case names
Cashier
Requirements
Use Case Diagram
1. Customer arrives ... 2. ... 3. Cashier enters item identifier. Use Case Text system events
ideas for the postconditions
the domain objects, attributes, and associations that undergo changes
Glossary
requirements that must be satisfied by the software
: System Operation: enterItem(…) Post-conditions: -...
: Cashier
system operations
Design
Supplementary Specification
enterItem (id, quantity) System Sequence Diagrams
Operation Contracts starting events to design for, and more detailed requirements that must be satisfied by the software
make NewSale()
: Register
Design Model
: ProductCatalog
: Sale
enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity )
© J.Zendulka 2008
UP - fáze rozpracování I
32
Podstata
Systémová operace – operace systému nabízená okolí. Jsou vyvolány vstupními událostmi systému (viz SSD). Kontrakt operace (Operation Contract) je popis chování systému při systémové operaci. Popisuje zejména stav objektů modelu domény po provedení dané systémové operace (následná podmínka). Lze považovat za součást modelu případu použití – zpřesňuje (použijeme jenom je-li třeba).
© J.Zendulka 2008
UP - fáze rozpracování I
33
NextGen POS: kontrakt pro enterItem
© J.Zendulka 2008
UP - fáze rozpracování I
34
Vstupní události a systémové operace Process Sale Scenario :System
: Cashier makeNewSale()
loop
[ more items ] enterItem(itemID, quantity)
these input system events invoke system operations
description, total
the system event enterItem invokes a system operation called enterItem and so forth
endSale()
this is the same as in objectoriented programming when we say the message foo invokes the method (handling operation) foo
total with taxes
makePayment(amount)
change due, receipt
© J.Zendulka 2008
UP - fáze rozpracování I
35
Literatura
Larman, C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall, 2005, pp. 123 - 194.
© J.Zendulka 2008
UP - fáze rozpracování I
36
