CSE300-02
DISTRIBUTED OBJECT COMPUTING
FINAL REPORT
RESEARCH AND DEVELOPMENT OF A DISTRIBUTED OBJECT COMPUTING SYSTEM USING THE UNIFIED MODELING LANGUAGE AND EXPLORATION OF UML SUPPORT FOR DOC
STUDENT NAMES: Hector N. Echegoyen
Gowri Shankar
Oliver Scheck
INSTRUCTOR'S NAME: S. A. Demurjian
5/4/99
Table of Contents
Motivation......
Objectives......
Problems Relating To Distributed Object Computing......
Project Overview......
Platform for application development
Introduction to the UML and Java Techniques employed in the project
detailed DISCUSSION of project......
PROJECT DEVELOPMENT PLAN......
EXPLORATION OF UML......
INTERFACES......
INTERFACES AND JAVA RMI......
DEPLOYMENT DIAGRAM......
SEQUENCE DIAGRAMS......
IMPLEMENTATION OF A DISTRIBUTED COMPUTING APPLICATION......
WHAT TYPE OF APPLICATION?......
CHOICE OF PROGRAMMING LANGUAGE AND MODELING TOOL......
FRONT END GUI FOR THE CLIENT......
INITIAL PREPARATION OF THE MODELING TOOL......
INITIAL RESEARCH AND DESIGN MEETINGS......
INITIAL DESIGN - SYSTEM USE CASE......
INITIAL DESIGN – DEPLOYMENT DIAGRAM......
SYSTEM ARCHITECTURE......
INITIAL DESIGN – CLIENT......
INITIAL DESIGN – SERVER SIMULATOR......
Description of the server part......
Features of the server
Features included in design but not implemented
The Transaction Hierarchy......
Interface Definition
The login
The database
The Server Hierarchy
SERVER - THE BIG PICTURE......
UML SUPPORT TO DOC......
RESEARCH OF OTHER TOOLS SUPPORTING ENHANCEMENTS TO DOC......
PARADIGM PLUS......
PICTURES OF PARADIGM PLUS UML NOTATION AND ENHANCEMENTS......
ENHANCEMENTS TO UML THAT SUPPORT DOC......
ObjecTime Developer™......
General Information......
What are the additions to UML?......
The Simulation Capabilities......
SoftModeler - Next Generation UML MODELING TOOL
Component Design and Creation in SoftModeler
SoftModeler’s Enhancement to the Class Diagram
Simulation of models - an enhancement to UML
ENHANCEMENTS TO UML THAT SUPPORT DOC......
Class diagrams in the UML notation can be enhanced to support specification of access rights for properties. This is a facility provided by SoftModeler and results in automatic generation of the methods to access these properties.
TogetherJ®
General Information......
Features of interest......
IDENTIFICATION OF ENHANCEMENTS TO UML AND/OR ROSE TO SUPPORT DOC......
UML SUPPORT OF OBJECT DEPLOYMENT......
SIMULATION CAPABILITIES IN DEPLOYMENT DIAGRAMS......
CONCLUSION AND FUTURE WORK......
FUTURE WORK......
APPENDIX......
COMPONENT-WISE BREAKDOWN OF THE TOPIC......
FINAL SYSTEM ARCHITECTURE......
FINAL CLIENT APPLICATION......
GUI DEVELOPMENT......
FINAL SERVER BANKING APPLICATION......
REFERENCES......
Table of Figures
Figure 1 – Interfaces in Class and Component Diagram......
Figure 2 - Example of a deployment diagram......
Figure 3 – Example of a sequence diagram......
Figure 4 – Example of Visual Café SWING Components......
Figure 5 – Rational ROSE 98 Reverse Engineered Classes......
Figure 6 – System Use Case......
Figure 7 – System Deployment Diagram......
Figure 8 – System Architecture......
Figure 9 – Initial Client......
Figure 10 – Server Simulator......
Figure 11 - Transaction Hierarchy......
Figure 12 - Transaction Interface Hierarchy......
Figure 13 - Login Process......
Figure 14 - The Database......
Figure 15 - Server Hierarchy......
Figure 16 - The complete Server......
Figure 17 - ROOM Capsule......
Figure 18 – Component Symbol......
Figure 19 – Component Creation Dialog......
Figure 20 – Class Diagram......
Figure 21 – Simulator Toolbar......
Figure 22 – Simulation of a Scenario......
Figure 23 - TogetherJ......
Figure 24 – J Applet and Bank Connection......
Figure 25 – Main Banking Client Application......
Figure 26 - Banking Application Hierarchy......
Motivation
There exists considerable research interest in Distributed object computing as it ushers in a new breed of problems in the development of systems .The purpose of the project was to evaluate the techniques provided by UML and Java, to support Distributed Object Computing and propose enhancements for currently unsupported issues. Modeling and Design of a distributed banking application using the UML notation was also an integral part of the process. A closely related activity was to propose extensions and enhancements to the UML notation based on experience gained during the course of the project.
Objectives
- Study the UML notation and identify the support offered to Distributed Object Computing.
- Employ Rational Rose to model a distributed banking Application while creating an RMI implementation.
- Identify key distribution issues relating to object-oriented methodologies.
- Explore the DOC related capabilities of established and emerging UML modeling tools.
- Suggest Extensions and enhancements to the UML notation.
Problems Relating To Distributed Object Computing
There are several issues that have to be resolved when a decision to build a distributed object system is made. The following is a list of distribution concerns that have been identified.
- 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 operations which changes object states.
The above questions have to be answered in order to achieve a good distribution of objects with minimum remote communication.
Project Overview
The project work has been divided into two phases in order to accomplish the goals.
The first part involves studying the UML notation with the view to identifying its support to DOC and todevelop a small distributed banking system which would not only give us an opportunity to apply the modeling techniques of UML but in the process enable us to understand their interrelationships during analysis and design. Among the Banking Application requirements are the possibility of distributed usage, management of persistent data and the inclusion of a GUI.
Platform for application development
- Choice of Modeling tool
The modeling tool of choice for the application is Rational Rose 98 as it was one of the first CASE tools to support the UML notation.
- Choice of OO language
Java was chosen as the Object oriented language for our application as it offers extensive support in the form of dynamic binding, applet programming for deployment over the web and RMI and object serialization to support distributed programming.
The second phase involved the research of UML and the DOC related capabilities of several modeling tools. There exists considerable research interest in Distributed object computing as it ushers in a new breed of problems in the development of systems. This phase of our project involved the identification of key issues relating to distributed systems. A closely related activity was to study the capabilities of UML and to identify the techniques and methods, which currently exist in UML for supporting distribution concerns. Furthermore, as part of our research, we have also to explored four emerging modeling tools which follow the UML standard and have identified the support offered by these, to the analysis and design of distributed object systems. Based on the conclusions drawn from the exploration of the tools, a list of extensions and enhancements to UML have been identified and documented.
Introduction to the UML and Java Techniques employed in the project
UML provides description techniques for various aspects of the system. The project involved the use of several UML diagram types such as use case, class diagrams, sequence diagrams, component diagrams and deployment diagrams, Class diagrams which show the classes of the program code, their attributes and operations, and the relationships and dependencies between them, proved very useful in the design of the distributed banking application.` Implementation diagrams viz. Component diagrams which show the structure of the source code and its partitioning into components, and deployment diagrams which show the run-time implementation structure and the distribution of objects and components on physical computing nodes, also proved to be very useful to model the distributed application and allowed us to identify enhancements to them.
The Java Language framework includes features that support distributed computing. Two interesting features that were used in the project were object serialization and RMI which allows communication between objects in different processes and address spaces, possibly on different hosts. RMI and object serialization are tightly integrated into the Java Framework and extend Java features like garbage collection and dynamic binding to support distributed programming.
detailed DISCUSSION of project
PROJECT DEVELOPMENT PLAN
The team drafted a project development plan to follow throughout the project. Their main points are as follows:
- Exploration of UML to mainly search for structures necessary for DOC
- Implementation of a DOC Application using a language that most or all of us knew and that potentially had capabilities and libraries to support DOC transactions. JAVA was picked.
- Usage of a modeling tool that supported designs, code generation, reverse engineering and that was available to us and reliable enough to handle our task. Rational ROSE 98 was picked.
- Suggest enhancements to UML to support DOC more efficiently.
- Research of tools other than ROSE that could provide enhancements to UML or to better support DOC modeling.
- Suggestions of ROSE Tool enhancements to support DOC.
EXPLORATION OF UML
The team explored UML at the very beginning of the project to find structures that could be directly used in DOC. All of the class diagrams were examined and found direct UML support in two diagrams: a) Interfaces (Class and Component Diagram), and b) Deployment Diagram. We also found support in sequence diagrams when depicting transactions.
INTERFACES
Figure 1 – Interfaces in Class and Component Diagram
Interfaces are supported in the Rose Tool as a stereotype in the Class Diagram and in the Component Diagram as a Component with a line and a bubble, the bubble representing the Class it is an Interface of. Unlike C++, JAVA supports them directly as a stereotype, and they contain no attributes [UMLRC].
INTERFACES AND JAVA RMI
Interfaces were the “logical communication ports” between objects. The actual remote communication mechanism existing in JAVA is Remote Method Invocation by which an object would invoke methods defined in an interface of a remote object thereby realizing the remote call.
DEPLOYMENT DIAGRAM
Nodes in Deployment Diagrams are used to describe the topology of a system from the physical point of view. Usually, nodes can be used to represent physical devices such as computers and other hardware where software is supposed to run.
Figure 2 - Example of a deployment diagram
SEQUENCE DIAGRAMS
Figure 3 – Example of a sequence diagram
It is part of the family of interaction diagrams, and it helps map the sequence of operations during a specific transaction. It shows the interaction between two objects, two entities or two concepts. In figure 3, they help depict transactions between a Client and a Server, even though they are composed of a group of objects.
IMPLEMENTATION OF A DISTRIBUTED COMPUTING APPLICATION
After reviewing the concepts behind UML’s support for DOC there was an interest in knowing how a real DOC application would use these constructs. Putting in practice the UML constructs was viewed as key to the better understanding of the modeling language. The decision was finally made to design a DOC application using UML and implement it using the DOC supporting constructs of a programming language.
WHAT TYPE OF APPLICATION?
The application to be modeled had to resemble a real world scenario, where real time transactions could take place in real work loads could be proven. The concept of “Banking Application” was studied and discussed in preparation for design and implementation. Also, a modeling tool had to be found for design and implementation. A programming language that supported DOC constructs had to be picked. The purpose was to design, implement and demo a prototype DOC application, learn from the experience gained and move on to the analysis phase as portrayed in the objectives.
CHOICE OF PROGRAMMING LANGUAGE AND MODELING TOOL
JAVA was chosen as the programming language to use because of its OO capabilities, ease of use, but most importantly because of it’s inherent DOC constructs such as JAVA RMI and Object Serialization. Also, Rational Rose 98 was chosen as the modeling tool because it supported JAVA modeling and code generation, reverse engineering capabilities, support for working on a team environment, and was believed to be fairly reliable and popular among the Software Engineering community, both commercial and academic.
FRONT END GUI FOR THE CLIENT
The team decided to use a visual tool for the development of the GUI. Symantec Visual Café professional edition Version 3 was used. This tool supported JDK 1.1.7a, therefore the team decided to use JDK 1.1.7b as a development language, since it was publicly available and it was the closest one to that of the tool.
Figure 4 – Example of Visual Café SWING Components
As a result of this tool, a new learning curve was introduced and it was also decided to model part of the tool in ROSE. The SWING GUI components were to be used in the GUI design because of their nice capabilities and Lightweight characteristics.
INITIAL PREPARATION OF THE MODELING TOOL
The reverse engineering capabilities of ROSE were identified as vital to the development process not only because the modeling curve was very steep, but also because the appropriate level of comfort as far as using the modeling tool was somehow far from being reached. Also, there existed the possibility of initial development without the use of the ROSE tool because of this learning curve.
In order to reverse engineer any piece of code from any of us, the complete JDK for the appropriate version had to also be reverse-engineered. This was a very long and painful process because the tool made many assumptions along the way and the documentation and help were, of course, lacking. Nevertheless, it was done and used. Also, since it was agreed that at least part of the GUI had to be modeled, then the whole library of Symantec Visual Café components had to also be reverse-engineered.
Figure 5 – Rational ROSE 98 Reverse Engineered Classes
INITIAL RESEARCH AND DESIGN MEETINGS
Since there was a lot of material to cover, DOC research was to be done concurrently with the application design and development. The research was to be conducted keeping in mind the following issues: a) key distribution issues about DOC, b) what issues were supported by ROSE, c) suggestions of enhancements to tools supporting UML, and d) look for other tools with support for DOC.
The Banking application was discussed as far as the scope and the extent of it. At one point there was even a discussion of implementing an Observer pattern to handle multiple copies of GUI data connected to a server at one time. We had to narrow this scope down to a beginning simple prototype of a server system to handle multiple clients with potentially different roles, and with a few transactions. If this worked, it would ramp up to more functionality and possibly the observer pattern.
INITIAL DESIGN - SYSTEM USE CASE
Considering “what makes sense during which scenario” did not come easy to us. A Use Case diagram was necessary to depict the different functionality to potentially add to our application. The concept was hard to grasp at the beginning, but as the discussions went on, some consensus was reached.
Figure 6 – System Use Case
Four major actors, namely Clerk, Customer, Server and Manager, were identified. They were used to right away identify user roles for the system. Also, the general operations of the system were identified as well as the need for role based security. Case scenarios of some transactions were written on draft paper.
INITIAL DESIGN – DEPLOYMENT DIAGRAM
The distribution of the system was the next step in our design. We raised questions such as where the objects would be and which. Object security and deployment was also discussed. As far as security, we decided to include all of the security on the client side to avoid duplication and inconsistencies in this matter between client and server. Two types of servers were identified: a) Branch, and b) Central. Branch sever would handle normal client-server communications and have a database of users for the manager and teller roles. Central server would be more of a bigger repository with Central bank transactions and end of the day downloads of data. The role types identified for clients were the following: a) Manager, b) Teller, c) ATM and d) Server. A Branch server doing a download of data to a Central server, acting as a client would take on the “server-transaction client” role, for example. The servers would handle multiple transactions at the same time. The system had to be designed generic enough so that it could be deployed in any of the scenarios that we covered.
Figure 7 – System Deployment Diagram
SYSTEM ARCHITECTURE
The system was then broken up into Client and Server packages, unitized for work under a team environment. Class and component diagrams were developed as a starting point for the design of the application. Inside the Client Server GUI a Class diagram of a Server Simulator was created. The Server simulator was needed during development of the GUI since work had to be done in parallel. The server also had to write a Client simulator to test its functionality while the Client was being developed.
Figure 8 – System Architecture
INITIAL DESIGN – CLIENT
Initially, a client and a server simulator were needed for development. The client side showed objects for data transfer (forms), interfaces to the server’s transaction objects and session handler and a Bank Connection object which was the link from the GUI to the Client Banking application. All requests from the GUI would be funneled via the Bank Connection object, which might use the forms for holding data, and use the Interfaces to call upon remote objects located at the server.