Jordan - Amman Tel:5609999 Fax:5232899 P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved ASU Open Course.

Slides:



Advertisements
Similar presentations
Chapter 14 Design with Reuse.
Advertisements

1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Component-Based Software Engineering.
Chapter 17 Component-based software engineering
COM vs. CORBA.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 12 Slide 1 Distributed Systems Design 2.
Software Reuse SEII-Lecture 28
Figures – Chapter 17. Figure 17.1 Component characteristics Component characteristic Description StandardizedComponent standardization means that a component.
Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved ASU Open Course.
Software Reuse Building software from reusable components Objectives
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 19 Slide 1 Component-based software engineering.
- 1 - Component Based Development R&D SDM Theo Schouten.
Soft. Eng. II, Spring 02Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 6 Title : The Software Reuse Reading: I. Sommerville, Chap. 20.
Building software from reusable components.
Copyright Arshi Khan1 System Programming Instructor Arshi Khan.
Component-Based Software Engineering (CBSE) Speaker: Jerry Gao Ph.D. San Jose State University URL:
Dr. Eman M. Saleh Al-Maghary
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering 2.
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Design with Reuse l Building software from reusable components.
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19 Slide 1 Component-based software engineering 2.
Component Based Development
L6 - March 1, 2006copyright Thomas Pole , all rights reserved 1 Lecture 6: Software Packaging: Dynamically Integrable Components and Text Ch.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19 Slide 1 Component-based software engineering 1.
Topic 6 Component-based software engineering
COM vs. CORBA Computer Science at Azusa Pacific University September 19, 2015 Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department.
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1 Component-based development l Building software from reusable components l Objectives.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
Software Requirements Engineering CSE 305 Lecture-2.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Lecture 21 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor.
Chapter 17 Component-based software engineering 1Chapter 17 Software reuse CS 425 November 20, 2014 Ian Sommerville, Software Engineering, 9 th Edition.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19 Slide 1 Component-based software engineering.
SWE 316: Software Design and Architecture Objectives Lecture # 18 Introduction to Components SWE 316: Software Design and Architecture To learn:  benefits.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
©Ian Sommerville 2000 Software Engineering. Chapter 18Slide 1 Chapters 18/19 Software Reuse / CBSE.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Chapter 14 Design with Reuse.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
CBSE Component Based Software Engineering cs. upt
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 32. Review Behavioral Patterns – Observer Pattern – Chain of command.
Chapter 16 - Component-based software engineering Chapter 16 Component-based software engineering119/11/2014.
Slide 1 Service-centric Software Engineering. Slide 2 Objectives To explain the notion of a reusable service, based on web service standards, that provides.
Chapter 16 Component-based software engineering 1 CS 425 November 19, 2015 Ian Sommerville, Software Engineering, 10 th Edition Pearson Education, Addison-Wesley.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 15. Review Interaction-Oriented Software Architectures – MVC.
©Ian Sommerville 2006MSc module: Advanced Software Engineering Slide 1 Component-based software engineering.
Component-based Software Engineering CBSE seminar, Oslo, 4 Feb Christian Bunse
CS223: Software Engineering Lecture 13: Software Architecture.
©Ian Sommerville 2000, Tom Dietterich 2001 Slide 1 Distributed Systems Architectures l Architectural design for software that executes on more than one.
Component-based software engineering (Sommervile chapter 17) 1Chapter 17 Software reuse.
Dr D. Greer, Queens University Belfast ) Software Engineering Chapter 7 Software Architectural Design Learning Outcomes Understand.
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Chapter 17 - Component-based software engineering
Software Implementation Components and Services
Common Object Request Broker Architecture (CORBA)
Chapter 17 - Component-based software engineering
Chapter 18 Maintaining Information Systems
Service-centric Software Engineering
Software Reuse Objectives
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Component-Based Software Engineering
Component--based development
Chapter 7 –Implementation Issues
Chapter 17 - Component-based software engineering
COMPONENT – BASED SOFTWARE ENGINEERING MODULE 2 – SECOND SEMESTER MKHIZE, BSC HONS COMPUTER SCIENCES, DIP IT, ICDL.
Presentation transcript:

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved ASU Open Course System Jordan - Amman Tel: Fax: P.O.Box : 166 Component-Based Software Engineering Module 1 Part 2 Component Moldel Elements Dr. Eman M. Saleh Al-Maghary – Ext SE Department Faculty of Information Technology –

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component-Based Software Engineering Prerequisite: Text Books: “Software Engineering, Ian Sommerville, 9 th Ed., 2012.“Software Engineering, Ian Sommerville, 9 th Ed., “Building Reliable Component Based Software Systems, Ivica Crnkovic and Magnus Larsson, Artech House, 2002.“Building Reliable Component Based Software Systems, Ivica Crnkovic and Magnus Larsson, Artech House, 2002.

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Lecture Contents Component as a service and Interfaces Components models 3

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component interfaces Provides interface –Defines the services that are provided by the component to other components. Requires interface –Defines the services that specifies what services must be made available for the component to execute as specified. 4Chapter 17 Software reuse

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component interfaces Note UML notation. Ball and sockets can fit together. 5

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component models A component model is a definition of standards for component implementation, documentation and deployment. Examples of component models implementations –EJB model (Enterprise Java Beans) –COM+ model (.NET model) –Corba Component Model –Web srvices Model 6

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component models The theoretical component model is a definition of standards for component implementation, documentation and deployment. Examples of component models implementation: –EJB model (Enterprise Java Beans) –COM+ model (.NET model) –Corba Component Model

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Basic elements of a component model 8 Sommerville, Chapter 17

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Elements of a component model Interfaces –The component model specifies how the interfaces should be defined and the elements, such as operation names, parameters and exceptions, which should be included in the interface definition. – it defines the language that should be used to define interfaces –Examples: WSDL (web services), CIL (.NET) –Java language (EJB), OMG IDL (CORBA) 9

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Interface definition examples –E.g. IDL OLE interface ISimple : IDispatch { [id(1, helpstring("method StringLen")] HRESULT StringLen([in] BSTR str, [out,retval] long* length); };

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Basic elements of a component model 12 Sommerville, Chapter 17

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Elements of a component model Interfaces –The component model specifies how the interfaces should be defined and the elements, such as operation names, parameters and exceptions, which should be included in the interface definition. – it defines the language that should be used to define interfaces –Examples: WSDL ( for web services), CIL (.for.NET), Java language (EJB), OMG IDL ( for CORBA) 13

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Elements of a component model Usage: These are information that you need to use the component in a program 14

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Naming The global marketplace requires uniquely identifiable components and interfaces. Name clashes have to be avoided (when two different components are assigned the same name) Thus a standardized naming schema is a necessary part of a component model. 15

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Naming Schemas –Unique IDs:-Unique identifiers are generated by dedicated tools An example of unique IDs are Global Unique IDs (GUIDs), which are used by Microsoft's COM/DCOM/COM+ family –Unique URI : Services have Uniform resource Identifier –-Hierarchical name spaces-Hierarchical namespaces are guaranteed to be unique if the top- level names are uniquely registered with a global naming authority. Most Java-based component models use hierarchical namespaces (although there is no global naming authority). 16

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Basic elements of a component model 17 Sommerville, Chapter 17

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Meta Data Meta data is information about the component itself. This information provides the basis for scripting and remote method invocation and is used by composition tools and reflective programs 18

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Sample Nested Do Nothing Component 1 Simplified Component Metadata example 19

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Test Component <method name="getDataObjects" return- description="Retrieve all embedded DBObjects"> More Detailed Component Metadata example 20

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Elements of a component model Deployment –The component model includes a specification of how components should be packaged for deployment as independent, executable entities. 21

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Middleware support Component models are the basis for middleware that provides support for executing components. Component model implementations provide: –Platform services –Support services –To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations. 22

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Middleware services defined in a component model 23

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Middleware support Component models are the basis for middleware that provides support for executing components. Component model implementations provide: –Platform services that allow components written according to the model to communicate; –Support services that are application-independent services used by different components. To use services provided by a model, components are deployed in a container. This is a set of interfaces used to access the service implementations. 24

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Previous Lectures What is CBSE, its Essentials and goals Component as a service and Interfaces Components models 25

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved This Lectures Relationship between different component parts and the component model CBSE Processes 26

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component Anatomy : Other Component Component Internals (Private Aspects) Platform Interface (Vertical Channel) Application Interface (Horizontal Channel) Application Interface (Horizontal Channel) Middleware Platform (Operating System, Communication Subsystem, and other Hardware Systems) 28

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component Anatomy : Other Component Component Internals (Private Aspects) Platform Interface (Vertical Channel) Application Interface (Horizontal Channel) Application Interface (Horizontal Channel) Middleware Platform (Operating System, Communication Subsystem, and other Hardware Systems) 29

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Internals (Private Aspects) Internals (Private Aspects) : it represents internal information and structure of a component. It represents the actual functionality (code) of the components as showing by its interface. 30

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component Anatomy : Other Component Component Internals (Private Aspects) Platform Interface (Vertical Channel) Application Interface (Horizontal Channel) Application Interface (Horizontal Channel) Middleware Platform (Operating System, Communication Subsystem, and other Hardware Systems) 31

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Application Interface Application Interfaces. 1.Direct interaction: Interfaces define the Direct interactions with other components in the same machine. 2.Indirect Interaction: Interfaces define the indirect interactions with Middleware for remote components Such interfaces represent the import or export relationships with other components or the middleware with which the component interacts. 32

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component Anatomy : Other Component Component Internals (Private Aspects) Platform Interface (Vertical Channel) Application Interface (Horizontal Channel) Application Interface (Horizontal Channel) Middleware Platform (Operating System, Communication Subsystem, and other Hardware Systems) 33

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Platform Interfaces It defines the component interaction with the platform on which it executes. A platform may be characterized by the hardware (specific processor, memory, communication equipments, or other hardware), the operating system; including the runtime environment, access to peripherals, communication subsystems, and so forth. Component developers may generate different components, one for each platform, This type of interfaces is essential for special type of applications (embedded systems for example) 34

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved For example, assume that we are developing a CORBA object that sorts an array of integers and we are making the source code available as a reusable component. We can identify the model elements as follows: Internals: The sort mechanism is designed and coded in C++, this represents the private aspects of the components. Application Interfaces (Horizontal Channel): The application interface will be the Interface Definition Language IDL. interface specifying the functionality available (sorting) and its signature. The component can then be called through the middleware i.e the ORB. Platform Interfaces (Vertical Channel): To run this component on a Windows environment (for example), a subset of the platform interfaces could be specified by: Compile with : C++ compiler for windows Run on: Windows Platform 35

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component Anatomy Example CORBA C++ Sort Component Other Component Component Internals (Private Aspects) Platform Interface (Vertical Channel) Application Interface (Horizontal Channel) Application Interface (Horizontal Channel) Middleware Platform (Operating System, Communication Subsystem, and other Hardware Systems) 36 C++ code IDL Interface IDL Interface ORB Compile in C++ Runs On Windowa X.Y Processor –intel 64 bit Windows OS, Processor X,….

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved 37

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Now assume that we want to develop the same component in Java. Internals: The sort mechanism is designed and coded in Java. Application Interfaces (Horizontal Channel): The application interface will still be an IDL interface. Platform Interfaces (Vertical Channel): The platform interfaces would include the Java Virtual Machine for that specific platform. 38

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved SC Theoretical Model Interface Naming MetaData. SC Internals (Private Aspects) Platform Interface (Vertical Channel) Application Interface (Horizontal Channel) Application Interface (Horizontal Channel) 39

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved 40

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved CBSE processes CBSE processes are software processes that support component-based software engineering. –They take into account the possibilities of reuse and the different process activities involved in developing and using reusable components. Development for reuse –This process is concerned with developing components or services that will be reused in other applications. It usually involves generalizing existing components. Development with reuse –This process is the process of developing new applications using existing components and services. 41 Chapter 17

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved CBSE processes 42

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Supporting processes Component acquisition is the process of acquiring components for reuse or development into a reusable component. –It may involve accessing locally- developed components or services or finding these components from an external source. Component management is concerned with managing a company’s reusable components, ensuring that they are properly catalogued, stored and made available for reuse. Component certification is the process of checking a component and certifying that it meets its specification. 43

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved CBSE for reuse CBSE for reuse focuses on component development. Components developed for a specific application usually have to be generalized to make them reusable. A component is most likely to be reusable if it associated with a stable domain abstraction (business object). 44

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component development for reuse Components for reuse may be specially constructed by generalising existing components. Component reusability –Should reflect stable domain abstractions; –Should hide state representation; –Should be as independent as possible; –Should publish exceptions through the component interface. There is a trade-off between reusability and usability –The more general the interface, the greater the reusability but it is then more complex and hence less usable. 45Chapter 17 Software reuse

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Changes for reusability Remove application-specific methods. Change names to make them general. Add methods to broaden coverage. Make exception handling consistent. Add a configuration interface for component adaptation. Integrate required components to reduce dependencies. 46Chapter 17 Software reuse

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Exception handling Components should not handle exceptions themselves, because each application will have its own requirements for exception handling. –Rather, the component should define what exceptions can arise and should publish these as part of the interface. 47

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Exception handling In practice, however, there are two problems with this: –Publishing all exceptions leads to bloated interfaces that are harder to understand. This may put off potential users of the component. –The operation of the component may depend on local exception handling, and changing this may have serious implications for the functionality of the component. 48

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Reusable components The development cost of reusable components may be higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost. Generic components may be less space- efficient and may have longer execution times than their specific equivalents. 49

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Reusable components There is a trade-off between reusability and usability –The more general the interface, the greater the reusability but it is then more complex and hence less usable. 50

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component management Component management involves deciding how to classify the component so that it can be discovered, making the component available either in a repository or as a service, maintaining information about the use of the component and keeping track of different component versions. A company with a reuse program may carry out some form of component certification before the component is made available for reuse. –Certification means that someone apart from the developer checks the quality of the component. 51

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved CBSE with reuse CBSE with reuse process has to find and integrate reusable components. 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. –Composing components to create the system. 52

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved CBSE with reuse 53 Sommerville,Chapter 17

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved The component identification process 54Chapter 17 Software reuse

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component identification 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? 55Chapter 17 Software reuse

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Component validation Component validation involves developing a set of test cases for a component (or, possibly, extending test cases supplied with that component) and developing a test harness to run component tests. –The major problem with component validation is that the component specification may not be sufficiently detailed to allow you to develop a complete set of component tests. As well as testing that a component for reuse does what you require, you may also have to check that the component does not include any unsuitable code or functionality that you don’t need. 56

Jordan - Amman Tel: Fax: P.O.Box : 166 Copyright © 2011 Applied Science University. All Rights Reserved Ariane launcher failure – validation failure? 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. 57