Payroll Arch Handbk RPT

Rational Software
Payroll Architecture Handbook
Version 2003
Mastering OOAD with UML Issue: 2003
Payroll Architecture Handbook Issue Date: 2/7/03
payroll_arch_handbk_rpt.doc
Revision History
Date Issue Description Author
9/5/2000 V2000 Generation for beta Shawn Siemers
10/2/2000 V2000 Final release Shawn Siemers
01/14/2003 V2003 Final Release Alex Kutsick
Confidential Rational Software, 2003 Page 2 of 33

Payroll Architecture Handbook Issue Date: 2/7/03
Table of Contents
1. Description 5
2. Architectural Mechanisms 5
2.1 Analysis Mechanisms 5
2.2 Analysis-to-Design-to-Implementation Mechanisms Map 5
2.3 Implementation Mechanisms 6
2.3.1 Security 6
2.3.2 Persistency - RDBMS - JDBC 10
2.3.3 Persistency - OODBMS - ObjectStore 17
2.3.4 Distribution - RMI 25
3. Logical View 28
3.1 Architectural Analysis 28
3.1.1 Upper-Level Layers 28
3.1.2 Upper-Level Layer Dependencies 28
3.2 Architectural Design 28
3.2.1 Incorporating ObjectStore 28
3.2.2 Architectural Layers and Their Dependencies 29
3.2.3 Packages and Their Dependencies 30
4. Process View 32
4.1 Processes 32
4.2 Design Element to Process Mapping 32
5. Deployment View 32
5.1 Nodes and Connections 32
5.2 Process-to-Node Map 32

Payroll Architecture Handbook Issue Date: February 2003
Payroll Architecture Handbook

1. Description
This document supplements the course material for the Payroll Exercise used in the Object-Oriented Analysis and
Design Using the UML course. It provides the architectural givens that support the development of the Payroll
System design model during the course exercises.
This is because the OOAD course concentrates on demonstrating how architecture affects the design model. OOAD
is NOT an architecture course. The OOAD course gives the students an appreciation of what an architecture is and
why it is important.
In some sections of this document, the architecture is represented textually. The students, as part of the exercises
throughout the course, will generate the associated UML diagrams. Thus, for the UML representation of the
architecture, see the Payroll Exercise Solution.
Note: A SUBSET OF THE PAYROLL SYSTEM IS PROVIDED. Concentration is on the elements needed to
support the Login, Maintain Timecard and Run Payroll use cases.
2. Architectural Mechanisms
2.1 Analysis Mechanisms
Persistency: A means to make an element persistent (i.e., exist after the application that created it ceases to exist).
Distribution: A means to distribute an element across existing nodes of the system.
Note: For this course, it has been decided that the business logic will be distributed.
Security: A means to control access to an element.
Legacy Interface: A means to access a legacy system with an existing interface.
2.2 Analysis-to-Design-to-Implementation Mechanisms Map
Analysis Mechanism Design Mechanisms Implementation Mechanisms

Persistency OODBMS (new data) ObjectStore
Persistency RDBMS (data from JDBC to Ingres
legacy database)
Distribution Remote Method Java 1.1 from Sun
Invocation (RMI)
Security Reverse Engineered Secure.java
and UserContextRemoteObject
components
Legacy Interface
Note: Remote Method Invocation (RMI) is a Java-specific mechanism that allows client objects to invoke
operations on server objects as though they were local. Native Java RMI comes with Sun's Java 1.1.

2.3 Implementation Mechanisms
2.3.1 Security
2.3.1.1 Static View

Security
LoginForm
(from GUI Framework)
MainApplicationForm
(f ro m GUI Fra mework) + open()
+ enterUserName()
+ start() + validateUserIDPassword() : boolean
1 0..1
+ setupSecurityContext() + enterPassword()
+ displayAvailOperations() + logInUser()
1 + setupSecurityContext()
+ getUserContext() : ISecureUser
0..1
0..1
<<Interface>> 0..1 UserSecurityContext
ISecureUser (f rom Se curity Man ager)
(from Secure Interfaces)
+ setAccess (toData : SecureData, ac cess : Sec urityAcc ess)
+ setAccess(toData : ISecureData, access : SecurityAccess) + getAccess (toData : SecureData) : SecurityAcces s
+ getAccess(toData : ISecureData) : SecurityAccess + getUserId() : UniqueId
+ getUserId() : UniqueId + UserSecurityContext(userId : UniqueId)
+ new(forUser : UserID) + checkInternalTables()
<<Interface>>
Security Acc ess
ISecureData
+ isReadable() : Boolean
+ getUniqueId() : UniqueId
+ isWriteable() : Boolean
+ isDeleteable() : Boolean
UniqueId + makeReadable()
(from Secure Interfaces) + makeWriteable()
<<role>> + makeDeleteable()
SampleSecureClass + generat e() : UniqueId + new()
+ asSt ring() : String
+ getUniqueID() + UniqueId(value : String)
2.3.1.1.1 Class Descriptions

