Sept 200491.3913 Ron McFadyen1 Extend Relationship.

Slides:



Advertisements
Similar presentations
Design by Contract.
Advertisements

Object Design Examples with GRASP
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
Jan 15, Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Iteration: a simple cash-only success scenario of Process Sale.
Jan 23, Ron McFadyen1 SSD for a samplePOS Use Case Figure 13.1 Input Events invoke a system operation of the same name same idea as in object-oriented.
January Ron McFadyen1 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) enclosed in a box.
Sequence Diagram Objects are represented horizontally across the top of the diagram Each object has a lifeline some exist before and/or after some are.
Jan 16, Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Iteration 1: a simple cash-only success scenario of Process Sale.
Jan Ron McFadyen1 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) enclosed in a box Actors.
Jan Ron McFadyen1 Consider a simple cash-only Process Sale scenario 1. Customer arrives at a POS checkout with goods and/or services to purchase.
Object-Oriented Analysis and Design
Drawing System Sequence Diagrams
Systems Analysis and Design in a Changing World, Fourth Edition
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
January Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of.
Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” - may be of.
Fall 2009ACS-3913 Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
NJIT Use Case Model Operation Contracts Prepared By: Sumit Sharma.
ACS-3913Fall 2009 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3.
NJIT Drawing System Sequence Diagrams Chapter 10 Applying UML and Patterns Craig Larman Presented by Anuradha Dharani.
Object-Oriented Analysis and Design
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
Use Case Model Operation Contracts Prepared By: Sumit Sharma and Sravanthi Gillala.
חוזים – Contracts 1. Larman – Chapter 10 – SSDs 10.2 What are System Sequence Diagrams? (introduction) Use cases describe how external actors interact.
9/18/011 Software Requirements Analysis and Design (Continued)
LECTURE 5 SEQUENCE DIAGRAM 1. INTRODUCTION – SYSTEM SEQUENCE DIAGRAM A system sequence diagram is a fast and easily created artifact that illustrates.
TK2023 Object-Oriented Software Engineering CHAPTER 6 SYSTEM SEQUENCE DIAGRAMS.
Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative Development Part III Elaboration Iteration I – Basic1.
SENG 403 SENG 403 – Winter  Brief introduction to SSD  Example (A sales systems (Cashier))  Example (Monopoly game) SENG 403 – Winter 2012.
INFO 620Lecture #51 Information Systems Analysis and Design Sequence and Collaboration Diagrams INFO 620 Glenn Booker.
Chapter 18 Object Design Examples with GRASP. Objectives Design use case realizations –A use-case realization describes how a particular use case is realized.
Object Oriented Analysis and Design System Events & Contracts.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Object Design Examples with GRASP (Ch. 18)
Sept Ron McFadyen1 Section 10.1 Domain Models Domain Model: a visual representation of conceptual classes or real-world objects in a domain.
Use Case Model Operation Contracts Chapter 11 Applying UML and Patterns Craig Larman.
Review ♦ System sequence diagram ♦ Domain model
1 Lecture 6: Operation Contracts. 2 Overview  What is contract ?  The guidelines for writing contracts for the system operations.  Use Case realizations.
Operation Contracts: Getting ready to open the “System” black box All material from Applying UML and Patterns, 3 rd Edition, Craig Larman, chapter 11.
Chapter 9 Applying UML and Patterns -Craig Larman
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
Larman ch. 131 Use-Case Model : Adding Detail with operation contracts Larman ch. 13.
Drawing System Sequence Diagrams
COMP-350 Object-Oriented Analysis and Design Drawing System Sequence Diagrams Reference: Larman, Chapter 9.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
System sequence diagrams
TK2023 Object-Oriented Software Engineering CHAPTER 12 Introduction to Responsibility-Driven Design.
Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” Used to capture and describe.
Domain Model A representation of real-world conceptual classes in a problem domain. The core of object-oriented analysis They are NOT software objects.
OO Methodology Elaboration Phase Iteration 1- Part 3.
1 Chapter 9: Operation Contracts Chapter 13 in Applying UML and Patterns Book.
Software Engineering 1 Object-oriented Analysis and Design Chap 31 More SSDs and Contracts.
Use-Case Model: Adding Detail with Operation Contracts.
SYSTEM-LEVEL SEQUENCE DIAGRAMS Sys466. System-Level Sequence Diagrams  Use cases describe how external actors interact with the software system…  An.
1 Object Oriented Analysis and Design System Events & Contracts.
Sept Ron McFadyen1 Include Relationship UC1:Process Sale … Main Success Scenario … 7. Customer pays and System handles payment. … Extensions.
Jan Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
Object Design Examples with GRASP
Elaboration popo.
Systems Analysis and Design in a Changing World, Fourth Edition
System Sequence Diagrams and Operation Contracts
Used to help understand requirements more completely
System sequence diagrams
Webapp Design with System Sequence Diagrams
Sequence Diagrams Lecture 6.
System Sequence Diagrams(SSD)
Operation Contracts Ch. 11.
Presentation transcript:

