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í UP - fáze rozpracování I 2
Neformální specifikace () UP - fáze rozpracování I 3
Neformální specifikace (2) UP - fáze rozpracování I 4
První iterace fáze rozpracování 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í UP - fáze rozpracování I 6
Typické aktivity a artefakty fáze zahájení () 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, 0 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. 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í. 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). 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. UP - fáze rozpracování I 0
Postupná implementace případů použití 2 3... A use case or feature is often too complex to complete in one short iteration. Use Case Process Sale Use Case Process Sale Use Case Process Sale Therefore, different parts or scenarios must be allocated to different iterations. Feature: Logging Use Case Process Rentals UP - fáze rozpracování I
Artefakty fáze rozpracování (mimo započatých ve fázi zahájení) UP - fáze rozpracování I 2
Obsah Případová studie NextGen POS Podstata fáze rozpracování Model domény (Domain Model) Systémový diagram sekvencí Kontrakty operací UP - fáze rozpracování I 3
Vliv modelu domény na další artefakty Sample UP Artifact Relationships Domain Model Business Modeling date... Sale..* Sales... LineItem... quantity Requirements Process Sale conceptual classes terms, concepts attributes, associations. Customer arrives... 2.... 3. Cashier enters item identifier. 4... Use Case Text Use-Case Model Operation: enteritem( ) Post-conditions: -... Operation Contracts the domain objects, attributes, and associations that undergo state changes Cashier: Item ID:... elaboration of some terms in the domain model Glossary conceptual classes in the domain inspire the names of some software classes in the design Design Model : Register : ProductCatalog : Sale Design enteritem (itemid, quantity) spec = getproductspec( itemid ) addlineitem( spec, quantity )... UP - fáze rozpracování I 4
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. UP - fáze rozpracování I 5
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. UP - fáze rozpracování I 6
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. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount Payment amount: Money Pays-for inspires objects and names in Pays-for date time Sale Sale date: Date starttime: Time getbalance(): Money 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. UP - fáze rozpracování I 7
Postup tvorby modelu domény. Najdi konceptuální třídy. Strategie: a) Použij, příp. modifikuj existující modely (publikované vzory analýzy vzory datových modelů atd.). b) Použij seznam kategorií. c) Identifikuj jmenné fráze. 2. Zakresli je jako třídy v diagramu tříd. 3. Přidej asociace a atributy. UP - fáze rozpracování I 8
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 Příklad prodej, platba položkatransakce účetníkniha UP - fáze rozpracování I 9
Použití identifikace jmenných frází Slovní rozbor (lingvistická analýza). Př) UP - fáze rozpracování I 20
Používej náčrty třídy. Doporučení pro třídy Prodej 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ží). UP - fáze rozpracování I 2
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. UP - fáze rozpracování I 22
Částečný model pro NextGen POS Records-sale-of 0.. Contained-in Sales LineItem Sale..* * Ledger Logscompleted Recordsaccountsfor Product Catalog Store Register Used-by * Houses..* Contains..* Stocks * Product Description * Item Describes..* Captured-on 0.. Paid-by Is-for 3 Works-on CashPayment 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). UP - fáze rozpracování I 24
Částečný model pro NextGen POS Records-sale-of 0.. Sales LineItem quantity Contained-in Paid-by Sale datetime / total..* * Ledger Captured-on 0.. Is-for Logscompleted Recordsaccountsfor id Product Catalog Store name address Register Used-by * Houses..* Contains..* Stocks 3 Works-on * Product Description itemid description price * Item Describes..* CashPayment Customer Cashier amounttendered 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í UP - fáze rozpracování I 26
Vliv SSD na další artefakty Sample UP Artifact Relationships Domain Model Business Modeling date... Sale..* Sales... LineItem... quantity Use-Case Model Vision Process Sale Requirements Cashier Process Sale Use Case Diagram use case names. Customer arrives... 2. Cashier makes new sale. 3.... Use Case Text system events parameters and return value details Glossary : System Operation: enteritem( ) Post-conditions: -... system operations : Cashier make NewSale() enteritem (id, quantity) Supplementary Specification Operation Contracts System Sequence Diagrams starting events to design for : Register Design Model : ProductCatalog : Sale Design enteritem (itemid, quantity) spec = getproductspec( itemid ) addlineitem( spec, quantity ) 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 : Cashier :System makenewsale a UML loop interaction frame, with a boolean guard expression loop [ more items ] enteritem(itemid, quantity) description, total return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned endsale total with taxes makepayment(amount) change due, receipt a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism 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. UP - fáze rozpracování I 29
Vztah SSD a případu použití Process Sale Scenario : Cashier :System Simple cash-only Process Sale scenario: makenewsale. 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 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í UP - fáze rozpracování I 3
Vliv kontraktů operací na další artefakty Sample UP Artifact Relationships Domain Model Business Modeling date... Sale..* Sales... LineItem... quantity Use-Case Model Vision Process Sale the domain objects, attributes, and associations that undergo changes Requirements Cashier Process Sale Use Case Diagram Operation: enteritem( ) Post-conditions: -... ideas for the postconditions use case names system operations : Cashier. Customer arrives... 2.... 3. Cashier enters item identifier. Use Case Text system events make NewSale() enteritem (id, quantity) : System requirements that must be satisfied by the software Glossary Supplementary Specification starting events to design for, and more detailed requirements that must be satisfied by the software Design Operation Contracts enteritem (itemid, quantity) : Register System Sequence Diagrams Design Model spec = getproductspec( itemid ) addlineitem( spec, quantity ) : ProductCatalog : Sale 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). UP - fáze rozpracování I 33
NextGen POS: kontrakt pro enteritem UP - fáze rozpracování I 34
Vstupní události a systémové operace : Cashier Process Sale Scenario makenewsale() :System 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() total with taxes this is the same as in objectoriented programming when we say the message foo invokes the method (handling operation) foo makepayment(amount) change due, receipt 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. 23-94. UP - fáze rozpracování I 36