ISecureData : Analysis Mechanisms:
- Security
SecurityAccess : Analysis Mechanisms:

- Security
SampleSecureClass :
UserSecurityContext : Analysis Mechanisms:

- Security
UniqueId : Analysis Mechanisms:

- Security
MainApplicationForm : Requirements Traceability:

- Usability: The desktop user-interface shall be Windows 95/98 compliant.
ISecureUser : Analysis Mechanisms:

- Security
LoginForm : Analysis Mechanisms:

- Security
Requirements Traceability:
- Usability: The desktop user-interface shall be Windows 95/98 compliant.

2.3.1.2 Dynamic View

Secure User Set-Up
Any User : : LoginForm : ISecureUs er

MainApplicationForm
1. start( )
1.1. open( )
2. enterUserName( )
We did not expand on
3. enterPas sword( ) validation since it was a
reverse engineered
4. logInUser( ) component
4.1. validateUserIDPassword( )
[ login s uccessful ]
4.2. setupSecurityContext( )
4.2.1. new(UserID)
The
5. setupSecurityContext( ) MainApplicationForm
retains the secure
Display the 5.1. getUserContext( ) user context for later
operations/functions processing by the
that the application user.
provides. 6. close( )
7. displayAvailOperations( )

Secure Data Access
Secure : :
Clien SecurityAcce
After retrieving an object that

SecureData interface, the Secure
Client should retrieve the security 1.
information for the secure object
for the current user and compare 2.
make sure the current user
view/edit/delete the AND/O
3.
AND/O
4.

2.3.2 Persistency - RDBMS - JDBC
2.3.2.1 Static View

Persistency - JDBC
For JDBC, a client will work with a DBClass to read and write persistent data.
The DBClass is responsible for accesing the JDBC database using the
DriverManager class. 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. The results of the SQL query is
returned in a ResultSet class object.
<<role>>
PersistentClassList
(from SamplePersistentClass)
<<role>>
PersistencyClient
(from SamplePersistency Client) + new()
+ add(c : PersistentClass)
1
0..*
<<role>>
<<role>>
PersistentClass
DBClass
+ create() : PersistentClass + getData()

+ read(searchCriteria : string) : PersistentClassList + setData()
+ update(c : PersistentClass) + command()
+ delete(c : PersistentClass) + new()
1
DriverManager
1 (from java.sql)
Connection
(from java.sql) + getConnection()
+ createSt atement ()
Statement
(from java.sql)
+ executeQuery()
Result Set
(from java.sql)
+ executeUpdate()
+ get String()


PersistencyClient : An example of a client of a persistent class.
PersistentClass : An example of a class that's persistent.
PersistentClassList :
Statement : The class used for executing a static SQL statement and obtaining the results produced by it.
SQL statements without parameters are normally executed using Statement objects.
DBClass : A sample of a class that would be responsible for making another class persistent.
Every Class that's persistent will have a corresponding DBClass (e.g., Student will have a DBStudent class).
With an RDBMS, you need a mapping of objects/classes to tables, and you must recreate the
(association/aggregation) structures. DBClass is a database interface class which understands the OO-to-RDBMS
mapping and has the behavior to interface with the RDBMS. This database interface class is used whenever a
persistent class needs to be created, accessed, or deleted. The database interface class flattens the object and writes
it to the RDBMS and reads the object data from the RDBMS and builds the object.
Connection : A connection (session) with a specific database. Within the context of a Connection, SQL statements
are executed, and results are returned.
ResultSet : A ResultSet provides access to a table of data. A ResultSet object is usually generated by executing a
Statement.
DriverManager : The basic service for managing a set of JDBC drivers.


JDBC RDBMS Read
JDBC RDBMS Read
: : DBClass : Connection : Statement : ResultSet : :

Persistenc yClient PersistentClassList PersistentClass
1. read(string) returns a The SQL statement

