ECE750-Topic11: Component-Based Software Systemsltahvild/courses/ECE... · Evolutionary: Iterative, incremental, agile, RUP . June 22, 2009 ECE750-Topic 11 3 The Sequential/Waterfall

Ladan Tahvildari, PEngLadan Tahvildari, PEngAssistant ProfessorAssistant Professor

Software Technologies Applied Research (STAR) Group Software Technologies Applied Research (STAR) Group

Dept. of Elect. & Comp. Eng.Dept. of Elect. & Comp. Eng.

University of WaterlooUniversity of Waterloo

ECE750-Topic11:Component-Based Software Systems

Component-Based Development Process

ECE750-Topic 11 2June 22, 2009

Software Development ProcessTypical Phases

Requirements analysis and specificationsSystem and architecture designImplementation and unit testingSystem integrationVerification and validationOperation and maintenance/evolution

Two general modelsSequential: Top-down and bottom-up Evolutionary: Iterative, incremental, agile, RUP


The Sequential/Waterfall Model

Development

Analysis

Design

Implementation

Integration

Test


The Evolutionary Development Develop a system gradually in many repetitive stages:

Increasing the knowledge of the system requirements and system functionality in each stage exposing the results to user comments

This can be achieved by using:The Iterative ModelThe Incremental ModelThe Prototyping Model


The Iterative Model

Development

Analysis

Design

Implementation

Integration

Test


The Incremental ModelIncrement 1 2...n

Analysis

Design

Implementation

Integration

Test

Development


The Prototyping Model

Analysis

Design

Implementation

Integration

Test

DevelopmentDevelopprototype

Test prototype


The Rational Unified ProcessA modern process model derived from the work on the UML and associated process.

Normally described from 3 perspectivesA dynamic perspective that shows phases over timeA static perspective that shows process activitiesA proactive perspective that suggests good practice


RUP Phase Model

Inception: Establish the business case for the systemElaboration: Develop an understanding of the problem domain and the system architectureConstruction: System design, programming and testingTransition: Deploy the system in its operating environment

ECE750-Topic 11 10June 22, 2009

Unified Process Illustrated

Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test

Iter #1 Iter #nIter #2 --- --- --- --- --- ---

An iteration in the elaboration phase

Phases

Iterations

ECE750-Topic 11 11June 22, 2009

ReusabilityThe main tenet of CBSEWhat to reuse

Requirements specifications and analysisDesign: generic or domain-specific design spec, design patterns, and architectural styles Implementations: open/closed source componentTest data

Two general types of reuseVertical Reuse – reusing domain-specific assets (e.g., visualization components) Horizontal Reuse – reusing generic assets, mostly as extemsions of programming languages (e.g., C++ STL)

ECE750-Topic 11 12June 22, 2009

Design with and for ReuseHow to reuse

Design for reuse, often called Domain EngineeringDesign with reuse, often called Application Engineering

Different assets from domain can be reused

Domain ModelDomain Design Implemented Components

ECE750-Topic 11 13June 22, 2009

Component-Based Development (CBD)In CBD, the two phases of design for and with reuse, is normally called:

Component Development – producing reusable components Some concerns

Business goalsLicensing Maintenance and support policyOpen-closed source (also called white-box and black-box reuse)

System Development – consuming components to compose and integrate systems

Based on end-user and stakeholders requirements Some concerns

Change propagation for provided and required interfacesHow do the available components fit into the requirements specifications

ECE750-Topic 11 14June 22, 2009

System Development Design with Reuse

Our goal if to have a development process Based on successful conventional processesCustomized for component-based development

Some new steps are added Finding the candidatesEvaluating and selecting the most suitable candidates Adapting and composing components

ECE750-Topic 11 15June 22, 2009

System Development Process

DevelopmentAnalysis

Design

Implementation

Integration

Test

Evaluation

Find

Select

Adapt

Integrate

Test

Component evaluation System Development

Matching component evaluation with system development

ECE750-Topic 11 16June 22, 2009

Simplified Process (I)

Define the requirements

Design the system Find & Select

Compose/Integrate

Adapt

Test & DeployOperation

&Maintenance

ECE750-Topic 11 17June 22, 2009

Simplified Process (II) Define the requirements

Capture system requirements from stakeholders Specify functional and non-functional requirements

Design the systemHigh-level architecture Specify main subsystems and components

Find and select the candidatesCollect information about appropriate components

Code repositories likes sourceForge, Google, Apache, IBM developerWorks, …

ECE750-Topic 11 18June 22, 2009

Simplified Process (III) Find and select the candidates (cont’d)

Evaluation and selection – based on the following criteria:Trust: dependability and security factors

