Unit 3. Engineering Component-Based Software: Processes and lifecycle
description
Transcript of Unit 3. Engineering Component-Based Software: Processes and lifecycle
Component-Based Software Engineering Dr R Bahsoon
1Unit 3. Engineering Component-Based
Software: Processes and lifecycle
Component-Based Software Dr. Rami Bahsoon
School of Computer ScienceThe University Of Birmingham
[email protected]/~rzb
Office 112 Y9- Computer Science
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
3
Critical Question
How do you distinguish the process of “Component Development” from thatof “Systems development with Components”?
Component-Based Software Engineering Dr R Bahsoon
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”
Component-Based Software Engineering Dr R Bahsoon
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?
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
10
Waterfall Model
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Component-Based Software Engineering Dr R Bahsoon
11
Waterfall Model PhasesPhase 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.
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Phase 1
Component-Based Software Engineering Dr R Bahsoon
12
Phase 1. Requirements Engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Output
Activities
Component-Based Software Engineering Dr R Bahsoon
13
Waterfall Model PhasesPhase 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…..
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Phase 2
Component-Based Software Engineering Dr R Bahsoon
14
The Software Design Process
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specificationAlgorithm
specification
Requirementsspecification
Design activities
Design products
Output
Component-Based Software Engineering Dr R Bahsoon
15
Waterfall Model PhasesPhase 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.
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Phase 3
Component-Based Software Engineering Dr R Bahsoon
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
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Phase 4
Component-Based Software Engineering Dr R Bahsoon
17
Waterfall Model PhasesPhase 5. Operation and maintenance
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Phase 5
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
19
Evolutionary Development
Concurrentactivities
ValidationFinal
version
Development Intermediateversions
SpecificationInitial
version
Outlinedescription
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
21
Incremental Development
Reference: A. Finkelstein
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
25
Spiral Model
Component-Based Software Engineering Dr R Bahsoon
26
Spiral Model
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
28
Exercise -The Rational Unified Process• Use the Internet to understand RUP. Prepare a brief
summary on RUP for class discussion
Component-Based Software Engineering Dr R Bahsoon
29
RUP Model
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
31
RUP- Class DiscussionIt 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?
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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 development Time
Component-Based Software Engineering Dr R Bahsoon
35
Challenges in Software Engineering
• 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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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”
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
39
The Model-Driven Process
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
45
Another Shift in Paradigm…
1970 1990 2000
Component-Based Software Engineering Dr R Bahsoon
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 development System testing
25 50 75 1000
In CBSE much of the effort/cost are spent on integration and testing…
Component-Based Software Engineering Dr R Bahsoon
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...
Component-Based Software Engineering Dr R Bahsoon
48
Reuse Approaches & LandscapeDesign 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
Component-Based Software Engineering Dr R Bahsoon
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 f or 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
Component-Based Software Engineering Dr R Bahsoon
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 f aults
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
Component-Based Software Engineering Dr R Bahsoon
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, for 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
Component-Based Software Engineering Dr R Bahsoon
52
Problems with ReuseCreating 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
Component-Based Software Engineering Dr R Bahsoon
53
Problems with ReuseI 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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
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!
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
60
The CBSE process
Identify candidatecomponents
Outlinesystem
requirements
Modifyrequirements
according to discoveredcomponents
Identify candidatecomponents
Architecturaldesign
Composecomponents tocreate system
Component-Based Software Engineering Dr R Bahsoon
61
The Component Identification Process
Componentselection
Componentsearch
Componentvalidation
Component-Based Software Engineering Dr R Bahsoon
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?
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
64
V Development Process for CBS
Software process
Component-Based Software Engineering Dr R Bahsoon
65
V Development Process for CBS
Component-Based Software Engineering Dr R Bahsoon
66
CBS Process
Component-Based Software Engineering Dr R Bahsoon
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.
Component-Based Software Engineering Dr R Bahsoon
68
Component Identification
Component-Based Software Engineering Dr R Bahsoon
69
Component Interaction
Component-Based Software Engineering Dr R Bahsoon
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