2/9/2015

1

COMPONENT BASED SOFTWARE DEVELOPMENT –LECTURE -2

Dr. Fazal-e-Amin

DR. FAZAL-E-AMIN

AGENDA Lecture 2Software Reuse Software Reusability Component Based Software DevelopmentComponent Definition Component TypesComponent Development process

DR. FAZAL-E-AMIN

2/9/2015

2

SOFTWARE REUSE

Reuse of software refers to the phenomenon when a new software is developed using all or some of the available components. And those components were not developed originally for this new software.

Reuse has different form as discussed in last weeks lecture.

DR. FAZAL-E-AMIN

SOFTWARE REUSABILITY

Its an ability

“reapplication of various kinds of knowledge about one system to another system in order to reduce the effort of developing and maintaining that system” [REF].

DR. FAZAL-E-AMIN

2/9/2015

3

REUSE INTENSIVE SOFTWARE DEVELOPMENT

The reuse-intensive software development methodologies such as CBSD and SPL

reuse software artifacts to develop new products. In CBSD, software components are

composed to develop software systems.

DR. FAZAL-E-AMIN

REUSABLE SOFTWARE ASSETS

The term ‘software assets’ include the artifacts developed during software development process. The reusable artifacts range from the highest level artifact i.e. software architecture to the lowest level ‘objects’. At the source code level, these artifacts include objects, methods, classes, interfaces and packages.

DR. FAZAL-E-AMIN

2/9/2015

4

LEGO ANALOGYSet of building blocks in different shapes and colors

Can be combined in different ways

Composition through small stubs in one and corresponding holes in another building block

LEGO blocks are generic and easily composable

LEGO can be combined with LEGO, not with Meccano

BACKGROUNDComponent-level design occurs after the first iteration of the architectural design

It strives to create a design model from the analysis and architectural modelsThe translation can open the door to subtle errors that are difficult to find and correct later “Effective programmers should not waste their time debugging – they should not introduce bugs to start with.” Edsgar Dijkstra

A component-level design can be represented using some intermediate representation (e.g. graphical, tabular, or text-based) that can be translated into source code

The design of data structures, interfaces, and algorithms should conform to well-established guidelines to help us avoid the introduction of errors

2/9/2015

5

REUSE VIA COMPONENTS Catalogue of

software components

Customerrequirements

SoftwareapplicationComponent

Providers

Componentintegrator

WHY CBSE?

CBSE increases quality, especially evolvability and maintainability

CBSE increases productivity

CBSE shortens development time

2/9/2015

6

CBDFocus on composing software systems with existing components.

CBSE ProcessAnalysis and components acquisition Components-Oriented designComponents CompositionIntegration TestSystem Test

DEVELOPMENT PROCESS IN CBSE

Two separate development processes:Development of componentsDevelopment of systems out of components

Separate process to assess components

2/9/2015

7

COMPONENT DEVELOPMENT PROCESS

Requirements: combination of top-down (from system) and bottom-up (generality)Analysis and design: generality is an issue, assumptions about system (use) must be madeImplementation: largely determined by component technologyTesting: extensive (no assumptions of usage!), and well-documentedRelease: not only executables, also metadata

14

CBSE SYSTEM DEVELOPMENT PROCESSRequirements: also considers availability of components (like in COTS)

Analysis and design: very similar to what we normally do

Implementation: less coding, focus on selection of components, provision of glue code

Integration: largely automated

Testing: verification of components is necessary

Release: as in classical approaches

Maintenance: replace components

2/9/2015

8

WATERFALL VS. COMPONENT-BASED

Waterfall Component-based

Analysis Analysis and components acquisition

Design Components-Oriented design

Implementation Components Composition

Unit Test

Integration Test Integration Test

System Test System Test

MAIN DIFFERENCE

CBD is component orientedComponent development – creation of parts as reusable entities.

2/9/2015

9

COMPONENT DEVELOPMENT

Extra level of design

Components are designed separately from the final systems.

High requirements on functionality and flexibility

COMPONENT DEVELOPMENT (CONT.)

Forces components developers to

1. Think of (possible) products the components might be a part of.

2. How the components fit into those products architecturally

2/9/2015

10

A SOFTWARE COMPONENT:

Implements some functionality

Has explicit dependencies through provides and required interfaces

Communicates through its interfaces only

Has structure and behavior that conforms to a component model

COMPONENT FORMSComponent goes through different stages: development, packaging, distribution, deployment, execution

Across these stages, components are represented in different forms:During development: UML, e.g.When packaging: in a .zip file, e.g.In the execution stage: blocks of code and data

2/9/2015

11

ARCHITECTURE AND CBSE

Architecture-driven: top-down: components are identified as part of an architectural design

Product line: family of similar products, with 1 architecture

COTS-based: bottom-up, architecture is secondary to components found