It can be handled with software certifications (e.g., similar to the warning messages given by Microsoft Windows when installing an uncertified application)

Requirements: How does a candidate meet the requirement spec? Integration Effort: How hard is it to integrate the component with other components? Do we need glue code?Support: Are your issues going to be fixed? Can you ask for help? Pay for help? Alternatives: What happens if you cannot use the selected component? Is there any other alternative?Verification: Can you test the component?

ECE750-Topic 11 19June 22, 2009

Simplified Process (IV) Adapt

Configuring for the current systemProviding configuration file or rebuilding

Providing the adaptation codeAdjusting provided and required interfaces

With wrapper or adaptorCould be different for white-box and black-box reuse

Compose and Integrate Emergent properties

Composition of components may show unpredicted properties

Example: deadlock (an example will be discussed later)Different types of composition

ECE750-Topic 11 20June 22, 2009

Basic Types of CompositionSequential Composition where the composed components are executed in sequence. This involves composing the provided interfaces of each component.

Hierarchical Composition where one component calls on the services of another. The provided interface of one component is composed with the required interface of another.

Additive Composition where the interfaces of two components are put together to create a new component.

ECE750-Topic 11 21June 22, 2009

Basic Types of Composition

ECE750-Topic 11 22June 22, 2009

Interface IncompatibilityParameter Incompatibility where operations have the same name but are of different types

Operation Incompatibility where the names of operations in the composed interfaces are different

Operation Incompleteness where the provided interface of one component is a subset of the required interface of another

ECE750-Topic 11 23June 22, 2009

Incompatible Components

addressFinder

phoneDatabase (string command)string location(string pn)

string owner (string pn)

string property Type (string pn)

mapper

mapDB (string command)displayMap (string postCode, scale)

printMap (string postCode, scale)

ECE750-Topic 11 24June 22, 2009

Adaptor ComponentsAddress the problem of component incompatibility by reconciling the interfaces of the components that are composed

Different types of adaptor are required depending on the type of composition

An addressFinder and a mapper component may be composed through an adaptor that strips the postal code from an address and passes this to the mapper component

ECE750-Topic 11 25June 22, 2009

address = addressFinder.location (phonenumber) ;postCode = postCodeStripper.getPostCode (address) ;mapper.displayMap(postCode, 10000)

Composition through an AdaptorThe component postCodeStripper is the adaptor that facilitates the sequential composition of addressFinder and mapper component

ECE750-Topic 11 26June 22, 2009

Simplified Process (V) Test and deploy

Unit testing and integration testingMay discover that your selected components do not fit together

Operation and Maintenance/EvolutionOperation management

Reconfiguring and resource managementMaintenance/Evolution

Upgrading, patching or replacing components Disposal of components – normally missed in the development process

ECE750-Topic 11 27June 22, 2009

Component DisposalGenerally takes place due to two different factors:

Dissatisfaction initiated by consumers when they conclude that:

The component no longer provides the support of the system it was intended to provide orThe system no longer needs the component

Obsolescence is likely to occur when:A new, more effective component with the same, similar or extended functionality is foundPoor portability to new platforms/operating systemsThe producer is not able to continue with support or maintenanceThe component needs obsolete components

ECE750-Topic 11 28June 22, 2009

A More Realistic ProcessBased on “V” process

ECE750-Topic 11 29June 22, 2009

A More Realistic ProcessOperation & Maintenance may include

Adding new componentsReplacing components

The find/select, adapt, and test will be repeated

ECE750-Topic 11 30June 22, 2009

Composition and IntegrationIn theory

We connect required and provided interfacesIntegration s mostly based on interfaces and description of operations Component models help integration

Business interfaces in EJB

In practiceIt is not as simple as expected More details and contracts need to be known

ECE750-Topic 11 31June 22, 2009

Composition/Integration: 1st ExampleExample adopted from:

D. Garlan, R. Allen and J. Ockerbloom. “Architectural Mismatch: Why Reuse is So Hard,” IEEE Software, 12(6):17-26, November 1995.

The system: AESOPGenerates development environments tailored to development of systems in particular architectural styles Constituent components

Object-oriented database (OBST)GUI toolkit (Interview) Event-based tool integrations (HP SoftBench)RPC mechanism (MACH RPC Interface Integration - MIG)

All of the components are implemented using C and C++ Source code were available

ECE750-Topic 11 32June 22, 2009

AESOP Environment

ECE750-Topic 11 33June 22, 2009

Problems Effort

Estimate: six months (one person-year) Reality: two years (five person-year)

Excessive code

Poor performanceOverhead of connecting tools and database

