Your SlideShare is downloading. ×
Engineering Component-Based Software: Processes
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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