engineering component-based software: processes
TRANSCRIPT
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
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
Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation and
maintenance
Component-Based Software Engineering Dr R Bahsoon
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
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation and
maintenance
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 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…..
Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation and
maintenance
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
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Output
Component-Based Software Engineering Dr R Bahsoon
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.
Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation and
maintenance
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 and
maintenance
Phase 4
Component-Based Software Engineering Dr R Bahsoon
17
Waterfall Model Phases
Phase 5. Operation and maintenance
Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation and
maintenance
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
DevelopmentIntermediate
versions
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 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?
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 developmentTime
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
• 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
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 developmentSystem 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 & 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
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 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
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 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
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, 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
Component-Based Software Engineering Dr R Bahsoon
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
Component-Based Software Engineering Dr R Bahsoon
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
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
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