Statement built by the DBClass
1.1. creat eStat ement( ) using the given
criteria is passed to
The criteria used to executeQuery()
access data for the 1.2. executeQuery(string)
persistent class Create a list to hold all
retrieved data
1.3. new( )
Repeat these operations for 1.4. new( )

eac h element returned from
t he execut eQuery() 1.5. getString( )
command. called for each
attribute in the
The Persistent ClassList is 1.6. setData( ) class
loaded with the dat a retrieved
from the dat abase. 1.7. add(PersistentClass)
Add the retrieved course offering

to the list to be returned
To read a class, the client asks the DBClass to read. The DBClass creates a
new statement using the Connection class createStatement() operation. The
statement is executed and the data is returned in a ResultSet object. The
DBClass then creates a new instance of the PersistentClass and populates
with the retrieved data. The data is returned in a collection object, an instance
of the PersistentClassList class.

JDBC RDBMS Update
JDBC RDBMS
: : DBClass : : Connection : Statement

PersistencyClien PersistentClas
1. Retrieve the data to be

1.1. getData( ) written to the database,
so it can be
1.2. createStatement(
execute SQL
statement
1.3.
To update a class, the client asks the DBClass to update. The DBClass retriev
from the existing PersistentClass object, and creates a new Statement using
connection class createStatement() operation. Once the Statement is built, the
executed, and the database is updated with the new data from the

JDBC RDBMS Create
JDBC RDBMS Create
: : DBClass : : Connect ion : Statement

PersistencyClient PersistentClass
1. create( )
1.1. new( )
1.2. getData( )
1.3. createStatement( )
1.4. executeUpdate(string)
To create a new class, the client asks the DBClass to create the new class. The
DBClass creates a new instance of Persistent Class with default values. The
DBClass then creates a new Statement using the Connection class
createStatement() operation. The statement is executed and the data is inserted
into the database.

JDBC RDBMS Delete
JDBC RDBMS Delete
: : DBClass : Connec tion : Stat ement

PersistencyClient
1. delete(PersistentClass)
1.1. createStat ement( )

execute SQL
statement
1.2. executeUpdate(string)
To delete a class, the client asks the DBClass to delete a specific

class instance. The DBClass creates a new statement using the
Connection class createStatement() operation and formulates the
correct SQL statement for the object instance that's passed in. The
statement is executed and the data is removed from the database.

JDBC RDBMS Initialize
JDBC RDBMS Initializ e
: DBClass :
DriverManager
1. getConnection(url, user, pass)
To initialize the connection, the DBClass must load the

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. 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
user - The database user on whose behalf the Connection
is being made
password - The user's password
Returns a Connection to the URL

2.3.3 Persistency - OODBMS - ObjectStore
2.3.3.1 Static View

Persistency - ObjectStore OODBMS
Clients interface with the SampleDBManager class, which cont rols

<<role>> ac cess to PersistentClas s object s in the database. The
PersistencyClient SampleDBManager also cont rols user access, registration, and
(from SamplePersistency Client) session management. The SampleDBManager might run as an
applicat ion server that operates behind a web s erver and provides
ac cess to the database.
0..*
To access a persist ent object, the client work s with the
1
SampleDBManager c lass. The client can creat e a new instance of
<<role>> t he PersistentClas s wit h t he " newPersist entClass( )" operat ion, or
SampleDBManager invok e a command on the P ersist entClass with a "c ommand( )"
operat ion. In a real application, t he " command( )" operation would be
replaced with operations from t he Persis tent Class.
+ initialize()
+ command() The client is responsible for initializing and s hutt ing down the
+ shutdown() database through the SampleDBManager class, however the client
+ newP ersis tentClass () does not need t o be aware of any of the details of the Object Store
+ removePers istentClass() database.
+ get Pers istentClassData()
In the context of the ObjectStore database, the Pers ist entClass is
considered the "root class". If there were other root classes, there
would be addit ional clas ses with associat ion relat ionships with the
SampleDBManager.
<<role>>
PersistentClass
From the ObjectSt ore manual: " Objects become persis tent when
t hey are referenced by other persis tent object s. The applicat ion
defines persist ent roots and when it c ommits a t ransaction,
+ getData()
PSE/PSE Pro finds all object s reachable from pers ist ent roots and
+ setData()
stores t hem in t he database.
+ command()
This is called persis tence by reachability and it helps to preserve the
+ new()
automatic s torage management semant ic s of Java. "
You define the Persistent Class for persis tent use the same way you
define it for transient use. Ot her than t he required import com.odi.*
statement, there is almost no special code for pers ist ent use of the
Persis tent Class.

PersistencyClient : An example of a client of a persistent class.
SampleDBManager : Responsible for providing access to the persistent objects.

The SampleDBManager is an example of a class an ObjectStore user would write. It is a control class that provides
a single entry point into a specific ObjectStore database. The user would add the appropriate operations to the class
to access entities in the database. It is often implemented as a singleton, but doesn't have to be (if an application
needs to have multiple instances of a database open at once, then each instance would have its own
SampleDBManager). Both solutions would work, it just depends on how you want to do it.
PersistentClass : An example of a class that's persistent.

