©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1 Component-based development l Building software from reusable components l Objectives To explain the benefits and challenges of constructing software systems from existing components To introduce the concept of design frameworks and middleware

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 2 Software components l In most engineering disciplines, systems are designed by composing existing components that have been used in other systems l Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic reuse

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 3 CBSE l Component-based software engineering (CBSE) is an approach to software development that relies on reuse l It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific l Components are more abstract than object classes and can be considered to be stand-alone service providers

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 4 Components l Components provide a service without regard to where the component is executing or its programming language A component is an independent executable entity that can be made up of one or more executable objects The component interface is published and all interactions are through the published interface l Components can range in size from simple functions to entire application systems

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 5 Component interfaces

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 6 Component abstractions l Functional abstraction The component implements a single function such as a mathematical function l Casual groupings The component is a collection of loosely related entities that might be data declarations, functions, etc. l Data abstractions The component represents a data abstraction or class in an object-oriented language l Cluster abstractions The component is a group of related classes that work together l System abstraction The component is an entire self-contained system

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 7 CBSE problems l Component incompatibilities may mean that cost and schedule savings are less then expected l Finding and understanding components l Managing evolution as requirements change in situations where it may be impossible to change the system components

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 8 COTS –based development l COTS - Commercial Off-The-Shelf systems l COTS systems are usually complete application systems that offer an API (Application Programming Interface) l Building large systems by integrating COTS systems is now a viable development strategy for some types of system e.g., E-commerce systems l Package-oriented programming (POP) is a step beyond COTS

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 9 COTS system integration problems l Lack of control over functionality and performance COTS systems may be less effective than they appear l Problems with COTS system inter-operability Different COTS systems may make different assumptions that means integration is difficult l No control over system evolution COTS vendors not system users control evolution l Support from COTS vendors COTS vendors may not offer support over the lifetime of the product

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 10 Application frameworks l Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them l The sub-system is implemented by adding components to fill in parts of the design and by instantiating the abstract classes in the framework l Frameworks are moderately large entities that can be reused

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 11 Framework classes l System infrastructure frameworks Support the development of system infrastructures such as communications, user interfaces and compilers l Middleware integration frameworks Standards and classes that support component communication and information exchange l Enterprise application frameworks Support the development of specific types of application such as telecommunications or financial systems

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 12 Extending frameworks l Frameworks are generic and are extended to create a more specific application or sub-system l Extending the framework involves Adding concrete classes that inherit operations from abstract classes in the framework Adding methods that are called in response to events that are recognised by the framework l Problem with frameworks is their complexity and the time it takes to use them effectively

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 13 Model-view controller l System infrastructure framework for GUI design l Allows for multiple presentations of an object and separate interactions with these presentations

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 14 Middleware – CORBA l CORBA is an international standard for an Object Request Broker middleware to manage communications between distributed objects l Several implementation of CORBA are available l DCOM is an alternative approach by Microsoft l CORBA has been defined by the Object Management Group

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 15 Application structure l Application objects l Standard objects, defined by the OMG, for a specific domain e.g. insurance l Fundamental CORBA services such as directories and security management l Horizontal (i.e. cutting across applications) facilities such as user interface facilities

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 16 CORBA application structure

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 17 CORBA objects l CORBA objects are comparable, in principle, to objects in C++ and Java l They MUST have a separate interface definition that is expressed using a common language (IDL) similar to C++ l There is a mapping from this IDL to programming languages (C++, Java, etc.) l Therefore, objects written in different languages can communicate with each other

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 18 Object request broker (ORB) l The ORB handles object communications. It knows of all objects in the system and their interfaces l Using an ORB, the calling object binds an IDL stub that defines the interface of the called object l Calling this stub results in calls to the ORB which then calls the required object through a published IDL skeleton that links the interface to the service implementation

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 19 ORB-based communication

©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 20 l Component-based software engineering relies on black-box components with defined requires and provides interfaces l COTS product reuse is concerned with the reuse of large, off-the-shelf systems l CORBA is a set of middleware standards that support distributed object architectures Key points