Architecting Adaptable Software Using COTS: An NFR Approach Lawrence Chung Kendra Cooper Anna Yi Department of Computer Science University of Texas at Dallas {chung, kcooper,

Why COTS (Commercial-Off-The-Shelf)? Why more? (Perceived) benefits with use of COTS components – improvements by orders of magnitude - quick-build, well-tested, etc. Want: utilize COTS for the same benefits in architecting adaptable software. Issues Many (more types of) stakeholders and sources of changes Customer needs (enhancements, new env., technology changes – hw/sw/infrastructure, new/similar products, etc.) Evolution of COTS components & Discontinued components Legal issues ((chain of) licensing, open-source,…) & Standards Added complexity high degree of usage vs. high degree of satisficing Here, COTS components must meet both functional requirements and non-functional requirements, … and at the same time fit with the architecture Adaptability hardly addressed, or ad hoc at best

Our Approach: ACASA (Adaptable COTS-Aware Software Architecting) Evolution of ACASA CARECASAACASA COTS-Aware Requirements Engineering (CARE) Consider COTS as a requirements activity Agent-oriented, Goal-oriented, knowledge-based, defined process Uses NFR Framework to Match, Select, and Analyze COTS Components based on goals and requirements COTS-Aware Software Architecting (CASA) Extension of CARE Considers COTS as a requirements and software architecting activity Agent-oriented, goal-oriented, knowledge-based, defined process Applies the concepts of the NFR Framework to define the software architecture Now, Adaptable COTS-Aware Software Architecting (ACASA) specialization of CASA that focuses on adaptability requirements

CASA: Mapping Native Goals, Requirements & Architecture Components to Foreign Goals, Specifications & Architecture Components Mapping System Goals to Component Goals Mapping System, Software Requirements to Component Specification Legend AgentSoftgoal Hardgoal Requirement Architecture Subsystem Component Repository (Foreign Goals, Specifications, …) System Under Development (Native Goals, Requirements, …) Component Repository SUD Artifacts … Softgoal 3 Softgoal 2 System Requirement System Requirement HardGoal 1 Software Requirement Software Requirement End User Requirements Engineer External System Customer Manager Development Manager … … … ++ (NFR) Component 1 (blackbox) Architectural Subsystem Architectural Subsystem Component 2 (whitebox)

ACASA: An NFR Approach Represent COTS reqs & SUD (System Under Development) reqs:  functional reqs (OO) + NFRS (softgoals), with agents Represent architectural constituents:  Select COTS architectural components according to:  COTS functional reqs (COTS components) satisficing SUD functional reqs  Use adaptability as a main selection criteria among the candidate COTS architectural components Maintain rationale behind matching and selection Offer both run-time and design-time adaptability

NFR Framework non-functional requirements (NFRs), are treated as goals (softgoals) to be achieved allows for: refinements of (often unclear and subjective) adaptability requirements exploration of alternatives to achieve the softgoals systematic analysis of tradeoffs among the alternatives evaluation of the degree to which such softgoals are achieved.

NFR Framework representation: softgoal interdependency graph Adaptability Run-time (dynamic) Adaptability Design-time (static) Adaptability Run-time Self- Adaptability Run-time External Adaptability Design-time Self- Adaptability Design-time External Adaptability

ACASA: Architecting Process ACASA Process Utilizes NFR Framework

Illustration: Architecting Adaptable Telepresence System Would you like to experience your presence in an environment at a different location? Digital camera Force feedback joystick Microphone Video from Erin Erin in NewYork can see, hear, speak, or move closer/farther away from Al, Sue, John Speaker Audio, Video from Al, John and Sue Audio,Video control signals Video control signals Audio from Erin Audio control signals

COTS Components COTS Component #1: The camera shall cap1.1 be a black and white pan/tilt/zoom camera with 22X zoom and 460 TVL of resolution.; cap1.2 provide 300° pan / 120° tilt with 90°/sec. speed. Adaptability-NFR1.3COTS The output ports shall support: S video RS-232C (used to daisy chain up to seven cameras). cap1.4 Manual focus and exposure shall be supported. ; cap1.5 Automatic focus and exposure shall be supported. cap1.6 The infra-red remote control shall operate from the front and back of camera. COTS Component #2: The camera shall cap2.1 be a color pan/tilt/zoom camera with 10x Optical Zoom, 40x with Digital Zoom, 470 TV lines resolution cap2.2 provide Pan/Tilt Horizontal ± 100 deg (Max speed 300 degrees/s), Vertical ± 25 deg (Max speed 125 degrees/s) (in 0.07 deg incr) cap2.3 The output ports shall support VBS, Y/C, video signal NTSC, and RS-232-C.; cap2.4 The infra-red remote control shall operate from the front of the camera. cap2.5 The zoom, focus, pan, tilt, exposure shall be controlled using the included infrared remote control or by computer through an RS-232C serial connection. cap2.6 provide manual focus and exposure capabilities Note. Daisy chaining cameras not supported. COTS Component #3: The camera shall cap3.1 be a color pan, tilt, zoom camera with 16X zoom and 460 TVL of resolution. cap3.2 The field of view supported shall range from 3 to 47.5 degrees (65 degrees with wide angle lens adapter). Adaptability-NFR3.3COTS The 5 output ports shall support: S video, NTSC video, and 2 RS232 ports (to control the camera from a PC or daisy chain up to 8 cameras). cap3.4 Manual focus and exposure shall be supported.; cap3.5 Automatic focus and exposure shall be supported. COTS Component #5 : The head mounted display shall cap5.1 input NTSC or SVGA signals; cap5.2 automatically select between NTSC and VGA depending on which is connected. cap5.3 support SVGA resolution (800 x 600). cap5.4 support color, 3D video..; cap5.5 provide stereo audio. COTS Component #6 The head mounted display shall cap6.1 input S-video signals.; COTS-Adaptability-NFR6.2 support SVGA and SXVGA resolution. cap6.3 support 24 bit color depth, 3D video.; cap6.4 provide RCA stereo audio. cap6.5 support a field of view: 26 Degrees diagonal, image size: 76" at 13'.; cap6.6 support a head tracking capability. COTS Component #7 cap7.1 The orientation tracking component shall track movement in three dimensions. COTS Component #8 cap8.1 JAAS supports user-based authorization. cap8.2 It implements a Java version of the standard Pluggable Authentication Module (PAM) framework cap8.3 JAAS can be used to determine who is executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet.

Step 1. Order Groups of SUD Capabilities SUD Camera Requirements SUD-cap3.1 The remote system shall use pan/tilt/zoom cameras to supply video image and microphones to supply audio. SUD-cap3.2 The cameras shall provide manual and automatic focus capabilities. SUD-cap3.3 The remote system shall send synchronized audio and video to the Head Mounted Display (with headphones) at the local site. SUD-Adaptability-NFR3.4 The configuration of the remote site shall be adaptable during the operation of the system and support configurations of two to six cameras and two to eight microphones. SUD-cap3.5 The video output of the cameras at the remote site shall be S-video (i.e., Y/C). SUD-Adaptability-NFR3.6 If a camera at the remote site fails, then the system can detect this and adapt the system by switching to the remaining two cameras to obtain the video feed while the system is running. SUD-cap3.7 The cameras shall be color cameras. SUD Head Mounted Display Requirements SUD-cap2.1 The system shall be able to display the image of the remote meeting site to a local user with a head mounted display. SUD-cap2.2 The head mounted display video image shall be in color and be 3-dimensional. SUD-cap2.3 The head mounted display video shall be displayed in such a way that the viewpoint displayed changes in accordance with the local user’s head movements (orientation). SUD-Adaptability-NFR2.4 The resolution of the head mounted display system shall be dynamically adaptable by the system to provide VGA or SXVGA. SUD-cap2.5 The default resolution of the head mounted display shall be of SXGA (1280 x 1024). SUD Authentication Requirements SUD-cap6.1 The system shall support identification and password authentication. SUD-cap6.2 The system shall support fingerprint scanning authentication. SUD-Adapatability-NFR6.3 The system shall be configurable to support identification and password or fingerprint scanning authentication when the system is installed.

Step 2. Match SUD Capabilities to COTS Component Capabilities (Camera)

Step 3. Match COTS Component (Camera) for Adaptability Requirements

Step 4. Identify COTS Component Solutions Step 5. Rank the COTS components Step 6. Compose the Architectures (Camera) Step 4: Two components are selected {COTS Component #2, COTS Component #3} Step 5: MAKE run-time adaptation alternatives:  HELP run-time adaptation alternatives: {COTS Component #3} MAKE development-time adaptation alternatives: {COTS Component #2} HELP development-time adaptation alt.}: {COTS Component #2, COTS Component #3} Step 6: {case of SUD-FR3.2, SUD-FR3.7, SUD-Adaptability-NFR3.4, SUD- Adaptability-NFR3.6: COTS-3 … }

Step 2. Match SUD Capabilities to COTS Component Capabilities (Head Mounted Display)

Step 3. Match COTS Components (Head Mounted Display) that Provide Adaptability

Step 4. Identify COTS Component Solutions Step 5. Rank the COTS components Step 6. Compose the Architectures (Head Mounted Device) Step 4: {COTS Component #6, COTS Component #5, COTS Component #7} Step 5: MAKE run-time adaptation alternatives:  HELP run-time adaptation alternatives: {COTS Component #6} MAKE development-time adaptation alternatives: {COTS Component #5, COTS Component #7}} HELP development-time adaptation alt.}: {COTS Component #5, COTS Component #6, COTS Component #7} Step 6: {case of SUD-FR2.2, SUD-FR2.3, SUD-Adaptability-NFR2.4: COTS- 6 … }

Step 2. Match SUD Capabilities to COTS Component Capabilities Step 3. Match COTS Components that Provide Adaptability (Authentication)

Conclusions Contributions Systematic methodology for using COTS components in developing adaptable software architecture – an NFR-driven, repository-based approach. Future Work More matching techniques and selection heuristics Definition of meta-model (in relation to the UML) Tool support (from CASA Assistant to ACASA Assistant)