DEFINEDA software component is a modular building block for computer softwareIt is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces

A component communicates and collaborates withOther componentsEntities outside the boundaries of the system

Three different views of a componentAn object-oriented viewA conventional viewA process-related view

2/9/2015

12

OBJECT-ORIENTED VIEWA component is viewed as a set of one or more collaborating classesEach problem domain (i.e., analysis) class and infrastructure (i.e., design) class is elaborated to identify all attributes and operations that apply to its implementation This also involves defining the interfaces that enable classes to

communicate and collaborate

This elaboration activity is applied to every component defined as part of the architectural designOnce this is completed, the following steps are performed

1) Provide further elaboration of each attribute, operation, and interface2) Specify the data structure appropriate for each attribute3) Design the algorithmic detail required to implement the processing logic

associated with each operation4) Design the mechanisms required to implement the interface to include

the messaging that occurs between objects

CONVENTIONAL VIEWA component is viewed as a functional element (i.e., a module) of a program that incorporatesThe processing logicThe internal data structures that are required to implement the processing logicAn interface that enables the component to be invoked and data to be passed to it

A component serves one of the following rolesA control component that coordinates the invocation of all other problem domain componentsA problem domain component that implements a complete or partial function that is required by the customerAn infrastructure component that is responsible for functions that support the processing required in the problem domain

2/9/2015

13

CONVENTIONAL VIEW (CONTINUED)Conventional software components are derived from the data flow diagrams (DFDs) in the analysis model Each transform bubble (i.e., module) represented at the lowest levels

of the DFD is mapped into a module hierarchy Control components reside near the top Problem domain components and infrastructure components migrate

toward the bottom Functional independence is strived for between the transforms

Once this is completed, the following steps are performed for each transform

1) Define the interface for the transform (the order, number and types of the parameters)

2) Define the data structures used internally by the transform3) Design the algorithm used by the transform (using a stepwise

refinement approach)

PROCESS-RELATED VIEWEmphasis is placed on building systems from existing components maintained in a library rather than creating each component from scratch

As the software architecture is formulated, components are selected from the library and used to populate the architecture

Because the components in the library have been created with reuse in mind, each contains the following:A complete description of their interfaceThe functions they performThe communication and collaboration they require

2/9/2015

14

WHAT IS A COMPONENT? “an independently deliverable set of reusable services”

(Short `97)

“a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition.” (Szyperski `98)

“a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard” (Heinemand & Councill `01)

WHAT IS A COMPONENT? “an independently deliverable set of reusable services”

(Short `97)

“a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition.” (Szyperski `98)

“a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard” (Heinemand & Councill `01)

2/9/2015

15

WHAT IS A COMPONENT?

• Well defined service (functionality)• Well defined interface• Explicit dependences• Standardization - component model

HIDING OF COMPONENT INTERNALS

Black box: only specification is known

Glass box: internals may be inspected, but not changed

Grey box: part of the internals may be inspected, limited modification is allowed

While box: component is open to inspection and modification

SE, CBSE, HANS VAN VLIET, ©2008 31

2/9/2015

16

COMPONENT MODELDefines the types of building block, and the recipe for putting them together

More precisely, a component model defines standards for:Properties individual components must satisfyMethods and mechanisms for composing components

Consequently, a component has to conform to some component model

WHAT IS A COMPONENT MODEL? • A standard which defines components, i.e.

• How components can be constructed• How components can be composed (assembled)• How components are deployed

• But there are many competing standards, e.g.• Enterprise JavaBeans (EJB) - Sun• Component Object Model (COM) .NET - Microsoft• CORBA Component Model (CCM) – OMG

Note: CORBA = Common Object Requesting Broker Architecture

2/9/2015

17

A COMPONENT TECHNOLOGY

Is the implementation of a component model, by means of:Standards and guidelines for the implementation and execution of software componentsExecutable software that supports the implementation, assembly, deployment, execution of components

Examples: EJB, COM+, .NET, CORBA

SE, CBSE, HANS VAN VLIET, ©2008 34

COMMON FEATURES OF COMPONENT MODELSInfrastructure mechanisms, for binding, execution, etc

Instantiation

Binding (design time, compile time, …)

Mechanisms for communication between components

Discovery of components

Announcement of component capabilities (interfaces)

Development support

Language independence

Platform independence

Analysis support

Support for upgrading and extension

Support for quality properties

2/9/2015

18

CHALLENGES• Requirements trade-offs – how do we decide

between alternative component solutions? • Trustworthiness – without access to source code

how can a component be trusted?• Emergent properties – how can emergent

properties of component compositions be predicated?

COMPONENT-BASED PROCESS

• Develop initial application requirements• Search for candidate components• Modify requirements given the functionality of

the candidate components OR continue the search for a better match

