1. Object Oriented Analysis and Design Using the UML
OOADv4.2 Instructor Notes
Object Oriented Analysis and Design Using the UML
Architectural Design:
Look at a Lower Layer
Persistency
Modified considerably by Instructor
Module 8 - Architectural Design

2. Objectives: Architectural Design
OOADv4.2 Instructor Notes
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
In the discussion and the exercise, we will give the students the architectural mechanism map and the architectural layers. This was necessary as part of the scoping effort.
Module 8 - Architectural Design

3. 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).

4. Architectural Design in Context – ‘about choices!’
OOADv4.2 Instructor Notes
Architectural Design in Context – ‘about choices!’
Architectural Design is where the “filtering and factoring” is done before setting the designers loose on Use-Case Design.
Keep in mind that the focus of all architectural activities is on the “big picture”.
Architectural Design is all about decisions.
In Architectural Design, the Logical View chapter of the “Design Handbook” is developed.
Architectural Design in this course encompasses the following RUP Analysis and Design workflow activities: - Identify Design Mechanisms - Identify Design Elements - Incorporate Existing Design Elements. They are covered in a single module here as they are conceptually a single activity (all dealing with the Logical View of the architecture), and they are not covered in the same level of detail as they are in RUP.
Architectural
Analysis
Architectural
Describe
Review the
Describe
Architecture
Architecture
Architect
Design
Concurrency
Distribution
Reviewer
Subsystem Design
Use-Case
Analysis
Use-Case
Designer
Design
Review the
Design
Design
Reviewer
Class Design
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.
Module 8 - Architectural Design

5. 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.

6. Review: Class and Package
OOADv4.2 Instructor Notes
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
Now let’s review some key terms.
Classes and Packages were introduced in the Introduction to Object Orientation module.
Class Name
Package Name
Module 8 - Architectural Design

7. OOADv4.2 Instructor Notes
Global Packages
Certain packages are used by all other packages
These packages are marked global
There is not a specific reference to global packages in the UML Semantics document, but the UML does not seem to preclude them.
It is best to try to figure out a way to avoid global packages. They tend to be misused and they cause havoc with layering (since they basically cut across layers).
Global packages are not introduced until Architectural Design as they are generally not needed until Design time (and should really be avoided altogether).
Foundation
Classes
global
Examples: Foundation classes
(lists, queues, etc.) Error
Handling classes; math
libraries; Utilities; third-party
libraries.
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.
Module 8 - Architectural Design

8. Architectural Design Topics
OOADv4.2 Instructor Notes
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 mechanisms
Will provide abstract patterns of behavior for the mechanisms which will use in later
design activities.
Goal: let us produce designs that incorporate these mechanisms.
Module 8 - Architectural Design

9. 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.

10. Design/Implementation Mechanisms -accommodating NFR
OOADv4.2 Instructor Notes
Analysis mechanisms were identified in Architectural Analysis,
In a Design Mechanism, some specific technology is chosen, whereas with Implementation mechanisms, a VERY specific technology is chosen. The design mechanisms emerge from analysis mechanisms, and are constrained based on what is possible to achieve in the implementation environment. One can think of design mechanisms as refined in a "bottom-up" manner, although they are initially derived from the need for analysis mechanisms (which are found “top-down”).
You may have more than one design mechanism associated with a client class as a compromise between different characteristics (e.g., fast access during application execution, but needs to be persistent).
The mechanism map must be navigable in both directions, so that it is easy to determine client classes when changing implementation mechanisms.
In Architectural Design, the Design and Implementation mechanisms are not only defined. “Patterns for use” are also provided. We will look at some specific examples on the following slides.
As stated in Architectural Analysis, Anytime anyone has issues with the included mechanisms (i.e., persistence, security, etc.), emphasize that these are just one set of choices. On your project, your architect may pick others, so your design will be different.
Emphasize to the students that you will only be covering the JDBC mechanism in this course (the others can be found in the appendix).
Analysis
Design
Implementation
Remote Method Invocation (RMI)
Persistency
Mechanism
(Conceptual)
(Concrete)
(Actual)
OODBMS
RDBMS
JDBC
ObjectStore
Java 1.2 from Sun
Legacy Data
New Data
Distribution
A ‘what’ was needed to
solve a problem:
Module 8 - Architectural Design

11. 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, …

12. 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…

