Engineering Component-Based Software: Processes

Component-Based Software Engineering Dr R Bahsoon

1

Unit 3. Engineering Component-Based Software: Processes and lifecycle

Component-Based Software

Dr. Rami BahsoonSchool of Computer Science

The University Of [email protected]/~rzb

Office 112 Y9- Computer Science


2

Unit 2 Learning Objectives

• In this unit,– Unit 2.1

• Quick review software development processes & lifecycle

– Unit 2.2• Discuss software engineering challenges • Discuss reuse-software development and landscape• Appraise the benefits & limitations of reuse

– Case study for orientation: Failure of Ariane 5

• Introduces the component-based software lifecycle and contrast it to generic lifecycles


3

Critical Question

How do you distinguish the process of “Component Development” from thatof “Systems development with Components”?


4

Unit 2.1 Overview of Software Processes (Revision & Background)

Perhaps what you have seen from processes looks explicitly at “Component Development”… and

implicitly at “Developing Software Systems from Components”


5

Brainstorming Exercise

• What is your understanding of a “Software Process”?

• Have you used any “Software Process Model” in your practice? – Which models?– Examples?– Uses? Strengths/Weaknesses? – Observations?


6

Objectives

• Quick revision for software processes models (These are background material which you may have seen elsewhere)– Waterfall, incremental, evolutionary, spiral

• Advantages and disadvantages – To describe the Rational Unified Process model


7

Software Engineering – for Orientation • Software Engineering is a branch of systems engineering

concerned with the development of large and complex software intensive systems. It focuses on: – the real-world goals for, services provided by, and constraints

on such systems, – the precise specification of systems structure and behaviour,

and the implementations of these specifications,– the activities required in order to develop an assurance that the

specifications and real world-world goals have been met, – the evolution of these systems over time, and across systems

families, – It is also concerned with the processes, methods and tools for

the development of software intensive systems in an economic and timely manner.

Reference: A. Finkelstein


8

Software Process

• A structured set of activities required to develop a software system– Specification;– Design;– Validation;– Evolution.

• A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.


9

• The waterfall model– Separate and distinct phases of specification and

development.

• Evolutionary development– Specification, development and validation are interleaved.

• Component-based software engineering– The system is assembled from existing components.

Process Models: Examples


10

Waterfall Model

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenance


11

Waterfall Model Phases

Phase 1. Requirements analysis and definition– The process of establishing what services are

required and the constraints on the system’s operation and development.• What is the system about?

– Requirements engineering process• Feasibility study;• Requirements elicitation and analysis;• Requirements specification;• Requirements validation.

Requirements

definition




Operation and

maintenance

Phase 1


12

Phase 1. Requirements Engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Output

Activities


13


Phase 2. System and software design– i.e., How the requirements to be realised?

Design a software structure that realises the specification; • Architectural design• Abstract specification• Interface design• Component design• Data structure design• Algorithm design…..

Requirements

definition




Operation and

maintenance

Phase 2


14

The Software Design Process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Output


15


Phase 3. Implementation and unit testing– Implementation: Executable code– Unit testing (Component test)

» Individual components (function/programs/classes) are tested independently;

» Components may be functions or objects or coherent groupings of these entities.

Requirements

definition




Operation and

maintenance

Phase 3


16

Waterfall Model PhasesPhase 4. Integration and system testing

– System testing» Testing of the system as a whole. Testing of

emergent properties is particularly important.

– Acceptance testing» Testing with customer data to check that the

system meets the customer’s needs.Requirements

definition




Operation and

maintenance

Phase 4


17


Phase 5. Operation and maintenance

Requirements

definition




Operation and

maintenance

Phase 5


18

Evolutionary Development

• Exploratory development – Objective is to work with customers and to evolve a final

system from an initial outline specification. – Start with well-understood requirements and add new

features as proposed by the customer.

• Throw-away prototyping– Objective is to understand the system requirements. Should

start with poorly understood requirements to clarify what is really needed.


19

Evolutionary Development

Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription


20

Process Iteration• System requirements ALWAYS evolve in the course of a

