The CT Insurance Department Project

1. The CT Insurance Department Project Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

2. Overview of Presentation • Overview of CT Insurance Project - Concepts • A Quick Review of Java • Software Engineering and Architectural Issues • Language and Database • Evaluation Tools (Design & Development) • Software Architectural Structure • Design Alternatives and Tradeoffs • Applet vs. Application • RMI for System Interactions • Documentation Standards and Design Models • Example GUI/System Functionality • Summary

3. The CT Insurance Department Project • Purposes • Upgrade Computing Environment to 21st Century Technologies • Support all Existing Capabilities • Add New Functionality that Provide More Opportunities for Personnel to Perform Their Jobs in a Cost Effective Manner • Institute Philosophy that Promotes Future Improvements and Extension to eCommerce • Partnership of • CT Insurance Department Personnel • UConn’s Computer Science & Engrg. Dept. • GentronicsWang Corporation • Merrill Clark Corporation

4. Software Architectural Structure A First Licensing Prototyping Database Server Running Oracle Initial Data Entry Operator (Scanning & Posting) Advanced Data Entry Operators Analyst Manager 10-100MB Network RMI Registry Document Server Stored Images/CD RMI Act. Obj/Server RMI Act. Obj/Server Functional Server

5. Business Process Model: Scanning and Initial Data Entry DB DB DB DB DB Historical Records Completed Applications Licensing Supervisor Review Scanner Licensing Division Scanning Operator Stored Images Printer Licensing Division Data Entry Operator . . Basic Information Entered New Licenses New Appointments FOI Letters (Request Information, etc.)

6. Software Engineering and Architectural Issues • Java is Emerging Programming Language of Choice for Majority of Software Development • Distributed Internet-Based Applications • Legacy/COTS Integration • General-Purpose, Single-CPU Development • Specifically Targeted for eCommerce • Oracle will be Database System Platform • Proven System with Long, Stable History • Underlying Relational Database Management is Workhorse of Industrial Applications • Ability to Interact with Existing and Emerging Technologies • Still to be Determined Technologies for Document Scanning and Storage

7. Software Engineering and Architectural Issues • Design and Development Tools • GDPro vs. Paradigm vs. Rose vs. Together/J • Vis. Café v. Jbuilder v. Jdeveloper v. WebDB • Software Architectural Structure • Design Alternatives and Tradeoffs • Applet vs. Application • Relevant Issues for Both • Insurance Agents vs. Department Employees • Designing for Today and Tomorrow • Software Engineering Process • Documentation for Users: Contract • Documentation/Design Models for Developers • Standards for Developers: Maintenance

8. Design and Development Tools • GDPro vs. Paradigm vs. Rose vs. Together/J • What are Advantages of Each? • What are Drawbacks of Each? • What are Documentation Capabilities of Each? • Integration of UML Diagrams • Cost vs. Support vs. Training • Visual Café v. Jbuilder v. Jdeveloper v. WebDB • What is Best Tool for Rapid GUI Prototyping? • What is Best Tool for Non-GUI Client Code? • What is Best Tool for RMI/Servlet Code? • What is Best Tool for Database Server Code? • Impact of Tool Choice on Long Term Maintenance/Evolution - re. Ins. Agent GUI

9. UML Design ToolsThe Players • GDPro 3.2 • Advanced Software Technologies Inc. • www.advancedsw.com • Paradigm Plus Enterprise Edition 3.6 • Computer Associates International • www.cai.com • Rational Rose 98 Enterprise Edition (August 98) • Rational Software Corporation • www.rational.com • Together/J Version 3.0, Developer Edition • TogetherSoft LLC • www.togethersoft.com

10. UML Design ToolsThe Evaluators • Scott Craig, Graduate Student, UConn • Strong Background in UML • Long-Time User of Rational Rose • Steven A. Demurjian, Professor, UConn • Software Engineering/Object-Oriented Researcher • Minimal Experience with Rational Rose • Earl DuBack, Migration Facilitator Manager, CT Insurance Dept. • Significant Expertise with Numerous Design and Documentation Methods • Minimal Experience with UML

