RO-1.1 Research Efforts in Software Engineering Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut Storrs, CT (860)

RO-1.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)

RO-1.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

RO-1.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

RO Reusable Component Framework(Demurjian) Demonstrating Levels of Generality DairyItemDeliItem Item ProduceItem NonPerishItemPerishItem BigYProdItemDoleProdItemBigYDairyItemHoodDairyItem Where can Item be Reused? Where can NonPerishItem and PerishItem be Reused? Where can ProduceItem and DairyItem be Reused? Are DoleProdItem and HoodDairyItem Specific?

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

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

RO-1.8 Reusable Component Framework(Demurjian) The DRE Tool - Version 2.02

RO-1.9 Reusable Component Framework(Demurjian) Reusability in Together CC

RO-1.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:  See:

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

RO-1.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

RO-1.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

RO-1.14 Role-Security in Distributed Environment (Demurjian) Legacy COTS Database NETWORK (LAN, WAN) Java Client Java Client How is Security Handled for Individual Systems? for Individual Systems? Security Issues for New Clients? New Servers? Across Network? What if Security Never Available for Legacy/COTS/Database? for Legacy/COTS/Database? 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?

RO-1.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)

RO-1.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  I 5 : 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

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

RO-1.18  The Five Levels of I 5  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) Architectural Specification/Deployment of Distributed Systems(Demurjian/Shvartsman) Abstraction Detail

RO-1.19 Dependencies Between Levels Component TypesNode Types INTERFACE IMPLEMENTATION INTEGRATION INSTANTIATION INSTALLATION Component ClassesNode Classes Implementation Dependencies Inst. ComponentsInst. Nodes Installation Req. (together,separated) Installation Req. (fix location) Complete Installation System Instantiation

RO-1.20 A First Look at the Interface Level  Component and Node Types Are Specified As Well As Their Connections. PNODE CITY PUZZLE SLIST PATH USERBASE TCP/IP types INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

RO-1.21 A First Look at the Inheritance Level  Two Types of Inheritance:  Implementation  Inheritance  Interface  Refinement WINDOW DIALOG BOX x_window x_dialog box w_window w_dialog box classes types INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

RO-1.22 A First Look at the Implementation Level  Implementation Constraints State the Class of Node Where Each Implementation Class of Component Should Run puzzleslistpath user > stereotypesclasses INTERFACE INHERITANCE IMPLEMENTATION INSTANTIATION INSTALLATION

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

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

RO-1.25 Architectural Specification/Deployment of Distributed Systems(Demurjian/Shvartsman)  Benefits of I 5  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  

RO-1.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