project so process iteration where earlier stages are reworked is always part of the process for large systems

• Iteration can be applied to any of the generic process models (e.g., waterfall)

• Two (related) approaches

– Incremental delivery;– Spiral development.


21

Incremental Development

Reference: A. Finkelstein


22

Incremental Delivery

• Rather than deliver the system as a single delivery, – the development and delivery is broken down into

increments with each increment delivering part of the required functionality

• User requirements are prioritised – highest priority requirements are included in early

increments

• Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve


23

Incremental Development Advantages• Early increments act as a prototype to help elicit

requirements for later increments• Lower risk of overall project failure• The highest priority system services tend to receive the most

testing • Customer value can be delivered with each increment so

system functionality is available earlier


24

Spiral Development

• Process is represented as a spiral rather than as a sequence of activities with backtracking

• Each loop in the spiral represents a phase in the process

• No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

• Risks are explicitly assessed and resolved throughout the process


25

Spiral Model


26

Spiral Model


27

Spiral Model Sectors

• Objective setting– Specific objectives for the phase are identified.

• Risk assessment and reduction– Risks are assessed and activities put in place to reduce

the key risks• Development and validation

– A development model for the system is chosen which can be any of the generic models

• Planning– The project is reviewed and the next phase of the spiral is

planned


28

Exercise -The Rational Unified Process• Use the Internet to understand RUP. Prepare a brief

summary on RUP for class discussion


29

RUP Model


30

RUP- Phases

• Inception– Establish the business case for the system

• Elaboration– Develop an understanding of the problem domain

and the system architecture

• Construction– System design, programming and testing

• Transition– Deploy the system in its operating environment


31

RUP- Class Discussion

It is claimed that RUP, if adopted, can: – Develop software iteratively,– Manage requirements,– Support component-based software development,– Verify software quality,– Control changes to software etc.

What do you think?Do you agree/disagree & Why?


32

Summary of Unit 2.1

• Software processes are the activities involved in producing and evolving a software system

• Software process models are abstract representations of these processes

• General activities are specification, design and implementation, validation and evolution

• Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering

• Iterative process models describe the software process as a cycle of activities

• The Rational Unified Process is a generic process model that separates activities from phases


33

Unit 2 Learning Objectives

• In this unit,– Unit 2.1

• Quick review software development processes & lifecycle

– Unit 2.2• Rational Unified Process• Model-driven development • Reuse-driven software development and landscape• Component-based software lifecycle


34

Challenges in Software Engineering

• Complexity – The size and complexity of software is increasing

rapidly

• Change, maintenance & continuous evolution– Users’ Requirements and the environment in which

the software works are in continuous change…– Changes in non-functional requirements have global

impact to threat software stability – Legacy systems: old and valuable systems must be

maintained, updated, and be integrated with new systems

– Software upgrades are expected after deployment…Development and evolution costs for long-lifetime systems

System evolution

System developmentTime


35


• Architecting dependable software– Software must be trustworthy by its users

Dependability

Availability Reliability Security

The ability of the systemto deliver services when

requested

The ability of the systemto deliver services as

specified

The ability of the systemto operate withoutcatastrophic failure

The ability of the systemto protect itelf againstaccidental or deliberate

intrusion

Safety


36


• Single products become part of product family

• Heterogeneity– Software that can cope with heterogeneous

platforms and execution environments• E.g. Fixed distributed and mobile environments

• Time to market• There is increasing pressure for faster delivery of

software to gain competitive advantage


37


Concentration on the business issues…“Around 30% of the development effort is spent

on the infrastructure that add no value”


38

Model Driven Development

• The software development process is driven by the activity of modelling (with UML)

• Supports full lifecycle: analysis, design, implementation, deployment, maintenance, evolution and integration with later systems

• Builds in Interoperability and Portability• Lowers initial cost and maximises return-on-

investment• Applies directly to the mix you face:

• Programming language; Network; Operating system, Middleware


39

The Model-Driven Process


40

MDA Framework

• A model is a description of a system.• A PIM describes a system without any knowledge of

the final implementation platform.• A PSM describes a system with full knowledge of

