Download PPT

Key Mechanisms
OOAD Using UML, v. 3.0
Key Mechanisms, p. 1
Copyright © 1997 by Rational Software Corporation
R
Objectives: Key Mechanisms
You will be able to:
 Describe some OO-specific key mechanisms
 Explain the issues associated with database interface
 List some considerations for evaluating database management
systems
 Describe exception handling and its associated issues
 Explain the issues associated with interprocess communication
OOAD Using UML, v. 3.0
Key Mechanisms, p. 2
Copyright © 1997 by Rational Software Corporation
R
What are Key Mechanisms ?



A key mechanism is a decision regarding common standards, policies,
and practices, for example
 A common approach to error handling, or
 A common way of communicating among processes
Most of the traditional software design principles still apply in OO
design
 The problems to be solved are similar, e.g., resource contention,
risk mitigation, and so on
Some differences arise due to:
 Solutions being structured using OO methods
 The features of OO programming languages
OOAD Using UML, v. 3.0
Key Mechanisms, p. 3
Copyright © 1997 by Rational Software Corporation
R
Common Key Mechanisms






Management of resource contention
Special handling required for system startup and termination
Integration with persistent data storage systems
Error detection / handling / reporting
Interprocess communication
Software reuse
OOAD Using UML, v. 3.0
Key Mechanisms, p. 4
Copyright © 1997 by Rational Software Corporation
R
Resource Contention




A resource manager class can be used to control access to resources
The manager class utilizes traditional software methods, such as
semaphores to control access to its resource
The manager provides operations to allow clients of the resource to
acquire it, release it, enqueue to acquire it, obtain its status, etc.
A superclass which embodies the interface to the managed resources
can be supplied with the resource manager to enhance its reusability
OOAD Using UML, v. 3.0
Key Mechanisms, p. 5
Copyright © 1997 by Rational Software Corporation
R
Resource Contention
ResourceManager
ManagedResource
acquire ()
release ()
1
1..*
File
OOAD Using UML, v. 3.0
Key Mechanisms, p. 6
Copyright © 1997 by Rational Software Corporation
SharedMemory
R
System Startup and Termination



If not already covered during analysis, use cases should be defined for
both system startup and termination
Scenarios should be developed for each use case - as many as are
necessary to handle all major normal and abnormal situations
During this process new states and behaviors may be uncovered for
existing classes and the need may arise for entirely new classes to
control startup and/or termination
OOAD Using UML, v. 3.0
Key Mechanisms, p. 7
Copyright © 1997 by Rational Software Corporation
R
Persistent Objects





A persistent object is one that logically exists beyond the scope of the
program that created it
OO programming languages deal only with essentially transient,
memory-resident objects
A persistent object has the ability to save the value of its attributes into
some type of persistent storage
A persistent object can also be created in memory and initialized with
its attribute values from persistent storage
The overall strategy for providing persistence for objects in the system
is decided during tactical design
OOAD Using UML, v. 3.0
Key Mechanisms, p. 8
Copyright © 1997 by Rational Software Corporation
R
Persistent Storage



Persistent storage can be done using a simple file system or some type
of database management system
There are several models for DBMSs:
 Hierarchical
 Network
 Relational (RDBMS)
 Object-oriented (OODBMS)
Relational and OODBMSs are most common
OOAD Using UML, v. 3.0
Key Mechanisms, p. 9
Copyright © 1997 by Rational Software Corporation
R
Selecting an Approach to Persistence


The design strategy for retaining persistent objects must consider
 Access times
 Storage capacity
 Storage system reliability
 Access to existing data
The model chosen influences system and object design in that
designers must consider:
 Additional object methods to store and retrieve persistent objects
 Addition of attributes to handle storage system details
 Additional classes to interface with the DBMS
OOAD Using UML, v. 3.0
Key Mechanisms, p. 10
Copyright © 1997 by Rational Software Corporation
R
DBMS Evaluation Criteria


Evaluation criteria for picking a DBMS should be decided early on
The following slides contain criteria found in “Considerations for
evaluating object database management systems” by Robert Gancarz
and Grant Colley, Object Magazine, March/April 1992
 These criteria also apply to choosing a relational database
