architecting adaptable software using cots an nfr approach l.
Download
Skip this Video
Download Presentation
Architecting Adaptable Software Using COTS: An NFR Approach

Loading in 2 Seconds...

play fullscreen
1 / 19

Architecting Adaptable Software Using COTS: An NFR Approach - PowerPoint PPT Presentation


  • 150 Views
  • Uploaded on

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. Why COTS ( C ommercial- O ff- T he- S helf)? Why more?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Architecting Adaptable Software Using COTS: An NFR Approach' - hazelle


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
architecting adaptable software using cots an nfr approach

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

why cots c ommercial o ff t he s helf why more
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 a daptable c ots a ware s oftware a rchitecting
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
slide4

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

acasa an nfr approach
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
nfr framework
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 framework7

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
acasa architecting process
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

illustration architecting adaptable telepresence system

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

cots components
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
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.

slide14
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 …

}

step 2 match sud capabilities to cots component capabilities head mounted display
Step 2. Match SUD Capabilities to COTS Component Capabilities (Head Mounted Display)
slide17
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 …

}

slide18
Step 2. Match SUD Capabilities to COTS Component CapabilitiesStep 3. Match COTS Components that Provide Adaptability (Authentication)
conclusions
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)
ad