11. Comparing UML Design ToolsGDPro and Paradigm Plus • Drawbacks of Both: • Awkward to Learn and Use • Neither Provided a Hierarchical View of the Packages in the Application being Modeled • Hierarchical View Akin to File Hierarchy/Explorer • Necessary to Organize Design into Units • Supports Concurrent Design by Team Members • Facilitates Transition to Implementation • Minimal Code Editing/Generation Capabilities • No Round-Trip Engineering • S. Craig Found Both Difficult to Use Given his Experience with Rational Rose • Overall, Lacking in Key Facets which are Critical to Support the Goals of Our Project

12. Comparing UML Design ToolsRational Rose • Was Expected to be Chosen Tool • Familiarity of Tool with Numerous Team Members • Rational Influence re. Three Amigos (Booch, Rumbaugh, Jacobson) who Defined UML • Long Established Product Commercially Utilized Throughout Industry/Academic/Gov. • But, Significant Drawbacks • Round-Trip Engineering Lacking • Minimal Java Support • JDK 1.1.6 Can be Loaded into Rose • Efforts with JDK 1.2 Unsuccessful

13. Comparing UML Design ToolsRational Rose • Significant Drawbacks - Continued • Limited to Design and Documentation • No Support to Edit Generated Code within Rose • Would Require Extensive Bookkeeping for Migrating Code Changes to Design and Vice-Versa • Some Rose Diagrams Violated UML Standard • Dependencies Among Use-Cases Not Allowed • To Achieve, Utilize Generalization and Stereotype with <<include>> and <<extend>> • Awkward to Use and Counter-Intuitive • Overall, Despite S. Craig’s History with Rose, the Tool was Inadequate as Compared to Together/J

14. Comparing UML Design ToolsTogether/J • Key Benefits and Features: • Integrated Java Code Editor with UML Diagrams • Changes to Code Immediately Propagate to UML Diagrams • Changes to Diagrams Immediately Propagate to Code • Changes to Code in External Tool (Visual Café) are Reflected in UML Diagrams after File Save • Support for Round-Trip Engineering • As Mentioned in Above Change Propagation • Ability to “Load” Java Source Code Not Created in Together/J and Tool Generates UML Diagrams

15. Comparing UML Design ToolsTogether/J • Key Benefits and Features: • Hierarchical View of Application • Similar Capability to Rational Rose • Allows Modularization of UML Design • Integration with JDK 1.2.2 • Ability to Load Zip/JAR File to Bring in All JDK 1.2.2 Classes and APIs • UML Designs can Utilize APIs/Classes • Simplifies Transition to Software Development by Allowing Specifics to be Included • For Example, GUI Classes, JDBC Interactions, etc., can All be Modeled

16. Choosing Together/JOther Considerations • Support for Version Control • Ships with Concurrent Versions System(CVS) • CVS Allows Multiple Users on Different Workstations Running Together/J to Share Common UML Design Repository • Insures Consistency of Application and Its Model Elements • Ease of Use • For Rose Users, Together/J has Similar Look and Feel: Easy to Switch to Together/J • For Non-UML Users, One Evaluator Found it Easier to Learn and Utilize Together/J • Rational Rose - Less Intuitive • Together/J - Easy Transition to UML Design

17. Evaluating Development Tools Visual Café/Jbuilder/Jdeveloper/WebDB • What is Best Tool for Rapid GUI Prototyping? • Chosen Visual Café re. Project Team Recommendations and Past Experience • Targeting Visual Café 4.0 Expert Ed. ($799) • Caveat: Café Recently Sold to BEA • What is Best Tool for Non-GUI Client Code? • Exploit Editing Capabilities of Together/J • Transition to Visual Café • What is Best Tool for Database Server Code? • Still Evaluating • Potential for Jbuilder and/or Café • Role of DBDesigner for ER Design and Relation Generation

18. Software Architectural Structure Design Alternatives and Tradeoffs • What is Current Software Structure? • How are Components Deployed on Workstations? • How can Components be Redeployed in Future? • What Architecture Facilitates Rapid Prototyping and Requirements Capture in Short Term? • How do we Transition for “Real” System? GUI Client Web Server at DOIT Servlets Interaction Abstraction Oracle Database Server RMI

