CSE298
CSE300
RESEARCH AND DEVELOPMENT OF A DISTRIBUTED OBJECT
COMPUTING SYSTEM USING THE UNIFIED MODELING
LANGUAGE AND EXPLORATION OF UML SUPPORT FOR DOC
Research and Work By:
Hector N. Echegoyen
Oliver Scheck
Gowri Shankar
[email protected]
[email protected]
[email protected]
DOC/UML.1
CSE298
CSE300
Overview of Presentation






Objectives of the Project
Overview of Distributed Banking Application
 Modeling and Development plan employed
 Description of the components of the
application
 Demo
Brief Introduction to UML and DOC
Description and Evaluation of DOC support
provided by a few UML modeling tools.
Proposals for enhancements to UML/ROSE based
on the experiences gained during the project.
Future work and conclusion
DOC/UML.2
CSE298
CSE300
Objective

Explore UML Modeling techniques/constructs and
identify support to DOC.

Employ ROSE to Model and develop a Distributed
Banking Application ( with RMI distribution )

Identify key distribution issues relating to OOM

Explore a few UML modeling tools to identify
DOC support.

Suggest enhancements to UML through the
experience gained during the project
DOC/UML.3
CSE298
CSE300
PROJECT DEVELOPMENT PLAN






Exploration Of UML was Done First
Decided To Implement Prototype Of DOC App In
JAVA
Usage Of ROSE Tool Vital To The Process
Followed By Suggestions To UML Enhancements
In DOC
Research Of What Other Tools Offer To Support
DOC Application Development
Suggestions To ROSE Tool Enhancements To
Support DOC
DOC/UML.4
CSE298
CSE300
EXPLORATION OF UML




UML Books and Internet Links
Looked At Every Single Diagram
Found Direct UML Support For DOC In Two
Diagrams
 Interfaces (Class & Component)
 Deployment Diagram
Sequence Diagrams were Useful To Depict Client
Server Transactions
DOC/UML.5
CSE298
CSE300
HOW DOES IT ALL WORK?








Book Concepts - “Instant UML, The Unified
Modeling Language User’s Guide”- OK.
How Would a Real Application Use Them?
Drawing From Experience. Worth it?
Client-Server Application - Banking
Had To Closely Resemble Real World DOC
Mechanism
Use of a Modeling Tool was Vital to The Process
Code Generation and Implementation
Draw Conclusions from there and Move on to the
Next Phase
DOC/UML.6
CHOICE OF PROGRAMMING
LANGUAGE
CSE298
CSE300


JAVA was the language of choice
 Ease of use
 Prior experience working with JAVA
Found JAVA Features And Components To
Directly Support DOC
 Object Serialization
 Remote Method Invocation
DOC/UML.7
CSE298
CSE300
CHOICE OF MODELING TOOL


Decided On Rational Rose
98
 Team had some
experience with it
 Fairly stable
 Recognized and used at
companies for real
development and code
generation not just
modeling
Had to set up the tool for
development in a team
environment
DOC/UML.8
CSE298
CSE300
INITIAL PREPARATION OF TOOL




Reverse engineering was
vital at least for startup
 Learning curve steep
 Level of comfort had not
been reached yet
 Possible initial
development without tool
Banking App was done in
JAVA - Reverse engineering
of whole JDK was necessary
Difficult - Tool made many
assumptions
Documentation..well..
DOC/UML.9
CSE298
CSE300
FRONT END GUI FOR CLIENT




Symantec Visual Café was
Used
New learning curve introduced
Used SWING components
 Platform-independent,
lightweight components
part of JFC
 Written in Pure Java.
 Will look the same on
different OSes
 Fewer System Resources
 Can control their look and
feel (appearance and
behavior)
Part Of GUI Modeled in
ROSE
DOC/UML.10
INITIAL RESEARCH AND DESIGN
MEETINGS
CSE298
CSE300