Trade-off between ideal requirements and the functionality of the available components - requirements

engineering & design go hand-in-hand

2/9/2015

19

COMPOSITION PROBLEMS• Overlapping functionality:

• Multiple-components that can provide the same functionality

• Designer needs to select the most appropriate and ensure that only it provides the functionality

• Missing functionality: • Search for an appropriate component OR • Develop a component that fills the gap

COMPOSITION PROBLEMS

• Redundant functionality: • Composition may deliver additional

functionality• Either incorporate OR disable the additional

functionality • Architectural mismatch:

• Mismatch between what a component offers and what is expected within the application context

2/9/2015

20

COMPONENT INTERFACES

• Requires interface defines the services that must be available for the component to operate correctly

• Provides interface defines the services that the component provides

Requiresinterface

Providesinterface

component

COMPONENT INTERFACES

Controller

Majority vote

Requires: 3 sensor signalsProvides: majority signal value

Requires: • Enables/disables input• Speed sensor input

Provides:• Brake setting• Speed setting

2/9/2015

21

COMPONENT INTERFACES

Brakectrl

Speedctrl

Requires: Brake setting (on/off)Provides: Brake activator setting

Requires: Speed setting Provides: Speed activator setting

COMPONENT INTERFACES

Controller

Brakectrl

Speedctrl

Majority vote

Cruse control system

2/9/2015

22

INTERFACE MISMATCH • Typically interface incompatibilities will arise, e.g.

• Mismatch between parameter types• Mismatch between operator names• Incomplete interface – requires and/or provides

• Possible solutions:• Write “glue code” which bridges the gaps OR• Use an adaptor component to bridge the gap

Adaptorkmph2mph

Speedokmph

Displaymph

COMPONENT-LEVEL DESIGN PRINCIPLES Open-closed principle A module or component should be open for extension but closed for modification The designer should specify the component in a way that allows it to be extended without the need to make internal code or design modifications to the existing parts of the component

Liskov substitution principle Subclasses should be substitutable for their base classes A component that uses a base class should continue to function properly if a subclass of the base class is passed to the component instead

Dependency inversion principle Depend on abstractions (i.e., interfaces); do not depend on concretions The more a component depends on other concrete components (rather than on the interfaces) the more difficult it will be to extend

Interface segregation principle Many client-specific interfaces are better than one general purpose interface For a server class, specialized interfaces should be created to serve major categories of clients Only those operations that are relevant to a particular category of clients should be specified in the interface

2/9/2015

23

COMPONENT PACKAGING PRINCIPLESRelease reuse equivalency principle The granularity of reuse is the granularity of releaseGroup the reusable classes into packages that can be managed, upgraded, and controlled as newer versions are created

Common closure principleClasses that change together belong togetherClasses should be packaged cohesively; they should address the same functional or behavioral area on the assumption that if one class experiences a change then they all will experience a change

Common reuse principleClasses that aren't reused together should not be grouped togetherClasses that are grouped together may go through unnecessary integration and testing when they have experienced no changes but when other classes in the package have been upgraded

COMPONENT-LEVEL DESIGN GUIDELINESComponentsEstablish naming conventions for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level modelObtain architectural component names from the problem domain and ensure that they have meaning to all stakeholders who view the architectural model (e.g., Calculator)Use infrastructure component names that reflect their implementation-specific meaning (e.g., Stack)

Dependencies and inheritance in UMLModel any dependencies from left to right and inheritance from top (base class) to bottom (derived classes)Consider modeling any component dependencies as interfaces rather than representing them as a direct component-to-component dependency

2/9/2015

24

COHESIONCohesion is the “single-mindedness’ of a component

It implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself

The objective is to keep cohesion as high as possible

The kinds of cohesion can be ranked in order from highest (best) to lowest (worst) FunctionalA module performs one and only one computation and then returns a result LayerA higher layer component accesses the services of a lower layer componentCommunicationalAll operations that access the same data are defined within one class

COHESION (CONTINUED)Kinds of cohesion

Sequential Components or operations are grouped in a manner that allows the first to provide input to the next and so on in order to implement a sequence of operations

Procedural Components or operations are grouped in a manner that allows one to be invoked immediately after the preceding one was invoked, even when no data passed between them

Temporal Operations are grouped to perform a specific behavior or establish a certain state such as program start-up or when an error is detected

Utility Components, classes, or operations are grouped within the same category because of similar general functions but are otherwise unrelated to each other

49

2/9/2015

25

COUPLING

As the amount of communication and collaboration increases between operations and classes, the complexity of the computer-based system also increases

As complexity rises, the difficulty of implementing, testing, and maintaining software also increases

Coupling is a qualitative measure of the degree to which operations and classes are connected to one another

The objective is to keep coupling as low as possible