19. Current Architecture from Scott Craig <<Applet>> <<Servlet>> client Licensing Servlet External Updated Oracle Daily 120-160 (20-30 Licensing) JDBC Internal <<Application>> Licensing Oracle RMIimpl Licensing RMI

20. Design Alternatives and Tradeoffs What are Critical Design Considerations? • Internal Clients vs. External Clients • Evolvability with respect to … • Adding New Clients Over Lifetime of Project • Adding/Changing Post-April 2001 • Easily Upgrading Components … • Changes re. New Versions of Java/Browsers • Adding More Web-Servers, Functional Servers, Database Servers • Supporting External Clients (Mirror Site DOIT) • Replacement of Database/OS (Drastic Changes) • What are Dimensions of Extensibility that are Supported by Architecture? • Where is Concurrency/Data Consistency Handled?

21. Software Architectural Structure Design Alternatives and Tradeoffs • What is the “Optimal” Architecture? • For Rapid Prototyping • For “Real” System • For “Long-Term” Maintenance & Evolution • For “Anticipated” Future Users (Agents, etc.) • For “Ease of Adopting” Future Technologies • Do we Need a “Single” Architecture? • How Do we Transition Between Architectures? • Where is Concurrency/Data Consistency Handled? • Any Responsibility in Client? • Is there Functional Server Between Client and Database? • Will Database System be Sole Arbitrator?

22. Software Architectural Structure Applet vs. Application • Applet: Web Browser or Applet Viewer • Downloaded from Web Server to Client • Allows Transparent Changes to “Code” -- Next Download Provides “New” Code • All at Once Download • Incurs Overhead During Initial Download • System Must Handle “Hot” Spots of Activity During AM, After Lunch • On-Demand Download • Incurs Overhead Throughout Usage of Client • Download from Web Server Still Uses Network which Competes with Database Queries by Clients • Is One Approach More Complex than Another? • Regardless of Approach, Need Modularization

23. Software Architectural Structure Applet vs. Application • Application • Standalone Application Installed as Program on Client Workstations • Startup Incurs Network Traffic Only on Load of “Custom Parameters and Values” from DB • Changes to Application Require Reinstallation on Each Platform • Automatic Update for New Releases • Small Number of GUI Clients (30??) • Should AdvDataEntryOp have Application Due to Size and Complexity of Software? • Will InitDataEntryOp Utilize Downloaded Applet Due to Lack of Complexity?

24. Software Architectural Structure Summary: Applet vs. Application • Does Client Software Need to be Incorporated into Browser? • Any Capabilities Client Can Utilize within Browser as Applet that Aren’t Available as Application (or Vice Versa)? • Web Sites Can be Accessed by Applet or Application • Application Can Load Browser Based on Situation • Will Browser Version and Incompatibility with Java Cause Difficulties in Maintenance? • Different Versions use Different Java Versions • Unresolved Sun/Microsoft Suit re. Java • Is Application Approach “Safer”

25. Software Architectural Structure Summary: Applet vs. Application • What Software will Different Levels of Employees Require? • Scanner/Basic Client for InitDataEntryOp • Image/Client/Netscape for AdvDataEntryOp • What is Tradeoff re. Screen Space and Number of Active Programs? • Remove Extra Space Needed for Browser? • Recall Tasks in Separate Windows • Do we Need a Unified Approach for Both Internal Clients (Dept. Employees) and External Clients (Insurance Agents and Others)? • Does Frequency of Changes Influence Choice? • How Often Laws Change vs. GUI Changes

26. Software Architectural Structure Summary: Expanding Scope • We’ve had Two Interfaces so Far … • InitDataEntryOp to Enter Basic Information • AdvDataEntryOp for New/Modified Licenses • For AdvDataEntryOP - • Not All Users Can Do All Functions • Customizability - via DB or SW Versions? • Other Divisions and Corresponding GUIs • What is Management Challenge for Maintaining and Distributing … • All at Once Downloaded Applets • On-Demand Downloaded Applets • Installed Applications • How are Various “Approaches” Managed?