13. Documenting Architectural Mechanisms
OOADv4.2 Instructor Notes
Documenting Architectural Mechanisms
Architectural Mechanisms can be treated as patterns (i.e., stereotyped parameterized collaboration) (Will discuss patterns later…)
One way to document the mechanisms in Rose is to create an “Architectural Mechanisms” package in the Design Model package in the Logical View. Each mechanism could be represented by a <<mechanism>> stereotyped use case. The class and interaction diagrams for the mechanism could then be attached to the <<mechanism>> use case.
There is also a need to define which elements are concrete and which are roles that should be filled by the designer as they apply the mechanism. One way to model this is to use the <<role>> stereotype on anything (class, operation, relationship, attribute) that should be regarded as a placeholder for the actual design element (in Rose you could also use a different color). Such a convention makes it easier to apply the mechanism because it is easier to recognize what the designer is to supply. The concrete classes supporting the mechanisms will reside in the actual Design Model layers. The <<role>> classes will reside within the Architectural Mechanisms package (or sub-packages).
This is the approach that we have taken in the course models.
Note: Rose does not yet support UML colaborations. Thus, you cannot draw the dotted ellipse shown in the top part of this diagram. Workaround: Use a stereotyped use case.
Rationale for mechanisms in the Design Guidelines instead of the Architecture Document:: The Design Guidelines contain explicit rules for the Designers, and how to use the chosen implementation mechanisms are definitely explicit rules. The architectural mechanism choices (the map, shown earlier) belongs in the Architecture Document.
Rose uses a stereotyped Use Case to show
a mechanism
Use Case might be Update Inventory Database…
Pattern Name
Template Parameters
Structural Aspect
Behavioral Aspect
Module 8 - Architectural Design

14. 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.

15. 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 a
design 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 design
representation (or at least the most significant parts of it), the
Design Guidelines cover how to do design, in a very specific,
not just conceptual, way.

16. 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.

17. 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)

18. 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)

19. 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.

20. Example: Persistency: RDBMS: JDBC
OOADv4.2 Instructor Notes
Example: Persistency: RDBMS: JDBC
<<role>>
Roles to be filled by the designer applying the mechanism
PersistencyClient
<<role>>
Role classes must be
built by designer.
(from SamplePersistency Client)
PersistentClassList
The classes to be replaced with concrete classes by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals).
With this approach, the OO model is separable from the DBMS model and the class does not know it is persistent (it can be reused in applications where it’s objects are not persistent).
For performance optimization, there is also the notion of PreparedStatements (which inherit from Statement). The basic idea with a PreparedStatement is that most of the SQL can be pre-compiled, 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 use PreparedStatements at all. For more information, see the JDBC specifications.
Walk the students through the mechanism diagrams at a high-level. Do not let them get hung up on the mechanism details. We’ll cover how the RDBMS mechanism is applied in Subsystem Design.
(from SamplePersistentClass)
new()
add(c: PersistentClass)
<<role>>
DBClass 1 1
0..*
0..*
create() : PersistentClass
Uses DriverManager
to establish connection
Then, DBClass builds
statements which it
transmits to Connection;
Connection builds ‘real’
Statement for execution.
<<role>>
read(searchCriteria : string) : PersistentClassList
PersistentClass
update(c : PersistentClass)
(from SamplePersistentClass)
delete(c : PersistentClass) 1
getData()
setData()
command()
new()
DriverManager
(from java.sql) 1
getConnection(url, user, pass) : Connection
Connection made to
Database here and
returned to DBClass.
Statement
executeQuery(sql : String) : ResultSet
executeUpdate(sql : String) : int
(from java.sql)
Connection
ResultSet
(from java.sql)
(from java.sql)
createStatement() : Statement
getString() : string
Module 8 - Architectural Design

21. Example: Persistency: RDBMS: JDBC - continuing
The DBClass is class responsible for
making another class instance (object) persistent.
It understands the OO-to-RDBMS mapping
and has the behavior to interface with the
RDBMS.
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.

22. 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.

23. Example: Persistency: RDBMS: JDBC: Initialize
OOADv4.2 Instructor Notes
Example: Persistency: RDBMS: JDBC: Initialize
(The objects to be
replaced by concrete
objects by the designer
applying the mechanism
shown in yellow.) (That is,
you program this.)
: DBClass :
DriverManager
This diagram is one of the dynamic representations of the chosen RDBMS persistency mechanism, JDBC.
The objects to be replaced by concrete objects by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals).
Possible question from the students: “Every DBClass must establish a separate Connection? Since there’s one DBClass per persistent class, that’s a lot of connections. I would have expected one connection that everyone shares.”
Answer: Depends how many persistent classes you have to access. Each DBClass could create it’s own connection (as is done in this example) or a connection could be passed in.
Don’t spend too much time on this diagram as it will not be applied in later modules. However, it is needed in order to better understand the persistency mechanism.
Note: Explicit shutdown of the database is not required with the RDBMS mechanism.
Note the life lines and
the focus!
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
Module 8 - Architectural Design

