Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.

Slides:



Advertisements
Similar presentations
Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Advertisements

Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 1: Introduction.
Based on Java Software Development, 5th Ed. By Lewis &Loftus
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 2, Modeling with UML, Part 4 UML 2 Metamodel.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering September 12, 2001 Capturing.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 7, Object Design.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Example of a Problem Statement: Introduction into.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Art for Chapter 7, Object Design.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 7, Object Design.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Object Constraint Language.
Using UML, Patterns, and Java Object-Oriented Software Engineering Art for Chapter 9, Specifying Interfaces.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Object Design: Specifying Interfaces Chapter 9. 2 Object Design  Object design is the process of adding details to the requirements analysis and making.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 7, Object Design.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5: Analysis, Object Modeling.
Liang,Introduction to Java Programming,revised by Dai-kaiyu 1 Chapter 10 Object-Oriented Modeling.
Chapter 9: Object Design: Specifying Interfaces
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Analysis: Dynamic Modeling.
Software Testing and Quality Assurance
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 8, Object Design: Reuse and Patterns.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Object Modeling.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 7, Object Design.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Object Design  Object design  Detail requirements.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Using UML, Patterns, and Java Object-Oriented Software Engineering Example of a Problem Statement: Introduction into ARENA.
Object-Oriented Analysis and Design
Object Oriented Analysis By: Don Villanueva CS 524 Software Engineering I Fall I 2007 – Sheldon X. Liang, Ph. D.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
Using UML, Patterns, and Java Object-Oriented Software Engineering Art for Chapter 8, Object Design: Reusing Pattern Solutions.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Object Modeling.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5: Analysis, Object Modeling.
111 Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract,
Approaching a Problem Where do we start? How do we proceed?
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 2, Modeling with UML: Review Session (Optional)
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 2, Modeling with UML: Review Session (Optional)
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
Lecture 6: Structural Modeling
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Few comments about midterm I graded very lightly.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 10, Mapping Models to Relational Schema.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 11 Object-Oriented.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
CEN th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi Object Design: Specifying.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 2, Modeling with UML: UML 2 Metamodel Note to Instructor: The material in this.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Two New UML Diagram Types Component Diagram Deployment Diagram.
1 Use Cases Object-Oriented Modeling and Design with UML (Second Edition) Blaha & Rumbaugh Sections 7.1, 8.1.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Bernd Bruegge and Allen Dutoit Requirements Process The requirements process consists of two activities: Requirements Elicitation: Definition of the system.
Chapter 9, Object Design: Specifying Interfaces
Example of a Problem Statement: Introduction into ARENA
Chapter 9, Object Design: Specifying Interfaces
Chapter 9, Object Design: Specifying Interfaces
Chapter 9, Object Design: Specifying Interfaces
Object Design Object design is the process of adding details to the requirements analysis and making implementation decisions The object designer must.
Presentation transcript:

Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 Lecture Plan Specifying Interfaces (Chapter 9) Object Design Activities Visibilities and Information Hiding, Contracts Mapping Models to Java Code (Chapter 10) Optimizations to address performance requirements Implementation of class model components Realization of associations Realization of contracts Mapping Models to Relational Schema (Ch ) Realizing entity objects Mapping the object model to a storage schema Mapping class diagrams to tables.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Outline of Today’s Lecture Object Design Activities Visibilities Information Hiding Contracts

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 Requirements Analysis vs. Object Design Requirements Analysis: The functional model and the dynamic model deliver operations for the object model Object Design: Decide where to put these operations in the object model Object design is the process of adding details to the requirements analysis making implementation decisions Thus, object design serves as the basis of implementation The object designer can choose among different ways to implement the system model obtained during requirements analysis.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Object Design: Closing the Final Gap Custom objects Application objects Off-the-shelf components Solution objects System Problem Machine System design gap Object design gap Requirements gap

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Developers play 3 different Roles during Object Design of a Class DeveloperClass Implementor Class User Class Extender Call the Class Realize the Class (Implement it) Refine the Class (Implement a subclass)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Class user versus Class Extender GameTicTacToeChess LeagueTournament 1 * The developer responsible for the implementation of League is a class user of Game The developer responsible for the implementation of TicTacToe is a class extender of Game The Developer responsible for the implementation of Game is a class implementor

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Specifying Interfaces Requirements analysis activities Identify attributes and operations without specifying their types or their parameters Object design activities Add visibility information Add type signature information Add contracts.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Add Visibility Information Class user (“Public”): + Public attributes/operation can be accessed by any class Class implementor (“Private”): - Private attributes and operations can be accessed only by the class in which they are defined They cannot be accessed by subclasses or other classes Class extender (“Protected”): # Protected attributes/operations can be accessed by the class in which they are defined and by any descendent of the class. Developer Call Class Class Extender Class Implementor Class User Realize Class Refine Class

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Implementation of UML Visibility in Java public Tournament(League l, int maxNumPlayers) public int getMaxNumPlayers() {…}; public List getPlayers() {…}; public void acceptPlayer(Player p) {…}; public void removePlayer(Player p) {…}; public boolean isPlayerAccepted(Player p) {…}; Tournament - maxNumPlayers: int + acceptPlayer(p:Player) + removePlayer(p:Player) + getMaxNumPlayers():int + getPlayers(): List + isPlayerAccepted(p:Player):boolean public class Tournament { private int maxNumPlayers;

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Information Hiding Heuristics Carefully define the public interface for classes as well as subsystems For subsystems use a façade design pattern if possible Always apply the “Need to know” principle: Only if somebody needs to access the information, make it publicly possible Provide only well defined channels, so you always know the access The fewer details a class user has to know the easier the class can be changed the less likely they will be affected by any changes in the class implementation Trade-off: Information hiding vs. efficiency Accessing a private attribute might be too slow.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 Information Hiding Design Principles Only the operations of a class are allowed to manipulate its attributes Access attributes only via operations Hide external objects at subsystem boundary Define abstract class interfaces which mediate between the external world and the system as well as between subsystems Do not apply an operation to the result of another operation Write a new operation that combines the two operations.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Add Type Signature Information Hashtable +put(key:Object,entry:Object) +get(key:Object):Object +remove(key:Object) +containsKey(key:Object):boolean +size():int -numElements:int Hashtable put() get() remove() containsKey() size() numElements:int Attributes and operations without visibility and type information are ok during requirementsanalysis During object design, we decide that the hash table can handle any type of keys, not only Strings.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Outline of Today’s Lecture Object Design Activities Visibilities Information Hiding Contracts

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Modeling Constraints with Contracts Example of constraints in Arena: An already registered player cannot be registered again The number of players in a tournament should not be more than maxNumPlayers One can only remove players that have been registered These constraints cannot be modeled in UML We model them with contracts Contracts can be written in OCL.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Contract Contract: A lawful agreement between two parties in which both parties accept obligations and on which both parties can found their rights The remedy for breach of a contract is usually an award of money to the injured party Object-oriented contract: Describes the services that are provided by an object if certain conditions are fulfilled services = “obligations”, conditions = “rights” The remedy for breach of an OO-contract is the generation of an exception.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Object-Oriented Contract An object-oriented contract describes the services that are provided by an object. For each service, it specifically describes two things: The conditions under which the service will be provided A specification of the result of the service Examples: A letter posted before 18:00 will be delivered on the next working day to any address in Germany For the price of 4 Euros a letter with a maximum weight of 80 grams will be delivered anywhere in the USA within 4 hours of pickup.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Object-Oriented Contract An object-oriented contract describes the services that are provided by an object. For each service, it specifically describes two things: The conditions under which the service will be provided A specification of the result of the service that is provided. Examples: A letter posted before 18:00 will be delivered on the next working day to any address in Germany. For the price of 4 Euros a letter with a maximum weight of 80 grams will be delivered anywhere in Germany within 4 hours of pickup.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Modeling OO-Contracts Natural Language Mathematical Notation Models and contracts: A language for the formulation of constraints with the formal strength of the mathematical notation and the easiness of natural language:  UML + OCL (Object Constraint Language) Uses the abstractions of the UML model OCL is based on predicate calculus

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Contracts and Formal Specification Contracts enable the caller and the provider to share the same assumptions about the class A contract is an exact specification of the interface of an object A contract include three types of constraints: Invariant: A predicate that is always true for all instances of a class Precondition (“rights”): Must be true before an operation is invoked Postcondition (“obligation”): Must be true after an operation is invoked.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 Formal Specification A contract is called a formal specification, if the invariants, rights and obligations in the contract are unambiguous.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 Expressing Constraints in UML Models A constraint can also be depicted as a note attached to the constrained UML element by a dependency relationship. HashTable put(key,entry:Object) get(key):Object remove(key:Object) containsKey(key:Object):boolean size():int numElements:int > numElements >= 0 > !containsKey(key) > containsKey(key) > !containsKey(key) > get(key) == entry

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 Why not use Contracts already in Requirements Analysis? Many constraints represent domain level information Why not use them in requirements analysis? Constraints increase the precision of requirements Constraints can yield more questions for the end user Constraints can clarify the relationships among several objects Constraints are sometimes used during requirements analysis, however there are trade offs

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 Requirements vs. Object Design Trade-offs Communication among stakeholders Can the client understand formal constraints? Level of detail vs. rate of requirements change Is it worth precisely specifying a concept that will change? Level of detail vs. elicitation effort Is it worth the time interviewing the end user Will these constraints be discovered during object design anyway? Testing constraints If tests are generated early, do they require this level of precision?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 To be continued in Lecture on OCL