Need to modify external packagesModifying client-loop event in SoftBench

Reinventing existing functions Hierarchical nested view management in Interview, because it didn’t allow direct access to nested view

ECE750-Topic 11 34June 22, 2009

Underlying Issues Nature of components

Assumption aboutInfrastructure – e.g., all tools have GUIControl model – e.g., Where is the main thread of control? Where is the main loop? Data model – e.g., the assumptions about the nature of data each component manipulating

Nature of connectorsAssumption about

Interactions – e.g., request/reply protocol or event notificationData model – e.g., the format of data which us transferred between components

ECE750-Topic 11 35June 22, 2009

Underlying Issues (cont’d) Global architecture

For example, in this case OO DB component assumes that there us no interaction between components

It blocks all tools when one is working with dataFor solving this problem, the team added another transaction manager

Error-prone construction/composition processDependencies in generated codes by different tools As they built the system, modifications became increasingly costly

ECE750-Topic 11 36June 22, 2009

Proposed Solutions for Composition Make assumptions explicit

Having these assumptions leads to find the problem sooner Unfortunately, still there is no notation for documenting architectural assumptions

How to say that a component has an event loop?

Use orthogonal loosely-couple components in reusable assets

Use bridging techniques to resolve interface mismatchesWrapper or adaptor

Provide design and composition guidanceGeneric and domain-specific

ECE750-Topic 11 37June 22, 2009

Composition/Integration: 2nd ExampleExample adopted from:

P. Inverardi, A.L. Wolf, and D. Yankelevich, “Static Checking of System Behaviors Using Derived Component Assumptions,” ACM Transactions on Software Engineering, 9(3):239-272, July 2000.

The main point is that component users Not only need the specifications of component’s interactions behavior But also, they need specifications if the assumptions that the component makes about the expected interactions behavoir of other components

ECE750-Topic 11 38June 22, 2009

Composition/Integration: 2nd ExampleThe authors use a “guest analogy”

Assume H: Host, P: Host’s Partner, Y: YouAt a party:

H & Y: greet at door, invite inH & P: introduce Y to P P & Y: take to living room, offer a drink and introduce Y to others

Suppose that by any reason H does not introduce you to P You feel uncomfortable with people you don’t knowIt is insufficient only your interaction with environment, and need to also consider intra-environment interactions

ECE750-Topic 11 39June 22, 2009

Compressing Filter: 2nd ExampleNow consider this example

Adding data compression to a web serverThe main goal is to improve performance of www browsers over slow networks

Assume the web server is the standard CERN HTTP server

The web server has a pipe-and-filet architecture style

ECE750-Topic 11 40June 22, 2009

Compressing Filter: 2nd ExampleWe want to add an external filter to compress data using gzip

The external compressing filter communicates with the web server through Unix pipes

Read and write data

A pseudo filter (adaptor) has been added to work with the external compressing filter

ECE750-Topic 11 41June 22, 2009

Compressing Filter: 2nd Example

Filter FilterPseudo Filter(Adaptor)

gzip

1

2 3

4

Compressing Filter

Process

Component

Channel

Function call interface

UNIX pipe interface

ECE750-Topic 11 42June 22, 2009

Compressing Filter: 2nd ExampleHTTP server filters are forced to read when data are pushed at themHowever, Unix filters choose when to reda data

So, gzip may block

Normal caseAdaptor passes the data from upstream filter to gzip, and when the stream us closed, read the data from gzip, and write it to downstream filter

Problematic case (Emergent Property)Because gzip has a limited internal buffer, it may attempt to write a portion of compressed data before the adaptor is ready

gzip blocks and then adaptor blocked Deadlock!

ECE750-Topic 11 43June 22, 2009

Compressing Filter: 2nd ExampleIn this example, the solution is not hard

Adaptor can handle data incrementally and use unblocking reads and writes

However, for composing more complex systems Component developers need to document these assumptions (not straightforward!!)In this article, the authors build models of component and its environment that enables static analysis of deadlock freedom.

ECE750-Topic 11 44June 22, 2009

Suggested Solutions for Component CompositionPredictable Assembly for Certified Components (PACC)

http://www.sei.cmu.edu/pacc/Component certifications

Pre- and post-conditions Mathematical models for reliabilityComponent credential (extra-functional properties) In this example, the solution is not hard

Prediction-Enabled Component Technology (PECT)http://www.sei.cmu.edu/pacc/pect_init.htmlA component model plus the analysis model

ECE750-Topic 11 45June 22, 2009

Prediction-Enabled Component Technology (PECT)

Component Model

AnalysisModel

Component Model

AnalysisModel

assumptions

