Engineering Component-Based Software: Processes


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Engineering Component-Based Software: Processes

  1. 1. Unit 3. Engineering Component-Based Software: Processes and lifecycle Component-Based Software Dr. Rami Bahsoon School of Computer Science The University Of Birmingham r. bahsoon @ cs . bham .ac. uk www. cs . bham .ac. uk /~ rzb Office 112 Y9- Computer Science
  2. 2. Unit 2 Learning Objectives <ul><li>In this unit, </li></ul><ul><ul><li>Unit 2.1 </li></ul></ul><ul><ul><ul><li>Quick review software development processes & lifecycle </li></ul></ul></ul><ul><ul><li>Unit 2.2 </li></ul></ul><ul><ul><ul><li>Discuss software engineering challenges </li></ul></ul></ul><ul><ul><ul><li>Discuss reuse-software development and landscape </li></ul></ul></ul><ul><ul><ul><li>Appraise the benefits & limitations of reuse </li></ul></ul></ul><ul><ul><ul><ul><li>Case study for orientation: Failure of Ariane 5 </li></ul></ul></ul></ul><ul><ul><ul><li>Introduces the component-based software lifecycle and contrast it to generic lifecycles </li></ul></ul></ul>
  3. 3. Critical Question How do you distinguish the process of “ Component Development” from that of “Systems development with Components”?
  4. 4. <ul><li>Unit 2.1 Overview of Software Processes </li></ul><ul><ul><li>(Revision & Background) </li></ul></ul>Perhaps what you have seen from processes looks explicitly at “Component Development”… and implicitly at “Developing Software Systems from Components”
  5. 5. Brainstorming Exercise <ul><li>What is your understanding of a “Software Process”? </li></ul><ul><li>Have you used any “Software Process Model” in your practice? </li></ul><ul><ul><li>Which models? </li></ul></ul><ul><ul><li>Examples? </li></ul></ul><ul><ul><li>Uses? Strengths/Weaknesses? </li></ul></ul><ul><ul><li>Observations? </li></ul></ul>
  6. 6. Objectives <ul><li>Quick revision for software processes models (These are background material which you may have seen elsewhere) </li></ul><ul><ul><li>Waterfall, incremental, evolutionary, spiral </li></ul></ul><ul><ul><ul><li>Advantages and disadvantages </li></ul></ul></ul><ul><ul><li>To describe the Rational Unified Process model </li></ul></ul>
  7. 7. Software Engineering – for Orientation <ul><li>Software Engineering is a branch of systems engineering concerned with the development of large and complex software intensive systems. It focuses on: </li></ul><ul><ul><li>the real-world goals for, services provided by, and constraints on such systems, </li></ul></ul><ul><ul><li>the precise specification of systems structure and behaviour , and the implementations of these specifications, </li></ul></ul><ul><ul><li>the activities required in order to develop an assurance that the specifications and real world-world goals have been met, </li></ul></ul><ul><ul><li>the evolution of these systems over time , and across systems families , </li></ul></ul><ul><ul><li>It is also concerned with the processes , methods and tools for the development of software intensive systems in an economic and timely manner . </li></ul></ul>Reference: A. Finkelstein
  8. 8. Software Process <ul><li>A structured set of activities required to develop a software system </li></ul><ul><ul><li>Specification; </li></ul></ul><ul><ul><li>Design; </li></ul></ul><ul><ul><li>Validation; </li></ul></ul><ul><ul><li>Evolution. </li></ul></ul><ul><li>A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. </li></ul>
  9. 9. <ul><li>The waterfall model </li></ul><ul><ul><li>Separate and distinct phases of specification and development. </li></ul></ul><ul><li>Evolutionary development </li></ul><ul><ul><li>Specification, development and validation are interleaved. </li></ul></ul><ul><li>Component-based software engineering </li></ul><ul><ul><li>The system is assembled from existing components. </li></ul></ul>Process Models: Examples
  10. 10. Waterfall Model
  11. 11. Waterfall Model Phases <ul><li>Phase 1. Requirements analysis and definition </li></ul><ul><ul><li>The process of establishing what services are required and the constraints on the system’s operation and development. </li></ul></ul><ul><ul><ul><li>What is the system about? </li></ul></ul></ul><ul><ul><li>Requirements engineering process </li></ul></ul><ul><ul><ul><li>Feasibility study; </li></ul></ul></ul><ul><ul><ul><li>Requirements elicitation and analysis; </li></ul></ul></ul><ul><ul><ul><li>Requirements specification; </li></ul></ul></ul><ul><ul><ul><li>Requirements validation. </li></ul></ul></ul>Phase 1
  12. 12. Phase 1. Requirements Engineering process Output Activities
  13. 13. Waterfall Model Phases <ul><li>Phase 2. System and software design </li></ul><ul><ul><li>i.e., How the requirements to be realised? Design a software structure that realises the specification ; </li></ul></ul><ul><ul><ul><li>Architectural design </li></ul></ul></ul><ul><ul><ul><li>Abstract specification </li></ul></ul></ul><ul><ul><ul><li>Interface design </li></ul></ul></ul><ul><ul><ul><li>Component design </li></ul></ul></ul><ul><ul><ul><li>Data structure design </li></ul></ul></ul><ul><ul><ul><li>Algorithm design….. </li></ul></ul></ul>Phase 2
  14. 14. The Software Design Process Output
  15. 15. Waterfall Model Phases <ul><li>Phase 3. Implementation and unit testing </li></ul><ul><ul><ul><ul><li>Implementation: Executable code </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Unit testing (Component test) </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Individual components (function/programs/classes) are tested independently; </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Components may be functions or objects or coherent groupings of these entities. </li></ul></ul></ul></ul></ul>Phase 3
  16. 16. Waterfall Model Phases <ul><li>Phase 4. Integration and system testing </li></ul><ul><ul><ul><ul><li>System testing </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Testing of the system as a whole. Testing of emergent properties is particularly important. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Acceptance testing </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Testing with customer data to check that the system meets the customer’s needs. </li></ul></ul></ul></ul></ul>Phase 4
  17. 17. Waterfall Model Phases <ul><li>Phase 5. Operation and maintenance </li></ul>Phase 5
  18. 18. Evolutionary Development <ul><li>Exploratory development </li></ul><ul><ul><li>Objective is to work with customers and to evolve a final system from an initial outline specification. </li></ul></ul><ul><ul><li>Start with well-understood requirements and add new features as proposed by the customer. </li></ul></ul><ul><li>Throw-away prototyping </li></ul><ul><ul><li>Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed. </li></ul></ul>
  19. 19. Evolutionary Development
  20. 20. Process Iteration <ul><li>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 </li></ul><ul><li>Iteration can be applied to any of the generic process models (e.g., waterfall) </li></ul><ul><li>Two (related) approaches </li></ul><ul><ul><li>Incremental delivery; </li></ul></ul><ul><ul><li>Spiral development. </li></ul></ul>
  21. 21. Incremental Development Reference: A. Finkelstein
  22. 22. Incremental Delivery <ul><li>Rather than deliver the system as a single delivery, </li></ul><ul><ul><li>the development and delivery is broken down into increments with each increment delivering part of the required functionality </li></ul></ul><ul><li>User requirements are prioritised </li></ul><ul><ul><li>highest priority requirements are included in early increments </li></ul></ul><ul><li>Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve </li></ul>
  23. 23. Incremental Development Advantages <ul><li>Early increments act as a prototype to help elicit requirements for later increments </li></ul><ul><li>Lower risk of overall project failure </li></ul><ul><li>The highest priority system services tend to receive the most testing </li></ul><ul><li>Customer value can be delivered with each increment so system functionality is available earlier </li></ul>
  24. 24. Spiral Development <ul><li>Process is represented as a spiral rather than as a sequence of activities with backtracking </li></ul><ul><li>Each loop in the spiral represents a phase in the process </li></ul><ul><li>No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. </li></ul><ul><li>Risks are explicitly assessed and resolved throughout the process </li></ul>
  25. 25. Spiral Model
  26. 26. Spiral Model
  27. 27. Spiral Model Sectors <ul><li>Objective setting </li></ul><ul><ul><li>Specific objectives for the phase are identified. </li></ul></ul><ul><li>Risk assessment and reduction </li></ul><ul><ul><li>Risks are assessed and activities put in place to reduce the key risks </li></ul></ul><ul><li>Development and validation </li></ul><ul><ul><li>A development model for the system is chosen which can be any of the generic models </li></ul></ul><ul><li>Planning </li></ul><ul><ul><li>The project is reviewed and the next phase of the spiral is planned </li></ul></ul>
  28. 28. Exercise -The Rational Unified Process <ul><li>Use the Internet to understand RUP. Prepare a brief summary on RUP for class discussion </li></ul>
  29. 29. RUP Model
  30. 30. RUP- Phases <ul><li>Inception </li></ul><ul><ul><li>Establish the business case for the system </li></ul></ul><ul><li>Elaboration </li></ul><ul><ul><li>Develop an understanding of the problem domain and the system architecture </li></ul></ul><ul><li>Construction </li></ul><ul><ul><li>System design, programming and testing </li></ul></ul><ul><li>Transition </li></ul><ul><ul><li>Deploy the system in its operating environment </li></ul></ul>
  31. 31. RUP- Class Discussion <ul><li>It is claimed that RUP, if adopted, can: </li></ul><ul><ul><li>Develop software iteratively, </li></ul></ul><ul><ul><li>Manage requirements, </li></ul></ul><ul><ul><li>Support component-based software development, </li></ul></ul><ul><ul><li>Verify software quality, </li></ul></ul><ul><ul><li>Control changes to software etc. </li></ul></ul><ul><li>What do you think? </li></ul><ul><li>Do you agree/disagree & Why? </li></ul>
  32. 32. Summary of Unit 2.1 <ul><li>Software processes are the activities involved in producing and evolving a software system </li></ul><ul><li>Software process models are abstract representations of these processes </li></ul><ul><li>General activities are specification, design and implementation, validation and evolution </li></ul><ul><li>Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering </li></ul><ul><li>Iterative process models describe the software process as a cycle of activities </li></ul><ul><li>The Rational Unified Process is a generic process model that separates activities from phases </li></ul>
  33. 33. Unit 2 Learning Objectives <ul><li>In this unit, </li></ul><ul><ul><li>Unit 2.1 </li></ul></ul><ul><ul><ul><li>Quick review software development processes & lifecycle </li></ul></ul></ul><ul><ul><li>Unit 2.2 </li></ul></ul><ul><ul><ul><li>Rational Unified Process </li></ul></ul></ul><ul><ul><ul><li>Model-driven development </li></ul></ul></ul><ul><ul><ul><li>Reuse-driven software development and landscape </li></ul></ul></ul><ul><ul><ul><li>Component-based software lifecycle </li></ul></ul></ul>
  34. 34. Challenges in Software Engineering <ul><li>Complexity </li></ul><ul><ul><li>The size and complexity of software is increasing rapidly </li></ul></ul><ul><li>Change, maintenance & continuous evolution </li></ul><ul><ul><li>Users’ Requirements and the environment in which the software works are in continuous change… </li></ul></ul><ul><ul><li>Changes in non-functional requirements have global impact to threat software stability </li></ul></ul><ul><ul><li>Legacy systems: old and valuable systems must be maintained, updated, and be integrated with new systems </li></ul></ul><ul><ul><li>Software upgrades are expected after deployment… </li></ul></ul>Development and evolution costs for long-lifetime systems System evolution System development Time
  35. 35. Challenges in Software Engineering <ul><li>Architecting dependable software </li></ul><ul><ul><li>Software must be trustworthy by its users </li></ul></ul>
  36. 36. Challenges in Software Engineering <ul><li>Single products become part of product family </li></ul><ul><li>Heterogeneity </li></ul><ul><ul><li>Software that can cope with heterogeneous platforms and execution environments </li></ul></ul><ul><ul><ul><li>E.g. Fixed distributed and mobile environments </li></ul></ul></ul><ul><li>Time to market </li></ul><ul><ul><ul><li>There is increasing pressure for faster delivery of software to gain competitive advantage </li></ul></ul></ul>
  37. 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. 38. Model Driven Development <ul><li>The software development process is driven by the activity of modelling (with UML) </li></ul><ul><li>Supports full lifecycle: analysis, design, implementation, deployment, maintenance, evolution and integration with later systems </li></ul><ul><li>Builds in Interoperability and Portability </li></ul><ul><li>Lowers initial cost and maximises return-on-investment </li></ul><ul><li>Applies directly to the mix you face: </li></ul><ul><ul><ul><li>Programming language; Network; Operating system, Middleware </li></ul></ul></ul>
  39. 39. The Model-Driven Process
  40. 40. MDA Framework <ul><li>A model is a description of a system. </li></ul><ul><li>A PIM describes a system without any knowledge of the final implementation platform. </li></ul><ul><li>A PSM describes a system with full knowledge of the final implementation platform. </li></ul><ul><li>A transformation definition describes how a model in a source language can be transformed into a model in a target language. </li></ul><ul><li>A transformation tool performs a transformation for a specific source model according to a transformation definition. </li></ul>
  41. 41. PIM - Platform Independent Model <ul><li>Platform Independent Model </li></ul><ul><ul><li>Model with a high level of abstraction independent of any implementing technology. </li></ul></ul><ul><ul><li>Specifies the system from the viewpoint of how it best supports the business. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  42. 42. PSM – Platform Specific Model <ul><li>A transformation of PIM tailored to specify a system in terms of the implementation constructs available in the chosen implementation technology </li></ul><ul><li>A PIM is transformed into one or more PSMs: for each specific technology platform a separate PSM is generated. </li></ul><ul><ul><li>For example, an EJB PSM is a model of the system in terms of EJB structures. </li></ul></ul><ul><ul><li>It typically contains EJB specific terms like “home interface”, “entity bean”, “session bean” and so on. </li></ul></ul><ul><ul><li>A relational database PSM includes terms like “table”, “column”, “foreign key”, and so on. </li></ul></ul>
  43. 43. Code <ul><li>The final step in the development is the transformation of each PSM to code. </li></ul><ul><li>A PSM fits its technology closely and so this transformation is relatively straightforward. </li></ul><ul><li>MDA defines the PIM, PSM, and code and also defines how these relate to each other. </li></ul>
  44. 44. Tool Support & References <ul><li>AndroMDA </li></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><li>An extensible open source generator framework that adheres to the Model Driven Architecture (MDA) paradigm. </li></ul><ul><li>Models from UML tools can be transformed into deployable components for your choice of platform (J2EE, Spring, .NET). </li></ul><ul><li>References: </li></ul><ul><ul><li>OMG </li></ul></ul><ul><ul><ul><li>http://www. omg .org/ mda </li></ul></ul></ul><ul><ul><li>Book by A. Kleppe et al., MDA Explained, Addison-Wesley, 2003 </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul>
  45. 45. Another Shift in Paradigm… 1970 1990 2000
  46. 46. Shift in Effort… Waterfall model Iterative development Component-based software engineering Specification Design Development Integration and testing 2 5 5 0 7 5 1 00 0 Specification Development Integration and testing 2 5 5 0 7 5 1 00 0 Specification Iterative development System testing 2 5 5 0 7 5 1 00 0 <ul><li>In CBSE much of the effort/cost are spent on </li></ul><ul><li>integration and testing… </li></ul>
  47. 47. Systematic Software Reuse <ul><li>In most engineering disciplines, systems are designed by composing existing components that have been used in other systems </li></ul><ul><li>Software engineering has been more focused on original development… </li></ul><ul><li>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... </li></ul>
  48. 48. Reuse Approaches & Landscape
  49. 49. Reuse Approaches & Landscape
  50. 50. Benefits of Reuse
  51. 51. Benefits of Reuse
  52. 52. Problems with Reuse
  53. 53. Problems with Reuse
  54. 54. Case Study: Ariane 5 <ul><li>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 </li></ul><ul><li>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 </li></ul><ul><li>The functionality that failed in this component was not required in Ariane 5 </li></ul><ul><ul><li> </li></ul></ul>
  55. 55. Case Study: Ariane 5 <ul><li>On June 4, 1996 Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off from French Guiana </li></ul><ul><ul><li> </li></ul></ul><ul><li>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 </li></ul><ul><li>A board of inquiry investigated the causes of the explosion and in two weeks issued a report </li></ul>
  56. 56. Case study: Ariane 5 <ul><li>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 . </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed! </li></ul></ul><ul><ul><li>There was no exception handler associated with the conversion so the system exception management facilities were invoked. These shutdown the software! </li></ul></ul><ul><ul><li>REUSE! </li></ul></ul>System Backup
  57. 57. Component-Based Software Engineering <ul><li>Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. </li></ul><ul><li>Process stages </li></ul><ul><ul><li>Component analysis; </li></ul></ul><ul><ul><li>Requirements modification; </li></ul></ul><ul><ul><li>System design with reuse; </li></ul></ul><ul><ul><li>Development and integration. </li></ul></ul><ul><li>Emphasis is on Reuse  Reuse-oriented development </li></ul><ul><li>This approach is becoming increasingly used as component standards have emerged. </li></ul>
  58. 58. Reuse-Oriented Development Analyse written software Do existing software/packages fit my need? e.g. Ariane 5 doesn’t require the 64bit conversion…. Drop it!
  59. 59. The CBSE process <ul><li>When reusing components, </li></ul><ul><ul><li>It is essential to make trade-offs between ideal requirements and the services actually provided by available components. </li></ul></ul><ul><li>This involves: </li></ul><ul><ul><li>Developing outline requirements; </li></ul></ul><ul><ul><li>Searching for components then modifying requirements according to available functionality </li></ul></ul><ul><ul><li>Searching again to find if there are better components that meet the revised requirements. </li></ul></ul>
  60. 60. The CBSE process
  61. 61. The Component Identification Process
  62. 62. Component dentification issues <ul><li>Trust. </li></ul><ul><ul><li>You need to be able to trust the supplier of a component </li></ul></ul><ul><ul><li>At best, an untrusted component may not operate as advertised; at worst, it can breach your security </li></ul></ul><ul><li>Requirements. </li></ul><ul><ul><li>Different groups of components will satisfy different requirements </li></ul></ul><ul><li>Validation. </li></ul><ul><ul><li>The component specification may not be detailed enough to allow comprehensive tests to be developed. </li></ul></ul><ul><ul><li>Components may have unwanted functionality. How can you test this will not interfere with your application? </li></ul></ul>
  63. 63. Component composition <ul><li>The process of assembling components to create a system </li></ul><ul><li>Composition involves integrating components with each other and with the component infrastructure </li></ul><ul><li>Normally you have to write ‘glue code’ to integrate components </li></ul>
  64. 64. V Development Process for CBS Software process
  65. 65. V Development Process for CBS
  66. 66. CBS Process
  67. 67. CBS Process <ul><li>Requirements: Requirements definition -> use case model and business concept model </li></ul><ul><li>Specification: Component Identification, Component Interaction, and Component Specification </li></ul><ul><li>Provisioning: determine what components to build, buy or reuse </li></ul><ul><li>Assembly: guide correct integration of components, existing assets and suitable user interface -> application that meets business needs </li></ul><ul><li>Theses phases replace analysis, design and implementation phases in processes like RUP. </li></ul>
  68. 68. Component Identification
  69. 69. Component Interaction
  70. 70. Provisioning <ul><li>Source component implementations either </li></ul><ul><ul><li>by directly implementing the specification or </li></ul></ul><ul><ul><li>by finding an existing component that fits the specification </li></ul></ul><ul><li>The component specification is as independent as possible from target technologies/platforms </li></ul>