The design process is concerned with describing how a requirement is to be met by the design product. In other words, design is a creative process of transforming the problem into a solution. Good design is the key to effective engineering. However, it is not possible to formalize the design process in any engineering discipline. It must be practiced and learnt by experience and study of existing system (Turner et al.
2003). Software design can be viewed in the same way. We use the requirements specification to define the problem. Then, we declare something to be a solution to the problem if it satisfies all the requirements in the specification. The nature of the solution may change as the solution is described or implemented (Pfleeger2001).
Object-oriented design is a design strategy based on information hiding. It differs from the functional approach to design in that it views a software system as a set of interactive objects with its own private state, rather than as a set of functions that share a global state. Outside the business systems domain it is the
predominant design strategy for new software systems. In an object-oriented design, the system state is decentralized and each object manages its own state information. Objects have a set of attributes defining their own state and operations which act on these attributes. Objects are usually members of an object class whose definition defines attributes and operations of class members. These may be inherited from one or more super-classes so that a class definition need only set out the differences between that class and its super-classes. Conceptually, objects communicate by exchanging messages; in practice, most object communication is achieved by an object calling a procedure associated with another object.
The stages in object-oriented approach according to Sommerville (2004) are:
1. Understand and define the context and the modes of use of system 2. Design the system architecture
3. Identify the principal objects in the system 4. Develop design models
5. Specify object interface
All the activities here are interleaved and influence each other. Here, objects are identified and the interfaces fully or partially specified as the architecture of the system is defined. As the object models are produced, these individual object definitions may be refined, which leads to changes to system architecture. The aim of the object-orientation is to employ reusable components rather than writing the modules from scratch. This approach would result in increased systems develop-ment productivity and higher systems quality (Burch1992).
In the preceding section, it was remarked that in identifying the benefits that could be obtained through using the principle of information hiding, (Parnas2001) also recognized that it was difficult to produce such structures by following any well-formed set of procedures. By the time the object-oriented philosophy began to coalesce in the late 1970s, it was obvious that this difficulty with providing any form of design process that incorporated encapsulation still remained a significant problem, and, indeed, that the problems were increased further by the nature of the object-oriented model being so very different from the forms previously experi-enced. A further spur to finding a design process that could encompass object-oriented principles came from the development of the Ada programming language, which became an ANSI standard in 1983. While the 1983 form of Ada is not strictly an object-oriented programming language, it can be considered to be object-based in its form, since its structures support the use of:
• Abstraction, both in terms of data typing and through the generic mechanism with the latter allowing for some abstraction in the description of the algorithmic part;
• Encapsulation, since the scope of data instances can be controlled via the private/public mechanism;
• Modularity, through the use of the package construct (and arguably by using the 3 task and the procedure mechanisms).
130 7 System Design
7.4.1 Component-Based Design
Component-based software engineering (CBSE) is commonly considered the next step after object-oriented programming. It is not surprising that components are often related to objects and sometimes the term component is simply used as a synonym for object. However, the concepts of components and objects are inde-pendent, although most component models are based on object-oriented concepts.
To avoid further confusion we will briefly characterize objects and components and outline their differences.
7.4.2 Components and Objects
Objects are entities that encapsulate state and behavior, and have a unique identity.
The behavior and structure of objects are defined by classes. A class serves multiple purposes: First, it implements the concept of an abstract data type (ADT) and provides an abstract description of the behavior of its objects. Class names are often used as type names in strongly typed systems. Second, a class provides the implementation of object behavior. Third, a class is used for creating objects, that is, instances of the class.
Nearly all modern component models are based on the object-oriented gramming paradigm. The basic premise of object-orientation is to construct pro-grams from sets of interacting and collaborating objects. This does not change with component based approaches. Components are similar to classes. Like clas-ses, components define object behavior and create objects. Objects created by means of components are called component instances. Both components and classes make their implemented functionality available through abstract behavior descriptions called interfaces.
Unlike classes, the implementation of a component is generally completely hidden and sometimes only available in binary form. Internally, a component may be implemented by a single class, by multiple classes, or even by traditional procedures in a non-object-oriented programming language. Unlike classes, component names may not be used as type names. Instead, the concept of type (interface) and the concept of implementation are completely separated. Finally, the most important distinction is that software components conform to the stan-dards defined by a component model.
7.4.3 Component Models
A component model defines a set of standards for component implementation, naming, interoperability, customization, composition, evolution, and deployment.
A component model also defines standards for associated component model
implementations, i.e., the dedicated set of executed software entities that are required to support the execution of any component that conforms to said com-ponent model.
There are numerous component models currently available. The main com-peting component models today are OMG’s CORBA Component Model (CCM), Microsoft’s (D)COM/COM family, and SUN Microsystems JavaBeans and Enterprise JavaBeans. We need generally accepted component models to create a global component market-place. It is not necessary to agree on one standard, but at the same time there should not be too many standards. The market share of a particular standard has to be large enough to make the development of compliant components worthwhile. In this chapter we comment on important elements constituting a component model (Weber et al.2000).
In the global software component marketplace, components are independently deployed and subject to third-party composition. This marketplace requires stan-dards. Standards for communication and data exchange among components from different component producers are obvious. Such an interoperability standard, sometimes called a wiring or connection standard, is a central element in a compo-nent model. Other basic elements of a compocompo-nent model are standards for interfaces, naming, meta data, customization, composition, evolution, and deployment.
A component model can also have specialized standards for describing domain specific features required for certain applications. For example, the composition of components in domains with concurrent activities requires appropriate standard-ized threading models and synchronization mechanisms. An open distributed processing system requires standards for remote method invocation and security.
7.4.4 The Component Concept
Although the goal of reusing elements of one system in other systems has long been associated with the object-oriented paradigm, it really has a much longer history. Actual reuse through object-orientation would appear to be quite difficult to achieve. At the ‘system facilities’ level there are some successful examples such as Java’s Abstract Windowing Toolkit (AWT). For this type of example, reuse is motivated both by the need to avoid rewriting major low-level elements of soft-ware, and also by the influence of human factors, since users generally like to see a consistent presentational style for the images on a screen, regardless of the application producing them.
For other domains in which design is an important process, the idea of com-ponent reuse is fairly well established, although systematic practices to support such reuse are relatively informal. One motivation for reuse of components is that it reduces the manufacturing costs of the final product, something that of course does not have any parallel for software development and distribution. Indeed, although the concept of ‘product lines’ appears to have become established by the early 1900s, the adoption of manufacturing (and hence design) reuse on an
132 7 System Design
incredibly large scale would appear to have been highly motivated by the need to increase manufacturing volume drastically during the Second World War.
Perhaps one of the most visible examples of designing around reusable com-ponents that can be encountered in the current era is that of the motor car. While a given manufacturer’s models may differ substantially in appearance, many ele-ments such as switches, instruele-ments, starter motors etc. will be common across manufacturers. Design reuse is also (if less visibly) used very successfully in such domains as electronics, as well as in the building industry (for example, through the standardization of dimensions for windows, doors, pipes), and in many other domains. The motivation may well be ease of both manufacturing and mainte-nance. While the former is more relevant to software, the latter may also be a significant factor when viewed across the often-long lifetimes of software prod-ucts, even if maintenance of these is interpreted in a rather different way.
While such reuse may often be centered upon quite small elements, larger, pos-sibly composite, ones are reused too (car engines provide a good example). However, there are two important characteristics of such reuse that we need to note here.
• The first is that it is commonly based upon well-defined functionality. Most physical components have very well defined roles (starter motor, pump, switch, etc.), making it easy for the designer to identify the appropriate manufacturer’s catalogues, and then search them in order to view what is available to them.
• The second is that the elements themselves have well-defined interfaces. Indeed, an important corollary of this is that there may also be several manufacturers who are able to provide a given component (‘second sourcing’). Substitution may be an exact functional and non-functional match (as it tends to occur for integrated circuits), or may differ slightly in terms of non-functional charac-teristics, while still conforming to the specified interface.
These are not accidental properties, but rather ones that are driven by several economic factors. These include the need to minimize the cost of manufacturing an item, pressure to maintain a marketplace position, and the user’s need to protect their supply chain (here the ‘user’ is another manufacturer who makes use of a given component for integration into their own product). Sometimes the standards necessary to enable this emerge from marketplace factors, leading to the accep-tance of one manufacturer’s format as a standard for all; at other times an industry may set up a standards body to undertake the role of agreeing standards. Whatever the route leading to the standards, there is significant pressure on manufacturers to conform to them. For the engineering designer, as mentioned above, catalogues of components are now readily available in many domains, with examples ranging across electronic and electrical, to mechanical and civil engineering. However, the ways in which these catalogues are used during the design process appear to be a rather more elusive concept. A good example of this is given in Pugh, which provides the following quotation from Cooke:
The designer of electronic-based products has available an enormous range of basic building blocks of high or still increasing complexity. What he often does not have is
either training or well-established conceptual tools for working out levels of sophistication.
A situation which still seems largely unchanged similarly in Pahl et al. (1996), widely cited as a repository of engineering design knowledge, the discussion of
‘design catalogues’ is almost entirely confined to consideration of how such a catalogue should be constructed. The authors suggest that component classification should be based upon function, since the assumption is that the catalogue will be searched for components that will meet specific sub functions of the conceptual design. Indeed, their view of component reuse is very much that this is a subsidiary element of the design process.
Turning to software, the above characteristics take very different forms. Func-tionality is apt to be blurred and can be extended or modified with relative ease, whereas no-one would even think of modifying the design of a car’s starter motor so that it can also be used to power the engine’s cooling fan. It is easy to generate variants of a software unit, and hence there are few catalogues of software com-ponents only of the end products. Interfaces are rarely standardized to any great degree and producers are much less motivated to conform to such standards that may exist. Likewise, although standards bodies may exist, they are likely to be less effective than their manufacturing counterparts. Second, sourcing of components from more than one supplier in order to protect a supply chain exists only in a limited form, —although the motivations for adopting this practice may not be so different.
All of this is important when we come to examine the ways in which the component concept has been mapped on to the software domain. In the rest of this section we examine how the concept has been interpreted, identify the characteristics of a software component, and consider how business models may have to be modified to cope with these characteristics. The following sections then examine more design-centered ideas about how to design with components and how to design components for reuse, as well as considering the effects of the ‘proprietary factor’.