management system
OOAD Using UML, v. 3.0
Key Mechanisms, p. 11
Copyright © 1997 by Rational Software Corporation
R
DBMS Evaluation Criteria



Vendor Strengths
 Look at financial strength, organization structure, customer
support procedures, training and consulting support, alliances
with other companies
Database Performance
 No one benchmark can prove that the DBMS is fastest for all
applications
 Performance is application dependent
 Application specific prototypes are very important
Database Capabilities
 Transaction management, concurrency control, backup and
recovery, security, and query language support capabilities
should be evaluated
OOAD Using UML, v. 3.0
Key Mechanisms, p. 12
Copyright © 1997 by Rational Software Corporation
R
DBMS Evaluation Criteria




Database Architecture
 Evaluate concurrency control schemes, locking mechanisms, and
storage managers
Development Tools
 Look at tools for database design, modification of the database
schema, and database browsing and debugging
Language Support
 Make sure there is support for the language of choice for the
system being developed
Ease of Migration
 How easy/hard is it to migrate to the database system
OOAD Using UML, v. 3.0
Key Mechanisms, p. 13
Copyright © 1997 by Rational Software Corporation
R
DBMS Evaluation Criteria


Integration With Legacy Systems
 How easy/hard is it to integrate with existing database
management systems
Multi-user Support
 Evaluate support for multi-user development, configuration
management, versioning, and locking strategies
Bottom Line: Invest the time and energy to select the
right database management system for the project
It is ALWAYS more expensive to correct a mistake
than it is to do it right the first time !!!
OOAD Using UML, v. 3.0
Key Mechanisms, p. 14
Copyright © 1997 by Rational Software Corporation
R
Relational Database Issues



There are two major issues to contend with when designing an OO
system using a relational database
There is a natural semantic difference between the class-based model
of an object-oriented design and the table-based model of a relational
database
 A mapping, or translation, between the two must be defined
Behavior which interfaces to the RDBMS and implements this
translation must be defined
 Should this behavior be inserted into the persistent objects or
somehow be kept separate?
OOAD Using UML, v. 3.0
Key Mechanisms, p. 15
Copyright © 1997 by Rational Software Corporation
R
Mapping to Relational Databases

Typically, each class maps to a table and each instance maps to a row
Customer
name
address
discount

Customer Table
customerID
name
address
discount
More complicated mappings are possible
– One class maps to multiple tables
– Multiple classes map to one table
OOAD Using UML, v. 3.0
Key Mechanisms, p. 16
Copyright © 1997 by Rational Software Corporation
R
Mapping to Relational Databases

One-to-many relationships are implemented using a foreign key in the
table representing the “many” side of the relationship
Custom er
name
address
discount
1
0..*
Customer Table
customerID
name
address
discount
Order Table
Order
deliveryTime
urgency
OOAD Using UML, v. 3.0
Key Mechanisms, p. 17
orderID
delivery
urgency
Copyright © 1997 by Rational Software Corporation
customerID
R
Mapping to Relational Databases

Tables are created to resolve many-to-many relationships
Product
0..*
Product Ingredient Table
productID
ingredientID
1..*
Ingredient
OOAD Using UML, v. 3.0
Key Mechanisms, p. 18
Copyright © 1997 by Rational Software Corporation
R
Mapping to Relational Databases

Superclass / subclass can also be mapped to tables
 Each class and subclass is a table
 Views are provided for the hierarchy
Order
deliveryTime
urgency
Order Table
orderID
SpecialOrder
startDate
endDate
StandingOrder
urgency
SpecialOrder Table
frequency
orderID
OOAD Using UML, v. 3.0
Key Mechanisms, p. 19
deliveryTime
endDate
Copyright © 1997 by Rational Software Corporation
startDate
R
Mapping to Relational Databases


Alternate strategies exist for superclasses and subclasses
 Repeat all attributes in the superclass table
 Problem: wasted space
 Repeat all attributes in the subclass table
 Problem: redundancy
