1. Computing: An Object-Oriented Approach Chapter 35 Component-based Software Development Prepared by: M206 Team - Kuwait Branch

2. M206 Team Work - Kuwait Branch2 Objectives Describe the potential benefits and drawbacks of reuse both to software and to the software development process. Describe the characteristics of a component that make it reusable. Explain why encapsulation is important if software components are to be reused successfully. Describe the concepts of cohesion and coupling in the context of object oriented software. Describe what is involved in both design for reuse and design with reuse and what this means in the context of the development method used in this course.

3. M206 Team Work - Kuwait Branch3 Introduction In Chapters 33 and 34 we studied the activities in our software development method that are concerned with producing an initial structural model of a system. The purpose of this model is to represent some of the static aspects of the system in terms of classes and associations between them. The next stage will involve us in developing dynamic models of the system; Models in which we describe how the behavior of the system will be achieved in the context of the structural model. Having developed dynamic models of the system we shall then refine the detail of the design for the system. Deciding how each class, and its responsibilities, will be implemented and will implement the system accordingly.

4. M206 Team Work - Kuwait Branch4 Introduction The traditional development of software has been viewed as a sequential process of steps or phases, where each step is completed before the next step starts. For example, design would be completed before any implementation is undertaken. With the advent of object-oriented technology this sequential process of software development is no longer appropriate. For this reason, we refer to development activities rather than steps!

5. M206 Team Work - Kuwait Branch5 1. Components Component-based manufacturing makes available to the marketplace many products that would otherwise be prohibitively expensive. Software development would be enhanced if: We could produce and use software components in a similar fashion to those components produced and used by engineers in constructing artifacts such as cars. And not always constructing specific software solutions from scratch. i.e. following a component-based approach. The goal of component-based software development is to employ the software components to produce a quick and inexpensive assembled reliable software. Irrespective of whether it is a one-off program for a particular customer or a production for the mass market.

6. M206 Team Work - Kuwait Branch6 1.1 Reusable components The main benefit of having components is the reusability and the potential to be employed in more than one program or system. The advantages of having reusable components: Already have been tested. A component may be replaced without the rest of the software requiring significant change. The difficulties in dealing with reusable components: The search for a suitable component may be a lengthy process. The reused component may not have been tested in a sufficiently similar environment to the one in which it is to be reused. There are two issues related to component reuse: How to produce reusable components. How to use the reusable components.

7. M206 Team Work - Kuwait Branch7 1.2 Hardware components A characteristic of an engineering discipline is that it is based upon an approach to design that makes appropriate use of existing components. Engineers do not specify a design where every component has to be manufactured especially, but base their design on components that have been tried and tested in other systems such as nuts, bolts, engines, gearboxes and fuel pumps. When new components have to be designed, it is with the expectation of reusing them later in other products or systems. Such an approach to design reduces the time and cost of developing products and systems without compromising the reliability and efficiency of the final product or system. The approach also promotes the construction of maintainable products and systems, since components are replaceable.

8. M206 Team Work - Kuwait Branch8 1.2 Hardware components The following are the main characteristics of hardware components: Components are designed and packaged as independent building blocks that may be used in the construction of different products and systems. Components are constructed from a hierarchy of building blocks where the ‘leaves’ are fundamental building blocks. Components are designed and built to a specification, where the interface between components is standardized. Manufacturers (implementers) and users of components can hold different but appropriate perspectives of the components with which they deal. (They only need to be conversant with its interfaces with other components.)

9. M206 Team Work - Kuwait Branch9 1.3 Object-oriented software components Developing object-oriented software is based on the notion of software as a collection of objects that interact with each other to perform some useful purpose. A single class is considered as an OO-software component. In some cases more than one related classes can be considered as one component. After examining whether software components share the characteristics of hardware components described before or not. We conclude that object-oriented technology could facilitate component-based software development, with encapsulation being the basis of a successful approach. Following is a brief description of the characteristics of OO- software components compared with characteristics of hardware components.

10. M206 Team Work - Kuwait Branch10 1.3 Object-oriented software components Components are designed and packaged as independent building blocks that may be used in the construction of different products and systems. A class’s protocol, and the information needed by objects of that class to implement the protocol, are packaged under the name of the class, and can be reused as one software component. Smalltalk allows the internal structure of an object to be available to the object itself, but not to any other object. An object can change its own state directly, but other object need to send it a message to achieve this (concept of encapsulation). Components are constructed from a hierarchy of building blocks where the leaves’ are fundamental building blocks. In Smalltalk an object may possess instance variables referencing other objects, which themselves may possess instance variables referencing other objects, and so on, until the objects that are fundamental building blocks. In OOP, these fundamental blocks are considered to be immutable objects. (e.g. objects of SmallInteger and Character classes).

11. M206 Team Work - Kuwait Branch11 1.3 Object-oriented software components Components are designed and built to a specification where the interface between components is standardized. The specification of a class describes its protocol. In Smalltalk, this specification includes, for each message, the corresponding method heading and the initial comments, which by convention provide an English language description of what the method does. The specification describes what an object of that class does; what its behavior is when its services are used. So the software developer can use those services in a system without the concern of how they are implemented. One class may be replaced by another in a system, as long as both have identically specified protocols. Such a substitution doesn’t affect the functionality of the software since the implementation is encapsulated within the objects of the class. A vital concept here is that of polymorphism which allows a message requesting a service to be sent without concern for the class of object receiving the message.

