Transcript Persistency Mechanism

Object Oriented Analysis and Design
Using the UML
Version 4.2
Architectural Design Patterns
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Analysis, Design, and Implementation Mechanisms
 We know about (in RUP) Analysis Mechanisms –
which are really Non Functional Requirtements…
 In Design, the ‘conceptual’ is morphed into a
general technology.
 In Implementation, these ‘general technologies’
are mapped into quite specific technologies.
 E.g. Relational Data Base  Oracle; MySQL, etc.
 Choice of Design Mechanism constrained by
availability in implementation environment.
 If we plan to use a relational databases and
have one or two ‘on site,’ then this is a real
constraint and influences how we
accommodate such requirements.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Design/Implementation Mechanisms
Analysis
Design
Implementation
Mechanism
Mechanism
Mechanism
(Conceptual)
(Concrete)
(Actual) (often
constrained by
Availability)
A ‘what’ was needed to
solve a problem:
Persistency
Legacy Data
RDBMS
JDBC
New Data
Persistency
Distribution
OODBMS
Remote Method
Invocation (RMI)
Analysis
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
Design
34
ObjectStore
Java x.x from Sun
Implementation
Design Mechanisms
 Design mechanism assume
 some details of the implementation environment,
 but not tied to a specific implementation
 For ‘persistency’ our design mechanisms
might include:
 RDBMS,
 OODBMS,
 in-memory storage, …
 For ‘security’ there will be some other design
mechanisms that address…
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Implementation Mechanisms
 Implementation mechanisms are used during
implementation.
 They are bound to a certain technology, implementation
language, vendor, technique, etc.
 Examples:




actual programming language,
COTS products,
Database (Oracle, Sybase, SQL Server…);
Inter process communication/distribution technology (COM/DCOM,
CORBA) , etc.

 We will use JDBC in our examples ahead – very detailed!
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Documenting Architectural Mechanisms
 Architectural Mechanisms may be treated as patterns.
 Perhaps some ‘trusted’ way or mechanism (that is, a
series of communicating classes or pattern of classes
with specific responsibilities) for accommodating a
specific requirement.
Template
Parameters
Pattern Name
Structural Aspect
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Behavioral Aspect
Documenting Architectural Mechanisms – more
 Most of these requirements are:
 Identified in analysis - like, persistence, or later as some
kind of design pattern (observer, singleton, adaptor…)
 have both a structural and behavioral aspect. (accompanied
by rules of use – as indicated in the last slide)
 Structural part - classes whose instances and their
relationships implement the mechanism
• These constitute the ‘static view.’ Often class diagram.
 Behavioral part shows how the instances collaborate to
implement the mechanism – ‘dynamic view.’
• Shown as an interaction
diagram in many cases
34
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
Documenting Architectural Mechanisms – more**
 Architect must:
 decide on the pattern,
 validate these by building (or integrating them),
and
 verify they do the job.
 The architect must consistently impose these
mechanisms on rest of system design.
 The architect must ensure that these approaches
are consistently used throughout
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Documenting the Architectural Mechanisms - more
 Most organizations have / specify a Software Architecture
Document (SAD) and a Design Guidelines Document
 organizational assets independent of the project
particulars
 These documents represents the collected reusable design
wisdom.
 In fact, a structural and behavioral model may already exist.


The Software Architecture Document (SAD) captures the
‘actual’ architectural design choices for a system based on
functional / functional requirements.
non-
The Design Guidelines is a ‘how to’ document a design not yet done. (for
your project) in a very specific way.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency:
RDBMS (design)  JDBC (implementation)
 Show both design and implementation patterns
 Persistent data objects must be mapped into a
storage structure.
 Several slides (static view - classes) upcoming:
 Design: demonstrates the pattern of use of the persistency
mechanism chosen for the RDBMS classes
 Implementation: Here in our example: JDBC.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS and JDBC (1 of 2)
 For JDBC, a client (entity) class (our job) will
work with a DBClass to read and write persistent
data for objects of that class.
 Every class that has persistent objects (e.g.
book, student, country, etc.) will have a
corresponding DBClass, and all persistent
objects from this persistent class are stored in one
single table. (This makes sense.)
 (Several ways to actually do this. See readings…)
 The DBClass - for objects of this class requiring
persistence - is responsible for accessing the
JDBC database using a DriverManager class.
 (Note: DriverManager is found in java.sql)
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS and JDBC (2 of 2)
 Once the DBClass gets a connection via Driver
Manager (found in java.sql),
 DBClass can then create SQL statements (via
Connection Class – found in java.sql)
 The SQL statement will be sent to the underlying
Statement Class object (found in java.sql) and
executed
 The Statement object “talks” the database.
 Result of the SQL query is returned in a ResultSet
object (found in java.sql).
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Summary of ‘cooperation’ for this pattern
 So we have a DBClass for the desired
persistent object – Driver Manager for
connection, Connection object to build an
SQL statement, to Statement for execution,
to Result Set for results.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Performance in Statement Class – read on your own
 For performance optimization, there is also the notion of
