1 / 11

An Overview of The COTS-Aware Requirements Engineering and Software Architecting Project (CARE/SA)

An Overview of The COTS-Aware Requirements Engineering and Software Architecting Project (CARE/SA). The University of Texas at Dallas Department of Computer Science Fall 2004. Topics. COTS-Aware? Issues, Motivation Introduction to COTS-Aware Requirements Engineering and Architecting

una
Download Presentation

An Overview of The COTS-Aware Requirements Engineering and Software Architecting Project (CARE/SA)

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. An Overview ofThe COTS-Aware Requirements Engineering and Software Architecting Project(CARE/SA) The University of Texas at Dallas Department of Computer Science Fall 2004

  2. Topics • COTS-Aware? • Issues, Motivation • Introduction to COTS-Aware Requirements Engineering and Architecting • Overview of the CARE/SA Approach • Validation of CARE/SA • Digital Library System • Summary and Future Work

  3. Why COTS-Aware? • Current state-of-the-art COTS approach (e.g. Rational Unified Process): • Develop Requirements • Develop Architecture • Develop Detailed Design and Consider COTS • COTS Components Must Meet Functional AND Non-functional Requirements AND Fit With the Architecture • Detailed design phase is too late • Difficult to find COTS components, costly to change requirements, architecture, detailed design, and test cases • Consider the use of COTS components earlier i.e., in the Requirements and Architecting workflows

  4. Why COTS-Aware? • Software Engineering Issues for CARE/SA • Customer “Satisficing” • Meet the non-functional goals and requirements in a “good enough” sense • Flexibility of Customer Requirements • Specification, Matching, Selecting, Integrating COTS Components • Goal- and Agent-oriented • Model Based • Process, product, meta-model • Knowledge Based • Should Consider the Impact on Entire SDLC

  5. Why COTS-Aware? • Effective Use of COTS Components is a Complex Problem • COTS Issues have been categorized as: • Technical Issues • Acquisition, Selection, Interactions, Incomplete product information, ... • Business Issues • Loss of Autonomy • Costs/benefits: short term vs. long term • Legal Issues • Licensing

  6. Overview of CARE/SA • Our Methodology • Iterative strategy • Define, extend/refine, and validate CARE/SA models and tool support • Re-use, extend existing processes, models, standards (e.g., tailor RUP, extend SPEM, re-use OMG MOF, …) • Validate using examples from a Digital Library System, Telepresence system, Home Appliance Control System, and Groupware application • Large scale, complex systems with a rich set of functional and non-functional requirements

  7. Overview of CARE/SA • CARE/SA considers how to represent and reason about: • Agents • Goals • Software Requirements • Software Architecture • COTS Components • Relationships Among Artifacts (new traceability required) • Mapping System Goals to COTS Components • Mapping Software Requirements to COTS Components • Mapping Architectural subsystems to COTS Components • Tracing Agent to Goals • Tracing Goals to Software Requirements • Tracing Goals and Requirements to Architecture Subsystems • Constraints (or rules) Among Artifacts • Defining NFR Framework relationships (makes, helps, hurts, breaks) • …

  8. Overview of CARE/SA RE and CE Expertise Initial System Concept, System Goals Software Requirements Component Repository Define Architecture (with COTS) Architecture, SA Decisions, Update Component Goals, Specs 5 SA SA and CE Expertise Initial System Concept, System Goals Software Requirements Component Repository Architecture Update Component Goals, Update Component Specs. RE and SA Expertise System Goals Software Requirements Architecture Component Repository Define Requirements (with COTS) Agents, Goals, Requirements RE Decisions, Update Component Goals, Specs 5 Maintain Component Repository 6 Updated Component Repository, CE Decisions RE CE High Level View of the Process Model (IDEF0 Notation)

  9. Component 2 Component n Reqs. Reqs. Reqs. Architecture Architecture Architecture Softgoal2 Goal1 Component 1 Overview of CARE/SA Component Repository (Component Requirements, Architecture, …) System Under Development (System Goals, Requirements, Architecture…) … Goaln Software Architecture Software Requirement Subsystem Architecture Software Requirement … Subsystem Architecture … Software Requirement Architecture Elements Architecture Elements Mapping System Goals to Component Goals Mapping Requirements to Component Specification Mapping Architectures to Component Specifications Agent Mapping Goals, Requirements, and Architecture Subsystems to COTS Components

  10. Validation • We have applied CARE/SA to part of a Digital Library System (DLS) • Partial illustration below is from MPEC 2004 paper

  11. Summary and Future Work • CARE/SA approach • Supports the definition of agents, goals, software requirements, COTS components and architectural elements • Demonstrated using an example from a Digital Library System • Detailed description of CARE and examples are available in TR UTDCS-11-02, www.utdallas.edu/~kcooper • Note. The process model is being ported from IDEF0 to activity diagrams in UML • This term? • Additional validation using scenarios • Extend the CARE Assistant Tool (CAT) to support the scenarios and make it widely available to researchers • Investigate alternative reasoning techniques for COTS matching and selection

More Related