RESEARCH AND DEVELOPMENT OF A DISTRIBUTED OBJECT COMPUTING SYSTEM USING THE UNIFIED MODELING LANGUAGE AND EXPLORATION OF UML SUPPORT FOR DOC

1
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
Hector.Echegoyen_at_otis.com oliverscheck_at_email.com
gowri_at_engr.uconn.edu
2
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

3
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

4
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

5
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

6
HOW 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

7
CHOICE 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

8
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

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

10
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

11
INITIAL 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?

12
BEHAVIORAL MODELING -SYSTEM USE CASE
13
SYSTEM 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

14
ARCHITECTURAL MODELING -DEPLOYMENT DIAGRAM
15
DEPLOYMENT 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

16
STRUCTURAL MODELING - LOGICAL AND COMPONENT VIEWS
17
INITIAL LOGICAL VIEW OF CLIENT
18
INIT LOCAL SERVER SIMULATOR AND CLIENT COMP MODEL
19
INITIAL LOGICAL VIEW OF THE SERVER SIMULATOR
20
BEHAVIORAL MODELING - SEQUENCE DIAGRAM OF LOG IN
21
BEHAVIORAL MODELING - SEQUENCE DIAGRAM OF LOG OUT
22
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

23
FINAL DEVELOPMENT - APPLET AND CONNECTION
24
FINAL DEVELOPMENT - MAIN CLIENT APPLICATION
25
RMI Structure

• Make method callable by declaring signature in
  interface
• Compile class and interface and generate stub and
  skeleton

26
RMI Flow of Events
27
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)

28
Server - Transaction Objects
29
Server - Transaction Interfaces
30
Server at Runtime - Login
31
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)

32
Server - Database

• Designed to support persistency via object
  serialization
• Associations are Vectors not intuitively
  displayed in Rose

33
Server - Hierarchy
34
Server - The Big Picture
35
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

36
SERVER APPLICATION HIERARCHY
37
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 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

38
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)

39
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 lt customers.size() i)
  
• obj (Customer)customers.elementAt(i)
• if ( ((Customer)obj).custNumber
  customerNumber )
• System.out.println("customer found")

40
Sample 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.")

41
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

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

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

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

45
Softmodeler - 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.

46
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

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

48
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)

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

50
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

51
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

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

53
SoftModeler Vs Rational Rose ( Contd. )

• Doest not support state diagrams and Activity
  Diagrams.

• Supports all constructs defined in the UML
  Notation.

54
Component Creation
55
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 UML-RT)

56
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

57
ObjecTime 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.

58
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)

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

60
RESEARCH 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.

61
PARADIGM PLUS - REVERSE ENGINEERING
62
PARADIGM PLUS - BUSINESS PROCESS MODEL
63
PARADIGM PLUS - PHYSICAL DATABASE MODELING
64
PARADIGM PLUS - COMPONENT BASED DEVELOPMENT
65
PARADIGM PLUS AND UML - CLASS DIAGRAM
66
PARADIGM PLUS AND UML -USE CASE DIAGRAM
67
PARADIGM PLUS AND UML -STATE AND OBJECT DIAGRAMS
68
PARADIGM PLUS AND UML -SEQUENCE AND COMPONENT
DIAGRAM
69
PARADIGM PLUS AND UML -PHYS DATABASE AND
COLLABORATION DIAGRAM
70
PARADIGM PLUS AND UML -PROJECT AND DEPLOYMENT
DIAGRAMS
71
PARADIGM PLUS AND UML -ENTERPRISE COMPONENT
MODELING
72
PARADIGM PLUS AND UML -ECM ZOOMING INTO
CONCEPTUALIZATION
73
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.

74
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

75
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

76
Together - Screenshot
77
Coads 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

78
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

79
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

80
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