27. Software Architectural Structure Choice: Application over Applet • All GUIs for CT Insurance Department Employees • Chosen for Following Reasons: • Installing Applications Reduces Network Traffic During Startup • Increases Screen Real-Estate Since Browser Not Needed • Removes Dependence on Browser Versions • Eliminates Uncertainty re. Microsoft’s Support of Java within Internet Explorer • Note: • System Still Positioned for Internet Based Interactions by Insurance Agents/Firms

28. Software Architectural Structure A First Licensing Prototyping Database Server Running Oracle Initial Data Entry Operator (Scanning & Posting) Advanced Data Entry Operators Analyst Manager 10-100MB Network RMI Registry Document Server Stored Images/CD RMI Act. Obj/Server RMI Act. Obj/Server Functional Server

29. Using RMI in Licensing Prototype Adv. Data Entry Analyst Manager rmid rmiregistry Activation Object ActivatableImplementation.java Unicast Remote Object LicensingImpl Unicast Remote Object LicensingImpl Unicast Remote Object LicensingImpl rmiregistry 1100 rmiregistry 1101 rmiregistry 1102

30. Using RMI in Licensing Prototype Adv. Data Entry • Client Looks Up Activation Object • rmid Creates New Activation Object • rmid Binds Activation Object Interface to Client rmid rmiregistry • Client can Now Directly Communicate with Unicast Remote Object Implementation Class(LicenseImpl) • Client Can Invoke Methods and Receive Results • Client Requests a Unicast Remote Object Activation Object ActivatableImplementation.java • Activatable Object Returns to Client All Necessary Info Unicast Remote Object LicensingImpl • Activatable Object Creates New Unicast Remote Object and Binds to Unique Name on a Registry (Round Robin) rmiregistry 1100

31. Software Engineering Process Documentation for Users: Contract • Existing Documentation and Interviews to Determine Current and Future User Requirements • Documentation of Business Processes and Rules • Creation of Use Cases by Development Team • Transition From Use Cases to PowerPoint Presentations • Provide Means to Capture Requirements in Easy to Understand Medium • Utilized for Give-and-Take and Sign-Off • Need for “Written” Scenario Description to Accompany PPT • Creation of “How System Works” and “How to Use System” Documents/GUI Mockups in Café

32. Software Engineering Process Doc./Design Models for Developers • What is System Documentation? • From Use Cases to … • Scenarios for Developers • Static Views: Class, Object, Component, Deployment Diagrams • UML Extension: Robustness Diagrams • Dynamic Views: Sequence, Collaboration, Statechart, Activity Diagrams • Which Diagrams are Relevant at Which Stages of Design and Development Process? • Are All Diagrams to be Utilized for Project? • What are Most Likely Diagrams? Time

33. Software Engineering Process Standards for Developers: Maintenance • What Documentation Requirements and Standards are Required? • Use Cases Plus Accompanying Textual Descriptions • Use Case Development Standards • PowerPoint Versions of Use Cases • Others??? • What are Software Development Standards? • What are Configuration Management/Version Control Standards? • Who will Play the Role of Librarian?

34. Business Process Model: Scanning and Initial Data Entry DB DB DB DB DB Historical Records Completed Applications Licensing Supervisor Review Scanner Licensing Division Scanning Operator Stored Images Printer Licensing Division Data Entry Operator . . Basic Information Entered New Licenses New Appointments FOI Letters (Request Information, etc.)

35. Utilizing the Work Queue Next License Application Supervisor Work Queue Issue Rejection Letter Issue New License New License Application Work Queue Operator Requests Next License Application in Work Queue

36. Licensing GUIsCapabilities and Tasks • Scanning Business Process • Scan Documents and Enter Basic Information • Verify Readability of Scanned Documents • Scanned Documents Automatically Enter a Work Queue for Subsequent Processing • Create Historical Record for Each Action of Scanning Personnel • Historical Record Allows: • Tracking Productivity by Examining Who Scanned Which Documents • Ability to Provide History of Application, License, etc., when Processing Question from Agent, FOI Request, etc.

37. Licensing GUIsCapabilities and Tasks • Processing Work Queue Elements Which Contain: • License Applications • Documents Requested by Insurance Dept. • Appointments/Re-appointments • FOI Requests, etc … • Each Work Queue Element Contains One or More Scanned Images to be Processed • Result of Processing • Modify Historical Record • Create Entry in Oracle Database • Document Sent to CD-Rom Repository • Errors/Problems Forwarded to Analyst

