1 / 60

Distributed Object Computing and UML

Distributed Object Computing and UML. Research and Work By: Hector N. Echegoyen Oliver Scheck Gowri Shankar. Hector.Echegoyen@otis.com oliverscheck@email.com gowri@engr.uconn.edu. Objective. Explore UML Modeling Techniques/Constructs and Identify Support to DOC

caresse
Download Presentation

Distributed Object Computing and UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Object Computing and UML Research and Work By: Hector N. Echegoyen Oliver Scheck Gowri Shankar Hector.Echegoyen@otis.com oliverscheck@email.com gowri@engr.uconn.edu

  2. Objective • Explore UML Modeling Techniques/Constructs and Identify Support to DOC • Employ Rational ROSE to Model and Develop a Distributed Banking Application (using RMI) • Identify Key Distribution Issues Relating to OOM • Explore a Select Set of UML Modeling Tools to Identify DOC Support

  3. 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 Doesn’t Perform Audits) • Actors Directly Linked to Roles? • Wrote Case Scenarios of Major Functions

  4. Behavioral Modeling System Use Case 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

  5. 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 • Attempt to Make Our System Generic So That We Can Run All Possible Scenarios

  6. Architectural Modeling Deployment Diagram Terminal Terminal 2 Terminal X 1 Branch ATM X Server Terminal 1 Branch Hub Central Server Bank Terminal 2 ATM 2 ATM 1 Terminal X

  7. Structural Modeling Logical and Component Views CLASS DIAGRAM TheServer ClientServerGui U U COMPONENT DIAGRAM ClientServerGui TheServer U U

  8. Initial Logical View of Client This is Where The Applet GUI Goes. To be Added To The Model Later. CustomerAccountForm <<Interface>> (from TheServer) TransactionInterface 1 1 +BankTransaction Vector (from util) <<Interface>> Serializable (from io) <<Interface>> TellerInterface 1 1 +TellerTransaction CustomerProfileForm (from TheServer) BankConnection RMI Here

  9. Initial Local Server Simulator and Client Comp Model Teller Serializ Interface able Teller Transactio Interface nInterface Bank Connection Transaction Serializable Interface Transacti Session rmi onByRole Interface Funny Money Session server Interface Remote BankServer util Teller Atm Mgr Trans Trans Trans

  10. Initial Logical View of the Server Simulator This is Where The Applet GUI Goes. To be Added To The Model Later. <<Interface>> SessionInterface SessionHandler 1 1 <<Interface>> <<Interface>> Remote Serializable +TheSessionHandler (from io) (from rmi) FunnyMoney amount : int Hashtable (from util) accounts RemoteBankServer <<Interface>> UnicastRemoteObject TransactionInterface (from server) +TheAccount +TheTransactionHandler 1 1 Account <<Interface>> RMI Here TransactionByRole TellerInterface Account() $ GOOD_CONN : int = 0 MgrTrans AtmTrans TellerTrans CustomerAccountForm (from TheServer) CustomerProfileForm (from TheServer)

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

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

  13. 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-Fledged Application • Demo is Limited to a Couple of Transactions • Goal is to Prove Java RMI Concepts, Interfaces, UML Support of Them in a Real World App • After This Phase, Ready to Jump to the Analysis Phase

  14. Final Development Applet and Connection BankConnection BankingApp $ GOOD_CONN : int = 0 $ UNK_CONN_ERR : int = 1 init() $ REMOT_ERR : int = 2 JMenuItem2_actionPerformed() $ NOT_BOUND_ERR : int = 3 JMenuItem2_actionPerformed_Interaction1() $ COMM_FAILED : int = 4 JMenuItem18_actionPerformed() $ ATM_CONN : int = 11 JMenuItem18_actionPerformed_Interaction1() $ TELLER_CONN : int = 12 JMenuItem2_actionPerformed_Interaction2() $ MGR_CONN : int = 13 myBankingAppCode_Logout() $ VERIF_FAILED : int = 14 +$MyBankConnection JMenuItem4_actionPerformed() $ TRANSACTION_PASSED : int = 20 JMenuItem4_actionPerformed_Interaction1() $ TRANSACTION_FAILED : int = 21 JMenuItem4_actionPerformed_Interaction2() createCustProfMenu_actionPerformed() Connect_To_Bank() createCustProfMenu_actionPerformed_Interaction1() Run_Query() closeMenu_actionPerformed() Login() closeMenu_actionPerformed_Interaction1() Logout() createNewAccountMenu_actionPerformed() SendCustomerProfile() createNewAccountMenu_actionPerformed_Interaction1() SendCustomerAccount() myBankingAppCode_ShowAllCustomers() Connect_To_ServerBank() JShowCustomersMItem_actionPerformed() LoginToServer() JShowCustomersMItem_actionPerformed_Interaction1() LogoutFromServer() ShowAllCustomers() APPLET AND ITS CONNECTION TO THE GUI CLIENT BANK ENGINE

  15. Final Development Main Client Application The Applet GUI IS To be Added To <<Interface>> The Model Later. Serializable (from io) CustomerProfileForm CustomerAccountForm (from TheServer) (from TheServer) FORM CLASSES FOR DATA TRANSFER Vector (from util) BankConnection <<Interface>> +BankServerTransaction 1 1 RoleTransactionInterface (from TheServer) CONNECTION CLASS WITH THE GUI <<Interface>> TellerTransactionInterface (from TheServer) <<Interface>> ServerTransactionInterface (from TheServer) +BankServerSession +BankSession 1 1 <<Interface>> <<Interface>> SessionInterface MgrTransactionInterface (from TheServer) RMI ENTRY VerifyUserNameAndPassword() HERE PerformLogout() <<Interface>> BranchServerInterface <<Interface>> (from TheServer) ServerInterface (from TheServer) <<Interface>> ATMTransactionInterface login() (from TheServer) logout()

  16. RMI Structure Client Object Server Object Stub Skeleton • Make Method Callable by Declaring Signature in Interface • Compile Class and Interface and Generate Stub and Skeleton

  17. RMI Flow of Events

  18. Server - Goals • Handle Multiple Virtual Connections • Have Multiple User Types, With Varying Privileges • Provide the Financial Services • Use of Database • Select Design Elements haven’t Been Coded • Server-Server Connection to have Hierarchy of Servers • Use of Distributed Database • Persistency of DB (Object Serialization)

  19. Server - Transaction Objects

  20. Server - Transaction Interfaces

  21. Server at Runtime - Login

  22. 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"); returnnull; }

  23. Server - Database • Designed to Support Persistency Via Object Serialization • Associations Are Vectors; Not Intuitively Displayed in Rose

  24. Server - Hierarchy

  25. Server - The Big Picture

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

  27. Server Application Hierarchy UnicastRemoteObject REMOTE SERVER (from server) UnicastRemoteObject() User readObject() clone() exportObject() Server Customer Acct Database -db accno : int #customers balance : float = (float)0.0 -transactions CustomerProfileForm SavingsAccount CheckingAccount +TheSavingsAccount CustomerAccountForm -users +TheCheckingAccount Vector -customers (from util) UTILITY CLASSES TheCustomerAccount AND FORMS AccountNumber : int #account BANK ACCOUNT AND Customer CUSTOMER INFORMATION

  28. 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; }

  29. 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; }

  30. 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");

  31. 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.");

  32. 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; }

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

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

  35. Softmodeler - A Next Generation UML Modeling Tool • 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

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

  37. 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 in Either Corba or Java RMI

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

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

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

  41. Component Diagrams Provide Facilities for Specifying Distinct Local & Remote Methods Specifying Distribution Method Required Support for the Simulation of Models During Analysis and Design Phase. Allows Specification of Properties With Access Rights Within Classes. Does Not Support State Diagrams and Activity Diagrams. Extensive Support for Component Diagrams Not Supported Not Supported Not Supported Supports All Constructs Defined in the UML Notation. SoftModeler vs. Rational Rose

  42. Component Creation

  43. ObjecTime Developer™ • Product of Objectime Limited • Http://www.Objectime.Com/ • Versions for C, C++ • Consider Themselves as the Leading Provider of • Software Engineering Tools • Middleware for Developers of Distributed Systems • Product Has Been Incorporated in Rational Rose® Realtime • Uses Extensions on UML to Incorporate Real-Time Aspects, Methodology Call ROOM • Bought Out by Rational - Now Rose-RT Product

  44. ObjecTime Developer™ - Features • Different Levels of Views for Developers and Customers • Executable Modeling Capability for Understanding Complex, Real-Time Systems • Tracing Messages Visually and Debugging Using Graphics • Supports Ability to • Build Model From Design • Load Model to Target Platform • Control & Animate Model From the Development Platform • Generates Entire Applications by Using Formal Methods That Allow Automatisation

  45. ObjecTime Developer™ - Features • Integrates Smoothly with Other Developement Tools and Operating Systems • Especially Real-time Operating Systems • Stated on Their Web Page: • ROOM Forms the Basis for UML-RT • Contains a Set of Real-time Extensions to UML • Will Soon to Be an OMG Standard for General Purpose Software Development

  46. UML-RT components • Capsules Represent Complex, Potentially Concurrent and Also Distributed Active Components • Port is Physical Part of Implementation of Capsule • Mediates Interaction of Capsule With Outside World • Includes Interface and Protocol [Signals]

  47. UML-RT components • Connectors Capture Key Communication Relationships Between Capsules • Relationships Have Architectural Significance • Relationships Identify Which Capsules Can Affect One Another Other Through Direct Communication

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

  49. Paradigm Plus - Business Process Model

  50. Paradigm Plus - Physical Database Modeling

More Related