Architecting Adaptable Software Using COTS: An NFR Approach

1. 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, annayi}@utdallas.edu

2. 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

3. Our Approach: ACASA(Adaptable COTS-Aware Software Architecting) • Evolution of ACASA CARE CASA ACASA • 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

4. Architectural Subsystem Software Requirement Architectural Subsystem CASA: Mapping Native Goals, Requirements & Architecture Components to Foreign Goals, Specifications & Architecture Components Component Repository (Foreign Goals, Specifications, …) System Under Development (Native Goals, Requirements, …) 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

5. ACASA: An NFR Approach • Represent COTS reqs & SUD (System Under Development) reqs: • functional reqs (OO) + NFRS (softgoals), with agents • Represent architectural constituents: • <components, connections, constraints, patterns, styles> • 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

6. 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.

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

8. ACASA: Architecting Process Step 1 Order Groups of SUD Capabilities Match SUD Capabilities to Step 2 COTS Component Capabilities For each COTS Component: Is COTS Component Blackbox ? Yes No Match SUD Adaptability Requirements Step 3 Match SUD Adaptability Requirements Step 3 COTS Components Architecture Subsystem COTS Component to to Case 1 Case 2 Adaptability Requirements Adaptability Requirements Identify COTS Component Step 4 Solutions Rank COTS Component Step 5 Solutions Select COTS Component Step 6 Solutions All SUD Functional Requirements No Processed? Yes ACASA Process Utilizes NFR Framework

9. Pan, Tilt, Zoom Control signals (control the movement of the camera) ) Camera Head mounted display with head tracking and earphones Display Al, Sue, and John in Dallas can see, hear, and spe ak to Erin. Microphone Illustration: Architecting Adaptable Telepresence System Would you like to experience your presence in an environment at a different location? Force feedback joystick Audio, Video from Al, John and Sue Microphone Audio,Video control signals Video from Erin Video control signals Digital camera Erin in NewYork can see, Audio from Erin hear, speak, or move closer/farther away from Audio control signals Al, Sue, Jo hn Speaker

10. 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.

11. 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.

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

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

14. Step 4. Identify COTS Component SolutionsStep 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 SUD-R3@now of SUD-FR3.2, SUD-FR3.7, SUD-Adaptability-NFR3.4, SUD- Adaptability-NFR3.6: COTS-3 … }

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

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

17. Step 4. Identify COTS Component SolutionsStep 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 SUD-R3@now of SUD-FR2.2, SUD-FR2.3, SUD-Adaptability-NFR2.4: COTS- 6 … }

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

19. 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)