PreparedStatements, (which ‘inherits’ from Statement).
 The basic idea with PreparedStatement is that most of the
SQL can be precompiled, and then only the small amount of
changing data needs to be passed in for each call.
 This is a performance optimization and is not that important
from a mechanisms point of view.
In this model, we did not include PreparedStatements at all.
 Let’s walk through the mechanisms diagrams at a
high level. Do not get hung up on the mechanism
details. Will look more closely at the RDBMS
mechanism in Subsystem Design.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC
<<role>>
PersistencyClient
Roles to be filled by the
designer applying the
mechanism
(from SamplePersistency Client)
Role classes must be
built by designer.
<<role>>
PersistentClassList
(from SamplePersistentClass)
Note: UML dependency arrows.
new()
add(c: PersistentClass)
<<role>>
DBClass
1
0..*
create() : PersistentClass
read(searchCriteria : string) : PersistentClassList
update(c : PersistentClass)
delete(c : PersistentClass)
Uses DriverManager
to establish connection
Then, DBClass builds
statements which it
transmits to Connection;
Connection builds ‘real’
Statement for execution.
<<role>>
PersistentClass
(from SamplePersistentClass)
getData()
setData()
command()
new()
1
DriverManager
(from java.sql)
1
Statement
ResultSet
(from java.sql)
(from java.sql)
getString() : string
executeQuery(sql : String) : ResultSet
executeUpdate(sql : String) : int
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
getConnection(url, user, pass) : Connection
Connection
(from java.sql)
createStatement() : Statement
Connection made to
Database here and a
connection object
is returned to DBClass.
Example: Persistency: RDBMS: JDBC – continuing: DBClass
 DBClass - responsible for making objects persistent.
 It ‘understands’ the OO-to-RDBMS mapping.

This means that the DBClass possesses the behaviors
(methods) to interface with the RDBMS.
 The DBClass responsible for ‘writing’ an object to the
