ooad using the uml - architectural design, v 4.2 copyright 1998-1999 rational software, all rights...

OOAD Using the UML - Architectural Design, v 4.2Copyright 1998-1999 Rational Software, all rights reserved 1

Object Oriented Analysis and Design Using the UML

Architectural Design:Look at a Lower Layer

Persistency

Modified considerably by Instructor


Objectives: Architectural Design

First several slides: on your own. Read and Study!

Explain what Design and Implementation Mechanisms are and how they map from Analysis Mechanisms

Understand what subsystems and interfaces are and what role they play in the architecture

Describe the process for identifying interfaces and subsystems

Understand the rationale and considerations that support the architectural decisions


Objectives of Architectural Design

Here, we define the pieces/parts of the system and their relationships Organizing pieces/parts into well-defined

layers Layers will have explicit dependencies;

that is, some components in a layer will have dependencies on components in (a) lower layer(s).


Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

Class Design

Subsystem Design

Use-Case Design

DesignReviewer

Architectural Design in Context – ‘about choices!’

Our workflow – a tailored version of the Analysis and Design core workflow of the RUP.Use Case Analysis: captured requirements; allocated responsibilities to analysis classes.

We have defined and decided upon our layered architecture and recorded decisions.Continuing Architectural Design, we now refine Analysis Classes into design elements (design classes, subsystems, components); Will look arbitrarily consider components in the lower architectural layers. We will allocate these design elements to packages and layers in the architecture.


Information on Associated Documents The Use Case Model influences the Architectural Design

activities. (Recall: RUP is ‘Use Case Driven…’)

The Design Model contains the use case realizations developed during Use Case Analysis. Equivalently, the design model will contain the class

diagrams and interaction diagrams that are need to ‘realize’ (to accommodate) the use cases.

This Supplementary Specifications Document includes analysis mechanisms and non-functional requirements identified during architectural analysis. (see deliverables) There may very well be additional documents for local

conventions and procedures / regulations

These activities support the best practice that the architecture be use-case driven.


Class Name

Package Name

Review: Class and Package

What is a class? A description of a set of objects that share the same

responsibilities, relationships, operations, attributes, and semantics. (an abstraction; a template)

What is a package? A general purpose mechanism for organizing

elements into groups A model element which can contain other model

elements Later, we will contrast these ‘vanilla packages’ with

subsystems


Foundation

Classesglobal

Global Packages

Certain packages are used by all other packages These packages are marked global

Probably best to try to avoid global packages as they tend to be misused and cause havoc with layering, since they basically cut across layers.Nothing in UML prevents us from using Global Packages, however, only introduced now in architectural design. May see some as <<utility>>.

If global packages used, dependency relationships need not be drawn. ‘Implied dependency’ Also, they can significantly reduce the clutter on class diagrams.

Examples: Foundation classes (lists, queues, etc.) Error Handling classes; math libraries; Utilities; third-party libraries.


Architectural Design Topics

Key Concepts Design and Implementation Mechanisms

How to address several non-functional requirements (NFR)

• Will look at persistence and security. Design Classes and Subsystems

We now need to look at design and implementation mechanisms.How they map from analysis mechanismsWill provide abstract patterns of behavior for the mechanisms which will use in later design activities.Goal: let us produce designs that incorporate these mechanisms.


Analysis, Design, and Implementation Mechanisms We know about Analysis Mechanisms – NFR… A number of NFR (in Design) require progressing to the

‘next stage’ by selecting some specific technology. During Implementation, these ‘general technologies’ (like,

RDBMS) which might be used to support a NFR then are mapped into quite specific technologies (like Oracle).

Choice of Design Mechanism is constrained by what is available in the implementation environment. If we are using relational databases and have one or

two ‘on site,’ then this is a real constraint and influences how we accommodate such requirements.

The mechanism map must be navigable in both directions so that it is easy to determine client classes (one’s the developer develops) when changing implementation mechanisms.