Performance versus storage space tradeoffs are used to decide which
mapping to use for inheritance situations
OOAD Using UML, v. 3.0
Key Mechanisms, p. 20
Copyright © 1997 by Rational Software Corporation
R
Interfacing With RDBMS



The major issue associated with interfacing with a RDBMS is whether
or not to separate the application-specific behavior from the databasespecific behavior
Suppose our system has a Customer class which we have decided
should be persistent
 Should the Customer class contain the details of the OO-toRDBMS mapping?
 Should the Customer class contain behavior to interface with the
RDBMS agent (e.g. code which generates SQL to do reads/writes
from/to the database)?
 Should the Customer class even know that it is persistent?
Either way can work - each has its own advantages and disadvantages
OOAD Using UML, v. 3.0
Key Mechanisms, p. 21
Copyright © 1997 by Rational Software Corporation
R
Interfacing With RDBMS

Database-specific behavior not separated from application-specific
behavior:
 Each persistent class can have create, read, update, and delete
(CRUD) functionality built in (e.g., operations which perform OOto-RDBMS mapping and generate SQL to implement it)
 Advantages
 Not technically challenging to implement
 Disadvantages
 OO and RDBMS models are not separable
 CRUD functionality is not always cleanly inheritable
OOAD Using UML, v. 3.0
Key Mechanisms, p. 22
Copyright © 1997 by Rational Software Corporation
R
Database Behavior Inside the Class
: CurriculumManager
: Course
1: save ( )
Course
description
The Course must have
database knowledge
OOAD Using UML, v. 3.0
Key Mechanisms, p. 23
Copyright © 1997 by Rational Software Corporation
save ()
R
Interfacing With RDBMS

Database-specific behavior is separated from application-specific
behavior
 System can be modeled in two partitions: Application and
Database Interface
 For each persistent class, an associated database interface
class is defined which understands the OO-to-RDBMS
mapping and has the behavior to interface with the RDBMS
 Advantages
 The OO model is separable from the RDBMS model
 Tools are available to generate the basic database interface
classes
 Disadvantages
 More technically challenging to implement
OOAD Using UML, v. 3.0
Key Mechanisms, p. 24
Copyright © 1997 by Rational Software Corporation
R
Separate Database Behavior
: CurriculumManager
: Transaction
Manager
: DBCourse
: Course
1: saveCourse (Course)
2: save (Course)
3: getDescription ( )
4: makePersistent ( )
TransactionManager
The TransactionManager
separates the logical (Course)
from the physical (DBCourse)
OOAD Using UML, v. 3.0
Key Mechanisms, p. 25
Course
Copyright © 1997 by Rational Software Corporation
DBCourse
R
Object-Oriented DBMSs




OODBMSs allow storage, retrieval and recovery of objects themselves
(with complex data encapsulated within each object)
An OODBMS typically retains
 Objects (i.e., attribute values)
 Class information about each object
There is no semantic gap between the OO model and the OODBMS
model - they are identical
No special behavior must be designed to interface with the OODBMS
OOAD Using UML, v. 3.0
Key Mechanisms, p. 26
Copyright © 1997 by Rational Software Corporation
R
Object-Oriented DBMSs



Advantages:
 Seamless interface between application and database
 Relatively little code needed to make objects persistent
 Very effective with systems which must traverse complicated data
structures
Disadvantages:
 Higher development risk as OODBMS technology and products
are not as mature as their RDBMS counterparts
 Performance with simpler data structures provides no advantage
over RDBMS
Existing investment in relational technology must be considered when
evaluating OO database technology
OOAD Using UML, v. 3.0
Key Mechanisms, p. 27
Copyright © 1997 by Rational Software Corporation
R
Error Detection



A consistent approach to error detection should be established during
tactical design
Objects should detect errors which would violate their integrity - this
includes errors
 Arising within their operations
 Resulting from parameters received from client objects
 Resulting from return values provided by supplier objects
A plan can be established to monitor the health of the system
 Test operation defined for each class which verifies the integrity