RDBMS and ‘reading’ an object data from the RDBMS
and building objects.
 (Note: DBClass does not directly do this; is ‘responsible.’)
 (Note: DBClass is a control class.
 (N.B. Recall: Every class whose objects are persistent
will have a corresponding DBClass.)
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC. DBClass - more
 A PersistentClassList object is returned
from a DBClass.read(). (will show ahead)
 The persistent class list object is used to set up an
aggregate of persistent class objects of type Persistent
Class. (See previous figure)
 Will contain a number of objects of the persistent class.
 Consider the need to:
 Initialize, Read, Create, Update, Delete
 (Note: The <<role>> stereotype is used for anything that
should be regarded as a placeholder for the actual design
element to be supplied by the developer.
 This convention makes it easier to apply the mechanism
because easier to recognize what the designer is to supply.)
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC: Initialize
: DBClass
:
DriverManager
(The objects to be
replaced by concrete
objects by the designer
Note that DriverManager is
applying the mechanism
available via the Java.sql API.
But the software designer
shown in yellow.) (That is,
1.
getConnection(url,
user,
pass)
must develop the DBClass
you program this. These
if it is not already available
Have the stereotype ‘role.’)
for objects of the client class.
. Initialization must occur before any persistent objects can be accessed.
. To initialize the connection to the database, DBClass must load the appropriate driver
by calling DriverManager.getConnection() operation with a URL, user, and password.
. getConnection() attempts to establish a connection to the given database URL.
. (The DriverManager attempts to select an appropriate driver from the set of registered
JDBC drivers.) DriverManager then returns a connection object.
Parameters:
url:
A database url of the form jdbc:subprotocol:subname. URL used to locate the
actual database server and is not Web-related in this instance.
user:
The database user on whose behalf the Connection is being made
password: The user's password. Returns: a Connection object to the URL
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC: Create
:
PersistencyClient
: DBClass
:
:PersistentClass
: Connection
: Statement
1. create( )
1.1. new()
1.2. getData( )
1.3. createStatement( )
1.4. executeUpdate(String)
(Lot of detail here…needed in order to better understand the persistency mechanism.)
. To create a new class, the persistency client asks the DBClass to create the new class.
. DBClass creates a reference to a PersistentClass
. DBClass creates a new object via new().
. DBClass then retrieves (getData) the ‘object’
. The DBClass ‘builds’ the object and serializes it (into a String) and then sends a message
(createStatement()) to the Connection object which returned by DriverManager earlier.
. createStatement() returns a Statement object to DBClass, which in turn sends the
executeUpdate() with the (now) string to the Statement object, which executes the SQL statement
OOAD Using the UML - Architectural Design, v 4.2
Copyright
 1998-1999will
Rational
Software,
all rights
reserved
statement,
add
the
string
to the
34 database and returns an integer indicating success (or not)
Example: Persistency: RDBMS: JDBC: Read (two info…)
 To read a persistent class object, the persistency client asks
the DBClass to read (searchCriteria…).
 The DBClass sends message to Connection object’s method createStatement()
which creates a new Statement object, as before.

 DBClass sends message to Statement.executeQuery(sql: String) with the
appropriate SQL string to ‘select’ the correct data
 executeQuery() returns a ResultSet object DBClass.

DBClass can now get the returned String retrieved via the getString() from the
ResultSet object.
But note that the data retrieved is a String - not an object or series of objects.
 The procedure that follows (see next sequence diagram) is that repeatedly
retrieve a string, create a new instance of an object, and populate this new object.
We will continue to do so until we have exhausted each string and have created a
number of persistent objects – the aggregate of persistent objects..
 The data is returned in a collection object, an instance of the PersistentClassList
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
More on Read…Very important. Read on your own!
 Note: The string ultimately passed to
executeQuery() is NOT the exact same string as
the one passed into the read() from the client.
 The DBClass will build the SQL query to retrieve the
persistent data from the database, using the criteria
passed into the read().
 This is because we do not want the client of the
DBClass to have the knowledge of the internals of the
database.
 This knowledge is encapsulated within DBClass.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC: Read
:
PersistencyClient
: DBClass
: Connection
: Statement
: ResultSet
:
PersistentClassList
:
PersistentClass
returns a
Statement object
1. read(string)
1.1. createStatement( )
The criteria used to
access data for the
persistent class
1.2. executeQuery(string)
Create a list to hold all
retrieved data
1.3. new( )
1.4. new()
Repeat these operations for
each element returned from
the executeQuery()
command.
1.5. getString( )
1.6. setData( )
The PersistentClassList is
loaded with the data retrieved
from the database.
called for each
attribute in the
class
1.7. add(PersistentClass)
Add the retrieved course offering
to the list to be returned
Note the loop! Spend some time on this diagram
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC: Update (one info)
 To update an object, the persistency client sends a
message to DBClass via update().
 The DBClass is retrieves a persistent object
 (next sequence diagram)
 DBClass obtains a Statement object returned from
Connection class when the Connection object is sent the
message createStatement().
 (See Statement object in sequence diagram in next slide)
Once the object is serialized into a String, the
executeUpdate(string) is executed via
Statement.executeUpdate(String) message.
(Remember: It is the DBClass’s job to “flatten” the
PersistentClass object and write it to the database.)
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC: Update
:
PersistencyClient
: DBClass
:
PersistentClass
: Connection
: Statement
1. update(PersistentClass)
1.1. getData( )
1.2. createStatement( )
execute SQL
statement
1.3. executeUpdate(string)
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Persistency: RDBMS: JDBC: Delete
:
PersistencyClient
: DBClass
: Connection
: Statement
1. delete(PersistentClass)
1.1. createStatement( )
execute SQL
statement
1.2. executeUpdate(string)
(not to spend too much time on this one because it will not be applied later on…)
. To delete an object, persistency client asks the DBClass to delete the object.
. DBClass is passed a new Statement object when Connection class createStatement()
is invoked.
. The Statement.executeUpdate(string) is executed (this is an SQL statement) and the
data is removed from the database.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Summary of Steps to Implement the RDBMS
Persistency Mechanism (JDBC)
 Provide access to the class libraries needed to
implement JDBC
 Import java.sql package (contains the design
elements that support the RDBMS persistency
mechanism. It will be depended upon by the
packages in which the DBClasses are placed.
 Create necessary DBClasses – one per persistent class
 Once created, incorporate DBClasses into the design
 Allocated to a package/layer – likely middleware
 Add relationships from persistency clients to the
DBClasses
More…..

OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Incorporating JDBC: Steps – Summary…
 Create/Update interaction diagrams that describe:
 Database initialization
 Persistent class access: Create, Read, Update, Delete
 Interaction diagrams used to verify all required database
functionality is supported by the design elements.
 The sample interaction diagrams provided for the
persistency architectural mechanisms during Architectural
Design should serve as a starting point for the specific
interaction diagrams defined in detailed design. (Note:
specific algorithms were not given.)
 Definition of the actual DBClasses and development of the
detailed interaction diagrams - deferred until detailed design.
OOAD Using the UML - Architectural Design, v 4.2
Copyright  1998-1999 Rational Software, all rights reserved
34
Example: Incorporating JDBC
The following changes must be made to
the Course Registration Model to
incorporate the JDBC persistency
mechanisms:
Sample
Persistency
Client Package
java.sql
DriverManager
Connection
(from java.sql)
(from java.sql)
Statement
ResultSet
(from java.sql)
(from java.sql)
Access must be provided to the java.sql package that contains the design elements that
support the RDBMS persistency mechanism.
The packages where the created DBClasses reside will need to have a dependency on
the java.sql package. (Remember, there is a DBClass for every persistent class.)
The creation of the DB classes and the decision as to where they reside in the architecture
OOAD Using the UML - Architectural Design, v 4.2
Copyright
 1998-1999
Rational Software,
all rights reserved
34 design (e.g., Use-Case and Subsystem Design).
will
be
determine
during
detailed