Agreed to do DOC research concurrently with App
design
Initial Issues we looked for in our research
 Key distribution issues about DOC
 What issues were supported by ROSE
 Suggestions of enhancements to tools
supporting UML
 Look for other tools with support for DOC
Discussion on definition of Banking System
Extent of functionality to be implemented
DOC issues to consider during transactions - what
makes sense for which scenario. Use Cases?
DOC/UML.11
BEHAVIORAL MODELING SYSTEM USE CASE
CSE298
CSE300
BANKING SYSTEM
THE CLERK
Clerk
<<uses>>
Printing
THE
MANAGER
Report Generation
<<uses>>
Manager
Process Transactions <<uses>>
<<uses>>
Auditing
<<uses>>
Persistent Storage
The Customer
THE
CUSTOMER
Distributed Communication
THE SERVER
TheServer
DOC/UML.12
SYSTEM USE CASE DESCRIPTION
CSE298
CSE300








Hard concept to grasp initially
Almost self-explanatory - Focus on functionality
of system with interaction of Actors
Identified Four major Actors
Major functionality and relations to Actors also
identified
Drew clear definitions of operations for each actor
Helped to identify the need for some sort of Role
based security (i.e. Customer actor doesn’t
perform Audits)
Actors directly linked to roles?
Wrote Case Scenarios Of Major functions
DOC/UML.13
ARCHITECTURAL MODELING DEPLOYMENT DIAGRAM
CSE298
CSE300
Terminal
1
Terminal
X
Terminal
X
Branch
Server
Terminal
1
Terminal
2
Terminal
2
Branch
Server
ATM X
Hub
Central
Bank
ATM 1
ATM 2
DOC/UML.14
DEPLOYMENT DIAGRAM DESCRIPTION
CSE298
CSE300






To get an idea of how the system would be
distributed
Concept of more than one type of Bank Server
Questions: What kind of functionality is
distributed where? Where is security, servers or
clients, both?
Where should we deploy objects, and which
object?
Servers handling multiple clients and/or server
transactions at the same time
How to make our system Generic so that we can
run all possible scenarios
DOC/UML.15
CSE298
CSE300
STRUCTURAL MODELING LOGICAL AND COMPONENT VIEWS
TheServer
ClientServerGui
U
U
ClientServerGui
U
TheServer
U
CLASS
DIAGRAM
COMPONENT
DIAGRAM
DOC/UML.16
CSE298
CSE300
INITIAL LOGICAL VIEW OF CLIENT
This is Where T he Applet GUI Goes.
To be Added To T he Model Later.
CustomerAccountForm
<<Interface>>
TransactionInterface
(f rom TheServ er)
1
+BankTransaction
Vector
(f rom util)
<<Interface>>
Serializable
(f rom io)
<<Interface>>
TellerInterface
1
+TellerTransaction
CustomerProfileForm
(f rom TheServ er)
BankConnection
RMI Here
DOC/UML.17
CSE298
CSE300
INIT LOCAL SERVER SIMULATOR
AND CLIENT COMP MODEL
Teller
Interface
Trans actio
nInterface
Serializ
able
Teller
Interface
Bank
Connection
Trans action
Interface
Serializable
Trans acti
onByRole
rmi
Ses s ion
Interface
Funny
Money
Ses s ion
Interface
s erver
Remote
BankServer
util
Teller
Trans
Atm
Trans
Mgr
Trans
DOC/UML.18
CSE298
CSE300
INITIAL LOGICAL VIEW OF THE
SERVER SIMULATOR
DOC/UML.19
CSE298
CSE300
BEHAVIORAL MODELING SEQUENCE DIAGRAM OF LOG IN
Client 1
Server
Enter UName And Passwd
Send UName And Passwd
Verify UName And Passwd
Allocate Memory And Resources For Transactions
Send Connection Status
Allocate Memory And Resources For Transactions
Prompt User For Transaction Info
DOC/UML.20
CSE298
CSE300
BEHAVIORAL MODELING SEQUENCE DIAGRAM OF LOG OUT
Client
Server
User Execute Logout
Send Logout Message
Release Memory And Resources
Successfully Logged Out Message
Release Memory And Resources
DOC/UML.21
CSE298
CSE300
FINAL APPLICATION MODELS AND
DEPLOYMENT