Persistency - DBManager Detail
The DBManager class contains most of the database-specific

code, such as starting and ending transactions. There are no
DBManager objects stored in the database, which means that the
DBManager class is not required to be persistence-capable.
The SampleDBManager class has a static members that keep

track of the database that is open. It also has a number of
static methods, each of which executes a transaction in the ObjectStore
database.
<<role>>
SampleDBManager
+ initialize()
+ command()
+ shutdown()
+ newPersistentClass() : PersistentClass
1
+ removePersistentClass(theClass : PersistentClass)
+ getPersistentClassData() : PersistentClass
Session
1 Object St ore
(from com.odi)
1 1 1 (from com.odi)
1
1
+ create()
+ destroy(object : Object)
+ join()
+ terminate() 0..*
1 Transaction
Map (from com.odi)
(f ro m c om.od i)
+ begin()
+ put(name : string, object : Object) + commit(retain : int)
+ get(name : string) : Object
+ remove(name : string) 1
+ new()
Database
(from com.odi)
You do not have to use the Map + open()

class as the collection. You can + create()
use any number of collections + createRoot(name : string, object : Object)
that ObjectStore provides, or you + close()
can define your own. We have
chosen to use the Map.

Session : The class that represents a database session. A session must be created in order to access the database and
any persistent data.
A session is the context in which PSE/PSE Pro databases are created or opened, and transactions can be executed.
Only one transaction at a time can exist in a session.
Map : A persistent map container classes that stores key/value pairs.

Database : The Database class represents an ObjectStore database.
Before you begin creating persistent objects, you must create a database to hold the objects. In subsequent
processes, you open the database to allow the process to read or modify the objects. To create a database, you call
the static create() method on the Database class and specify the database name and an access mode.
Transaction : An ObjectStore transaction. Manages a logical unit of work. All persistent objects must be accessed
within a transaction.
ObjectStore : Defines system-level operations that are not specific to any database.
SampleDBManager : Responsible for providing access to the persistent objects.

The SampleDBManager is an example of a class an ObjectStore user would write. It is a control class that provides
a single entry point into a specific ObjectStore database. The user would add the appropriate operations to the class
to access entities in the database. It is often implemented as a singleton, but doesn't have to be (if an application
needs to have multiple instances of a database open at once, then each instance would have it's own
SampleDBManager). Both solutions would work, it just depends on how you want to do it.


ObjectStore OODBMS Create
ObjectStore OODBMS Create
: : : Transaction : DatabaseRoot :
PersistencyClient SampleDBManager PersistentClass Map
1. newPersistentClass( )
1.1. begin( ) constructor
call
The root is
1.2. new( ) the entry
point into the
Database.
1.3. put(string, Object)
1.4. commit(int)
Pass in the unique key for the
PersistentClass and the
PersistentClass.
The PersistentClass will be stored in
the Map, and subsequently, in the
ObjectStore Database.
To create a new instance of PersistentClass in the database, the SampleDBManager

first creates a transaction and then calls the constructor for PersistentClass. Once
the class has been constructed the class is added to the database via the root
"put()" operation. The transaction is then committed.

ObjectStore OODBMS Delete

ObjectStore OODBMS Delete
: : : Transaction DatabaseRoot : : : ObjectStore