the final implementation platform.• A transformation definition describes how a model

in a source language can be transformed into a model in a target language.

• A transformation tool performs a transformation for a specific source model according to a transformation definition.


41

PIM - Platform Independent Model

• Platform Independent Model

– Model with a high level of abstraction independent of any implementing technology.

– Specifies the system from the viewpoint of how it best supports the business.

– Whether a system will be implemented on a mainframe with a relational database or on an EJB application server plays no role in a PIM.


42

PSM – Platform Specific Model

• A transformation of PIM tailored to specify a system in terms of the implementation constructs available in the chosen implementation technology

• A PIM is transformed into one or more PSMs: for each specific technology platform a separate PSM is generated.– For example, an EJB PSM is a model of the system in

terms of EJB structures.– It typically contains EJB specific terms like “home

interface”, “entity bean”, “session bean” and so on.– A relational database PSM includes terms like

“table”, “column”, “foreign key”, and so on.


43

Code

• The final step in the development is the transformation of each PSM to code.

• A PSM fits its technology closely and so this transformation is relatively straightforward.

• MDA defines the PIM, PSM, and code and also defines how these relate to each other.


44

Tool Support & References

• AndroMDAhttp://www.andromda.org/

• An extensible open source generator framework that adheres to the Model Driven Architecture (MDA) paradigm.

• Models from UML tools can be transformed into deployable components for your choice of platform (J2EE, Spring, .NET).

• References:– OMG

http://www.omg.org/mda– Book by A. Kleppe et al., MDA Explained, Addison-

Wesley, 2003• http://www.klasse.nl/mdaexplained


45

Another Shift in Paradigm…

1970 1990 2000


46

Shift in Effort…

Waterfall model

Iterative development

Component-based software engineering

Specification Design Development Integration and testing

25 50 75 1000

Specification Development Integration and testing

25 50 75 1000

Specification Iterative developmentSystem testing

25 50 75 1000

In CBSE much of the effort/cost are spent on integration and testing…


47

Systematic Software Reuse

• In most engineering disciplines, systems are designed by composing existing components that have been used in other systems

• Software engineering has been more focused on original development…

• To achieve “potentially” better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic software reuse...


48

Reuse Approaches & Landscape

Design patterns

Generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions

Component-based development

Systems are developed by integrating components that conform to component-model standards

Application f rameworks

Collections of abstract and concrete classes that can be adapted and extended to create application systems

Legacy system wrapping

Legacy systems that can be ‘wrapped’ by defining a set of interfaces and providing access to these legacy systems through these interfaces


49

Reuse Approaches & Landscape

Application product lines

An application type is generalised around a common architecture so that it can be adapted in diff erent ways for diff erent customers

COTS integration

Systems are developed by integrating existing application systems

Service-oriented systems

Systems are developed by linking shared services that may be externally provided

Program libraries

Class and function libraries implementing commonly-used abstractions are available for reuse


50

Benefits of Reuse

I ncreased dependability

Reused sof tware, that has been tried and tested in working systems, should be more dependable than new sof tware. The initial use of the sof tware reveals any design and implementation faults

Reduced process risk

I f sof tware exists, there is less uncertainty in the costs of reusing that sof tware than in the costs of development. This is particularly true when relatively large sof tware components such as sub-systems are reused

Eff ective use of specialists

I nstead of application specialists doing the same work on diff erent projects, these specialists can develop reusable sof tware that encapsulate their knowledge


51

Benefits of Reuse

Standards compliance

Some standards, such as user interface standards, can be implemented as a set of standard reusable components. The use of standard user interfaces, f or example, improves dependability as users are less likely to make mistakes when presented with a familiar interface

Accelerated development

Bringing a system to market as early as possible is of ten more important than overall development costs. Reusing sof tware can speed up system production because both development and validation time should be reduced


52

Problems with Reuse

Creating and maintaining a component library

Populating a reusable component library and ensuring the sof tware developers can use this library can be expensive. Our current techniques f or classif ying, cataloguing and retrieving sof tware components are immature

Finding, understanding and adapting reusable components

