Research Efforts in Software Engineering

1. Research Efforts in Software Engineering Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve http://www.engr.uconn.edu/cse (860) 486 - 4818

2. Overview of Presentation • Reusable Component Framework (Demurjian) • Data Consistency, Interoperability and Architectural Design (Demurjian/Shin) • Security Issues for Distributed Applications Comprised of Legacy/COTS (Demurjian) • Architectural Specification/Deployment of Distributed Systems (Demurjian/Shvartsman) • Summary: Potential Interactions (All)

3. Reusable Component Framework (Demurjian) • Popular OO Methodologies Omit/Ignore Reuse • Current Research Concentrates on Consumer (Reuser) and Not Producer (Creator) • Two-Fold Goal • Elevate Reuse to Equal Partner • Domain-and-Organization Specific Reuse • Capabilities of Evaluation Techniques • Identify the Reusable Portions of Design/Code • Estimate/Measure Reusability Automatically • Support Refactoring Guidelines for Reuse Improvement • For Newly Created Designs and Legacy Code • Design Reuse Evaluation Tool: C++ and Java

4. Reusable Component Framework(Demurjian) General/Specific Characterization • Best Estimate on Potential Utility of Class • General Class (G) • Those Application Classes that Facilitate Domain-and-Organization Specific Reuse • Abstract Classes/Root Classes/Non-Leaf Classes in Inheritance Hierarchies • Specific Class (S) • Only Applicable in Current Applications • Unlikely to be Reused in Future Applications • Purposes • Determine Classes with Highest Reuse Potential for Organization’s Future Systems • Quantify Dependencies that Hinder Reuse

5. Reusable Component Framework(Demurjian)Demonstrating Levels of Generality Item NonPerishItem PerishItem ProduceItem DairyItem DeliItem BigYProdItem DoleProdItem BigYDairyItem HoodDairyItem Where can Item be Reused? Where can NonPerishItem and PerishItem be Reused? Where can ProduceItem and DairyItem be Reused? ... Are DoleProdItem and HoodDairyItem Specific?

6. Reusable Component Framework(Demurjian)Reusability in Supermarket Domain Root classes for Items, ItemDB, etc., which are Most General. Inventory Control Other Components. Inventory Control Tool for Ordering Items from Suppliers Cost Accounting Tool for Tracking Net and Gross Profit Classes Specific to Grocery Store Domain. Specific Applications for Big Y or Shaw’s or Stop/Shop (S)

7. Reusable Component Framework(Demurjian)Reusability in Supermarket Domain Root classes for Items, ItemDB, etc., which are Most General. Classes Specific to Grocery Store Domain. Inventory Control/Other Components. Classes for Large Supermarket Classes for Specialty Supermarket Classes for 24 Hour Convenience Specific Applications for Big Y or Shaw’s or Stop/Shop (S)

8. Reusable Component Framework(Demurjian)The DRE Tool - Version 2.02

9. Reusable Component Framework(Demurjian)Reusability in Together CC

10. Reusable Component Framework(Demurjian) Status and Objectives • Work Currently Funded by Electric Boat, Inc. (T. Rando, T. Daggett, and M. Price) and Jointly Conducted with USNA (Dr. D. Needham) • Planned Research Over Next 12 Months • Complete Prototypes (DRE /TCC) • Genetic Algorithm for Refactoring/Assessment • Formal Reuse Model • XML/Reuse • Research - Through 2004 • Focus on Comprehensive Reuse Framework • Guided Reusability Assessment/GA Analysis • Component Repository with Search Capabilities • Leverage Domain/Organization Specificity • UML, XML, and Java Components • See:http://www.engr.uconn.edu/~steve/DRE/dre.html

11. Data Consistency, Interoperability and Architectural Design (Demurjian/Shin) COTS Database Legacy Legacy COTS NETWORK (LAN, WAN) Java Client Java Client Legacy Database COTS How do Systems and Applications Interact? What are Performance Constraints? What Platforms Must Interact? How are New Clients Added? New Servers Added? What is the Role of XML, JDBC, ODBC, JINI, CORBA?

12. Data Consistency, Interoperability and Architectural Design (Demurjian/Shin) • Reuse in a Distributed Computing Environment • Reuse Legacy/COTS in Innovative Ways • Not Cost Effective to Redesign/Reimplement • Wrappers for Cohesive/Seamless Interactions • Apply to Languages (C, C++, Ada, etc.) and Paradigms (OODBS, CORBA, RPC) • Address Communication, Translation, Security, Concurrency, Performance, Bandwidth, etc. • Communications Alternatives Dictated by Domain • Low-Level (Sockets) vs. Mid-Level (RCP, RMI) vs. High-Level (CORBA, DCOM, …) • Message/Database Translations via XML

13. Data Consistency, Interoperability and Architectural Design (Demurjian/Shin) • Consistency in Distributed Environment • When is Data Sent from Client to Legacy Server? • Automatic (Regular) vs. User-Initiated? • When Network Traffic is Low? • Distributed Computing Spans Broad Spectrum • Database Interoperability • Many Platforms (Oracle, Sybase, Infomix, …) • Translation Between Different Databases • Exploring XML Capabilities • Funding: • Current: State of CT Insurance Department • Previous: Mitre Corp, Eatontown NJ