interpretation

PECT

not connectedspecializesinfluences

Based on two fundamental premises:

The system quality attributes are emergent properties that are associated with patterns of interaction among components

The software component technologyprovides a means of enforcing predefined and designed interaction patterns, thus facilitating the achievement of system quality attributes by construction

ECE750-Topic 11 46June 22, 2009

COTS Definition“Commercial Off the Shelf” Software

Commercial Software Productssold, leased, licensed at advertised prices

Source Code UnavailableOnly application program interface (API)

Usually periodic releases with feature growth or obsolescence

ECE750-Topic 11 47June 22, 2009

COTS: Commercial Off the ShelfBlack Box: modifications to code internal to COTS product not allowedWhite Box: some modifications to code internal to COTS product permitted

GFE: Government Furnished Equipment

GOTS: Government Off the Shelf

NDI: Non-Developmental Item/Not Developed In-house

Related Terms

ECE750-Topic 11 48June 22, 2009

Using COTS in Software ProjectsA survey at USC (2002)

28% use in 1997 70% in 2002

CBA Growth Trend

00.10.20.30.40.50.60.70.8

1997 1998 1999 2000 2001 2002

Year

%

ECE750-Topic 11 49June 22, 2009

AdvantagesAvailable now;earlier payback Avoids expensive development & maintenancePredictable license costs & performanceRich in functionalityBroadly used, mature technologyFrequent upgrades often anticipate organization’s needsDedicated support organizationHardware/software independenceTracks technology trends

COTS Advantages and DisadvantagesDisadvantages

Licensing and intellectual property procurement delaysUp front license feesRecurring maintenance feesReliability often unknown/ inadequate; scale often difficult to changeUnnecessary features compromise usability, performanceNo control over upgrades/maintenance Dependency on vendorIntegration not always trivial; incompatibilities among vendorsSynchronizing multiple-vendor upgrades

ECE750-Topic 11 50June 22, 2009

Case Study: When it Works…Hubble Space Telescope Control Center Software was redone

This restructuring began in 1995 and it was the so-called Vision 2000 project to extend the life of the Hubble telescopeVERY Data-IntensiveThey had a goal of not interrupting ongoing data-collection

Goals:Use COTS to save moneyExtend life of HST until 2010

Mission-critical softwareHigh performance requirementsHigh security requirements

ECE750-Topic 11 51June 22, 2009

Case Study: When it Works…Final Product

Integration of 30+ COTS/GOTS components with 1M lines of legacy code using .5M lines of glue code

ResultsReplaced 3M lines of source codeProof of concept delivered in 3 monthsLive system delivered in 1 yearBrand new architecture delivers greater functionalityVery encouraging

ECE750-Topic 11 52June 22, 2009

COTS ActivitiesCOTS Assessment is the activity whereby COTS products are evaluated and selected as viable components for a user application

COTS Tailoring is the activity whereby COTS software products are configured for use in a specific context

COTS Glue Code development and integration is the activity whereby code is designed, developed, and used to ensure that COTS products satisfactorily interoperate in support of the user application

ECE750-Topic 11 53June 22, 2009

COTS AssessmentDivides up into three stages

Trade Study: A ‘quick and dirty’ filtering of a large number of components

Hands-on Evaluation: A more thorough analysis of the remaining components

Final Selection: Selection based on the results of previous stages

ECE750-Topic 11 54June 22, 2009

COTS Assessment Process

ECE750-Topic 11 55June 22, 2009

Trade StudyBreak down your requirements

These will form the basis for questions on a questionnaireRequirements should be of similar granularitiesSend questionnaire to vendors and current users

Component Requirements Matrix

Components that receive less than half of the total points, don’t move on

When no COTS move on, this is the time to consider Reviewing your requirementsDeveloping custom code

ECE750-Topic 11 56June 22, 2009

Components Requirements Matrix

Weight requirements are based on a 0-10 scale where 10 is betterBased on responses from questionnaires, give 0, .5, or 1 to each category

0 is not fulfilling requirement.5 is partial satisfaction1 is total satisfaction

ECE750-Topic 11 57June 22, 2009

Hands-On EvaluationYou must actually have access to the components

Necessary if component represents a significant investment

Use components as the basis for testsScenario-Based TestsExamining Specific Criteria

ECE750-Topic 11 58June 22, 2009

Hands-On Evaluation

ECE750-Topic 11 59June 22, 2009

Criticism of this TechniqueThis technique is primarily requirements-driven

Tends to select “best-in-breed” componentsShould be tailored to reflect internal requirements

Assumes clean division of requirements

Full assessment not always cost effective

ECE750-Topic 11 60June 22, 2009