of internal structure and environment
 Monitoring objects defined to periodically poll each object’s test
function
OOAD Using UML, v. 3.0
Key Mechanisms, p. 28
Copyright © 1997 by Rational Software Corporation
R
Error Handling




Even in OO systems, error handling must be carefully designed -- more
than 30% of final code often exists to handle error conditions
Modern OO languages (such as 3.0 C++) provide exception handling
features to help in this design
Exception handling allows an error to be handled by an object other
than the object which detected the error
This is often appropriate, since the system-wide impact of an error is
not always known by the detecting object
OOAD Using UML, v. 3.0
Key Mechanisms, p. 29
Copyright © 1997 by Rational Software Corporation
R
Exception Handling Example
class String {
public:
class RangeError { int badIndex; }; // error type
char getChar(int index) const;
// ...
};
char String::getChar(int index) const {
if (index < 0 || index > lastValid)
throw RangeError(index); // throw point
return contents[index];
};
void foo() {
try {
String s = “hello”;
char c = s.getChar(0);
}
catch (const String::RangeError& why) { // catch point
cout << “subscript out of range” << why.badIndex << endl;
}
}
OOAD Using UML, v. 3.0
Key Mechanisms, p. 30
Copyright © 1997 by Rational Software Corporation
R
Throwing and Catching Exceptions



When there is a problem that cannot be handled in the current context,
an exception can be created and “thrown”
throw Problem(“things are bad”);
What does throw do ?
 The exception object is created and “returned”
Where does the exception object go?
 When an exception is thrown the call stack is searched for the
first matching handler
 There will be an exception handler for every type of
exception that could be caught
catch (Problem&) {
// handle exceptions of type Problem
}
OOAD Using UML, v. 3.0
Key Mechanisms, p. 31
Copyright © 1997 by Rational Software Corporation
R
Exception Handling Issues




In the process of searching the call stack, destructors for local objects
are called
 Automatic variables
 Value parameters
 Temporaries
Destructors are not called for
 Dynamic variables
 Static variables
Code after the throw point is never executed
Exceptions preempt resource management (e.g. closing open files)
OOAD Using UML, v. 3.0
Key Mechanisms, p. 32
Copyright © 1997 by Rational Software Corporation
R
Should Exceptions Always Be Used?

Exceptions should not be used in the follow situations:
 Ordinary error conditions
 If there is enough information available to handle the error
then it is NOT an exception
 To control the program flow
 An exception is NOT an alternate return
OOAD Using UML, v. 3.0
Key Mechanisms, p. 33
Copyright © 1997 by Rational Software Corporation
R
When Should Exceptions Be Used?


Exceptions are thrown as a result of a serious error
 There is no return to the point where the exception was throw
Exceptions should not be used if the error can be handled (fixed) and
processing continues
 An operation may be called to “fix” the problem and processing
can continue
OOAD Using UML, v. 3.0
Key Mechanisms, p. 34
Copyright © 1997 by Rational Software Corporation
R
Typical Use of Exceptions







Fix the problem and continue processing without retrying the function
that threw the exception
Calculate an alternate result
Throw the error to a higher context
Terminate the program
Wrap functions that use ordinary error schemes
Simplify the code
Make the code more maintainable
OOAD Using UML, v. 3.0
Key Mechanisms, p. 35
Copyright © 1997 by Rational Software Corporation
R
Error Reporting




Proper error record keeping and on-line reporting are key to most
systems
Consistent error reporting behavior can be implemented in the base
error class used in exception handling
This behavior can include
 Adding the error to a system-wide error log
 Distributing the error to processes which facilitate on-line error
monitoring
This type of approach ensures consistency while separating the
detailed responsibility from the application classes
OOAD Using UML, v. 3.0
Key Mechanisms, p. 36
Copyright © 1997 by Rational Software Corporation
R
Interprocess Communication




ClassA calls ClassB’s operation functionB()
What happens when ClassA and ClassB are in different processes?
This becomes a critical issue in distributed systems
A standard mechanism for interprocess communication is needed
: ClassA
ClassA
ClassB
: ClassB
1: functionB ( )
functionB( )
OOAD Using UML, v. 3.0
Key Mechanisms, p. 37
Copyright © 1997 by Rational Software Corporation
R
Interprocess Communication