Sept Ron McFadyen1 Extend Relationship

Sept Ron McFadyen2 Extend Relationship The extend relationship is typically used for optional behaviour Extend is used to separate optional from mandatory behaviour; extend is used to distinguish variants in behaviour Under a specified condition the base use case is extended with the behaviour specified in the addition use case. We say the addition use case is dependent on the base use case (note the directed line in the drawing)

Sept Ron McFadyen3 Extend Relationship Process Sale collects the payment from the customer. Suppose payment via a gift certificate is considered an exceptional case. See Figure 25.3 > Handle Gift Certificate Payment Cashier Payment, if the Customer presents a gift certificate Process Sale Extension Points: Payment

Sept Ron McFadyen4 Extend Relationship Process Sale declares/states “Payment” is an extension point, but Process Sale does not know anything else: the condition, the name of the other addition use case. (see page 389) > Handle Gift Certificate Payment Cashier Payment, if the Customer presents a gift certificate Process Sale Extension Points: Payment

Sept Ron McFadyen5 System Sequence Diagrams

Sept Ron McFadyen6 Use-case model: System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of Process Sale beginning a wide-and-shallow design and implementation touches on many major architectural elements begins with a expansion of the Use Case Model with a System Sequence Diagram to clarify the input and output system events

Sept Ron McFadyen7 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...

Sept Ron McFadyen8 System Sequence Diagram a picture showing actors and systems, lifelines, messages, time for a particular scenario for SSDs we will be ignoring an “activation box” that is normally placed on a lifeline :Cashier :System an arbitrary cashier a cashier object the software system to be developed We’ll see it as a black box

Sept Ron McFadyen9 Sequence Diagram object-oriented systems perform tasks by interacting with each other through the passing of messages a sequence diagram is an interaction diagram that emphasizes the messaging sequence A sequence diagram illustrates the dynamic behaviour of a system of objects The arrow we utilize ( ) is for procedural or synchronous messages – where the sender sends a message, transfers control to the receiving object, and waits for a response To indicate a return message and the explicit return of control, we use Ch 15 discusses interaction diagrams more fully

Sept Ron McFadyen10 System Sequence Diagram :Cashier :System Message at Time1 from :Cashier to :System Response at Time2 from :System to :Cashier Earlier events are above later events in the diagram time travels downward Time1 earlier than Time2: Time1 < Time2 message response

Sept Ron McFadyen11 Figure 9.1

Sept Ron McFadyen12 Figure 9.3 There are 4 system events shown here. The cashier will interact with the system in 4 ways. The events are given operation names: makeNewSale, enterItem, endSale, makePayment.

Sept Ron McFadyen13 Contracts

Sept Ron McFadyen14 Contracts Used to help understand requirements more completely based on assertions; assertions are applicable to any element of the UML text discusses contracts for system operations; contracts are applicable to execution of any software component