Design/Implementation Mechanisms -accommodating NFR

Analysis Design Implementation

Remote Method Invocation (RMI)

Persistency

Analysis

Mechanism

(Conceptual)

Design

Mechanism

(Concrete)

Implementation

Mechanism

(Actual)

OODBMS

RDBMS JDBC

ObjectStore

Java 1.2 from Sun

Legacy Data

New Data

Distribution

Persistency

A ‘what’ was needed to solve a problem:


Design Mechanisms

A design mechanism assumes ‘some’ details of the implementation environment, but it is not tied to a specific implementation (as is an implementation mechanism).

For ‘persistency’ our mechanisms might include: RDBMS, OODBMS, in-memory storage, …


Implementation Mechanism

An implementation mechanism is used during the implementation process.

They are bound to a certain technology, implementation language, vendor, etc. Examples include: the actual programming language,

COTS products, database (Oracle, Sybase); inter process communication/distribution technology in use (COM/DCOM, CORBA) , etc.

We will use JDBC in our examples ahead – they are detailed!

How do we capture these, though…


Architectural Mechanisms can be treated as patterns (i.e., stereotyped parameterized collaboration) (Will discuss patterns later…)

Documenting Architectural Mechanisms

Structural Aspect Behavioral Aspect

Pattern Name

TemplateParameters

Rose uses a stereotyped Use Case to show a mechanismUse Case might be Update Inventory Database…


Documenting Architectural Mechanisms – more** Mechanism have both a structural and behavioral aspect.

Structural part (classes whose instances implement the mechanism and their relationships) constitute the ‘static view.’

Behavioral part shows how the instances collaborate to implement the mechanism – dynamic view.

Role of architect is to decide upon and validate mechanisms by building (or integrating them), and verifying that they do the job. (In same was as analysis classes and interaction diagrams do for scenarios)

The architect must then consistently impose these mechanisms (patterns) for all developers to use.

So, for EACH architectural mechanism, the architect will normally have both a static and a dynamic view, accompanied by rules of use. Here, we are looking at persistency.


Documenting Architectural Mechanisms - more The Software Architecture Document (SAD) captures the

‘actual’ architectural design choices for a system based on non-functional / functional requirements. (Design Decisions)

The Design Guidelines is a ‘how to’ document guidelines for adesign not yet done. (for your project)

In many organizations, the design guidelines will exist as an organization asset independent of the project

particulars Represents the collected reusable design wisdom. In fact, a structural and behavioral model already exists.

The Software Architecture Document is the architectural designrepresentation (or at least the most significant parts of it), theDesign Guidelines cover how to do design, in a very specific, not just conceptual, way.


Example: Persistency: RDBMS: JDBC – Start… Example of Persistency - implemented with both

design and implementation mechanisms:

Remember, persistent data objects must be mapped into a storage structure. In an OODBMS, persistent parts are mapped one-to-one in the database.

We are going to look at several slides (static view) that demonstrate the pattern of use of the persistent mechanism chosen for the RDBMS classes in our example: JDBC.


Example: Persistency: RDBMS: JDBC – Design Guidelines For JDBC, a client class will work with a

DBClass to readand write persistent data.