24. Example: Persistency: RDBMS: JDBC: Create
OOADv4.2 Instructor Notes
Example: Persistency: RDBMS: JDBC: Create :
: DBClass :
: Connection
: Statement
PersistencyClient
PersistentClass
Don’t spend too much time on this diagram as it will not be applied in later modules. However, it is needed in order to better understand the persistency mechanism.
The objects to be replaced by concrete objects by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals).
1. create( )
1.1. New()
1.2. getData( )
1.3. createStatement( )
1.4. executeUpdate(String)
. 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.’
Module 8 - Architectural Design

25. 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.

26. 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.

27. Example: Persistency: RDBMS: JDBC: Read
OOADv4.2 Instructor Notes
Example: Persistency: RDBMS: JDBC: Read :
: DBClass
: Connection
: Statement
: ResultSet : :
PersistencyClient
PersistentClassList
PersistentClass
Spend the most time on this interaction diagram, as this is the one that will be applied in Subsystem Design.
The objects to be replaced by concrete objects by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals).
1. read(string)
returns a
The SQL statement
built by the DBClass
using the given
criteria is passed to
executeQuery()
Remember, it is the
Statement that
Talks to the dataabase.
Statement
1.1. createStatement( )
The criteria used to
access data for the
persistent class
1.2. executeQuery(string)
Create a list to hold all
1.3. new( )
retrieved data
1.4. new()
Repeat these operations for
each element returned from
1.5. getString( )
the executeQuery()
called for each
command.
attribute in the
1.6. setData( )
class
The PersistentClassList is
loaded with the data retrieved
from the database.
1.7. add(PersistentClass)
Add the retrieved course offering
to the list to be returned
Spend some time on this diagram
Module 8 - Architectural Design

28. 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, and
creates 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 given
PersistentClass before creating the SQL Statement…
Note: In the above mechanism, the PersistentClass must provide access
routines for all persistent data so that DBClass can access them. This
provides external access to certain persistent attributes that would have
otherwise have been private. This is a price you have to pay to pull the
persistence knowledge out of the class that encapsulates the data.

29. Example: Persistency: RDBMS: JDBC: Update
OOADv4.2 Instructor Notes
Example: Persistency: RDBMS: JDBC: Update :
: DBClass :
: Connection
: Statement
Don’t spend too much time on this diagram as it will not be applied in later modules. However, it is needed in order to better understand the persistency mechanism.
The objects to be replaced by concrete objects by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals).
PersistencyClient
PersistentClass
1. update(PersistentClass)
1.1. getData( )
1.2. createStatement( )
1.3. executeUpdate(string)
execute SQL
statement
Module 8 - Architectural Design

30. Example: Persistency: RDBMS: JDBC: Delete
OOADv4.2 Instructor Notes
Example: Persistency: RDBMS: JDBC: Delete :
: DBClass
: Connection
: Statement
Don’t spend too much time on this diagram as it will not be applied in later modules. However, it is needed in order to better understand the persistency mechanism.
The objects to be replaced by concrete objects by the designer applying the mechanism are shown in yellow (but this does not show up in the black and white manuals).
PersistencyClient
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, 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.
Module 8 - Architectural Design

31. Summary of Steps to Implement the RDBMS Persistency Mechanism (JDBC)
OOADv4.2 Instructor Notes
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…..
The italicized text reflects the RDBMS incorporation design decisions made for the current design.
Note: On the presented slide, the italicized text is also yellow, but this does not show up in the back-and-white manuals.
Deferred
Module 8 - Architectural Design

32. 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!).

33. Example: Incorporating JDBC
OOADv4.2 Instructor Notes
Example: Incorporating JDBC
Sample Persistency Client Package
The changes made to support the mechanism are shown in yellow (but this does not show up in the black and white manuals).
Note: If your students are interested in the OODBMS (ObjectStore) mechanism, the slides found in the Additional Information appendix, ObjectStore section, first part, should be inserted after this slide.
The following changes must be
made to the Course Registration
Model to incorporate the JDBC
persistency mechanisms:
java.sql
DriverManager
(from java.sql)
Connection
(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 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). T
Module 8 - Architectural Design