Sof tware components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. A component search is part of the normal development process


53

Problems with Reuse

I ncreased maintenance costs

I f the source code of a reused sof tware system or component is not available then maintenance costs may be increased as the reused elements of the system may become increasingly incompatible with system changes

Lack of tool support

CASE toolsets may not support development with reuse. I t may be diffi cult or impossible to integrate these tools with a component library system. The sof tware process assumed by these tools may not take reuse into account

Not-invented-here syndrome

Some sof tware engineers sometimes prefer to re-write components as they believe that they can improve on the reusable component. This is partly to do with trust and partly to do with the fact that writing original sof tware is seen as more challenging than reusing other people’s sof tware


54

Case Study: Ariane 5

• In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of control 37 seconds after take off

• The problem was due to a reused component from a previous version of the launcher (the Inertial Navigation System) that failed because assumptions made when that component was developed did not hold for Ariane 5

• The functionality that failed in this component was not required in Ariane 5– http://www.dailymotion.com/video/x256qu_explosion

-ariane-5_events


55

Case Study: Ariane 5

• On June 4, 1996 Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off from French Guianahttp://www.cnn.com/WORLD/9606/04/rocket.explode/ariane.mov

• The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million

• A board of inquiry investigated the causes of the explosion and in two weeks issued a report


56

Case study: Ariane 5

• Software failure in the inertial reference system occurred when an attempt to convert a 64-bit floating point number to a signed 16-bit integer causing overflow.– Specifically a 64 bit floating point number relating to the horizontal

velocity of the rocket with respect to the platform was converted to a 16 bit signed integer.

– The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed!

– There was no exception handler associated with the conversion so the system exception management facilities were invoked. These shutdown the software!

– REUSE!

System Backup


57

Component-Based Software Engineering

• Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.

• Process stages– Component analysis;– Requirements modification;– System design with reuse;– Development and integration.

• Emphasis is on Reuse Reuse-oriented development

• This approach is becoming increasingly used as component standards have emerged.


58

Reuse-Oriented Development

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Analyse written software Do existing software/packages fit my need?

e.g. Ariane 5 doesn’t require the 64bit conversion…. Drop it!


59

The CBSE process

• When reusing components, – It is essential to make trade-offs between ideal

requirements and the services actually provided by available components.

• This involves:– Developing outline requirements;– Searching for components then modifying

requirements according to available functionality– Searching again to find if there are better

components that meet the revised requirements.


60

The CBSE process

Identify candidatecomponents

Outlinesystem

requirements

Modifyrequirements

according to discoveredcomponents


Architecturaldesign

Composecomponents tocreate system


Outlinesystem

requirements

Modifyrequirements

according to discoveredcomponents


Architecturaldesign

Composecomponents tocreate system


61

The Component Identification Process

Componentselection

Componentsearch

Componentvalidation


62

Component dentification issues

• Trust. – You need to be able to trust the supplier of a component– At best, an untrusted component may not operate as

advertised; at worst, it can breach your security

• Requirements. – Different groups of components will satisfy different

requirements

• Validation.– The component specification may not be detailed

enough to allow comprehensive tests to be developed.– Components may have unwanted functionality. How can

you test this will not interfere with your application?


63

Component composition

• The process of assembling components to create a system

• Composition involves integrating components with each other and with the component infrastructure

• Normally you have to write ‘glue code’ to integrate components


64

V Development Process for CBS

Software process


65

V Development Process for CBS


66

CBS Process


67

CBS Process

• Requirements: Requirements definition → use case model and business concept model

• Specification: Component Identification, Component Interaction, and Component Specification

• Provisioning: determine what components to build, buy or reuse

• Assembly: guide correct integration of components, existing assets and suitable user interface → application that meets business needs

Theses phases replace analysis, design and implementation phases in processes like RUP.


68

Component Identification


69

Component Interaction


70

Provisioning

• Source component implementations either – by directly implementing the specification or – by finding an existing component that fits the

specification

• The component specification is as independent as possible from target technologies/platforms

Engineering Component-Based Software: Processes

Documents

Transcript of Engineering Component-Based Software: Processes