PersistencyClient SampleDBManager Map PersistentClass
Retrieve the instance
to be removed, The root is
1. removePersistentClass(PersistentClass) passing in the unique the entry
id of the point int o t he
1.1. begin( ) PersistentClass to be Dat abase.
deleted
If the instance to be
deleted has constituent
1.2. get(string)
parts (i.e., there's a
composition between
their associated 1.3. get Data( )
classes), those parts
must be retrieved and Once the "part s"
1.4. remove(string)
manually deleted. This have been
is necessary as it is not removed, remove
always the case that the t he original class
parts are removed with
the whole (only with 1.5. destroy(Object)
composition are the
lifetimes coincident).
1.6. commit Completely remove the instance
from the ObjectStore database.
this syncs up the cache and the
physical database.
This forces the delete to happen
right away, as opposed to being
cached (you don't want
something else to link to an
object that is to be deleted).
To delete an object from the database, the SampleDBManager first creates a new transaction,
removes any constituent parts, and then removes the object using the database root "remove()"
operation. The object is then completely removed from the ObjectStore database immediately via
ObjectStore.destry (). Once the object has been removed, the transaction is committed.
Thus, in ObjectStore, delete really has two steps -- removal from the container class that is the
database in memory, and removal from the physical database. that is because you want the deletion
to occur right away, as opposed to being cached.

ObjectStore OODBMS Read
ObjectStore OODBMS Read
: : : Transaction : DatabaseRoot :
PersistencyClient SampleDBManager PersistentClass Map
The root is
1. getPersistentClassData( ) the entry
Find the object in point int o t he
1.1. begin( )
the database; pass Databas e.
in the unique key
St art a read-only
t ransaction to ensure
t hat t he object isn't 1.2. get(string)
c hanged while we're
reading it
1.3. getData(String)
1.4. commit(RETAIN_HOLLOW)
Read the dat a from
returned object
Specify the object
RETAIN_HOLLOW option
on the commit(), so that the
references to the retrieved
data can be used outside of
the transaction.
To read an object , the SampleDBManager first creates a new read-only transaction then looks
up the object using the Map "get()" operation. Once the object has been found it can be read with
the "getData()" operation, and the transaction committed. RETAIN_HOLLOW is specified for the
commit,. so the references to the object and the retrieved data can be used outside of the
retrieval transaction. Once the transaction is committed the object can then be updated.
Note: Even though RETAIN_HOLLOW is specified, it does not guarantee the integrity of the
reference outside of the transaction. There is still some risk that the reference could be outdated.
RETAIN_HOLLOW basically says "I'm consciously taking such a risk". If that option was not
used, then the references would not be available.

ObjectStore OODBMS Update

ObjectStore OODBMS Update
: : : Transaction DatabaseRoot : :
PersistencyClient SampleDBManager Map PersistentClass
1. command( ) The root is

the entry
1.1. begin( ) point into the
Database.
Find the object in the
database; pass in the
unique key 1.2. get(string)
Invoke the object
command
1.3. command( )
1.4. commit
To update an object , t he SampleDBManager first creates a new

t ransaction then looks up t he object using t he Map "get ()" operation.
Once the object has been found a command c an be invoked on it .
W hen the command is complete t he t rans action is committ ed.
A separate put () t o t he Map is not necessary as the get () operat ion

ret urns a reference t o t he persist ent object and any c hanges to that
objec t, if made in t he contex t of a t ransaction, are automatically
c ommitted t o t he database.

ObjectStore OODBMS Initialize
Object Store OODBMS Initializ e
: : : Session : Database : Transact ion DatabaseRoot :

PersistencyClient SampleDBManager Map
1. initializ e( )
1.1. create( )
The root is the entry point into the
Database. It is a "special" data
1.2. join( ) structure. Any changes to this
data structure that occur within the
context of a transaction will be
applied to the associated
1.3. create( ) ObjectStore Database.
1.4. begin( )
Pass in the
name of the
Map, as well 1.5. new( )
as the Map
itself (the map 1.6. createRoot(string, Object) Create the Map that will
is an Object). serve as the database
root.
1.7. commit ()
Once the session has been c reated and joined, t he SampleDBManager must open and create the new
database.
To create the database, the SampleDB Manager creates a new transac tion and creates the "root" of t he
database with the "createRoot()" operation.
The root is the entry point into the Database (the root class is the top-level class in t he object databas e).
It is a "special" data st ructure (in the above example, a Map that contains instanc es of the root class and
all “reachable” c lasses). Any changes to this data struct ure that occur within t he c ontext of a trans action
will be applied to the associated ObjectStore Database. There may be multiple database root s.
Once the root has been c reated, the t ransaction is committed.

ObjectStore OODBMS Shutdown
ObjectSt ore OODBMS Shutdown
: : : Database : Sess ion