38. Licensing GUIsCapabilities and Tasks • Additional Capabilities: • Process Problem Work Queue Elements • Route Specific Elements to Advanced Data Entry Operator • Set Privileges and Capabilities of Personnel • Handle Inquiries: FOI, NAIC, Legislature, etc. • Database Administrator Capabilities (DBA): • Responding to Special Requests • Maintaining Oracle Database • Investigating Data Consistency

39. GUI Login

40. Application Scanning

41. Work Queue

42. Data Entry

43. Licensing GUIsCapabilities and Tasks • Additional Capabilities: • Set Privileges and Capabilities of Personnel • Handle Inquiries: FOI, NAIC, Legislature, … • Supervisor Review Queue • Reclassify Work Queue Elements • Investigations, Statistics, Analysis Reports • Manager Review Queue, Work Flow • Management Reports • Database Administrator Capabilities (DBA): • Responding to Special Requests • Maintaining Oracle Database • Investigating Data Consistency

44. Examples of User-Specific TasksCustomizing GUI Based on User User #1 Authorization User #2 Authorization • License Applications • Producer • Casualty Adjuster • Public Adjuster • License Change • Producer • Casualty Adjuster • Public Adjuster • Viatical Settlement Broker • Letter of Certification • License Applications • Producer • Casualty Adjuster • Certified Insurance Consultant • Public Adjuster • License Change • Producer • Casualty Adjuster • Public Adjuster • Certified Insurance Consultant • Viatical Settlement Broker • Letter of Certification • Duplicate License • Freedom of Information

45. GUIs for Other Divisions • Exploit Licensing GUI as Blueprint for all Other GUIs • Utilize Similar Look-and-Feel Across GUIs • Customize GUIs for Business Models and Desired Processing for Each Division • Reuse Software Components to Speed Development • Key Issues • Realize Existing Computing Functionality • Offer New Capabilities for Tracking Trends, Historical Data, Productivity, etc.

46. Current Software ArchitectureIssues and Decisions • Utilizing Two-Tiered Approach • RMI Too Costly • Employ Middle Layer to “Hide” Relational Data and Oracle Platform from GUI/Client • Stage Data To/From “Java” Instances for Processing by Client • Adopt Strategy Similar to Java Blend • Develop “Classes” to Represent Database Views Needed by Different Tasks • May Exploit EJB in Future • Still Haven’t Chosen Document Management Sys.

47. DB Server Contains Relations Views Client Application Must Store/Retrieve Between GUI and Database Contrast of Class vs. Relation Objects vs. Tuples Creation of Java Classes One Class per Relation License Relation Yields License Class Class Contains Gets, Sets, and Iterator One Class per View New Appl. View Yields New Appl. Class Gets, Sets, and Iterator Current Software ArchitectureDatabase/Middle-Tier Interactions Database Server Running Oracle Java Classes One Per Relation Translation Java Classes One Per View

48. Client Interacts with Middle-Tier for Processing Middle-Tier Provides Repository for Storing Information for DB Information from DB Client Interacts with Multiple Relations Multiple Viewsfor Each Processing Task Java Classes Existing within “Conceptual Middle Tier Allow Information to be Staged To/From Database Utilized by GUI Client for All Processing Provides Transparency of Database to Client Current Software ArchitectureDatabase/Middle-Tier Interactions Java Classes One Per Relation Utilization Java Classes One Per View

49. Software Design and Analysis • Developing “Reusable” GUI Client for Licensing Employees • Intend to Reuse Across Different Divisions • In January 2001 Timeframe, Utilize DRE • Initial Evaluation of “Reuse” Potential • Assignment of General and Specific Classes • Incremental Use of DRE on Different Prototyping Versions • Guide Development Process Towards Future Reuse • Key Issue: We Understand the Domain!

50. Summary • What Decisions have we Made? • UML Tool - Together/J • Development Tool - Visual Café • Database Tool - DBDesigner • State of Current Prototyping Status • Employing Together, Visual Café • Integrating with Oracle Database Server at UConn • Utilizing Source Code Control System for Managing • Database Relations • UML Designs • Java Code