ece750-topic11: component-based software systemsltahvild/courses/ece... · evolutionary: iterative,...
TRANSCRIPT
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
ECE750-Topic 11 3June 22, 2009
The Sequential/Waterfall Model
Development
Analysis
Design
Implementation
Integration
Test
ECE750-Topic 11 4June 22, 2009
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
ECE750-Topic 11 5June 22, 2009
The Iterative Model
Development
Analysis
Design
Implementation
Integration
Test
ECE750-Topic 11 6June 22, 2009
The Incremental ModelIncrement 1 2...n
Analysis
Design
Implementation
Integration
Test
Development
ECE750-Topic 11 7June 22, 2009
The Prototyping Model
Analysis
Design
Implementation
Integration
Test
DevelopmentDevelopprototype
Test prototype
ECE750-Topic 11 8June 22, 2009
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
ECE750-Topic 11 9June 22, 2009
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) ?
Choose Architectural
Decisions
ModelComponent
Market
ListImplementation
Approaches
Choose BestImplementation
Approach
Architecture-Based COTS Selection
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
Choose Architectural
Decisions
ModelComponent
Market
ListImplementation
Approaches
Choose BestImplementation
Approach
Architecture-Based COTS Selection
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
Architecture-Based COTS Selection
To determine the feasible selections
Enumerate the architectural approachesOf the form:Example:
Enumerate implementation approachesOf the form:Example:
nKADxKADKADAA L21=
Choose Architectural
Decisions
ModelComponent
Market
ListImplementation
Approaches
Choose BestImplementation
Approach
aex KADAA 1=
),( CAAIA =}),,{,( QtOgreDirectXAAIA exex =
ECE750-Topic 11 69June 22, 2009
Architecture-Based COTS Selection
Under the constraints of these set of components:
Covers all rows in the requirements matrixSatisfies all component dependenciesIs consistent with Architectural Approach
Choose Architectural
Decisions
ModelComponent
Market
ListImplementation
Approaches
Choose BestImplementation
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