Title: RESEARCH AND DEVELOPMENT OF A DISTRIBUTED OBJECT COMPUTING SYSTEM USING THE UNIFIED MODELING LANGUAGE AND EXPLORATION OF UML SUPPORT FOR DOC
1RESEARCH 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
Hector.Echegoyen_at_otis.com oliverscheck_at_email.com
gowri_at_engr.uconn.edu
2Overview 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
3Objective
- 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
4PROJECT 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
5EXPLORATION 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
6HOW DOES IT ALL WORK?
- Book Concepts - Instant UML, The Unified
Modeling Language Users 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
7CHOICE OF PROGRAMMING LANGUAGE
- 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
8CHOICE 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
9INITIAL 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..
10FRONT 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
11INITIAL RESEARCH AND DESIGN MEETINGS
- 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?
12BEHAVIORAL MODELING -SYSTEM USE CASE
13SYSTEM USE CASE - DESCRIPTION
- 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 doesnt
perform Audits) - Actors directly linked to roles?
- Wrote Case Scenarios Of Major functions
14ARCHITECTURAL MODELING -DEPLOYMENT DIAGRAM
15DEPLOYMENT DIAGRAM -DESCRIPTION
- 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
16STRUCTURAL MODELING - LOGICAL AND COMPONENT VIEWS
17INITIAL LOGICAL VIEW OF CLIENT
18INIT LOCAL SERVER SIMULATOR AND CLIENT COMP MODEL
19INITIAL LOGICAL VIEW OF THE SERVER SIMULATOR
20BEHAVIORAL MODELING - SEQUENCE DIAGRAM OF LOG IN
21BEHAVIORAL MODELING - SEQUENCE DIAGRAM OF LOG OUT
22FINAL 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
23FINAL DEVELOPMENT - APPLET AND CONNECTION
24FINAL DEVELOPMENT - MAIN CLIENT APPLICATION
25RMI Structure
- Make method callable by declaring signature in
interface - Compile class and interface and generate stub and
skeleton
26RMI Flow of Events
27Server - 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)
28Server - Transaction Objects
29Server - Transaction Interfaces
30Server at Runtime - Login
31Server - 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)
32Server - Database
- Designed to support persistency via object
serialization - Associations are Vectors not intuitively
displayed in Rose
33Server - Hierarchy
34Server - The Big Picture
35Application 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
36SERVER APPLICATION HIERARCHY
37Sample 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 lt 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
-
38Sample 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)
39Sample 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 lt customers.size() i)
- obj (Customer)customers.elementAt(i)
- if ( ((Customer)obj).custNumber
customerNumber ) - System.out.println("customer found")
-
40Sample Code
- // Check for Duplicate account numbers
- for (int j 0 j lt ((Customer)obj).accounts.size(
) j) -
- accObj (TheCustomerAccount)
((Customer)obj).accounts.elementAt(j) -
- if ( ((TheCustomerAccount)accObj).Acco
untNumber a.AccountNumber) -
- System.out.println("Account is
duplicated") - return false
-
- // end for int j
- System.out.println("Account Number "
a.AccountNumber " Successfully Added.")
41Sample 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
-
42Distribution 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.
43UML 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.
44Tool 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.
45Softmodeler - A Next Generation UML Modeling Tool
- Exploration of the capabilities of Softmodeler
- Identify support to DOC
- Suggest enhancements to UML/Rose through the
exploration of Softmodeler.
46Capabilites 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
47Features 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.
48Component 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)
49Component 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.
50Component 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
51Class 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
52SoftModeler 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.
53SoftModeler Vs Rational Rose ( Contd. )
- Doest not support state diagrams and Activity
Diagrams.
- Supports all constructs defined in the UML
Notation.
54Component Creation
55ObjecTime 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 UML-RT)
56ObjecTime 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
57ObjecTime Developer - Features
- Integrates smoothly with other developement tools
and operating systems (esp. real-time operating
systems - Stated on their web pageROOM forms the basis
for UML-RT, a set of real-time extensions to UML,
which is soon to be an OMG standard for general
purpose software development.
58UML-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)
59UML-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.
60RESEARCH OF UML TOOLS -PARADIGM PLUS
- 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.
61PARADIGM PLUS - REVERSE ENGINEERING
62PARADIGM PLUS - BUSINESS PROCESS MODEL
63PARADIGM PLUS - PHYSICAL DATABASE MODELING
64PARADIGM PLUS - COMPONENT BASED DEVELOPMENT
65PARADIGM PLUS AND UML - CLASS DIAGRAM
66PARADIGM PLUS AND UML -USE CASE DIAGRAM
67PARADIGM PLUS AND UML -STATE AND OBJECT DIAGRAMS
68PARADIGM PLUS AND UML -SEQUENCE AND COMPONENT
DIAGRAM
69PARADIGM PLUS AND UML -PHYS DATABASE AND
COLLABORATION DIAGRAM
70PARADIGM PLUS AND UML -PROJECT AND DEPLOYMENT
DIAGRAMS
71PARADIGM PLUS AND UML -ENTERPRISE COMPONENT
MODELING
72PARADIGM PLUS AND UML -ECM ZOOMING INTO
CONCEPTUALIZATION
73PARADIGM 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.
74Together
- 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
75Together - 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
76Together - Screenshot
77Coads 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
78Future 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
79IDENTIFICATION 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
80Conclusions
- 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