12 - OOSC - Object Design (Specifying Interfaces)
-
Upload
ariana-puscas -
Category
Documents
-
view
232 -
download
0
Transcript of 12 - OOSC - Object Design (Specifying Interfaces)
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
1/45
Armin B. Cremers, Sascha Alda & Tobias Rho(based on Bruegge & Dutoit)
Object-OrientedSoftwareConstruction
Chapter 12:Object Design (Specifying Interfaces)
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
2/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2
Announcement Practice Talk
Michael Mahlberg (TCG The Consulting Guild GmbH)
Experiences with (and without!) coupling andcohesion from industry
Thursday, 29th 2006 16:30 (B-IT Lecture Hall)
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
3/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 3
Object Design: Closing the Gap
Custom objects
Application objects
Off-the-shelf components
Solution objects
System Problem
Machine
System design gap
Object design gap
Requir ements gap
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
4/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 4
Object Design Interface Design
Requirements analysis activities
Identifying first attributes and operations without specifying their typesor their parameters.
Goal of Interface Design:
Describe the Interface of each object precisely enough so that objectsrealized by individual developers fit together with minimal Integration
problems
Activities:
Identify missing attributes and operations from analysis object and
subsystem service Specify Visibility and Signatures
Specify Contracts (main focus in this lecture)
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
5/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 5
Developers play different Roles duringObject Design
Developer
Call Class
Class Extender
Class Implementor
Class User
Realize Class
Refine Class
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
6/45
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
7/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 7
Add Visibility Information
UML defines three levels of visibility:
Private (Class implementor):
A private attribute can be accessed only by the class in which it isdefined.
A private operation can be invoked only by the class in which it isdefined.
Private attributes and operations cannot be accessed by subclasses or
other classes. Protected (Class extender):
A protected attribute or operation can be accessed by the class in whichit is defined and on any descendent (subclass) of the class.
Public (Class user): A public attribute or operation can be accessed by any class.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
8/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 8
Implementation of UML Visibilityin Java
Tournament
- maxNumPlayers: int
# removePlayer(p:Player)+ acceptPlayer(p:Player)
+ getMaxNumPlayers():int+ getPlayers(): List
+ isPlayerAccepted(p:Player):boolean
publicTournament(League l, int maxNumPlayers)
public intgetMaxNumPlayers() {};protected voidremovePlayer(Player p) {};
publicList getPlayers() {};
public voidacceptPlayer(Player p) {};
public booleanisPlayerAccepted(Player p) {};
public classTournament {
private intmaxNumPlayers;
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
9/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 9
Information Hiding Heuristics
Carefully define the public interface for classes as well as subsystems(faade)
Always apply the Need to know principle.
Only if somebody needs to access the information, make it publiclyavailable, but then only through well defined channels, so you alwaysknow the access.
The fewer an operation knows
the less likely it will be affected by any changes the easier the method can be changed
Information hiding is not a major issue during analysis, howeverduring design it is a problem.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
10/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 10
Information Hiding Design Principles
Only the operations of a class are allowed to manipulateits attributes
Access attributes only via operations.
// Can be accessed directly
public Object myAttr = ;
// Cant be accessed directly
private Object myAttr = ;
public void getMyAttr(){
return this.myAttr;
}
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
11/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 11
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 operationswithout type information
are acceptable during analysis
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
12/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 12
Design by Contract
Idea: Contracts on a class enable caller (client) and callee (class
itself) to share the same assumptions (semantics) about the class.
Problem: Accurate Semantics cannot be added to standard UML
models discussed so far Solution/Realization: Design By Contract by Betrand Meyer
(Object-Oriented Software Construction, Prentice Hall)
Process of developing software based on the notion of contracts
between objects
Contracts are expressed as assertions (predicates)
Assertions comprise preconditions, postconditions and invariants
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
13/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 13
Types of Assertions
Precondition:
Preconditions are predicates associated with a specific operation andmust be true before the operation is invoked.
Preconditions are used to specify constraints that a caller must meetbefore calling an operation.
Postcondition:
Postconditions are predicates associated with a specific operation andmust be true afteran operation is invoked.
Postconditions are used to specify constraints that the object (callee)must ensure after the invocation of the operation.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
14/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 14
Examples of AssertionsAssertion of List method add
List
+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean+size():int
-list:Collection
PreCondition
list != null //List exists
key.instanceOf(String)
PostCondition
size = size +1;containsKey( key ) = true;
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
15/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 15
Design by Contract
Parties in the contract: class and client
PreCondition binds clients
PostCondition binds class
Contract important for Class User (Client) and Class Implementor(class)
Contract entails benefits and obligations for both parties
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
16/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 16
Example
Contract for add
of class List
Class User
Class Implementor
Obligations Benefits
Only call add() on a
non-full and existing List
Make sure that key is in the
List; List has increased by one
Can retrieve item by
containsKey( );
Does not need to care
about Cases, where Listis full or not created
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
17/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 17
Class invariants and class correctness
Preconditions and postconditions describe properties of individualmethods
Need for global properties of instances which must be preserved by
all routines Examples (List)
Size of List must not be negative
Size of List must be lower than 1000 entries
The number of elements must be even
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
18/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 18
Class invariants and class correctness
A class invariant is an assertion to be satisfied by all instances of theclass at all stable times (instance in stable state):
on instance creation
before and after every remote call to a routine may be violated during call
A class invariant only applies to public methods; private methods are
not required to maintain the invariant.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
19/45
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
20/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 20
Design by ContractInheritance
What does inheritance mean in relation to Design by Contract?
Overridden methods must conceptually do the same job!
Contract Inheritance
Rule of Thumb: Demand no more, promise no less.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
21/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 21
Design by ContractInheritance
Demand no more:
A method of subclass is allowed to weaken the preconditions of
the method it overrides
An overridden method with a weaker precondition can handle morecases than its superclass
Promise no less:A method must ensure a stronger postcondition than the method
it overrides
An overridden method with a stronger postcondition ensures more
specific cases to the client upon return
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
22/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 22
Design by ContractInheritance Example 1
A method of subclass is allowed to weaken the preconditions of the
method it overrides. Example (1)
List
+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean+size():int
-list:Collection
NewList
+add(key:Object)New PreCondition P2
list != null //List exists
PreConditionP1
list != null //List exists
key.instanceOf(String)
Correct!
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
23/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 23
List
+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean
+size():int
-list:Collection
NewList
+add(key:Object)
A method of subclass is allowed to weaken the preconditions of the
method it overrides. Example (2)
Violated!
New PreCondition P2
list != null //List exists
key.instanceOf(String)
Length(key) < 10
PreConditionP1
list != null //List exists
key.instanceOf(String)
Design by ContractInheritance Example 2
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
24/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 24
A method must ensure a stronger postcondition as the method it
overrides: Example:
Violated!
Design by ContractInheritance Example 4
List
+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean+size():int
-list:Collection
NewList
+add(key:Object)
PostConditionP2
size = size +1;
containsKey( key ) = true;
size > 2
PostConditionP1
size = size +1;
containsKey( key ) = true;
size > 10
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
25/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 25
A method must ensure a stronger postcondition as the method it
overrides: Example:
Correct!
Design by ContractInheritance Example 3
List
+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean+size():int
-list:Collection
NewList
+add(key:Object)
New PostCondition P2
size = size +1;
containsKey( key ) = true;
size > 9
PostConditionP1
size = size +1;
containsKey( key ) = true;
size > 3
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
26/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 26
Application of Design by Contract
The Liskov Substitution Principle:
If an object of type S can be substituted in all places where anobject of Type T is expected, then S is a subtype of T
If all preconditions of the methods of type S are weakened and allpostconditions of the methods of type S are stronger than themethods of type T, then S is a subtype of type T
Client do not has to change its code, if object T is substituted by S
T
S
Client
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
27/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 27
Advantages of Design By Contract
Improves the reliability of programs
Assertions provide accurate documentation for the
implemented classes so that a programmer knows how touse the classes and what to expect from them;
Assertions provide a way of controlling inheritance(substitutability)
Assertions can be an important aid to developing criticalsystems.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
28/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 28
Expressing constraints in UML Models
OCL 2.0 (Object Constraint Language) is part of UML 2.0
OCL allows constraints to be formally specified on single model elements
(attributes, operations, classes) or groups of model elements
(associations and participating classes)
A constraint is expressed as an OCL expression returning the value true
or false.
OCL is not a procedural language (cannot constrain control flow).
More Info:
Introduction of OCL for Together
http://bdn1.borland.com/devcon05/article/1,2006,33187,00.html
Tutorial of University of Koblenz
http://www.uni-koblenz.de/~beckert/Lehre/Praktikum-Formale-Entwicklung/oclIntro.pdf
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
29/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 29
Expressing constraints in UML Models
OCL expressions for Hashtable operation put():
The context keyword indicates the object to which theexpression is valid
Invariant:
context Hashtable inv: numElements >= 0 OCL expression
Context is a class
Precondition: context Hashtable::put(key, entry) pre:!containsKey(key)
Post-condition:
context Hashtable::put(key, entry) post: containsKey(key) andget(key) = entry
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
30/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 30
A constraint can also be depicted as a note attached to theconstrained UML element by a dependency relationship.
!containsKey(key)
containsKey(key)
containsKey(key)
get(key) == entry
!containsKey(key)
numElements >= 0
HashTable
put(key,entry:Object)
get(key):Objectremove(key:Object)containsKey(key:Object):booleansize():int
numElements:int
Expressing constraints in UML Models
C t t f tPl i
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
31/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 31
Contract for acceptPlayer inTournament
contextTournament::acceptPlayer(p) pre:
not isPlayerAccepted(p)
contextTournament::acceptPlayer(p) pre:getNumPlayers() < getMaxNumPlayers()
contextTournament::acceptPlayer(p) post:
isPlayerAccepted(p)
Contract for acceptPlayer in
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
32/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 32
contextTournament::removePlayer(p) pre:
isPlayerAccepted(p)
contextTournament::removePlayer(p) post:not isPlayerAccepted(p)
contextTournament::removePlayer(p) post:
getNumPlayers() = @pre.getNumPlayers() - 1
Contract for acceptPlayer inTournament
@pre.= value returned bymethod before invoking
removePlayervalue returned bymethod afterinvoking
removePlayer
OCL Annotations
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
33/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 33
public classTournament {
/** The maximum number of players* is positive at all times.* @invariant maxNumPlayers > 0*/
private intmaxNumPlayers;
/** The players List contains* references to Players who are* are registered with the* Tournament. */
privateList players;
/** Returns the current number of* players in the tournament. */
public intgetNumPlayers() {}
/** Returns the maximum number of* players in the tournament. */
public intgetMaxNumPlayers() {}
/** The acceptPlayer() operation* assumes that the specified* player has not been accepted* in the Tournament yet.* @pre !isPlayerAccepted(p)* @pre getNumPlayers()
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
34/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 34
Constraints can involve more thanone class
Until now: Constraints are valid within a single class
Often, Constraints are necessary to declare assertions
across many classes Make Assumptions about associations between classes
Definition of global invariants
Expressions for navigating between classes are necessary
Set-based operations
Types of Navigation through a Class
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
35/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 35
Types of Navigation through a ClassDiagram
Tournament
start:Dateend:Date
League
Player Tournament
League
1. Local attribute 2. Directly related class 3. Indirectly related class
*
*
*
*
Player*
Any OCL constraint for any class diagram can be builtusing only a combination of these three navigation types!
Example: League Tournament and
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
36/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 36
Example: League, Tournament andPlayer
players
* tournaments
Tournament
+start:Date+end:Date
+acceptPlayer(p:Player)
*League
+start:Date+end:Date
+getActivePlayers()
* Player
+name:String+email:String
* players
tournaments*
Model Refinement with 2 additional
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
37/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 37
Model Refinement with 2 additionalConstraints
A Tournaments planned duration must be under one week.
Players can be accepted in a Tournament only if they are already
registered with the corresponding League.
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
38/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 38
OCL Collections
Collections are data types used to navigate to associatedclasses within a constraint expression.
OCL Sets
Used to navigate a single (1:1, 1:n, or n:m) association
League
Player
*
*
chess:League
Isa:Player Marc:PlayerBob:Player
league.player = {Bob, Isa, Marc}
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
39/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 39
OCL Collections
Collections are data types used to navigate to associatedclasses within a constraint expression.
OCL Bags
Used to navigate through a series of at least two associations withone-to-many or many-to-many multiplicity
League
Tournament
*
chess:League
Isa:Player Marc:PlayerBob:Player*
*Player
WM:
Tournament
EM:
Tournament
league.tournament.player = {Bob, Isa, Marc,Isa}
OCL C ll i
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
40/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 40
OCL Collections
OCL provides many operations for accessing collections (viaAccess Operator ). Examples:
includes(Object) returns true if Object is in Collection
union(Collection) returns a Collection containing elements fromboth the original collection and the collectionspecified as paramater
asSet(Collection) returns a Set containing each element of the
collection without any duplicate elements (asopposed to a bag)
Examples:
{Bob, Isa, Marc}includes( Timo ) = false;
league.tournament.player = {Bob, Isa, Marc,Isa}
league.tournament.playerasSet = {Bob, Isa, Marc}
S if i th M d l C t i t
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
41/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 41
Specifying the Model Constraints
Local attribute navigationcontext Tournamentinv:
end - start includes(p)
OCL Q ifi i
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
42/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 42
OCL supports Quantification
OCL forAll quantifier
forAll (variable | expression) is true, if expression is true for allelements in the collection
Example: All Matches m in a Tournament toccur within theTournaments time frame:
contextTournament inv:matches->forAll( m:Match |m.start.after(t.start) and m.end.before(t.end))
OCL exists quantifier
exists ( variable | expression ) is true if there is at least oneelement in the collection for which expression is true
Example: Each Tournament conducts at least one Match on thefirst day of the Tournament:
contextTournament inv:matches->exists(m:Match | m.start.equals(start))
Realization of Constrains in
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
43/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 43
Programming Language: Java
Often realized in terms of conventional exception handling
Assertions to check pre- and postconditions within methods can beused since JDK 1.4
The validation of Assertions must be enabled (is disabled by default)
Compilation:
Start:
Boolean expression (must be true at runtime,anAssertionError is thrown, otherwise)
Start:
java Assertions
x = 0java.lang.ArithmeticException:
/ by zero
java ea Assertions
x = 0
/ by 0
Optional indication of a Message-String
for the AssertionError Objekt
Realization of OCL in Java
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
44/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 44
Realization of OCL in Java
Only view OCL compilers and parsers are available.
Dresden OCL Toolkit
Generates Java Code for given OCL assertions
Runtime Evaluation of Assertions
Web: http://dresden-ocl.sourceforge.net/aboutproject.html
IBM OCL Parser
Checking of syntax only, no Code Generation
Web: http://www-306.ibm.com/software/awdtools/library/standards/ocl-download.html
Together Borland
S mmar
-
8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)
45/45
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 45
Summary
There are three different roles for developers during object design Class user, class implementor and class extender
During object design - and only during object design - we specifyvisibility rules
Constraints are boolean expressions on model elements
Contracts are constraints on a class enable class users, implementorsand extenders to share the same assumption about the class(Design by contract)
OCL is a language that allows us to express constraints on UMLmodels
Complicated constratins involving more than one class, attribute or
operation can be expressed with 3 basic navigation types.