Every class that is persistent will have a corresponding DBClass. (show and return) and all persistent objects from a persistent class are stored in one single table. (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 the DriverManager class.

(show and tell) (note: DriverManager is found in java.sql)


Example: Persistency: RDBMS: JDBC – Design Guidelines

Once a database Connection is opened, the DBClass can then create SQL statements that will be sent to the underlying RDBMS and executed using the Statement class. (go and return)

The Statement object is what “talks” to the database.

The result of the SQL query is returned in a ResultSet object. (go and return)


Performance in Statement Class – Supplementary Info…

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. Thus, for 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.


Example: Persistency: RDBMS: JDBC

ResultSet

getString() : string

(from java.sql)

Connection

createStatement() : Statement

(from java.sql)

Statement

executeQuery(sql : String) : ResultSetexecuteUpdate(sql : String) : int

(from java.sql)

DriverManager

getConnection(url, user, pass) : Connection

(from java.sql)

DBClass

create() : PersistentClassread(searchCriteria : string) : PersistentClassListupdate(c : PersistentClass)delete(c : PersistentClass)

<<role>>

1

1

PersistencyClient(from SamplePersistency Client)

<<role>>

PersistentClass

getData()setData()command()new()

(from SamplePersistentClass)

<<role>>

PersistentClassList

new()add(c: PersistentClass)

(from SamplePersistentClass)

<<role>>

0..*1

0..*1

Roles to be filled by the designer applying the

mechanism

Uses DriverManager to establish connectionThen, DBClass builds statements which it transmits to Connection;Connection builds ‘real’Statement for execution.

Role classes must be built by designer.

Connection made toDatabase here and returned to DBClass.


Example: Persistency: RDBMS: JDBC - continuing The DBClass is class responsible for

making another class instance (object) persistent.

It understands the OO-to-RDBMS mappingand has the behavior to interface with theRDBMS.

The DBClass ‘writes’ the object to the RDBMS and ‘reads’ the object data from the RDBMS and builds the object (via Statement object – note dependency!)

N.B. again: Every class whose objects are persistent will have a corresponding DBClass.


Example: Persistency: RDBMS: JDBC - continuing

The PersistentClassList is used to return a set of persistent objects as a result of a database query (e.g., DBClass.read()). Ultimately, the results of a, say, retrieval will be a set of

objects that is an aggregate – PersistentClassList of PersistentClass Objects.

The <<role>> stereotype was 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 it is easier to recognize what the designer is to supply.


Example: Persistency: RDBMS: JDBC: Initialize : DBClass :

DriverManager

1. getConnection(url, user, pass)

. Initialization must occur before any persistent class can be accessed.

. To initialize the connection to the database, the DBClass must load appropriate driver by calling the DriverManager.getConnection() operation with a URL, user, and password. . getConnection() attempts to establish a connection to the given database URL.

(Note dependency arrow). The DriverManager attempts to select an appropriate driver from the set of registered JDBC drivers. Parameters: url: A database url of the form jdbc:subprotocol:subname. This URL used to locate the actual database server (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 to the URL

(The objects to be replaced by concrete objects by the designer applying the mechanism shown in yellow.) (That is, you program this.)

Note the life lines and the focus!


Example: Persistency: RDBMS: JDBC: Create : Connection : Statement :

PersistencyClient : DBClass :

PersistentClass

1. create( )

1.1. New()

1.3. createStatement( )

1.4. executeUpdate(String)

1.2. getData( )

. To create a new class, the persistency client asks the DBClass to create the new class. . The DBClass creates a new instance of PersistentClass with default values …. DBClass then retrieves the ‘object’ (with default values only) . The DBClass sends message to Connection class where a new Statement is created (arguments not shown above…; just cryptic here…) and returned to DBClass. . The DBClass then sends the Statement containing the object data, … to the Statement object, which talks to the database and sends back a ‘return code.’


Example: Persistency: RDBMS: JDBC: Read (two info…) To read a persistent class, the persistency client asks

DBClass to read.

The DBClass sends message to Connection class which creates a new Statement using the createStatement() operation and returns this statement ot DBClass.

The DBClass sends this ‘string’ (now) to Statement object via executeQuery(String)

Statement talks to the database via the string to cause the query to be executed. Retrieved data is captured in a ResultSet object.

Before this data is accessed by a client needing the data, DBClass must create new instance of PersistentClass and populate with the retrieved data.

The data is returned in a collection object, an instance of the PersistentClassList class.


More on Read…

Note: The string passed to executeQuery() (in Statement object) is NOT the exact same string as the one passed into the read() in DBClass. The DBClass will build the SQL query to retrieve

the persistent data from the database, using the criteria passed into the read().

We do not want the client of the DBClass to have the knowledge of the internals of the database to create a valid query.

This knowledge is encapsulated within DBClass.


Example: Persistency: RDBMS: JDBC: Read : Connection : Statement : ResultSet :

PersistencyClient : DBClass :

PersistentClass :

PersistentClassList

1. read(string)


1.2. executeQuery(string)

1.4. new()

1.5. getString( )

1.6. setData( )

called for each attribute in the class

returns a Statement

1.3. new( )Create a list to hold all retrieved data

1.7. add(PersistentClass)

Add the retrieved course offering to the list to be returned

Repeat these operations for each element returned from the executeQuery() command.

The PersistentClassList is loaded with the data retrieved from the database.

The SQL statement built by the DBClass using the given criteria is passed to executeQuery()The criteria used to

access data for the persistent class

Spend some time on this diagram

Remember, it is theStatement thatTalks to the dataabase.


Example: Persistency: RDBMS: JDBC: Update (one info)

To update a class, the persistency client asks the DBClass to update.

The DBClass retrieves data from the given PersistentClass object, andcreates a new Statement using the Connection class, createStatement()operation. (assumes object is ‘in’ PersistentClass and changes have been made.)

DBClass builds a string from the Statement and sends this to the Statement object for execution.

Statement object talks to the database (executeUpdate (String)) and the database is updated with the new object data.

Remember: It is the DBClass’s job to “flatten” the PersistentClass and write it to the database. That is why the data must be retrieved from the givenPersistentClass before creating the SQL Statement…

Note: In the above mechanism, the PersistentClass must provide accessroutines for all persistent data so that DBClass can access them. Thisprovides external access to certain persistent attributes that would haveotherwise have been private. This is a price you have to pay to pull thepersistence knowledge out of the class that encapsulates the data.


Example: Persistency: RDBMS: JDBC: Update : DBClass :

PersistencyClient :

PersistentClass : Connection : Statement

1. update(PersistentClass)


1.1. getData( )

1.3. executeUpdate(string)

execute SQL statement


Example: Persistency: RDBMS: JDBC: Delete

: PersistencyClient

: DBClass : Connection : Statement

1. delete(PersistentClass)


1.2. executeUpdate(string)

execute SQL statement

(not to spend too much time on this one because it will not be applied later on…)

. To delete an object, the persistency client asks the DBClass to delete the PersistentClass.

. The DBClass creates a new Statement using the Connection class createStatement()

operation.

. The Statement is executed via the executeUpdate(string) and the data is removed

from the database.


Deferred

Summary of Steps to Implement the RDBMS Persistency Mechanism (JDBC)

Provide access to the class libraries needed to implement JDBC (Developers responsible for ‘yellow.’) 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 the necessary DBClasses One DBClass per persistent class

Once created, incorporate DBClasses into the design They must be allocated to a package/layer – likely a

middleware layer – but maybe not. Then, add relationships from persistency clients to the

DBClasses More…..


Incorporating JDBC: Steps – Summary… Create/Update interaction diagrams that describe:

Database initialization Persistent class access: Create, Read, Update, Delete

The interaction diagrams provide a means to verify that 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.)

In Architectural Design, we make sure that the architecture has the necessary infrastructure (i.e., that we have access to the class libraries that are needed to implement JDBC).

The definition of the actual DBClasses and the development of the detailed interaction diagrams is deferred until detailed design (coming real soon!).


java.sql

ResultSet(from java.sql)

Connection(from java.sql)

Statement(from java.sql)

DriverManager(from java.sql)

Sample Persistency

Client Package

Example: Incorporating JDBC

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 RDBMS persistent class.)The creation of the DB classes and the decision as to where they reside in the architecture will be determine during detailed design (e.g., Use-Case and Subsystem Design).

The following changes must be made to the Course Registration Model to incorporate the JDBC persistency mechanisms:

T