1. Introduction 2. OO Concepts 3. The Unified Modeling Language 4. Object Persistence 5. From Analysis to Design 6. The Unified Process Inception Elaboration and Design Patterns 7. Object Constraint Language (OCL) Appendix : Forward Engineering Exercises & Case Studies Elaboration: Iteration 1 - Basics - Applying UML and Patterns P ART III Use case implementation may be spread across iterations. Part of the requirement of Process Sale is implemented in the first iteration. 1 Use Case Process Sale 2 3 . . . Use Case Process Sale Use Case Process Sale Use Case Process Rentals 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. However, short and simple use cases may be completed within a single iteration. We Don’t Implement All the Requirements at Once • The requirements for iteration-1 are subsets of the complete requirements. For example, the NextGen POS iteration-1requirements are a simplified version of the complete Process Sale use case; they describe one “simple cash-only scenario”. • Note that we haven’t done all the requirements analysis for the NextGen POS system. We’ve only analyzed the Process Sale use case in detail; many other use cases are not yet analyzed. • Also note that, in contrast to a waterfall process, we start production-quality programming and testing for a subset of requirements, and we start that development before the requirements analysis is complete. In the first iteration of the NextGen POS, our plan is: Implement a basic, key scenario of the Process Sale use case: Entering items and receiving a cash payment. Nothing fancy or complex is handled, just a simple “happy path” scenario, and the design and implementation to support it. There is no collaboration with external services, such as a tax calculator or product database. No complex pricing rules are applied. “A simple cash-only scenario” 1 st Iteration of Elaboration On to Elaboration Elaboration is the initial series of iterations during which: the core, risky software architecture is programmed and tested the majority of requirements are discovered and stabilized the major risks are mitigated or retired • Elaboration is the initial series of iterations during which the team does serious investigation, implements (programs and tests) the core architecture, clarifies most requirements, and tackles high-risk issues. • In the UP, “risk” includes business value. Therefore, early work may include implementing scenarios that are deemed important (but perhaps are not technically risky). • Elaboration often consists of two or more iterations; each iteration is recommended to be between two and six weeks. • During this phase, one is not creating throw-away prototypes; rather, the code and design are production- quality portions of the final system. Such a production subset of the system is commonly called the executable architecture or architectural baseline On to Elaboration ... “Elaboration” in one sentence: Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources. Some key ideas and best practices will manifest in elaboration: do short timeboxed risk-driven iterations start programming early adaptively design, implement, and test the core and risky parts of the architecture test early, often, realistically adapted based on feedback from tests, users, developers write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration s – start; r - refine Discipline Artifact Incept. Elab. Const. Trans. I1 E1..En C1..Cn T1..Tn Business Modeling Domain Model Requirements Use-Case Model Vision Supplementary Specification Glossary Design Design Model SW Architecture Document s s r s r s r s r s r s Iteration As suggested by this table, the UP Domain Model is usally both started and completed in the elaboration phase. Sample UP Artifacts and Timing Domain Model A domain model is the most important—and classic—model in OO analysis. It illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be an input to several artifacts explored in the case study. The quintessential object-oriented analysis step is the composition of a domain Into noteworthy concepts or objects. A domain model is a visual representation of real-situation conceptual classes not of software objects . The term does not mean a set of diagrams describing software classes (such as Java or C# classes), the domain layer of a software architecture, or software objects with responsibilities. Domain models have also been called conceptual models , domain object models , and analysis object models ... It illustrates noteworthy concepts in a domain. Explanation Process Sale 1. Customer arrives ... 2. ... 3. Cashier enters item identifier 4.... Use Case Text Operation: enterItem(...) Post-conditions: - . . . Operation Contracts Sale date . . . Sales LineItem quantity 1.. * 1 . . . . . . the domain objects , attributes, and associations that undergo state changes Domain Model Use-Case Model Design Model : Register enterItem (itemID, quantity) : ProductCatalog spec = getProductSpec ( itemID ) addLineItem( spec, quantity ) : Sale . . . conceptual classes in the domain inspire the names of some software classes in the design conceptual classes– terms, concepts attributes, associations Cashier: ... Item ID: ... ... Glossary elaboration of some terms in the domain model Requirements Business Modeling Design Sample UP Artifact Influence Sale date time concept's symbol "A sale represents the event of a purchase transaction. It has a date and time." concept's intension sale-1 sale-3 sale-2 sale-4 concept's extension A conceptual class has a symbol, intension, and extension. A conceptual class may be considered in terms of its symbol, intension, and extension. Symbols : words or images representing a conceptual class. Intension : the definition of a conceptual class. Extension: the set of examples to which the conceptual class applies; in other words, the set of all instances of the conceptual class. A domain model does not show software artifacts or classes. However it inspires creation of software classes. Payment amount Sale date time Pays-for Payment amount: Money getBalance(): Money Sale date: Date startTime: Time getTotal(): Money . . . Pays-for UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. 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. 1 1 1 1 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. inspires objects and names in An Example: A Point-Of-Sale System Store Register Sale Item Cash Payment Sales LineItem Cashier Customer Product Catalog Product Description Ledger NextGen POS System Initial Domain Model Ledger—a book in which a business, bank etc records how much money it receives and spends Register Item Store Sale CashPayment Sales LineItem Cashier Customer Product Catalog Product Description Stocks * Houses 1.. * Used-by * Contains 1.. * Describes * Captured-on Contained-in 1.. * Records-sale-of 0..1 Paid-by Is-for Logs- completed * Works-on 1 1 1 1 1..* 1 1 1 1 1 1 1 0..1 1 1 Ledger Records- accounts- for 1 1 NextGen POS System Partial Domain Model Associations Added Register id Item Store name address Sale dateTime / total CashPayment amountTendered Sales LineItem quantity Cashier id Customer Product Catalog Product Description itemID description price Stocks * Houses 1.. * Used-by * Contains 1.. * Describes * Captured-on Contained-in 1.. * Records-sale-of 0..1 Paid-by Is-for Logs- completed * Works-on 1 1 1 1 1..* 1 1 1 1 1 1 1 0..1 1 1 Ledger Records- accounts- for 1 1 NextGen POS System Partial Domain Model Attributes Added System Sequence Diagrams (SSD) • Use cases describe how external actors interact with the software system we are developing. During this interaction an actor generates “ system events” to a system, usually requesting some “ system operation ” to handle the event For example, when a cahier enters an item’s ID, the cashier is requesting the POS system to record that item’s sale. That event initiates an operation upon the system. • An SSD is a fast and easily created artifact that illustrates input and output events related to the systems under discussion. They are input to operation contracts and—most importantly—object design (they serve as a starting point for designing collaborating objects). • A system sequence diagram (SSD) is a picture that show, for one particular scenario of a use case , the events that external actors generate, their order, and inter-system events. Before proceeding to a detailed design of how software application will work, it is useful to investigate and define its behavior as a “black block”. System behavior is a description of what a system does , without explaining how it does it. One part of that description is an SSD. (Other parts include the use cases and system operation contracts.) • Guideline : Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios. Sample UP Artifact Influence Operation: enterItem(...) Post-conditions: - . . . Operation Contracts Sale date . . . Sales LineItem quantity 1.. * 1 . . . . . . Domain Model Use-Case Model Design Model : Register enterItem (itemID, quantity) : ProductCatalog spec = getProductSpec( itemID ) addLineItem( spec, quantity ) : Sale Require- ments Business Modeling Design Sample UP Artifact Relationships : System enterItem (id, quantity) Use Case Text System Sequence Diagrams make NewSale() system events Cashier Process Sale : Cashier use case names system operations Use Case Diagram Vision Supplementary Specification Glossary parameters and return value details starting events to design for Process Sale 1. Customer arrives ... 2. Cashier makes new sale. 3. ... Business Modeling Business Modeling Requirements Requirements Design Design 1 1 2 2 3 4 NextGen POS System SSD for a Process Sale Scenario enterItem(itemID, quantity) :System : Cashier endSale makePayment(amount) a UML loop interaction frame , with a boolean guard expression external actor to system Process Sale Scenario 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 a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism 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 total with taxes change due, receipt makeNewSale [ more items ] loop NextGen POS System An SSD shows system events for one scenario of a use case ; therefore, it is generated from inspection of a use case. The Relationship Between SSDs and Use Cases 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 : Cashier :System enterItem (itemID, quantity) endSale makePayment (amount) description , total total with taxes change due , receipt makeNewSale [ more items ] Process Sale Scenario An “ operation contract ” reduces the possibility of misunderstanding by making clear what a “system operation” should do. Operation Contracts • Use cases or system features are the main ways in the UP to describe system behavior, and are usually sufficient. • Sometimes a more detailed or precise description of system behavior has value. Operation contracts use a pre- and post-condition form to “ describe detailed change to objects in a domain model, as the result of a system operation ”. • Operation contracts may be considered part of the UP Use-Case Model because they provide more analysis detail on the effect of the system operations implied in the use cases. The prime inputs to the contracts are the system operations identified in SSDs (such as enterItem ), the domain model, and domain insight from experts. The contracts can in turn serve as input to the object design, as they describe changes that are likely required in the software objects or database.