COTS-Aware Requirements Engineering and Software Architecting

1. COTS-Aware Requirements Engineering and Software Architecting Lawrence Chung and Kendra Cooper Department of Computer Science University of Texas at Dallas {chung, kcooper}@utdallas.edu

2. Why COTS (Commercial-Off-The-Shelf)? • Perceivedbenefits – cheaper, faster, better software development by orders of magnitude! • Issues • Gaps between requirements and COTS components - high degree of usage vs. high degree of satisficing - COTS components must meet both functional and non-functional requirements, … and at the same time fit with the architecture • Many (more types of) stakeholders • Many more sources of changes - Customer needs, new technology – hw/sw/infrastructure, new/similar products, etc. - Evolution of COTS components & Discontinued components - Legal issues ((chain of) licensing, open-source,…) & Standards

3. Outline • Bridging the gap • Defining, Matching, Ranking, and Selecting COTS Components in the CARE/SA Process • Capturing Requirements (FR & NFR) & Architecture Components • Matching, Ranking, and Selecting COTS Components

4. Bridging the Gap:COTS Components Capabilities System Under Development (SUD) Requirements Component SUD Goal Exact match G - j G - i Transformed SUG Goal Transformed Component G - j1’ G - i1’ Transformed SUG Goal Transformed Component G - i1’’ G - j1’’ G - i is an agent's goal Another exact match Transformed SUG Goal G - k G - j2’ How do we bridge the gap systematically?

5. Defining Goals; Matching, Ranking, and Selecting COTS Components in the CARE/SA Process Define Goals create a System Goal Model using scenarios Select Components Based on ranking, select set of COTS components Match Goals search for COTS components with goals that match SUG soals (functional & non-functional) Negotiate Changes Rank Components Perform a gap analysis to rank COTS components using the NFR Framework What do we represent and where ?

6. Capturing Requirements (FRs & NFRs) & Architecture Components Architectural Subsystem Architectural Subsystem Software Requirement Component Repository (Foreign Goals, Specifications, …) System Under Development (Native Goals, Requirements, …) in SUD Product Repository Customer Manager End User Development Manager Requirements Engineer Component Repository … External System ++ (NFR) Softgoal2 Softgoal3 … HardGoal1 Component 2 (whitebox) … System Requirement System Requirement … SUD Artifacts Software Requirement Component 1 (blackbox) Legend Agent Softgoal Mapping System Goals to Component Goals Mapping System, Software Requirements to Component Specification Hardgoal Architecture Subsystem Requirement

7. Matching, Ranking, and Selecting COTS Components. • With a non-functional candidate goal COTS Architecture to (other) COTS NFR SUD NFR to COTS NFR COTS NFRs to (other) SUD NFRs SUD Product SUD Product COTS Component SUD Product COTS Component COTS Component Model Repository Model Repository Repository Model Repository Repository Repo sitory j C C … C … … … … … R … R A R A … … … … NFR NFR NFR k NFR j i i i Legend Softgoal (non - functional) Candidate softgoal COTS Component Possib le Match Candidate Hardgoal Hardgoak And Decomposition C Component, A Architecture, R Requirement, FR Functional requirement, NFR Non-Functional Req.

8. Matching, Ranking, and Selecting COTS Components. • With a functional candidate goal COTS Architecture to COTS NFR SUD FR to COTS FR COTS NFRs to (other) SUD NFRs SUD Product SUD Product COTS Component SUD Product COTS Component COTS Component j Model Repository Model Repository Repository Model Repository Repository Repository i C C C … … … … … … … R R A R A … … … FR FR NFR FR NFR i i i i Legend Softgoal (non - functional) Candidate softgoal COTS Component Possib le Match Candidate Hardgoal Hardgoak And Decomposition C Component, A Architecture, R Requirement, FR Functional requirement, NFR Non-Functional Req.

9. Preliminary Softgoal Interdependency Graph and COTS Component Repository part of the CARE/SA knowledge base - populated for a DLS before the Goals of the SUD are matched, ranked and selected wrt the Goals of the components). COTS Component Repository SUD Product Model Repository C Secure Good Performance Java Authentication & Authorization Service … Easy to Use Interface … Search theCatalog - … Architecture Requirements R A Configurable Interface … Variety of Non - functional Requirements Functional Requirements Interface Options Encryption FR PC platform NFR Role Based Touch Screen Interface C C PDA Protect Tivoli Access Control Novice Configuration GUI C Authentication Audio/Video Security, communication, multimedia, compressi on, etc. components … Expert Configuration User Interface

10. Results of Matching, Ranking, and Selecting COTS components part of the CARE/SA knowledge base - populated for a DLS after the Goals of the SUD are matched, ranked and selected wrt the Goals of the components). COTS Component Repository SUD Product Model Repository Java Authentication & Authorization Service Good Performance Secure … Easy to Use Interface … Search theCatalog C - … Configurable Interface R A + Variety of Interface Options Encryption + Tivoli C PC platform + C PDA Protect Role Based + R A Access Control Novice Configuration Touch Screen Interface + R A GUI Authentication Audio/Video + … Expert Configuration Security, communication, multimedia, compression, etc. components User Interface - - + Inadequte: {PDA Protect} Potentially good-enough: {JAAS, Tivoli}

11. Conclusions • Contributions • Systematic methodology for using COTS components in developing software architecture • COTS components as aggregates of FRs, NFRs, and architectures • Requirements-driven matching, ranking and selection • Future Work • More matching, ranking and selection heuristics • Definition of meta-model (in relation to the UML) • Web-based tool support