PersistencyClient SampleDBManager
1. shutdown( )
1.1. c lose( )
1.2. terminate( )
To shutdown the database, the SampleDBManager must

close the database and terminate the session.
2.3.4 Distribution - RMI
2.3.4.1 Static View

Distribution - RMI
For all classes that realize the Remot e
interface, a remote st ub and a remote
One instance Remote sk eleton is created. These classes handle
per node Naming.
(from java.rmi) (f rom ja va.rmi) t he communication that must occ ur to
support dist ribution.
+ lookup(name : String) : Remote
Any Java class that you want t o
<<Interface>> pas s as an argument t o an
<<role>> ISampleDistributedClassInterface operat ion on a remote interface
SampleDistributedClassClient must realize the S erializable
+ doSomething(aParameter : SamplePass edData) interface
To "distribute" a class in Java, you must define an interface

that inherits from Remote. The distributed class needs to
UnicastRemoteObject <<role>>
realize the defined Remote interface and also inherit from
(from Server) SamplePassedData
(extend) the UnicastRemoteObject.
Serializable
(from java.io)
<<role>>
SampleDistributedClass
+ doSomething(aParamet er : SampleP assedDat a)


Naming. :
* This is the bootstrap mechanism for obtaining references to remote
* objects based on Uniform Resource Locator (URL) syntax. The URL
* for a remote object is specified using the usual host, port and
* name:
* rmi://host:port/name
* host = host name of registry (defaults to current host)
* port = port number of registry (defaults to the registry port number)
* name = name for remote object
SampleDistributedClass : An example of a class that's distributed.
Remote :
* The Remote interface serves to identify all remote objects.
* Any object that is a remote object must directly or indirectly implement
* this interface. Only those methods specified in a remote interface are
* available remotely. 
* Implementation classes can implement any number of remote interfaces
* and can extend other remote implementation classes.
For all classes that realize the Remote interface, a remote stub and a remote skeleton are created. These classes
handle the communication that must occur to support distribution.
SampleDistributedClassClient : An example of a client of a distributed class.
SamplePassedData : An example of data that is passed to/from a distributed class.
UnicastRemoteObject :
ISampleDistributedClassInterface : An example of an interface defined for a distributed class.
Serializable : Any Java class that you want to pass as an argument to an operation on a remote interface must
realize the Serializable interface.


Set Up Remote Connection (details)
The Remote Stub and Remote Skeleton replace the
original class that was distributed.
DistributionClient : : Naming. Remote Stub Remot e

SampleDistributedClassClient Skeleton
Lookup remote object by

specifying it's URL. This
returns a reference to the
1. lookup(String) remote object interface.
2. doSomething
2.1. doSomething
All calls to the distributed class are forwarded

to the remote skeleton.
This diagram describes what happens “under the hood”, but in

reality, you don’t really need to model the RemoteStub and
RemoteSkeleton as these are autogenerated by tools from Sun.
Set Up Remote Connection
: : Naming. : :
SampleDistributedClassClient ISampleDist ributedClassInt erface SampleDistributedClass
Lookup remote object by

specifying it's URL. This
ret urns a reference to the
1. lookup(String) remote object interface.
2. doSomething
2.1. doSomething
All calls t o t he dist ributed class

int erface are forwarded t o t he actual
dist ribut ed class

3. Logical View
3.1 Architectural Analysis
3.1.1 Upper-Level Layers

- Application layer
- Business Services layer
3.1.2 Upper-Level Layer Dependencies
- The Application layer depends on the Business Services layer
3.2 Architectural Design
3.2.1 Incorporating ObjectStore

For the Payroll System, a single root class has been chosen -- Employee.
The selected container is the Map, where the unique key to access the Employees is EmployeeID.
There is one DBManager class per ObjectStore database instance. For the Payroll System, there is one ObjectStore
database, the Payroll Database, that contains employee information, including timecard, purchase order, and
paycheck information. Thus, there is one PayrollDBManager that exists in the new OODBMS Support package.
For the ObjectStore persistency mechanism, the DBManager class includes operations to access the OODBMS
persistent entities in the database. For the PayrollDBManager class, operations have been added to access
Employee, Timecard, Purchase Order, and Paycheck information since that is required for the core system
functionality.
During Identify Design Mechanisms, the architect provides guidance to the designers and makes sure that the
architecture has the necessary infrastructure to support the mechanism. Thus, the PayrollDBManager and the
supporting architectural packages and relationships (OODBMS Support) have been defined in Identify Design
Mechanisms. However, the development of the interaction diagrams that describe these operations and where they
fit into the existing use-case realizations has been deferred until detailed design (e.g., Use-Case and Subsystem
Design).
The following diagram demonstrates the operations that have been defined for the PayrollDBManager during
Identify Design Mechanisms:

3.2.2 Architectural Layers and Their Dependencies

Main Diagram
<<layer>>
Application
<<layer>>
Business
Services
<<layer>>
Middleware
Base Reuse
global
3.2.2.1 Layer Descriptions
Application Layer: The Application layer contains application-specific design elements.
Business Services Layer: The Business Services layer contains business-specific elements that are used in several
applications.
Base Reuse : Basic reusable design elements.
Middleware Layer: Provides utilities and platform-independent services.

3.2.3 Packages and Their Dependencies

Package Dependencies Diagram
Administration Employee Payroll

(from Application) Activities (from Application)
(from Application)
<<subsystem>>
BankSystem
(from Business Services)
<<subsystem>>
PrintService
<<subsystem>>
ProjectManagementData
External System b ase
Interfaces (from Business Services)
When the OODBMS

mechanism is incorporated,
the dependency to
ObjectStore Support will be
added
ObjectStore Support
Payroll Artifacts
GUI Framework
(from Security)
Security
<<subsystem>>
Secure When the RDBMS
Security Manager
Interfaces mechanism is incorporated,
(from Security) the dependency to java.sql
(from Security)
will be added
com.odi java.sql
java.rmi java.awt (from Middleware) (from Middleware)
(from Middleware) (from Middleware)
Base Reuse
java.lang
global (from Middleware)
3.2.3.1 Package Descriptions
Employee Activities : Contains the design elements that support the Employee's applications.
Administration : Contains the design elements that support the Payroll Administrator's applications.
Payroll : Contains the design elements that support the execution of the payroll processing.

Payroll Artifacts : Contains the core payroll abstractions.
BankSystem Subsystem: Encapsulates communication with all external bank systems.
External System Interfaces : Contains the interfaces that support access to external systems. This is so that the
external system interface classes can be version controlled independently from the subsystems that realize them.
PrintService Subsystem: Provides utilities to produce hard-copy.
ProjectManagementDatabase Subsystem: Encapsulates the interface to the legacy database containing

information regarding projects and charge numbers.
java.awt : The java.awt package contains the basic GUI design elements for java.
com.odi : The com.odi package contains the design elements that support the OODBMS persistency mechanism.
The name of the package in the model reflects the naming convention for 3rd party Java software. The convention is
to use the reverse of the domain name, so if Rational had a Java package called "util" they’d call it
"com.rational.util". This com.odi has nothing to do with Microsoft COM/DCOM; they are totally separate. There is
nothing COM/DCOM related when using CORBA, RMI, or ObjectStore.
Base Reuse : Basic reusable design elements.
java.lang : The package contains some basic java design elements.
Security : Contains design elements that implement the security mechanism.
GUI Framework : This package comprises a whole framework for user interface management.
It has a ViewHandler that manages the opening and closing of windows, plus window-to-window communication
so that windows do not need to depend directly upon each other.
This framework is security-aware, it has a login window that will create a server-resident user context object. The
ViewHandler class manages a handle to the user context object.
The ViewHandler also starts up the controller classes for each use case manager.
Secure Interfaces : Contains the interfaces that provide clients access to security services.
Security Manager Subsystem: Provides the implementation for the core security services.
ObjectStore Support : Contains the business-specific design elements that support the OODBMS persistency
mechanism. This includes the DBManager. The DBManager class must contain operations for every OODBMS
persistent class.
java.rmi : The java.rmi package contains the classes that implement the RMI distribution mechanism. This package
is commercially available with most standard JAVA IDEs.
java.sql : The package that contains the design elements that support RDBMS persistency.

4. Process View
4.1 Processes
The processes for the Payroll System will be the following:
One process per major interface or family of forms (e.g. EmployeeApplication):

- EmployeeApplication: Controls the interface of the Employee application. Controls the family of forms that
the employee uses.
There is one process per major interface because these are now seen as separate, mutually exclusive applications
that will run concurrently with each other.
One process per business service controller:

- PayrollControllerProcess
- TimecardControllerProcess
There is one process per controller because these activities will need to run concurrently with each other.
One process per external system:

