1 Lecture 6: Operation Contracts. 2 Overview  What is contract ?  The guidelines for writing contracts for the system operations.  Use Case realizations.

Slides:



Advertisements
Similar presentations
Object Design Examples with GRASP
Advertisements

Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
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.
March Ron McFadyen1 Ch 17: Use Case Realizations with GRASP Patterns Assigning responsibilities to objects to achieve user goals Section 17.4.
Oct Ron McFadyen1 Ch 17: Use Case Realizations with GRASP Patterns P. 248: “The assignment of responsibilities and design of collaborations.
Object-Oriented Analysis and Design
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
NJIT Object Design Examples with GRASP Chapter 18 Applying UML and Patterns Craig Larman Presented By : Ajay Alegonda.
NJIT Use Case Model Operation Contracts Prepared By: Sumit Sharma.
6/8/991 Analysis Tuesday 09/14/99 Revised: September 11, 2000 (APM)
ACS-3913Fall 2009 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
Feb Ron McFadyen1 Use Case Realizations with GRASP Patterns “The assignment of responsibilities and design of collaborations are very important.
September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3.
Object-Oriented Analysis and Design
Sept Ron McFadyen1 Extend Relationship.
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)
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.
CSSE 374: More GRASP’ing and Use Case Realization Steve Chenoweth Office: Moench Room F220 Phone: (812) These.
CSSE 374: Operations Contracts and Logical Architectures Steve Chenoweth Office: Moench Room F220 Phone: (812)
Chapter 18 Object Design Examples with GRASP. Objectives Design use case realizations –A use-case realization describes how a particular use case is realized.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
1 Ch 18. Object Design Examples With Grasp Objectives Design use case realizations. Apply GRASP to assign responsibilities to classes. Apply UML to illustrate.
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.
GRASP: Designing Objects With Responsibilities Chapter 17 Applying UML and Patterns -Craig Larman.
Object Design Examples with GRASP (Ch. 18)
Use Case Model Operation Contracts Chapter 11 Applying UML and Patterns Craig Larman.
Review ♦ System sequence diagram ♦ Domain model
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
♦ Use Case Model  Detailled use case - Important  Use case diagram- Refactoring Use case diagram  > 1 Last Lectures.
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.
System sequence diagrams
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
Chapter 11 Operation Contracts. What They Are An operation is a specification of a transformation or query that an object may be called on to execute.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Operation Contracts. Primary way to describe system behavior is with use cases Operation contracts provide more details in terms of state changes to objects.
Week 4 Operational Contracts Requirements to Design Logical Architecture.
Fall 2009ACS-3913 Ron McFadyen1 Use Case Realizations with GRASP Patterns “The assignment of responsibilities and design of collaborations are very important.
Phase 6 Start: Saturday14 April End: Saturday 21 April
Case Study in Analysis: A library information system.
Domain Model A representation of real-world conceptual classes in a problem domain. The core of object-oriented analysis They are NOT software objects.
GRASP: Designing Objects With Responsibilities
OO Methodology Elaboration Phase Iteration 1- Part 3.
Summary from previous lectures
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.
1 Design Model Use-Case realizations with GRASP Larman chapter 17.
1 Object Oriented Analysis and Design System Events & Contracts.
OO Methodology Elaboration Phase Iteration 1- Part 2.
Object Design Examples with GRASP
Elaboration popo.
TK2023 Object-Oriented Software Engineering
System Sequence Diagrams and Operation Contracts
Used to help understand requirements more completely
System sequence diagrams
DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS
Chapter 11: Class Diagram
Operation Contracts Ch. 11.
Domain Model: Visualizing Concepts
Chapter 11: Class Diagram
Design Model: Creating Design Class Diagrams
Presentation transcript:

1 Lecture 6: Operation Contracts

2 Overview  What is contract ?  The guidelines for writing contracts for the system operations.  Use Case realizations.  Writing contracts leads to domain model updates.

3 Contracts  Contracts are documents that describe system behavior.  Contracts may be defined for system operations.  Operations that the system (as a black box) offers in its public interface to handle incoming system events.  The entire set of system operations across all use cases, defines the public system interface.

4 SSD for BuyItem use case