Each of us to explain his/her own piece in detail
 Hector - Client GUI and App
 Oliver - Main Server Transaction and Interface
Hierarchy
 Gowri - Main Server Banking Application
Only a Prototype - Not a full fledge application.
Demo is limited to a couple of transactions.
Goal is to prove Java RMI Concepts, Interfaces,
UML support of them and know how they work in
a Real World App
After this phase, ready to jump to the Analysis
phase
DOC/UML.22
CSE298
CSE300
FINAL DEVELOPMENT - APPLET
AND CONNECTION
DOC/UML.23
CSE298
CSE300
FINAL DEVELOPMENT - MAIN
CLIENT APPLICATION
DOC/UML.24
CSE298
CSE300
RMI Structure


Make method callable by declaring signature in
interface
Compile class and interface and generate stub and
skeleton
Client Object
Server Object
Stub
Skeleton
DOC/UML.25
CSE298
CSE300
RMI Flow of Events
DOC/UML.26
CSE298
CSE300
Server - Goals





Handle multiple virtual connections
Have multiple user types, with varying privileges
Provide the financial services
Use of database
Design elements, which have been prepared in the
design, but have not been implemented
 server-server connection to have hierarchy of
servers
 use of distributed database
 persistency of DB (object serialization)
DOC/UML.27
CSE298
CSE300
Server - Transaction Objects
DOC/UML.28
CSE298
CSE300
Server - Transaction Interfaces
DOC/UML.29
CSE298
CSE300
Server at Runtime - Login
DOC/UML.30
CSE298
CSE300
Server - Login Method
switch (db.validateUser(u, p)) {
case User.ATM: {
atmTransaction = new ATMTransaction(this);
addTransaction(atmTransaction);
return (atmTransaction);
}
case User.MANAGER: {
mgrTransaction = new MgrTransaction(this);
addTransaction(mgrTransaction);
return (mgrTransaction);
}
case User.TELLER: {
tellerTransaction = new TellerTransaction(this);
addTransaction(tellerTransaction);
return (tellerTransaction);
}
case User.SERVER: {
serverTransaction = new ServerTransaction(this);
addTransaction(serverTransaction);
return (serverTransaction);
}
default: {
System.out.println("unsupported user type");
return null;
}
DOC/UML.31
CSE298
CSE300
Server - Database

Designed to
support
persistency
via object
serialization

Associations
are Vectors;
not intuitively
displayed in
Rose
DOC/UML.32
CSE298
CSE300
Server - Hierarchy
DOC/UML.33
CSE298
CSE300
Server - The Big Picture
DOC/UML.34
CSE298
CSE300
Application Functionality



Adding a new Customer to the bank
 Customer Profile Information transferred from
client to Server Transaction Object
 Customer Information extracted from the
Customer Profile Object
 Server function invoked to add current
customer to list of customers
Display information about existing bank customers
Opening one or more accounts for customers.
 Two types of accounts - Savings,Checking
 Customer can have any number of accounts
 Can have more than one type of account with
the same account number
DOC/UML.35
CSE298
CSE300
SERVER APPLICATION HIERARCHY
DOC/UML.36
CSE298
CSE300
Sample Code

Add a Customer to the bank
protected boolean addCustomer(Customer c) {
System.out.println("Server.addCustomer()");
Object obj = null;
for (int i = 0; i < customers.size(); i++) {
obj = (Customer)customers.elementAt(i);
if (obj.equals(c)) {
System.out.print("customer already exists");
return false;
}
}
customers.addElement(c);
return true;
}
DOC/UML.37
CSE298
CSE300
Sample Code
Open an Account for customer
public int createAccount(AccProfileForm apf) throws
RemoteException {
Acct account = null;
switch (apf.type) {
case AccProfileForm.SAVINGS: {
account = new SavingsAccount();
break;
}
case AccProfileForm.CHECKING: {
account = new CheckingAccount();
break;
}
default:
}
account.balance = apf.initialDeposit;
account.accno = server.accNoGen();
account.type = apf.type;
server.addAccount(customer, account);
return account.accno;
}

DOC/UML.38
CSE298
CSE300
Sample Code
protected boolean NewAddAccount(int
customerNumber, TheCustomerAccount a) {
// get a reference to current customer object
System.out.println("entering NewAddAccount()");
Object obj = null;
Object accObj = null;
for (int i = 0; i < customers.size(); i++) {
obj = (Customer)customers.elementAt(i);
if ( ((Customer)obj).custNumber ==
customerNumber ) {
System.out.println("customer found");
DOC/UML.39
CSE298
CSE300
Sample Code
// Check for Duplicate account numbers
for (int j = 0; j < ((Customer)obj).accounts.size(); j++)
{
accObj = (TheCustomerAccount)
((Customer)obj).accounts.elementAt(j);
if (
((TheCustomerAccount)accObj).AccountNumber
== a.AccountNumber)
{
System.out.println("Account is duplicated");
return false;
}
} // end for int j
System.out.println("Account Number: " +
a.AccountNumber + " Successfully Added.");
DOC/UML.40
CSE298
CSE300
Sample Code
System.out.println("Account Number: " +
a.AccountNumber + " Successfully Added.");
Add the account to the customer
((Customer)obj).accounts.addElement(a);
return true;
} // end if == cust number
} // end for i
System.out.println("Customer Not Found");
}
return false;
DOC/UML.41
CSE298
CSE300
Distribution Issues Relating to OOM

Problems relating to distribution.
 How to distribute the different parts of the
system.
 How to find the distribution objects.
 How to decide clusters of objects.
 How to distinguish high and low read/write
ratios between objects.
 How to find the operations which changes the
object states.
DOC/UML.42
CSE298
CSE300
UML Support For DOC


Component Diagrams Shows the structure of the code
 Graph of components connected by
dependency relationships
 Shows dependencies among software
components
Deployment Diagrams
 Shows the structure of the run-time system
 Used to depict which components may run on
which nodes
 Migration of components from node to node
may also be shown.
DOC/UML.43
CSE298
CSE300
Tool Exploration

Having done a Distributed Object
Communications project we looked into several
other tools, that use the UML methodology

Found some extensions to UML that support
DOC, though not as many as anticipated

Took a look at additional features of the tools in
comparison to the industry standard Rose™.
DOC/UML.44
Softmodeler - A Next Generation UML
Modeling Tool
CSE298
CSE300

Exploration of the capabilities of Softmodeler

Identify support to DOC

Suggest enhancements to UML/Rose through the
exploration of Softmodeler.
DOC/UML.45
CSE298
CSE300
Capabilites of Softmodeler



Supports three important technological trends
 Software Components
 Distributed Computing
 OO Technology
Supports the basic UML Constructs
 Use Case Diagrams
 Object Diagrams
 Class Diagrams
 Sequence Diagrams
No support for
 State Diagrams
 Activity Diagrams
DOC/UML.46
CSE298
CSE300
Features Supporting DOC

True Component Design

Distribution Modeling with support for RMI and
CORBA Distribution

Code Generation of Enterprise Java Beans and
Java Beans.

Simulation of models during the analysis and
design stages.
DOC/UML.47
CSE298
CSE300
Component Design and Distribution

Provides special notation for defining components

supports component distribution modeling

Allows reuse of existing models of components

Automatic generation of Enterprise Java Beans
and Java Beans code

Creation of visual graphical component models
from existing EJB and JB source code.

Produces required distribution code (CORBA,Java
RMI)
DOC/UML.48
CSE298
CSE300
Component Notation

Components are Special Classes that define a
higher level of encapsulation.

Possess an extra interface layer of remotely
accessed methods

Belong to a certain Component Framework such as
JB or EJB.

Have an optional distribution method(RMI,
CORBA) for accessing their remotely accessed
interface.
DOC/UML.49
CSE298
CSE300
Component Diagram - An Extension to the
UML Notation
Different from a Class Diagram in the following
 Component Scope
- can be a components
class or a set of classes and interfaces
 Components Interface - a set of methods and
properties which allow remote access.
 Component Framework- Java Beans ,
Enterprise Java Beans , COM
 Components Distribution Method CORBA,RMI
DOC/UML.50
CSE298
CSE300
Class Diagram - An Enhancement to UML
Field
Property
Method
SoftModeler differentiates between regular fields
and properties of a class
 Property is a field with access rights
 Set/Get methods for the property fields generated
automatically

DOC/UML.51
CSE298
CSE300
SoftModeler Vs Rational Rose



Component Diagrams
provide facilities for
 Specifying distinct
local and remote
methods
 Specifying the
distribution method
required.
Support for the simulation
of Models during
Analysis and Design
phase.
Allows specification of
properties with access
rights within classes.

Extensive support for
Component Diagrams not
available.

No support.

No support.
DOC/UML.52
CSE298
CSE300
SoftModeler Vs Rational Rose ( Contd. )

Doest not support state
diagrams and Activity
Diagrams.

Supports all constructs
defined in the UML
Notation.
DOC/UML.53
CSE298
CSE300
Component Creation
DOC/UML.54
CSE298
CSE300
ObjecTime Developer™






Product of ObjecTime Limited
http://www.objectime.com/
Versions for C, C++
Consider themselves as the leading provider of
software engineering tools and middleware for
developers of distributed systems
This product has been incorporated in Rational
Rose® RealTime
Uses extensions on UML to incorporate real-time
aspects, methodology call ROOM (part of UMLRT)
DOC/UML.55
CSE298
CSE300
ObjecTime Developer™ - Features



Different levels of views for developers and
customers
Executable modeling capability for understanding
complex, real-time systems designs
 tracing messages visually and debugging using
graphics
 build model from design, load it to target
platform, control and animate them from the
development platform
generates entire applications, not only headers and
skeletons, by using formal methods that allow
automatisation
DOC/UML.56
CSE298
CSE300
ObjecTime Developer™ - Features

Integrates smoothly with other developement tools
and operating systems (esp. real-time operating
systems

Stated on their web page:
ROOM forms the basis for UML-RT, a set of realtime extensions to UML, which is soon to be an
OMG standard for general purpose software
development.
DOC/UML.57
CSE298
CSE300
UML-RT components

Capsules represent
complex,
potentially
concurrent and also
distributed active
components

Port is physical part of implementation of
capsule that mediates interaction of capsule
with outside world (includes Interface and
Protocol [signals])
DOC/UML.58
CSE298
CSE300
UML-RT components

Connectors capture key communication
relationships between capsules.
These relationships have architectural significance
since they identify which capsules can affect each
other through direct communication.
DOC/UML.59
RESEARCH OF UML TOOLS PARADIGM PLUS
CSE298
CSE300





Enterprise Component Modeling (ECM: share and
reuse of components across projects)
Models Business Processes
Object Repository for component sharing and
reuse and to reverse engineer legacy software
Fully integrated business process modeling, object
modeling, and physical database modeling
OOCL (Object Oriented Change and Learning).
Business managers capture, model, and
communicate corporate strategies to development
teams by mapping business requirements directly
into use-case, object, and physical database
models.
DOC/UML.60
CSE298
CSE300
PARADIGM PLUS - REVERSE
ENGINEERING
DOC/UML.61
CSE298
CSE300
PARADIGM PLUS - BUSINESS
PROCESS MODEL
DOC/UML.62
CSE298
CSE300
PARADIGM PLUS - PHYSICAL
DATABASE MODELING
DOC/UML.63
CSE298
CSE300
PARADIGM PLUS - COMPONENT
BASED DEVELOPMENT
DOC/UML.64
CSE298
CSE300
PARADIGM PLUS AND UML - CLASS
DIAGRAM
DOC/UML.65
CSE298
CSE300
PARADIGM PLUS AND UML USE CASE DIAGRAM
DOC/UML.66
CSE298
CSE300
PARADIGM PLUS AND UML STATE AND OBJECT DIAGRAMS
DOC/UML.67
CSE298
CSE300
PARADIGM PLUS AND UML SEQUENCE AND COMPONENT DIAGRAM
DOC/UML.68
CSE298
CSE300
PARADIGM PLUS AND UML PHYS DATABASE AND COLLABORATION
DIAGRAM
DOC/UML.69
CSE298
CSE300
PARADIGM PLUS AND UML PROJECT AND DEPLOYMENT DIAGRAMS
DOC/UML.70
CSE298
CSE300
PARADIGM PLUS AND UML ENTERPRISE COMPONENT MODELING
DOC/UML.71
CSE298
CSE300
PARADIGM PLUS AND UML ECM ZOOMING INTO CONCEPTUALIZATION
DOC/UML.72
CSE298
CSE300
PARADIGM PLUS - ENHANCEMENTS
TO UML THAT SUPPORT DOC





Use Case Diagram
 Communication Types
Sequence Diagram
 Timing Related Interactions
Deployment Diagram
 Additions to Physical Components
Project Diagram
 Not Directly Related To DOC
 Useful in Project Management Activities For
Team Leaders and Middle Management
ECM
 Not Directly Related To DOC. Could be used
in Software Systems Engineering.
DOC/UML.73
CSE298
CSE300
Together®




Product of Object International, Inc.
http://www.oi.com/
Together/J & Together/C++
President and founder Peter Coad
 Coad conducts workshops and performs
corporate consultations
 publishes books on modeling
 provides extensions to UML
 tries to propagate his own model called “Coad
Object Model” and Archetypes
DOC/UML.74
CSE298
CSE300
Together® - Features










Supports C++ and Java™
Round-trip engineering
Works directly with source files, thus no
intermediate repository necessary
UML diagrams, Coad Object Models
Generation of system documentation
Configurability of reverse engineering and code
generation
Rational Rose™ import/export
Open API for extensibility
Availability on multiple OS platforms
Supports IDL for CORBA and COM
DOC/UML.75
CSE298
CSE300
Together - Screenshot
DOC/UML.76
CSE298
CSE300
Coad’s Extension to UML

4 basic “Archetypes”
 moment-interval
 role
 category-entry-like description
 party, place or thing

Use of color, because …
 psychology behind colors

His Archetypes are actually Patterns
DOC/UML.77
CSE298
CSE300
Future Work


Completion of Application Functionality
 Server hierarchy with branch and central server
 Distributed DB
 Client GUI adapted to new functionality
Explore more UML modeling tools to identify
further support to DOC
DOC/UML.78
CSE298
CSE300
IDENTIFICATION OF ENHANCEMENTS TO
UML TO SUPPORT DOC


Object Deployment
 Placing the objects at the right places (C or S)
 Ongoing work at UCONN
 To be incorporated into the design phase of the
model
Simulation Capabilities In Deployment Diagrams
 Formal Methods, Mathematical Equations,
Node Constraints, Connections, Traffic
Reports, Line Capacity Maximization,
Statistics and Run Time Simulation
 Script of Events to generate activity in a DOC
System
 Lots Of CPU
DOC/UML.79
CSE298
CSE300
Conclusions


Experience gained from the Project
 Knowledge about UML notation
 Opportunity to model using Rational Rose
 Java RMI
 More DOC support provided by other tools
 Team-work
Enhancements to UML that support DOC
 Use Case, Deployment and Sequence Diagram
additions to UML by Paradigm Plus
 Extensions to the Component Diagram, Class
Diagram provided by SoftModeler
 UML-RT as found in Rose for Real-Time
DOC/UML.80