Download presentation
Presentation is loading. Please wait.
1
Unit 3. Engineering Component-Based Software: Processes and lifecycle
Component-Based Software Dr. Rami Bahsoon School of Computer Science The University Of Birmingham Office 112 Y9- Computer Science Unit 3. Engineering Component-Based Software: Processes and lifecycle 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
Component-Based Software Engineering
Critical Question How do you distinguish the process of “Component Development” from that of “Systems development with Components”? Component-Based Software Engineering Dr R Bahsoon
4
Component-Based Software Engineering
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
Component-Based Software Engineering
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
Component-Based Software Engineering
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
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. Component-Based Software Engineering Dr R Bahsoon
10
Component-Based Software Engineering
Waterfall Model 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. Phase 1 Component-Based Software Engineering Dr R Bahsoon
12
Phase 1. Requirements Engineering process
Activities Output 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….. Phase 2 Component-Based Software Engineering Dr R Bahsoon
14
The Software Design Process
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. Phase 3 Component-Based Software Engineering Dr R Bahsoon
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 customer’s needs. Phase 4 Component-Based Software Engineering Dr R Bahsoon
17
Waterfall Model Phases
Phase 5. 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
Component-Based Software Engineering Dr R Bahsoon
20
Component-Based Software Engineering
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
Component-Based Software Engineering
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
Component-Based Software Engineering
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
Component-Based Software Engineering
Spiral Model Component-Based Software Engineering Dr R Bahsoon
26
Component-Based Software Engineering
Spiral Model Component-Based Software Engineering Dr R Bahsoon
27
Component-Based Software Engineering
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
Component-Based Software Engineering
RUP Model Component-Based Software Engineering Dr R Bahsoon
30
Component-Based Software Engineering
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
Do you agree/disagree & Why? Component-Based Software Engineering
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
Component-Based Software Engineering
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 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
Component-Based Software Engineering
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
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
Component-Based Software Engineering
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 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 Book by A. Kleppe et al., MDA Explained, Addison-Wesley, 2003 Component-Based Software Engineering Dr R Bahsoon
45
Another Shift in Paradigm…
1970 1990 2000 Component-Based Software Engineering Dr R Bahsoon
46
Component-Based Software Engineering
Shift in Effort… Waterfall model 2 5 5 7 5 1 00 Specification Design Development Integration and testing Iterative development 2 5 5 7 5 1 00 Specification Iterative development System testing Component-based software engineering 2 5 5 7 5 1 00 Specification Development Integration and testing 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
Component-Based Software Engineering Dr R Bahsoon
49
Reuse Approaches & Landscape
Component-Based Software Engineering Dr R Bahsoon
50
Component-Based Software Engineering
Benefits of Reuse Component-Based Software Engineering Dr R Bahsoon
51
Component-Based Software Engineering
Benefits of Reuse Component-Based Software Engineering Dr R Bahsoon
52
Component-Based Software Engineering
Problems with Reuse Component-Based Software Engineering Dr R Bahsoon
53
Component-Based Software Engineering
Problems with Reuse Component-Based Software Engineering Dr R Bahsoon
54
Component-Based Software Engineering
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 Component-Based Software Engineering Dr R Bahsoon
55
Component-Based Software Engineering
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 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
Component-Based Software Engineering
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
e.g. Ariane 5 doesn’t require the 64bit conversion…. Drop it! Analyse written software Do existing software/packages fit my need? Component-Based Software Engineering Dr R Bahsoon
59
Component-Based Software Engineering
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
Component-Based Software Engineering
The CBSE process Component-Based Software Engineering Dr R Bahsoon
61
The Component Identification Process
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
Component-Based Software Engineering
CBS Process Component-Based Software Engineering Dr R Bahsoon
67
Component-Based Software Engineering
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
Component-Based Software Engineering
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 Component-Based Software Engineering Dr R Bahsoon
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.