- ProjectManagementDBAccess
- BankSystemAccess
- PrinterAccess
There is one process per external system. These processes manage access to those systems. Such access may be
slow, so this allows other functionality to continue while the external system processes wait on the external system.
These processes also synchronize access to the external systems from the other system processes.
To further improve throughput and turnaround, a Bank Transaction thread was defined to allow multiple accesses to
the Bank System to occur concurrently. Each time a transaction needs to be sent to the Bank System, a different
thread is used. The Bank Transaction thread will run in the context of the Bank System Access process.
In general, the above processes and threads were defined to support faster response times and take advantage of
multiple processors.
4.2 Design Element to Process Mapping
- The classes associated with the individual user interfaces should be mapped to those processes.
- The classes associated with the individual business services should be mapped to those processes.
- The classes associated with access to the external systems should be mapped to those processes.
5. Deployment View
5.1 Nodes and Connections
The nodes of the physical architecture for the Payroll System are the following:
- Desktop PCs (processors)
- Payroll Server (processor)
- Bank System (processor)
- Project Management Database (processor)
- Printers (devices)
- The Desktop PCs are connected to the Payroll Server via the Company LAN
- The Printers are connected to the Payroll Server via the Company LAN
- The Payroll Server is connected to the external Bank System via the Internet.
- The Payroll Server is connected to the ProjectManagementDatabase via the Company LAN
5.2 Process-to-Node Map
The following processes run on the Desktop PCs:

- EmployeeApplication
The following processes run on the Payroll Server:

- PayrollControllerProcess
- TimecardControllerProcess
- ProjectManagementDBAccess
- BankSystemAccess
- PrinterAccess

Payroll Arch Handbk RPT

Uploaded by

Copyright:

Available Formats

Payroll Arch Handbk RPT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Payroll Arch Handbk RPT

Uploaded by

Copyright:

Available Formats

Rational Software

Payroll Architecture Handbook

Confidential Rational Software, 2003 Page 2 of 33

Confidential Rational Software, 2003 Page 3 of 33

Payroll Architecture Handbook

Analysis Mechanism Design Mechanisms Implementation Mechanisms

Confidential Rational Software, 2003 Page 5 of 33

2.3 Implementation Mechanisms

2.3.1.1 Static View

2.3.1.1.1 Class Descriptions

SecurityAccess : Analysis Mechanisms:

UserSecurityContext : Analysis Mechanisms:

UniqueId : Analysis Mechanisms:

MainApplicationForm : Requirements Traceability:

ISecureUser : Analysis Mechanisms:

Confidential Rational Software, 2003 Page 6 of 33

LoginForm : Analysis Mechanisms:

Confidential Rational Software, 2003 Page 7 of 33

2.3.1.2 Dynamic View

Any User : : LoginForm : ISecureUs er

Confidential Rational Software, 2003 Page 8 of 33

Secure Data Access

After retrieving an object that

Confidential Rational Software, 2003 Page 9 of 33

2.3.2 Persistency - RDBMS - JDBC

2.3.2.1 Static View

+ create() : PersistentClass + getData()

Confidential Rational Software, 2003 Page 10 of 33

2.3.2.1.1 Class Descriptions

PersistentClass : An example of a class that's persistent.

DriverManager : The basic service for managing a set of JDBC drivers.

Confidential Rational Software, 2003 Page 11 of 33

2.3.2.2 Dynamic View

: : DBClass : Connection : Statement : ResultSet : :

1. read(string) returns a The SQL statement

Repeat these operations for 1.4. new( )

Add the retrieved course offering

Confidential Rational Software, 2003 Page 12 of 33

JDBC RDBMS Update

: : DBClass : : Connection : Statement

1. Retrieve the data to be

Confidential Rational Software, 2003 Page 13 of 33

JDBC RDBMS Create

JDBC RDBMS Create

: : DBClass : : Connect ion : Statement

Confidential Rational Software, 2003 Page 14 of 33

JDBC RDBMS Delete

JDBC RDBMS Delete

: : DBClass : Connec tion : Stat ement

1.1. createStat ement( )

To delete a class, the client asks the DBClass to delete a specific

Confidential Rational Software, 2003 Page 15 of 33

JDBC RDBMS Initialize

JDBC RDBMS Initializ e

1. getConnection(url, user, pass)

To initialize the connection, the DBClass must load the

getConnection() attempts to establish a connection to the

Returns a Connection to the URL

Confidential Rational Software, 2003 Page 16 of 33