A common solution which supports the OO paradigm has been
developed
 Proxy classes are inserted into each process which provide the
interfaces of the original classes and encapsulate lower-level
communication
Distribution is transparent to application classes
OOAD Using UML, v. 3.0
Key Mechanisms, p. 38
Copyright © 1997 by Rational Software Corporation
R
OO Distributed Standards



Choosing a distribution standard is a design issue if your system uses
distributed objects
There are two emerging standards for OO distribution
 Common Object Request Broker Architecture (CORBA)
 Component Object Model (COM/OLE)
Object Request Brokers (ORB) provide transparent access to objects
in a distributed environment
 ORB allows location-independent client / server connectivity
 Distribution decisions can be made at runtime
OOAD Using UML, v. 3.0
Key Mechanisms, p. 39
Copyright © 1997 by Rational Software Corporation
R
Proxy Classes
ClassA
ProxyClientB
ProxyServerB
ClassB
Object Request Broker
OOAD Using UML, v. 3.0
Key Mechanisms, p. 40
Copyright © 1997 by Rational Software Corporation
R
Planning for Reuse




Reusable components must be considered early in the design process
for incorporation into the system
Evaluate commercial and internal software libraries for modules to
apply in the system
Class libraries are groups of collaborating classes that provide some
service, interface, or function
Class libraries are commonly available for:
 Container objects
 Interfaces to databases
 User interface widgets
OOAD Using UML, v. 3.0
Key Mechanisms, p. 41
Copyright © 1997 by Rational Software Corporation
R
Updating Diagrams


Class diagrams are updated to show the chosen key mechanisms
Sequence diagrams are updated to show interaction between classes
already discovered and classes representing the key mechanism
strategies
OOAD Using UML, v. 3.0
Key Mechanisms, p. 42
Copyright © 1997 by Rational Software Corporation
R
Updated Class Diagram
Outgoing
Interfaces
GUI Widgets
Business
Rules
Foundations
global
OOAD Using UML, v. 3.0
Key Mechanisms, p. 43
Error
Handling
Incoming
Interfaces
University
Artifacts
Database
global
Copyright © 1997 by Rational Software Corporation
R
Updated Sequence Diagram
: Registrar
aForm :
CurriculumMgr
1: open
theManager :
CurriculumMgr
theCourse
: Course
anOf f ering
: (Course
dbMgr :
TransactionMgr
dbCourse :
DBCourse
dbOf f ering :
DBOf fering
2: enter id
3: v erif y id
4: enter
5: create a
6: set number, name, description,
7: set number of f erings, prof essor,
8: process
9: create course(number, name, description, credit hours, of f erings,
10: create(number, name, description,
11: create of f ering(number, pof essor,
12: create(prof essor, time,
13: sav e
14: sav e(course)
15: get inf o
16: commit
17: sav e(of f ering)
18: get inf o
19: commit
OOAD Using UML, v. 3.0
Key Mechanisms, p. 44
Copyright © 1997 by Rational Software Corporation
R
Exercise: Key Mechanisms



Discuss key mechanisms strategies for the problem
Update the class diagram to show the incorporation of the key
mechanisms
Update diagrams as necessary
OOAD Using UML, v. 3.0
Key Mechanisms, p. 45
Copyright © 1997 by Rational Software Corporation
R
Summary: Key Mechanisms

The selection of key mechanisms focuses on decisions regarding
common standards, policies, and practices including:
 Management of resource contention
 Special handling required for system startup and termination
 Integration with persistent data storage systems
 Error detection / handling / reporting
 Interprocess communication
 Software reuse
OOAD Using UML, v. 3.0
Key Mechanisms, p. 46
Copyright © 1997 by Rational Software Corporation
R

OOAD Using UML, v. 3.0
Key Mechanisms, p. 47
Copyright © 1997 by Rational Software Corporation
R