COUPLING (CONTINUED)The kinds of coupling can be ranked in order from lowest (best) to highest (worst) Data coupling Operation A() passes one or more atomic data operands to operation B(); the less the number of operands, the lower the level of coupling

Stamp coupling A whole data structure or class instantiation is passed as a parameter to an operation

Control coupling Operation A() invokes operation B() and passes a control flag to B that directs logical flow within B() Consequently, a change in B() can require a change to be made to the meaning of the control flag passed by A(), otherwise an error may result

Common coupling A number of components all make use of a global variable, which can lead to uncontrolled error propagation and unforeseen side effects

Content coupling One component secretly modifies data that is stored internally in another component

2/9/2015

26

COUPLING (CONTINUED)Other kinds of coupling (unranked) Subroutine call couplingWhen one operation is invoked it invokes another operation within side of it Type use couplingComponent A uses a data type defined in component B, such as for an instance variable or a local variable declaration If/when the type definition changes, every component that declares a variable of that data type must also change

Inclusion or import couplingComponent A imports or includes the contents of component B External couplingA component communicates or collaborates with infrastructure components that are entities external to the software (e.g., operating system functions, database functions, networking functions)

CONDUCTING COMPONENT-LEVEL DESIGN1) Identify all design classes that correspond to the problem domain as defined in

the analysis model and architectural model

2) Identify all design classes that correspond to the infrastructure domain• These classes are usually not present in the analysis or architectural models• These classes include GUI components, operating system components, data

management components, networking components, etc.

3) Elaborate all design classes that are not acquired as reusable componentsa) Specify message details (i.e., structure) when classes or components

collaborateb) Identify appropriate interfaces (e.g., abstract classes) for each componentc) Elaborate attributes and define data types and data structures required to

implement them (usually in the planned implementation language)d) Describe processing flow within each operation in detail by means of

pseudocode or UML activity diagrams

2/9/2015

27

CONDUCTING COMPONENT-LEVEL DESIGN (CONTINUED)4) Describe persistent data sources (databases and files) and identify the classes

required to manage them

5) Develop and elaborate behavioral representations for a class or component• This can be done by elaborating the UML state diagrams created for the analysis

model and by examining all use cases that are relevant to the design class

6) Elaborate deployment diagrams to provide additional implementation detail• Illustrate the location of key packages or classes of components in a system by

using class instances and designating specific hardware and operating system environments

7) Factor every component-level design representation and always consider alternatives

• Experienced designers consider all (or most) of the alternative design solutions before settling on the final design model

• The final decision can be made by using established design principles and guidelines

THE COST OF COMPONENT DESIGN • The cost of developing a reusable component will

typically be greater than for developing a specific equivalent – so from the perspective of development costs the longer term benefits of effective reuse must be taken into account

• Components by definition will be generic, and therefore may not be optimized with respect to time and space – depending on the sector, there may be a cost attached to such inefficiencies

2/9/2015

28

PREDICATING EMERGENT BEHAVIOURS

• Ideally if a system is developed from components with well-defined behaviours then it should be possible to predict the emergent behaviour of the system – but reality is far from the ideal!

• Providing tool support for predicating emergent behaviour is a major area of research, e.g.– The Carnegie Mellon Software Engineering Institute (SEI)– Predictable Assembly from Certifiable Code (PACC)– http://www.sei.cmu.edu/pacc/

TRUSTWORTHINESS• Given a component with no access to the source

code, how do you decide if it is safe to execute?• Execute it and see – latent bugs may only come

to light once the system is deployed • Trust the provider – does not take account of

defects, honest mistakes (or otherwise) and tampering during distribution

• Certification – who provides the certification, why trust them, why trust the certificate?

2/9/2015

29

MANAGING QUALITY IN CBSE

Who manages the quality: the component, or the execution platform

Scope of management: per-collaboration, or system-wide

MANAGING QUALITY IN CBSE

Approach A: left to the designers (e.g. when integrating COTS components)Approach B: model provides standardized facilities for managing qualitiesApproach C: component only addresses functionality, quality in surrounding containerApproach D: similar to C, but container interacts with platform on quality issues

2/9/2015

30

COMPONENT ASSESSMENT

SE, CBSE, HANS VAN VLIET, ©2008 60

Find components

Verify components

Store components in repository

COMPONENT DEVELOPMENT PROCESS

Components are intended for reuse

Managing requirements is more difficultMore effort required to develop reusable componentsMore effort in documentation for consumers

2/9/2015

31

COMPONENT MAINTENANCE

Who is responsible: producer or consumer?Blame analysis: relation between manifestation of a fault and its cause, e.g.Component A requires more CPU timeAs a consequence, B does not complete in timeAs required by C, soC issues a time-out error to its userAnalysis: goes from C to B to A to input of AWho does the analysis, if producers of A,B,C are different?