• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Engineering Component-Based Software: Processes

Engineering Component-Based Software: Processes






Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.slideshare.net 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.


11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • اريد شرح مفصل وشكرا
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Engineering Component-Based Software: Processes Engineering Component-Based Software: Processes Presentation Transcript

    • 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
    • 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
    • Critical Question How do you distinguish the process of “ Component Development” from that of “Systems development with Components”?
      • 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”
    • 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?
    • 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
    • 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
    • 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.
      • 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
    • Waterfall Model
    • 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
    • Phase 1. Requirements Engineering process Output Activities
    • 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
    • The Software Design Process Output
    • 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
    • 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
    • Waterfall Model Phases
      • Phase 5. Operation and maintenance
      Phase 5
    • 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.
    • Evolutionary Development
    • 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.
    • Incremental Development Reference: A. Finkelstein
    • 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
    • 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
    • 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
    • Spiral Model
    • Spiral Model
    • 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
    • Exercise -The Rational Unified Process
      • Use the Internet to understand RUP. Prepare a brief summary on RUP for class discussion
    • RUP Model
    • 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
    • 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?
    • 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
    • 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
    • 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
    • Challenges in Software Engineering
      • Architecting dependable software
        • Software must be trustworthy by its users
    • 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
    • Challenges in Software Engineering Concentration on the business issues… “ Around 30% of the development effort is spent on the infrastructure that add no value ”
    • 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
    • The Model-Driven Process
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • Another Shift in Paradigm… 1970 1990 2000
    • 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…
    • 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...
    • Reuse Approaches & Landscape
    • Reuse Approaches & Landscape
    • Benefits of Reuse
    • Benefits of Reuse
    • Problems with Reuse
    • Problems with Reuse
    • 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
    • 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
        • http://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
    • 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
      • 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.
    • 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!
    • 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.
    • The CBSE process
    • The Component Identification Process
    • 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 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
    • V Development Process for CBS Software process
    • V Development Process for CBS
    • CBS Process
    • 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 Identification
    • Component Interaction
    • 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