Sept Ron McFadyen15 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3 Relationship between Contracts and other artifacts

Sept Ron McFadyen16 Contracts A contract is a technique for describing system operations in terms of state changes to objects in a Domain Model Contracts in Chapter 13, are based on work by Bertrand Meyer … Eiffel programming language Based on concept of assertion a statement, a constraint or declaration, that must be true a false value indicates a bug may be expressed informally, or in the UML we can (optionally) use the Object Constraint Language (OCL; 1999) to specify constraints rigorously

Sept Ron McFadyen17 Constraints Three types pre-condition: must be true before a part of the system executes post-condition: must be true after a part of the system executes invariant: must be true before and after any part of the system is executed. Constraints can be enclosed in braces and placed in a note on a diagram appear as guards on a diagram kept in a separate file managed by a CASE tool

Sept Ron McFadyen18 Consider the execution of a routine: The called routine provides a service - it is the supplier The caller is the client requesting the service. A contract will spells out precisely the obligations of the caller (client) and the callee (supplier). The contract serves as an interface specification for the routine. Example: consider a routine that merges two sorted sequences. The merge routine is the supplier of the service; the calling routine is the caller. A contract will spell out the responsibilities of each party. Contracts

Sept Ron McFadyen19 Responsibilities: Client: Ensure that the both sequences to be merged are each already sorted Supplier: Efficiently merge the two sorted sequences into one sorted sequence Contracts

Sept Ron McFadyen20 Software contract: The responsibilities of the client will be called pre- conditions The responsibilities of the supplier will be called post- conditions Pre-condition: both sequences to be merged are each already sorted Post-condition: the two sorted sequences are merged into one sorted sequence Contracts

Sept Ron McFadyen21 During analysis developers must first understand the problem domain and identify domain objects, their relationships with other domain objects, and their constraints. If a contract is defined in terms of domain objects the constraints can be clear and explicit, easily understood Everyone understands the business contracting metaphor. Business rules (constraints) can become an integral part of the software from the very beginning. Example: consider a withdraw method for an ACCOUNT class:withdraw (amount_to_withdraw: MONEY) Contracts

Sept Ron McFadyen22 Example: consider a withdraw method for an ACCOUNT class: withdraw (amount_to_withdraw: MONEY) Pre-conditions: positive_amount: amount_to_withdraw > 0 sufficient_balance: balance >= amount_to_withdraw Post-conditions: correct_balance: balance = initial balance - amount_to_withdraw Contracts

Sept Ron McFadyen23 Contracts Contract Components (Larman) Operation - name and parameters Cross References - where operation used Preconditions - assumptions about the state of the system or Domain Model objects Postconditions - state of objects after the operation completes objects:any new ones? any attributes modified? associations: any new or modified associations? Larman’s version is very informal

Sept Ron McFadyen24 SSD for a samplePOS Use Case Figure 13.1 Input Events invoke a system operation of the same name same idea as in object-oriented programming when we say a message foo invokes the method foo Referred to as the enterItem system operation

Sept Ron McFadyen25 SalesLineItem quantity Product Specification itemID Sale 1 1..* * 1Described by Contained in The part of the Domain Model relevant to enterItem( )

Sept Ron McFadyen26 Contracts Example Operation:enterItem (itemID : ItemID, quantity : integer) Preconditions there is a Sale underway Postconditions a SalesLineItem instance was created an association between the sale and the sales line item was created an attribute, quantity, was modified an association between the product specification and the sales line item was created

Sept Ron McFadyen27 Design By Contract (DBC) provides the basis for documenting software interfaces Reusers of a software component need to understand what the software provides them and what they must do to obtain these benefits. This is the contract. DBC is perhaps a best non-practice. Example of a new DBC tool: iContract: Design by Contract in Java allows one to include runtime assertions for development purposes and suppress them for production cooltools.html DBC (aside)