Component-Based Software Engineering

1
Component-Based Software Dr. Rami
BahsoonSchool of Computer ScienceThe University
Of Birminghamr.bahsoon_at_cs.bham.ac.ukwww.cs.bham.
ac.uk/rzbOffice 112 Y9- Computer Science

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

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 that of 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
Process Models Examples

• 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.

10
Waterfall Model
11
Waterfall Model Phases

• Phase 1. Requirements analysis and definition
• The process of establishing what services are
  required and the constraints on the systems
  operation and development.
• What is the system about?
• Requirements engineering process
• Feasibility study
• Requirements elicitation and analysis
• Requirements specification
• Requirements validation.

Phase 1
12
Phase 1. Requirements Engineering process
Activities
Output
13
Waterfall Model Phases

• 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..

Phase 2
14
The Software Design Process
Output
15
Waterfall Model Phases

• 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.

Phase 3
16
Waterfall Model Phases

• Phase 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 customers needs.

Phase 4
17
Waterfall Model Phases

• Phase 5. 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
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

35
Challenges in Software Engineering

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

36
Challenges in Software Engineering

• 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
Challenges in Software Engineering
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

• AndroMDA
• http//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
2
5
5
0
1
00
0
7
5
Specification
Design
Development
Integration and testing
Iterative development
2
5
5
0
7
5
1
00
0
Specification
Iterative development
System testing
Component-based software engineering
2
5
5
0
1
00
0
7
5
Specification
Development
Integration and testing
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
49
Reuse Approaches Landscape
50
Benefits of Reuse
51
Benefits of Reuse
52
Problems with Reuse
53
Problems with Reuse
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 Guiana
• http//www.cnn.com/WORLD/9606/04/rocket.explode/ar
  iane.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
e.g. Ariane 5 doesnt require the 64bit
conversion. Drop it!
Analyse written software Do existing
software/packages fit my need?
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
61
The Component Identification Process
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