5 System Operations and the System Interface  In the UML the system as a whole can be represented as a class.  Contracts are written for each system operation to describe its behavior.

6 Guidelines for Contracts

7 Use Case Realizations  A use case realization describes how a use case is realized in terms of collaborating objects.  UML interaction diagrams are used to illustrate use case realizations.  Recall Process Sale: from main scenario we identified a number of system events (operations).  Each system event was then described by a contract.

8 Contracts  A contract is a document that describes what an operation commits to achieve.  Emphasizing what will happen rather than how it will be achieved.  Contracts can be expressed by pre- and post- conditions.

9 Conceptual Model and Contracts  A Conceptual Model is a visual representation of conceptual classes or real- world objects in a domain of interest.  Contracts describe detailed system behavior in term of state changes to objects in the Domain Model, after a system operation has executed.

10 Utilize Conceptual Model  To make contracts you have to use the conceptual model.  We added the conceptual model from previous slides to assist the comprehension of post conditions in the contracts.

11 Domain Model

12 Contract Sections Operation: Name Of operation, and parameters. Cross References: (optional) Use cases this can occur within. Preconditions:Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. Postconditions:-The state of objects in the Domain Model after completion of the operation.

13 Example: AddLineItem Contract Contract CO2: AddLineItem Operation: addLineItem (itemID: ItemID, quantity: integer) Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway. Post-conditions:  A SalesLineItem instance sli was created. (instance creation)  sli was associated with the current Sale. (association formed)  sli.quantity was set to quantity. (attribute modification)  sli was associated with a ProductSpecification, based on itemID match. (association formed)

14 Pre- & Post- Conditions  Preconditions are assumptions about the state of the system before execution of the operation.  A Postcondition is an assumption that refers to the state of the system after completion of the operation.  The postconditions are not actions to be performed during the operation.  Describe changes in the state of the objects in the Domain Model (instances created, associations are being formed or broken, and attributes are changed).

15 How to Make a Contract 1.Identify system operations from the system sequence diagrams. 2.For each system operation, construct a contract. 3.Write the preconditions section. 4.Write the postconditions section describing the state changes that occur to concepts in the conceptual model. Postconditon categories:  Instance creation and deletion.  Attribute modification.  Associations formed and broken.

16 AddLineItem Postconditions Creation and Deletion  After the itemID and quantity of an item have been entered by the cashier, what new objects should have been created?  A SaleLineItem instance sli was created.

17 AddLineItem Postconditions Attribute Modification  After the itemID and quantity of an item have been entered by the cashier, what attributes of new or existing objects should have been modified?  sli.quantity was set to quantity.

18 AddLineItem Postconditions Associations Formed and Broken  After the itemID and quantity of an item have been entered by the cashier, what associations of new or existing objects should have been formed or broken?  sli was associated with the current Sale.  sli was associated with a ProductSpecification, based on itemID match.

19 Writing Contracts leads to Domain Model Updates  It is also common to discover the need to record new concepts, attributes or associations in the Domain Model.  For example:  If in one of the postconditions, you wanted to create an instance to store some values in it, and it was not presented by any Concept in the domain model.  Then you should go back and correct your domain model by adding this concept.

20 The most common mistake in creating contract  The most common problem in creating contracts is forgetting to include the forming of associations. Particularly, when new instances are created, it is very likely that associations to several objects need be established.  Don’t forget to include all the associations formed and broken.

21 Example 1: End Sale Contract Contract: EndSale Operation: EndSale () Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway and all items have been entered. Post-conditions: Sale.isComplete became true. (attribute modification)

22 Example 2: Make Payment Contract Contract: MakePayment Operation: MakePayment (amount: Number or Quantity) Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway and all items have been entered. Post-conditions:  A Payment instance p was created. (instance creation)  p.amountTendered was set to amount. (attribute modification)  p was associated with the current Sale. (association formed)  The current Sale was associated with the Store; to add it to the historical log of completed sales. (association formed)

23 Summary  Contracts describe detailed system behavior in terms of state changes to objects in the Conceptual model after a system operation.  Contracts have sections of Operations, Cross references, Preconditions and Postconditions. Postconditions are the most important section.  Postconditions describe changes in the state of objects in the Conceptual model.