Component Selection: RevisedThe previous technique selecting components was fundamentally requirements-based

Now you will see a technique for selecting components that is architecture-based

Goal:Avoid the problems encountered in “Architectural Mismatch”

Low level interoperabilityProgram languagesPlatform dependenciesData base schemas

Different trade-offs in non-functional terms

ECE750-Topic 11 61June 22, 2009

Architecture-Based COTS SelectionWhen using COTS, you accept their architectural restrictions

Component selection and architecture definition are intertwined

Here we’ll use a simple case study to exemplify the points

Case study come from Mancebo2005

ECE750-Topic 11 62June 22, 2009

Has four stepsiterative process

Here we will select components for a multimedia presentation application

Think “PowerPoint 3D”

Choose Architectural

Decisions

ModelComponent

Market

ListImplementation

Approaches

Choose BestImplementation

Approach

Architecture-Based COTS Selection

ECE750-Topic 11 63June 22, 2009

Possible architectures are modeled as a decisions spaceExamples:

1. Should graphics object know how to render themselves (KAD1a), or should they be decoupled from rendering (KAD1b)?

2. Should objects keep track of time individually (KAD2a), or should their be master synchronization object (KAD2b)?

3. Should presentations be stored in XML format (KAD3a) or as serialized objects (KAD3b) ?


Decisions

ModelComponent

Market

ListImplementation

Approaches


Approach


ECE750-Topic 11 64June 22, 2009

Perform analysis of available components

Create matrices reflecting the assumptions a capabilities of components

Requirements FulfillmentComponent Dependency Architectural Assumptions


Decisions

ModelComponent

Market

ListImplementation

Approaches


Approach


ECE750-Topic 11 65June 22, 2009

Requirements Fulfillment Matrix

XGUIWidgets

XX3d Text

XXAudio

XXGraphicsAPI

QTOGLFTOpenALOpenGLDirectXOgre

The X axis is the potential components would be considered usingThe Y axis lists user’s requirements An X represents that that particular component fulfils a particular requirement

ECE750-Topic 11 66June 22, 2009

Component Dependency Matrix

XGLTT

XOGLFT

XDirectX

XOgre

OpenGLMFCGraphics

API

The Y axis is the potential componentsThe X axis is things on which those components depend.An X represents that that particular component fulfils a particular dependency

ECE750-Topic 11 67June 22, 2009

Architectural Assumptions Matrix

KAD2

KAD3

1aKAD1

DirectXOgre

Should graphics object know how to render themselves (KAD1a), or should they be decoupled from rendering (KAD1b)? Should objects keep track of time individually (KAD2a), or should their be master

synchronization object (KAD2b)?Should presentations be stored in XML format (KAD3a) or as serialized objects

(KAD3b) ?

Ogre assumes decision 1a that graphics objects must know how to render themselves.

NOTE: Only one is constrained by one component. So we can eliminate decisions 2 and 3 from our matrix. This is a good thing. Usually what will happen is that in examining potential components on the market, we will find new architectural decisions that we must choose between. This is why this process must be iterated.

ECE750-Topic 11 68June 22, 2009


To determine the feasible selections

Enumerate the architectural approachesOf the form:Example:

Enumerate implementation approachesOf the form:Example:

nKADxKADKADAA L21=


Decisions

ModelComponent

Market

ListImplementation

Approaches


Approach

aex KADAA 1=

),( CAAIA =}),,{,( QtOgreDirectXAAIA exex =

ECE750-Topic 11 69June 22, 2009


Under the constraints of these set of components:

Covers all rows in the requirements matrixSatisfies all component dependenciesIs consistent with Architectural Approach


Decisions

ModelComponent

Market

ListImplementation

Approaches


Approach

}),,{,( MFCOgreDirectXAAIA exex =

ECE750-Topic 11 70June 22, 2009

SummaryComponent-based development includes two main phases

Component Development (design for reuse) System Development (design with reuse)

System DevelopmentThere is a sequence of finding, selecting, and testing components

This sequence may be repeated in the operation and maintenance/evolution as well

There may be also custom development

ECE750-Topic 11 71June 22, 2009

SummaryComponent Development

Save time and effort in software projectsMay bring more predictability of cost and performanceCan reuse successful components with appropriate support

System composition/integration may confront problems

Mainly due to hidden assumptions about ComponentsConnectorsGlobal ArchitectureComposition Process

Documents

ECE750-Topic11: Component-Based Software Systemsltahvild/courses/ECE... · Evolutionary: Iterative, incremental, agile, RUP . June 22, 2009 ECE750-Topic 11 3 The Sequential/Waterfall