14. Role-Security in Distributed Environment (Demurjian) COTS Database Legacy Legacy COTS NETWORK(LAN, WAN) Java Client Java Client Legacy Database COTS How is Security Handled for Individual Systems? What if Security Never Available for Legacy/COTS/Database? Security Issues for New Clients? New Servers? Across Network? Can Software Agents be Utilized for Distributed Security? Authentication Is the Client who S/he Says they are? Authorization Does the Client have Permission to do what S/he Wants? Privacy Is Anyone Intercepting Client/Server Communications?

15. Role-Security in Distributed Environment (Demurjian) • Can we Provide Customized Control to APIs of Legacy, COTS, Databases? • API Typically Public to All • No Explicit way to Prohibit Access • Only Exactly What’s Needed and No More • Current Research/Prototyping of Constraint-Based Distributed Role-Security Model • Integrated Prototype on NTs/Linux Using Java, Oracle/Access, and JINI/VisiBroker • Security Authorization/Management Tools • Clients Limited in API Usage Based on Role • Web Page Currently Under Development • Work Currently Funded by AFOSR(Previously Mitre)

16. Architectural Specification/Deployment of Distributed Systems(Demurjian/Shvartsman) • Architect/Deploy of Distributed Software • Formal Definition (textually in Z or graphically in UML) of a Distributed Application • (Re)Deploy (Existing) New Distributed Application • Distributing Standalone Legacy Application • I5 : An Integrated Five-Level Specification Framework for Distributed Systems • Support for the Architectural Specification of OO and Component Based Distributed Systems • With a Uniform Notation and With Different Levels of Abstraction

17. Architectural Specification/Deployment of Distributed Systems(Demurjian/Shvartsman) Integrated Framework for Design and Deployment SOFTWARE HARDWARE Dependencies Deployment Performance: Efficient Use of Resources w.r.t. Throughput/Number of Messages

18. Architectural Specification/Deployment of Distributed Systems(Demurjian/Shvartsman) • The Five Levels of I5 • Interface (I1) - Types of Components, Nodes and Connectors • Implementation (I2) - Classes of Components, Nodes and Connectors • Integration (I3) - Dependencies Between Component and Node Classes • Instantiation (I4) - Instances of Each Class Definition • Installation (I5) - Deployment of Each Instance (Requirements and Complete Deployment) Detail Abstraction

19. Dependencies Between Levels Component Types Node Types Component Classes Node Classes Inst. Components Inst. Nodes Installation Req. (together,separated) Installation Req. (fix location) INTERFACE IMPLEMENTATION Implementation Dependencies INTEGRATION System Instantiation INSTANTIATION INSTALLATION Complete Installation

20. A First Look at the Interface Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Component and Node Types Are Specified As Well As Their Connections. TCP/IP PUZZLE TCP/IP PNODE TCP/IP USER BASE SLIST CITY PATH types

21. A First Look at the Inheritance Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Two Types of Inheritance: • Implementation • Inheritance • Interface • Refinement x_window x_dialog box WINDOW classes w_window DIALOG BOX w_dialog box types

22. A First Look at the Implementation Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION puzzle slist path <<supports>> <<supports>> <<supports>> user • Implementation Constraints State the Class of Node Where Each Implementation Class of Component Should Run classes stereotypes

23. A First Look at the Instantiation Level INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION • Instantiation Identifies the Instance Components and Computers of Each Class That Form Part of the Actual System puzzle: PUZZLE user1: USER user2: USER pnode: PNODE slist1: SLIST instances slist2: SLIST base1: BASE base2: BASE city: CITY path: PATH

24. Complete Installation city: CITY pnode: PNODE puzzle: PUZZLE slist2: SLIST slist1: SLIST path: PATH user1: USER user2: USER base2: BASE base1: BASE

25. Architectural Specification/Deployment of Distributed Systems(Demurjian/Shvartsman) • Benefits of I5 • Organize Design of New Systems and Documentation of Existing Systems • Firm Basis for Configuration Management • UML Usage Exploits Large User Community • Other Aspects of Framework • Binary Integer Programming Model • Optimal Deployment Based on Communication • Tested on Toy, Seek Real OO Applications • Explored Genetic Algorithm for Deployment • Ph.D. Research of C. Bastarrica • http://www.dcc.uchile.cl/~cecilia/ • http://www.dcc.uchile.cl/~cecilia/publicaciones.html

26. Summary: Potential Interactions (All) • Funded Interactions • Faculty Consulting (Year Round/Sabbaticals) • Funded Research Contracts to UConn • Faculty Funding During Summer/Academic Year • Graduate Student Research Assistantships • Cooperative Research Funding • Collaborations • Faculty Presentations • Industry Presentations (CSE Courses) • Graduate/Undergraduate Semester Projects