12. M206 Team Work - Kuwait Branch12 1.3 Object-oriented software components Manufacturers (implementers) and users of components can hold different but appropriate perspectives of the components with which they deal. Encapsulation requires the separation of the specification and the implementation of a class of objects. A user of the services provided by an object must be familiar with the protocol for invoking those services (for specifying what is desired). The implementer of the services must be concerned with how the services are to be provided to the user. This separation facilitates software development at appropriate levels of abstraction. From this comparison we can conclude that object-oriented technology could facilitate component-based software development as we mentioned. However there are many issues, both technical and social, that need to be addressed before component-based software development becomes more viable and acceptable to the software industry.

13. M206 Team Work - Kuwait Branch13 2. A component-based approach to design and implementation There are two aspects of component-based software development: Design with reuse: The process of constructing a software by reusing existing software components. Example: using the class library supplied with the Smalltalk system. Design for reuse: When suitable components are not available, developing new components both for that project and for possible reuse by other future projects.

14. M206 Team Work - Kuwait Branch14 2.1 Design with reuse Reuse concerns not just using existing components without modification, but also adapting components for reuse employing, for example, inheritance. The protocol of a new class can be extended by implementing additional methods or modified by overriding inherited methods. The advantages to the software developer of reusing software? New software can be produced more cheaply and more quickly, and existing software can be maintained more easily. The quality of software may be higher and contain fewer defects since reused code will already have been tested.

15. M206 Team Work - Kuwait Branch15 2.1 Design with reuse Prototyping is a term normally used to describe the development of an early working model of a system or part of a system, to test and confirm ideas about what the system is required to do and how best to achieve this. Prototyping is often regarded as a throw-away activity, with the resulting code being discarded. This approach is intended to discover any further refinement of some aspect of the system. Incremental prototyping involves employing reuse to facilitate the construction of software components in an incremental fashion, where prototype components that meet the essential requirements are initially implemented and are successively adapted by reuse until they meet all the requirements.

16. M206 Team Work - Kuwait Branch16 2.2 Design for reuse The production of reusable components requires foresight of the requirements for software components by future software projects, and is a job for skilled designers and implementers. 1.For component-based software development to be a practical proposition, encapsulation must be maintained. If a message in its protocol is used in an unintended way its integrity is not guaranteed. It is therefore often necessary for a software developer to explicitly maintain encapsulation during design and implementation. 2.The separation of the specification of a class from its implementation (as part of the encapsulation of objects) brings the benefit of encouraging the development of software at appropriate levels of abstraction.

17. M206 Team Work - Kuwait Branch17 2.2 Design for reuse 3.The focus is on defining what responsibilities an object has; before specifying how it carries out these responsibilities. Such an approach is sometimes referred to as responsibility- driven design. It is inspired by the client/server model, a description of the collaborations between two objects. The model focuses on what services a server provides for clients, rather than on how the server provides them. 4.Two factors have to be considered in designing for reuse: Cohesion: A measure of how strongly related and focused the responsibilities of a class are. Coupling: A measure of the extent to which the classes in a system are dependent on (or rely on) each other.

18. M206 Team Work - Kuwait Branch18 2.2 Design for reuse Cohesion: A measure of how strongly related and focused the responsibilities of a class are. High cohesion is the ideal. This means that a class should define responsibilities that we would expect to see carried out by a single object, and it should not have too many of them. A class with low cohesion defines unrelated responsibilities, or defines too many responsibilities. Such features may mean that the class is harder to reuse: it is less likely to be useful in other projects, and may be harder to understand, test and maintain. For example, an Account class for a banking system is likely to define responsibilities for maintaining details of an account (its balance, and so on). It should not have unrelated responsibilities for maintaining details of mortgages: such responsibilities are likely to be more appropriately allocated elsewhere, to a Mortgage class, for example.

19. M206 Team Work - Kuwait Branch19 2.2 Design for reuse Coupling: A measure of the extent to which the classes in a system are dependent on (or rely on) each other. Although encapsulation means that each class is independent of the implementation of other classes, other kinds of dependencies can exist between classes. For example, one class can be considered to be dependent on another if an object of the first class needs to send a message to an object of the second; i.e. if the classes collaborate. Low coupling is the ideal. A class with low coupling is dependent on as few other classes as possible. A highly coupled class may be dependent on many other classes and this may mean that the class is harder to reuse. Whilst it is important to recognize the importance of high cohesion and low coupling, the attainment of these ideals is not usually straightforward in practice (as we shall discuss further in Chapter 39).

20. M206 Team Work - Kuwait Branch20 2.3 Reuse in the M206 development method In our development method we aim to follow at least the basics of a component-based approach, attempting to balance this with other factors such as the need to maintain an appropriate distinction between the domain model and the user interface. We will concentrate on specifying the protocol of a class (Chapters 39 and 45) before considering how the protocol is to be implemented (Chapter 46), and will maintain encapsulation when defining methods (Chapter 46). When we have choices to make in the allocation of responsibilities to classes, we shall refer to the ideals of high cohesion and low coupling (Chapter 39). We shall reuse existing components by using and adapting existing classes in our Smalltalk hierarchy (Chapter 45). We shall also aim to produce structures that are amenable to future reuse by the creation of classes within sensibly structured hierarchies (Chapter 45). Key elements of our approach: Our development will generally progress from the abstract to the specific: from design to detailed design to implementation. During development process it is important to produce models of the system at appropriate levels of abstraction.