SDA01 9/18/07 10:32 AM Page iii
www.Vidyarthiplus.com
Software Design
www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 3
www.Vidyarthiplus.com
UNIT 1 : SOFTWARE DESIGN PRINCIPLES INTRODUCTION Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activities involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... in a stylized software engineering process." Software design usually involves problem solving and planning a software solution. This includes both low-level component and algorithm design and high- level, architecture design. Software design is the process of implementing software solutions to one or more set of problems. One of the important parts of software design is the software requirements analysis (SRA). It is a part of the software development process that lists specifications used in software engineering. If the software is "semi- automated" or user centered, software design may involve user experience design yielding a story board to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-standard methods like Unified Modeling Language and Fundamental modeling concepts. In either case, some documentation of the plan is usually the product of the design. Furthermore, a software design may be platform-independent or platform-specific, depending on the availability of the technology used for the design.
Software design can be considered as creating a solution to a problem in hand with available capabilities. The main difference between Software analysis and design is that the output of a software analysis consist of smaller problems to solve. Also, the analysis should not be very different even if it is designed by different team members or groups. The design focuses on the capabilities, and there can be multiple designs for the same problem depending on the environment that solution will be hosted. They can be operations systems, webpages, mobile or even the new cloud computing paradigm. Sometimes the design depends on the environment that it was developed for, whether it is created from reliable frameworks or implemented with suitable design patterns. www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 8
www.Vidyarthiplus.com
External requirements
1 Clarify Requirements nature of specification requirements
2 Analyse needs Functional and build ‘black specification box’ model of problem
Functional specification 3 Postulate a ‘white box’ design List of mismatches solution 4 Validate solution (including use of prototypes)
White box model
5 Design plan Implementation of the design plan using a suitable form of software
Figure 1.3 A model of the design process.
n postulate a solution; n build a model of the solution; n evaluate the model against the original requirement; n elaborate the model to produce a detailed specification of the solution.
www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 16
www.Vidyarthiplus.com
A software designer may need to acquire some degree of ‘domain knowledge’ as a routine part of the input needed for undertaking any particular design task. Some of this may be obtained from the specification (which may well run to hundreds of pages), but by no means all of the necessary knowledge is likely to be available in this way. So, as shown in Figure 1.7, the software designer may need to be responsive to many channels of communi-cation. This is an aspect that will be addressed further in Chapter 3, while some of the ways of transferring the domain knowledge will also be examined more fully in later chapters.
To continue with the needs of software development: it is clear from the above that the main task of the design phase is to produce the plans necessary for software production to proceed. The form and extent of the plans will be determined by the design practices and means of implementation chosen, as well as by the size of the
Requirements specification
Plans for realization of the design Constraints
Domain knowledge
Figure 1.7 The designer’s channels of communication.
www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 17
www.Vidyarthiplus.com
system being developed. Clearly, in a large project employing many programmers the design plans will need to capture a much wider range of factors than will be needed by the one-person project, where the designer may well be the programmer too. Typically, such plans will be concerned with describing:
n the static structure of the system, including any subprograms to be used and their hierarchy; n any data objects to be used in the system; n the algorithms to be used; n the packaging of the system, in terms of how components are grouped in compi- lation units (assuming that implementation will use a conventional imperative programming language); n interactions between components, including the form these should take, and the nature of any causal links.
These are all concerned with specifying the form of the design product itself. But as was observed above, the overall design task may also involve producing process- oriented plans too, concerned with such matters as the preferred order of development for subprograms/modules and so on, and the strategy for their eventual integration into the complete system. (These are rather like the assembly directions that are needed for construction of the garden shed.) However, for the moment we will chiefly concern ourselves with the needs of the design product. As in many more ‘classical’ forms of engineering, software designers produce plans that specify how the final product is to be assembled in terms of the items listed above. This usually requires the use of a variety of forms of representation, since each of these provides a different ‘view’ of a system. In a way, the use of these multiple views corres- ponds to the use of plan, elevation and end views in technical drawing, as well as to the cross-sectional forms used to indicate assembly details. (The concept of tolerance is perhaps lacking though, since software components generally have to ‘fit’ rather precisely.) For software systems, however, a further degree of complexity has to be consid- ered. For designing software consists of designing a process; and so it becomes neces- sary to model and describe its behaviour as well as its structure, and also the functions that it will perform. So the designer’s model will ideally include descriptions that also encompass these aspects of the eventual system. To meet these needs, the designer will usually make use of a number of different forms of design representation to help with constructing the model, each represen- tation providing a different viewpoint on the form of a design, as shown in Figure 1.8. The more complex the system, the more we need a full set of viewpoints to understand its behaviour, and to provide a specification that is sufficiently complete for it to be used as an aid in the construction of the system. We will return later to consider more fully the ways in which the dynamic nature of a software system influences (and complicates) the process of design; for the moment we will continue to focus our attention upon the nature of the design process in general.
www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 18
www.Vidyarthiplus.com
18
Figure 1.8 Examples of design viewpoints.
www.Vidyarthiplus.com www.Vidyarthiplus.com
principles for software design
• The design process should not suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job. • The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model. • The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist. • The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain. • The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components. • The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achieve this principle. • The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well- designed software should never “bomb.” It should be designed to accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner. • Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code. The only design decisions made at the
www.Vidyarthiplus.com www.Vidyarthiplus.com
coding level address the small implementation details that enable the procedural design to be coded. • The design should be assessed for quality as it is being created, not after the fact. A variety of design concepts and design measures are available to assist the designer in assessing quality. • The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model.
Design Concepts
The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are:
1. Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose. 2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts. 3. Modularity - Software architecture is divided into components called modules. 4. Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. A good software architecture will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost. 5. Control Hierarchy - A program structure that represents the organization of a program component and implies a hierarchy of control. 6. Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure. 7. Data Structure - It is a representation of the logical relationship among individual elements of data. 8. Software Procedure - It focuses on the processing of each modules individually
www.Vidyarthiplus.com www.Vidyarthiplus.com
9. Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information
Design considerations
There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects are:
• Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself. • Extensibility - New capabilities can be added to the software without major changes to the underlying architecture. • Fault-tolerance - The software is resistant to and able to recover from component failure. • Maintainability - A measure of how easily bug fixes or functional modifications can be accomplished. High maintainability can be the product of modularity and extensibility. • Modularity - the resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project. • Reliability - The software is able to perform a required function under stated conditions for a specified period of time. • Reusability - the software is able to add further features and modification with slight or no modification. • Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions. • Security - The software is able to withstand hostile acts and influences. • Usability - The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users. • Performance - The software performs its tasks within a user-acceptable time. The software does not consume too much memory. • Portability - The usability of the same software in different environments. • Scalability - The software adapts well to increasing data or number of users.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Overview
A software design creates meaningful engineering representation (or model) of some software product that is to be built. Designers must strive to acquire a repertoire of alternative design information and learn to choose the elements that best match the analysis model. A design model can be traced to the customer's requirements and can be assessed for quality against predefined criteria. During the design process the software requirements model (data, function, behavior) is transformed into design models that describe the details of the data structures, system architecture, interfaces, and components necessary to implement the system. Each design product is reviewed for quality (i.e. identify and correct errors, inconsistencies, or omissions, whether better alternatives exist, and whether the design model can be implemented within the project constraints) before moving to the next phase of software development.
Software Design
• Encompasses the set of principles, concepts, and practices that lead to the development of a high quality system or product • Design principles establish and overriding philosophy that guides the designer as the work is performed • Design concepts must be understood before the mechanics of design practice are applied • Goal of design engineering is to produce a model or representation that is bug free (firmness), suitable for its intended uses (commodity), and pleasurable to use (delight) • Software design practices change continuously as new methods, better analysis, and broader understanding evolve
Software Engineering Design
• Data/Class design - created by transforming the analysis model class-based elements (class diagrams, analysis packages, CRC models, collaboration diagrams) into classes and data structures required to implement the software • Architectural design - defines the relationships among the major structural elements of the software, it is derived from the class-based elements and flow-oriented elements (data flow diagrams, control flow diagrams, processing narratives) of the analysis model • Interface design - describes how the software elements, hardware elements, and end-users communicate with one another, it is derived from the analysis model scenario-based elements (use-case text, use-case diagrams, activity diagrams, swim lane diagrams), flow-oriented elements, and behavioral elements (state diagrams, sequence diagrams)
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Component-level design - created by transforming the structural elements defined by the software architecture into a procedural description of the software components using information obtained from the analysis model class-based elements, flow-oriented elements, and behavioral elements
Software Quality Attributes
A good design must • implement all explicit requirements from the analysis model and accommodate all implicit requirements desired by the user • be readable and understandable guide for those who generate code, test components, or support the system • provide a complete picture (data, function, behavior) if the software from an implementation perspective
Design Quality Guidelines
A design should • exhibit an architecture that o has been created using recognizable architectural styles or patterns o is composed of components that exhibit good design characteristics o can be implemented in an evolutionary manner • be modular • contain distinct representations of data, architecture, interfaces, and components (modules) • lead to data structures that are appropriate for the objects to be implemented and be drawn from recognizable design patterns • lead to components that exhibit independent functional characteristics • lead to interfaces that reduce the complexity of connections between modules and with the external environment • be derived using a repeatable method that is driven by information obtained during software requirements analysis • be represented using a notation that effectively communicates its meaning
FURPS Quality Factors
• Functionality – feature set and program capabilities • Usability – human factors (aesthetics, consistency, documentation) • Reliability – frequency and severity opf failure • Performance – processing speed, response time, throughput, efficiency • Supportability – maintainability (extensibility, adaptability, serviceability), testability, compatibility, configurability
www.Vidyarthiplus.com www.Vidyarthiplus.com
Generic Design Task Set
1. Examine information domain model and design appropriate data structures for data objects and their attributes 2. Select an architectural pattern appropriate to the software based on the analysis model 3. Partition the analysis model into design subsystems and allocate these subsystems within the architecture o Be certain each subsystem is functionally cohesive o Design subsystem interfaces o Allocate analysis class or functions to subsystems 4. Create a set of design classes o Translate analysis class into design class o Check each class against design criteria and consider inheritance issues o Define methods and messages for each design class o Evaluate and select design patterns for each design class or subsystem after considering alternatives o Revise design classes and revise as needed 5. Design any interface required with external systems or devices 6. Design user interface o Review task analyses o Specify action sequences based on user scenarios o Define interface objects and control mechanisms o Review interface design and revise as needed 7. Conduct component level design o Specify algorithms at low level of detail o Refine interface of each component o Define component level data structures o Review components and correct all errors uncovered 8. Develop deployment model
Important Design Questions
• What criteria can be used to partition software into individual components? • How is function or data structure detail separated from conceptual representation of the software? • What uniform criteria define the technical quality of a software design?
Design Concepts
• Abstraction – allows designers to focus on solving a problem without being concerned about irrelevant lower level details (procedural abstraction - named sequence of events and data abstraction – named collection of data objects)
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Software Architecture – overall structure of the software components and the ways in which that structure provides conceptual integrity for a system o Structural models – architecture as organized collection of components o Framework models – attempt to identify repeatable architectural patterns o Dynamic models – indicate how program structure changes as a function of external events o Process models – focus on the design of the business or technical process that system must accommodate o Functional models – used to represent system functional hierarchy • Design Patterns – description of a design structure that solves a particular design problem within a specific context and its impact when applied • Separation of concerns – any complex problem is solvable by subdividing it into pieces that can be solved independently • Modularity - the degree to which software can be understood by examining its components independently of one another • Information Hiding – information (data and procedure) contained within a module is inaccessible to modules that have no need for such information • Functional Independence – achieved by developing modules with single- minded purpose and an aversion to excessive interaction with other models o Cohesion - qualitative indication of the degree to which a module focuses on just one thing o Coupling - qualitative indication of the degree to which a module is connected to other modules and to the outside world • Refinement – process of elaboration where the designer provides successively more detail for each design component • Aspects – a representation of a cross-cutting concern that must be accommodated as refinement and modularization occur • Refactoring – process of changing a software system in such a way internal structure is improved without altering the external behavior or code design
Design Classes
• Refine analysis classes by providing detail needed to implement the classes and implement a software infrastructure the support the business solution • Five types of design classes can be developed to support the design architecture o user interface classes – abstractions needed for human-computer interaction (HCI) o business domain classes – refinements of earlier analysis classes o process classes – implement lower level business abstractions o persistent classes – data stores that persist beyond software execution o System classes – implement software management and control functions
www.Vidyarthiplus.com www.Vidyarthiplus.com
Design Class Characteristics
• Complete (includes all necessary attributes and methods) and sufficient (contains only those methods needed to achieve class intent) • Primitiveness – each class method focuses on providing one service • High cohesion – small, focused, single-minded classes • Low coupling – class collaboration kept to minimum
Design Model
• Process dimension – indicates design model evolution as design tasks are executed during software process o Architecture elements o Interface elements o Component-level elements o Deployment-level elements • Abstraction dimension – represents level of detail as each analysis model element is transformed into a design equivalent and refined o High level (analysis model elements) o Low level (design model elements) • Many UML diagrams used in the design model are refinements of diagrams created in the analysis model (more implementation specific detail is provided) • Design patterns may be applied at any point in the design process
Data Design
• High level model depicting user’s view of the data or information • Design of data structures and operators is essential to creation of high-quality applications • Translation of data model into database is critical to achieving system business objectives • Reorganizing databases into a data warehouse enables data mining or knowledge discovery that can impact success of business itself
Architectural Design
• Provides an overall view of the software product • Derived from o Information about the application domain relevant to software o Relationships and collaborations among specific analysis model elements o Availability of architectural patterns and styles
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Usually depicted as a set of interconnected systems that are often derived from the analysis packages with in the requirements model
Interface Design
• Interface is a set of operations that describes the externally observable behavior of a class and provides access to its public operations • Important elements o User interface (UI) o External interfaces to other systems o Internal interfaces between various design components • Modeled using UML communication diagrams (called collaboration diagrams in UML 1.x)
Component-Level Design
• Describes the internal detail of each software component • Defines o Data structures for all local data objects o Algorithmic detail for all component processing functions o Interface that allows access to all component operations • Modeled using UML component diagrams, UML activity diagrams, pseudocode (PDL), and sometimes flowcharts
Deployment-Level Design
• Indicates how software functionality and subsystems will be allocated within the physical computing environment • Modeled using UML deployment diagrams • Descriptor form deployment diagrams show the computing environment but does not indicate configuration details • Instance form deployment diagrams identifying specific named hardware configurations are developed during the latter stages of design
www.Vidyarthiplus.com SDC02 9/18/07 10:36 AM Page 25
www.Vidyarthiplus.com
25 Design process
The Software Design Process
2.1 What is software? 2.4 Constraints upon the design 2.2 Building models process and product 2.3 Transferring design knowledge 2.5 Recording design decisions 2.6 Designing with others
This chapter begins by reviewing some ideas about what might constitute ‘software’ and then takes the ideas about design that were introduced in Chapter 1 and considers how they can be interpreted for the problem of designing software. It examines some of the conclusions that have been drawn from observation of software designers at work, and uses these to identify the forms of support that are required to help with transferring design experience and knowledge. Some of the other factors influencing software design are surveyed, and their influence upon the evolution of software design practices is considered.
www.Vidyarthiplus.com software have helped with classifying architectural style www.Vidyarthiplus.com www.Vidyarthiplus.com The one factor that these developments have particularly highlighted, and the one The one factor that these developments have particularly highlighted, and In some ways, the effect of these developments upon design thinking has probably In some ways, the effect of these developments This process of variation in the forms of implementation has continued apace, This process of variation in the forms By the 1970s the idea that computing tasks could be distributed across multiple By the 1970s the idea that computing When people first began to develop computer-based applications that were recog- began to develop computer-based applications When people first that existing design practices (including many described in this book) have been least that existing design practices (including many described in this book) have While successful in addressing, is the continuing demand for faster delivery of systems. been less than might be expected (and arguably, somewhat less than might be desir- been less than might be expected (and arguably, somewhat less than might able). At one level, such concepts as a matter of the wealth of implementation forms. However, in some ways this is more process having the question of implementation form considered earlier in the design rather than being a radical change in the nature of the design process itself. parameters. Ideas about distribution have further extended the potential for employ- parameters. Ideas about distribution final structure of a system, as well as extending ing run-time binding to determine the as ‘client–server’ are now widespread, if not par- ideas about distribution (terms such time, the addition of ‘scripting’ forms to static ticularly well-defined). At the same and XML has further extended our ideas about description notations such as HTML the forms that ‘software’ might take. one, the designers now had to incorporate additional factors into their decision- one, the designers now had to incorporate data were to be partitioned or shared between making, such as how functionality and mechanisms to employ, and the likely perform- machines, the form of communication ance effects of these choices. of the Internet has added many new and in the 1990s in particular, the development resulting binary code, the close link between these generally rendered the distinction resulting binary code, the close link unimportant. further possibility of changing the links between computers had been added, with the could largely be considered to be a variation these at run-time. While this development of course influence the thinking of the designers in the details of implementation, it did system was to be implemented as a distributed of such systems. Where the eventual table binary code’ that was intended for execution on a single machine. Indeed, this that was intended for execution on table binary code’ about software design. The implicit in all early thinking assumption was effectively was compiled (which can be was largely fixed when the code structure of such systems of the designer(s) were directed binding’) and so the ideas described as ‘compile-time code. Indeed, while the term a single monolithic unit of binary towards producing times to describe both ‘source code’ and the ‘software’ might be used at different begun the previous chapter by asking the question ‘what is design?’, it is appropriate chapter by asking the question ‘what begun the previous is software?’. by considering the question ‘what to begin this chapter this question was one that enough to merit an explicit design phase, nized as being large at least, software was been asked by anyone. Until the mid-1970s was unlikely to have with generating ‘execu- all of the forms that were concerned considered to encompass 2.1software? is What and process of design of the general the characteristics chapter we examined In the first this a creative task. In it as being design that characterize those features of identified the design of the ways in which with examining will be concerned chapter we the task of designing any ways in which and identifying general pattern, fits into this of artifact. So having any other forms that of designing might differ from software
26 The software design process SDC02 9/18/07 10:36 AM Page 26 AM Page 10:36 9/18/07 SDC02 27 Building models , et al. they are to do they are how www.Vidyarthiplus.com www.Vidyarthiplus.com do, than develop solutions that describe develop solutions do, than . This is seen as being an essential property of software, in which no . Software, being ‘pliable’, is expected to conform to the standards should However, since the main theme of this book is one of ‘software design’, for much However, since the main theme of this One way of achieving faster delivery of systems to their users is to employ a higher faster delivery of systems to their One way of achieving imposed by other components, such as hardware, or by external bodies, or by exist- imposed by other components, such as hardware, or by external bodies, or ing software. Complexity execution. two parts are alike and a system may possess very many states during than This complexity is also arbitrary, being dependent upon the designer rather the problem. Conformity n n and size, software development techniques seem to have inched along in a series of rel- and size, software development techniques are cited for this, and in his widely acclaimed atively small steps. Various reasons accidents of software engineering’, Fred Brooks paper ‘No silver bullet: Essence and causes of this relatively slow progress (Brooks, has pointed out some of the principal following properties of software as major factors 1987). In particular, Brooks cites the affecting its development. 2.2 models Building systems have long been recognized. The difficulties involved in creating software-based such as hardware design and production has While apparently-related technology in performance, and similarly reducing price raced along gaining orders of magnitude of the time we take a very general and abstract view of what might constitute ‘soft- of the time we take a very general and to the effects of choosing specific forms of imple- ware’, although we do pay attention affect design decisions. Indeed, our thesis here mentation where this may significantly argued that whatever the form(s) of software that is one of unification, in that it can be design should still reflect a set of consistent con- are used to implement a system, its cepts and principles. to writing them in ‘high-order languages’. This freed them from dependence on one ‘high-order languages’. This freed to writing them in faster production of code. An type of computer and also enabled particular make and design stage is to place greater the potential for a similar step at the approach offering rather than designing existing ‘objects’ and ‘components’ emphasis on manipulating chapters. be discussing these ideas in our later new ones. We will is unlikely to be achieved without expenditure of considerable effort. Whether this will without expenditure of considerable is unlikely to be achieved open question (Brereton many ‘web-based’ systems is an prove achievable for 1998). In the 1970s such a step in terms of what we think of as ‘software’. level of abstraction assembler code from writing programs using machine-specific was achieved by moving this has always been a problem, the concept of ‘internet time’ is one which probably which is one time’ of ‘internet the concept problem, been a always this has To a considerable process. design a reflective need for with the strongly most conflicts our ideas about adapt and extend can much more quickly arises because we extent this what systems a its structure, due care to preserve design is that, given of good it. One characteristic as characteristics harming such other modified without be extended and system can that is one However, this characteristic and consistency. time, dependability response SDC02 9/18/07 10:36 AM Page 27 AM Page 10:36 9/18/07 SDC02 . In later chapters we will scale link that can provide an easily link that of a system within a given context or of the designer’s intentions. Models of of the designer’s intentions. Models visual behaviour (reduced to only the properties of direct interest), (reduced to only the properties of direct representation abstract www.Vidyarthiplus.com www.Vidyarthiplus.com . Software suffers constant need for change, partly because of the because partly for change, need constant suffers . Software . Because software is ‘invisible’, any forms of representation that are of representation any forms software is ‘invisible’, . Because (Larousse) Constructing a model for a proposed solution allows the designer to explore the Constructing a model for a proposed solution allows the designer to explore In developing software, we need models that are often less precise than the math- In developing software, we need models The idea of using some form of ‘model’ to help with exploring design ideas is some form of ‘model’ to help with The idea of using This not only constrains our ability to conceptualize the characteristics of software, our ability to conceptualize the This not only constrains its development. among those involved with it also hinders communication Changeability costing them). for techniques poor (and relatively changes of making ease apparent Invisibility any form of it will lack used to describe for example, and the system – unlike, the representation between grasped relationship of the building. the visible features be easily linked to plan which can a building ‘A three-dimensional representation, usually in miniature, of a thing to be con- ‘A three-dimensional representation, structed.’ the process of software design. In this section we will try to identify some of the main the process of software design. In this section we will try to identify some features and characteristics of the models that are used in software design. be examining some of the forms that such a model can take. structure. potential limitations of the solution as well as to assess its behaviour and required the However, the examples used in the first two case studies (Chapter 1) the ‘solution designer to construct only relatively simple models in order to explore assist with space’. Simple, that is, as compared with the models that are needed to designer. more abstract than those used by the ship-builder, ematician’s models, while also being in the physical sense! However, their role and that are certainly not three-dimensional is still to provide some form of software will usually be of how we handle which also helps to address the issues may be concerned with more than just construction. An example of such an abstract may be concerned with more than just which may be employed for such tasks as pre- form is that of the mathematical model, of a metal bridge; describing the life expectancies dicting the stress in the components traffic flow at road junctions. Models of this of insurance policyholders; and describing type can also be used to predict the much more closely to the needs of the software scenario, a role which corresponds reads something like the following: and models may well be more abstract and However, this is a rather physical view, ter by considering the key design factor of model-building, used by a designer to posit the key design factor of model-building, ter by considering a solution. magnificent scale models shipbuilders constructed hardly new. The seventeenth-century also (equally important) as a as an aid to their own planning and of sailing ships, both shipyard workers who were to be tasked with means of conveying those plans to the is a model? A typical dictionary definition constructing the vessel. So what exactly For these reasons (and especially the last one), while the act of designing software (and especially the last one), while For these reasons design activity in Chapter 1, it general characteristics identified for usually shares the We therefore begin this chap- additional problems for the designer. incorporates many n n
28 The software design process SDC02 9/18/07 10:36 AM Page 28 AM Page 10:36 9/18/07 SDC02 29 Building models www.Vidyarthiplus.com www.Vidyarthiplus.com A general model of the software design process. A general model of the In practice, and especially when developing larger systems, the process of design is In practice, and especially when developing Figure 2.1 shows a (very general) ‘model’ of the software design process itself. The Figure 2.1 shows a (very general) ‘model’ strongly influenced by the eventual form that will be adopted for its solution. strongly influenced by the eventual form units (the ‘detailed’ or ‘phys- first phase are mapped on to technologically-based box into a white box. Where design and ical’ design), hence turning the black it is the output from this phase that implementation are separate responsibilities, provides the specifications for the programmers. ‘architectural’ or ‘logical’ design) in which only the external properties of the ‘architectural’ or ‘logical’ design) in black-box partitioning of the problem is model elements are included. This initial nature and form of the problem itself, and less therefore largely concerned with the Figure 2.1 design, rather than upon the exact forms that the models and transformations will take design, rather than upon the exact forms that the models and transformations for specific design strategies. Again, this is a rather idealistic description, but conceptually useful, even where it is Again, this is a rather idealistic description, but conceptually useful, even when not practical to keep the activities of the two phases separate (as, for example, we come to seeking to reuse existing components). So it is one that we will use when for the review different approaches to software design in the later chapters. However, during moment we will concentrate chiefly upon the general role of model-building 2. that were identified in the In the second phase, the abstract ‘chunks’ of the problem apt to be divided into two distinct phases, as illustrated in Figure 2.2. apt to be divided into two distinct phases, 1. model of a solution (the In the first phase, the designer develops a highly abstract input to this process is provided by the Requirements Specification documents, while input to this process is provided by consist of a set of detailed specifications that the outputs produced from it should components. (Of course, we know from our describe the form of the eventual program wicked problems that this is a highly idealized discussion of the characteristics of account!) SDC02 9/18/07 10:36 AM Page 29 AM Page 10:36 9/18/07 SDC02 www.Vidyarthiplus.com www.Vidyarthiplus.com The major phases of the software design process. The major phases of the software design The initial ‘architectural model’ that is used to describe the intended form that a The initial ‘architectural model’ that The use of abstract ‘mental models’ by the designer to simulate the dynamic The use of abstract ‘mental models’ by the designer to simulate the behaviour of the eventual system that will be derived from the design. a familiar problem; but taken from a familiar domain; and a problem that was unfamiliar in detail, senses. a problem that was unfamiliar in all n The study was limited in scope, in that they looked at only a small number of subjects, The study was limited in scope, in that they looked at only a small number for prac- and concentrated their study to a single specialized problem domain. Also, their tical reasons, the problems themselves were relatively small in scale. However, process. findings do seem to reflect more general experience with the software design Some key observations that were produced from this research included: posed: n n n system will take is generally highly abstract in its nature. The way that this is devel- system will take is generally highly was examined in an interesting study of the ways oped during the process of designing by Adelson and Soloway (1985). In their experi- that software designers work, made both experienced and inexperienced designers ments, they studied the ways in which models when they were faced with a range of set about the task of forming their were based upon situations where a designer was different problems. The experiments Figure 2.2
30 The software design process SDC02 9/18/07 10:36 AM Page 30 AM Page 10:36 9/18/07 SDC02 31 Building models , programming , rather than on design , 1988; Visser and Hoc, 1990). While this work con- , 1988; Visser and Hoc, 1990). While et al. www.Vidyarthiplus.com www.Vidyarthiplus.com The models formed during the early stages of design are mainly concerned with The models formed during the early stages of design are mainly concerned Returning to the large-scale issues of design (such as arise for the type of problem Returning to the large-scale issues of There have been relatively few empirical studies of software designers conducted There have been relatively few empirical by using a previously developed design object or structure. Where this occurs, developed design object or structure. by using a previously describing it in detail at a ‘label’ to identify the plan, rather than designers may use that point. aid to systematic expansion future (detailed) intentions, as an Making notes about of a design. Expanding the detail of a model in a systematic manner by keeping all elements of all elements keeping by manner in a systematic a model detail of the Expanding task aids the This then are developed. as they level of detail same at the the design of simulation. as possible when design as explicit affecting the to make any constraints The need an unfamiliar problem. handling can be solved part of a problem This arises when previous design plans. Reuse of that was given on page 5, based upon the quotation from the work of J. Christopher that was given on page 5, based upon the quotation from the work of J. with the idea Jones, we can see that this use of an initial abstract model corresponds system for different scenarios. In addition, the models can be used to aid a systematic system for different scenarios. In addition, the models can be used to aid of a detailed expansion of the initial ideas of the designer towards the production design description. since they assisting either the analysis or the specification of the problem (or with both, process are often entwined). If we return briefly to the more general view of the design that we term ‘programming in the large’), we will see when we come to examine dif- that we term ‘programming in the large’), many of these provide quite extensive forms of ferent software design methods that abstract models in order to explore ideas. The support for a designer in building initial as in the case of ‘systematic’ methods, or forms used for the models may be graphical, the more ‘formal’ methods. In each case, the use mathematically-based, in the case of the designer to predict the likely behaviour of a of an abstract model generally allows small’. For instance, many programmers probably perform simulations by executing small’. For instance, many programmers when coding conditional loop structures: mental models for sections of their programs that occur when the loop is first executed, and modelling the entry/exit conditions terminate in the intended manner. In that sense, checking to ensure that the loop will one, and it is clearly rather important at all the idea of simulation is a fairly familiar levels of abstraction. within a controlled experimental environment that have examined the activities within a controlled experimental viewpoint of the actions of the designer. How- involved in software design from the studies of design activity in more ‘normal’ ever, others have conducted some similar working situations (Curtis software centrated on studying the process of some of the observed techniques are also used many programmers will recognize that that they undertake when ‘programming in the for the more detailed design tasks The last point is less directly concerned with the manner in which a model is developed directly concerned with the manner The last point is less designer avoids the pitfall of the way in which an experienced and used, but it reflects the details of one aspect of a design in too much detail. (Fixing following one thread later constrain the early a stage may severely, and inappropriately, of a design at too for the other aspects.) designer’s choices n n n n SDC02 9/18/07 10:36 AM Page 31 AM Page 10:36 9/18/07 SDC02 , 1988). et al. , enabling them to map between problem www.Vidyarthiplus.com www.Vidyarthiplus.com design knowledge design , (1988), the exceptional designers were observed to possess three , (1988), the exceptional designers were et al. The characteristics of an exceptional designer. In Curtis Experimental study of software designers and their practices suggests that, as Experimental study of software designers So in many ways, the various approaches to supporting and structuring the soft- supporting and structuring approaches to ways, the various So in many Familiarity with the application domain ease. (A domain in this sense may be one structures and solution structures with systems, and so on.) such as data processing, real-time, telecommunication 1. might be expected, some people are better designers than others (Curtis might be expected, some people are great designers is very small, we need to seek However, since the number of truly skills to a wider group in as effective a manner ways of providing appropriate design as possible. in Figure 2.3, these are: significant characteristics. As illustrated Chapter 1 examined the nature of the general design process and showed that it is quite the nature of the general design process Chapter 1 examined act of designing is not based approach to problem-solving. The unlike the ‘scientific’ true solution to a problem, as aimed at identifying the one upon an analytic strategy, process, and certainly very laws. Instead, it is a highly creative determined by physical to any given problem. the identification of a single solution unlikely to lead to examine this issue of knowledge transfer more fully and identify some of the other of knowledge transfer more fully examine this issue involved in it. factors that may be 2.3 Transferring that a designer needs to ‘predict a future state’ and so needs to assume the outcome of the outcome to assume so needs state’ and a future ‘predict needs to a designer that process. that to begin in order process the design the concerned with this book are largely will examine in process that we ware design models. Indeed, and elaborating describing, constructing practices used for different as can be considered assess such models to develop and that is needed the knowledge we section, therefore, In the next designer’s portfolio. element in the an important Figure 2.3
32 The software design process SDC02 9/18/07 10:36 AM Page 32 AM Page 10:36 9/18/07 SDC02 33 Transferring design knowledge . This was . This is one that has offered a , to the extent that they could be found that they could , to the extent experienced, and have extensive domain know- experienced, and have extensive domain of further developments in the design. www.Vidyarthiplus.com www.Vidyarthiplus.com . The idea of design methods emerged in the 1970s in order to a decision, if the information required is not yet available at this design a decision, if the information required postpone Domain knowledge can be acquired partly through experience, and also, to some Domain knowledge can be acquired domain Design methods are not the only means of formalizing the transfer of Even if rigorous procedures for performing the transformations between the stages Even if rigorous procedures for performing Others too have identified the importance of the domain knowledge of the identified the importance of the domain Others too have are other factors to con- how successful designers work, there When we look at Skill in communicating technical vision to other project members project to other vision technical in communicating Skill often was work of the design much factor that a so significant to be observed with others. while interacting accomplished performance with project Identification taking on significant management responsibilities for ensuring technical progress. for ensuring technical responsibilities significant management taking on to to hand, and which can be used for defining to process information that is readily modules in anticipation level; or ledge to guide their actions. However, such techniques are clearly inadequate where ledge to guide their actions. However, the question of how are they to be acquired? these characteristics are lacking, leaving practices that may be related to a particular degree, through learning a set of design upon making decisions that are based upon the domain. Such practices place emphasis through the key characteristics of the domain. One way of learning such practices is use of design methods use do seem meet this need for knowledge transfer, and in some ways their forms and regard to be something that is peculiar to software development. We can, therefore, that will the purpose of a software design method as being to provide the framework enable a designer to develop and elaborate a design in a systematic manner. knowledge, and more recently the idea of the design pattern n n not unstructured; instead, it is more likely to Such opportunistic design activity is domain knowledge. One important consequence reflect the designer’s experience and support tools should not give them an inter- is that the developers of software design on the part of the designer. face form that impedes this behaviour there may still be benefits in seeking to codify of a designer’s model cannot be devised, designers can make use of opportunistic design strategies in some way. Experienced techniques precisely because they are 2. 3. Interestingly, though, the exceptional designers studied often did not possess particu- the exceptional designers studied Interestingly, though, skills. larly good programming Soloway, 1985), and clearly successful designs (Adelson and designer for producing in a particular problem come from the accumulation of experience this aspect can only such knowledge can be be, though, that the process of acquiring domain. It may well accelerated and improved. section. Visser and Hoc those that were outlined in the previous sider, apart from of software design term ‘opportunistic’ to describe observations (1990) have used the such as ‘top-down’ (systematic- designers aim to follow a strategy activity. Even where into ever smaller actions), they may deviate ally refining the description of the solution from this plan, either: SDC02 9/18/07 10:36 AM Page 33 AM Page 10:36 9/18/07 SDC02 , 1995). However, since the use of , 1995). However, et al. provides a set of descriptive forms that the designer can provides a set of descriptive forms that www.Vidyarthiplus.com www.Vidyarthiplus.com that can be used to provide guidelines on the ways in which the that can be used to provide guidelines is concerned with describing how the necessary transformations is concerned with describing how the heuristics The two major components of a software design method. The two major components representation part process part So representation forms generally reflect the properties of the objects in the design. So representation forms generally reflect the properties of the objects in the The representation part of a design method will usually include forms that can be The representation part of a design method For our purposes, a software design method can be considered as providing a a software design method can be For our purposes, ideas for its solution, and for describing the structural features of the solution to ideas for its solution, and for describing the eventual implementors. to be organized, as well as with any elabor- between the representation forms are ation of their detail that might be required. use for building both black box and white box models of the problem and their use for building both black box and A set of can be organized for specific classes of prob- activities defined in the process part experience of past use of the method within a lem. These are generally based upon form of structure. particular domain or for a particular properties such as the calling hierarchy, complex data structures, number of parameters properties such as the calling hierarchy, complex data structures, number will be and so on. On the other hand, the forms that are used for problem modelling which showed how key joints were to be assembled. In describing software, one will which showed how key joints were to be assembled. In describing software, sub- typically use detailed design forms that describe the structures of the program that units, the relationships that these have with one another, and the relationships they have with the other entities in the system. concrete Those forms that describe the detailed design may be concerned with fairly While these do not necessarily provide the domain knowledge that a designer needs, While these do not necessarily provide knowledge. they may well aid in developing this as forms that reflect the significant structures used for modelling the problem, as well example of the latter form: in describing a garden of the implementation media. As an described its plan, elevation and end view, and shed, one would use drawings that A further component is provided in most design methods: A further component is provided in n 2. The returning to the concept of the pattern at a later point. returning to the concept (shown schematically in that consists of two major components supportive framework Figure 2.4). 1. The less ‘procedural’ mechanism for this (Gamma less ‘procedural’ mechanism domain and hence in thinking deeply engrained in the software design methods is role in knowledge transfer, we will focus here upon their about software design, Figure 2.4
34 The software design process SDC02 9/18/07 10:36 AM Page 34 AM Page 10:36 9/18/07 SDC02 35 Transferring design knowledge , we will design pattern about how such problems are best step, in which a change of viewpoint that is used to step, in which a change of viewpoint www.Vidyarthiplus.com www.Vidyarthiplus.com , sometimes termed the ‘Aha!’ response. This is a skill in which , sometimes termed the ‘Aha!’ response. development of procedural knowledge problem restructuring recognition step Akin (1990) has suggested that there are three ‘classic’ conditions that are Akin (1990) has suggested that there The process part of design is rather more difficult to quantify and classify. Its to quantify is rather more difficult part of design The process (Again, Akin notes that there are many fields of human endeavour where this can (Again, Akin notes that there are many fields of human endeavour where be seen to apply.) example, in solving a given problem, the designer may decide to store the data in example, in solving a given problem, the designer may decide to store the an array. This choice may subsequently require a highly complex set of algorithms, array will and the designer may later realize that using a linked list in place of the result in much simpler algorithms. domain. solved, allowing the designer to perform many creative acts within a the designer recognizes a solution that has been there all along. (This form of cre- the designer recognizes a solution that scientific progress than of design progress ative act is perhaps more typical of the concept of the although when we later come to study depend upon a form of recognition step.) see that effective use of patterns does to a major breakthrough in solving it. As an describe or model a problem leads identification of particular constraints to be considered; identification of particular constraints verification/validation operations. identification of the design actions to be performed; identification of the forms; use of the representation transformations between representations; procedures for making quality measures to aid in making choices; 3. The 2. The designer to identify the choices available, and to evaluate these in terms of their likely designer to identify the choices available, consequences. These are: observed in creative acts such as design. 1. The n n guidance for the designer, rather than detailed Most design methods provide strategic this is driven by the problem-oriented nature of solutions to issues. To a large extent has to make: the role of the method is to help the many of the choices that a designer n n n n heuristics (‘it worked well when we did it this way before’). Most likely, it will reflect well when we did it this way before’). heuristics (‘it worked theoretical underpinnings these. In general there is a lack of strong a mix of all three of principles may themselves be methods, and even the underlying for existing design some of the expectations in nature. However, we can still identify relatively empirical which will include providing the process part of a design method, that we have from for the following tasks: some degree of guidance concerned with more abstract properties of the problem objects and any relationships and objects of the problem properties more abstract with concerned abstract relatively upon be based will usually model these. This between may exist that pro- comes closest to flow, and as such, and information such as operations concepts by placing emphasis by a designer element needed ‘domain knowledge’ viding the significance. to be of the greatest are considered domain features that upon the ‘principles’, or from from specific fairly general theory, may be derived from structure SDC02 9/18/07 10:36 AM Page 35 AM Page 10:36 9/18/07 SDC02 , 1984; Friel and Budgen, 1997). et al. , which may involve a change of representation ) of structures, in which the input and output forms ) of structures, in which the input and www.Vidyarthiplus.com www.Vidyarthiplus.com elaboration that, again, can have any of these forms; that may be described by using a suitable ‘representation’ (which that may be described by using a suitable (or through which the designer adds information to the model. through which the designer adds information Transformation model of design activity. Transformation model transformation of viewpoint refinement input model output model The view of design as being a series of transformations is one that has been The view of design as being a series of transformations is one that If we explore further the transformation steps themselves, we find that for each If we explore further the transformation of the model are the same, but extra detail is added; of the model are the same, but extra the of the representation form. form or introduce a different interpretation design inputs the an may be graphical, textual or mathematical); an As a general model it provides a useful summary of design method structuring, and it As a general model it provides a useful summary of design method structuring, methods. will be used for this purpose in the chapters that describe specific design add both decisions and a change of the structure of the design model. In the former add both decisions and a change of the structure of the design model. space’ by case, the designer is chiefly concerned with reducing the eventual ‘solution be adding making additional choices and decisions; whereas in the latter he or she may information about new relationships between design objects. explored and used in a number of ways (Lehman n involve refinement are apt to preserve the repres- In general, the transformations that while those that involve a change of viewpoint entation form while adding more detail; n forms of design transformation, which In addition, we can identify two principal respectively involve: n step we can identify a general structure of the form shown in Figure 2.5. Each trans- step we can identify a general structure formation involves: n n A major component of the process part of a design method is the structuring of the of the process part of a design method A major component in the ‘process diagram’ used The sequence that is expressed design transformations. omits any detail about the iter- course, still a fairly abstract one, and in Figure 2.2 is, of evaluates the design options. occur as a designer explores and ations that will normally since the nature of these is too of the heuristics is also omitted, Any ‘formal’ inclusion strongly method-specific. Figure 2.5
36 The software design process SDC02 9/18/07 10:36 AM Page 36 AM Page 10:36 9/18/07 SDC02 37 Constraints upon the design process and product that particle-wave design pattern (Shaw and Garlan, 1996) (Shaw and Garlan, software architecture , 1995) has focused upon categorizing solution , 1995) has focused et al. www.Vidyarthiplus.com www.Vidyarthiplus.com exhibited by light, in which it can have the characteristics of one form or the other in any given situation, Similarly, for the case of software design, we can readily identify many of the con- Similarly, for the case of software design, We will return to look at both of these approaches in later chapters. In many We will return to look at both of Of course, as always occurs when considering design issues, there are trade-offs occurs when considering design Of course, as always As indicated earlier, design methods have formed part of the software designer’s software part of the formed have methods design earlier, As indicated reasons, two as well as for other this problem, the need to address Partly through duality but not both. senses, their key contribution to the task of transferring design and domain knowledge senses, their key contribution to the task are complementary to those employed in design is through providing strategies that so often occurs in software development, finding methods. Unfortunately though, as approaches is apt to prove elusive.* ways to combine the strengths of different involved in their application. While both of these approaches offer much better scope While both of these approaches involved in their application. design methods do, the lack of ideas than ‘traditional’ software for reusing successful to the novice and, in the can make them less readily accessible a procedural element well the concept will scale up there are questions about how case of design patterns, in a given context?). are likely to be both useful and accessible (how many patterns was mentioned earlier (Gamma was mentioned earlier be reused for different problems. structures that can straints imposed upon the form of the product. Some may be determined by the even- straints imposed upon the form of the product. Some may be determined of the user tual run-time environment (organization of file structures; the ‘look and feel’ required interface), while others may relate to the need to conform to the conventions between by a chosen architectural style (JavaBeans; forms of remote access; choice * that resemble the physicists’ dilemma with the Software often seems to possess characteristics were concerned both with functional issues (blocking power outlets or windows) and were concerned both with functional colour, or putting a bed in the dining room etc.). with aesthetic ones (clashes of style or the form of the solution (or product in These considerations largely act to constrain garden sheds, the main constraints were again this case). For the example of designing driven by the need to provide a way of con- on the form of the product, and were units. structing sheds from easily prefabricated In practice, there are very few opportunities to design a system with a totally free hand, In practice, there are very few opportunities a particular context, and this will provide since each design task takes place within of the design itself and possibly on the way that particular constraints upon the form this in the case studies of developing designs for it is produced. We have already seen In the example of moving house, the constraints moving house and for a garden shed. 2.4 and product process upon the design Constraints developed in the 1990s. The concept of developed in the 1990s. procedural approach to think- as taking a more structural and less can be considered idea of the can be developed. Similarly, the ing about how a design support base since the 1970s. However, in providing this support, their form and their form support, this in providing However, 1970s. since the base support 1999) and there creativity (Budgen, influence upon also be a constraining nature can to support, that they are ill-equipped design behaviour of ‘conventional’ are aspects used successfully. have previously been that the reuse of part-solutions most notably knowledge were of design and domain with the transfer to assisting other approaches SDC02 9/18/07 10:36 AM Page 37 AM Page 10:36 9/18/07 SDC02 , which can design reviews www.Vidyarthiplus.com www.Vidyarthiplus.com appear here), although this will not necessarily be true for those that appear here), although this will not necessarily , Modula-2, Java and scripting languages such as Javascript etc.) have and scripting languages such as Javascript , Modula-2, Java should ++ , 1995) as well as upon the task of allocating functionality between components. functionality between task of allocating well as upon the , 1995) as Many constraints will be identified in the initial specification documents (or at Many constraints will be identified Constraints on the process of design are more difficult to identify. They may be Constraints on the process of design can be considered as forming a set of bounds Whatever form they take, constraints The imperative forms of programming language (COBOL, ALGOL, FORTRAN, of programming language (COBOL, The imperative forms Perhaps one of the most important constraints on the design task and the form task and the form on the design constraints of the most important Perhaps one The need to record the decisions of the designer (or, for larger projects, of the design The need to record the decisions of the designer (or, for larger projects, more so from team) is important, from the viewpoint of the design task itself, and even identify and track constraints is through the use of regular be given the role of ensuring that an audit trail is maintained. 2.5 decisions design Recording limit the overall solution space by limiting the range of choices available to the limit the overall solution space by course, that inconsistencies in specification may designer. (There is also the risk, of solution!) Some constraints are problem-specific actually make it impossible to find a should be assumed for a new application), while (such as the level of user skills that as architectural style). While problem-specific others are more solution-specific (such into any formal design process (such as a constraints cannot readily be incorporated need to be considered at every step. One way to design method), their influence does upon the ‘solution space’. Even if the process of design will not necessarily converge upon the ‘solution space’. Even if the the effects of the constraints may be to limit upon one solution for a given problem, will be acceptable in particular circumstances. the amount of possible divergence that least, they Whatever their source, constraints effectively are related to any expectations of reuse. concerned with designer skills and knowledge (experience with a particular method), concerned with designer skills and knowledge ‘architectural style’ of design, in order to aid or with a need to conform to a particular constraint upon the product leads to a constraint future maintenance. In some cases, a form needs to be consistent with that gener- upon the process – where, say, the output strategy. ally produced from a particular design Ada, C, C the use of imperative lan- tool in software production. Indeed, remained the dominant currently available, and so implicit in almost all design methods guage constructs is use of imperative forms is not this book. However, the will be assumed throughout studied here are certainly process, and the principles of design essential to the design alone. not restricted to the imperative paradigm hardware and select the major software facilities (operating system, programming the major software facilities (operating hardware and select While enlightenment may be beginning on the design task itself. language) before even language is still more likely to the choice of the programming (very slowly) dawning, skills and knowledge than by external factors such as programmer be determined by problem itself. the features of the processes or objects; etc.). Where it is also intended that the eventual system will be con- will system that the eventual intended it is also Where etc.). or objects; processes constraints lead to further this may components, software existing by reusing structed may possess (Garlan the components styles that ‘acceptable’ architectural upon the et al. For many years of implementation. of the eventual form itself is that of the design the been to purchase projects has software development used by most the approach
38 The software design process SDC02 9/18/07 10:36 AM Page 38 AM Page 10:36 9/18/07 SDC02 39 Recording design decisions . Such an audit may . Such an design audit , 1987). Possessing some record of , 1987). Possessing et al. www.Vidyarthiplus.com www.Vidyarthiplus.com The principal benefits of such an approach are that new members of a design team The principal benefits of such an approach are that new members of a design An important issue in terms of recording decisions about a design has been raised An important issue in terms of recording The way in which design decisions are recorded is obviously somewhat dependent The way in which design decisions are So a major motivation for recording the reasoning behind any design decisions is one So a major motivation for recording the methods generally provide good forms of Unfortunately, while software design There is an even stronger need on the part of the system maintenance task (which need on the part of the system There is an even stronger Beginning with the original task of design, the recording of rationale is likely to be recording of rationale task of design, the with the original Beginning the eventual task of maintaining the system will also be made easier. Parnas and the eventual task of maintaining the system will also be made easier. proof, the Clements observe that even for a scientific document such as a mathematical documentation should be written as though the ‘ideal’ design process was the one that documentation should be written as though the ‘ideal’ design process was process (as was followed. Indeed, they argue that since design will never be a rational documen- we have been observing throughout this and the preceding chapter), any tation produced will always need to ‘fake’ this appearance of rationality. and also that should be able to absorb knowledge about the project much more easily, modelling this process of design deliberation – the ‘Potts and Bruns model’ (Potts and modelling this process of design deliberation been demonstrated for the JSD method. As yet, Bruns, 1988; Lee, 1991) – and it has support that can be used for this task. though, there is little or no general tool have observed that, even if the design process by Parnas and Clements (1986). They not a rational one, the documentation that is actually used to produce a design is appear as though it were. In other words, the finally produced should still make it other notation, they are generally weaker on process matters, such as recording the other notation, they are generally weaker of decisions and their reasons can fairly reasons for the decision. While the recording it is relatively hard to enforce it unless there is easily be made a part of design practice, a strong quality control system in operation. work has been performed to look at ways of upon the design process adopted. Some complete history of the system design. stage and also much later, during maintenance. of quality control, both at the design we hope to fully understand a design, and this Only if we have a complete picture can good, reliable design. is an essential factor in producing a product issues, usually through diagrams or support for recording decisions about the reasons for the existing structure can help both with recreating this model and with existing structure can help both with the reasons for the for the change need to be of any changes. In turn, the reasons evaluating the effects in order to maintain a consistent and added to the records kept by the maintainers, ture the original models that were used by the designers of a system. Only when they that were used by the designers ture the original models decide how to implement their complete model can they reliably have a reasonably effective manner (Littman changes in the most consist of peer review of the designer’s ideas, or may be something more formal that is of the designer’s ideas, or may be consist of peer review if audits are held, they will be manager. Whatever the form, conducted by the project for decisions are recorded. and usefully performed if the reasons more systematically and designer effort). In around 50–80 per cent of programmer is thought to involve need to be able to recap- extend a design, the maintenance designers order to modify or the viewpoint of the maintenance team who may later need to extend and modify the and modify to extend later need may team who of the maintenance the viewpoint it is decisions, the actual record diligently may while designers Unfortunately, design. choice. (Experience the basis for the final that forms to record the rationale much rarer it engineering alone: to software that is confined this is not a problem suggests that practice too.) branches of engineering occur in many other seems to form of includes any if the design process encouraged SDC02 9/18/07 10:36 AM Page 39 AM Page 10:36 9/18/07 SDC02 operating system is prob- operating system is Linux . Such software is made freely available and is usu- . Such software is www.Vidyarthiplus.com www.Vidyarthiplus.com open source software Many of the very successful and ‘exciting’ software systems have been the work Many of the very successful and ‘exciting’ designing a system through the use of a team In the absence of any great designers, We will return to the issue of design documentation in later chapters. It is certainly We will return to the issue of design documentation Before concluding this section, we should also briefly refer to one of the more briefly refer to we should also this section, Before concluding how to integrate the individual contributions to the design, which may well involve how to integrate the individual contributions to the design, which may well a process of negotiation between the members of the team. how to split the design task among the team, and to determine the interfaces how to split the design task among the team, and to determine the between the parts; n brings two major additional issues that need to be handled within the chosen design brings two major additional issues that need to be handled within the chosen strategy. These are: n modules should be equal to the number of members of the design team!) modules should be equal to the number (1987) contrasts the ‘excitement’ of Unix, of one or a few ‘great designers’. Brooks systems with the ‘blandness’ of COBOL, PL/1, Pascal, Modula, SmallTalk and similar that support this point. (A more recent contrast MVS/370 and MS-DOS as examples might be Linux versus Windows XX!) of any scale, it is essential for any form of programming in the large, where a project of any scale, it is essential for any form than a single designer. Given the nature of the is likely to involve a design team rather that designing as a team adds further compli- design process, it is hardly surprising added constraints upon the process, and hence cations, many of them in the form of medium-sized systems it sometimes appears as upon the form of the product. (For of design that specified that the number of design though there were an invariant ‘law’ one where software’s characteristic of ‘invisibility’, and the complexity of its nature, one where software’s characteristic are made very evident! 2.6 others with Designing is important for software development tasks While the development of a sound design both version control and documentation are essential elements in managing the efforts and documentation are essential elements both version control at time of writing, there (Wu and Lin, 2001). Curiously though, of so many volunteers that are involved in developing study into how the processes has been little academic the more ‘traditional’ forms of differ from those employed in open source software in the preceding paragraphs. development described emergence of basis. While there are developers, contributed on a voluntary ally the work of many this type of software product, the many examples of for preparing this revised (and has been used as the platform ably the best known of such software is be returning to look at how the development edition). We will section we should note that chapter, but in the context of this organized in the next form published is rarely the form of the initial derivation, since, as understanding since, derivation, initial of the the form is rarely published form they proof, since simpler need the Readers be found. usually can simplifications grows, discovery. In the same the process of its the theorem, not in the truth of are interested member or the main- to the new team design that matters the structure of a way, it is developed. not the way it was tainer, and the 1990s, namely of the 1980s and developments social and technical interesting
40 The software design process SDC02 9/18/07 10:36 AM Page 40 AM Page 10:36 9/18/07 SDC02 41 Designing with others The Psychology ., 1988) et al (Curtis (Weinberg, 1971). In this he observed the effects of differ- (Weinberg, 1971). www.Vidyarthiplus.com www.Vidyarthiplus.com Bringing the elements of a design together, along with the accompanying negoti- with the accompanying design together, along the elements of a Bringing (and hence designing) is research studying how programming Some of the original by the exponents of approach was at one time advocated The more hierarchical act along such lines, perhaps because there In practice, few design teams seem to and model the psychological factors Researchers have also sought to understand the large impact that may be exerted by a small subset of the members of the team the large impact that may be exerted knowledge; who possess superior application domain within a company (and particularly the need the influence of organizational issues and the customer). to maintain a bridge between the developers the size of a team (there seem to be pointers that a size of 10–12the size of a team (there seem to be pointers members is prob- ably an upper limit for productive working); ‘Designers needed operational scenarios of system use to understand the appli- ‘Designers needed operational scenarios of system use to understand were too cation’s behaviour and its environment. Unfortunately, these scenarios generated seldom passed from the customer to the developer. Customers often them and many such scenarios in determining their requirements, but did not record abstracted them out of the requirements document.’ n n in that: This last point raises an important issue n design teams, This point is an interesting one, for it is relevant not only to the use of the full set but addresses a much wider organizational issue in itself. (Figure 2.6 shows The first of these problems is at least partly aided by the increasing trend towards towards trend increasing by the aided least partly is at problems first of these The it is the moment, For a later point. at be examined that will an issue designs, modular the of subdividing with the problem strategy does help to note that this sufficient ensure a fair balance is still necessary to team, although it among a design operations where appropriate. of effort, a process of negoti- issues. While and managerial again a mix of technical ations, is to reduce the integrity of and necessary, it should not be allowed ation may be right the overall design. classic book was described in Gerald Weinberg’s performed by teams of Computer Programming that worked as an ‘egoless’ set organization, ranging from groups ent forms of group take the lead for specific different members of the group might of peers (in which had a highly hierarchical form. tasks), to those that Set in the design context, school (Baker, 1972; Brooks, 1975). the ‘chief programmer’ in a highly centralized role, functions as a chief designer, acting the chief programmer performing functions that are solely intended to with the other members of the team usually drawn has been with the surgical team support his or her activity. The parallel – the question of the very different purpose of the latter. Members which rather begs themselves, such as librarian, administrator or of the team might have specialized roles back-up who acts as the technical deputy to the documentation expert, and there is a chief programmer. on the very exacting central role it demands. are few great designers who can take (Curtis et al., 1988; Curtis and Walz, that influence team behaviour in designing references include: 1990). The factors discussed in these SDC02 9/18/07 10:36 AM Page 41 AM Page 10:36 9/18/07 SDC02 , 1988.) We will return later to examine more recent , 1988.) We will return later to examine et al. www.Vidyarthiplus.com www.Vidyarthiplus.com ., (1988) ) Factors influencing the software design process. Factors influencing the et al For the present, however, the key issues of design team operation seem to lie more For the present, however, the key issues the need for domain knowledge on the part of the designer; the widening interpretation of what consists ‘software’; to con- the complexity of the model-building processes for software systems, with their need sider static forms as well as the dynamic behaviour of the eventual system; the influence of the invisible nature of software upon any attempts to describe it; ‘Programming in the large is, in part, a learning, negotiation, and communication ‘Programming in the large is, in part, process.’ Summary n n n n This chapter has enlarged upon the issues that were raised in Chapter 1 by considering how they This chapter has enlarged upon the issues design. Major points from this chapter are: apply to the particular domain of software (1990): has gone into technical research than into invest- Unfortunately, to date far more effort igating team and organizational factors. thinking about the roles of scenarios and ‘use cases’ in software development. thinking about the roles of scenarios in that of design technology. Certainly few, if in the domain of group psychology than methods offer any significant guidance on how any, of the more widely used design team as opposed to an individual, and it would they should be adapted for use by a avoid doing so. To quote from Curtis and Walz seem that they are probably correct to Figure 2.6 (After Curtis of factors identified in Curtis
42 The software design process SDC02 9/18/07 10:36 AM Page 42 AM Page 10:36 9/18/07 SDC02 43 Exercises www.Vidyarthiplus.com www.Vidyarthiplus.com how to go about recording the results of the design process, presenting an ideal view of the results of the design process, how to go about recording by ‘faking’ an ideal development process; design development and how this differs from indi- affect the operation of design teams, some of the factors that vidual design practices. how the observed practices of software designers relate to the model of the general design of the to the model relate designers of software practices observed how the design practices by use of opportunistic in particular, the was presented, and process that designers; the representation major components: and its three form of a design method, the general heuristics; part, and the part, the process n n n n SDC02 9/18/07 10:36 AM Page 43 AM Page 10:36 9/18/07 SDC02 www.Vidyarthiplus.com
Managing complexity
What is the main problem facing software development?
• insufficient analysis and poorly understood requirements • poorly documented requirements • poor communication, especially of requirements • poor estimates • unrealistic deadlines (often due to poor estimates) • inadequate testing (often due to unrealistic deadlines) • changing requirements • unmaintainable software (often due to frequently changing requirements)
If you look at all these answers you can see that the root cause is simply due to complexity. The complexity of the original problem makes it hard to understand and communicate to others, which has the knock-on effect of poor estimates, etc. Coping with change just magnifies the complexity.
The significant problem of unmaintainable software is I believe also due to complexity. This can, and often is, due to large amount of duplicate and even unnecessary code. However, the complexity may just be due to the design of the software, or simply that the design is not well understood - after all complexity is just a matter of understanding.
Coping with Complexity
So how do we cope with complexity? In brief, and in general, we use a fundamental principle that has been used for thousands of years - divide and conquer. An example of its importance is the division of labour, without which the rise of human civilisation would not have even been possible.
How can we use the divide and conquer principle in software development? You have probably already guessed that the answer is we already do so, in a myriad of ways. Thousands, if not millions, of people have been involved in creating all the things that go towards someone creating a piece of software - from the people who created the operatings system, compiler, run-time libraries etc, through to the hardware etc, all the way to your mum, who made the breakfast that keeps your neurons firing.
The principle of divide and conquer is also at the core of the actual design of software. In fact just about everything you have or will ever read about creating software is concerned with the best way to break down a problem into manageable sub- problems. This is also known as information hiding, modules, black box, separation of
www.Vidyarthiplus.com www.Vidyarthiplus.com
concerns, encapsulation, decoupling, cohesion, modularity, abstraction. Its also the primary concern of modular programming, orthogonality, abstract data types, component-based software engineering, and object-oriented programming. In a way it is even the basis of the most important paradigm in the history of programming, that of structured programming.
Of course, there are other ways to deal with complexity, but divide and conquer is by far the most important. Before I look at some others though, I need to back-track a bit to consider the nature of complexity.
I mentioned above that there are other ways to deal with complexity. They are
* simplification, or removing information superfluous to the problem * analogy, or finding a similar problem that is easier to conceptualize * symbols, since the brain is highly visually-oriented, things like diagrams and notations may assist understanding * commonality, or recognizing sub-problems that have the same solution
Software Design Complexity
The term complexity stands for state of events or things, which have multiple interconnected links and highly complicated structures. In software programming, as the design of software is realized, the number of elements and their interconnections gradually emerge to be huge, which becomes too difficult to understand at once.
Software design complexity is difficult to assess without using complexity metrics and measures. Let us see three important software complexity measures.
Halstead's Complexity Measures
In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software complexity. Halstead’s metrics depends upon the actual implementation of program and its measures, which are computed directly from the operators and operands from source code, in static manner. It allows to evaluate testing time, vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code.
According to Halstead, “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operands”. Halstead metrics think a program as sequence of operators and their associated operands.
He defines various indicators to check complexity of module.
www.Vidyarthiplus.com www.Vidyarthiplus.com
When we select source file to view its complexity details in Metric Viewer, the following result is seen in Metric Report:
Cyclomatic Complexity Measures
Every program encompasses statements to execute in order to perform some task and other decision-making statements that decide, what statements need to be executed. These decision-making constructs change the flow of the program.
If we compare two programs of same size, the one with more decision-making statements will be more complex as the control of program jumps frequently.
McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity of a given software. It is graph driven model that is based on decision-making constructs of program such as if-else, do-while, repeat-until, switch-case and goto statements.
Process to make flow control graph:
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Break program in smaller blocks, delimited by decision-making constructs. • Create nodes representing each of these nodes. • Connect nodes as follows: o If control can branch from block i to block j
Draw an arc
o From exit node to entry node
Draw an arc.
To calculate Cyclomatic complexity of a program module, we use the formula -
According to P. Jorgensen, Cyclomatic Complexity of a module should not exceed 10.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Function Point
It is widely used to measure the size of software. Function Point concentrates on functionality provided by the system. Features and functionality of the system are used to measure the software complexity.
Function point counts on five parameters, named as External Input, External Output, Logical Internal Files, External Interface Files, and External Inquiry. To consider the complexity of software each parameter is further categorized as simple, average or complex.
Let us see parameters of function point:
External Input
Every unique input to the system, from outside, is considered as external input. Uniqueness of input is measured, as no two inputs should have same formats. These inputs can either be data or control parameters.
• Simple - if input count is low and affects less internal files • Complex - if input count is high and affects more internal files • Average - in-between simple and complex.
www.Vidyarthiplus.com www.Vidyarthiplus.com
External Output
All output types provided by the system are counted in this category. Output is considered unique if their output format and/or processing are unique.
• Simple - if output count is low • Complex - if output count is high • Average - in between simple and complex.
Logical Internal Files
Every software system maintains internal files in order to maintain its functional information and to function properly. These files hold logical data of the system. This logical data may contain both functional data and control data.
• Simple - if number of record types are low • Complex - if number of record types are high • Average - in between simple and complex.
External Interface Files
Software system may need to share its files with some external software or it may need to pass the file for processing or as parameter to some function. All these files are counted as external interface files.
• Simple - if number of record types in shared file are low • Complex - if number of record types in shared file are high • Average - in between simple and complex.
External Inquiry
An inquiry is a combination of input and output, where user sends some data to inquire about as input and the system responds to the user with the output of inquiry processed. The complexity of a query is more than External Input and External Output. Query is said to be unique if its input and output are unique in terms of format and data.
• Simple - if query needs low processing and yields small amount of output data • Complex - if query needs high process and yields large amount of output data • Average - in between simple and complex.
Each of these parameters in the system is given weightage according to their class and complexity. The table below mentions the weightage given to each parameter:
www.Vidyarthiplus.com www.Vidyarthiplus.com
The table above yields raw Function Points. These function points are adjusted according to the environment complexity. System is described using fourteen different characteristics:
• Data communications • Distributed processing • Performance objectives • Operation configuration load • Transaction rate • Online data entry, • End user efficiency • Online update • Complex processing logic • Re-usability • Installation ease • Operational ease • Multiple sites • Desire to facilitate changes
These characteristics factors are then rated from 0 to 5, as mentioned below:
• No influence • Incidental • Moderate • Average • Significant • Essential
All ratings are then summed up as N. The value of N ranges from 0 to 70 (14 types of characteristics x 5 types of ratings). It is used to calculate Complexity Adjustment Factors (CAF), using the following formulae:
www.Vidyarthiplus.com www.Vidyarthiplus.com
CAF = 0.65 + 0.01N
Then,
Delivered Function Points (FP)= CAF x Raw FP
This FP can then be used in various metrics, such as:
Cost = $ / FP
Quality = Errors / FP
Productivity = FP / person-month
www.Vidyarthiplus.com www.Vidyarthiplus.com
Software Modeling and notation
What is software modeling? By software modeling we do not mean expressing a scientific theory or algorithm in software. This is what scientists traditionally call a software model. What we mean here by software modeling is larger than an algorithm or a single method. Software modeling should address the entire software design including interfaces, interactions with other software, and all the software methods. Software models are ways of expressing a software design. Usually some sort of abstract language or pictures are used to express the software design. For object-oriented software, an object modeling language such as UML is used to develop and express the software design. There are several tools that you can use to develop your UML design. In almost all cases a modeling language is used to develop the design not just to capture the design after it is complete. This allows the designer to try different designs and decide which will be best for the final solution. Think of designing your software as you would a house. You start by drawing a rough sketch of the floor plan and layout of the rooms and floors. The drawing is your modeling language and the resulting blueprint will be a model of your final design. You will continue to modify your drawings until you arrive at a design that meets all your requirements. Only then should you start cutting boards or writing code. Again the benefit of designing your software using a modeling language is that you discover problems early and fix them without refactoring your code.
Software Design Notations
A large number of notations and languages exist to represent software design artifacts. Some are used mainly to describe the structural organization of a design, whereas others are used to represent the behavior of such software systems. Note that certain notations are used mostly during architectural design whereas others are useful mainly during detailed design, although some can be used in both steps. Here, we categorize them into notations for describing the structural (static) view vs. the behavioral (dynamic) view.
• Structural descriptions (static view): These notations, mostly (but not always) graphical, can be used to describe and represent the structural aspects of a software design, that is, to describe what the major components are and how they are interconnected (static view).
- Architecture Description Languages (ADL): textual, often formal, languages used to describe an architecture in terms of components and connectors
www.Vidyarthiplus.com www.Vidyarthiplus.com
- Class and object diagrams: diagrams used to show a set of classes (and objects) and their relationships - Component diagrams: used to show a set of components (“physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces”) and their relationships - CRC Cards: used to denote the name of components (class), their responsibilities and the names of their collaborating components - Deployment diagrams: used to show a set of (physical) nodes and their relationships and, thus, to model the physical aspects of a system - Entity-Relationship Diagrams (ERD): used to define conceptual models of data stored in information systems - Interface Description Languages (IDL):programming-like languages used to define the interface (name and types of exported operations) of software components - Jackson structure diagrams: used to describe the structure of data in terms of sequence, selection and iteration - Structure charts: used to describe the calling structure of programs (which procedure/module calls/is called by which other)
• Behavioral descriptions (dynamic view): These notations and languages are used to describe the dynamic behavior of systems and components. Such notations include various graphical notations (e.g., activity diagrams, DFD, sequence diagrams, state transition diagrams) as well as some textual notations (e.g., formal specification languages, pseudo-code and PDL). Many of these notations are useful mostly, but not exclusively, during detailed design. - Activity diagrams: used to show the flow of control from activity (“ongoing non-atomic execution within a state machine”) to activity - Collaboration diagrams: used to show the interactions that occur among a group of objects, where the emphasis is on the objects, their links and the messages they exchange on these links - Data flow diagrams: used to show the flow of data among a set of processes - Decision tables and diagrams: used to represent complex combination of conditions and actions - Flowcharts and structured flowcharts: used to represent the flow of control and the associated actions to be performed Formal specification languages: textual languages that use basic notions from mathematics (e.g., logic, set, sequence) to rigorously and abstractly define the interface and behavior of software components, often in terms of pre/post-conditions:
www.Vidyarthiplus.com www.Vidyarthiplus.com
- Pseudo-code and Program Design Languages (PDL): structured, programming-like languages used to describe, generally at the detailed design stage, the behavior of a procedure or method - Sequence diagrams: used to show the interactions among a group of objects, with the emphasis on the time-ordering of messages - State transition and statechart diagrams: used to show the flow of control from state to state in a state machine
Data Flow Diagrams (DFDs) • A notation developed in conjunction with structured systems • analysis/structured design (SSA/SD). • Used primarily for pipe-and-filter styles of architecture. • Graph–based diagrammatic notation. • There are extensions for real-time systems that distinguish control • flow from data flow.
DFDs: Diagrammatic elements
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
Software Design Concepts
Every software process is characterized by basic concepts along with certain practices or methods. Methods represent the manner through which the concepts are applied. As new technology replaces older technology, many changes occur in the methods that are used to apply the concepts for the development of software. However, the fundamental concepts underlining the software design process remain the same, some of which are described here. Abstraction
Abstraction refers to a powerful design tool, which allows software designers to consider components at an abstract level, while neglecting the implementation details of the components. IEEE defines abstraction as 'a view of a problem that extracts the essential information relevant to a particular purpose and ignores the remainder of the information.' The concept of abstraction can be used in two ways: as a process and as an entity. As a process, it refers to a mechanism of hiding irrelevant details and representing only the essential features of an item so that one can focus on important things at a time. As an entity, it refers to a model or view of an item.
Each step in the software process is accomplished through various levels of abstraction. At the highest level, an outline of the solution to the problem is presented whereas at the lower levels, the solution to the problem is presented in detail. For example, in the requirements analysis phase, a solution to the problem is presented using the language of problem environment and as we proceed through the software process, the abstraction level reduces and at the lowest level, source code of the software is produced.
As different levels of abstraction are developed, you work to create both procedural and data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. An example of a procedural abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.). A data abstraction is a named collection of data that describes a data object. In the context of the procedural abstraction open, we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe
www.Vidyarthiplus.com www.Vidyarthiplus.com
the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstraction door.
There are three commonly used abstraction mechanisms in software design, namely, functional abstraction, data abstraction and control abstraction. All these mechanisms allow us to control the complexity of the design process by proceeding from the abstract design model to concrete design model in a systematic manner.
1. Functional abstraction: This involves the use of parameterized subprograms. Functional abstraction can be generalized as collections of subprograms referred to as 'groups'. Within these groups there exist routines which may be visible or hidden. Visible routines can be used within the containing groups as well as within other groups, whereas hidden routines are hidden from other groups and can be used within the containing group only.
2. Data abstraction: This involves specifying data that describes a data object. For example, the data object window encompasses a set of attributes (window type, window dimension) that describe the window object clearly. In this abstraction mechanism, representation and manipulation details are ignored.
3. Control abstraction: This states the desired effect, without stating the exact mechanism of control. For example, if and while statements in programming languages (like C and C++) are abstractions of machine code implementations, which involve conditional instructions. In the architectural design level, this abstraction mechanism permits specifications of sequential subprogram and exception handlers without the concern for exact details of implementation. Modularity
Modularity is achieved by dividing the software into uniquely named and addressable components, which are also known as modules. A complex system (large program) is partitioned into a set of discrete modules in such a way that each module can be developed independent of other modules. After developing the modules, they are integrated together to meet the software requirements. Note that larger the number of modules a system is divided into, greater will be the effort required to integrate the modules.
Modularity is designing a system that is divided into a set of functional units (named modules) that can be composed into a larger application. A module represents a set of
www.Vidyarthiplus.com www.Vidyarthiplus.com
related concerns. It can include a collection of related components, such as features, views, or business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.
A composite application exhibits modularity. For example, consider an online banking program. The user can access a variety of functions, such as transferring money between accounts, paying bills, and updating personal information from a single user interface (UI). However, behind the scenes, each of these functions is a discrete module. These modules communicate with each other and with back-end systems such as database servers. Application services integrate components within the different modules and handle the communication with the user. The user sees an integrated view that looks like a single application.
It has been stated that “modularity is the single attribute of software that allows a program to be intellectually manageable”. Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer. The number of control paths, span of reference, number of variables, and over- all complexity would make understanding close to impossible. In almost all instances, you should break the design into many modules, hoping to make under- standing easier and, as a consequence, reduce the cost required to build the software. Recalling my discussion of separation of concerns, it is possible to conclude that if you subdivide software indefinitely the effort required to develop it will become negligibly small! Unfortunately, other forces come into play, causing this conclusion to be (sadly) invalid. Referring to Figure 8.2, the effort (cost) to develop an individual software module does decrease as the total number of modules increases. Given the same set of requirements, more modules means smaller individual size. However, as the number of modules grows, the effort (cost)
www.Vidyarthiplus.com www.Vidyarthiplus.com
associated with integrating the modules also grows. These characteristics lead to a total cost or effort curve shown in the figure. There is a number, M, of modules that would result in minimum development cost, but we do not have the necessary sophistication to predict M with assurance. The curves shown in Figure 8.2 do provide useful qualitative guidance when modularity is considered. You should modularize, but care should be taken to stay in the vicinity of M. Undermodularity or overmodularity should be avoided. But how do you know the vicinity of M? How modular should you make software? The answers to these questions require an understanding of other design concepts considered later in this chapter. You modularize a design (and the resulting program) so that development can be more easily planned; software increments can be defined and delivered; changes can be more easily accommodated; testing and debugging can be conducted more effi- ciently, and long- term maintenance can be conducted without serious side effects.
Why Choose a Modular Design?
The following scenarios describe why you might want to choose a modular design for your application:
• Simplified modules. Properly defined modules have a high internal cohesion and loose coupling between modules. The coupling between the modules should be through well-defined interfaces. • Developing and/or deploying modules independently. Modules can be developed, tested, and/or deployed on independent schedules when modules are developed in a loosely coupled way. By doing this, you can do the following: o You can independently version modules. o You can develop and test modules in isolation. o You can have modules developed by different teams. • Loading modules from different locations. A Windows Presentation Foundation (WPF) application might retrieve modules from the Web, from the file system and/or from a database. A Silverlight application might load modules from different XAP files. However, most of the time, the modules come from one location; for example, there is a specific folder that contains the modules or they are in the same XAP file. • Minimizing download time. When the application is not on the user's local computer, you want to minimize the time required to download the modules. To minimize the download time, only download modules that are required to start-up
www.Vidyarthiplus.com www.Vidyarthiplus.com
the application. The rest are loaded and initialized in the background or when they are required. • Minimizing application start-up time. To get part of the application running as fast as possible, only load and initialize the module(s) that are required to start the application. • Loading modules based on rules. This allows you to only load modules that are applicable for a specific role. An application might retrieve from a service the list of modules to load.
Modularizing a design helps to plan the development in a more effective manner, accommodate changes easily, conduct testing and debugging effectively and efficiently, and conduct maintenance work without adversely affecting the functioning of the software.
Objectives of modularity in a design method
•Modular Decomposability –Provide a systematic mechanism to decompose a problem into sub problems •Modular Composability –Enable reuse of existing components •Modular Understandability –Can the module be understood as a stand alone unit? Then it is easier to understand and change. •Modular Continuity –If small changes to the system requirements result in changes to individual modules, rather than system-wide changes, the impact of the side effects is reduced (note implications in previous example) •Modular Protection –If there is an error in the module, then those errors are localized and not spread to other modules
www.Vidyarthiplus.com www.Vidyarthiplus.com
Cohesion
•Relative functional strength of a module •A cohesive module performs a single task •Different levels of cohesion –Coincidental, logical, temporal, procedural, communications, sequential, functional
•Coincidental Cohesion –Occurs when modules are grouped together for no reason at all
• Elements contribute to activities with no meaningful relationship to one another
• Similar to logical cohesion, except the activities may not even be the same type
• Mixture of activities - like ‘rojak’!
• Difficult to understand and maintain, with strong possibilities of causing ‘side effects’ every time the module is modified • Example of Coincidental Cohesion module miscellaneous functions use customer record display customer record calculate total sales read transaction record return transaction record end module
•Logical Cohesion –Modules have a logical cohesion, but no actual connection in data and control
• Elements contribute to activities of the same general category (type)
• For example, a report module, display module or I/O module
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Usually have control coupling, since one of the activities will be selected
• Example of Logical Cohesion • module display record
use record-type, record if record-type is student then display student record else if record-type is staff then display staff record end module
•Temporal Cohesion –Modules are bound together because they must be used at approximately the same time
• Elements are involved in activities that are related in time
• Commonly found in initialisation and termination modules
• Elements are basically unrelated, so the module will be difficult to reuse
• Good practice is to initialise as late as possible and terminate as early as possible
• Example of Temporal Cohesion • module initialise • set counter to 0
• open student file
• clear error message variable
• initialise array
• Procedural cohesion
• Elements are related only by sequence, otherwise the activities are unrelated
• Similar to sequential cohesion, except for the fact that elements are unrelated
• Commonly found at the top of hierarchy, such as the main program module
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Example of Procedural Cohesion • module write read and edit something • use out record
• write out record
• read in record
• pad numeric fields with zeros
• return in record
•Communication Cohesion –Modules grouped together because they access the same Input/Output devices
• Elements contribute to activities that use the same input or output data
• Not flexible, for example, if we need to focus on some activities and not the others
• Possible links that cause activities to affect each other
• Better to split to functional cohesive ones
• Example of Communicational Cohesion
• module determine customer details
• use customer account no
• find customer name
• find customer loan balance
• return customer name, loan balance
•Sequential Cohesion –Elements in a module are linked together by the necessity to be activated in a particular order
• Elements are involved in activities such that output data from one activity becomes input data to the next
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Usually has good coupling and is easily maintained
• Not so readily reusable because activities that will not in general be useful together
• Example of Sequential Cohesion
• module format and cross-validate record
• use raw record
• format raw record
• cross-validate fields in raw record
• return formatted cross-validated record
•Functional Cohesion –All elements of a module relate to the performance of a single function
• All elements contribute to the execution of one and only one problem- related task
• Focussed - strong, single-minded purpose
• No elements doing unrelated activities
• Examples of functional cohesive modules: • Compute cosine of angle
• Read transaction record
• Assign seat to airline passenger
The internal cohesion of a module is measured in terms of the strength of binding elements within the module. Cohesion of elements occurs on the scale of weakest (least desirable) to strongest (most desirable).
We have seen that coupling is reduced, when the relationships among elements, in different modules are minimized. That is, coupling is reduced when elements in different modules have little or no bonds between them. Another way of achieving this effect is to strengthen the bond between elements of the same module by maximizing the relationship between elements of the same module. Cohesion is the concept that tries to capture this intramodule. With cohesion, we are interested in determining how closely the elements of a module are related to each other.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Cohesion of a module represents how tightly the internal elements of the module are bound to one another. Cohesion of a module gives the designer an idea about whether the different elements of a module belong together in the same module. Cohesion and coupling are clearly related. Usually, the greater the cohesion of each module in the system, the lower the coupling between modules is. This correlation is not perfect, but it has been observed in practice. There are several levels of cohesion:
• Coincidental • Logical • Temporal • Procedural • Communicational • Sequential • Functional
Coincidental is the lowest level, and functional is the highest. These levels do not form a linear scale. Functional binding is much stronger than the rest, while the first two are considered much weaker than others. Often, many levels can be applicable when considering cohesion between two elements of a module. In such situations, the highest level is considered. Cohesion of a module is considered the highest level of cohesion applicable to all elements in the module.
Coincidental cohesion occurs when there is no meaningful relationship among the elements of a module. Coincidental cohesion can occur if an existing program is “modularized”, by chopping it into pieces and making different piece modules. If a module is created to save duplicate code by combining some part of code that occurs at many different places, that module is likely to have coincidental cohesion. In this situation, the statements in the module have no relationship with each other, and if one of the modules using the code needs to be modified and this modification includes the common code, it is likely that other modules using the code do not want the code modified. Consequently, the modification of this “common module” may cause other modules to behave incorrectly. The modules using these modules are, therefore, not modifiable separately and have strong interconnection between them. We can say that, generally speaking, it is poor practice to create a module merely to avoid duplicate code (unless, the common code happens to perform some identifiable function, in which case, the statements will have some relationship between them) or to chop a module into smaller modules to reduce the module size.
A module has logical cohesion if there is some logical relationship between the elements of a module, and the elements perform functions that fall in the same logical class. A typical example of this kind of cohesion is a module that performs all the inputs or all the outputs. In such a situation, if we want to input or output a particular record, we have to somehow convey this, to the module. Often, this will be done by passing some kind of special status flag, which will be used to determine what statements to execute in the module. Besides, resulting in hybrid information flow between modules, which is
www.Vidyarthiplus.com www.Vidyarthiplus.com
generally the worst form of coupling between modules, such a module will usually have tricky and clumsy code. In general, logically cohesive modules should be avoided, if possible.
Temporal cohesion is the same as logical cohesion, except that the elements are also related in time and are executed together. Modules that perform activities like “initialization,” “clean-up,” and “termination” are usually temporally bound. Even though the elements in a temporally bound module are logically related, temporal cohesion is higher than logical cohesion, because the elements are all executed together. This avoids the problem of passing the flag, and the code is usually simpler.
A procedurally cohesive module contains elements that belong to a common procedural unit. For example, a loop or a sequence of decision statements in a module may be combined to form a separate module. Procedurally cohesive modules, often, occur when modular structure is determined from some form flowchart, Procedural cohesion, often, cuts across functional lines. A module with only procedural cohesion may contain only part of a complete function or parts of several functions.
A module with communicational cohesion has elements that are related by a reference to the same input or output data. That is, in a communication ally bound module, the elements are together because they operate on the same input or output data. An example of this could be a module to “print and punch record.” Communicably, cohesive modules may perform more than one function. However, communicational cohesion is sufficiently high, as to be generally acceptable, if alternative structures with higher cohesion cannot be easily identified.
When the elements are together in a module, because the output of one forms the input to another, we get sequential cohesion. If we have a sequence of elements in which the output of one forms the input to another, sequential cohesion does not provide any guidelines on how to combine them into modules. Different possibilities exist: combine all in one module, put the first half in one and the second half in another, the first third in one and the rest in the other, and so forth. Consequently, a sequentially bound module may contain several functions or parts of different functions. Sequentially, cohesive modules bear a close resemblance to the problem structure. However, they are considered to be far from the ideal, which is functional cohesion.
Functional cohesion is the strongest cohesion. In a functionally bound module, all the elements of the module are related to performing a single function. By function, we do not mean simply mathematical functions; modules accomplishing a single goal are also included. Functions like “compute square root” and “sort the array” are clear examples of functionally cohesive modules.
How does one determine the cohesion level of a module? There is no mathematical formula that can be used. We have to use our judgment for this. A useful technique for determining if a module has functional cohesion is to write a sentence that describes,
www.Vidyarthiplus.com www.Vidyarthiplus.com
fully and accurately, the function or purpose of the module. The following tests can, then, be made:
1. If the sentence must be a compound sentence, if it contains a comma, or it has more than one verb, the module is probably performing more than one function, and it probably has sequential or communicational cohesion. 2. If the sentence contains words relating to time, like “first,” “next,” “when,” and “after”, the module, probably, has sequential or temporal cohesion. 3. If the predicate of the sentence does not contain a single specific object following the verb (such as “edit all data”), the module probably has logical cohesion. 4. Words like “initialize,” and “cleanup” imply temporal cohesion.
Modules with functional cohesion can always be described by a simple sentence. However, if a description is a compound sentence, it does not mean that the module does not have functional cohesion. Functionally cohesive modules can also be described by compound sentences. If we cannot describe it using a simple sentence, the module is not likely to have functional cohesion. Coupling
•Relative interdependence among modules •Coupling describes the interconnection among modules •Data coupling –Occurs when one module passes local data values to another as parameters
• Modules communicate by parameters
• Each parameter is an elementary piece of data
• Each parameter is necessary to the communication
• Nothing extra is needed
Data coupling problems
• Too many parameters - makes the interface difficult to understand and possible error to occur
• Tramp data - data ‘traveling’ across modules before being used
•Stamp coupling –Occurs when part of a data structure is passed to another module as a parameter
www.Vidyarthiplus.com www.Vidyarthiplus.com
• A composite data is passed between modules
• Internal structure contains data not used
• Bundling - grouping of unrelated data into an artificial structure
•Control Coupling –Occurs when control parameters are passed between modules
• A module controls the logic of another module through the parameter
• Controlling module needs to know how the other module works - not flexible!
• Common Coupling –Occurs when multiple modules access common data areas such as Fortran Common or C extern
• Use of global data as communication between modules
• Dangers of • ripple effect
• inflexibility
• difficult to understand the use of data
•Content Coupling –Occurs when a module data in another module
• A module refers to the inside of another module
• Branch into another module
• Refers to data within another module
• Changes the internal workings of another module
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Mostly by low-level languages
•Subclass Coupling –The coupling that a class has with its parent class
A fundamental goal of software design is to structure the software product so that the number and complexity of interconnections between modules is minimized. An appealing set of heuristics, for achieving this goal, involves the concepts of coupling and cohesion.
Two modules are considered independent if one can function completely without the presence of other. Obviously, if two modules are independent, they are solvable and modifiable separately. However, all the modules in a system cannot be independent of each other, as they must interact so that together, they produce the desired external behavior of the system. The more connections between modules, the more dependent they are in the sense that more knowledge about one module is required to understand or solve the other module. Hence, the fewer and simpler the connections between modules, the easier it is to understand one without understanding the other. The notion of coupling attempts to capture this concept of “how strongly” different modules are interconnected.
Coupling between modules is the strength of interconnections between modules or a measure of interdependence among modules. In general, the more we must know about module A, in order to understand module B, the more closely connected A is to B. “Highly coupled” modules are joined by strong interconnections, while “loosely coupled” modules have weak interconnections. Independent modules have no interconnections. To solve and modify a module separately, we would like the module to be loosely coupled with other modules. The choice of modules decides the coupling between modules. Because the modules of the software system are created during system design, the coupling between modules is largely decided during system design and cannot be reduced during implementation.
Coupling is an abstract concept and is not easily quantifiable. So, no formulas can be given to determine the coupling between two modules. However, some major factors can be identified as influencing coupling between modules. Among them the most important are, the type of connection between modules, the complexity of the interface, and the type of information flow between modules.
Coupling increases with the complexity and obscurity of the interface between modules. To keep coupling low, we would like to minimize the number of interfaces per module and the complexity of each interface. An interface of a module is used to pass information to and from other modules. Coupling is reduced if only the defined entry interface of a module is used by other modules (for example, passing information to and from a module, exclusively through parameters). Coupling would increase if a module were used by other modules via an indirect and obscure interface, like directly using the internals of a module or using shared variables.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Complexity of the interface is another factor affecting coupling. The more complex each interface is, the higher will be the degree of coupling. For example, complexity of the entry interface of a procedure depends on the number of items being passed as parameters and on the complexity of the items. Some level of complexity of interfaces is required to support the communication needed between modules. However, often more than this, minimum is used. For example, if a field of a record is needed by a procedure, often the entire record is passed, rather than just passing that field of the record. By passing the record, we are increasing the coupling unnecessarily. Essentially, we should keep the interface of a module as simple and small as possible.
The type of information flow along the interfaces is the third major factor-affecting coupling. There are two kinds of information that can flow along an interface: data or control. Passing or receiving control information means that the action of the module will depend on this control information, which makes it more difficult to understand the module and provide its abstraction. Transfer of data information means that a module passes some data as input to another module and gets in return some data as output. This allows a module to be treated as a simple input- output function that performs some transformation on the input data to produce the output data. In general, interfaces with only data communication result in the lowest degree of coupling, followed by interfaces that only transfer control data. Coupling is considered highest if the data is hybrid, that is, some data items and some control items are passed between modules.
Examples of Coupling
www.Vidyarthiplus.com www.Vidyarthiplus.com
Hierarchy
• Hierarchy reduces component interactions by restricting the topology of relationships
• A relation defines a hierarchy if it partitions units into levels
• Hierarchies form the basis of architectures and designs
– Facilitates independent development
– Isolates complexity of change
– Allows rapid prototyping
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
Design guidelines
Design is the process of organizing structured solutions to tasks from a problem domain _ This process is carried out in many disciplines, in many ways
– There are many similarities and commonalities among design processes – There are also many common design mistakes . . .
Common Design Mistakes
_ Depth-first design
– only partially satisfy the requirements – experience is best cure for this problem . . .
_ Directly refining requirements specification
– leads to overly constrained, inefficient designs
_ Failure to consider potential changes
– always design for extension and contraction _ Making the design too detailed – this overconstrains the implementation
_ Ambiguously stated design
– misinterpreted at implementation
_ Undocumented design decisions
– designers become essential to implementation
_ Inconsistent design
– results in a non-integratable system, because separately developed modules don’t fit together
Rules of Design
_ Make sure that the problem is well-defined – All design criteria, requirements, and constraints, should be enumerated before a design is started
www.Vidyarthiplus.com www.Vidyarthiplus.com
– This may require a “spiral model” approach
_ What comes before how – i.e., define the service to be performed at every level of abstraction before deciding which structures should be used to realize the services _ Separate orthogonal concerns – Do not connect what is independent – Important at many levels and phases . . . _ Design external functionality before internal functionality. – First consider the solution as a black-box and decide how it should interact with its environment – Then decide how the black-box can be internally organized. Likely it consists of smaller black-boxes that can be refined in a similar fashion _ Keep it simple. – Fancy designs are buggier than simple ones; they are harder to implement, harder to verify, and often less efficient – Problems that appear complex are often just simple problems huddled together – Our job as designers is to identify the simpler problems, separate them, and then solve them individually _ Work at multiple levels of abstraction – Good designers must be able to move between various levels of abstraction quickly and easily _ Design for extensibility – A good design is “open-ended,” i.e., easily extendible – A good design solves a class of problems rather than a single instance – Do not introduce what is immaterial – Do not restrict what is irrelevant _ Use rapid prototyping when applicable – Before implementing a design, build a high-level prototype and verify that the design criteria are met
_ Details should depend upon abstractions – Abstractions should not depend upon details – Principle of Dependency Inversion _ The granule of reuse is the same as the granule of release – Only components that are released through a tracking system can be effectively reused _ Classes within a released component should share common closure – That is, if one needs to be changed, they all are likely to need to be changed – i.e., what affects one, affects all
www.Vidyarthiplus.com www.Vidyarthiplus.com
_ Classes within a released component should be reused together – That is, it is impossible to separate the components from each other in order to reuse less than the total _ The dependency structure for released components must be a DAG – There can be no cycles _ Dependencies between released components must run in the direction of stability – The dependee must be more stable than the depender _ The more stable a released component is, the more it must consist of abstract classes – A completely stable component should consist of nothing but abstract classes _ Where possible, use proven patterns to solve design problems _ When crossing between two different paradigms, build an interface layer that separates the two – Don’t pollute one side with the paradigm of the other _ Software entities (classes, modules, etc) should be open for extension, but closed for modification – The Open/Closed principle – Bertrand Meyer _ Derived classes must usable through the base class interface without the need for the user to know the difference – The Liskov Substitution Principle
_ Make it work correctly, then make it work fast – Implement the design, measure its performance, and if necessary, optimize it _ Maintain consistency between representations – e.g., check that the final optimized implementation is equivalent to the high-level design that was verified – Also important for documentation . . .
checklists
The checklist is intended to provide system owners, project managers, configuration managers, and other information system development and maintenance professionals with guidance in identifying and planning software design activities. The checklist reflects recognized design activities to be performed throughout the information system project life cycle. Software design starts as a process for translating documented system requirements into a user-oriented functional design. The system owner, users, and project team finalize this design and use it as a basis for the more technical system design.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Example 1:
1. Are the following attributes well-defined for each design entity? a. Identification (unique name) b. Type (describing what kind of design entity it is) c. Purpose (describing why it was introduced, in terms of the requirements) d. Function (summarizing what the component does) e. Dependencies (possibly `none'; describing the requires or uses relationship) f. Interface (provided by the design entity) g. Processing (including autonomous activities) h. Data (information `hidden' inside) 2. Is the relationship to the requirements clearly motivated? Is it clear why the proposed architecture realizes the requirements? 3. Is the software architecture as simple as possible (but no simpler)? o No more than 7 loosely-coupled coherent high-level components. o Lower-level components possibly clustered into high-level components (hierarchy). o Using standard(ized) components. o Is deviation from intuitively obvious solution motivated? 4. Is the architecture complete? o Are all requirements covered? o Trace some critical requirements through the architecture (e.g. via use cases). 5. Are the component descriptions sufficiently precise? o Do they allow independent construction? o Are interfaces and external functionality of the high-level components described in sufficient detail? o Interface details: . Routine kind, name, parameters and their types, return type, pre- and post-condition, usage protocol with respect to other routines. . File name, format, permissions. . Socket number and protocol. . Shared variables, synchronization primitives (locks). o Have features of the target programming language been used where appropriate? o Have implementation details been avoided? (No details of internal classes.) 6. Are the relationships between the components explicitly documented? o Preferably use a diagram 7. Is the proposed solution achievable? o Can the components be implemented or bought, and then integrated together. o Possibly introduce a second layer of decomposition to get a better grip on achievability.
www.Vidyarthiplus.com www.Vidyarthiplus.com
8. Are all relevant architectural views documented? o Logical (Structural) view (class diagram per component expresses functionality). o Process view (how control threads are set up, interact, evolve, and die). o Physical view (deployment diagram relates components to equipment). o Development view (how code is organized in files). 9. Are cross-cutting issues clearly and generally resolved? o Exception handling. o Initialization and reset. o Memory management. o Security. o Internationalization. o Built-in help. o Built-in test facilities. 10. Is all formalized material and diagrammatic material accompanied by sufficient explanatory text in natural language? 11. Are design decisions documented explicitly and motivated? o Restrictions on developer freedom with respect to the requirements. 12. Has an evaluation of the software architecture been documented? o Have alternative architectures been considered? o Have non-functional requirements also been considered? o Negative indicators: . High complexity: a component has a complex interface or functionality. . Low cohesion: a component contains unrelated functionality. . High coupling: two or more components have many (mutual) connections. . High fan-in: a component is needed by many other components. . High fan-out: a component depends on many other components. 13. Is the flexibility of the architecture demonstrated? o How can it cope with likely changes in the requirements? o Have the most relevant change scenarios been documented?
Example 2:
– Was the software architecture presented? – Were all interface descriptions presented (both internal and external)? – Were software subsystems or major components defined? – Were design alternatives and tradeoffs addressed? – Were resource estimates presented (e.g., Central Processing Unit (CPU), memory, databases, and data storage)? – Was the error handling and recovery strategy presented?
www.Vidyarthiplus.com www.Vidyarthiplus.com
– Has the design been elaborated in baseline diagrams to a sufficient level of detail? – Were the following drivers specified: performance, reliability, hardware, memory considerations, and programming languages? – Was the test strategy/plan discussed, including test environments, test data, and tools? – Was the design or part of a design follow a well-known architectural pattern? – Was the design or a part of the design follow a well-known design pattern? – Were Configuration Management (CM) and Product Assurance tools discussed to a sufficient level of detail? – Was change control discussed in a sufficient details?
– Does the overall design implement all explicit (functional) requirements? Has a traceability table been developed? – Does the overall design achieve all implicit (non-functional) requirements? – Is the design represented in a form that is easily understood by outsiders? – Is design notation standardized? Consistent? – Does the overall design provide sufficient information for test case design? – Does the design strive to incorporate reusable components? – Is the design modular? – Has the resultant software architecture been partitioned for ease of implementation? Maintenance? – Have the concepts of information hiding and functional independence been followed throughout the design?
– Does the design exhibits loose coupling?
– Does the design exhibits high cohesion? – Has a Design Specification been developed for the software?
www.Vidyarthiplus.com www.Vidyarthiplus.com
Refactoring
Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code, and many other varieties of confusion and clutter.
Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems. In an agile context, it can mean the difference between meeting or not meeting an iteration deadline.
Refactoring code ruthlessly prevents rot, keeping the code easy to maintain and extend. This extensibility is the reason to refactor and the measure of its success. But note that it is only "safe" to refactor the code this extensively if we have extensive unit test suites of the kind we get if we work Test-First. Without being able to run those tests after each little step in a refactoring, we run the risk of introducing bugs. If you are doing true Test- Driven Development (TDD), in which the design evolves continuously, then you have no choice about regular refactoring, since that's how you evolve the design.
What?
Fowler says that refactoring is the
"... process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."
The definition of refactoring is:
"a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour"
Just cleaning up code.
Contrary to idealized development strategy:
1. analysis and design 2. code 3. test
www.Vidyarthiplus.com www.Vidyarthiplus.com
At first, code is pretty good but as requirements change or new features are added, the code structure tends to atrophy. Refactoring is the process of fixing a bad or chaotic design.
Amounts to moving methods around, creating new methods, adding or deleting classes, ...
Note: Sometimes it means completely redoing the entire code base (i.e., throwing stuff away). Avoid the second system effect!
Why?
Improve code structure and design
• more maintainable • easier to understand • easier to modify • easier to add new features
Cumulative effect can radically improve design rather than normal slide into decay.
Flip-flop code development and refactoring. Only refactor when refactoring--do not add features during refactoring.
Note: kind of like an immune system that constantly grooms the body looking for offensive and intrusive entities.
Bad code usually takes more code to do the same thing often because of duplication:
Improving design then often includes removing duplicate code. Don't want duplicates because of bloat and also you only want one place to change functionality not multiple.
Fowler says he will refactor existing code just to understand it better and sometimes it helps to find bugs.
In summary, refactoring helps you develop better code, faster!
The purpose of refactoring is to improve the quality, clarity and maintainability of your code. Simple really.
But also, refactoring can be a great lesson in understanding an unfamiliar code base.
Think about it, if you inherit a poorly designed code base that you've not seen before and you now need to either fix a bug or add a new feature, then implementing the code necessary would be a lot easier once you had refactored it to be in a more stable, maintainable and ultimately 'understandable' state.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Otherwise you would be forced to retro fit your new code on top of a poorly designed foundation and that would be the start of a very unhappy relationship.
Kent Beck:
"Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow."
Mostly we are focused on today, but you cannot code today so that you cannot code tomorrow. Actively making the future smoother is a great idea. When you find tomorrow that today you made a mistake, you use refactoring to fix the decision.
Fowler says database refactoring is super hard. See TJP's jGuru example below for entity specifications. :)
When not to refactor?
• Sometimes you should throw things out and start again. • Sometimes you are too close to a deadline.
When should you refactor?
You'll usually find the time you start refactoring the most is when you are fixing bugs or adding new features.
For example, you typically first need to understand the code that has already been written (regardless of whether it was you who wrote it originally or someone else).
The process of refactoring helps you better understand the code, in preparation for modifying it.
But don't fall into the trap of thinking that refactoring is something you set aside time for, or only consider at the start/end of a project. It's not. Refactoring should be done in small chunks throughout the entire life cycle of the project.
As the great Uncle Bob once said: leave a module in a better state than you found it
...what this suggests is that refactoring is essential to your daily coding process.
Tests
Before we get started, it's important to mention that you should have tests in place when you're refactoring.
www.Vidyarthiplus.com www.Vidyarthiplus.com
You can refactor without tests, but realise that without tests to back you up then you can have no confidence in the refactoring you are implementing.
Refactoring can result in substantial changes to the code and architecture but still leave the top layer API the same. So while you're refactoring remember the old adage...
program to an interface, not an implementation
We want to avoid changing a public API where ever possible (as that's one of the tenets of refactoring).
If you don't have tests then I recommend you write some (now)... don't worry, I'll wait.
Remember, the process of writing tests (even for an application you don't know) will help solidify your understanding and expectations of the code you're about to work on.
Code should be tested regularly while refactoring to ensure you don't break anything. Keep the 'red, green, refactor' feedback loop tight. Tests help confirm if your refactoring has worked or not. Without them you're effectively flying blind.
So although I won't explicitly mention it below when discussing the different refactoring techniques, it is implied that on every change to your code you should really be running the relevant tests to ensure no broken code appears.
Refactoring Techniques
There are many documented refactoring techniques and I do not attempt to cover them all, as this post would end up becoming a book in itself. So I've picked what I feel are the most common and useful refactoring techniques and I try my best to explain them in a short and concise way.
I've put these techniques in order of how you might approach refactoring a piece of code, in a linear, top to bottom order. This is a personal preference and doesn't necessarily represent the best way to refactor.
Final note: with some of the techniques I have provided a basic code example, but to be honest some techniques are so simple they do not need any example. The Extract Method is one such technique that although really useful and important, providing a code example would be a waste of time and space.
1. Rename Method
The single most effective and simple refactoring you can implement is to rename a property/attribute, method or object.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
You'll find that renaming things is a fundamental part of other refactoring techniques to aid understanding of the code.
This technique relies on giving items a descriptive name to ensure the developer knows at a glance exactly what it does. The following technique Introduce Explaining Variable is effectively the same.
2. Introduce Explaining Variable
So here is a technique specifically based around the premise of renaming.
If you have a complicated expression (for example, you'll typically have a long winded set of conditions within an if statement) then place that complex expression into a temp variable and give it a descriptive identifier.
Note: this is the only technique that finds temps (i.e. local variables) acceptable. This is because temps are deemed to be less reusable than methods (due to their very nature being 'local') and so introducing temps is something that shouldn't be considered lightly. Maybe consider using the Extract Method technique instead before using this particular technique.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Also, don't worry about performance until you know you have a performance issue to worry about. Developers will always suggest that calling methods is slower than running code inline, but good programming is about readability and maintainability, and extracted methods are not only easier to understand but are much more reusable by other methods.
So if you are considering using the Introduce Explaining Variable technique, first decide whether the temp would be more useful if it was available to other methods (that way you could use Extract Method instead and avoid defining a temp altogether).
3. Inline Temp
Temp variables are a bit of a code smell as they make methods longer and can make the Extract Method more awkward (as you'd have to pass through more data to the extracted method).Inline Temp effectively removes the temp variable altogether by just using the value assigned to it (I'd only suggest doing this if the temp is only used once or if the resulting value has come from a method invocation).
4. Split Temp Variable
This technique aims to resolve the concern of violating the SRP (Single Responsibility Principle), although slightly tamer in the sense that SRP is aimed more at Classes/Objects and methods, not typically variable assignments.
But regardless if a temporary variable is assigned to more than once and it is not a loop variable or a collecting/accumulator variable then it is a temp considered to have too many responsibilities.
5. Replace Temp With Query
This technique has a very similar intent to Inline Temp in that one of its primary focuses is to aid the Extract Method.The subtle but important difference between this technique and Inline Temp is that the complex expression assigned to the temp needs to be first moved to a method (where as the Inline Temp technique is different in that the temp may already be using a method invocation).
6. Extract Method The implementation behind this technique is very simple. It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
7. Replace Temp With Chain
This is yet another technique designed to rid your code of temp variables. If you have a temp variable holding the result of calling an object's method, and follow the assignment
www.Vidyarthiplus.com www.Vidyarthiplus.com
by using that temp to carry out more method calls, then you should consider chaining method calls instead.The implementation is quite simple, you just have to ensure the methods called return self (or this if using a language like JavaScript).By allowing methods to chain we again have the opportunity to remove an unnecessary temps.
8. Inline Method
Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. In this instance we're just making an extra call for no real benefit.
So to fix this problem we'll convert the method invocation into an inlined piece of code (unless of course the method is used in multiple places, in that case leave it where it is as having it in a separate method keeps our code DRY).
9. Move Method
In a previous post about Object-Oriented Design I explained that you should query your classes/objects to ensure the methods they define are actually where they should be (another reason is 'feature envy', if a method is asking another class a lot of questions then it may be an indication the method is on the wrong object).
The Move Method technique ensures this decoupling by simply moving the identified misplaced method onto the correct one.
Once the method has been moved you should clean up the previously passed parameters by seeing what can be moved over to the other object or whether additional data needs to be passed over now via the method invocation.
10. Replace Method With Method Object
You may run into a problem where you have a long method you want to use Extract Method on, but the number of temporary local variables are too great to allow you to utilise the Extract Method technique (because passing around that many variables would be just as messy as the long method itself).
To resolve this issue you could look at different types of smaller refactors (such as Inline Temp) but in some cases it would actually be better to first move the contents of the long method into an entirely new object.
So the first thing to do is create a new class named after the long method and add the temp local vars as properties/attributes of the class/object.Now when you try to implement Extract Method you don't have to pass around the temp vars because they are now available throughout the class/object. Then from within the original class/object you can delegate any calls to the original method on to the object (you'll still pass on the
www.Vidyarthiplus.com www.Vidyarthiplus.com
original arguments to the method within the new object but from there on the method extraction becomes easier).
11. Pull Up Method
When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).
12. Form Template Method
The technique is reliant on inheritance: a parent class and two sub classes of that parent. The two sub classes have methods which have similar steps, in the same order and yet the steps themselves are different.
The technique involves moving the sequence of steps into the parent class and then using polymorphism to allow the sub classes to handle the differences in the steps.
13. Extract Surrounding Method
If you find you have different methods which contain almost identical code but with a slight variant in the middle, then pull up the duplicated code into a single method and pass a code block to the newly created method which it yields to in order to execute the unique behaviour...
14. Self Encapsulate Field
When inheriting properties from a parent class/object then it can be more flexible if the parent class only allows access to the properties from within a getter/setter.
The motivation for this technique is that a sub class can override and modify the behaviour of the getter/setter without affecting the parent class' implementation. Which is similar to how the Decorator design pattern works (e.g. modifying the behaviour without affecting the original).
This technique should only be used once you find the coupling between objects is becoming a problem. Otherwise direct access to properties and instance variables should be acceptable initially.
15. Introduce Named Parameter
When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).
www.Vidyarthiplus.com www.Vidyarthiplus.com
UNIT II - OO DESIGN
The Object Model
Object-oriented technology is built on a sound engineering foundation, whose elements we collectively call the object model of development or simply the object model. The object model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence. By themselves, none of these principles are new. What is important about the object model is that these elements are brought together in a synergistic way. Let there be no doubt that object-oriented analysis and design is funda- mentally different than traditional structured design approaches: It requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture.
Object modeling is an object-oriented analysis and design technique that became very fashionable in the 1990's. The goal of object modeling is to create a model comprising:
* a set of related object type definitions representing concepts from the 'real world' (problem domain) that are needed in the system.
* descriptions of how objects of those types interact with each other to form the functions of the system.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 41
Object-Oriented Programming
What, then, is object-oriented programming (OOP)? We define it as follows:
Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.
There are three important parts to this definition: (1) Object-oriented program- ming uses objects, not algorithms, as its fundamental logical building blocks (the “part of” hierarchy we introduced in Chapter 1); (2) each object is an instance of some class; and (3) classes may be related to one another via inheritance relation- ships (the “is a” hierarchy we spoke of in Chapter 1). A program may appear to be object-oriented, but if any of these elements is missing, it is not an object-oriented program. Specifically, programming without inheritance is distinctly not object- oriented; that would merely be programming with abstract data types.
By this definition, some languages are object-oriented, and some are not. Strous- trup suggests that “if the term ‘object-oriented language’ means anything, it must mean a language that has mechanisms that support the object-oriented style of programming well. . . . A language supports a programming style well if it pro- vides facilities that make it convenient to use that style. A language does not sup- port a technique if it takes exceptional effort or skill to write such programs; in that case, the language merely enables programmers to use the techniques” [33]. From a theoretical perspective, one can fake object-oriented programming in non- object-oriented programming languages like Pascal and even COBOL or assem- bly language, but it is horribly ungainly to do so. Cardelli and Wegner thus say:
[A] language is object-oriented if and only if it satisfies the following requirements: ■ It supports objects that are data abstractions with an interface of named operations and a hidden local state. ■ Objects have an associated type [class]. ■ Types [classes] may inherit attributes from supertypes [superclasses]. [34]
For a language to support inheritance means that it is possible to express “is a” relationships among types, for example, a red rose is a kind of flower, and a flower is a kind of plant. If a language does not provide direct support for inherit- ance, then it is not object-oriented. Cardelli and Wegner distinguish such lan- guages by calling them object-based rather than object-oriented. Under this definition, Smalltalk, Object Pascal, C++, Eiffel, CLOS, C#, and Java are all object-oriented, and Ada83 is object-based (support for object orientation was later added to Ada95). However, since objects and classes are elements of both
www.Vidyarthiplus.com www.Vidyarthiplus.com
42 SECTION ICONCEPTS
kinds of languages, it is both possible and highly desirable for us to use object- oriented design methods for both object-based and object-oriented programming languages.
Object-Oriented Design
The emphasis in programming methods is primarily on the proper and effective use of particular language mechanisms. By contrast, design methods emphasize the proper and effective structuring of a complex system. What, then, is object- oriented design (OOD)? We suggest the following:
Object-oriented design is a method of design encompassing the process of object- oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design.
There are two important parts to this definition: object-oriented design (1) leads to an object-oriented decomposition and (2) uses different notations to express different models of the logical (class and object structure) and physical (module and process architecture) design of a system, in addition to the static and dynamic aspects of the system.
The support for object-oriented decomposition is what makes object-oriented design quite different from structured design: The former uses class and object abstractions to logically structure systems, and the latter uses algorithmic abstrac- tions. We will use the term object-oriented design to refer to any method that leads to an object-oriented decomposition.
Object-Oriented Analysis
The object model has influenced even earlier phases of the software development lifecycle. Traditional structured analysis techniques, best typified by the work of DeMarco [35], Yourdon [36], and Gane and Sarson [37], with real-time exten- sions by Ward and Mellor [38] and by Hatley and Pirbhai [39], focus on the flow of data within a system. Object-oriented analysis (OOA) emphasizes the building of real-world models, using an object-oriented view of the world:
Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.
How are OOA, OOD, and OOP related? Basically, the products of object-oriented analysis serve as the models from which we may start an object-oriented design;
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 43
the products of object-oriented design can then be used as blueprints for com- pletely implementing a system using object-oriented programming methods.
2.3 Elements of the Object Model
Jenkins and Glasgow observe that “most programmers work in one language and use only one programming style. They program in a paradigm enforced by the language they use. Frequently, they have not been exposed to alternate ways of thinking about a problem, and hence have difficulty in seeing the advantage of choosing a style more appropriate to the problem at hand” [40]. Bobrow and Stefik define a programming style as “a way of organizing programs on the basis of some conceptual model of programming and an appropriate language to make programs written in the style clear” [41]. They further suggest that there are five main kinds of programming styles, listed here with the kinds of abstractions they employ:
1. Procedure-oriented Algorithms 2. Object-oriented Classes and objects 3. Logic-oriented Goals, often expressed in a predicate calculus 4. Rule-oriented If–then rules 5. Constraint-oriented Invariant relationships
There is no single programming style that is best for all kinds of applications. For example, rule-oriented programming would be best suited for the design of a knowledge base, and procedure-oriented programming would be best for the design of computation-intense operations. From our experience, the object-oriented style is best suited to the broadest set of applications; indeed, this programming paradigm often serves as the architectural framework in which we employ other paradigms.
Each of these styles of programming is based on its own conceptual framework. Each requires a different mindset, a different way of thinking about the problem. For all things object-oriented, the conceptual framework is the object model. There are four major elements of this model:
1. Abstraction 2. Encapsulation 3. Modularity 4. Hierarchy
By major, we mean that a model without any one of these elements is not object- oriented. www.Vidyarthiplus.com www.Vidyarthiplus.com
44 SECTION ICONCEPTS
There are three minor elements of the object model:
1. Typing 2. Concurrency 3. Persistence
By minor, we mean that each of these elements is a useful, but not essential, part of the object model.
Without this conceptual framework, you may be programming in a language such as Smalltalk, Object Pascal, C++, Eiffel, or Ada, but your design is going to smell like a FORTRAN, Pascal, or C application. You will have missed out on or other- wise abused the expressive power of the object-oriented language you are using for implementation. More importantly, you are not likely to have mastered the complexity of the problem at hand.
The Meaning of Abstraction
Abstraction is one of the fundamental ways that we as humans cope with com- plexity. Dahl, Dijkstra, and Hoare suggest that “abstraction arises from a recogni- tion of similarities between certain objects, situations, or processes in the real world, and the decision to concentrate upon these similarities and to ignore for the time being the differences” [42]. Shaw defines an abstraction as “a simplified description, or specification, of a system that emphasizes some of the system’s details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment, immaterial or diversionary” [43]. Berzins, Gray, and Naumann recommend that “a concept qualifies as an abstraction only if it can be described, understood, and analyzed independently of the mechanism that will eventually be used to realize it” [44]. Combining these different viewpoints, we define an abstraction as follows:
An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.
An abstraction focuses on the outside view of an object and so serves to separate an object’s essential behavior from its implementation. Abelson and Sussman call this behavior/implementation division an abstraction barrier [45] achieved by applying the principle of least commitment, through which the interface of an object provides its essential behavior, and nothing more [46]. We like to use an additional principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction. www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 45
Abstraction focuses on the essential characteristics of some object, relative to the perspective of the viewer.
Deciding on the right set of abstractions for a given domain is the central problem in object-oriented design. Because this topic is so important, the whole of Chapter 4 is devoted to it.
“There is a spectrum of abstraction, from objects which closely model problem domain entities to objects which really have no reason for existence” [47]. From the most to the least useful, these kinds of abstractions include the following:
■ Entity abstraction An object that represents a useful model of a problem domain or solution domain entity ■ Action abstraction An object that provides a generalized set of operations, all of which perform the same kind of function ■ Virtual machine abstraction An object that groups operations that are all used by some superior level of control, or operations that all use some junior-level set of operations ■ Coincidental abstraction An object that packages a set of operations that have no relation to each other
www.Vidyarthiplus.com www.Vidyarthiplus.com
46 SECTION ICONCEPTS
We strive to build entity abstractions because they directly parallel the vocabulary of a given problem domain.
A client is any object that uses the resources of another object (known as the server). We can characterize the behavior of an object by considering the services that it provides to other objects, as well as the operations that it may perform on other objects. This view forces us to concentrate on the outside view of an object and leads us to what Meyer calls the contract model of programming [48]: the outside view of each object defines a contract on which other objects may depend, and which in turn must be carried out by the inside view of the object itself (often in collaboration with other objects). This contract thus establishes all the assump- tions a client object may make about the behavior of a server object. In other words, this contract encompasses the responsibilities of an object, namely, the behavior for which it is held accountable [49].
Individually, each operation that contributes to this contract has a unique signa- ture comprising all of its formal arguments and return type. We call the entire set of operations that a client may perform on an object, together with the legal order- ings in which they may be invoked, its protocol. A protocol denotes the ways in which an object may act and react and thus constitutes the entire static and dynamic outside view of the abstraction.
Central to the idea of an abstraction is the concept of invariance. An invariant is some Boolean (true or false) condition whose truth must be preserved. For each operation associated with an object, we may define preconditions (invariants assumed by the operation) as well as postconditions (invariants satisfied by the operation). Violating an invariant breaks the contract associated with an abstrac- tion. If a precondition is violated, this means that a client has not satisfied its part of the bargain, and hence the server cannot proceed reliably. Similarly, if a post- condition is violated, this means that a server has not carried out its part of the contract, and so its clients can no longer trust the behavior of the server. An exception is an indication that some invariant has not been or cannot be satisfied. Certain languages permit objects to throw exceptions so as to abandon processing and alert some other object to the problem, which in turn may catch the exception and handle the problem.
As an aside, the terms operation, method, and member function evolved from three different programming cultures (Ada, Smalltalk, and C++, respectively). They all mean virtually the same thing, so we will use them interchangeably.
All abstractions have static as well as dynamic properties. For example, a file object takes up a certain amount of space on a particular memory device; it has a name, and it has contents. These are all static properties. The value of each of these properties is dynamic, relative to the lifetime of the object: A file object may grow or shrink in size, its name may change, its contents may change. In a
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 47 procedure-oriented style of programming, the activity that changes the dynamic value of objects is the central part of all programs; things happen when subpro- grams are called and statements are executed. In a rule-oriented style of program- ming, things happen when new events cause rules to fire, which in turn may trigger other rules, and so on. In an object-oriented style of programming, things happen whenever we operate on an object (i.e., when we send a message to an object). Thus, invoking an operation on an object elicits some reaction from the object. What operations we can meaningfully perform on an object and how that object reacts constitute the entire behavior of the object.
Examples of Abstraction
Let’s illustrate these concepts with some examples. We defer a complete treat- ment of how to find the right abstractions for a given problem to Chapter 4.
On a hydroponics farm, plants are grown in a nutrient solution, without sand, gravel, or other soils. Maintaining the proper greenhouse environment is a deli- cate job and depends on the kind of plant being grown and its age. One must control diverse factors such as temperature, humidity, light, pH, and nutrient con- centrations. On a large farm, it is not unusual to have an automated system that constantly monitors and adjusts these elements. Simply stated, the purpose of an automated gardener is to efficiently carry out, with minimal human intervention, growing plans for the healthy production of multiple crops.
One of the key abstractions in this problem is that of a sensor. Actually, there are several different kinds of sensors. Anything that affects production must be mea- sured, so we must have sensors for air and water temperature, humidity, light, pH, and nutrient concentrations, among other things. Viewed from the outside, a tem- perature sensor is simply an object that knows how to measure the temperature at some specific location. What is a temperature? It is some numeric value, within a limited range of values and with a certain precision, that represents degrees in the scale of Fahrenheit, Centigrade, or Kelvin, whichever is most appropriate for our problem. What is a location? It is some identifiable place on the farm at which we desire to measure the temperature; presumably, there are only a few such loca- tions. What is important for a temperature sensor is not so much where it is located but the fact that it has a location and identity unique from all other tem- perature sensors. Now we are ready to ask: What are the responsibilities of a tem- perature sensor? Our design decision is that a sensor is responsible for knowing the temperature at a given location and reporting that temperature when asked. More concretely, what operations can a client perform on a temperature sensor? Our design decision is that a client can calibrate it, as well as ask what the current temperature is. (See Figure 2–6. Note that this representation is similar to the rep- resentation of a class in UML 2.0. You will learn the actual representation in Chapter 5.)
www.Vidyarthiplus.com www.Vidyarthiplus.com
48 SECTION ICONCEPTS
Abstraction: Temperature Sensor Important Characteristics: temperature location Responsibilities: report current temperature calibrate
Figure 2–6 Abstraction of a Temperature Sensor
The abstraction we have described thus far is passive; some client object must operate on an air Temperature Sensor object to determine its current tem- perature. However, there is another legitimate abstraction that may be more or less appropriate depending on the broader system design decisions we might make. Specifically, rather than the Temperature Sensor being passive, we might make it active, so that it is not acted on but rather acts on other objects whenever the temperature at its location changes a certain number of degrees from a given setpoint. This abstraction is almost the same as our first one, except that its responsibilities have changed slightly: A sensor is now responsible for reporting the current temperature when it changes, not just when asked. What new operations must this abstraction provide?
This abstraction is a bit more complicated than the first (see Figure 2–7). A client of this abstraction may invoke an operation to establish a critical range of temper- atures. It is then the responsibility of the sensor to report whenever the tempera- ture at its location drops below or rises above the given setpoint. When the function is invoked, the sensor provides its location and the current temperature, so that the client has sufficient information to respond to the condition.
Abstraction: Active Temperature Sensor Important Characteristics: temperature location setpoint Responsibilities: report current temperature calibrate establish setpoint
Figure 2–7 Abstraction of an Active Temperature Sensor
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 49
How the Active Temperature Sensor carries out its responsibilities is a function of its inside view and is of no concern to outside clients. These then are the secrets of the class, which are implemented by the class’s private parts together with the definition of its member functions.
Let’s consider a different abstraction. For each crop, there must be a growing plan that describes how temperature, light, nutrients, and other conditions should change over time to maximize the harvest. A growing plan is a legitimate entity abstrac- tion because it forms part of the vocabulary of the problem domain. Each crop has its own growing plan, but the growing plans for all crops take the same form.
A growing plan is responsible for keeping track of all interesting actions associ- ated with growing a crop, correlated with the times at which those actions should take place. For example, on day 15 in the lifetime of a certain crop, our growing plan might be to maintain a temperature of 78°F for 16 hours, turn on the lights for 14 of these hours, and then drop the temperature to 65°F for the rest of the day. We might also want to add certain extra nutrients in the middle of the day, while still maintaining a slightly acidic pH. From the perspective outside of each growing-plan object, a client must be able to establish the details of a plan, modify a plan, and inquire about a plan, as shown in Figure 2–8. (Note that abstractions are likely to evolve over the lifetime of a project. As details begin to be fleshed out, a responsibility such as “establish plan” could turn into multiple responsibilities, such as “set temperature,” “set pH,” and so forth. This is to be expected as more knowledge of client requirements is gained, designs mature, and implementation approaches are considered.)
Our decision is also that we will not require a growing plan to carry out its plan: We will leave this as the responsibility of a different abstraction (e.g., a Plan Controller). In this manner, we create a clear separation of concerns among the logically different parts of the system, so as to reduce the conceptual size of each individual abstraction. For example, there might be an object that sits at the
Abstraction: Growing Plan Important Characteristics: name Responsibilities: establish plan modify plan clear plan Related Candidate Abstractions: Crop, Conditions, Plan Controller Figure 2–8 Abstraction of a Growing Plan
www.Vidyarthiplus.com www.Vidyarthiplus.com
50 SECTION ICONCEPTS
boundary of the human/machine interface and translates human input into plans. This is the object that establishes the details of a growing plan, so it must be able to change the state of a Growing Plan object. There must also be an object that carries out the growing plan, and it must be able to read the details of a plan for a particular time.
As this example points out, no object stands alone; every object collaborates with other objects to achieve some behavior.1 Our design decisions about how these objects cooperate with one another define the boundaries of each abstraction and thus the responsibilities and protocol of each object.
Objects collaborate with other objects to achieve some behavior.
The Meaning of Encapsulation
Although we earlier described our abstraction of the Growing Plan as a time/ action mapping, its implementation is not necessarily a literal table or map data structure. Indeed, whichever representation is chosen is immaterial to the client’s contract with the Growing Plan, as long as that representation upholds the contract. Simply stated, the abstraction of an object should precede the decisions about its implementation. Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients.
1. Stated another way, with apologies to the poet John Donne, no object is an island (al- though an island may be abstracted as an object). www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 51
Encapsulation hides the details of the implementation of an object.
Abstraction and encapsulation are complementary concepts: Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior. Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential charac- teristics; typically, the structure of an object is hidden, as well as the implementa- tion of its methods. “No part of a complex system should depend on the internal details of any other part” [50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort” [51].
Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. For example, consider again the structure of a plant. To understand how photosynthesis works at a high level of abstraction, we can ignore details such as the responsibilities of plant roots or the chemistry of cell walls. Similarly, in designing a database application, it is standard practice to write programs so that they don’t care about the physical representation of data but depend only on a schema that denotes the data’s logical view [52]. In both of these cases, objects at one level of abstraction are shielded from implementation details at lower levels of abstraction.
“For abstraction to work, implementations must be encapsulated” [53]. In prac- tice, this means that each class must have two parts: an interface and an imple- mentation. The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class. The imple- mentation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions.
www.Vidyarthiplus.com www.Vidyarthiplus.com
52 SECTION ICONCEPTS
To summarize, we define encapsulation as follows:
Encapsulation is the process of compartmentalizing the elements of an abstrac- tion that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.
Britton and Parnas call these encapsulated elements the “secrets” of an abstrac- tion [54].
Examples of Encapsulation
To illustrate the principle of encapsulation, let’s return to the problem of the Hydroponics Gardening System. Another key abstraction in this problem domain is that of a heater. A heater is at a fairly low level of abstraction, and thus we might decide that there are only three meaningful operations that we can perform on this object: turn it on, turn it off, and find out if it is running.
Separation of Concerns
We do not make it a responsibility of the Heater abstraction to maintain a fixed temperature. Instead, we choose to give this responsibility to another object (e.g., the Heater Controller), which must collaborate with a temperature sensor and a heater to achieve this higher-level behavior. We call this behavior higher-level because it builds on the primitive semantics of temperature sensors and heaters and adds some new semantics, namely, hysteresis, which prevents the heater from being turned on and off too rapidly when the temperature is near boundary conditions. By deciding on this separation of responsibilities, we make each individual abstraction more cohesive.
All a client needs to know about the class Heater is its available interface (i.e., the responsibilities that it may execute at the client’s request—see Figure 2–9).
Turning to the inside view of the Heater, we have an entirely different perspec- tive. Suppose that our system engineers have decided to locate the computers that control each greenhouse away from the building (perhaps to avoid the harsh envi- ronment) and to connect each computer to its sensors and actuators via serial lines. One reasonable implementation for the Heater class might be to use an electromechanical relay that controls the power going to each physical heater, with the relays in turn commanded by messages sent along these serial lines. For example, to turn on a heater, we might transmit a special command string, fol- lowed by a number identifying the specific heater, followed by another number used to signal turning the heater on.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 53
Abstraction: Heater Important Characteristics: location status Responsibilities: turn on turn off provide status Related Candidate Abstractions: Heater Controller, Temperature Sensor Figure 2–9 Abstraction of a Heater
Suppose that for whatever reason our system engineers choose to use memory- mapped I/O instead of serial communication lines. We would not need to change the interface of the Heater, yet the implementation would be very different. The client would not see any change at all as the client sees only the Heater inter- face. This is the key point of encapsulation. In fact, the client should not care what the implementation is, as long as it receives the service it needs from the Heater.
Let’s next consider the implementation of the class GrowingPlan. As we men- tioned earlier, a growing plan is essentially a time/action mapping. Perhaps the most reasonable representation for this abstraction would be a dictionary of time/ action pairs, using an open hash table. We need not store an action for every hour, because things don’t change that quickly. Rather, we can store actions only for when they change, and have the implementation extrapolate between times.
In this manner, our implementation encapsulates two secrets: the use of an open hash table (which is distinctly a part of the vocabulary of the solution domain, not the problem domain) and the use of extrapolation to reduce our storage require- ments (otherwise we would have to store many more time/action pairs over the duration of a growing season). No client of this abstraction need ever know about these implementation decisions because they do not materially affect the out- wardly observable behavior of the class.
Intelligent encapsulation localizes design decisions that are likely to change. As a system evolves, its developers might discover that, in actual use, certain opera- tions take longer than is acceptable or that some objects consume more space than is available. In such situations, the representation of an object is often changed so that more efficient algorithms can be applied or so that one can optimize for space by calculating rather than storing certain data. This ability to change the represen- tation of an abstraction without disturbing any of its clients is the essential benefit of encapsulation.
www.Vidyarthiplus.com www.Vidyarthiplus.com
54 SECTION ICONCEPTS
Hiding is a relative concept: What is hidden at one level of abstraction may repre- sent the outside view at another level of abstraction. The underlying representa- tion of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity. Thus, encapsulation cannot stop a developer from doing stupid things; as Stroustrup points out, “Hiding is for the prevention of accidents, not the prevention of fraud” [56]. Of course, no pro- gramming language prevents a human from literally seeing the implementation of a class, although an operating system might deny access to a particular file that contains the implementation of a class.
The Meaning of Modularity
“The act of partitioning a program into individual components can reduce its complexity to some degree. . . . Although partitioning a program is helpful for this reason, a more powerful justification for partitioning a program is that it creates a number of well-defined, documented boundaries within the program. These boundaries, or interfaces, are invaluable in the comprehension of the program” [57]. In some languages, such as Smalltalk, there is no concept of a module, so the class forms the only physical unit of decomposition. Java has packages that contain classes. In many other languages, including Object Pascal, C++, and Ada, the module is a separate language construct and therefore warrants a separate set of design decisions. In these languages, classes and objects form the logical structure of a system; we place these abstractions in modules to produce the system’s phys- ical architecture. Especially for larger applications, in which we may have many hundreds of classes, the use of modules is essential to help manage complexity.
Modularity packages abstractions into discrete units.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 55
“Modularization consists of dividing a program into modules which can be com- piled separately, but which have connections with other modules. We will use the definition of Parnas: ‘The connections between modules are the assumptions which the modules make about each other’” [58]. Most languages that support the module as a separate concept also distinguish between the interface of a module and its implementation. Thus, it is fair to say that modularity and encapsulation go hand in hand.
Deciding on the right set of modules for a given problem is almost as hard a prob- lem as deciding on the right set of abstractions. Zelkowitz is absolutely right when he states that “because the solution may not be known when the design stage starts, decomposition into smaller modules may be quite difficult. For older applications (such as compiler writing), this process may become standard, but for new ones (such as defense systems or spacecraft control), it may be quite dif- ficult” [59].
Modules serve as the physical containers in which we declare the classes and objects of our logical design. This is no different than the situation faced by the electrical engineer designing a computer motherboard. NAND, NOR, and NOT gates might be used to construct the necessary logic, but these gates must be physically packaged in standard integrated circuits. Lacking any such standard software parts, the software engineer has considerably more degrees of freedom— as if the electrical engineer had a silicon foundry at his or her disposal.
For tiny problems, the developer might decide to declare every class and object in the same package. For anything but the most trivial software, a better solution is to group logically related classes and objects in the same module and to expose only those elements that other modules absolutely must see. This kind of modu- larization is a good thing, but it can be taken to extremes. For example, consider an application that runs on a distributed set of processors and uses a message- passing mechanism to coordinate the activities of different programs. In a large system, such as a command and control system, it is common to have several hun- dred or even a few thousand kinds of messages. A naive strategy might be to define each message class in its own module. As it turns out, this is a singularly poor design decision. Not only does it create a documentation nightmare, but it makes it terribly difficult for any users to find the classes they need. Furthermore, when decisions change, hundreds of modules must be modified or recompiled. This example shows how information hiding can backfire [60]. Arbitrary modu- larization is sometimes worse than no modularization at all.
In traditional structured design, modularization is primarily concerned with the meaningful grouping of subprograms, using the criteria of coupling and cohesion. In object-oriented design, the problem is subtly different: The task is to decide where to physically package the classes and objects, which are distinctly different from subprograms.
www.Vidyarthiplus.com www.Vidyarthiplus.com
56 SECTION ICONCEPTS
Our experience indicates that there are several useful technical as well as non- technical guidelines that can help us achieve an intelligent modularization of classes and objects. As Britton and Parnas have observed, “The overall goal of the decomposition into modules is the reduction of software cost by allowing mod- ules to be designed and revised independently. . . . Each module’s structure should be simple enough that it can be understood fully; it should be possible to change the implementation of other modules without knowledge of the implementation of other modules and without affecting the behavior of other modules; [and] the ease of making a change in the design should bear a reasonable relationship to the likelihood of the change being needed” [61]. There is a pragmatic edge to these guidelines. In practice, the cost of recompiling the body of a module is relatively small: Only that unit need be recompiled and the application relinked. However, the cost of recompiling the interface of a module is relatively high. Especially with strongly typed languages, one must recompile the module interface, its body, all other modules that depend on this interface, the modules that depend on these modules, and so on. Thus, for very large programs (assuming that our develop- ment environment does not support incremental compilation), a change in a single module interface might result in much longer compilation time. Obviously, a development manager cannot often afford to allow a massive “big bang” recompi- lation to happen too frequently. For this reason, a module’s interface should be as narrow as possible, yet still satisfy the needs of the other modules that use it. Our style is to hide as much as we can in the implementation of a module. Incremen- tally shifting declarations from a module’s implementation to its interface is far less painful and destabilizing than ripping out extraneous interface code.
The developer must therefore balance two competing technical concerns: the desire to encapsulate abstractions and the need to make certain abstractions visi- ble to other modules. “System details that are likely to change independently should be the secrets of separate modules; the only assumptions that should appear between modules are those that are considered unlikely to change. Every data structure is private to one module; it may be directly accessed by one or more programs within the module but not by programs outside the module. Any other program that requires information stored in a module’s data structures must obtain it by calling module programs” [62]. In other words, strive to build mod- ules that are cohesive (by grouping logically related abstractions) and loosely coupled (by minimizing the dependencies among modules). From this perspec- tive, we may define modularity as follows:
Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.
Thus, the principles of abstraction, encapsulation, and modularity are synergistic. An object provides a crisp boundary around a single abstraction, and both encap- sulation and modularity provide barriers around this abstraction.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 57
Two additional technical issues can affect modularization decisions. First, since modules usually serve as the elementary and indivisible units of software that can be reused across applications, a developer might choose to package classes and objects into modules in a way that makes their reuse convenient. Second, many compilers generate object code in segments, one for each module. Therefore, there may be practical limits on the size of individual modules. With regard to the dynamics of subprogram calls, the placement of declarations within modules can greatly affect the locality of reference and thus the paging behavior of a virtual memory system. Poor locality happens when subprogram calls occur across seg- ments and lead to cache misses and page thrashing that ultimately slow down the whole system.
Several competing nontechnical needs may also affect modularization decisions. Typically, work assignments in a development team are given on a module-by- module basis, so the boundaries of modules may be established to minimize the interfaces among different parts of the development organization. Senior design- ers are usually given responsibility for module interfaces, and more junior devel- opers complete their implementation. On a larger scale, the same situation applies with subcontractor relationships. Abstractions may be packaged so as to quickly stabilize the module interfaces as agreed upon among the various companies. Changing such interfaces usually involves much wailing and gnashing of teeth— not to mention a vast amount of paperwork—so this factor often leads to conser- vatively designed interfaces. Speaking of paperwork, modules also usually serve as the unit of documentation and configuration management. Having ten modules where one would do sometimes means ten times the paperwork, and so, unfortu- nately, sometimes the documentation requirements drive the module design deci- sions (usually in the most negative way). Security may also be an issue. Most code may be considered unclassified, but other code that might be classified secret or higher is best placed in separate modules.
Juggling these different requirements is difficult, but don’t lose sight of the most important point: Finding the right classes and objects and then organizing them into separate modules are largely independent design decisions. The identification of classes and objects is part of the logical design of the system, but the identifica- tion of modules is part of the system’s physical design. One cannot make all the logical design decisions before making all the physical ones, or vice versa; rather, these design decisions happen iteratively.
Examples of Modularity
Let’s look at modularity in the Hydroponics Gardening System. Suppose we decide to use a commercially available workstation where the user can control the system’s operation. At this workstation, an operator could create new growing plans, modify old ones, and follow the progress of currently active ones. Since one
www.Vidyarthiplus.com www.Vidyarthiplus.com
58 SECTION ICONCEPTS
of our key abstractions here is that of a growing plan, we might therefore create a module whose purpose is to collect all of the classes associated with individual growing plans (e.g., FruitGrowingPlan, GrainGrowingPlan). The implementations of these GrowingPlan classes would appear in the implemen- tation of this module. We might also define a module whose purpose is to collect all of the code associated with all user interface functions.
Our design will probably include many other modules. Ultimately, we must define some main program from which we can invoke this application. In object- oriented design, defining this main program is often the least important decision, whereas in traditional structured design, the main program serves as the root, the keystone that holds everything else together. We suggest that the object-oriented view is more natural, for, as Meyer observes, “Practical software systems are more appropriately described as offering a number of services. Defining these systems by single functions is usually possible, but yields rather artificial answers. . . . Real systems have no top” [63].
The Meaning of Hierarchy
Abstraction is a good thing, but in all except the most trivial applications, we may find many more different abstractions than we can comprehend at one time. Encapsulation helps manage this complexity by hiding the inside view of our abstractions. Modularity helps also, by giving us a way to cluster logically related abstractions. Still, this is not enough. A set of abstractions often forms a hierar- chy, and by identifying these hierarchies in our design, we greatly simplify our understanding of the problem.
We define hierarchy as follows:
Hierarchy is a ranking or ordering of abstractions.
The two most important hierarchies in a complex system are its class structure (the “is a” hierarchy) and its object structure (the “part of” hierarchy).
Examples of Hierarchy: Single Inheritance
Inheritance is the most important “is a” hierarchy, and as we noted earlier, it is an essential element of object-oriented systems. Basically, inheritance defines a rela- tionship among classes, wherein one class shares the structure or behavior defined in one or more classes (denoting single inheritance and multiple inheritance, respectively). Inheritance thus represents a hierarchy of abstractions, in which a subclass inherits from one or more superclasses. Typically, a subclass augments or redefines the existing structure and behavior of its superclasses.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 59
Abstractions form a hierarchy.
Semantically, inheritance denotes an “is a” relationship. For example, a bear “is a” kind of mammal, a house “is a” kind of tangible asset, and a quick sort “is a” particular kind of sorting algorithm. Inheritance thus implies a generalization/ specialization hierarchy, wherein a subclass specializes the more general structure or behavior of its superclasses. Indeed, this is the litmus test for inheritance: If B is not a kind of A, then B should not inherit from A.
Consider the different kinds of growing plans we might use in the Hydroponics Gardening System. An earlier section described our abstraction of a very general- ized growing plan. Different kinds of crops, however, demand specialized grow- ing plans. For example, the growing plan for all fruits is generally the same but is quite different from the plan for all vegetables, or for all floral crops. Because of this clustering of abstractions, it is reasonable to define a standard fruit- growing plan that encapsulates the behavior common to all fruits, such as the knowledge of when to pollinate or when to harvest the fruit. We can assert that FruitGrowingPlan “is a” kind of GrowingPlan. www.Vidyarthiplus.com www.Vidyarthiplus.com
60 SECTION ICONCEPTS
In this case, FruitGrowingPlan is more specialized, and GrowingPlan is more general. The same could be said for GrainGrowingPlan or VegetableGrowingPlan, that is, GrainGrowingPlan “is a” kind of GrowingPlan, and VegetableGrowingPlan “is a” kind of GrowingPlan. Here, GrowingPlan is the more general superclass, and the others are special- ized subclasses.
As we evolve our inheritance hierarchy, the structure and behavior that are com- mon for different classes will tend to migrate to common superclasses. This is why we often speak of inheritance as being a generalization/specialization hierar- chy. Superclasses represent generalized abstractions, and subclasses represent specializations in which fields and methods from the superclass are added, modi- fied, or even hidden. In this manner, inheritance lets us state our abstractions with an economy of expression. Indeed, neglecting the “is a” hierarchies that exist can lead to bloated, inelegant designs. “Without inheritance, every class would be a free-standing unit, each developed from the ground up. Different classes would bear no relationship with one another, since the developer of each provides meth- ods in whatever manner he chooses. Any consistency across classes is the result of discipline on the part of the programmers. Inheritance makes it possible to define new software in the same way we introduce any concept to a newcomer, by comparing it with something that is already familiar” [64].
There is a healthy tension among the principles of abstraction, encapsulation, and hierarchy. “Data abstraction attempts to provide an opaque barrier behind which methods and state are hidden; inheritance requires opening this interface to some extent and may allow state as well as methods to be accessed without abstraction” [65]. For a given class, there are usually two kinds of clients: objects that invoke operations on instances of the class and subclasses that inherit from the class. Liskov therefore notes that, with inheritance, encapsulation can be violated in one of three ways: “The subclass might access an instance variable of its superclass, call a private operation of its superclass, or refer directly to superclasses of its superclass” [66]. Different programming languages trade off support for encapsu- lation and inheritance in different ways. C++ and Java offer great flexibility. Specifically, the interface of a class may have three parts: private parts, which declare members that are accessible only to the class itself; protected parts, which declare members that are accessible only to the class and its subclasses; and pub- lic parts, which are accessible to all clients.
Examples of Hierarchy: Multiple Inheritance
The previous example illustrated the use of single inheritance: the subclass FruitGrowingPlan had exactly one superclass, the class GrowingPlan. For certain abstractions, it is useful to provide inheritance from multiple superclasses.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 61
For example, suppose that we choose to define a class representing a kind of plant. Our analysis of the problem domain might suggest that flowering plants and fruits and vegetables have specialized properties that are relevant to our appli- cation. For example, given a flowering plant, its expected time to flower and time to seed might be important to us. Similarly, the time to harvest might be an impor- tant part of our abstraction of all fruits and vegetables. One way we could capture our design decisions would be to make two new classes, a Flower class and a FruitVegetable class, both subclasses of the class Plant. However, what if we need to model a plant that both flowered and produced fruit? For example, florists commonly use blossoms from apple, cherry, and plum trees. For this abstraction, we would need to invent a third class, FlowerFruitVegetable, that duplicated information from the Flower and FruitVegetable classes.
A better way to express our abstractions and thereby avoid this redundancy is to use multiple inheritance. First, we invent classes that independently capture the properties unique to flowering plants and to fruits and vegetables. These two classes have no superclass; they stand alone. These are called mixin classes because they are meant to be mixed together with other classes to produce new subclasses.
For example, we can define a Rose class (see Figure 2–10) that inherits from both Plant and FlowerMixin. Instances of the subclass Rose thus include the structure and behavior from the class Plant together with the structure and behavior from the class FlowerMixin.
Similarly, a Carrot class could be as shown in Figure 2–11. In both cases, we form the subclass by inheriting from two superclasses.
Now, suppose we want to declare a class for a plant such as the cherry tree that has both flowers and fruit. This would be conceptualized as shown in Figure 2–12.
Figure 2–10 The Rose Class, Which Inherits from Multiple Superclasses
www.Vidyarthiplus.com www.Vidyarthiplus.com
62 SECTION ICONCEPTS
Figure 2–11 The Carrot Class, Which Inherits from Multiple Superclasses
Figure 2–12 The CherryTree Class, Which Inherits from Multiple Superclasses
Multiple inheritance is conceptually straightforward, but it does introduce some practical complexities for programming languages. Languages must address two issues: clashes among names from different superclasses and repeated inherit- ance. Clashes will occur when two or more superclasses provide a field or opera- tion with the same name or signature as a peer superclass.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 63
Figure 2–13 The Repeated Inheritance Problem
Repeated inheritance occurs when two or more peer superclasses share a common superclass. In such a situation, the inheritance lattice will be diamond-shaped, so the question arises, does the leaf class (i.e., subclass) have one copy or multiple copies of the structure of the shared superclass? (See Figure 2–13.) Some lan- guages prohibit repeated inheritance, some unilaterally choose one approach, and others, such as C++, permit the programmer to decide. In C++, virtual base classes are used to denote a sharing of repeated structures, whereas nonvirtual base classes result in duplicate copies appearing in the subclass (with explicit qualification required to distinguish among the copies).
Multiple inheritance is often overused. For example, cotton candy is a kind of candy, but it is distinctly not a kind of cotton. Again, the litmus test for inherit- ance applies: If B is not a kind of A, then B should not inherit from A. Ill-formed multiple inheritance lattices should be reduced to a single superclass plus aggre- gation of the other classes by the subclass, where possible.
Examples of Hierarchy: Aggregation
Whereas these “is a” hierarchies denote generalization/specialization relation- ships, “part of” hierarchies describe aggregation relationships. For example, con- sider the abstraction of a garden. We can contend that a garden consists of a collection of plants together with a growing plan. In other words, plants are “part of” the garden, and the growing plan is “part of” the garden. This “part of” rela- tionship is known as aggregation. www.Vidyarthiplus.com www.Vidyarthiplus.com
64 SECTION ICONCEPTS
Aggregation is not a concept unique to object-oriented development or object- oriented programming languages. Indeed, any language that supports record-like structures supports aggregation. However, the combination of inheritance with aggregation is powerful: Aggregation permits the physical grouping of logically related structures, and inheritance allows these common groups to be easily reused among different abstractions.
When dealing with hierarchies such as these, we often speak of levels of abstrac- tion, a concept first described by Dijkstra [67]. In terms of its “is a” hierarchy, a high-level abstraction is generalized, and a low-level abstraction is specialized. Therefore, we say that a Flower class is at a higher level of abstraction than a Plant class. In terms of its “part of” hierarchy, a class is at a higher level of abstraction than any of the classes that make up its implementation. Thus, the class Garden is at a higher level of abstraction than the type Plant, on which it builds.
Aggregation raises the issue of ownership. Our abstraction of a garden permits different plants to be raised in a garden over time, but replacing a plant does not change the identity of the garden as a whole, nor does removing a garden neces- sarily destroy all of its plants (they are likely just transplanted). In other words, the lifetime of a garden and its plants are independent. In contrast, we have decided that a GrowingPlan object is intrinsically associated with a Garden object and does not exist independently. Therefore, when we create an instance of Garden, we also create an instance of GrowingPlan; when we destroy the Garden object, we in turn destroy the GrowingPlan instance.
The Meaning of Typing
The concept of a type derives primarily from the theories of abstract data types. As Deutsch suggests, “A type is a precise characterization of structural or behav- ioral properties which a collection of entities all share” [68]. For our purposes, we will use the terms type and class interchangeably.2 Although the concepts of a type and a class are similar, we include typing as a separate element of the object
2. A type and a class are not exactly the same thing; some languages distinguish these two concepts. For example, early versions of the language Trellis/Owl permitted an object to have both a class and a type. In Smalltalk, objects of the classes SmallInteger, LargeNegativeInteger, and LargePositiveInteger are all of the same type, Integer, although not of the same class [69]. For most mortals, however, separat- ing the concepts of type and class is utterly confusing and adds very little value. It is suffi- cient to say that a class implements a type.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 65 model because the concept of a type places a very different emphasis on the meaning of abstraction. Specifically, we state the following:
Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways.
Typing lets us express our abstractions so that the programming language in which we implement them can be made to enforce design decisions.
A given programming language may be strongly typed, weakly typed, or even untyped, yet still be called object-oriented. For example, Eiffel is strongly typed, meaning that type conformance is strictly enforced: Operations cannot be called on an object unless the exact signature of that operation is defined in the object’s class or superclasses.
The idea of conformance is central to the notion of typing. For example, consider units of measurement in physics [71]. When we divide distance by time, we expect some value denoting speed, not weight. Similarly, dividing a unit of force by temperature doesn’t make sense, but dividing force by mass does. These are both examples of strong typing, wherein the rules of our domain prescribe and enforce certain legal combinations of abstractions.
Strong typing prevents mixing of abstractions.
www.Vidyarthiplus.com www.Vidyarthiplus.com
66 SECTION ICONCEPTS
Strong typing lets us use our programming language to enforce certain design decisions and so is particularly relevant as the complexity of our system grows. However, there is a dark side to strong typing. Practically, strong typing intro- duces semantic dependencies such that even small changes in the interface of a base class require recompilation of all subclasses.
There are two general solutions to these problems. First, we could use a type-safe container class that manipulates only objects of a specific class. This approach addresses the first problem, wherein objects of different types are incorrectly min- gled. Second, we could use some form of runtime type identification; this addresses the second problem of knowing what kind of object you happen to be examining at the moment. In general, however, runtime type identification should be used only when there is a compelling reason because it can represent a weakening of encapsulation. As we will discuss in the next section, the use of polymorphic operations can often (but not always) mitigate the need for runtime type identification.
As Tesler points out, there are a number of important benefits to be derived from using strongly typed languages:
■ Without type checking, a program in most languages can ‘crash’ in mysterious ways at runtime. ■ In most systems, the edit-compile-debug cycle is so tedious that early error detection is indispensable. ■ Type declarations help to document programs. ■ Most compilers can generate more efficient object code if types are declared. [72]
Untyped languages offer greater flexibility, but even with untyped languages, as Borning and Ingalls observe, “In almost all cases, the programmer in fact knows what sorts of objects are expected as the arguments of a message, and what sort of object will be returned” [73]. In practice, the safety offered by strongly typed lan- guages usually more than compensates for the flexibility lost by not using an untyped language, especially for programming-in-the-large.
Examples of Typing: Static and Dynamic Typing
The concepts of strong and weak typing and static and dynamic typing are entirely different. Strong and weak typing refers to type consistency, whereas static and dynamic typing refers to the time when names are bound to types. Static typing (also known as static binding or early binding) means that the types of all variables and expressions are fixed at the time of compilation; dynamic typing (also known as late binding) means that the types of all variables and expressions are not known until runtime. A language may be both strongly and statically typed (Ada), strongly typed yet supportive of dynamic typing (C++, Java), or untyped yet supportive of dynamic typing (Smalltalk). www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 67
Polymorphism is a condition that exists when the features of dynamic typing and inheritance interact. Polymorphism represents a concept in type theory in which a single name (such as a variable declaration) may denote objects of many different classes that are related by some common superclass. Any object denoted by this name is therefore able to respond to some common set of operations [74]. The opposite of polymorphism is monomorphism, which is found in all languages that are both strongly and statically typed.
Polymorphism is perhaps the most powerful feature of object-oriented program- ming languages next to their support for abstraction, and it is what distinguishes object-oriented programming from more traditional programming with abstract data types. As we will see in the following chapters, polymorphism is also a cen- tral concept in object-oriented design.
The Meaning of Concurrency
For certain kinds of problems, an automated system may have to handle many dif- ferent events simultaneously. Other problems may involve so much computation that they exceed the capacity of any single processor. In each of these cases, it is natural to consider using a distributed set of computers for the target implementa- tion or to use multitasking. A single process is the root from which independent dynamic action occurs within a system. Every program has at least one thread of control, but a system involving concurrency may have many such threads: some that are transitory and others that last the entire lifetime of the system’s execution. Systems executing across multiple CPUs allow for truly concurrent threads of
Concurrency allows different objects to act at the same time.
www.Vidyarthiplus.com www.Vidyarthiplus.com
68 SECTION ICONCEPTS
control, whereas systems running on a single CPU can only achieve the illusion of concurrent threads of control, usually by means of some time-slicing algorithm.
We also distinguish between heavyweight and lightweight concurrency. A heavy- weight process is one that is typically independently managed by the target oper- ating system and so encompasses its own address space. A lightweight process usually lives within a single operating system process along with other light- weight processes, which share the same address space. Communication among heavyweight processes is generally expensive, involving some form of interpro- cess communication; communication among lightweight processes is less expen- sive and often involves shared data.
Building a large piece of software is hard enough; designing one that encom- passes multiple threads of control is much harder because one must worry about such issues as deadlock, livelock, starvation, mutual exclusion, and race condi- tions. “At the highest levels of abstraction, OOP can alleviate the concurrency problem for the majority of programmers by hiding the concurrency inside reus- able abstractions” [76]. Black et al. therefore suggest that “an object model is appropriate for a distributed system because it implicitly defines (1) the units of distribution and movement and (2) the entities that communicate” [77].
Whereas object-oriented programming focuses on data abstraction, encapsulation, and inheritance, concurrency focuses on process abstraction and synchronization [78]. The object is a concept that unifies these two different viewpoints: Each object (drawn from an abstraction of the real world) may represent a separate thread of control (a process abstraction). Such objects are called active. In a sys- tem based on an object-oriented design, we can conceptualize the world as con- sisting of a set of cooperative objects, some of which are active and thus serve as centers of independent activity. Given this conception, we define concurrency as follows:
Concurrency is the property that distinguishes an active object from one that is not active.
Examples of Concurrency
Let’s consider a sensor named ActiveTemperatureSensor, whose behavior requires periodically sensing the current temperature and then notifying the client whenever the temperature changes a certain number of degrees from a given setpoint. We do not explain how the class implements this behavior. That fact is a secret of the implementation, but it is clear that some form of concurrency is required.
In general, there are three approaches to concurrency in object-oriented design. First, concurrency is an intrinsic feature of certain programming languages, which provide mechanisms for concurrency and synchronization. In this case, we www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 69 may create an active object that runs some process concurrently with all other active objects.
Second, we may use a class library that implements some form of lightweight processes. Naturally, the implementation of this kind is highly platform-dependent, although the interface to the library may be relatively portable. In this approach, concurrency is not an intrinsic part of the language (and so does not place any burdens on nonconcurrent systems) but appears as if it were intrinsic, through the presence of these standard classes.
Third, we may use interrupts to give us the illusion of concurrency. Of course, this requires that we have knowledge of certain low-level hardware details. For exam- ple, in our implementation of the class ActiveTemperatureSensor, we might have a hardware timer that periodically interrupts the application, during which time all such sensors read the current temperature and then invoke their callback function as necessary.
No matter which approach to concurrency we take, one of the realities about concurrency is that once you introduce it into a system, you must consider how active objects synchronize their activities with one another as well as with objects that are purely sequential. For example, if two active objects try to send messages to a third object, we must be certain to use some means of mutual exclusion, so that the state of the object being acted on is not corrupted when both active objects try to update its state simultaneously. This is the point where the ideas of abstraction, encapsulation, and concurrency interact. In the presence of concur- rency, it is not enough simply to define the methods of an object; we must also make certain that the semantics of these methods are preserved in the presence of multiple threads of control.
The Meaning of Persistence
An object in software takes up some amount of space and exists for a particular amount of time. Atkinson et al. suggest that there is a continuum of object exist- ence, ranging from transitory objects that arise within the evaluation of an expres- sion to objects in a database that outlive the execution of a single program. This spectrum of object persistence encompasses the following:
■ Transient results in expression evaluation ■ Local variables in procedure activations ■ Own variables [as in ALGOL 60], global variables, and heap items whose extent is different from their scope ■ Data that exists between executions of a program ■ Data that exists between various versions of a program ■ Data that outlives the program [79] www.Vidyarthiplus.com www.Vidyarthiplus.com
70 SECTION ICONCEPTS
Traditional programming languages usually address only the first three kinds of object persistence; persistence of the last three kinds is typically the domain of database technology. This leads to a clash of cultures that sometimes results in very strange architectures: Programmers end up crafting ad hoc schemes for stor- ing objects whose state must be preserved between program executions, and data- base designers misapply their technology to cope with transient objects [80].
An interesting variant of Atkinson et al.’s “Data that outlives the program” is the case of Web applications where the application may not be connected to the data it is using through the entire transaction execution. What changes may happen to data provided to a client application or Web service while disconnected to the data source, and how should resolution of the two be handled? Frameworks like Microsoft’s ActiveX Data Object for .NET (ADO.NET) have arisen to help address such distributed, disconnected scenarios.
Unifying the concepts of concurrency and objects gives rise to concurrent object- oriented programming languages. In a similar fashion, introducing the concept of persistence to the object model gives rise to object-oriented databases. In practice, such databases build on proven technology, such as sequential, indexed, hierarchi- cal, network, or relational database models, but then offer to the programmer the abstraction of an object-oriented interface, through which database queries and other operations are completed in terms of objects whose lifetimes transcend the lifetime of an individual program. This unification vastly simplifies the develop- ment of certain kinds of applications. In particular, it allows us to apply the same design methods to the database and nondatabase segments of an application.
Persistence saves the state and class of an object across time or space.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 71
Some object-oriented programming languages provide direct support for persis- tence. Java provides Enterprise Java Beans (EJBs) and Java Data Objects. Small- talk has protocols for streaming objects to and from storage (which must be redefined by subclasses). However, streaming objects to flat files is a naive solu- tion to persistence that does not scale well. Persistence may be achieved through a modest number of commercially available object-oriented databases [81]. A more typical approach to persistence is to provide an object-oriented skin over a rela- tional database. Customized object-relational mappings can be created by the individual developer. However, that is a very challenging task to do well. Frame- works are available to ease this task, such as the open source framework Hiber- nate [85]. Commercial object-relational mapping software is available. This approach is most appealing when there is a large capital investment in relational database technology that would be risky or too expensive to replace.
Persistence deals with more than just the lifetime of data. In object-oriented data- bases, not only does the state of an object persist, but its class must also transcend any individual program, so that every program interprets this saved state in the same way. This clearly makes it challenging to maintain the integrity of a data- base as it grows, particularly if we must change the class of an object.
Our discussion thus far pertains to persistence in time. In most systems, an object, once created, consumes the same physical memory until it ceases to exist. How- ever, for systems that execute on a distributed set of processors, we must some- times be concerned with persistence across space. In such systems, it is useful to think of objects that can move from machine to machine and that may even have different representations on different machines.
To summarize, we define persistence as follows:
Persistence is the property of an object through which its existence transcends time (i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s location moves from the address space in which it was created).
2.4 Applying the Object Model
As we have shown, the object model is fundamentally different from the models embraced by the more traditional methods of structured analysis, structured design, and structured programming. This does not mean that the object model abandons all of the sound principles and experiences of these older methods. Rather, it introduces several novel elements that build on these earlier models. Thus, the object model offers a number of significant benefits that other models simply do not provide. Most importantly, the use of the object model leads us to
www.Vidyarthiplus.com www.Vidyarthiplus.com
72 SECTION ICONCEPTS
construct systems that embody the five attributes of well-structured complex sys- tems noted in Chapter 1: hierarchy, relative primitives (i.e., multiple levels of abstraction), separation of concerns, patterns, and stable intermediate forms. In our experience, there are five other practical benefits to be derived from the appli- cation of the object model.
Benefits of the Object Model
First, the use of the object model helps us to exploit the expressive power of object-based and object-oriented programming languages. As Stroustrup points out, “It is not always clear how best to take advantage of a language such as C++. Significant improvements in productivity and code quality have consistently been achieved using C++ as ‘a better C’ with a bit of data abstraction thrown in where it is clearly useful. However, further and noticeably larger improvements have been achieved by taking advantage of class hierarchies in the design process. This is often called object-oriented design and this is where the greatest benefits of using C++ have been found” [82]. Our experience has been that, without the application of the elements of the object model, the more powerful features of languages such as Smalltalk, C++, Java, and so forth are either ignored or greatly misused.
Second, the use of the object model encourages the reuse not only of software but of entire designs, leading to the creation of reusable application frameworks [83]. We have found that object-oriented systems are often smaller than equivalent non- object-oriented implementations. Not only does this mean less code to write and maintain, but greater reuse of software also translates into cost and schedule benefits. However, reuse does not just happen. If reuse is not a primary goal of your project, it is unlikely that it will be achieved. Plus, designing for reuse may cost you more when initially implementing the reusable component. The good news is that the initial cost will be recovered in the subsequent uses of that component.
Third, the use of the object model produces systems that are built on stable inter- mediate forms, which are more resilient to change. This also means that such systems can be allowed to evolve over time, rather than be abandoned or com- pletely redesigned in response to the first major change in requirements.
Chapter 7, Pragmatics, explains further how the object model reduces the risks inherent in developing complex systems. This fourth benefit accrues primarily because integration is spread out across the lifecycle rather than occurring as one major event. The object model’s guidance in designing an intelligent separation of concerns also reduces development risk and increases our confidence in the cor- rectness of our design.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 2THE OBJECT MODEL 73
Finally, the object model appeals to the workings of human cognition. As Robson suggests, “Many people who have no idea how a computer works find the idea of object-oriented systems quite natural” [84].
Open Issues
To effectively apply the elements of the object model, we must next address sev- eral open issues.
■ What exactly are classes and objects? ■ How does one properly identify the classes and objects that are relevant to a particular application? ■ What is a suitable notation for expressing the design of an object-oriented system? ■ What process can lead us to a well-structured object-oriented system? ■ What are the management implications of using object-oriented design?
These issues are the themes of the next five chapters.
Summary
■ The maturation of software engineering has led to the development of object-oriented analysis, design, and programming methods, all of which address the issues of programming-in-the-large. ■ There are several different programming paradigms: procedure-oriented, object-oriented, logic-oriented, rule-oriented, and constraint-oriented. ■ An abstraction denotes the essential characteristics of an object that distin- guish it from all other kinds of objects and thus provide crisply defined con- ceptual boundaries, relative to the perspective of the viewer. ■ Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation. ■ Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. ■ Hierarchy is a ranking or ordering of abstractions. ■ Typing is the enforcement of the class of an object, such that objects of dif- ferent types may not be interchanged or, at the most, may be interchanged only in very restricted ways.
www.Vidyarthiplus.com www.Vidyarthiplus.com
74 SECTION ICONCEPTS
■ Concurrency is the property that distinguishes an active object from one that is not active. ■ Persistence is the property of an object through which its existence tran- scends time and/or space.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Classes and Objects
Both the engineer and the artist must be intimately familiar with the materials of their trade. Oils versus watercolors, steel versus aluminum, bolts versus nails, object versus classes—each of these materials serves similar functions (e.g., bolts and nails are both fasteners), yet each has its own specific properties and uses. The architect may not know the most efficient way to drive a nail (that is a specific skill of the carpenter), but the architect must understand when it is appropriate to use nails or bolts or glue or welds. To ignore such fundamental considerations can yield disas- trous results.
When we use object-oriented methods to analyze or design a complex software system, our basic building blocks are classes and objects. Since we have thus far provided only informal definitions of these two elements, in this chapter we turn to a detailed study of the nature of classes, objects, and their relationships, and along the way we provide several rules of thumb for crafting quality abstractions and mechanisms.
3.1 The Nature of an Object
The ability to recognize physical objects is a skill that humans learn at a very early age. A brightly colored ball will attract an infant’s attention, but typically, if you hide the ball, the child will not try to look for it; when the object leaves her field of vision, as far as she can determine, it ceases to exist. It is not until near the age of one that a child normally develops what is called the object concept, a skill that is of critical importance to future cognitive development. Show a ball to a one-year-old and then hide it, and she will usually search for it even though it is
75 www.Vidyarthiplus.com www.Vidyarthiplus.com
76 SECTION ICONCEPTS
not visible. Through the object concept, a child comes to realize that objects have a permanence and identity apart from any operations on them [1].
What Is and What Isn’t an Object
In Chapter 1, we informally defined an object as a tangible entity that exhibits some well-defined behavior. From the perspective of human cognition, an object is any of the following:
■ A tangible and/or visible thing ■ Something that may be comprehended intellectually ■ Something toward which thought or action is directed
We add to our informal definition the idea that an object models some part of real- ity and is therefore something that exists in time and space. In software, the term object was first formally applied in the Simula language; objects typically existed in Simula programs to simulate some aspect of reality [2].
Real-world objects are not the only kinds of objects that are of interest to us dur- ing software development. Other important kinds of objects are inventions of the design process whose collaborations with other such objects serve as the mecha- nisms that provide some higher-level behavior [3]. Jacobson et al. define control objects as “the ones that unite courses of events and thus will carry on communi- cation with other objects” [62]. This leads us to the more refined definition of Smith and Tockey, who suggest that “an object represents an individual, identifi- able item, unit, or entity, either real or abstract, with a well-defined role in the problem domain” [4].
Consider for a moment a manufacturing plant that processes composite materials for making such diverse items as bicycle frames and airplane wings. Manufactur- ing plants are often divided into separate shops: mechanical, chemical, electrical, and so forth. Shops are further divided into cells, and in each cell we have some collection of machines, such as die stamps, presses, and lathes. Along a manufac- turing line, we might find vats containing raw materials, which are used in a chemical process to produce blocks of composite materials, and which in turn are formed and shaped to produce bicycle frames, airplane wings, and other end items. Each of the tangible things we have mentioned thus far is an object. A lathe has a crisply defined boundary that separates it from the block of composite mate- rial it operates on; a bicycle frame has a crisply defined boundary that distin- guishes it from the cell of machines that produced the frame itself.
Some objects may have crisp conceptual boundaries yet represent intangible events or processes. For example, a chemical process in a manufacturing plant
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 77 may be treated as an object because it has a crisp conceptual boundary, interacts with certain other objects through a well-ordered collection of operations that unfolds over time, and exhibits a well-defined behavior. Similarly, consider a CAD/CAM system for modeling solids. Where two solids such as a sphere and a cube intersect, they may form an irregular line of intersection. Although it does not exist apart from the sphere or cube, this line is still an object with crisply defined conceptual boundaries.
An object has state, exhibits some well-defined behavior, and has a unique identity.
Some objects may be tangible yet have fuzzy physical boundaries. Objects such as rivers, fog, and crowds of people fit this definition.1 Just as the person holding a hammer tends to see everything in the world as a nail, so the developer with an object-oriented mindset begins to think that everything in the world is an object. This perspective is a little naive because some things are distinctly not objects. For example, attributes such as beauty or color are not objects, nor are emotions such as love and anger. On the other hand, these things are all potentially proper- ties of other objects. For example, we might say that a man (an object) loves his wife (another object), or that a particular cat (yet another object) is gray.
1. This is true only at a sufficiently high level of abstraction. To a person walking through a fog bank, it is generally futile to distinguish “my fog” from “your fog.” However, consid- er a weather map: A fog bank over San Francisco is a distinctly different object than a fog bank over London.
www.Vidyarthiplus.com www.Vidyarthiplus.com
78 SECTION ICONCEPTS
Thus, it is useful to say that an object is something that has crisply defined bound- aries, but this is not enough to guide us in distinguishing one object from another, nor does it allow us to judge the quality of our abstractions. Our experience there- fore suggests the following definition.
An object is an entity that has state, behavior, and identity. The structure and behavior of similar objects are defined in their common class. The terms instance and object are interchangeable.
We will consider the concepts of state, behavior, and identity in more detail in the sections that follow.
State
Consider a vending machine that dispenses soft drinks. The usual behavior of such objects is that when someone puts money in a slot and pushes a button to make a selection, a drink emerges from the machine. What happens if a user first makes a selection and then puts money in the slot? Most vending machines just sit and do nothing because the user has violated the basic assumptions of their oper- ation. Stated another way, the vending machine was in a state (of waiting for money) that the user ignored (by making a selection first). Similarly, suppose that the user ignores the warning light that says, “Correct change only,” and puts in extra money. Most machines are user-hostile; they will happily swallow the excess money.
In each of these circumstances, we see how the behavior of an object is influenced by its history: The order in which one operates on the object is important. The reason for this event- and time-dependent behavior is the existence of state within the object. For example, one essential state associated with the vending machine is the amount of money currently entered by a user but not yet applied to a selec- tion. Other important properties include the amount of change available and the quantity of soft drinks on hand.
From this example, we may form the following low-level definition.
The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties.
Another property of a vending machine is that it can accept money. This is a static (i.e., fixed) property, meaning that it is an essential characteristic of a vending machine. In contrast, the actual quantity of money accepted at any given moment represents the dynamic value of this property and is affected by the order of oper- ations on the machine. This quantity increases as a user inserts money and then decreases when a product is vended. We say that values are “usually dynamic”
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 79 because in some cases values are static. For example, the serial number of a vend- ing machine is a static property and value.
A property is an inherent or distinctive characteristic, trait, quality, or feature that contributes to making an object uniquely that object. For example, one essential property of an elevator is that it is constrained to travel up and down and not horizontally. Properties are usually static because attributes such as these are unchanging and fundamental to the nature of the object. We say “usually static” because in some circumstances the properties of an object may change. For exam- ple, consider an autonomous robot that can learn about its environment. It may first recognize an object that appears to be a fixed barrier, only to learn later that this object is in fact a door that can be opened. In this case, the object created by the robot as it builds its conceptual model of the world gains new properties as new knowledge is acquired.
All properties have some value. This value might be a simple quantity, or it might denote another object. For example, part of the state of an elevator might have the value 3, denoting the current floor on which the elevator is located. In the case of the vending machine, its state encompasses many other objects, such as a collec- tion of soft drinks. The individual drinks are in fact distinct objects; their proper- ties are different from those of the machine (they can be consumed, whereas a vending machine cannot), and they can be operated on in distinctly different ways. Thus, we distinguish between objects and simple values: Simple quantities such as the number 3 are “atemporal, unchangeable, and non-instantiated,” whereas objects “exist in time, are changeable, have state, are instantiated, and can be created, destroyed, and shared” [6].
The fact that every object has state implies that every object takes up some amount of space, be it in the physical world or in computer memory.
We may say that all objects within a system encapsulate some state and that all of the state within a system is encapsulated by objects. Encapsulating the state of an object is a start, but it is not enough to allow us to capture the full intent of the abstractions we discover and invent during development (refer to Example 3–1, which shows how a simple abstraction may evolve). For this reason, we must also consider how objects behave.
Example 3–1 Consider an abstraction of an employee record. Figure 3–1 depicts this abstraction using the Unified Modeling Language notation for a class. (For more on the UML notation, see Chapter 5.)
Each part of this abstraction denotes a particular property of our abstraction of an employee. This abstraction is not an object because it does not represent a
www.Vidyarthiplus.com www.Vidyarthiplus.com
80 SECTION ICONCEPTS
Figure 3–1 Employee Class with Attributes
specific instance. When made specific, we may have, for example, two distinct objects: Tom and Kaitlyn, each of which takes up some amount of space in memory (see Figure 3–2).
Figure 3–2 Employee Objects Tom and Kaitlyn
None of these objects shares its space with any other object, although each of them has the same properties; thus, their states have a common representation.
It is good engineering practice to encapsulate the state of an object rather than expose it. For example, we might change the abstraction (class) as shown in Figure 3–3.
Figure 3–3 Employee Class with Protected Attributes and Public Operations
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 81
This abstraction is slightly more complicated than the previous one, but it is superior for a number of reasons. Specifically, its internal representation is hidden (protected, indicated by #) from all other outside clients. If we change its representation, we will have to recompile some code, but semantically, no outside client will be affected by this change (in other words, existing code will not break).
Also, we have captured certain decisions about the problem space by explic- itly stating some of the operations (responsibilities) that clients may perform on objects of this class. In particular, we grant all clients the (public, indicated by +) right to retrieve the name, social security number, and department of an employee. We will discuss visibility (i.e., public, protected, private, and pack- age) later in this chapter.
Behavior
No object exists in isolation. Rather, objects are acted on and themselves act on other objects. Thus, we may say the following:
Behavior is how an object acts and reacts, in terms of its state changes and mes- sage passing.
In other words, the behavior of an object represents its outwardly visible activity.
An operation is some action that one object performs on another in order to elicit a reaction. For example, a client might invoke the operations append and pop to grow and shrink a queue object, respectively. A client might also invoke the oper- ation length, which returns a value denoting the size of the queue object but does not alter the state of the queue itself.
In Java, operations that clients may perform on an object are typically declared as methods. In languages such as C++, which derive from more procedural ances- tors, we speak of one object invoking the member function of another. In pure object-oriented languages such as Smalltalk, we speak of one object passing a message to another. Generally, a message is simply an operation that one object performs on another, although the underlying dispatch mechanisms are different. For our purposes, the terms operation and message are interchangeable.
Message passing is one part of the equation that defines the behavior of an object; our definition for behavior also notes that the state of an object affects its behavior as well. Consider again the vending machine example. We may invoke some operation to make a selection, but the vending machine will behave differently depending on its state. If we do not deposit change sufficient for our selection, the machine will probably do nothing. If we provide sufficient change, the machine
www.Vidyarthiplus.com www.Vidyarthiplus.com
82 SECTION ICONCEPTS
will take our change and then give us our selection (thereby altering its state). Thus, we may say that the behavior of an object is a function of its state as well as the operation performed on it, with certain operations having the side effect of altering the object’s state. This concept of side effect thus leads us to refine our definition of state.
The state of an object represents the cumulative results of its behavior.
Most interesting objects do not have state that is static; rather, their state has prop- erties whose values are modified and retrieved as the object is acted on. The behavior of an object is embodied in the sum of its operations. Next we will dis- cuss operations, how they relate to an object’s roles, and how they enable objects to meet their responsibilities.
Operations
An operation denotes a service that a class offers to its clients. In practice, we have found that a client typically performs five kinds of operations on an object.2 The three most common kinds of operations are the following:
■ Modifier: an operation that alters the state of an object ■ Selector: an operation that accesses the state of an object but does not alter the state ■ Iterator: an operation that permits all parts of an object to be accessed in some well-defined order
Two other kinds of operations are common; they represent the infrastructure nec- essary to create and destroy instances of a class.
■ Constructor: an operation that creates an object and/or initializes its state ■ Destructor: an operation that frees the state of an object and/or destroys the object itself
In C++, constructors and destructors are declared as part of the definition of a class, whereas in Java there are constructors, but no destructors. In Smalltalk, such operations are typically part of the protocol of a metaclass (i.e., the class of a class).
2. Lippman suggests a slightly different categorization: manager functions, implementer functions, helping functions (all kinds of modifiers), and access functions (equivalent to se- lectors) [7].
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 83
Roles and Responsibilities
Collectively, all of the methods associated with a particular object comprise its protocol. The protocol of an object thus defines the envelope of an object’s allow- able behavior and so comprises the entire static and dynamic view of the object. For most nontrivial abstractions, it is useful to divide this larger protocol into log- ical groupings of behavior. These collections, which thus partition the behavior space of an object, denote the roles that an object can play. A role is a mask that an object wears [8] and so defines a contract between an abstraction and its clients.
Objects can play many different roles.
“Responsibilities are meant to convey a sense of the purpose of an object and its place in the system. The responsibilities of an object are all the services it pro- vides for all of the contracts it supports” [9]. In other words, we may say that the state and behavior of an object collectively define the roles that an object may play in the world, which in turn fulfill the abstraction’s responsibilities.
Indeed, most interesting objects play many different roles during their lifetime. Consider the following examples [10].
■ A bank account may have the role of a monetary asset to which the account owner may deposit or withdraw money. However, to a taxing authority, the account may play the role of an entity whose dividends must be reported on annually. www.Vidyarthiplus.com www.Vidyarthiplus.com
84 SECTION ICONCEPTS
■ To a trader, a share of stock represents an entity with value that may be bought or sold; to a lawyer, the same share denotes a legal instrument to which are attached certain rights. ■ In the course of one day, the same person may play the role of mother, doc- tor, gardener, and movie critic.
The roles played by objects are dynamic yet can be mutually exclusive. In the case of the share of stock, its roles overlap slightly, but each role is static relative to the client that interacts with the share. In the case of the person, her roles are quite dynamic and may change from moment to moment.
Objects play many different roles during their lifetimes.
As we will discuss further in later chapters, we often start our analysis of a prob- lem by examining the various roles that an object plays. During design, we refine these roles by inventing the particular operations that carry out each role’s responsibilities.
Objects as Machines
The existence of state within an object means that the order in which operations are invoked is important. This gives rise to the idea that each object is like a tiny,
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 85 independent machine [11]. Indeed, for some objects, this event and time ordering of operations is so pervasive that we can best formally characterize the behavior of such objects in terms of an equivalent finite state machine. In Chapter 5, we will show a particular notation for hierarchical finite state machines that we may use for expressing these semantics.
Continuing the machine metaphor, we may classify objects as either active or pas- sive. An active object is one that encompasses its own thread of control, whereas a passive object does not. Active objects are generally autonomous, meaning that they can exhibit some behavior without being operated on by another object. Passive objects, on the other hand, can undergo a state change only when explic- itly acted on. In this manner, the active objects in our system serve as the roots of control. If our system involves multiple threads of control, we will usually have multiple active objects. Sequential systems, on the other hand, usually have exactly one active object, such as a main object responsible for managing an event loop that dispatches messages. In such architectures, all other objects are passive, and their behavior is ultimately triggered by messages from the one active object. In other kinds of sequential system architectures (such as transaction-processing systems), there is no obvious central active object, so control tends to be distrib- uted throughout the system’s passive objects.
Identity
Khoshafian and Copeland offer the following definition for identity: “Identity is that property of an object which distinguishes it from all other objects” [12].
They go on to note that “most programming and database languages use variable names to distinguish temporary objects, mixing addressability and identity. Most database systems use identifier keys to distinguish persistent objects, mixing data value and identity.” The failure to recognize the difference between the name of an object and the object itself is the source of many kinds of errors in object- oriented programming.
Example 3–2 demonstrates the importance of maintaining the identity of the objects you create and shows how easily the identity can be irrecoverably lost.
Example 3–2 Consider a class that denotes a display item. A display item is a common abstraction in all GUI-centric systems: It represents the base class of all objects that have a visual representation on some window and so captures the structure and behavior common to all such objects. Clients expect to be able to draw, select, and move display items, as well as query their selection
www.Vidyarthiplus.com www.Vidyarthiplus.com
86 SECTION ICONCEPTS
state and location. Each display item has a location designated by the coordi- nates x and y.
Let us assume we instantiate a number of DisplayItem classes as indi- cated in Figure 3–4a. Specifically, the manner in which we instantiate these classes sets aside four locations in memory whose names are item1, item2, item3, and item4, respectively. Here, item1 is the name of a dis- tinct DisplayItem object, but the other three names each denote a pointer to a DisplayItem object. Only item2 and item3 actually point to distinct DisplayItem objects (because in their declarations we allocated a new DisplayItem object); item4 designates no such object. Furthermore, the names of the objects pointed to by item2 and item3 are anonymous: We can refer to these distinct objects only indirectly, via their pointer value.
a) item2 item3 item4
item1 0 X=0 X=75 X=100 Y=0 Y=75 Y=100
b) item2 item3 item4
item1 X=75 X=75 X=38 Y=75 Y=75 Y=100
c) item2 item3 item4
item1 X=75 X=75 X=38 Y=75 Y=75 Y=100 Figure 3–4 Object Identity
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 87
The unique identity (but not necessarily the name) of each object is preserved over the lifetime of the object, even when its state is changed. This is like the Zen question about a river: Is a river the same river from one day to the next, even though the same water never flows through it? For example, let’s move item1. We can access the object designated by item2, get its location, and move item1 to that same location.
Also, if we equate item4 to item3, we can now reference the object desig- nated by item3 by using item4 also. Using item4 we can then move that object to a new location, say, X=38, Y=100. Figure 3–4b illustrates these results. Here we see that item1 and the object designated by item2 both have the same location state and that item4 now also designates the same object as does item3. Notice that we use the phrase “the object designated by item2” rather than saying “the object item2.” The first phrase is more pre- cise, although we will sometimes use these phrases interchangeably.
Although item1 and the object designated by item2 have the same state, they represent distinct objects. Also, note that we have changed the state of the object designated by item3 by operating on it through its new indirect name, item4. This is a situation we call structural sharing, meaning that a given object can be named in more than one way; in other words, there are aliases to the object. Structural sharing is the source of many problems in object-oriented programming. Failure to recognize the side effects of operat- ing on an object through aliases often leads to memory leaks, memory- access violations, and, even worse, unexpected state changes. For example, if we destroyed the object designated by item3, then item4’s pointer value would be meaningless; this is a situation we call a dangling reference.
Consider also Figure 3–4c, which illustrates the results of modifying the value of the item2 pointer to point to item1. Now item2 designates the same object as item1. Unfortunately, we have introduced a memory leak: The object originally designated by item2 can no longer be named, either directly or indirectly, and so its identity is lost. In languages such as Smalltalk and Java, such objects will be garbage-collected and their storage reclaimed auto- matically, but in languages such as C++, their storage will not be reclaimed until the program that created them finishes. Especially for long-running pro- grams, memory leaks such as this are either bothersome or disastrous.3
3. Consider the effects of a memory leak in software controlling a satellite or a pacemaker. Restarting the computer in a satellite several million miles away from earth is quite incon- venient. Similarly, the unpredictable occurrence of automatic garbage collection in a pace- maker’s software is likely to be fatal. For these reasons, real-time system developers often steer away from the unrestrained allocation of objects on the heap.
www.Vidyarthiplus.com www.Vidyarthiplus.com
88 SECTION ICONCEPTS
3.2 Relationships among Objects
An object by itself is intensely uninteresting. Objects contribute to the behavior of a system by collaborating with one another. “Instead of a bit-grinding processor raping and plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires” [13]. For example, consider the object structure of an airplane, which has been defined as “a collection of parts having an inherent tendency to fall to earth, and requiring constant effort and supervision to stave off that outcome” [14]. Only the collabo- rative efforts of all the component objects of an airplane enable it to fly.
The relationship between any two objects encompasses the assumptions that each makes about the other, including what operations can be performed and what behavior results. We have found that two kinds of object relationships are of par- ticular interest in object-oriented analysis and design, namely:
1. Links 2. Aggregation
Links
The term link derives from Rumbaugh et al., who define it as a “physical or con- ceptual connection between objects” [16]. An object collaborates with other objects through its links to these objects. Stated another way, a link denotes the specific association through which one object (the client) applies the services of another object (the supplier), or through which one object may navigate to another.
Figure 3–5 illustrates several different links. In this figure, a line between two object icons represents the existence of a link between the two and means that messages may pass along this path. Messages are shown as small directed lines representing the direction of the message, with a label naming the message itself. For example, in Figure 3–5 we show part of a simplified flow control system. This may be controlling the flow of water through a pipe in a manufacturing plant. You can see that the FlowController object has a link to a Valve object. The Valve object has a link to the DisplayPanel object in which its status will be displayed. Only across these links may one object send messages to another.
Message passing between two objects is typically unidirectional, although it may occasionally be bidirectional. In our example, the FlowController object
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 89 invokes operations on the Valve object (to change its setting) and the DisplayPanel (to change what it displays), but these objects do not them- selves operate on the FlowController object. This separation of concerns is quite common in well-structured object-oriented systems. Notice also that although message passing is initiated by the client (such as FlowController) and is directed toward the supplier (such as the Valve object), data may flow in either direction across a link. For example, when FlowController invokes the operation adjust on the Valve object, data (i.e., the setting to change to) flows from the client to the supplier. However, if FlowController invokes a different operation, isClosed, on the Valve object, the result (i.e., whether the valve is in the fully closed position) passes from the supplier to the client.
As a participant in a link, an object may play one of three roles.
1. Controller: This object can operate on other objects but is not operated on by other objects. In some contexts, the terms active object and controller are interchangeable. 2. Server: This object doesn’t operate on other objects; it is only operated on by other objects. 3. Proxy: This object can both operate on other objects and be operated on by other objects. A proxy is usually created to represent a real-world object in the domain of the application.
In the context of Figure 3–5, FlowController acts as a controller object, DisplayPanel acts as a server object, and Valve acts as a proxy. Example 3–3 illustrates how responsibilities can be properly separated across a group of collab- orating objects.
Figure 3–5 Links
www.Vidyarthiplus.com www.Vidyarthiplus.com
90 SECTION ICONCEPTS
Example 3–3 In many different kinds of industrial processes, certain reactions require a temperature ramp, wherein we raise the temperature of some substance, hold it at that temperature for a fixed period, and then let it cool to ambient temper- ature. Different processes require different profiles: Some objects (such as telescope mirrors) must be cooled slowly, whereas other materials (such as steel) must be cooled rapidly. This abstraction of a temperature ramp has a sufficiently well-defined behavior that it warrants the creation of a class. Thus we provide the class TemperatureRamp, which is conceptually a time/tem- perature mapping (see Figure 3–6).
Actually, the behavior of this abstraction is more than just a literal time/ temperature mapping. For example, we might set a temperature ramp that requires the temperature to be 250°F at time 60 (one hour into the tempera- ture ramp) and 150°F at time 180 (three hours into the process), but then we would like to know what the temperature should be at time 120. This requires linear interpolation, which is therefore another behavior (i.e., interpolate) we expect of this abstraction.
One behavior we explicitly do not require of this abstraction is the control of a heater to carry out a particular temperature ramp. Rather, we prefer a greater separation of concerns, wherein this behavior is achieved through the collabo- ration of three objects: a temperature ramp instance, a heater, and a tempera- ture controller (see Figure 3–6). The operation process provides the central behavior of this abstraction; its purpose is to carry out the given temperature ramp for the heater at the given location.
A comment regarding our style: At first glance, it may appear that we have devised an abstraction whose sole purpose is to wrap a functional decompo- sition inside a class to make it appear noble and object-oriented. The opera- tion schedule suggests that this is not the case. Objects of the class TemperatureController have sufficient knowledge to determine when a particular profile should be scheduled, so we expose this operation as an additional behavior of our abstraction. In some high-energy industrial pro- cesses (such as steel making), heating a substance is a costly event, and it is important to take into account any lingering heat from a previous process, as well as the normal cool-down of an unattended heater. The operation sched- ule exists so that clients can query a TemperatureController object to determine the next optimal time to process a particular temperature ramp.
Visibility
Consider two objects, A and B, with a link between the two. In order for A to send a message to B, B must be visible to A in some manner. During our analysis of a problem, we can largely ignore issues of visibility, but once we begin to devise
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 91 concrete implementations, we must consider the visibility across links because our decisions here dictate the scope and access of the objects on each side of a link. We will discuss this further later in this chapter.
Synchronization
Whenever one object passes a message to another across a link, the two objects are said to be synchronized. For objects in a completely sequential application, this synchronization is usually accomplished by simple method invocation. How- ever, in the presence of multiple threads of control, objects require more sophisti- cated message passing in order to deal with the problems of mutual exclusion that can occur in concurrent systems. As we described earlier, active objects embody their own thread of control, so we expect their semantics to be guaranteed in the presence of other active objects. However, when one active object has a link to a passive one, we must choose one of three approaches to synchronization.
1. Sequential: The semantics of the passive object are guaranteed only in the presence of a single active object at a time. 2. Guarded: The semantics of the passive object are guaranteed in the presence of multiple threads of control, but the active clients must collaborate to achieve mutual exclusion. 3. Concurrent: The semantics of the passive object are guaranteed in the pres- ence of multiple threads of control, and the supplier guarantees mutual exclusion.
Aggregation
Whereas links denote peer-to-peer or client/supplier relationships, aggregation denotes a whole/part hierarchy, with the ability to navigate from the whole (also called the aggregate) to its parts. In this sense, aggregation is a specialized kind of association. For example, as shown in Figure 3–6, the object Temperature- Controller has a link to the object TemperatureRamp as well as to Heater. The object TemperatureController is thus the whole, and Heater is one of its parts. The notation shown for an aggregation relationship will be further explained in Chapter 5.
By implication, an object that is a part of another object has a link to its aggregate. Across this link, the aggregate may send messages to its parts. Given the object TemperatureController, it is possible to find its corresponding Heater. Given an object such as Heater, it is possible to navigate to its enclosing object (also called its container) if and only if this knowledge is a part of the state of Heater.
www.Vidyarthiplus.com www.Vidyarthiplus.com
92 SECTION ICONCEPTS
Figure 3–6 Aggregation
Aggregation may or may not denote physical containment. For example, an air- plane is composed of wings, engines, landing gear, and so on: This is a case of physical containment. On the other hand, the relationship between a shareholder and his or her shares is an aggregation relationship that does not require physical containment. The shareholder uniquely owns shares, but the shares are by no means a physical part of the shareholder. Rather, this whole/part relationship is more conceptual and therefore less direct than the physical aggregation of the parts that form an airplane.
There are clear trade-offs between links and aggregation. Aggregation is some- times better because it encapsulates parts as secrets of the whole. Links are sometimes better because they permit looser coupling among objects. Intelligent engineering decisions require careful weighing of these two factors.
3.3 The Nature of a Class
The concepts of a class and an object are tightly interwoven, for we cannot talk about an object without regard for its class. However, there are important differ- ences between these two terms.
What Is and What Isn’t a Class
Whereas an object is a concrete entity that exists in time and space, a class repre- sents only an abstraction, the “essence” of an object, as it were. Thus, we may speak of the class Mammal, which represents the characteristics common to all mammals. To identify a particular mammal in this class, we must speak of “this mammal” or “that mammal.” www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 93
In everyday terms, Webster’s Third New International Dictionary defines a class as “a group, set, or kind marked by common attributes or a common attribute; a group division, distinction, or rating based on quality, degree of competence, or condition” [17].
In the context of object-oriented analysis and design, we define a class as follows:
A class is a set of objects that share a common structure, common behavior, and common semantics.
A single object is simply an instance of a class.
A class represents a set of objects that share a common structure and a common behavior.
What isn’t a class? An object is not a class. Objects that share no common struc- ture and behavior cannot be grouped in a class because, by definition, they are unrelated except by their general nature as objects.
It is important to note that the class—as defined by most programming languages— is a necessary but insufficient vehicle for decomposition. Sometimes abstractions are so complex that they cannot be conveniently expressed in terms of a single class declaration. For example, at a sufficiently high level of abstraction, a GUI framework, a database, and an entire inventory system are all conceptually
www.Vidyarthiplus.com www.Vidyarthiplus.com
94 SECTION ICONCEPTS
individual objects, none of which can be expressed as a single class.4 Instead, it is far better for us to capture these abstractions as a cluster of classes whose instances collaborate to provide the desired structure and behavior. Stroustrup calls such a cluster a component [18].
Interface and Implementation
Meyer [19] and Snyder [20] have both suggested that programming is largely a matter of “contracting”: The various functions of a larger problem are decom- posed into smaller problems by subcontracting them to different elements of the design. Nowhere is this idea more evident than in the design of classes.
Whereas an individual object is a concrete entity that performs some role in the overall system, the class captures the structure and behavior common to all related objects. Thus, a class serves as a sort of binding contract between an abstraction and all of its clients. By capturing these decisions in the interface of a class, a strongly typed programming language can detect violations of this con- tract during compilation.
This view of programming as contracting leads us to distinguish between the out- side view and the inside view of a class. The interface of a class provides its outside view and therefore emphasizes the abstraction while hiding its structure and the secrets of its behavior. This interface primarily consists of the declara- tions of all the operations applicable to instances of this class, but it may also include the declaration of other classes, constants, variables, and exceptions as needed to complete the abstraction. By contrast, the implementation of a class is its inside view, which encompasses the secrets of its behavior. The implementa- tion of a class primarily consists of the implementation of all of the operations defined in the interface of the class.
We can further divide the interface of a class into four parts:
1. Public: a declaration that is accessible to all clients 2. Protected: a declaration that is accessible only to the class itself and its sub- classes
4. One might be tempted to express such abstractions in a single class, but the granularity for reuse and change is too coarse. Having a “fat” interface is bad practice because most clients will want to reference only a small subset of the services provided. Furthermore, changing one part of a huge interface obsolesces every client, even those that don’t care about the parts that changed. Nesting classes doesn’t eliminate these problems; it only de- fers them.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 95
3. Private: a declaration that is accessible only to the class itself 4. Package: a declaration that is accessible only by classes in the same package
The detailed semantics of these forms of visibility can vary based on the imple- mentation language used.
Visibility and Friendship
Different programming languages provide different mixtures of public, pro- tected, private, and package parts, which developers can choose among to establish specific access rights for each part of a class’s interface and thereby exercise control over what clients can see and what they can’t see (i.e., visibility). In particular, C++ allows a developer to make explicit distinctions among all four of these different parts.5 The C++ friendship mechanism permits a class to distinguish certain privileged classes that are given the rights to see the class’s protected and private parts. Friendships break a class’s encapsulation and so, as in life, must be chosen carefully. Java does not have friendship. Instead, Java has a somewhat similar type of visibility called package access, where all classes in the same package can access each other. Aside from friendship, public, protected, and private access operate in Java as they do in C++. By contrast, Ada permits declarations to be public or private but not protected. In Smalltalk, all instance variables are private, and all methods are public. In Object Pascal, both fields and operations are public and hence unencapsulated.
The constants and variables that form the representation of a class are known by various terms, depending on the particular language we use. For example, Small- talk uses the term instance variable, Object Pascal and Java use the term field, C++ uses the term data member. We will use these terms interchangeably to denote the parts of a class that serve as the representation of its instance’s state.
The state of an object must have some representation in its corresponding class and so is typically expressed as constant and variable declarations placed in the protected or private part of a class’s interface. In this manner, the representation common to all instances of a class is encapsulated, and changes to this representa- tion do not functionally affect any outside clients.5
5. The C++ struct is a special case, in the sense that a struct is a kind of class with all of its elements public.
www.Vidyarthiplus.com www.Vidyarthiplus.com
96 SECTION ICONCEPTS
Class Lifecycle
We may come to understand the behavior of a simple class just by understanding the semantics of its distinct public operations in isolation. However, the behavior of more interesting classes (such as moving an instance of the class DisplayItem or scheduling an instance of the class TemperatureController) involves the interaction of their various operations over the lifetime of each of their instances. As described earlier in this chapter, the instances of such classes act as little machines, and since all such instances embody the same behavior, we can use the class to capture these common event- and time-ordered semantics. As we discuss in Chapter 5, we may describe such dynamic behavior for certain interesting classes by using finite state machines.
3.4 Relationships among Classes
Consider for a moment the similarities and differences among the following classes of objects: flowers, daisies, red roses, yellow roses, petals, and ladybugs. We can make the following observations.
■ A daisy is a kind of flower. ■ A rose is a (different) kind of flower. ■ Red roses and yellow roses are both kinds of roses. ■ A petal is a part of both kinds of flowers. ■ Ladybugs eat certain pests such as aphids, which may be infesting certain kinds of flowers.
From this simple example we conclude that classes, like objects, do not exist in isolation. Rather, for a particular problem domain, the key abstractions are usu- ally related in a variety of interesting ways, forming the class structure of our design [21].
We establish relationships between two classes for one of two reasons. First, a class relationship might indicate some sort of sharing. For example, daisies and roses are both kinds of flowers, meaning that both have brightly colored petals, both emit a fragrance, and so on. Second, a class relationship might indicate some kind of semantic connection. Thus, we say that red roses and yellow roses are more alike than are daisies and roses, and daisies and roses are more closely related than are petals and flowers. Similarly, there is a symbiotic connection between ladybugs and flowers: Ladybugs protect flowers from certain pests, which in turn serve as a food source for the ladybug.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 97
In all, there are three basic kinds of class relationships [22]. The first of these is generalization/specialization, denoting an “is a” relationship. For instance, a rose is a kind of flower, meaning that a rose is a specialized subclass of the more gen- eral class, flower. The second is whole/part, which denotes a “part of” relation- ship. Thus, a petal is not a kind of a flower; it is a part of a flower. The third is association, which denotes some semantic dependency among otherwise unre- lated classes, such as between ladybugs and flowers. As another example, roses and candles are largely independent classes, but they both represent things that we might use to decorate a dinner table.
Association
Of these different kinds of class relationships, associations are the most general but also the most semantically weak. The identification of associations among classes is often an activity of analysis and early design, at which time we begin to discover the general dependencies among our abstractions. As we continue our design and implementation, we will often refine these weak associations by turn- ing them into one of the other more concrete class relationships.
Semantic Dependencies
As Example 3–4 suggests, an association only denotes a semantic dependency and does not state the direction of this dependency (unless otherwise stated, an association implies bidirectional navigation, as in our example), nor does it state the exact way in which one class relates to another (we can only imply these semantics by naming the role each class plays in relationship with the other). However, these semantics are sufficient during the analysis of a problem, at which time we need only to identify such dependencies. Through the creation of associ- ations, we come to capture the participants in a semantic relationship, their roles, and their cardinality.
Example 3–4 For a vehicle, two of our key abstractions include the vehicle and wheels. As shown in Figure 3–7, we may show a simple association between these two classes: the class Wheel and the class Vehicle. (Arguably, an aggregation would be better.) By implication, this association suggests bidirectional navi- gation. Given an instance of Wheel, we should be able to locate the object denoting its Vehicle, and given an instance of Vehicle, we should be able to locate all the wheels.
www.Vidyarthiplus.com www.Vidyarthiplus.com
98 SECTION ICONCEPTS
Figure 3–7 Association
Here we show a one-to-many association: Each instance of Wheel relates to one Vehicle, and each instance of Vehicle may have many Wheels (noted by the *).
Multiplicity
Our example introduced a one-to-many association, meaning that for each instance of the class Vehicle, there are zero (a boat, which is a vehicle, has no wheels) or more instances of the class Wheel, and for each Wheel, there is exactly one Vehicle. This denotes the multiplicity of the association. In prac- tice, there are three common kinds of multiplicity across an association:
1. One-to-one 2. One-to-many 3. Many-to-many
A one-to-one relationship denotes a very narrow association. For example, in retail telemarketing operations, we would find a one-to-one relationship between the class Sale and the class CreditCardTransaction: Each sale has exactly one corresponding credit card transaction, and each such transaction cor- responds to one sale. Many-to-many relationships are also common. For example, each instance of the class Customer might initiate a transaction with several instances of the class SalesPerson, and each such salesperson might interact with many different customers. As we will discuss further in Chapter 5, there are variations on these three common forms of multiplicity.
Inheritance
Inheritance, perhaps the most semantically interesting of these concrete relation- ships, exists to express generalization/specialization relationships. In our experi- ence, however, inheritance is an insufficient means of expressing all of the rich relationships that may exist among the key abstractions in a given problem domain. An alternate approach to inheritance involves a language mechanism called delegation, in which objects delegate their behavior to related objects.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 99
Example 3–5 After space probes are launched, they report back to ground stations with information regarding the status of important subsystems (such as electrical power and propulsion systems) and different sensors (such as radiation sen- sors, mass spectrometers, cameras, micrometeorite collision detectors, and so on). Collectively, this relayed information is called telemetry data. Teleme- try data is commonly transmitted as a bitstream consisting of a header, which includes a timestamp and some keys identifying the kind of information that follows, plus several frames of processed data from the various subsystems and sensors. This appears to be a straightforward aggregation of different kinds of data.
This critical data needs to be encapsulated. Otherwise, there is nothing to pre- vent a client from changing the value of important data such as timestamp or currentPower. Likewise, the representation of this data is exposed, so if we were to change the representation (e.g., by adding new elements or chang- ing the bit alignment of existing ones), every client would be affected. At the very least, we would certainly have to recompile every reference to this structure. More importantly, such changes might violate the assumptions that clients had made about this representation and cause the logic in our program to break.
Lastly, suppose our analysis of the system’s requirements reveals the need for several hundred different kinds of telemetry data, including electrical data that encompassed the preceding information and also included voltage readings from various test points throughout the system. We would find that declaring these additional structures would create a considerable amount of redun- dancy, in terms of both replicated structures and common functions.
A subclass may inherit the structure and behavior of its superclass.
www.Vidyarthiplus.com www.Vidyarthiplus.com
100 SECTION ICONCEPTS
A slightly better way to capture our decisions would be to declare one class for each kind of telemetry data. In this manner, we could hide the representation of each class and associate its behavior with its data. Still, this approach does not address the problem of redundancy.
A far better solution, therefore, is to capture our decisions by building a hierar- chy of classes, in which specialized classes inherit the structure and behavior defined by more generalized classes, as shown in Figure 3–8.
Figure 3–8 ElectricalData Inherits from the Superclass TelemetryData
As for the class ElectricalData, this class inherits the structure and behav- ior of the class TelemetryData but adds to its structure (the additional voltage data), redefines its behavior (the function transmit) to transmit the addi- tional data, and can even add to its behavior (the function currentPower, a function to provide the current power level).
Single Inheritance
Simply stated, inheritance is a relationship among classes wherein one class shares the structure and/or behavior defined in one (single inheritance) or more (multiple inheritance) other classes. We call the class from which another class inherits its superclass. In Example 3–5, TelemetryData is a superclass of ElectricalData. Similarly, we call a class that inherits from one or more classes a subclass; ElectricalData is a subclass of TelemetryData. Inheritance therefore defines an “is a” hierarchy among classes, in which a subclass inherits from one or more superclasses. This is in fact the litmus test for inheritance. Given classes A and B, if A is not a kind of B, then A should not be a subclass of B. In this sense, ElectricalData is a specialized kind of the more generalized class TelemetryData. The ability of a language to support this kind of inherit- ance distinguishes object-oriented from object-based programming languages.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 101
A subclass typically augments or restricts the existing structure and behavior of its superclasses. A subclass that augments its superclasses is said to use inherit- ance for extension. For example, the subclass GuardedQueue might extend the behavior of its superclass Queue by providing extra operations that make instances of this class safe in the presence of multiple threads of control. In con- trast, a subclass that constrains the behavior of its superclasses is said to use inherit- ance for restriction. For example, the subclass UnselectableDisplayItem might constrain the behavior of its superclass, DisplayItem,by prohibiting clients from selecting its instances in a view. In practice, it is not always so clear whether or not a subclass augments or restricts its superclass; in fact, it is com- mon for a subclass to do both.
Figure 3–9 illustrates the single inheritance relationships deriving from the super- class TelemetryData. Each directed line denotes an “is a” relationship. For example, CameraData “is a” kind of SensorData, which in turn “is a” kind of TelemetryData.
This is identical to the hierarchy one finds in a semantic net, a tool often used by researchers in cognitive science and artificial intelligence to organize knowledge about the world [25]. Indeed, as we discuss further in Chapter 4, designing a suit- able inheritance hierarchy among abstractions is largely a matter of intelligent classification.
We expect that some of the classes in Figure 3–9 will have instances and some will not. For example, we expect to have instances of each of the most specialized classes (also known as leaf classes or concrete classes), such as ElectricalData and SpectrometerData. However, we are not likely to have any instances of the intermediate, more generalized classes, such as SensorData or even TelemetryData. Classes with no instances are called abstract classes. An abstract class is written with the expectation that its subclasses will add to its structure and behavior, usually by completing the implementation of its (typi- cally) incomplete methods.
There is a very real tension between inheritance and encapsulation. To a large degree, the use of inheritance exposes some of the secrets of an inherited class. Practically, this means that to understand the meaning of a particular class, you must often study all of its superclasses, sometimes including their inside views.
Inheritance means that subclasses inherit the structure of their superclass. Thus, in Example 3–5, the instances of the class ElectricalData include the data members of the superclass (such as id and timestamp), as well as those of the more specialized classes (such as fuelCell1Voltage, fuelCell2Voltage, fuelCell1Amperes, and fuelCell2Amperes).
www.Vidyarthiplus.com www.Vidyarthiplus.com
102 SECTION ICONCEPTS
Figure 3–9 Single Inheritance
Subclasses also inherit the behavior of their superclasses. Thus, instances of the class ElectricalData may be acted on with the operations currentTime (inherited from its superclass), currentPower (defined in the class itself), and transmit (redefined in the subclass).
Polymorphism
For the class TelemetryData, the function transmit may transmit the iden- tifier of the telemetry stream and its timestamp. But the same function for the class ElectricalData may invoke the TelemetryData transmit func- tion and also transmit its voltage and current values.
This behavior is due to polymorphism. In a generalization, such operations are called polymorphic. Polymorphism is a concept in type theory wherein a name may denote instances of many different classes as long as they are related by some common superclass. Any object denoted by this name is thus able to respond to some common set of operations in different ways. With polymor- phism, an operation can be implemented differently by the classes in the hierar- chy. In this manner, a subclass can extend the capabilities of its superclass or override the parent’s operation, as ElectricalData does in Example 3–5.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 103
The concept of polymorphism was first described by Strachey [29], who spoke of ad hoc polymorphism, by which symbols such as + could be defined to mean different things. We call this concept overloading. In C++, one may declare functions having the same names, as long as their invocations can be distin- guished by their signatures, consisting of the number and types of their arguments (in C++, unlike Ada, the type of a function’s returned value is not considered in overload resolution). By contrast, Java does not permit overloaded operators. Strachey also spoke of parametric polymorphism, which today we simply call polymorphism.
Without polymorphism, the developer ends up writing code consisting of large case or switch statements.6 Without it, we cannot create a hierarchy of classes for the various kinds of telemetry data; rather, we have to define a single, monolithic variant record encompassing the properties associated with all the kinds of data. To distinguish one variant from another, we have to examine the tag associated with the record.
To add another kind of telemetry data, we would have to modify the variant record and add it to every case statement that operated on instances of this record. This is particularly error-prone and, furthermore, adds instability to the design.
In the presence of inheritance, there is no need for a monolithic type since we may separate different kinds of abstractions. As Kaplan and Johnson note, “Poly- morphism is most useful when there are many classes with the same protocols” [30]. With polymorphism, large case statements are unnecessary because each object implicitly knows its own type.
Inheritance without polymorphism is possible, but it is certainly not very useful.
Polymorphism and late binding go hand in hand. In the presence of polymor- phism, the binding of a method to a name is not determined until execution. In C++, the developer may control whether a member function uses early or late binding. Specifically, if the method is declared as virtual, then late binding is employed, and the function is considered to be polymorphic. If this virtual decla- ration is omitted, then the method uses early binding and thus can be resolved at the time of compilation. Java simply performs late binding without the need for an explicit declaration such as virtual. How an implementation selects a par- ticular method for execution is described in the sidebar, Invoking a Method.
6. This is in fact the litmus test for polymorphism. The existence of a switch statement that selects an action based on the type of an object is often a warning sign that the developer has failed to apply polymorphic behavior effectively.
www.Vidyarthiplus.com www.Vidyarthiplus.com
104 SECTION ICONCEPTS
Invoking a Method
In traditional programming languages, invoking a subprogram is a completely static activity. In Pascal, for example, for a statement that calls the subprogram P, a compiler will typically generate code that creates a new stack frame, places the proper arguments on the stack, and then changes the flow of control to begin executing the code associated with P. However, in languages that support some form of polymorphism, such as Smalltalk and C++, invok- ing an operation may require a dynamic activity because the class of the object being operated on may not be known until runtime. Matters are even more interesting when we add inheritance to the situation. The semantics of invoking an operation in the presence of inheritance without polymorphism is largely the same as for a simple static subprogram call, but in the pres- ence of polymorphism, we must use a much more sophisticated technique. Consider the class hierarchy in Figure 3–10, which shows the base class DisplayItem along with three subclasses named Circle, Triangle, and Rectangle. Rectangle also has one subclass, named SolidRectangle. In the class DisplayItem, suppose that we define the instance variable theCenter (denoting the coordinates for the center of the displayed item), along with the following operations as in our earlier example:
■ draw Draw the item. ■ move Move the item. ■ location Return the location of the item. The operation location is common to all subclasses and therefore need not be redefined, but we expect the operations draw and move to be rede- fined since only the subclasses know how to draw and move themselves.
Figure 3–10 DisplayItem Class Diagram www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 105
The class Circle must include the instance variable theRadius and appropriate operations to set and retrieve its value. For this subclass, the redefined operation draw draws a circle of the given radius, centered on theCenter. Similarly, the class Rectangle must include the instance variables theHeight and theWidth, along with appropriate operations to set and retrieve their values. For this subclass, the operation draw draws a rectangle with the given height and width, again centered on theCenter. The subclass SolidRectangle inherits all characteristics of the class Rectangle but again redefines the behavior of the operation draw. Specifically, the implementation of draw for the class SolidRectangle first calls draw as defined in its superclass Rectangle (to draw the outline of the rectangle) and then fills in the shape. The invocation of draw demands polymorphic behavior. Suppose now that we have some client object that wishes to draw all of the subclasses. In this situation, the compiler cannot statically generate code to invoke the proper draw operation because the class of the object being operated on is not known until runtime. Let’s consider how various object- oriented programming languages deal with this situation. Because Smalltalk is a typeless language, method dispatch is completely dynamic. When the client sends the message draw to an item found in the list, here is what happens.
■ The item object looks up the message in its class’s message dictionary. ■ If the message is found, the code for that locally defined method is invoked. ■ If the message is not found, the search for the method continues in the superclass. This process continues up the superclass hierarchy until the message is found or until we reach the topmost base class, Object, without finding the message. In the latter case, Smalltalk ultimately passes the message doesNotUnderstand to signal an error. The key to this algorithm is the message dictionary, which is part of each class’s representation and is therefore hidden from the client. This dictio- nary is created when the class is created and contains all the methods to which instances of this class may respond. Searching for the message is time-consuming; method lookup in Smalltalk takes about 1.5 times as long as a simple subprogram call. All production-quality Smalltalk implementa- tions optimize method dispatch by supplying a cached message dictionary, so that commonly passed messages may be invoked quickly. Caching typi- cally improves performance by 20% to 30% [31]. The operation draw defined in the subclass SolidRectangle poses a special case. We said that its implementation of draw first calls draw as
www.Vidyarthiplus.com www.Vidyarthiplus.com
106 SECTION ICONCEPTS
defined in the superclass Rectangle. In Smalltalk, we specify a super- class method by using the keyword super. Then, when we pass the mes- sage draw to super, Smalltalk uses the same method-dispatch algorithm as mentioned earlier, except that the search begins in the superclass of the object instead of its class. Studies by Deutsch suggest that polymorphism is not needed about 85% of the time, so message passing can often be reduced to simple procedure calls [32]. Duff notes that in such cases, the developer often makes implicit assumptions that permit an early binding of the object’s class [33]. Unfortu- nately, typeless languages such as Smalltalk have no convenient means for communicating these implicit assumptions to the compiler. More strongly typed languages such as C++ do let the developer assert such information. Because we want to avoid method dispatch wherever possible but must still allow for the occurrence of polymorphic dispatch, invoking a method in these languages proceeds a little differently than in Smalltalk. In C++, the developer can decide whether a particular operation is to be bound late by declaring it to be virtual; all other methods are considered to be bound early, and thus the compiler can statically resolve the method call to a simple subprogram call. To handle virtual member functions, most C++ implementations use the concept of a vtable, which is defined for each object requiring polymorphic dispatch, when the object is created (and thus when the class of the object is fixed). This table typically consists of a list of pointers to virtual functions. For example, if we create an object of the class Rectangle, then the vtable will have an entry for the virtual function draw, pointing to the closest implementation of draw. If, for example, the class DisplayItem included the virtual function Rotate, which was not redefined in the class Rectan- gle, then the vtable entry for Rotate would point to the implementation of Rotate in the class DisplayItem. In this manner, runtime searching is eliminated: Referring to a virtual member function of an object is just an indirect reference through the appropriate pointer, which immediately invokes the correct code without searching [34].
Multiple Inheritance
With single inheritance, each subclass has exactly one superclass. However, as Vlissides and Linton point out, although single inheritance is very useful, “it often forces the programmer to derive from one of two equally attractive classes. This limits the applicability of predefined classes, often making it necessary to dupli- cate code. For example, there is no way to derive a graphic that is both a circle and a picture; one must derive from one or the other and reimplement the func- tionality of the class that was excluded” [40].
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 107
Consider for a moment how one might organize various assets such as savings accounts, real estate, stocks, and bonds. Savings accounts and checking accounts are both kinds of assets typically managed by a bank, so we might classify both of them as kinds of bank accounts, which in turn are kinds of assets. Stocks and bonds are managed quite differently than bank accounts, so we might classify stocks, bonds, mutual funds, and the like as kinds of securities, which in turn are also kinds of assets.
However, there are many other equally satisfactory ways to classify savings accounts, real estate, stocks, and bonds. For example, in some contexts, it may be useful to distinguish insurable items such as real estate and certain bank accounts (which, in the United States, are insured up to certain limits by the Federal Deposit Insurance Corporation). It may also be useful to identify assets that return a dividend or interest, such as savings accounts, checking accounts, and certain stocks and bonds.
Unfortunately, single inheritance is not expressive enough to capture this lattice of relationships, so we must turn to multiple inheritance.7 Figure 3–11 illustrates such a class structure. Here we see that the class Security is a kind of Asset as well as a kind of InterestBearingItem. Similarly, the class BankAccount is a kind of Asset, as well as a kind of InsurableItem and InterestBearingItem.
Designing a suitable class structure involving inheritance, and especially involving multiple inheritance, is a difficult task. This is often an incremental and iterative process. Two problems present themselves when we have multiple inher- itance: How do we deal with name collisions from different superclasses, and how do we handle repeated inheritance?
Name collisions are possible when two or more different superclasses use the same name for some element of their interfaces, such as instance variables and methods. For example, suppose that the classes InsurableItem and Asset both have attributes named presentValue, denoting the present value of the item. Since the class RealEstate inherits from both of these classes, what does
7. In fact, this is the litmus test for multiple inheritance. If we encounter a class lattice wherein the leaf classes can be grouped into sets denoting orthogonal behavior (such as in- surable and interest-bearing items), and these sets overlap, this is an indication that, within a single inheritance lattice, no intermediate classes exist to which we can cleanly attach these behaviors without violating our abstraction of certain leaf classes by granting them behaviors that they should not have. We can remedy this situation by using multiple inher- itance to mix in these behaviors only where we want them.
www.Vidyarthiplus.com www.Vidyarthiplus.com
108 SECTION ICONCEPTS
Figure 3–11 Multiple Inheritance
it mean to inherit two operations with the same name? This in fact is the key difficulty with multiple inheritance: Clashes may introduce ambiguity in the behavior of the multiply inherited subclass.
There are three basic approaches to resolving this kind of clash. First, the lan- guage semantics might regard such a clash as illegal and reject the compilation of the class. Second, the language semantics might regard the same name introduced by different classes as referring to the same attribute. Third, the language seman-
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 109 tics might permit the clash but require that all references to the name fully qualify the source of its declaration.
The second problem is repeated inheritance, which Meyer describes as follows: “One of the delicate problems raised by the presence of multiple inheritance is what happens when a class is an ancestor of another in more than one way. If you allow multiple inheritance into a language, then sooner or later someone is going to write a class D with two parents B and C, each of which has a class A as a par- ent—or some other situation in which D inherits twice (or more) from A. This sit- uation is called repeated inheritance and must be dealt with properly” [41]. As an example, suppose that we define the (ill-conceived) MutualFund class as a sub- class of the classes Stock and Bond. This class introduces repeated inheritance of the class Security, which is a superclass of both Stock and Bond (see Figure 3–11).
There are various approaches to dealing with the problem of repeated inheritance. First, we can treat occurrences of repeated inheritance as illegal. Second, we can permit duplication of superclasses but require the use of fully qualified names to refer to members of a specific copy. Third, we can treat multiple references to the same class as denoting the same class. Different languages handle this approach differently.
The existence of multiple inheritance gives rise to a style of classes called mixins. Mixins derive from the programming culture surrounding the language Flavors: One would combine (mix in) little classes to build classes with more sophisticated behavior. “A mixin is syntactically identical to a regular class, but its intent is dif- ferent. The purpose of such a class is solely to . . . [add] functions to other flavors [classes]—one never creates an instance of a mixin” [44]. In Figure 3–11, the classes InsurableItem and InterestBearingItem are mixins. Neither of these classes can stand alone; rather, they are used to augment the meaning of some other class. Thus, we may define a mixin as a class that embodies a single, focused behavior and is used to augment the behavior of some other class via inheritance. The behavior of a mixin is usually completely orthogonal to the behavior of the classes with which it is combined. A class that is constructed pri- marily by inheriting from mixins and does not add its own structure or behavior is called an aggregate class.
Aggregation
We also need aggregation relationships, which provide the whole/part relation- ships manifested in the class’s instances. Aggregation relationships among classes have a direct parallel to aggregation relationships among the objects corresponding to these classes.
www.Vidyarthiplus.com www.Vidyarthiplus.com
110 SECTION ICONCEPTS
Figure 3–12 Aggregation
As we show in Figure 3–12, the class TemperatureController denotes the whole, and the class Heater is one of its parts. This corresponds exactly to the aggregation relationship among the instances of these classes illustrated earlier in Figure 3–6.
Physical Containment
In the case of the class TemperatureController, we have aggregation as containment by value, a kind of physical containment meaning that the Heater object does not exist independently of its enclosing TemperatureController instance. Rather, the lifetimes of these two objects are intimately connected: When we create an instance of TemperatureController, we also create an instance of the class Heater. When we destroy our TemperatureController object, by implication we also destroy the corresponding Heater object.
A less direct kind of aggregation is also possible, called composition, which is containment by reference. In this case, the class TemperatureController still denotes the whole, and an instance of the class Heater is still one of its parts, although that part must now be accessed indirectly. Hence, the lifetimes of these two objects are not so tightly coupled as before: We may create and destroy instances of each class independently.
Aggregation asserts a direction to the whole/part relationship. For example, the Heater object is a part of the TemperatureController object, and not vice versa. Of course, as we described in an earlier example, aggregation need not require physical containment. For example, although shareholders own stocks, a shareholder does not physically contain the owned stocks. Rather, the lifetimes of these objects may be completely independent, although there is still conceptually a whole/part relationship (each share is always a part of the shareholder’s assets). Representation of this aggregation can be very indirect.
This is still aggregation, although not physical containment. Ultimately, the lit- mus test for aggregation is this: If and only if there exists a whole/part relation- ship between two objects, we must have an aggregation relationship between their corresponding classes.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 111
Multiple inheritance is often confused with aggregation. When considering inher- itance versus aggregation, remember to apply the litmus test for each. If you can- not honestly affirm that there is an “is a” relationship between two classes, aggregation or some other relationship should be used instead of inheritance.
Dependencies
Aside from inheritance, aggregation, and association, there is another group of relationships called dependencies. A dependency indicates that an element on one end of the relationship, in some manner, depends on the element on the other end of the relationship. This alerts the designer that if one of these elements changes, there could be an impact to the other. There are many different kinds of depen- dency relationships (refer to the Object Management Group’s latest UML specifi- cation for the full list [45]). You will often see dependencies used in architectural models (one system component, or package, is dependent on another) or at the implementation level (one module is dependent on another).
3.5 The Interplay of Classes and Objects
Classes and objects are separate yet intimately related concepts. Specifically, every object is the instance of some class, and every class has zero or more instances. For practically all applications, classes are static; therefore, their exist- ence, semantics, and relationships are fixed prior to the execution of a program. Similarly, the class of most objects is static, meaning that once an object is cre- ated, its class is fixed. In sharp contrast, however, objects are typically created and destroyed at a furious rate during the lifetime of an application.
Relationships between Classes and Objects
For example, consider the classes and objects in the implementation of an air traf- fic control system. Some of the more important abstractions include planes, flight plans, runways, and air spaces. By their very definition, the meanings of these classes and objects are relatively static. They must be static, for otherwise one could not build an application that embodied knowledge of such commonsense facts as that planes can take off, fly, and then land, and that two planes should not occupy the same space at the same time. Conversely, the instances of these classes are dynamic. At a fairly slow rate, new runways are built, and old ones are deacti- vated. Faster yet, new flight plans are filed, and old ones are filed away. With great frequency, new planes enter a particular air space, and old ones leave.
www.Vidyarthiplus.com www.Vidyarthiplus.com
112 SECTION ICONCEPTS
The Role of Classes and Objects in Analysis and Design
During analysis and the early stages of design, the developer has two primary tasks:
1. Identify the classes that form the vocabulary of the problem domain 2. Invent the structures whereby sets of objects work together to provide the behaviors that satisfy the requirements of the problem
Collectively, we call such classes and objects the key abstractions of the problem, and we call these cooperative structures the mechanisms of the implementation.
During these phases of development, the developer must focus on the outside view of these key abstractions and mechanisms. This view represents the logical framework of the system and therefore encompasses the class structure and object structure of the system. In the later stages of design and then moving into imple- mentation, the task of the developer changes: The focus is on the inside view of these key abstractions and mechanisms, involving their physical representation.
3.6 On Building Quality Classes and Objects
Ingalls suggests that “a system should be built with a minimum set of unchange- able parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework” [51]. With object-oriented development, these parts are the classes and objects that make up the key abstractions of the system, and the framework is provided by its mechanisms.
In our experience, the design of classes and objects is an incremental, iterative process. Frankly, except for the most trivial abstractions, we have never been able to define a class exactly right the first time. It takes time to smooth the conceptual jagged edges of our initial abstractions. Of course, there is a cost to refining these abstractions, in terms of recompilation, understandability, and the integrity of the fabric of our system design. Therefore, we want to come as close as we can to being right the first time.
Measuring the Quality of an Abstraction
How can one know if a given class or object is well designed? We suggest five meaningful metrics:
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 113
1. Coupling 2. Cohesion 3. Sufficiency 4. Completeness 5. Primitiveness
Coupling is a notion borrowed from structured design, but with a liberal interpre- tation it also applies to object-oriented design. Stevens, Myers, and Constantine define coupling as “the measure of the strength of association established by a connection from one module to another. Strong coupling complicates a system since a module is harder to understand, change, or correct by itself if it is highly interrelated with other modules. Complexity can be reduced by designing systems with the weakest possible coupling between modules” [52]. A counterexample to good coupling is given by Page-Jones in his description of a modular stereo sys- tem in which the power supply is located in one of the speaker cabinets [53].
Coupling with regard to modules still applies to object-oriented analysis and design, but coupling with regard to classes and objects is equally important. How- ever, there is tension between the concepts of coupling and inheritance because inheritance introduces significant coupling. On the one hand, weakly coupled classes are desirable; on the other hand, inheritance—which tightly couples superclasses and their subclasses—helps us to exploit the commonality among abstractions.
The idea of cohesion also comes from structured design. Simply stated, cohesion measures the degree of connectivity among the elements of a single module (and for object-oriented design, a single class or object). The least desirable form of cohesion is coincidental cohesion, in which entirely unrelated abstractions are thrown into the same class or module. For example, consider a class comprising the abstractions of dogs and spacecraft, whose behaviors are quite unrelated. The most desirable form of cohesion is functional cohesion, in which the elements of a class or module all work together to provide some well-bounded behavior. Thus, the class Dog is functionally cohesive if its semantics embrace the behavior of a dog, the whole dog, and nothing but the dog.
Closely related to the ideas of coupling and cohesion are the criteria that a class or module should be sufficient, complete, and primitive. By sufficient, we mean that the class or module captures enough characteristics of the abstraction to permit meaningful and efficient interaction. To do otherwise renders the component use- less. For example, if we are designing the class Set, it is wise to include an oper- ation that removes an item from the set, but our wisdom is futile if we neglect an operation that adds an item. In practice, violations of this characteristic are detected very early; such shortcomings rise up almost every time we build a client that must use this abstraction.
www.Vidyarthiplus.com www.Vidyarthiplus.com
114 SECTION ICONCEPTS
By complete, we mean that the interface of the class or module captures all of the meaningful characteristics of the abstraction. Whereas sufficiency implies a mini- mal interface, a complete interface is one that covers all aspects of the abstraction. A complete class or module is thus one whose interface is general enough to be commonly usable to any client. Completeness is a subjective matter, and it can be overdone. Providing all meaningful operations for a particular abstraction over- whelms the user and is generally unnecessary since many high-level operations can be composed from low-level ones. For this reason, we also suggest that classes and modules be primitive.
Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction. Thus, adding an item to a set is primitive because to implement this operation Add, the underlying repre- sentation must be visible. On the other hand, an operation that adds four items to a set is not primitive because it can be implemented just as efficiently on the more primitive Add operation, without having access to the underlying representation. Of course, efficiency is also a subjective measure. An operation is indisputably primitive if we can implement it only through access to the underlying representa- tion. An operation that could be implemented on top of existing primitive opera- tions, but at the cost of significantly more computational resources, is also a candidate for inclusion as a primitive operation.
Choosing Operations
Crafting the interface of a class or module is plain hard work. Typically, we make a first attempt at the design of a class, and then, as we and others create clients, we find it necessary to augment, modify, and further refine this interface. Eventu- ally, we may discover patterns of operations or patterns of abstractions that lead us to invent new classes or to reorganize the relationships among existing ones.
We often can identify patterns of abstraction, structure, or behavior.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 115
Functional Semantics
Within a given class, it is our style to keep all operations primitive, so that each exhibits a small, well-defined behavior. We call such methods fine-grained. We also tend to separate methods that do not communicate with one another. In this manner, it is far easier to construct subclasses that can meaningfully redefine the behavior of their superclasses. The decision to contract out a behavior to one ver- sus many methods may be made for two competing reasons: Lumping a particular behavior in one method leads to a simpler interface but larger, more complicated methods; spreading a behavior across methods leads to a more complicated inter- face but simpler methods. As Meyer observes, “A good designer knows how to find the appropriate balance between too much contracting, which produces frag- mentation, and too little, which yields unmanageably large modules” [54].
It is common in object-oriented development to design the methods of a class as a whole because all these methods cooperate to form the entire protocol of the abstraction. Thus, given some desired behavior, we must decide in which class to place it. Halbert and O’Brien offer the following criteria to be considered when making such a decision [55].
■ Reusability: Would this behavior be more useful in more than one context? ■ Complexity: How difficult is it to implement the behavior? ■ Applicability: How relevant is the behavior to the type in which it might be placed? ■ Implementation knowledge: Does the behavior’s implementation depend on the internal details of a type?
We usually choose to declare the meaningful operations that we may perform on an object as methods in the definition of that object’s class (or superclass).
Time and Space Semantics
Once we have established the existence of a particular operation and defined its functional semantics, we must decide on its time and space semantics. This means that we must specify our decisions about the amount of time it takes to complete an operation and the amount of storage it needs. Such decisions are often expressed in terms of best, average, and worst cases, with the worst case specifying an upper limit on what is acceptable.
Earlier, we also mentioned that whenever one object passes a message to another across a link, the two objects must be synchronized in some manner. In the pres- ence of multiple threads of control, this means that message passing is much more than a subprogram-like dispatch. In most of the languages we use, synchronization
www.Vidyarthiplus.com www.Vidyarthiplus.com
116 SECTION ICONCEPTS
among objects is simply not an issue because our programs contain exactly one thread of control, meaning that all objects are sequential. We speak of message passing in such situations as simple because its semantics are most akin to simple subprogram calls. However, in languages that support concurrency, we must con- cern ourselves with more sophisticated forms of message passing, so as to avoid the problems created if two threads of control act on the same object in unre- strained ways. As we described earlier, objects whose semantics are preserved in the presence of multiple threads of control are either guarded or synchronized objects.
Choosing Relationships
Choosing the relationships among classes and among objects is linked to the selection of operations. If we decide that object X sends message M to object Y, then either directly or indirectly, Y must be accessible to X; otherwise, we could not name the operation M in the implementation of X. By accessible, we mean the ability of one abstraction to see another and reference resources in its outside view. Abstractions are accessible to one another only where their scopes overlap and only where access rights are granted (e.g., private parts of a class are accessi- ble only to the class itself and its friends). Coupling is thus a measure of the degree of accessibility.
The Law of Demeter
One useful guideline in choosing the relationships among objects is called the Law of Demeter, which states that “the methods of a class should not depend in any way on the structure of any class, except the immediate (top-level) structure of their own class. Further, each method should send messages to objects belong- ing to a very limited set of classes only” [56]. The basic effect of applying this law is the creation of loosely coupled classes, whose implementation secrets are encapsulated. Such classes are fairly unencumbered, meaning that to understand the meaning of one class, you need not understand the details of many other classes.
In looking at the class structure of an entire system, we may find that its inherit- ance hierarchy is wide and shallow, narrow and deep, or balanced. Class struc- tures that are wide and shallow usually represent forests of free-standing classes that can be mixed and matched [57]. Class structures that are narrow and deep represent trees of classes that are related by a common ancestor [58]. There are advantages and disadvantages to each approach. Forests of classes are more loosely coupled, but they may not exploit all the commonality that exists. Trees of classes exploit this commonality, so that individual classes are smaller than in for- ests. However, to understand a particular class, it is usually necessary to under-
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 117 stand the meaning of all the classes it inherits from or uses. The proper shape of a class structure is highly problem-dependent.
We must make similar trade-offs among inheritance, aggregation, and depen- dency relationships. For example, should the class Car inherit, contain, or use the classes named Engine and Wheel? In this case, we suggest that an aggregation relationship is more appropriate than an inheritance relationship. Meyer states that between the classes A and B, “inheritance is appropriate if every instance of B may also be viewed as an instance of A. The client relationship is appropriate when every instance of B simply possesses one or more attributes of A” [59]. From another perspective, if the behavior of an object is more than the sum of its individual parts, creating an aggregation relationship rather than an inheritance relationship between the appropriate classes is probably superior.
Mechanisms and Visibility
Deciding on the relationship among objects is mainly a matter of designing the mechanisms whereby these objects interact. The question the developer must ask is simply this: Where does certain knowledge go? For example, in a manufactur- ing plant, materials (called lots) enter manufacturing cells to be processed. As they enter certain cells, we must notify the room’s manager to take appropriate action. We now have a design choice: Is the entry of a lot into a room an operation on the room, an operation on the lot, or an operation on both? If we decide that it is an operation on the room, the room must be visible to the lot. If we decide that it is an operation on the lot, the lot must be visible to the room because the lot must know what room it is in. Lastly, if we consider this to be an operation on both the room and the lot, we must arrange for mutual visibility. We must also decide on some visibility relationship between the room and the manager (and not the lot and the manager); either the manager must know the room it manages, or the room must know of its manager.
Choosing Implementations
Only after we stabilize the outside view of a given class or object do we turn to its inside view. This perspective involves two different decisions: a choice of repre- sentation for a class or object and the placement of the class or object in a module.
Representation
The representation of a class or object should almost always be one of the encap- sulated secrets of the abstraction. This makes it possible to change the representa- tion (e.g., to alter the time and space semantics) without violating any of the
www.Vidyarthiplus.com www.Vidyarthiplus.com
118 SECTION ICONCEPTS
functional assumptions that clients may have made. As Wirth wisely states, “The choice of representation is often a fairly difficult one, and it is not uniquely deter- mined by the facilities available. It must always be taken in light of the operations that are to be performed upon the data” [60]. For example, given a class whose objects denote a set of flight-plan information, do we optimize the representation for fast searching or for fast insertion and deletion? We cannot optimize for both, so our choice must be based on the expected use of these objects. Sometimes it is not easy to choose, and we end up with families of classes whose interfaces are virtually identical but whose implementations are radically different, in order to provide different time and space behavior.
One of the more difficult trade-offs when selecting the implementation of a class is between computing the value of an object’s state versus storing it as a field. For example, suppose we have the class Cone, which includes the method Volume. Invoking this method returns the volume of the object. As part of the representa- tion of this class, we are likely to use fields for the height of the cone and the radius of its base. Should we have an additional field in which we store the vol- ume of the object, or should the method Volume just calculate it every time [61]? If we want this method to be fast, we should store the volume as a field. If space efficiency is more important to us, we should calculate the value. Which represen- tation is better depends entirely on the particular problem. In any case, we should be able to choose an implementation independently of the class’s outside view; indeed, we should even be able to change this representation without its clients caring.
Packaging
Similar issues apply to the declaration of classes and objects within modules. The competing requirements of visibility and information hiding usually guide our design decisions about where to declare classes and objects. Generally, we seek to build functionally cohesive, loosely coupled modules. Many nontechnical factors influence these decisions, such as matters of reuse, security, and documentation. Like the design of classes and objects, module design is not to be taken lightly. As Parnas, Clements, and Weiss note with regard to information hiding, “Applying this principle is not always easy. It attempts to minimize the expected cost of soft- ware over its period of use and requires that the designer estimate the likelihood of changes. Such estimates are based on past experience and usually require knowledge of the application area as well as an understanding of hardware and software technology” [63].
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 3CLASSES AND OBJECTS 119
Summary
■ An object has state, behavior, and identity. ■ The structure and behavior of similar objects are defined in their common class. ■ The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties. ■ Behavior is how an object acts and reacts in terms of its state changes and message passing. ■ Identity is the property of an object that distinguishes it from all other objects. ■ A class is a set of objects that share a common structure and a common behavior. ■ The three kinds of relationships include association, inheritance, and aggregation. ■ Key abstractions are the classes and objects that form the vocabulary of the problem domain. ■ A mechanism is a structure whereby a set of objects work together to pro- vide a behavior that satisfies some requirement of the problem. ■ The quality of an abstraction may be measured by its coupling, cohesion, sufficiency, completeness, and primitiveness.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Object oriented analysis
The purpose of any analysis activity in the software life-cycle is to create a model of the system's functional requirements that is independent of implementation constraints.
The main difference between object-oriented analysis and other forms of analysis is that by the object-oriented approach we organize requirements around objects, which integrate both behaviors (processes) and states (data) modeled after real world objects that the system interacts with. In other or traditional analysis methodologies, the two aspects: processes and data are considered separately. For example, data may be modeled by ER diagrams, and behaviors by flow charts or structure charts.
The primary tasks in object-oriented analysis (OOA) are:
• Find the objects • Organize the objects • Describe how the objects interact • Define the behavior of the objects • Define the internals of the objects
Common models used in OOA are use cases and object models. Use cases describe scenarios for standard domain functions that the system must accomplish. Object models describe the names, class relations (e.g. Circle is a subclass of Shape), operations, and properties of the main objects. User-interface mockups or prototypes can also be created to help understanding.
Mechanism of Object-oriented Approach
The principals of objects, encapsulation, inheritance, and polymorphism are the foundation for object-oriented systems development. To understand and express the essential and interesting features of an application in the complex real world, an object- oriented model is built around objects. An object encapsulates both data and behavior, implying that analysts can use the object-oriented approach for both data modeling and process modeling.
Specific objects in a system can inherit characteristics from the global instance of an object. For example, many types of objects may have a name and a creation date. Specific objects can inherit these global characteristics from parent objects that include only global characteristics. Objects can inherit characteristics from more than one parent object. Inheritance attempts to avoid the redundant definition of similar characteristics that can be embodied at higher levels in the system
By a concept called polymorphism, functionality that is conceptually similar among differing objects is extracted to a global level. This process limits the production of parallel functionality and streamlines the information interface. Polymorphism directs the
www.Vidyarthiplus.com www.Vidyarthiplus.com
specification writer to understand the functionality of a process and make it available to any object that requires a similar instance of functionality
Unified Modeling Language
The Unified Modeling Language (UML) is an object-oriented language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling (UML Document Set, 2001). The UML was developed by Rational Software and its partners. It is the successor to the modeling languages found in the Booch (Booch 1994), OOSE/Jacobson, OMT and other methods.
By offering a common blueprinting language, UML relieves developers of the proprietary ties that are so common in this industry. Major vendors including IBM, Microsoft, and Oracle are brought together under the UML umbrella. And because UML uses simple, intuitive notation, nonprogrammers can also understand UML models. In fact, many of the language's supporters claim that UML's simplicity is its chief benefit. If developers, customers, and implementers can all understand a UML diagram, they are more likely to agree on the intended functionality, thereby improving their chances of creating an application that truly solves a business problem (Apicella 2000).
The UML, a visual modeling language, is not intended to be a visual programming language. The UML notation is useful for graphically depicting object-oriented analysis and design models. It not only allows you to specify the requirements of a system and capture the design decisions, but it also promotes communication among key persons involved in the development effort . The emphasis in modeling should be on analysis and design, focusing on front-end conceptual issues, rather than back-end implementation issues, which unnecessarily restrict design choices
Analysis Process
In the analysis phase, a model of the real-world application is developed showing its important properties. It abstracts concepts from the application domain and describes what the intended system must do, rather than how it will be done.
Extant object-oriented approaches can be classified into three categories (Monarchi & Puhr, 1992): (1) combinative approaches use different modeling techniques in different stages of the system development process; (2) adaptive approaches apply existing techniques (e.g., data-flow diagram and entity-relationship approach) in object-oriented ways to analyze the problem domain; and (3) pure approaches adopt an object-oriented perspective in systems analysis and design.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Despite various ways to do modeling, this paper focuses on use-case modeling and class modeling to explore how system analysis are conducted under different methods.
Use-case Modeling
First adopted by Jacobson et al. (1992), use-case modeling is developed in the analysis phase of the object-oriented system development life cycle. Use-case modeling is done in the early stages of system development to help developers gain a clear understanding of the functional requirement of the system, without worrying about how those requirements will be implemented.
A use-case is a representation of a discrete set of work performed by a use (or another system) using the operational system (). A use-case model consists of actors and use cases. An actor is an external entity that interacts with the system and a use case represents a sequence of related actions initiated by an actor to accomplish a specific goal (Hoffer et al. 2002).
For identifying use cases, Jacobson et al. (1992) recommend to ask the following questions:
www.Vidyarthiplus.com www.Vidyarthiplus.com
· What are the main tasks performed by each actor? · Will the actor read or update any information in the system? · Will the actor have to inform the system about changes outside the system? · Does the actor have to be informed about unexpected changes?
In UML, a use-case model is depicted in a use-case diagram that contains the use cases and actors for a system. Begin working with the UML by modeling all scenarios in the system or business with Use Case diagrams. Describe the system in terms of actors, which are external agents that request a service from the system, and Use Cases. Each Use Case can be defined simply by a textual statement that describes the scenario, or via other definitions, such as the sequence of steps that are performed within the scenario, or the pre- and post-conditions of the scenario (Popking 2001).
A use-case may interact with other use-cases. Some of these relationships include extend and use and are reflected by single hollow arrow lines. For instance, Cancel Reservation use case uses information from Customer Requests Cancellation use case or Cancel Unconfirmed Reservation use case to finalize the actual cancellation of reservations.
While a use-case diagram shows all the use cases in the system, it does not describe how those use cases are carried out by the actors. The contents of a use case are normally described in plain text. While describing a use case, you should focus on its external behavior, that is, how is interacts with the actors, rather than how the use case is performed inside the system (Eriksson and Penker, 1998).
Also called system usage modeling, a use case modeling, at requirements analysis stage, consists of a Use Case Diagram plus a set of descriptions as well as illustrations of prototype screens.
One of the benefits of use-case or system usage modeling is its simplicity. The strength of the technique is in its non-technical simplicity, which allows users to participate in a way that is seldom possible using the abstractions of Class Modeling alone. It also helps the analyst get to grip with specific user needs before analyzing the internal mechanics of a system. Use cases also fit particularly well within an evolutionary and incremental process in that they provide a basis for early prototyping and readily identifiable units for incremental delivery. They also provide a means of traceability for functional requirements upstream in the process and for constructing test plans downstream in the process. It is no accident therefore that use cases have become such a popular technique (Artisan 2001). In summary, (Artisan 2001) provides a complete list of the steps in system usage modeling as follows:
· Identify the actors. · Identify the use cases. · Create a Use Case Diagram. · Describe the use cases. · Complete the use case descriptions.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Class Modeling
There are many new terms in object-oriented approach. Some have already been introduced above. An object is the most fundamental element in OO approach, which has a well-defined role in the application domain, and has state, behavior, and identity. A class is a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment.
Object modeling, or class modeling is the key activity in object-oriented development. If the use cases contain errors, then all is not lost. If the class model contains errors then all may well be lost. The quality of the resulting system in object-oriented development is essentially a reflection of the quality of the class model. This is because the class model sets the underlying foundation upon which objects will be put to work. A quality class model should provide a flexible foundation upon which systems can be assembled in component-like fashion. A poor class model results in a shaky foundation upon which systems will grind to a halt and buckle under the threat of change (Artisan 2001).
Each of the diagrams used in UML lets you see a business process from a different angle. Business users, for example, can view use case diagrams to see the business scenario overview and understand who's doing what, while developers can use class and object diagrams to get accurate descriptions of how to build those components into their code. The class and object diagrams are so detailed, describing elements such as interfaces and attributes, that translating UML notation into actual programming code is a virtual no-brainer (Apicella 2000).
In UML, a class is represented by a rectangle with three compartments separated by horizontal lines, which hold, from top to bottom, class name, the list of attributes, and the list of operations.
A class diagram allows you to document how the class relates to other classes. The class diagram doesn't fix the actual implementation. The actual code might not be a direct translation of the diagram. However the functionality of the code will remain the same.
Object-oriented Analysis process
Object-oriented analysis starts with a traditional structured specification, and adds the following information:
• A list of all objects - A list describing the data contents of each noun, or physical entities in the DFD. • A list all system behaviors - A list of all verbs within the process names such as Prepare order summary report, generate invoices, etc.
www.Vidyarthiplus.com www.Vidyarthiplus.com
• A list of the associate the primary behaviors (services) with each object - Each object will have behaviors which uniquely belong to the object. Other objects may request the behavior of the object. • A description of the contracts in the system - A contract is an agreement between two objects, such that one object will invoke the services of the other. • A behavior script for each object - A script describes each initiator, action, participant, and service. • A classification for each object and the object relationships - Generate an entity/relationship model and a generalization hierarchy (IS-A) for each object, using traditional E/R or normalization techniques.
Over the past 12 years there have numerous books about different approaches to object analysis bit they all contain these common elements. Now that we see the basic analysis requirements, let's explore the basic methodologies for object-oriented analysis.
Different Models for Object Analysis
Unlike the traditional systems analysis where user requirements are gathered and then specifications are put on the requirements and users are then asked to sign off on the specifications, the object methodologies use a more iterative process where the requirements and specifications are reviewed repeatedly and the users are heavily involved.
Object technology has many different methodologies to help analyze and design computer systems. We will review four of the more popular systems: Rumbaugh, Booch, Coad-Yourdon, and Shlaer-Mellor. In most cases these methodologies are very similar, but each has its own way to graphically represent the entities. To understand and use these four methodologies would become difficult, if not impossible, for all projects. If need be, it is possible to use concepts from one method with concepts from another technique, basically creating your own object development technique. The most important point is to remember is that the final outcome is what really matters, not the choice of one analysis technique over another technique. Remember, it is more important to do proper analysis and design to meet user requirements than it is to just follow a blind, meaningless procedure.
The traditional systems development approach is sometimes referred to as the waterfall method. By waterfall, object analyst's follow a logical progression through analysis, design, coding, testing, and maintenance. Unfortunately system development seldom fits this kind of structured approach. End-users are notorious for changing their minds or identifying some feature that they forgot to identify. These changes in requirements can happen at any phase of system development and the analyst must struggle to accommodate these changes into the system. What it means to the systems analyst is that you have to go back to whatever step in the development life cycle and make the necessary changes that will then cascade these changes through the entire system. For example, suppose that our end-users are in the testing phase when they
www.Vidyarthiplus.com www.Vidyarthiplus.com
realize that they need an additional screen. This would require a change to the initial requirements document, which would, in turn, cascade to analysis, design, and so on.
The object-oriented methodologies require a more iterative process with the same five steps. The iterative process either adds new or more clearly defines existing properties, unlike the traditional approach that would re-hash specifications that are already done. The iterative process helps to reduce confusion around what the system is really suppose to do and what the users really want. The object-oriented software development methods make the assumption that user requirements will change. However it doesn't matter which programming language you use, be it FORTRAN or C++. Furthermore, it doesn't matter which system development technique you use, you will follow the same five steps in system development. It is just, how these five steps are applied that will make the difference in your system development project.
1. The Rumbaugh method
The Rumbaugh method is listed first because it is these authors favorite, and we find it a very friendly and easy methodology. For traditional system analyst's, the Rumbaugh's methodology is the closest to the traditional approach to system analysis and design, and beginners will recognize familiar symbols and techniques. The Rumbaugh methodology has its primary strength in object analysis but it also does an excellent job with object design. Rumbaugh has three deliverables to the object analysis phase; the Object model, the Dynamic model, and the functional model. These three models are similar to traditional system analysis, with the additions for the object model, including definitions of classes along with the classes variables and behaviors. The Rumbaugh object model is very much like an entity relationship diagram except that there are now behaviors in the diagram and class hierarchies. The dynamic model is a "state transition" diagram that shows how an entity changes from one state to another state. The functional model is the equivalent of the familiar data flow diagrams from a traditional systems analysis.
2. The Booch method
Booch's methodology has its primary strength in the object system design. Grady Booch has included in his methodology a requirements analysis that is similar to a traditional requirements analysis, as well as a domain analysis phase. Booch's object system design method has four parts, the logical structure design where the class hierarchies are defined, the physical structure diagram where the object methods are described. In addition, Booch defines the dynamics of classes in a fashion very similar to the Rumbaugh method, as well as an analysis of the dynamics of object instances, where he describes how an object may change state.
www.Vidyarthiplus.com www.Vidyarthiplus.com
3. The Coad-Yourdon method
Coad-Yourdon methodology has its primary strength in system analysis. Their methodology is based on a technique called "SOSAS", which stands for the five steps that help make up the analysis part of their methodology. The first step in system analysis is called "Subjects", which are basically data flow diagrams for objects. The second step is called "Objects", where they identify the object classes and the class hierarchies. The third step is called "Structures", where they decompose structures into two types, classification structures and composition structures. Classification structures handle the inheritance connection between related classes, while composition structures handle all of the other connections among classes. The next step in analysis is called "Attributes", and the final step is called "Services", where all of the behaviors or methods for each class are identified.
Following analysis, Coad and Yourdon define four parts that make up the design part of their methodology. The steps of system design are:
• The problem domain component - This will define the classes that should be in the problem domain. • The human interaction component - These steps defines the interface classes between objects. • The task management component - This is where system-wide management classes are identified. • The data management component - This design step identifies the classes needed for database access methods.
4. The Shlaer-Mellor method
Shlaer-Mellor methodology has its primary strength in system design and is considered somewhat weak on analysis. The Shlaer-Mellor methodology includes three models; the information model, the state model, and the process model. The information model contains objects, variables, and all the relationships between the objects, and is basically a data model for the system. The state model records the different states of objects and changes that can occur between the objects. The process model is really not much more than a traditional data flow diagram.
Now that we have covered the basics of the object approach, let's take a look at how a real-world object is created by using these techniques.
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-Oriented Analysis
The boundaries between analysis and design are fuzzy, although the focus of each is quite distinct. In analysis, the focus is to fully analyze the problem at hand and to model the world by discovering the classes and objects that form the vocabu- lary of the problem domain. In design, we invent the abstractions and mecha- nisms in our models that provide the design of the solution to be built.
In the following sections, we examine a number of proven approaches for analy- sis that are relevant to object-oriented systems.
Classical Approaches
A number of methodologists have proposed various sources of classes and objects, derived from the requirements of the problem domain. We call these approaches classical because they derive primarily from the principles of classi- cal categorization.
For example, Shlaer and Mellor suggest that candidate classes and objects usually come from one of the following sources [32]:
■ Tangible things Cars, telemetry data, pressure sensors ■ Roles Mother, teacher, politician ■ Events Landing, interrupt, request ■ Interactions Loan, meeting, intersection
www.Vidyarthiplus.com www.Vidyarthiplus.com
132 SECTION ICONCEPTS
From the perspective of database modeling, Ross offers a similar list [33]:
■ People Humans who carry out some function ■ Places Areas set aside for people or things ■ Things Physical objects, or groups of objects, that are tangible ■ OrganizationsFormally organized collections of people, resources, facilities, and capabilities having a defined mission, whose existence is largely independent of individuals ■ Concepts Principles or ideas not tangible per se; used to organize or keep track of business activities and/or communications ■ Events Things that happen, usually to something else at a given date and time, or as steps in an ordered sequence
Coad and Yourdon suggest yet another set of sources of potential objects [34]:
■ Structure “Is a” and “part of” relationships ■ Other systems External systems with which the application interacts ■ Devices Devices with which the application interacts ■ Events remembered A historical event that must be recorded ■ Roles played The different roles users play in interacting with the application ■ Locations Physical locations, offices, and sites important to the application ■ Organizational units Groups to which users belong
At a higher level of abstraction, Coad introduces the idea of subject areas, which are basically logical groups of classes that relate to some higher-level system function.
Behavior Analysis
Whereas these classical approaches focus on tangible things in the problem domain, another school of thought in object-oriented analysis focuses on dynamic behavior as the primary source of classes and objects.1 These approaches are
1. Shlaer and Mellor extended their earlier work to focus on behavior as well. In particular, they studied the lifecycle of each object as a means of understanding the boundaries [35].
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 4CLASSIFICATION 133 more akin to conceptual clustering: We form classes based on groups of objects that exhibit similar behavior.
Wirfs-Brock, Wilkerson, and Wiener, for example, emphasize responsibilities, which denote “the knowledge an object maintains and the actions an object can perform. Responsibilities are meant to convey a sense of the purpose of an object and its place in the system. The responsibilities of an object are all the services it provides for all of the contracts it supports” [36]. In this manner, we group things that have common responsibilities, and we form hierarchies of classes involving superclasses that embody general responsibilities and subclasses that specialize their behavior.
Rubin and Goldberg offer an approach to identifying classes and objects derived from system functions. As they suggest, “the approach we use emphasizes first understanding what takes place in the system. These are the system behaviors. We next assign these behaviors to parts of the system, and try to understand who ini- tiates and who participates in these behaviors. . . . Initiators and participants that play significant roles are recognized as objects, and are assigned the behavioral responsibilities for these roles” [37].
Rubin’s concept of system behavior is closely related to the idea of function points, first suggested in 1979 by Albrech. A function point is “defined as one end-user business function” [38]. A business function represents some kind of output, inquiry, input, file, or interface. Although the information-system roots of this definition show through, the idea of a function point generalizes to all kinds of automated systems: A function point is any relevant outwardly visible and test- able behavior of the system.
Domain Analysis
The principles we have discussed thus far are typically applied to the develop- ment of single, specific applications. Domain analysis, on the other hand, seeks to identify the classes and objects that are common to all applications within a given domain, such as patient record tracking, bond trading, compilers, or missile avi- onics systems. If you are in the midst of a design and stuck for ideas as to the key abstractions that exist, a narrow domain analysis can help by pointing you to the key abstractions that have proven useful in other related systems. Domain analy- sis works well because, except for special situations, there are very few truly unique kinds of software systems.
The idea of domain analysis was first suggested by Neighbors. We define domain analysis as “an attempt to identify the objects, operations, and relationships [that]
www.Vidyarthiplus.com www.Vidyarthiplus.com
134 SECTION ICONCEPTS
domain experts perceive to be important about the domain” [39]. Moore and Bailin suggest the following steps in domain analysis.
■ Construct a strawman generic model of the domain by consulting with domain experts. ■ Examine existing systems within the domain and represent this understanding in a common format. ■ Identify similarities and differences between the systems by consulting with domain experts. ■ Refine the generic model to accommodate existing systems. [40]
Domain analysis may be applied across similar applications (vertical domain analysis), as well as to related parts of the same application (horizontal domain analysis). For example, when starting to design a new patient-monitoring system, it is reasonable to survey the architecture of existing systems to understand what key abstractions and mechanisms were previously employed and to evaluate which were useful and which were not. Similarly, an accounting system must pro- vide many different kinds of reports. By considering these reports within the same application as a single domain, a domain analysis can lead the developer to an understanding of the key abstractions and mechanisms that serve all the different kinds of reports. The resulting classes and objects reflect a set of key abstractions and mechanisms generalized to the immediate report generation problem; there- fore, the resulting design is likely to be simpler than if each report had been ana- lyzed and designed separately.
Who exactly is a domain expert? Often, a domain expert is simply a user, such as a train engineer or dispatcher in a railway system, or a nurse or doctor in a hospi- tal. A domain expert typically will not be a software developer; more commonly, he or she is simply a person who is intimately familiar with all the elements of a particular problem. A domain expert speaks the vocabulary of the problem domain.
Some managers may be concerned with the idea of direct communication between developers and end users (for some, even more frightening is the pros- pect of letting an end user see a developer!). For highly complex systems, domain analysis may involve a formal process, using the resources of multiple domain experts and developers over a period of many months. Such a formal analysis is not necessary on all projects, particularly smaller projects. Often, all it takes to clear up a design problem is a brief meeting between a domain expert and an architect or developer. It is truly amazing to see what a little bit of domain knowl- edge can do to enable intelligent design decisions. Indeed, we find it highly useful to have many such meetings throughout the design of a system. Domain analysis is rarely a monolithic activity; it is better focused if we consciously choose to ana- lyze a little and then design a little.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 4CLASSIFICATION 135
Use Case Analysis
In isolation, the practices of classical analysis, behavior analysis, and domain analysis all depend on a large measure of personal experience on the part of the analyst. For the majority of development projects, this is unacceptable because such a process is neither deterministic nor predictably successful.
However, there is one practice that can be coupled with all three of these earlier approaches, to drive the process of analysis in a meaningful way. That practice is use case analysis, first formalized by Jacobson. Jacobson et al. define a use case as “A behaviourally related sequence of transactions performed by an actor in a dialogue with the system to provide some measurable value to the actor” [41].
Briefly, we can apply use case analysis as early as requirements analysis, at which time end users, other domain experts, and the development team enumerate the scenarios that are fundamental to the system’s operation. (We need not elaborate on these scenarios at first; we can simply enumerate them.) These scenarios col- lectively describe the system functions of the application. Analysis then proceeds by a study of each scenario, possibly using storyboarding techniques similar to practices in the television and movie industry [42]. As the team walks through each scenario, they must identify the objects that participate in the scenario, the responsibilities of each object, and the ways those objects collaborate with other objects, in terms of the operations each invokes on the other. In this manner, the team is forced to craft a clear separation of concerns among all abstractions. As the development process continues, these initial scenarios are expanded to con- sider exceptional conditions as well as secondary system behaviors. The results from these secondary scenarios introduce new abstractions or add, modify, or reassign the responsibilities of existing abstractions. Scenarios also serve as the basis of system tests.
CRC Cards
CRC cards emerged as a simple yet marvelously effective way to analyze scenarios.2 First proposed by Beck and Cunningham as a tool for teaching object- oriented programming [44], CRC cards have proven to be a useful development tool that facilitates brainstorming and enhances communication among develop- ers. A CRC card is nothing more than a 3u5 index card,3 on which the analyst writes—in pencil—the name of a class (at the top of the card), its responsibilities
2. CRC stands for Class/Responsibilities/Collaborators. 3. If your software development budget can handle it, buy 5u7 cards. Cards with lines are nice, and a sprinkling of colored cards shows that you are a very cool developer.
www.Vidyarthiplus.com www.Vidyarthiplus.com
136 SECTION ICONCEPTS
(on one half of the card), and its collaborators (on the other half of the card). One card is created for each class identified as relevant to the scenario. As the team members walk through the scenario, they may assign new responsibilities to an existing class, group certain responsibilities to form a new class, or (most com- monly) divide the responsibilities of one class into more fine-grained ones and perhaps distribute these responsibilities to a different class.
CRC cards can be spatially arranged to represent patterns of collaboration. As viewed from the dynamic semantics of the scenario, the cards are arranged to show the flow of messages among prototypical instances of each class; as viewed from the static semantics of the scenario, the cards are arranged to represent gen- eralization/specialization or aggregation hierarchies among the classes.
Informal English Description
A radical alternative to classical object-oriented analysis was first proposed by Abbott, who suggests writing an English description of the problem (or a part of a problem) and then underlining the nouns and verbs [45]. The nouns represent candidate objects, and the verbs represent candidate operations on them.
Abbott’s approach is useful because it is simple and because it forces the devel- oper to work in the vocabulary of the problem space. However, it is by no means a rigorous approach, and it definitely does not scale well to anything beyond fairly trivial problems. Human language is a terribly imprecise vehicle of expression, so the quality of the resulting list of objects and operations depends on the writing skill of its author. Furthermore, any noun can be verbed, and any verb can be nouned; therefore, it is easy to skew the candidate list to emphasize either objects or operations.
Structured Analysis
Some organizations have tried to use the products of structured analysis as a front end to object-oriented design. This technique appears appealing only because a large number of analysts are skilled in structured analysis, and computer-aided software engineering (CASE) tools exist that support the automation of these methods. Personally, we discourage the use of structured analysis as a front end to object-oriented design.
This approach starts with an essential model of the system, as described by data flow diagrams and the other products of structured analysis. These diagrams pro- vide a reasonably formal model of the problem. From this model, we may pro- ceed to identify the meaningful classes and objects in our problem domain in three different ways.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 4CLASSIFICATION 137
McMenamin and Palmer suggest starting with an analysis of the data dictionary and proceeding to analyze the model’s context diagram. As they state, “With your list of essential data elements, think about what they tell you or what they describe. If they were adjectives in a sentence, for instance, what nouns would they modify? The answers to this question make up the list of candidate objects” [47]. These candidate objects typically derive from the surrounding environment, from the essential inputs and outputs, and from the products, services, and other resources managed by the system.
The next two techniques involve analyzing individual data flow diagrams. Given a particular data flow diagram (using the terminology of Ward and Mellor [48]), candidate objects may be derived from the following:
■ External entities ■ Data stores ■ Control stores ■ Control transformations
Candidate classes derive from two sources:
■ Data flows ■ Control flows
This leaves us with data transformations, which we assign either as operations on existing objects or as the behavior of an object we invent to serve as the agent responsible for this transformation.
Seidewitz and Stark suggest another technique, which they call abstraction analysis. Abstraction analysis focuses on the identification of central entities, which are similar in nature to central transforms in structured design. As they state, “In structured analysis, input and output data are examined and followed inwards until they reach the highest level of abstraction. The processes between the inputs and the outputs form the central transform. In abstraction analysis a designer does the same, but also examines the central transform to determine which processes and states represent the best abstract model of what the system does” [49]. After identifying the central entity in a particular data flow diagram, abstraction analysis proceeds to identify all the supporting entities by following the afferent and efferent data flows from the central entity and grouping the pro- cesses and states encountered along the way. In practice, Seidewitz and Stark have found abstraction analysis a difficult technique to apply successfully, and as an alternative they recommend object-oriented analysis methods [50].
We must strongly emphasize that structured design, as normally coupled with structured analysis, is entirely orthogonal to the principles of object-oriented
www.Vidyarthiplus.com www.Vidyarthiplus.com
138 SECTION ICONCEPTS
design. Our experience indicates that using structured analysis as a front end to object-oriented design often fails when the developer is unable to resist the urge to fall back into the abyss of the structured design mindset. Another very real dan- ger is the fact that many analysts tend to write data flow diagrams that reflect a design rather than an essential model of the problem. It is tremendously difficult to build an object-oriented system from a model that is so obviously biased toward algorithmic decomposition. This is why we prefer object-oriented analysis as the front end to object-oriented design: There is simply less danger of polluting the design with preconceived algorithmic notions.
If you must use structured analysis as a front end, for whatever honorable rea- sons,4 we suggest that you stop writing data flow diagrams as soon as they start to smell of a design instead of an essential model. Also, it is a healthy practice to walk away from the products of structured analysis once the design is fully under way. Remember that the products of development, including data flow diagrams, are not ends in themselves; they should be viewed simply as tools along the way that aid the developer’s intellectual comprehension of the problem and its imple- mentation. One typically writes a data flow diagram and then invents the mecha- nisms that implement the desired behavior. Practically speaking, the very act of design changes the developer’s understanding of the problem. Thus, only the products of structured analysis that are at a sufficiently high level of abstraction should be retained. They capture an essential model of the problem and so lend themselves to any number of different designs.
4.3 Key Abstractions and Mechanisms
A key abstraction is a class or object that forms part of the vocabulary of the prob- lem domain. The primary value of identifying such abstractions is that they give boundaries to our problem; they highlight the things that are in the system and therefore relevant to our design, and they suppress the things that are outside the system and therefore superfluous.
In the previous chapter, we used the term mechanism to describe any structure whereby objects collaborate to provide some behavior that satisfies a requirement of the problem. Whereas the design of a class embodies the knowledge of how individual objects behave, a mechanism is a design decision about how collec- tions of objects cooperate. Mechanisms thus represent patterns of behavior.
Let us now discuss the identification and refinement of these key abstractions and mechanisms.
4. Political and historical reasons are distinctly not honorable. www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 4CLASSIFICATION 139
Identifying Key Abstractions
The identification of key abstractions is highly domain-specific. As Goldberg states, the “appropriate choice of objects depends, of course, on the purposes to which the application will be put and the granularity of information to be manipulated” [51].
As we mentioned earlier, the identification of key abstractions involves two pro- cesses: discovery and invention. Through discovery, we come to recognize the abstractions used by domain experts; if the domain expert talks about it, the abstraction is usually important [52]. Through invention, we create new classes and objects that are not necessarily part of the problem domain but are useful arti- facts in the design or implementation. For example, a customer using an auto- mated teller speaks in terms of accounts, deposits, and withdrawals; these words are part of the vocabulary of the problem domain. A developer of such a system uses these same abstractions but must also introduce new ones, such as databases, screen managers, lists, queues, and so on. These key abstractions are artifacts of the particular design, not of the problem domain.
Refining Key Abstractions
Once we identify a certain key abstraction as a candidate, we must evaluate it according to the metrics described in the previous chapter. As Stroustrup suggests, “Often this means that the programmer must focus on the questions: how are objects of this class created? Can objects of this class be copied and/or destroyed? What operations can be done on such objects? If there are no good answers to such questions, the concept probably wasn’t ‘clean’ in the first place, and it might be a good idea to think a bit more about the problem and the proposed solution instead of immediately starting to ‘code around’ the problems” [53].
Given a new abstraction, we must place it in the context of the existing class and object hierarchies we have designed. Practically speaking, this is neither a top- down nor a bottom-up activity. As Halbert and O’Brien observe, “You do not always design types in a type hierarchy by starting with a supertype and then cre- ating the subtypes. Frequently, you create several seemingly disparate types, real- ize they are related, and then factor out their common characteristics into one or more supertypes. . . . several passes up and down are usually required to produce a complete and correct program design” [54]. This is not a license to hack, but an observation, based on experience, that object-oriented design is both incremental and iterative. Stroustrup makes a similar observation when he notes that “the most common reorganizations of a class hierarchy are factoring the common part of two classes into a new class and splitting a class into two new ones” [55].
www.Vidyarthiplus.com www.Vidyarthiplus.com
140 SECTION ICONCEPTS
Placing classes and objects at the right levels of abstraction is difficult. Some- times we may find a general subclass and so may choose to move it up in the class structure, thus increasing the degree of sharing. This is called class promotion [56]. Similarly, we may find a class to be too general, thus making inheritance by a subclass difficult because of the large semantic gap. This is called a grainsize conflict [57]. In either case, we strive to identify cohesive and loosely coupled abstractions, so as to mitigate these two situations.
Classes and objects should be at the right level of abstraction: neither too high nor too low.
Naming Key Abstractions
Naming things properly—so that they reflect their semantics—is often treated lightly by most developers yet is important in capturing the essence of the abstractions we are describing. Software should be written as carefully as English prose, with consideration given to the reader as well as to the computer [58]. Consider for a moment all the names we may need just to identify a single object: We have the name of the object itself, the name of its class, and the name of the module in which that class is declared. Multiply this by thousands of objects and possibly hundreds of classes, and you have a very real problem.
We offer the following suggestions.
■ Objects should be named with proper noun phrases, such as theSensor or just simply shape.
www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 4CLASSIFICATION 141
■ Classes should be named with common noun phrases, such as Sensor or Shape. ■ The names chosen should reflect the names used and recognized by the domain experts, whenever possible. ■ Modifier operations should be named with active verb phrases, such as draw or moveLeft. ■ Selector operations should imply a query or be named with verbs of the form “to be,” such as extentOf or isOpen. ■ The use of underscores and styles of capitalization are largely matters of personal taste. No matter which cosmetic style you use, at least have your programs be self-consistent.
Identifying Mechanisms
Consider a system requirement for an automobile: Pushing the accelerator should cause the engine to run faster, and releasing the accelerator should cause the engine to run slower. How this actually comes about is absolutely immaterial to the driver. Any mechanism may be employed as long as it delivers the required behavior, and thus which mechanism is selected is largely a matter of design choice. More specifically, any of the following designs might be considered.
■ A mechanical linkage connects the accelerator directly to the fuel injectors. ■ An electronic mechanism connects a pressure sensor below the accelerator to a computer that controls the fuel injectors (a drive-by-wire mechanism). ■ No linkage exists. The gas tank is placed on the roof of the car, and gravity causes fuel to flow to the engine. Its rate of flow is regulated by a clip around the fuel line; pushing on the accelerator pedal eases tension on the clip, causing the fuel to flow faster (a low-cost mechanism).
Which mechanism a developer chooses from a set of alternatives is most often a result of other factors, such as cost, reliability, manufacturability, and safety.
Just as it is rude for a client to violate the interface of another object, so it is socially unacceptable for objects to step outside the boundaries of the rules of behavior dictated by a particular mechanism. Indeed, it would be surprising for a driver if stepping on an accelerator turned on the car’s lights instead of causing the engine to run faster.
Whereas key abstractions reflect the vocabulary of the problem domain, mecha- nisms are the soul of the design. During the design process, the developer must consider not only the design of individual classes but also how instances of these classes work together. Again, the use of scenarios drives this analysis process.
www.Vidyarthiplus.com www.Vidyarthiplus.com
142 SECTION ICONCEPTS
Mechanisms are the means whereby objects collaborate to provide some higher-level behavior.
Once a developer decides on a particular pattern of collaboration, the work is dis- tributed among many objects by defining suitable methods in the appropriate classes. Ultimately, the protocol of an individual class encompasses all the opera- tions required to implement all the behavior and all the mechanisms associated with each of its instances.
Mechanisms thus represent strategic design decisions, as does the design of a class structure. In contrast, however, the interface of an individual class is more of a tactical design decision. These strategic decisions must be made explicitly; otherwise, we will end up with a mob of relatively uncooperative objects, all pushing and shoving to do their work with little regard for other objects. The most elegant, lean, and fast programs embody carefully engineered mechanisms.
Mechanisms as Patterns
Mechanisms are actually one in a spectrum of patterns we find in well-structured software systems. At the low end of the food chain, we have idioms. An idiom is an expression peculiar to a certain programming language or application culture, representing a generally accepted convention for use of the language.5 For exam-
5. One defining characteristic of an idiom is that ignoring or violating the idiom has imme- diate social consequences: You are branded as a yahoo or, worse, an outsider, unworthy of respect. www.Vidyarthiplus.com www.Vidyarthiplus.com
CHAPTER 4CLASSIFICATION 143 ple, in CLOS, no programmer would use underscores in function or variable names, although this is common practice in Ada [59]. Part of the effort in learning a programming language is learning its idioms, which are usually passed down as folklore from programmer to programmer. However, as Coplien points out, idioms play an important role in codifying low-level patterns. He notes that “many common programming tasks [are] idiomatic” and therefore identifying such idioms allows “using C++ constructs to express functionality outside the language proper, while giving the illusion of being part of the language” [60].
Whereas idioms are part of a programming culture, at the high end of the food chain, we have frameworks. A framework is a collection of classes that provides a set of services for a particular domain; a framework thus exports a number of individual classes and mechanisms that clients can use or adapt. Frameworks rep- resent reuse in the large. They are often the product of commercial ventures, such as Microsoft’s .NET Framework, or open source efforts such as Apache Software Foundation’s Struts framework and the JUnit testing framework (Erich Gamma and Kent Beck), among many others.
Examples of Mechanisms
Consider the drawing mechanism commonly used in graphical user interfaces. Several objects must collaborate to present an image to a user: a window, a view, the model being viewed, and some client that knows when (but not how) to dis- play this model. The client first tells the window to draw itself. Since it may encompass several subviews, the window next tells each of its subviews to draw themselves. Each subview in turn tells its model to draw itself, ultimately result- ing in an image shown to the user. In this mechanism, the model is entirely decou- pled from rendering of the window and view in which it is presented. This is the model-view-controller paradigm (MVC pattern) [61]. A similar mechanism is employed in almost every object-oriented graphical user interface framework.
Mechanisms thus represent a level of reuse that is higher than the reuse of indi- vidual classes. For example, the MVC paradigm is used extensively in the Small- talk user interface. The MVC paradigm in turn builds on another mechanism, the dependency mechanism, which is embodied in the behavior of the Smalltalk base class Model and thus pervades much of the Smalltalk class library.
Examples of mechanisms and patterns may be found in virtually every domain. For example, the structure of an operating system may be described at the highest level of abstraction according to the mechanism used to dispatch programs. In artificial intelligence, a variety of mechanisms have been explored for the design of reasoning systems. One of the most widely used paradigms is the blackboard mechanism, in which individual knowledge sources independently update a blackboard. There is no central control in such a mechanism, but any change to
www.Vidyarthiplus.com www.Vidyarthiplus.com
144 SECTION ICONCEPTS
the blackboard may trigger an agent to explore some new problem-solving path [63]. Coad has similarly identified a number of common mechanisms in object- oriented systems, including patterns of time association, event logging, and broadcasting [64]. In each case, these mechanisms manifest themselves not as individual classes but as the structure of collaborating classes.
This completes our study of classification and of the concepts that serve as the foundation of object-oriented design. The next three chapters focus on notation, process, and pragmatics.
Summary
■ The identification of classes and objects is a fundamental issue in object- oriented analysis and design; identification involves both discovery and invention. ■ Classification is fundamentally a problem of clustering. ■ Classification is an incremental and iterative process, made difficult because a given set of objects may be classified in many equally proper ways. ■ The three approaches to classification include classical categorization (clas- sification by properties), conceptual clustering (classification by concepts), and prototype theory (classification by association with a prototype). ■ Scenarios are a powerful tool of object-oriented analysis and can be used in approaches such as classical analysis, behavior analysis, domain analysis, and use case analysis. ■ Key abstractions reflect the vocabulary of the problem domain and may either be discovered from the problem domain or invented as part of the design. ■ Mechanisms denote strategic design decisions regarding the collaborative activity of many different kinds of objects.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Object oriented design
Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.
An object contains encapsulated data and procedures grouped together to represent an entity. The 'object interface', how the object can be interacted with, is also defined. An object-oriented program is described by the interaction of these objects. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis.
What follows is a description of the class-based subset of object-oriented design, which does not include object prototype-based approaches where objects are not typically obtained by instancing classes but by cloning other (prototype) objects. Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as state and dynamic models of the system under design.
Input (sources) for object-oriented design
The input for object-oriented design is provided by the output of object-oriented analysis. Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design; analysis and design may occur in parallel, and in practice the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.
Some typical input artifacts for object-oriented design are:
• Conceptual model: The result of object-oriented analysis, it captures concepts in the problem domain. The conceptual model is explicitly chosen to be independent of implementation details, such as concurrency or data storage. • Use case: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into use case diagrams. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform. • System sequence diagram: A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
www.Vidyarthiplus.com www.Vidyarthiplus.com
• User interface documentations (if applicable): Document that shows and describes the look and feel of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end-product and therefore helps the designer. • Relational data model (if applicable): A data model is an abstract model that describes how data is represented and used. If an object database is not used, the relational data model should usually be created before the design, since the strategy chosen for object-relational mapping is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.
Object-oriented concepts
The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. These features are often referred to by these common names:
• Object/Class: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of objects that are similar.
• Information hiding: The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class. • Inheritance: The ability for a class to extend or override functionality of another class. The so-called subclass has a whole section that is derived (inherited) from the superclass and then it has its own set of functions and data. • Interface (object-oriented programming): The ability to defer the implementation of a method. The ability to define the functions or methods signatures without implementing them. • Polymorphism: The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.
Designing concepts
• Defining objects, creating class diagram from conceptual diagram: Usually map entity to class.
• Identifying attributes.
• Use design patterns (if applicable): A design pattern is not a finished design, it is a description of a solution to a common problem, in a context.[1] The main advantage of using a design pattern is that it can be reused in multiple
www.Vidyarthiplus.com www.Vidyarthiplus.com
applications. It can also be thought of as a template for how to solve a problem that can be used in many different situations and/or applications. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
• Define application framework (if applicable): Application framework is a term usually used to refer to a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer, since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed.
• Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single runtime of the application. If a relational database is used, design the object relation mapping.
• Identify and define remote objects (if applicable).
Output (deliverables) of object-oriented design
• Sequence diagram: Extend the system sequence diagram to add specific objects that handle the system events.
A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.
• Class diagram: A class diagram is a type of static structure UML diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.
Some design principles and strategies
• Dependency injection: The basic idea is that if an object depends upon having an instance of some other object then the needed object is "injected" into the dependent object; for example, being passed a database connection as an argument to the constructor instead of creating one internally. • Acyclic dependencies principle: The dependency graph of packages or components (the granularity depends on the scope of work for one developer) should have no cycles. This is also referred to as having a directed acyclic graph.[2] For example, package C depends on package B, which depends on package A. If package A also depended on package C, then you would have a cycle.
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Composite reuse principle: Favor polymorphic composition of objects over inheritance.
Object-oriented design principles
Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:
• Rigidity - It is hard to change because every change affects too many other parts of the system. small changes causes the entire system to rebuild. • Fragility - When you make a change, unexpected parts of the system break. changes to one module causes other unrelated modules to misbehave. Imagine a car system in which changing the radio station affects windows. • Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application. a module’s internal components cannot be extracted and reused in new environments. For example, if an application’s login module cannot be used in entirely different system then this module is immobile, caused by couplings and dependencies between different modules. The strategy is to decouple central abstractions from low-level details, like a particular database schema or UI implementation (web, desktop) or specific frameworks.
SOLID is a set of five guiding principles that help developers design objects that are easy to maintain and use. Like many similar sets of principles in OO, SOLID is a guide not the goal. Let's take a look at each of the five principles.
SOLID
S - Single Responsibility Principle
SRP is the idea that objects should do one thing and one thing only. It is tempting to think this means that a class should represent an entire piece of business logic or data, but that is not quite correct. The idea is not to group all of the functionality that is related together, but all of the functionality that achieves the same goal together.
For example, if you have a class representing printer, putting all of the printer operations (getting toner levels, printing a page, getting an error message) in the printer class may make sense, but it is not really the right approach. Instead, you would put all of the functions related to printing in the same class, and all of the functions for reporting status in a class, and so on. You break the work down into small, digestible chunks. The
www.Vidyarthiplus.com www.Vidyarthiplus.com
payoff here is that you can make changes to a select piece of functionality without possibly affecting a ton of other items.
• A class should have only one reason to change.
In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.
Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.
O - Open/closed principle (OCP)
This very simple idea is that classes can allow themselves to be extended but not modified. The source code for the original class should only be modified if a bug is found. The reason behind this is that changing the code will mean that everything depending upon it will need to be retested as well.
• Software entities like classes, modules and functions should be open for extension but closed for modifications.
OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don't have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you will prefer to extend it without changing the code that was already written (backward compatibility, regression testing, ). This is why we have to make sure our modules follow Open Closed Principle.
When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern and Strategy Pattern.
L - Liskov substitution principle (LSP)
LSP states that the subclass of an object can be used in place of the superclass without changing things like what the program does, whether it compiles, etc. For example, if class "elephant" is a subtype of class "animal," then you should be able to use "elephant" where you use "animal," and the "walk" method will still "walk" (even though the implementation may be different), the "numberOfLegs" property will still return the
www.Vidyarthiplus.com www.Vidyarthiplus.com
number of legs (though again, it may be a different number from the base class), the "eat" method will not throw any exceptions that it would not throw in the "animal" class, and so on. It is much easier to make changes and test when you follow LSP.
• Derived types must be completely substitutable for their base types.
This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.
Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy
I - Interface segregation principle (ISP)
ISP dictates that interfaces need to have as little functionality in them as possible. This allows the consumer to only deal with the functionality they are concerned with, which reduces testing needs and the impact of changes to the system.
• Clients should not be forced to depend upon interfaces that they don't use.
This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?
As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.
D - Dependency inversion principle (DIP)
With DIP, high-level objects are abstracted away from low-level objects. It is normal to think of the low-level objects as just being smaller pieces of a bigger one. For example, let's say that you want to query a database and fill a data set. The temptation is to pass in the database connection information to the data set and let it make the connection. Instead, you pass in a connection that is already configured, and in this way, the database can change without needing to retest the entire data set object.
• High-level modules should not depend on low-level modules. Both should depend on abstractions. • Abstractions should not depend on details. Details should depend on abstractions.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.
Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, ) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, ) and an external module controlling the dependencies will inject the reference to the second one.
By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.
www.Vidyarthiplus.com www.Vidyarthiplus.com
2 Object-oriented Design
Object-oriented design is a design strategy where system designers think in terms of ‘things’ instead of operations or functions. Rather than a program being designed as a set of functions that interchange data through their parameters and through a shared memory (global variables), an object-oriented program is made up of interacting objects. Objects maintain their own local state and define operations on that state information. They hide information about the representation of the state and hence limit access to it. The characteristics of an object-oriented design (OOD) are: 1. In an object-oriented design a software system is designed as a set of interacting objects that manage their own private state and offer services to other objects. 2. Objects are created by instantiating an object class that defines the attributes and operations associated with the object. In Figure 12.1, the object name precedes the colon in the top part of the rectangle and the class name follows the colon. Several objects of the same class may co-exist in the same program. 3. Object classes are abstractions of real-world or system entities that encapsulate state information and that define a number of operations (alternatively called services or methods) that create, access or modify the state. 4. Objects are independent entities that may readily be changed because state and representation information is held within the object. Changes to the representation may be made without reference to other system objects. 5. System functionality is expressed in terms of operations or services associated with each object. Objects interact by calling on the operations defined by other objects. Interaction in Figure 12.1 is shown by arrows linking the objects. 6. There are no shared data areas. Objects communicate by calling on services offered by other objects rather than sharing variables. There is no possibility that a program component can be affected by modifications to shared information. Changes are therefore easier to implement. 7. Objects may be distributed and may execute either sequentially or in parallel.
o1: C1 o3:C3 o4: C4 state o1 state o3 state o4 ops1() ops3 () ops4 ()
Figure 12.1 A o2: C3 o6: C1 o5:C5 system designed as a state o2 state o6 state o5 number of interacting ops3 () ops1 () ops5 () objects
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
8 Object-oriented Design
12.2 An object-oriented design process
In this section, I illustrate the process of object-oriented design by developing an example design for the control software that is embedded in an automated weather station. As I discussed in the introduction, there are several methods of object- oriented design with no definitive ‘best’ method or design process. The process that I cover here is a general one that incorporates activities that are common to most OOD processes. In this respect, it is comparable to the proposed UML process [Rumbaugh, 1999 #954] but I have significantly simplified this process for presentation here. Examples of software design are inevitably artificial. Designs for large software systems involve creating hundreds of pages of documentation. However, in a book, only a few pages are available to convey the essence of the design. Readers must take on trust assertions about the advantages of object-oriented design. It is only when you practise this approach in a real, evolving system design that the advantages become clear. The example I use to illustrate object-oriented design is part of a system for creating weather maps using automatically collected meteorological data. The detailed requirements for such a weather mapping system would take up many
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 9
Data display layer where objects are «subsystem» concerned with preparing and Data display prsenting the data in a human- readable form
Data archiving layer where objects «subsystem» are concerned with storing the data Data archiving for future processing
Data processing layer where objects «subsystem» are concerned with checking and Data processing integrating the collected data Figure 12.6 Layered architecture Data collection layer where objects «subsystem» are concerned with acquiring data for weather mapping Data collection from remote sources system pages. However, an overall system architecture can be developed from a relatively brief system description: A weather mapping system is required to generate weather maps on a regular basis using data collected from remote, unattended weather stations and other data sources such as weather observers, balloons and satellites. Weather stations transmit their data to the area computer in response to a request from that machine. The area computer system validates the collected data and integrates the data from different sources. The integrated data is archived and, using data from this archive and a digitised map database, a set of local weather maps is created. Maps may be printed for distribution on a special-purpose map printer or may be displayed in a number of different formats. This description shows that part of the overall system is concerned with collecting data, part with integrating the data from different sources, part with archiving that data and part with creating weather maps. Figure 12.6 illustrates a possible system architecture that can be derived from this description. This is a layered architecture (discussed in Chapter 11) that reflects the different stages of processing in the system namely data collection, data integration, data archiving and map generation. A layered architecture is appropriate in this case because each stage only relies on the processing of the previous stage for its operation. In Figure 12.6, I have shown the different layers and have included the layer name in a UML package symbol that has been denoted as a subsystem. A UML package represents a collection of objects and other packages. I have used it here to show that the design of each layer includes a number of other components. In Figure 12.7 I have expanded on this abstract architectural model by showing that the components of the subsystems. Again, these are very abstract and they have been derived from the information in the description of the system. I continue the design example by focusing on the weather station subsystem that is part of the data collection layer.
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
10 Object-oriented Design
«subsystem» Data collection «subsystem» Data display
Observer Satellite User Map Comms interface display Map Weather Map station Balloon printer
«subsystem» «subsystem» Data processing Data archiving Figure 12.7 Packages in the Data weather mapping Data Data storage checking integration system Map store Data store
The general process that I use here for object-oriented design has a number of stages: 1. Understand and define the context and the modes of use of the system 2. Design the system architecture 3. Identify the principal objects in the system 4. Develop design models 5. Specify object interfaces I have deliberately not illustrated this as a simple process diagram as that would imply that there was a neat sequence of activities in this process. In fact, all of the above activities can be thought of as inter-leaved activities that influence each other. Objects are identified and the interfaces fully or partially specified as the architecture of the system is defined. As object models are produced, these individual object definitions may be refined and this may mean changes to the system architecture. I discuss these as separate stages in the design process in this section for convenience. However, you should not assume from this that design is a simple, well-structured process. In reality, you develop a design by proposing solutions and refining these solutions as information becomes available. You inevitably have to backtrack and retry when problems arise. Sometimes you explore options in detail to see if they work; other times you ignore details until late in the process. 12.2.1 System context and models of use The first stage in any software design process is to develop an understanding of the relationships between the software that is being designed and its external environment. Developing this understanding will help you decide how to provide the required system functionality and how to structure the system so that it can communicate effectively with its environment.
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 11
Startup
Shutdown
Report
Calibrate Figure 12.8 Use- cases for the weather Test station
The system context and the model of system use represent two complementary models of the relationships between a system and its environment: 1. The system context is a static model that describes the other systems in that environment. 2. The model of the system use is a dynamic model that describes how the system actually interacts with its environment. The context model of a system may be represented using associations as shown in Figure 12.4 where, essentially, a simple block diagram of the overall system architecture (discussed in Chapter 11) is produced. This can be expanded by representing a subsystem model using UML packages as shown in Figure 12.7. This illustrates that the context of the weather station system is within a subsystem concerned with data collection. It also shows other subsystems that make up the weather mapping system. When you model the interactions of a system with its environment you should use an abstract approach that does not include too much detail of these interactions. The approach that is proposed in the UML is to develop a use-case model where each use-case represents an interaction with the system. In use-case models (also discussed in Chapter 7), each possible interaction is named in an ellipse and the external entity involved in the interaction is represented by a stick figure. In the case of the weather station system, this external entity is not a human but the data processing system for the weather data. A use-case model for the weather station is shown in Figure 12.8. This shows that weather station interacts with external entities for startup and shutdown, for reporting the weather data that has been collected and for instrument testing and calibration. Each of these use cases can be described using a simple natural language description. This helps designers identify objects in the system and gives them an understanding of what the system is intended to do. I like to use a stylised form of this description that clearly identifies what information is exchanged, how the interaction is initiated etc. This is shown in Figure 12.9 where I have described the Report use case from Figure 12.8.
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
12 Object-oriented Design
System Weather station Use-case Report Actors Weather data collection system, Weather station Data The weather station sends a summary of the weather data that has been collected from the instruments in the collection period to the weather data collection system. The data sent are the maximum minimum and average ground and air temperatures, the maximum, minimum and average air pressures, the maximum, minimum and average wind speeds, the total rainfall and the wind direction as sampled at 5 minute intervals. Stimulus The weather data collection system establishes a modem link with the weather station and requests transmission of the data. Response The summarised data is sent to the weather data collection system Comments Weather stations are usually asked to report once per hour but this frequency may differ from one station to the other and may be modified in future. Of course, you can use any technique for describing use-cases so long as the description is short and easily understandable. You need to develop descriptions for Figure 12.9 each of the use-cases that are shown in the model. Weather station The use-case description helps to objects and operations in the system. From eport description the description of the Report use-case, it is obvious that objects representing the instruments that collect weather data will be required as will an object representing the summary of the weather data. There needs to be operations to request weather data and to send weather data. 12.2.2 Architectural design Once the interactions between the software system that is being designed and the system’s environment have been defined, you can then use this information as a basis for designing the system architecture. Of course, you need to combine this with your general knowledge of principles of architectural design and with more detailed domain knowledge.
Weather station
Manages all «subsystem» external Interface communications
Collects and «subsystem» summarises Data collection weather data Figure 12.10 The weather station architecture Package of «subsystem» instruments for raw Instruments data collections
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 13
The automated weather station is a relatively simple system and its architecture can again be represented as a layered model. I have illustrated this in Figure 12.10 as three UML packages within the more general Weather station package. Notice how I have used UL annotations to provide additional information here. The three layers of interaction are: 1. The interface layer which is concerned with all communications with other parts of the system and with providing the external interfaces of the system. 2. The data collection layer which is concerned with managing the collection of data from the instruments and with summarising the weather data before transmission to the mapping system. 3. The instruments layer which is an encapsulation of all of the instruments that are used to collect raw data about the weather conditions. In general, you should try and decompose a system so that architectures are as simple as possible. A good rule of thumb is that there should not be more than seven fundamental entities included in an architectural model. Each of these entities can be described separately but, of course, you may choose to reveal the structure of the entities as I have done in Figure 12.7. 12.2.3 Object identification By this stage in the design process, you will already have formulated some ideas about the essential objects in the system that you are designing. In the weather station system, it is clear that the instruments are objects and you need at least one object at each of the architectural levels. This reflects a general principle that objects tend to emerge during the design process. However, you usually also have to look for and document other objects that may be relevant. Although we usually talk about object identification, in practice we are usually actually identifying object classes and the design is described in terms of these classes. Inevitably, you have to refine the object classes that you initially identify and revisit this stage of the process as you develop a deeper understanding of the design. There have been various proposals made about how to identify objects: 1. Use a grammatical analysis of a natural language description of a system. Objects and attributes are nouns, operations or services are verbs. (Abbott, 1983). This approach has been embodied in the HOOD method for object- oriented design [Robinson, 1992 #384] that has been widely used in the European aerospace industry. 2. Use tangible entities (things) in the application domain such as aircraft, roles such as manager, events such as request, interactions such as meetings, locations such as offices, organisational units such as companies, etc. [Shlaer, 1988 #393; Coad, 1990 #72; Wirfs-Brock, 1990 #397]. Support this by identifying storage structures (abstract data structures) in the solution domain that might be required to support these objects. 3. Use a behavioural approach where the designer first understands the overall behaviour of the system. The various behaviours are assigned to different
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
14 Object-oriented Design
parts of the system and an understanding derived of who initiates and participates in these behaviours. Participants who play significant roles are recognised as objects (Rubin and Goldberg, 1992). 4. Use a scenario-based analysis where various scenarios of system use are identified and analysed in turn. As each scenario is analysed, the team responsible for the analysis must identify the required objects, attributes and operations. A method of analysis called CRC cards where analysts and designers take on the role of objects is effective in supporting this scenario- based approach (Beck and Cunningham, 1989). These approaches are not exclusive. Good designers may use all of them when trying to identify objects. The methods are informal and different designers will discover different objects when applying them. Nevertheless, they are a useful way to start identifying objects. In practice, many different sources of knowledge have to be used to discover objects and object classes. Objects and operations that are initially identified from the informal system description can be a starting point for the design. Further information from application domain knowledge or scenario analysis may then be used to refine and extend the initial objects. This information may be collected from requirements documents, from discussions with users and from an analysis of existing systems. I have used a hybrid approach here to identify the weather station objects. I don’t have space here to describe all the weather station system objects but I have shown five object classes in Figure 12.11. The Ground thermometer, Anemometer and Barometer represent application domain objects and the WeatherStation and WeatherData objects have been identified from the system description and the scenario (use-case) description. These objects are related to the different levels in the system architecture. 1. The WeatherStation object class provides the basic interface of the weather station with its environment. Its operations therefore reflect the interactions shown in Figure 12.8. In this case, I use a single object class to encapsulate
WeatherStation WeatherData identifier airTemperatures groundTemperatures reportWeather () windSpeeds calibrate (instruments) windDirections test () pressures startup (instruments) rainfall shutdown (instruments) collect () summarise ()
Ground Anemometer Barometer Figure 12.11 thermometer Examples of object windSpeed pressure temperature height classes in the weather windDirection test () station system test () test () calibrate () calibrate ()
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 15
all of these interactions but, in other designs, it may be more appropriate to use several classes to provide the system interface. 2. The WeatherData object class encapsulates the summarised data from the different instruments in the weather station. Its associated operations are concerned with collecting and summarising the data that is required. 3. The GroundThermometer, Anemometer and Barometer object classes are directly related to instruments in the system. They reflect tangible hardware entities in the system and the operations are concerned with controlling that hardware. At this stage in the design process, knowledge of the application domain may be used to identify further objects and services. In this case, we know that weather stations are often located in remote places. They include various instruments which sometimes go wrong. Instrument failures should be reported automatically. This implies that attributes and operations to check the correct functioning of the instruments are necessary. Obviously, there are many remote weather stations. You therefore need some way of identifying the data collected from each station so each weather station should have its own identifier. I have decided not to make the objects associated with each instrument active objects. The collect operation in WeatherData calls on instrument objects to make readings when required. Active objects includes their own control and, in this case, it would mean that each instrument would decide when to make readings. However, the disadvantage of this is that, if a decision was made to change the timing of the data collection or if different weather stations collected data differently then each individual object would have to be changed. By making the instrument objects make readings on request, any changes to collection strategy can be easily implemented without changing the objects associated with the instruments. 12.2.4 Design models Design models show the objects or object classes in a system and, where appropriate, different kinds of relationships between these entities. Design models essentially are the design. They represent the bridge between the requirements for the system and the system implementation. This means that there are conflicting requirements on these models. They have to be abstract so that unnecessary detail doesn’t hide the relationships between them and the system requirements. However, they also have to include enough detail so that the programmers of the system can make implementation decisions. In general, you get round this conflict by developing different models at different levels of detail. Where there are close links between requirements engineers, designers and programmers then abstract models may be all that are required. Specific design decisions may be made as the system is implemented. When the links between system specifiers, designers and programmers are indirect (e.g. where a system is being designed in one part of an organisation but implemented elsewhere) then much more detailed models may be required. An important step in the design process, therefore, is to decide which design models that you need and the level of detail of these models. This also depends on the type of system that is being developed. A simple sequential data processing system will be designed in a different way from an embedded real-time system and
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
16 Object-oriented Design
different design models will therefore be used. There are very few systems where all models are necessary and minimising the number of models that are produced reduces the costs of the design and the time required to complete the design process. There are, basically, two types of design models that should be produced to describe an object-oriented design. These are: 1. Static models that describe the static structure of the system in terms of the system object classes and their relationships. Important relationships that may be documented at this stage are generalisation relationships, uses/used- by relationships, composition relationships, etc. 2. Dynamic models that describe the dynamic structure of the system and that show the interactions between the system objects (not the object classes). Interactions that may be documented include the sequence of service requests made by objects and the way in which the state of the system is related to these object interactions. The UML provides for a large number of possible static and dynamic models that may be produced. Booch et al. [Booch, 1999 #955] propose 9 different types of diagram to represent these models. I don’t have space to go into all of these and not all are appropriate for the weather station example. The models that I will discuss in this section are: 1. Subsystem models that show logical groupings of objects into coherent subsystems. These are represented using a form of class diagram where each subsystem is shown as a package. Subsystem models are static models. 2. Sequence models that show the sequence of object interactions. These are represented using a UML sequence or a collaboration diagram. Sequence models are dynamic models. 3. State machine models that show how individual objects change their state in response to events. These are represented in the UML using statechart diagrams. State machine models are dynamic models. I have already discussed other types of model that may be developed earlier in this chapter and in other chapters. Use-case models show interactions with the system (Figure 12.8, Figures 7.12 and 7.13, Chapter 7), object models describe the object classes (Figure 12.2), generalisation or inheritance models (Figure 8.12 and Figure 8.13, Chapter 8) show how classes may be generalisations of other classes and aggregation models (Figure 8.14) show how collections of objects are related. A subsystem model is, in my view, one of the most helpful static models as it shows how the design may be organised into logically related groups of objects. We have already seen examples of this type of model in Figure 12.7 that showed the subsystems in the weather mapping system. In the UML packages are encapsulation constructs and do not reflect directly on entities in the system that is developed. However, they may be reflected in structuring constructs such as Java libraries. Figure 12.12 shows the objects in the subsystems in the weather station. I also show some associations in this model. For example, the CommsController object is associated with the WeatherStation object and the WeatherStation object is associated with the Data collection package. This means that this object is
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 17
«subsystem» «subsystem» Interface Data collection
CommsController WeatherData
Instrument WeatherStation Status
«subsystem» Instruments
Air thermometer RainGauge Anemometer
Ground thermometer Barometer WindVane Figure 12.12 Weather station packages associated with one or more objects in this package. A package model plus an object class model should describe the logical groupings in the system. One of the most useful and understandable dynamic models that may be produced is a sequence model that documents, for each mode of interaction, the sequence of object interactions that take place. In a sequence model: 1. The objects involved in the interaction are arranged horizontally with a vertical line linked to each object. 2. Time is represented vertically so that time progresses down the dashed vertical lines. Therefore, the sequence of operations can be read easily from the model. 3. Interactions between objects are represented by labelled arrows linking the vertical lines. These are not data flows but represent messages or events that are fundamental to the interaction. 4. The thin rectangle on the object lifeline represents the time when the object is the controlling object in the system. An object takes over control at the top of this rectangle and relinquishes control to another object at the bottom of the rectangle. If there is a hierarchy of calls, control is not relinquished until the last return to the initial method call has been completed. This is illustrated in Figure 12.13 that shows the sequence of interactions when the external mapping system requests the data from the weather station. This diagram may be read as follows:
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
18 Object-oriented Design
:CommsController :WeatherStation :WeatherData
request (report)
acknowledge () report () summarise ()
send (report) Figure 12.13 reply (report) Sequence of operations - data collection acknowledge ()
1. An object that is an instance of CommsController (:CommsController) receives a request from its environment to send a weather report. It acknowledges receipt of this request. The half-arrowhead indicates that the message sender does not expect a reply. 2. This object sends a message to an object that is an instance of WeatherStation to create a weather report. The instance of CommsController then suspends itself (its control box ends). The style of arrowhead used indicates that the CommsController object instance and the WeatherStation object instance are objects that may execute concurrently. 3. The object that is an instance of WeatherStation sends a message to WeatherData to summarise the weather data. In this case, the different style of arrowhead used indicates that the instance of WeatherStation waits for a reply. 4. This summary is computed and control returns to the WeatherStation object. The dotted arrow indicates a return of control. 2. This object sends a message to CommsController requesting it to transfer the data to the remote system. The WeatherStation object then suspends itself. 3. The CommsController object sends the summarised data to the remote system, receives an acknowledgement and then suspends itself waiting for the next request. From the sequence diagram we can see that the CommsController object and the WeatherStation object are actually concurrent processes where execution can be suspended and resumed. Essentially, the CommsController object instance listens for messages from the external system, decodes these messages and initiates weather station operations.
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 19
Operation calibrate () Calibrating
calibration OK test () startup () Waiting Testing Shutdown
shutdown () transmission done test complete
Transmitting clock collection done reportWeather () weather summary Summarising complete Collecting
When documenting a design, you should produce a sequence diagram for each significant interaction. If you have developed a use-case model then there should be gure 12.14 a sequence diagram for each use-case that you have identified. te diagram for Sequence diagrams are used to model the combined behaviour of a group of atherStation objects but you may also want to summarise the behaviour of a single object in response to the different messages that it can process. To do this, you can use a state machine model that shows how the object instance changes state depending on the messages that it receives. UML used statecharts, initially invented by Harel [Harel, 1987 #411] to describe state machine models. Figure 12.14 is a statechart for the WeatherStation object that shows how it responds to requests for various services. You can read this diagram as follows: 1. If the object state is ‘shutdown’ then it can only respond to a startup () message. It then moves into a state where it is waiting for further messages. The unlabelled arrow with the black blob indicates that this is the initial state. 2. In this state, if a shutdown () message is received, the object returns to the shutdown state. 3. If a report () message is received, the system moves to a summarising state then, when the summary is complete, to a transmitting state where the information is transmitted through the CommsController. It then returns to a waiting state. 2. If a Calibrate () message is received, the system moves to a calibrating state then a testing state before returning to the waiting state. 2. If a signal from the clock is received, the system moves to a collecting state where it is collecting data from the instruments. Each instrument is instructed in turn to collect its data.
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
20 Object-oriented Design
interface WeatherStation {
public void WeatherStation () ;
public void startup () ; public void startup (Instrument i) ;
public void shutDown () ; public void shutDown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ; public void test ( Instrument i ) ; Figure 12.15 Java description of public void calibrate ( Instrument i) ; weather station interface public int getID () ; } //WeatherStation
It is not usually necessary to produce a statechart for all of the objects that you have defined. Many of the objects in a system are relatively simple objects and a state machine model would not help implementors to understand these objects. 12.2.5 Specify object interfaces An important part of any design process is the specification of the interfaces between the different components in the design. You need to specify interfaces so that objects and other components can be designed in parallel. Once an interface has been specified, the developers of other objects may assume that interface will be implemented. Designers should avoid interface representation information in their interface design. Rather the representation should be hidden and object operations provided to access and update the data. If the representation is hidden, it can be changed without affecting the objects that use these attributes. This leads to a design which is inherently more maintainable. For example, an array representation of a stack may be changed to a list representation without affecting other objects which use the stack. By contrast, it often makes sense to expose the attributes in a static design model as this is the most compact way of illustrating essential characteristics of the objects. There is not necessarily a simple 1:1 relationship between objects and interfaces. The same object may have several interfaces that are each viewpoints on the methods that it provides. This is supported directly in Java where interfaces are declared separately from objects and objects ‘implement’ interfaces. Equally, a group of objects may all be accessed through a single interface. Object interface design is concerned with specifying the detail of the interface to an object or to a group of objects. This means defining the signatures and semantics of the services that are provided by the object or by a group of objects .
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Object-oriented Design 21
WeatherStation Air quality identifier NOData reportWeather () smokeData reportAirQuality () benzeneData calibrate (instruments) test () collect () startup (instruments) summarise () shutdown (instruments)
Pollution monitoring instruments
NOmeter SmokeMeter
Figure 12.16 New BenzeneMeter objects to support pollution monitoring
Interfaces can be specified in the UML using the same notation as in a class diagram. However, there is no attribute section and the UML stereotype <
An important advantage of an object-oriented approach to design is that it simplifies the problem of making changes to the design. The reason for this is that object state representation does not influence the design. Changing the internal details of an object is unlikely to affect any other system objects. Furthermore, because objects are loosely coupled, it is usually straightforward to introduce new objects without significant effects on the rest of the system. To illustrate the robustness of the object-oriented approach, assume that pollution monitoring capabilities are to be added to each weather station. This involves adding an air quality meter to compute the amount of various pollutants in the atmosphere. The pollution readings are transmitted at the same time as the weather data.
©Ian Sommerville 1999 www.Vidyarthiplus.com www.Vidyarthiplus.com
Identifying design elements
* analysis classes represent conceptual things which can perform behavior.
* In design, analysis classes evolve into a number of different kinds of design elements
In addition, in design we shall also identify:
Events and the Signals that are used to communicate them, allow us to describe the asynchronous triggers of behavior to which the system must respond.
www.Vidyarthiplus.com www.Vidyarthiplus.com
www.Vidyarthiplus.com www.Vidyarthiplus.com
Identify Design Elements in Context:
• In Identify Design Elements, the analysis classes are refined into design elements (design classes and subsystems). • In Use-Case Analysis, you were concerned with the "what." In the architecture activities, you are concerned with the "how" (for example, Design). Architecture is about making choices. • In this module, we will describe WHAT is performed in Identify Design Elements, but will not describe How to do it. Such a discussion is the purpose of an architecture course, which this course is not.
Identify Design Elements Overview:
www.Vidyarthiplus.com www.Vidyarthiplus.com
• The architect performs Identify Design Elements, once per iteration. • Purpose: To analyze interactions of analysis classes to identify Design Model elements • Design Model elements: o Classes o Packages o Subsystems
Identify Design Elements Steps:
• Identify classes and subsystems • Identify subsystem interfaces • Identify Reuse Opportunities
• Update the organization of the Design Model • Checkpoints
www.Vidyarthiplus.com www.Vidyarthiplus.com
1. Identify Classes and subsystems:
• The purpose of Identify Classes and Subsystems is to refine the analysis classes into appropriate Design Model elements. • Analysis classes may be expanded, collapsed, combined, or even deleted in Design. • Analysis classes handle primarily functional requirements, and model objects from the "problem" domain; design elements handle nonfunctional requirements, and model objects from the "solution" domain. • It is in Identify Design Elements that you decide which analysis "classes" are really classes, which are subsystems (which must be further decomposed), and which are existing components and do not need to be "designed" at all. • Once the design classes and subsystems have been created, each must be given a name and a short description. The responsibilities of the original analysis classes should be transferred to the newly created subsystems. In addition, the identified design mechanisms should be linked to design elements.
Identifying Design Classes:
www.Vidyarthiplus.com www.Vidyarthiplus.com
• An analysis class maps directly to a design class if: o It is a simple class o It represents a single logical abstraction o Typically, entity classes survive relatively intact into Design. • More complex analysis classes may: o Split into multiple classes o Become a package o Become a subsystem (discussed later) o Any combination... • In general, there is a many-to-many mapping between analysis classes and design elements. The possible mappings include the following. o An analysis class can become: . One single class in the Design Model. . A part of a class in the Design Model. . An aggregate class in the Design Model (meaning that the parts in this aggregate may not be explicitly modeled in the Analysis Model.) . A group of classes that inherits from the same class in the Design Model. . A group of functionally related classes in the Design Model (for example, a package). . A subsystem in the Design Model. . A relationship in the Design Model. o A relationship between analysis classes can become a class in the Design Model. o Part of an analysis class can be realized by hardware, and not modeled in the Design Model at all. o Any combination of the above.
Group Design Classes in Packages:
• The Design Model can be structured into smaller units to make it easier to understand. • You might want to partition the Design Model for a number for reasons: o You can use packages and subsystems as order, configuration, or delivery units when a system is finished. o Allocation of resources and the competence of different development teams might require that the project be divided among different groups at different sites. o Subsystems can be used to structure the Design Model in a way that reflects the user types. Many change requirements originate from users; subsystems ensure that changes from a particular user type will affect only the parts of the system that correspond to that user type. o Subsystems are used to represent the existing products and services that the system uses.
www.Vidyarthiplus.com www.Vidyarthiplus.com
2. Identifying Interfaces
Purpose
To identify the interfaces of the subsystems based on their responsibilities␀
Steps
Identify a set of candidate interfaces for all subsystems.␀Look for similarities between interfaces.
Define interface dependencies.
Map the interfaces to subsystems.
Define the behavior specified by the interfaces.
Package the interfaces(Stable, well-defined interfaces are key to a stable, resilient architecture.)
Identify candidate interfaces. Organize the subsystem responsibilities into groups of cohesive, related responsibilities. These groupings define the initial, first-cut set of interfaces for the subsystem. To start with, identify an operation for each responsibility, complete with parameters and return values. Look for similarities between interfaces. Look for similar names, similar responsibilities, and similar operations. Extract common operations into a new interface. Be sure to look at existing interfaces as well, re-using them where possible. Define interface dependencies. Add dependency relationships from the interface to all classes and/or interfaces that appear in the interface operation signatures. Map the interfaces to subsystems. Create realization associations from the subsystem to the interface(s) it realizes. Define the behavior specified by the interfaces. If the operations on the interface must be invoked in a particular order, define a state machine that illustrates the publicly visible (or inferred) states that any design element that realizes the interface must support. Package the interfaces. Interfaces can be managed and controlled independently of the subsystems themselves. Partition the interfaces according to their responsibilities.
Interface Guidelines
Interface name: Name the interface to reflect the role it plays in the system. The name should be short — one-to-two words. It is not necessary to include the word "interface" in the name; it is implied by the type of model element (that is, interface).
www.Vidyarthiplus.com www.Vidyarthiplus.com
Interface description: The description should convey the responsibilities of the interface.The description should be several sentences long, up to a short paragraph. The description should not simply restate the name of the interface. Instead, it should illuminate the role the interface plays in the system. Operation definition: Each interface should provide a unique and well-defined set of operations. Operation names should reflect the result of the operation. When an operation sets or gets information, including “set” or “get” in the name of the operation is redundant. Give the operation the same name as the property of the model element that is being set or retrieved. Example: name() returns the name of the object; name(aString) sets the name of the object to aString. The description of the operation should describe what the operation does, including any key algorithms, and what value it returns. Name the parameters of the operation to indicate what information is being passed to the operation. Identify the type of the parameter. Interface documentation: The behavior defined by the interface is specified as a set of operations.
3. Identify Reuse Opportunities
Look for existing subsystems or components that offer similar interfaces. Compare each identified interface to the interfaces provided by existing subsystems or components. There usually will not be an exact match, but approximate matches can be found. Look first for similar behavior and returned values, then consider parameters. Modify the newly identified interfaces to improve the fit. There may be opportunities to make minor changes to a candidate interface that will improve its conformance to the existing interface. Simple changes include rearranging or adding parameters to the candidate interface. They also include factoring the interface by splitting it into several interfaces, one or more of which match those of the existing component, with the "new" behaviors located in a separate interface. Replace candidate interfaces with existing interfaces where exact matches occur. After simplification and factoring, if there is an exact match to an existing interface, eliminate the candidate interface and simply use the existing interface. Map the candidate subsystem to existing components. Look at existing components and the set of candidate subsystems. Factor the subsystems so that existing components are used wherever possible to satisfy the required behavior of the system. Where a candidate subsystem can be realized by an existing component, create traceability between the subsystem and the component. Note in the description for this subsystem that the behavior is satisfied by the associated existing component. In mapping subsystems onto components, consider the design mechanisms associated with the subsystem. Performance or security requirements may disqualify a component from reuse despite an otherwise perfect match between operation signatures.
www.Vidyarthiplus.com www.Vidyarthiplus.com
In organizations that build similar systems, there is often a set of common components that provide many of the architectural mechanisms needed for a new system. There may also be components available in the marketplace that also fill the need for architectural mechanisms. Existing components should be examined to determine their suitability and compatibility within the software architecture. These components can be reverse engineered into the Design Model for examination and incorporation. You can then use design elements as proxies for the components. This allows you to show how what has been bought and what needs to be built interact (a necessary requirement unless you are buying all your components and only doing assembly).
4. Update the organization of the Design Model
Layering Considerations
Layering provides a logical partitioning of packages into layers with certain rules concerning the relationships between layers. Restricting inter-layer and inter-package dependencies makes the system more loosely coupled and easier to maintain. Failure to restrict dependencies causes architectural degradation, and makes the system brittle and difficult to maintain. Visibility: Elements should only depend on elements in the same layer and the next lower layer. Exceptions include cases where packages need direct access to lower-
www.Vidyarthiplus.com www.Vidyarthiplus.com
layer services (for example, primitive services needed throughout the system, such as printing, sending messages, and so forth). There is little value in restricting messages to lower layers if the solution is to effectively implement call pass-throughs in the intermediate layers. Volatility: In the highest layers, put elements that vary when user requirements change. In the lowest layers, put elements that vary when the implementation platform (hardware, language, operating system, database, and so forth) changes. Sandwiched in the middle, put elements that are generally applicable across wide ranges of systems and implementation environments. Add layers when additional partitions within these broad categories help to organize the model. Generality: Abstract model elements tend to be placed lower in the model, where they can be reused. If not implementation-specific, they tend to gravitate toward the middle layers. Number of Layers: For a small system, three layers are sufficient. For a complex system, five-to-seven layers are usually sufficient. For any degree of complexity, more than ten layers should be viewed with suspicion that increases with the number of layers.
5. Checkpoints
A well-structured architecture: • Encompasses a set of classes, typically organized into multiple hierarchies. • Provides a set of collaborations that specify how those classes cooperate to provide various system functions. If the classes contained in a package do not belong there according to the criteria for the package division then move them to other packages or create more packages. If the classes in the packages are not related functionally, then move some of the classes to other packages or create more packages. As a guideline regarding an appropriate ratio between the number of packages and the number of classes, 5 packages and 1,000 classes is probably a sign that something is wrong.
A well-structured class: • Provides a crisp abstraction of some thing drawn from the vocabulary of the problem domain or the solution domain. • Embodies a small, well-defined set of responsibilities, and carries them all out very well. • Provides a clear separation of the abstraction's behavior and its implementation. • Is understandable and simple yet extensible and adaptable.
www.Vidyarthiplus.com www.Vidyarthiplus.com
detailed design
The detailed or low-level design portion of the engineering design process is the task where the engineer can completely describe a product through solid modeling and drawings. Some specifications include:
• Operating parameters • Operating and nonoperating environmental stimuli • Test requirements • External dimensions • Maintenance and testability provisions • Materials requirements • Reliability requirements • External surface treatment • Design life • Packaging requirements • External marking • input machine
The advancement of computer-aided design, or CAD, programs have made the detailed design phase more efficient. This is because a CAD program can provide optimization, where it can reduce volume without hindering the part's quality. It can also calculate stress and displacement using the finite element method to determine stresses throughout the part. It is the engineer's responsibility to determine whether these stresses and displacements are allowable, so the part is safe.
Detailed design of the system is the last design activity before implementation begins. The hardest design problems must be addressed by the detailed design or the design is not complete. The detailed design is still an abstraction as compared to source code, but should be detailed enough to ensure that translation to source is a precise mapping instead of a rough interpretation.
The detailed design should represent the system design in a variety of views where each view uses a different modeling technique. By using a variety of views, different parts of the system can be made clearer by different views. Some views are better at elaborating a systems states whereas other views are better at showing how data flows within the system. Other views are better at showing how different system entities relate to each through class taxonomies for systems that are designed using an object- oriented approach.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Understanding the Need for Detailed Design
Detailed design provides the link for integrating all cross-disciplinary conceptual and preliminary data into a complete, finished digital product definition. Accordingly, today’s detailed design process is characterized by highly sophisticated designs and an ever- increasing demand for data sharing. Since many companies operate in a distributed environment, among partners and design teams, and across time-zones and language barriers, fast, secure information access is essential. It’s an absolute necessity to ensure that everyone is working on the correct version of the data while tracking team decisions and having real-time visibility into the team’s progress. Along the way, engineers must continually manage change and design complexity. They need to assess risks and balance trade-offs while rapidly delivering high quality designs that work reliably and offer customers value. Given the prevalence of electrical content in the majority of today’s products, it is necessary to effectively handle concurrent design of interrelated components, and improve collaboration between all different design disciplines (electrical, mechanical, software). Changes to requirements are frequent, and incorporating those changes into the design process in a managed and controlled way is vital. Balancing changing requirements with cost and quality pressures further complicates matters.And, ever-shrinking product lifecycles place a premium on an organization’s ability to implement automation and design reuse.
Benefits of an Optimized Process for Detailed Design An optimized, formalized, and flexible detailed design process enables companies to rapidly deliver competitive, high quality designs that offer customers real value. Typical benefits of improving the detailed design process may include:
Improve Design Productivity
• Centrally control and manage all design data (mechanical, electrical, software, documents)
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Enable concurrent design of interrelated components • Easily and effectively drive design to meet key requirements • Further automate and streamline the generation of deliverables (e.g., assemblies, drawings, manufacturing process plans)
Increase Design Process Efficiency
• Enable a formalized, automated, and repeatable design processes • Ensure everyone is working on the correct version of the product data • Enable “what if” design investigations, either with or without formal data management • Improve project execution and visibility into team progress
Optimize Design Reuse
• Reduce design cost by supporting part reuse and eliminating component duplication • Improve ability to quickly and easily find appropriately classified designs
Improve Design Collaboration
• Manage global product development involving external suppliers and customers • Provide for secure distributed team and customer design collaboration • Safely share cross-discipline product data across a globally dispersed enterprise product development team • Encourage early and frequent cross-discipline communication; visualize heterogeneous design data
Detailed design is especially vital given that it exists at the intersection of so many other product development processes. Outputs from the detailed design process are used not only as finished good, but also may take the form of modular components useful for developing product variants.
www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 347
www.Vidyarthiplus.com UNIT III - DESIGN PATTERNS Introduction to patterns PATTERN-BASED DESIGN
K EY ach of us has encountered a design problem and silently thought: I wonder C ONCEPTS if anyone has developed a solution for this? The answer is almost always— design yes! The problem is finding the solution; ensuring that it does, in fact, fit mistakes . . . . .359 E the problem you’ve encountered; understanding the constraints that may restrict forces ...... 349 the manner in which the solution is applied; and finally, translating the proposed frameworks . . .352 granularity . . . .369 solution into your design environment. pattern But what if the solution were codified in some manner? What if there was a stan- languages . . . .353 dard way of describing a problem (so you could look it up), and an organized patterns method for representing the solution to the problem? It turns out that software architectural . .360 problems have been codified and described using a standardized template, and so- behavioral . . .351 lutions to them (along with constraints) have been proposed. Called design patterns,
Q UICK What is it? Pattern-based design What are the steps? The requirements model is L OOK creates a new application by finding examined in order to isolate the hierarchical set a set of proven solutions to a clearly of problems to be solved. The problem space is delineated set of problems. Each partitioned so that subsets of problems associ- problem and its solution is described by a design ated with specific software functions and fea- pattern that has been cataloged and vetted by tures can be identified. Problems can also be other software engineers who have encountered organized by type: architectural, component- the problem and implemented the solution while level, algorithmic, user interface, etc. Once a designing other applications. Each design pat- subset of problems is defined, one or more pat- tern provides you with a proven approach to tern repositories are searched to determine if an one part of the problem to be solved. existing design pattern, represented at an ap- Who does it? A software engineer examines each propriate level of abstraction, exists. Patterns problem encountered for a new application and that are applicable are adapted to the specific then attempts to find a relevant solution by needs of the software to be built. Custom prob- searching one or more patterns repositories. lem solving is applied in situations for which no Why is it important? Have you ever heard the patterns can be found. phrase “reinventing the wheel”? It happens all What is the work product? A design model that the time in software development, and it’s a depicts the architectural structure, user interface, waste of time and energy. By using existing and component-level detail is developed. design patterns, you can acquire a proven solu- How do I ensure that I’ve done it right? As each tion for a specific problem. As each pattern is design pattern is translated into some element of applied, solutions are integrated and the appli- the design model, work products are reviewed for cation to be built moves closer to a complete clarity, correctness, completeness, and consis- design. tency with requirements and with one another.
347 www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 348
www.Vidyarthiplus.com 348 PART TWO MODELING
component- this codified method for describing problems and their solution allows the software level ...... 362 engineering community to capture design knowledge in a way that enables it to be generative . . .350 reused. creational . . . .350 The early history of software patterns begins not with a computer scientist but a structural . . . .351 building architect, Christopher Alexander, who recognized that a recurring set of user problems were encountered whenever a building was designed. He characterized interface . . . .366 these recurring problems and their solutions as patterns, describing them in the WebApps . . . .368 following manner [Ale77]:
Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use the solution a million times over without ever doing it the same way twice.
Alexander’s ideas were first translated into the software world in books by Gamma [Gam95], Buschmann [Bus96], and their many colleagues.1 Today, dozens of pattern repositories exist, and pattern-based design can be applied in many different appli- cation domains.
12.1 DESIGN PATTERNS
A design pattern can be characterized as “a three-part rule which expresses a rela- tion between a certain context, a problem, and a solution” [Ale79]. For software design, context allows the reader to understand the environment in which the prob- Forces are those lem resides and what solution might be appropriate within that environment. A set characteristics of the of requirements, including limitations and constraints, acts as a system of forces that problem and attributes of the solution that influences how the problem can be interpreted within its context and how the solu- constrain the way in tion can be effectively applied. which the design can To better understand these concepts, consider a situation2 in which a person must be developed. travel between New York and Los Angeles. In this context, travel will occur within an industrialized country (the United States), using an existing transportation infra- structure (e.g., roads, airlines, railways). The system of forces that will affect the way in which the travel problem is solved will include: how quickly the person wants to get from New York to LA, whether the trip will include site-seeing or stopovers, how much money the person can spend, whether the trip is intended to accomplish a spe- cific purpose, and the personal vehicles the person has at her disposal. Given these forces, the problem (traveling from New York to LA) can be better defined. For example, investigation (requirements gathering) indicates that the person has very little money, owns only a bicycle (and is an avid cyclist), wants to make the trip to raise money for her favorite charity, and has plenty of time to spare. The solution to the problem, given the context and the system of forces, might be a cross-country
1 Earlier discussions of software patterns do exist, but these two classic books were the first cohesive treatments of the subject. 2 This example has been adapted from [Cor98]. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 349
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 349
bike trip. If the forces were different (e.g., travel time must be minimized and the pur- pose of the trip is a business meeting), another solution might be more appropriate. It is reasonable to argue that most problems have multiple solutions, but that a uote: solution is effective only if it is appropriate within the context of the existing prob- “Our responsibility lem. It is the system of forces that causes a designer to choose a specific solution. is to do what we The intent is to provide a solution that best satisfies the system of forces, even when can, learn what we these forces are contradictory. Finally, every solution has consequences that may can, improve the have an impact on other aspects of the software and may themselves become part solutions, and pass them on.” of the system of forces for other problems to be solved within the larger system. Coplien [Cop05] characterizes an effective design pattern in the following way: Richard P. Feynman • It solves a problem: Patterns capture solutions, not just abstract principles or strategies.
• It is a proven concept: Patterns capture solutions with a track record, not theo- ries or speculation.
• The solution isn’t obvious: Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. The best patterns generate a solution to a problem indirectly—a necessary approach for the most difficult problems of design.
• It describes a relationship: Patterns don’t just describe modules, but describe deeper system structures and mechanisms.
• The pattern has a significant human component (minimize human intervention). All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility.
Stated even more pragmatically, a good design pattern captures hard-earned, prag- matic design knowledge in a way that enables others to reuse that knowledge “a mil- lion times over without ever doing it the same way twice.” A design pattern saves you from “reinventing the wheel,” or worse, inventing a “new wheel” that is slightly out of round, too small for its intended use, and too narrow for the ground it will roll over. De- sign patterns, if used effectively, will invariably make you a better software designer.
12.1.1 Kinds of Patterns
One of the reasons that software engineers are interested in (and intrigued by) design patterns is that human beings are inherently good at pattern recognition. If we weren’t, we’d be frozen in space and time—unable to learn from past experience, unwilling to venture forward because of our inability to recognize situations that might lead to high risk, unhinged by a world that seems to have no regularity or log- ical consistency. Luckily, none of this occurs because we do recognize patterns in virtually every aspect of our lives. In the real world, the patterns we recognize are learned over a lifetime of experi- ence. We recognize them instantly and inherently understand what they mean and how they might be used. Some of these patterns provide us with insight into www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 350
www.Vidyarthiplus.com 350 PART TWO MODELING
recurring phenomenon. For example, you’re on your way home from work on the interstate when your navigation system (or car radio) informs you that a serious accident has occurred on the interstate in the opposing direction. You’re 4 miles from the accident, but already you begin to see traffic slowing, recognizing a pattern that we’ll call RubberNecking. People in the travel lanes moving in your direction are slowing at the sight of the accident to get a better view of what happened on the opposite side of the highway. The RubberNecking pattern yields remarkably pre- dictable results (a traffic jam), but it does nothing more than describe a phenome- non. In patterns jargon, it might be called a nongenerative pattern because it describes a context and a problem but it does not provide any clear-cut solution. When software design patterns are considered, we strive to identify and document generative patterns. That is, we identify a pattern that describes an important and A “generative” pattern repeatable aspect of a system and that provides us with a way to build that aspect describes the problem, within a system of forces that are unique to a given context. In an ideal setting, a col- a context, and forces, lection of generative design patterns could be used to “generate” an application or but it also describes a computer-based system whose architecture enables it to adapt to change. Some- pragmatic solution to the problem. times called generativity, “the successive application of several patterns, each encap- sulating its own problem and forces, unfolds a larger solution which emerges indirectly as a result of the smaller solutions” [App00]. Design patterns span a broad spectrum of abstraction and application. Architectural patterns describe broad-based design problems that are solved using a structural approach. Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. Component patterns (also referred to as design patterns) address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement within a larger architecture. Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end users. WebApp patterns address a problem set that is encountered when building WebApps and often incorporates many of the other patterns categories just mentioned. At a lower level of abstraction, idioms describe how to implement all or part of a specific algorithm or data structure for a software component within the context of a specific programming language. 3 Is there a In their seminal book on design patterns, Gamma and his colleagues [Gam95] ? way to focus on three types of patterns that are particularly relevant to object-oriented categorize pattern design: creational patterns, structural patterns, and behavioral patterns. types? Creational patterns focus on the “creation, composition, and representation” of objects. Gamma and his colleagues [Gam95] note that creational patterns “encapsulate knowledge about which concrete classes the system uses“ but at the same time “hide how instances of these classes are created and put together.” Creational patterns provide mechanisms that make the instantiation of objects
3 Gamma and his colleagues [Gam95] are often referred to as the “Gang of Four” (GoF) in patterns literature. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 351
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 351
easier within a system and enforce “constraints on the type and number of objects that can be created within a system” [Maa07]. Structural patterns focus on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure. In essence, they help to establish relationships between entities within a system. For example, struc- tural patterns that focus on class-oriented issues might provide inheritance mecha- nisms that lead to more effective program interfaces. Structural patterns that focus on objects suggest techniques for combining objects within other objects or inte- grating objects into a larger structure. Behavioral patterns address problems associated with the assignment of respon- sibility between objects and the manner in which communication is effected between objects.
INFO Creational, Structural, and Behavioral Patterns A wide variety of design patterns that fit into • Container pattern: create objects for the sole creational, structural, and behavioral categories purpose of holding other objects and managing them. have been proposed and can be found on the Web. • Proxy pattern: a class functioning as an interface to Wikipedia (www.wikipedia.org) notes the following another thing. sampling: • Pipes and filters: a chain of processes where the output of each process is the input of the next. Creational Patterns Behavioral Patterns • Abstract factory pattern: centralize decision of what factory to instantiate. • Chain of responsibility pattern: Command • Factory method pattern: centralize creation of objects are handled or passed on to other objects by an object of a specific type choosing one of several logic-containing processing objects. implementations. • Command pattern: Command objects encapsulate • Builder pattern: separate the construction of a an action and its parameters. complex object from its representation so that the • Event listener: Data are distributed to objects that same construction process can create different are registered to receive them. representations. • Interpreter pattern: Implement a specialized • Prototype pattern: used when the inherent cost of computer language to rapidly solve a specific set of creating a new object in the standard way (e.g., using problems. the “new” keyword) is prohibitively expensive for a • Iterator pattern: Iterators are used to access the given application. elements of an aggregate object sequentially without • Singleton pattern: restrict instantiation of a class to exposing its underlying representation. one object. • Mediator pattern: Provides a unified interface to a set of interfaces in a subsystem. Structural Patterns • Visitor pattern: A way to separate an algorithm • Adapter pattern: “adapts” one interface for a class from an object. into one that a client expects. • Single-serving visitor pattern: Optimize the • Aggregate pattern: a version of the composite implementation of a visitor that is allocated, used only pattern with methods for aggregation of children. once, and then deleted. • Bridge pattern: decouple an abstraction from its • Hierarchical visitor pattern: Provide a way to visit implementation so that the two can vary independently. every node in a hierarchical data structure such as a tree. • Composite pattern: a tree structure of objects Comprehensive descriptions of each of these patterns can where every object has the same interface. be obtained via links at www.wikipedia.org. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 352
www.Vidyarthiplus.com 352 PART TWO MODELING
12.1.2 Frameworks
Patterns themselves may not be sufficient to develop a complete design. In some A framework is a cases it may be necessary to provide an implementation-specific skeletal infrastruc- reusable “mini- ture, called a framework, for design work. That is, you can select a “reusable mini- architecture” that architecture that provides the generic structure and behavior for a family of software serves as a foundation abstractions, along with a context . . . which specifies their collaboration and use from which other design patterns can be within a given domain” [Amb98]. applied. A framework is not an architectural pattern, but rather a skeleton with a collec- tion of “plug points” (also called hooks and slots) that enable it to be adapted to a spe- cific problem domain. The plug points enable you to integrate problem-specific classes or functionality within the skeleton. In an object-oriented context, a frame- work is a collection of cooperating classes. Gamma and his colleagues [Gam95] describe the differences between design patterns and frameworks in the following manner:
1. Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. A strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly....
2. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns but the reverse is never true.
3. Design patterns are less specialized than frameworks. Frameworks always have a particular application domain. In contrast, design patterns can be used in nearly any kind of application. While more specialized design patterns are certainly possible, even these wouldn’t dictate an application architecture. In essence, the designer of a framework will argue that one reusable mini- architecture is applicable to all software to be developed within a limited domain of application. To be most effective, frameworks are applied with no changes. Addi- tional design elements may be added, but only via the plug points that allow the designer to flesh out the framework skeleton.
12.1.3 Describing a Pattern
Pattern-based design begins with the recognition of patterns within the application you intend to build, continues with a search to determine whether others have addressed the pattern, and concludes with the application of an appropriate pattern to the problem at hand. The second of these three tasks is often the most difficult. How do you find patterns that fit your needs? An answer to this question must rely on effective communication of the problem the pattern addresses, the context in which the pattern resides, the system of forces that mold the context, and the solution that is proposed. To communicate this information unambiguously, a standard form or template for pattern descriptions is required. Although a number of different pattern templates have been proposed, www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 353
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 353
almost all contain a major subset of the content suggested by Gamma and his colleagues [Gam95]. A simplified pattern template is shown in the sidebar.
INFO Design Pattern Template
Pattern name—describes the essence of the Intent—describes the pattern and what it does pattern in a short but expressive name Collaborations—describes how other patterns contribute to Problem—describes the problem that the pattern addresses the solution Motivation—provides an example of the problem Consequences—describes the potential trade-offs that must Context—describes the environment in which the problem be considered when the pattern is implemented and resides including the application domain the consequences of using the pattern Forces—lists the system of forces that affect the manner in Implementation—identifies special issues that should be which the problem must be solved; includes a discussion considered when implementing the pattern of limitations and constraints that must be considered Known uses—provides examples of actual uses of the Solution—provides a detailed description of the solution design pattern in real applications proposed for the problem Related patterns—cross-references related design patterns
The names of design patterns should be chosen with care. One of the key techni- uote: cal problems in pattern-based design is the inability to find existing patterns when “Patterns are half- hundreds or thousands of candidate patterns exist. The search for the “right” pattern baked—meaning is aided immeasurably by a meaningful pattern name. you always have A pattern template provides a standardized means for describing a design pattern. to finish them Each of the template entries represents characteristics of the design pattern that can yourself and adapt them to your own be searched (e.g., via a database) so that the appropriate pattern can be found. environment.” 12.1.4 Pattern Languages and Repositories Martin Fowler When we use the term language, the first thing that comes to mind is either a natu- ral language (e.g., English, Spanish, Chinese) or a programming language (e.g., C , Java). In both cases the language has a syntax and semantics that are used to com- municate ideas or procedural instructions in an effective manner. When the term language is used in the context of design patterns, it takes on a slightly different meaning. A pattern language encompasses a collection of patterns, each described using a standardized template (Section 12.1.3) and interrelated to show how these patterns collaborate to solve problems across an application domain.4 In a natural language, words are organized into sentences that impart meaning. The structure of sentences is described by the language’s syntax. In a pattern lan- guage, design patterns are organized in a way that provides a “structured method of describing good design practices within a particular domain.”5
4 Christopher Alexander originally proposed pattern languages for building architecture and urban planning. Today, pattern languages have been developed for everything from the social sciences to the software engineering process. 5 This Wikipedia description can be found at http://en.wikipedia.org/wiki/Pattern_language. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 354
www.Vidyarthiplus.com 354 PART TWO MODELING
In a way, a pattern language is analogous to a hypertext instruction manual for problem solving in a specific application domain. The problem domain under con- If you can’t find a sideration is first described hierarchically, beginning with broad design problems as- pattern language that sociated with the domain and then refining each of the broad problems into lower addresses your problem domain, look levels of abstraction. In a software context, broad design problems tend to be archi- for analogies in tectural in nature and address the overall structure of the application and the data or another set of content that serve it. Architectural problems are refined to lower levels of abstrac- patterns. tion, leading to design patterns that solve subproblems and collaborate with one another at the component (or class) level. Rather than a sequential list of patterns, a pattern language represents an interconnected collection in which the user can WebRef begin with a broad design problem and “burrow down” to uncover specific problems For a listing of useful patterns languages and their solutions. see c2.com/ppr/ Dozens of pattern languages have been proposed for software design [Hil08]. In titles.html. Additional information most cases, the design patterns that are part of pattern language are stored in a Web- can be obtained at accessible patterns repository (e.g., [Boo08], [Cha03], [HPR02]). The repository pro- hillside.net/ vides an index of all design patterns and contains hypermedia links that enable the patterns/. user to understand the collaborations between patterns.
12.2 PATTERN-BASED S OFTWARE D ESIGN
The best designers in any field have an uncanny ability to see patterns that charac- terize a problem and corresponding patterns that can be combined to create a solu- tion. The software developers at Microsoft [Mic04] discuss this when they write:
While pattern-based design is relatively new in the field of software development, indus- trial technology has used pattern-based design for decades, perhaps even centuries. Catalogs of mechanisms and standard configurations provide design elements that are used to engineer automobiles, aircraft, machine tools, and robots. Applying pattern- based design to software development promises the same benefits to software as it does to industrial technology: predictability, risk mitigation, and increased productivity.
Throughout the design process, you should look for every opportunity to apply existing design patterns (when they meet the needs of the design) rather than creat- ing new ones.
12.2.1 Pattern-Based Design in Context
Pattern-based design is not used in a vacuum. The concepts and techniques dis- cussed for architectural, component-level, and user interface design (Chapters 9 through 11) are all used in conjunction with a pattern-based approach. In Chapter 8, I noted that a set of quality guidelines and attributes serve as the basis for all software design decisions. The decisions themselves are influenced by a set of fundamental design concepts (e.g., separation of concerns, stepwise refine- ment, functional independence) that are achieved using heuristics that have evolved over many decades, and best practices (e.g., techniques, modeling notation) that www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 355
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 355
FIGURE 12.1
Pattern-based Requirements design in model context Design begins
Extract Consider Consider problem, context design quality design concepts forces attributes
Addressed by pattern?
yes no
Begin Apply other pattern-based design methods design tasks and notation
Design model
have been proposed to make design easier to perform and more effective as a basis for construction. The role of pattern-based design in all of this is illustrated in Figure 12.1. A soft- ware designer begins with a requirements model (either explicit or implied) that presents an abstract representation of the system. The requirements model describes the problem set, establishes the context, and identifies the system of forces that hold sway. It may imply the design in an abstract manner, but the requirements model does little to represent the design explicitly. As you begin your work as a designer, it’s always important to keep quality attributes in mind. These attributes (e.g., a design must implement all explicit require- ments addressed in the requirements model) establish a way to assess software qual- ity but do little to help you actually achieve it. The design you create should exhibit the fundamental design concepts discussed in Chapter 8. Therefore, you should ap- ply proven techniques for translating the abstractions contained in the requirements model into a more concrete form that is the software design. To accomplish this, you’ll use the methods and modeling tools available for architectural, component- level, and interface design. But only when you’re faced with a problem, context, and system of forces that have not been solved before. If a solution already exists, use it! And that means applying a pattern-based design approach. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 356
www.Vidyarthiplus.com 356 PART TWO MODELING
12.2.2 Thinking in Patterns
In an excellent book on pattern-based design, Shalloway and Trott [Sha05] comment on a “new way of thinking” when one uses patterns as part of the design activity:
I had to open my mind to a new way of thinking. And when I did so, I heard [Christopher] Alexander say that “good software design cannot be achieved simply by adding together performing parts.”
Good design begins by considering context—the big picture. As context is evaluated, you extract a hierarchy of problems that must be solved. Some of these problems will be global in nature, while others will address specific features and functions of the software. All will be affected by a system of forces that will influence the nature of the solution that is proposed. Shalloway and Trott [Sha05] suggest the following approach6 that enables a designer to think in patterns:
Pattern- 1. Be sure you understand the big picture—the context in which the software to ? based design be built resides. The requirements model should communicate this to you. looks interesting 2. Examining the big picture, extract the patterns that are present at that level for the problem I have to solve. of abstraction. How do I get 3. Begin your design with “big picture” patterns that establish a context or started? skeleton for further design work. 4. “Work inward from the context” [Sha05] looking for patterns at lower levels of abstraction that contribute to the design solution. 5. Repeat steps 1 to 4 until the complete design is fleshed out. 6. Refine the design by adapting each pattern to the specifics of the software you’re trying to build.
It’s important to note that patterns are not independent entities. Design patterns that are present at a high level of abstraction will invariably influence the manner in which other patterns are applied at lower levels of abstraction. In addition, patterns often collaborate with one another. The implication—when you select an architec- tural pattern, it may very well influence the component-level design patterns you choose. Likewise, when you select a specific interface design pattern, you are some- times forced to use other patterns that collaborate with it. To illustrate, consider the SafeHomeAssured.com WebApp. If you consider the big picture, the WebApp must address a number of fundamental problems such as:
• How to provide information about SafeHome products and services • How to sell SafeHome products and services to customers • How to establish Internet-based monitoring and control of an installed security system
6 Based on the work of Christopher Alexander [Ale79]. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 357
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 357
Each of these fundamental problems can be further refined into a set of subprob- lems. For example How to sell via the Internet implies an E-commerce pattern that itself implies a large number of patterns at lower levels of abstraction. The E-commerce pattern (likely, an architectural pattern) implies mechanisms for setting up a customer account, displaying the products to be sold, selecting prod- ucts for purchase, and so forth. Hence, if you think in patterns, it is important to determine whether a pattern for setting up an account exists. If SetUpAccount is available as a viable pattern for the problem context, it may collaborate with other patterns such as BuildInputForm, ManageFormsInput, and Validate- FormsEntry. Each of these patterns delineates problems to be solved and solu- tions that may be applied.
12.2.3 Design Tasks
The following design tasks are applied when a pattern-based design philosophy is used:
1. Examine the requirements model and develop a problem hierarchy. Describe each problem and subproblem by isolating the problem, the
What are the context, and the system of forces that apply. Work from broad problems (high ? tasks level of abstraction) to smaller subproblems (at lower levels of abstraction). required to create 2. Determine if a reliable pattern language has been developed for the a pattern-based problem domain. As I noted in Section 12.1.4, a pattern language addresses design? problems associated with a specific application domain. The SafeHome software team would look for a pattern language developed specifically for home security products. If that level of pattern language specificity could not be found, the team would partition the SafeHome software problem into a series of generic problem domains (e.g., digital device monitoring problems, user interface problems, digital video management problems) and search for appropriate pattern languages. 3. Beginning with a broad problem, determine whether one or more architectural patterns is available for it. If an architectural pattern is available, be certain to examine all collaborating patterns. If the pattern is appropriate, adapt the design solution proposed and build a design model element that adequately represents it. As I noted in Section 12.2.2, a broad problem for the SafeHomeAssured.com WebApp is addressed with an E-commerce pattern. This pattern will suggest a specific architecture for addressing e-commerce requirements. 4. Using the collaborations provided for the architectural pattern, examine subsystem or component-level problems and search for appropriate patterns to address them. It may be necessary to search through other pattern repositories as well as the list of patterns that corre- sponds to the architectural solution. If an appropriate pattern is found, adapt www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 358
www.Vidyarthiplus.com 358 PART TWO MODELING
the design solution proposed and build a design model element that adequately represents it. Be certain to apply step 7. 5. Repeat steps 2 through 5 until all broad problems have been addressed. The implication is to begin with the big picture and elaborate to solve problems at increasingly more detailed levels. 6. If user interface design problems have been isolated (this is almost always the case), search the many user interface design pattern repositories for appropriate patterns. Proceed in a manner similar to steps 3, 4, and 5. 7. Regardless of its level of abstraction, if a pattern language and/or patterns repository or individual pattern shows promise, compare the problem to be solved against the existing pattern(s) presented. Be certain to examine context and forces to ensure that the pattern does, in fact, provide a solution that is amenable to the problem. 8. Be certain to refine the design as it is derived from patterns using design quality criteria as a guide.
Although this design approach is top-down, real-life design solutions are sometimes more complex. Gillis [Gil06] comments on this when he writes:
Design patterns in software engineering are meant to be used in a deductive, rationalis- tic fashion. So you have this general problem or requirement, X, design pattern Y solves X, therefore use Y. Now, when I reflect on my own process—and I’ve got reason to believe that I’m not alone here—I find that it’s more organic than that, more inductive than deductive, more bottom-up than top-down.
Obviously, there’s a balance to be achieved. When a project is in the initial bootstrap phase and I’m trying to make the jump from abstract requirements to a concrete design solution, I’ll often perform a sort of breadth-first search . . . I’ve found design patterns to be helpful, allowing me to quickly frame up the design problem in concrete terms.
In addition, the pattern-based approach must be used in conjunction with other soft- ware design concepts and techniques.
12.2.4 Building a Pattern-Organizing Table
As pattern-based design proceeds, you may encounter trouble organizing and categorizing candidate patterns from multiple pattern languages and repositories. Entries in the table can To help organize your evaluation of candidate patterns, Microsoft [Mic04] suggests be supplemented with the creation of a pattern-organizing table that takes the general form shown in an indication of the relative applicability Figure 12.2. of the pattern. A pattern-organizing table can be implemented as a spreadsheet model using the form shown in the figure. An abbreviated list of problem statements, organized by data/content, architecture, component-level, and user interface issues, is presented in the left-hand (shaded) column. Four pattern types—database, application, www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 359
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 359
FIGURE 12.2
A pattern- Database Application Implementation Infrastructure organizing table Data/Content Source: Adapted from [Mic04]. Problem statement ... PatternName(s) PatternName(s) Problem statement ... PatternName(s) PatternName(s) Problem statement ... PatternName(s) PatternName(s) Architecture Problem statement ... PatternName(s) Problem statement ... PatternName(s) PatternName(s) Problem statement ... Component-level Problem statement ... PatternName(s) PatternName(s) Problem statement ... PatternName(s) Problem statement ... PatternName(s) PatternName(s) User interface Problem statement ... PatternName(s) PatternName(s) Problem statement ... PatternName(s) PatternName(s) Problem statement ... PatternName(s) PatternName(s)
implementation, and infrastructure—are listed across the top row. The names of candidate patterns are noted in the cells of the table. To provide entries for the organizing table, you’ll search through pattern languages and repositories for patterns that address a particular problem statement. When one or more candidate patterns is found, it is entered in the row correspon- ding to the problem statement and the column that corresponds to the pattern type. The name of the pattern is entered as a hyperlink to the URL of the Web address that contains a complete description of the pattern.
12.2.5 Common Design Mistakes
Pattern-based design can make you a better software designer, but it is not a panacea. Like all design methods, you must begin with first principles, emphasizing software quality fundamentals and ensuring that the design does, in fact, address the needs expressed by the requirements model. A number of common mistakes occur when pattern-based design is used. In some Don’t force a pattern, cases, not enough time has been spent to understand the underlying problem and its even if it addresses the context and forces, and as a consequence, you select a pattern that looks right but problem at hand. If the context and forces are is inappropriate for the solution required. Once the wrong pattern is selected, you wrong, look for refuse to see your error and force-fit the pattern. In other cases, the problem has another pattern. forces that are not considered by the pattern you’ve chosen, resulting in a poor or www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 360
www.Vidyarthiplus.com 360 PART TWO MODELING
erroneous fit. Sometimes a pattern is applied too literally and the required adapta- tions for your problem space are not implemented. Can these mistakes be avoided? In most cases the answer is “yes.” Every good de- signer looks for a second opinion and welcomes review of her work. The review tech- niques discussed in Chapter 15 can help to ensure that the pattern-based design you’ve developed will result in a high-quality solution for the software problem to be solved.
12.3 ARCHITECTURAL PATTERNS
If a house builder decides to construct a center-hall colonial, there is a single archi- tectural style that can be applied. The details of the style (e.g., number of fireplaces, façade of the house, placement of doors and windows) can vary considerably, but once A software architecture may have a number of the decision on the overall architecture of the house is made, the style is imposed architectural patterns on the design.7 that address issues Architectural patterns are a bit different. For example, every house (and every such as concurrency, architectural style for houses) employs a Kitchen pattern. The Kitchen pattern and persistence, and distribution. patterns it collaborates with address problems associated with the storage and preparation of food, the tools required to accomplish these tasks, and rules for place- ment of these tools relative to workflow in the room. In addition, the pattern might address problems associated with countertops, lighting, wall switches, a central is- land, flooring, and so on. Obviously, there is more than a single design for a kitchen, often dictated by the context and system of forces. But every design can be conceived within the context of the “solution” suggested by the Kitchen pattern. What are As I have already noted, architectural patterns for software define a specific ? some typical approach for handling some characteristic of the system. Bosch [Bos00] and Booch architectural [Boo08] define a number of architectural pattern domains. Representative examples pattern domains? are provided in the paragraphs that follow:
Access control. There are many situations in which access to data, features, and functionality delivered by an application is limited to specifically defined end users. From an architectural point of view, access to some portion of the software archi- tecture must be controlled rigorously.
Concurrency. Many applications must handle multiple tasks in a manner that sim- ulates parallelism (i.e., this occurs whenever multiple “parallel” tasks or components are managed by a single processor). There are a number of different ways in which an application can handle concurrency, and each can be presented by a different architectural pattern. For example, one approach is to use an OperatingSystem- ProcessManagement pattern that provides built-in OS features that allow
7 This implies that there will be a central foyer and hallway, that rooms will be placed to the left and right of the foyer, that the house will have two (or more) stories, that the bedrooms of the house will be upstairs, and so on. These “rules” are imposed once the decision is made to use the center- hall colonial style. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 361
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 361
components to execute concurrently. The pattern also incorporates OS functionality that manages communication between processes, scheduling, and other capabilities required to achieve concurrency. Another approach might be to define a task sched- uler at the application level. A TaskScheduler pattern contains a set of active ob- jects that each contains a tick() operation [Bos00]. The scheduler periodically invokes tick() for each object, which then performs the functions it must perform before re- turning control back to the scheduler which then invokes the tick() operation for the next concurrent object.
Distribution. The distribution problem addresses the manner in which systems or components within systems communicate with one another in a distributed environ- ment. Two subproblems are considered: (1) the way in which entities connect to one another, and (2) the nature of the communication that occurs. The most common architectural pattern established to address the distribution problem is the Broker pattern. A broker acts as a “middleman” between the client component and a server com- ponent. The client sends a message to the broker (containing all appropriate information for the communication to be effected) and the broker completes the connection.
Persistence. Data persists if it survives past the execution of the process that created it. Persistent data are stored in a database or file and may be read or modified by other processes at a later time. In object-oriented environments, the idea of a persistent ob- ject extends the persistence concept a bit further. The values of all of the object’s at- tributes, the general state of the object, and other supplementary information are stored for future retrieval and use. In general, two architectural patterns are used to achieve persistence—a DatabaseManagementSystem pattern that applies the storage and retrieval capability of a DBMS to the application architecture or an Application Level- Persistence pattern that builds persistence features into the application architecture (e.g., word processing software that manages its own document structure).
Before any one of the representative architectural patterns noted in the preceding paragraphs can be chosen, it must be assessed for its appropriateness for the appli- cation and the overall architectural style, as well as the context and system of forces that it specifies.
INFO Design Pattern Repositories There are many sources for design patterns avail- Portland Pattern Repository able on the Web. Some patterns can be obtained http://c2.com/ppr/index.html from individually published pattern languages, while Contains pointers to a wide variety of patterns others are available as part of a patterns portal or patterns resources and collections. repository. The following Web sources are worth a look: Pattern Index http://c2.com/cgi/wiki?PatternIndex An “eclectic collection of patterns” Hillside.net http://hillside.net/patterns/ Booch’s Architecture Patterns Handbook One of the Web’s most comprehensive collections of www.booch.com/architecture/index.jsp patterns and pattern languages. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 362
www.Vidyarthiplus.com 362 PART TWO MODELING
Bibliographic reference to hundreds of architectural UI Design Patterns and component design patterns www.cs.helsinki.fi/u/salaakso/patterns/
UI Patterns Collections Specialized Design Patterns: UI/HCI Patterns Aircraft Avionics www.hcipatterns.org/patterns.html http://g.oswego.edu/dl/acs/acs/acs.html Jennifer Tidwell’s UI patterns Business Information Systems www.time-tripper.com/uipatterns/ www.objectarchitects.de/arcus/cookbook/ Mobile UI Design Patterns Distributed Processing http://patterns.littlespringsdesign.com/ www.cs.wustl.edu/~schmidt/ wikka.php?wakka=Mobile IBM Patterns for e-Business www128.ibm.com/ developerworks/patterns/ Patterns Yahoo! Design Pattern Library Pattern Language for UI Design http://developer.yahoo.com/ypatterns/ www.maplefish.com/todd/papers/ WebPatterns.org http://webpatterns.org/ Experiences.html Interaction Design Library for Games www.eelke.com/research/usability.html
12.4 COMPONENT-LEVEL D ESIGN PATTERNS
Component-level design patterns provide you with proven solutions that address one or more subproblems extracted from the requirements model. In many cases, design patterns of this type focus on some functional element of a system. For example, the SafeHomeAssured.com application must address the following design subproblem: How can we get product specifications and related information for any SafeHome device? Having enunciated the subproblem that must be solved, you should now consider context and the system of forces that affect the solution. Examining the appropriate requirements model use case, you learn that the consumer uses the specification for a SafeHome device (e.g., a security sensor or camera) for informational purposes. However, other information that is related to the specification (e.g., pricing) may be used when e-commerce functionality is selected. The solution to the subproblem involves a search. Since searching is a very com- mon problem, it should come as no surprise that there are many search-related patterns. Looking through a number of patterns repositories, you find the following patterns, along with the problem that each solves:
AdvancedSearch. Users must find a specific item in a large collection of items. HelpWizard. Users need help on a certain topic related to the website or when they need to find a specific page within the site. SearchArea. Users must find a page. SearchTips. Users need to know how to control the search engine. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 363
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 363
SearchResults. Users have to process a list of search results. SearchBox. Users have to find an item or specific information.
For SafeHomeAssured.com the number of products is not particularly large, and each has a relatively simple categorization, so AdvancedSearch and HelpWizard are probably not necessary. Similarly, the search is simple enough not to require SearchTips. The description of SearchBox, however, is given (in part) as:
Search Box (Adapted from www.welie.com/patterns/showPattern.php?patternID=search.) Problem: The users need to find an item or specific information. Motivation: Any situation in which a keyword search is applied across a collection of content objects organized as Web pages. Context: Rather than using navigation to acquire information or content, the user wants to do a direct search through content contained on multiple Web pages. Any website that already has primary navigation. User may want to search for an item in a category. User might want to further specify a query. Forces: The website already has primary navigation. Users may want to search for an item in a category. Users might want to further specify a query using simple Boolean operators. Solution: Offer search functionality consisting of a search label, a keyword field, a filter if applicable, and a “go” button. Pressing the return key has the same function as selecting the go button. Also pro- vide Search Tips and examples in a separate page. A link to that page is placed next to the search functionality. The edit box for the search term is large enough to accommodate three typical user queries (typically around 20 characters). If the number of filters is more than 2, use a combo box for filters selection, otherwise a radio button. The search results are presented on a new page with a clear label containing at least “Search results” or similar. The search function is repeated in the top part of the page with the entered keywords, so that the users know what the keywords were. The pattern description continues with other entries as described in Section 12.1.3.
The pattern goes on to describe how the search results are accessed, presented, matched, and so on. Based on this, the SafeHomeAssured.com team can design the components required to implement the search or (more likely) acquire existing reusable components. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 364
www.Vidyarthiplus.com 364 PART TWO MODELING
SAFEHOME
Applying Patterns
The scene: Informal discussion during Vinod: Well, why not just use the the design of a software increment that implements sensor InteractiveDeviceControl pattern! control via the Internet for SafeHomeAssured.com. Jamie: Uhmmm—what’s that? I haven’t heard of it? The players: Jamie (responsible for design) and Vinod Vinod: It’s basically a pattern for exactly the problem (SafeHomeAssured.com chief system architect). you are describing. The solution it proposes is basically to The conversation: create a control connection to the server with the device, Vinod: So how is the design of the camera control through which control commands can be sent. That way interface coming along? you don’t need to send normal HTTP requests. And the pattern even shows how you can implement this using Jamie: Not too bad. I’ve designed most of the capability some simple AJAX techniques. You have some simple to connect to the actual sensors without too many problems. client-side JavaScript that communicates directly with the I’ve also started thinking about the interface for the users to server and sends the commands as soon as the user does actually move, pan, and zoom the cameras from a remote anything. Web page, but I’m not sure I’ve got it right yet. Jamie: Cool! That’s just what I needed to solve this Vinod: What have you come up with? thing. Where do I find it? Jamie: Well, the requirements are that the camera control Vinod: It’s available in an online repository. Here’s needs to be highly interactive—as the user moves the control, the URL. the camera should move as soon as possible. So, I was thinking of having a set of buttons laid out like a normal Jamie: I’ll go check it out. camera, but when the user clicks them, it controls the camera. Vinod: Yep—but remember to check the consequences Vinod: Hmmm. Yeah, that would work, but I’m not sure field for the pattern. I seem to remember that there was it’s right—for each click of a control you need to wait for something in there about needing to be careful about the whole client-server communication to occur, and so issues of security. I think it might be because you are you won’t get a good sense of quick feedback. creating a separate control channel and so bypassing the Jamie: That’s what I thought—and why I wasn’t very normal Web security mechanisms. happy with the approach, but I’m not sure how else Jamie: Good point. I probably wouldn’t have thought I might do it. of that! Thanks.
12.5 USER I NTERFACE D ESIGN PATTERNS
Hundreds of user interface (UI) patterns have been proposed in recent years. Most fall within one of the following 10 categories of patterns (discussed with a represen- tative example8) as described by Tidwell [Tid02] and vanWelie [Wel01]: Whole UI. Provide design guidance for top-level structure and navigation throughout the entire interface. Pattern: TopLevelNavigation Brief description: Used when a site or application implements a number of major functions. Provides a top-level menu, often coupled with a logo or
8 An abbreviated pattern template is used here. Full pattern descriptions (along with dozens of other patterns) can be found at [Tid02] and [Wel01]. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 365
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 365
identifying graphic, that enables direct navigation to any of the system’s major functions. Details: Major functions (generally limited to between four and seven func- tion names) are listed across the top of the display (vertical column formats are also possible) in a horizontal line of text. Each name provides a link to the appropriate function or information source. Often used with the BreadCrumbs pattern discussed later. Navigation elements: Each function/content name represents a link to the appropriate function or content. Page layout. Address the general organization of pages (for websites) or distinct screen displays (for interactive applications). Pattern: CardStack Brief description: Used when a number of specific subfunctions or content categories related to a feature or function must be selected in random order. Provides the appearance of a stack of tabbed cards, each selectable with a mouse click and each representing specific subfunctions or content categories. Details: Tabbed cards are a well-understood metaphor and are easy for the user to manipulate. Each tabbed card (divider) may have a slightly different format. Some may require input and have buttons or other navigation mech- anisms; others may be informational. May be combined with other patterns such as DropDownList, Fill-in-the-Blanks, and others. Navigation elements: A mouse click on a tab causes the appropriate card to appear. Navigation features within the card may also be present, but in general, these should initiate a function that is related to card data, not cause an actual link to some other display. Forms and input. Consider a variety of design techniques for completing form- level input. Pattern: Fill-in-the-Blanks Brief description: Allow alphanumeric data to be entered in a “text box.” Details: Data may be entered within a text box. In general, the data are validated and processed after some text or graphic indicator (e.g., a button containing “go,” “submit,” “next”) is picked. In many cases this pattern can be combined with drop-down list or other patterns (e.g., SEARCH
Tables. Provide design guidance for creating and manipulating tabular data of all kinds. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 366
www.Vidyarthiplus.com 366 PART TWO MODELING
Pattern: SortableTable Brief description: Display a long list of records that can be sorted by selecting a toggle mechanism for any column label. Details: Each row in the table represents a complete record. Each column represents one field in the record. Each column header is actually a selec- table button that can be toggled to initiate an ascending or descending sort on the field associated with the column for all records displayed. The table is generally resizable and may have a scrolling mechanism if the number of records is larger than available window space. Navigation elements: Each column header initiates a sort on all records. No other navigation is provided, although in some cases, each record may itself contain navigation links to other content or functionality. Direct data manipulation. Address data editing, modification, and transformation. Pattern: BreadCrumbs Brief description: Provides a full navigation path when the user is working with a complex hierarchy of pages or display screens. Details: Each page or display screen is given a unique identifier. The naviga- tion path to the current location is specified in a predefined location for every display. The path takes the form: home>major topic page>subtopic page> specific page>current page. Navigation elements: Any of the entries within the bread crumbs display can be used as a pointer to link back to a higher level of the hierarchy. Navigation. Assist the user in navigating through hierarchical menus, Web pages, and interactive display screens. Pattern: EditInPlace Brief description: Provide simple text editing capability for certain types of content in the location that it is displayed. No need for the user to enter a text editing function or mode explicitly. Details: The user sees content on the display that must be changed. A mouse double click on the content indicates to the system that editing is desired. The content is highlighted to signify that editing mode is available and the user makes appropriate changes. Navigation elements: None. Searching. Enable content-specific searches through information maintained within a website or contained by persistent data stores that are accessible via an interactive application. Pattern: SimpleSearch Brief description: Provides the ability to search a website or persistent data source for a simple data item described by an alphanumeric string. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 367
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 367
Details: Provides the ability to search either locally (one page or one file) or globally (entire site or complete database) for the search string. Generates a list of “hits” in order of their probability of meeting the user’s needs. Does not provide multiple item searches or special Boolean operations (see advanced search pattern). Navigation elements: Each entry in the list of hits represents a navigation link to the data referenced by the entry. Page elements. Implement specific elements of a Web page or display screen. Pattern: Wizard Brief description: Takes the user through a complex task one step at a time, providing guidance for the completion of the task through a series of simple window displays. Details: Classic example is a registration process that contains four steps. The wizard pattern generates a window for each step, requesting specific information from the user one step at a time. Navigation elements: Forward and back navigation allows the user to revisit each step in the wizard process. E-commerce. Specific to websites, these patterns implement recurring elements of e-commerce applications. Pattern: ShoppingCart Brief description: Provides a list of items selected for purchase. Details: Lists item, quantity, product code, availability (in stock, out of stock), price, delivery information, shipping costs, and other relevant purchase infor- mation. Also provides ability to edit (e.g., remove, change quantity). Navigation elements: Contains ability to proceed with shopping or go to checkout. Miscellaneous. Patterns that do not easily fit into one of the preceding cate- gories. In some cases, these patterns are domain dependent or occur only for specific classes of users. Pattern: ProgressIndicator Brief description: Provides an indication of progress when an operation takes longer than n seconds. Details: Represented as an animated icon or a message box that contains some visual indication (e.g., a rotating “barber pole,” a slider with a percent complete indicator) that processing is under way. May also contain a text content indication of the status of processing. Navigation elements: Often contains a button that allows the user to pause or cancel processing. www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 368
www.Vidyarthiplus.com 368 PART TWO MODELING
Each of the preceding example patterns (and all patterns within each category) would also have a complete component-level design, including design classes, attributes, operations, and interfaces. A comprehensive discussion of user interface patterns is beyond the scope of this book. If you have further interest, see [Duy02], [Bor01], [Tid02], and [Wel01] for further information.
12.6 WEBA PP D ESIGN PATTERNS
Throughout this chapter you’ve learned that there are different types of patterns and many different ways they can be categorized. When you consider the design prob- lems that must be solved when a WebApp is to be built, it’s worth considering pat- tern categories by focusing on two dimensions: the design focus of the pattern and its level of granularity. Design focus identifies which aspect of the design model is relevant (e.g., information architecture, navigation, interaction). Granularity identi- fies the level of abstraction that is being considered (e.g., does the pattern apply to the entire WebApp, to a single Web page, to a subsystem, or an individual WebApp component?).
12.6.1 Design Focus
In earlier chapters I emphasized a design progression that begins by considering architecture, component-level issues, and user interface representations. At each step, the problems you consider and the solutions you propose begin at a high level of abstraction and slowly become more detailed and specific. Stated another way, Your focus becomes design focus becomes “narrower” as you move further into design. The problems “narrower” the further you move into design. (and solutions) you will encounter when designing an information architecture for a WebApp are different from the problems (and solutions) that are encountered when performing interface design. Therefore, it should come as no surprise that patterns for WebApp design can be developed for different levels of design focus, so that you can address the unique problems (and related solutions) that are encountered at each level. WebApp patterns can be categorized using the following levels of design focus:
• Information architecture patterns relate to the overall structure of the information space, and the ways in which users will interact with the information. • Navigation patterns define navigation link structures, such as hierarchies, rings, tours, and so on. • Interaction patterns contribute to the design of the user interface. Patterns in this category address how the interface informs the user of the conse- quences of a specific action, how a user expands content based on usage
www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 369
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 369
context and user desires, how to best describe the destination that is implied by a link, how to inform the user about the status of an ongoing interaction, and interface-related issues. • Presentation patterns assist in the presentation of content as it is presented to the user via the interface. Patterns in this category address how to organize user interface control functions for better usability, how to show the relation- ship between an interface action and the content objects it affects, and how to establish effective content hierarchies. • Functional patterns define the workflows, behaviors, processing, commu- nication, and other algorithmic elements within a WebApp.
In most cases, it would be fruitless to explore the collection of information architec- ture patterns when a problem in interaction design is encountered. You would ex- amine interaction patterns, because that is the design focus that is relevant to the work being performed.
12.6.2 Design Granularity
When a problem involves “big picture” issues, you should attempt to develop solutions (and use relevant patterns) that focus on the big picture. Conversely, when the focus is very narrow (e.g., uniquely selecting one item from a small set of five or fewer items), the solution (and the corresponding pattern) is targeted quite nar- rowly. In terms of the level of granularity, patterns can be described at the follow- ing levels:
• Architectural patterns. This level of abstraction will typically relate to patterns that define the overall structure of the WebApp, indicate the rela- tionships among different components or increments, and define the rules for specifying relationships among the elements (pages, packages, compo- nents, subsystems) of the architecture. • Design patterns. These address a specific element of the design such as an aggregation of components to solve some design problem, relationships among elements on a page, or the mechanisms for effecting component-to- component communication. An example might be the Broadsheet pattern for the layout of a WebApp home page. • Component patterns. This level of abstraction relates to individual small- scale elements of a WebApp. Examples include individual interaction elements (e.g., radio buttons), navigation items (e.g., how might you format links?) or functional elements (e.g., specific algorithms).
It is also possible to define the relevance of different patterns to different classes of applications or domains. For example, a collection of patterns (at different levels of design focus and granularity) might be particularly relevant to e-business.
www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 370
www.Vidyarthiplus.com 370 PART TWO MODELING
INFO Hypermedia Design Patterns Repositories
The IAWiki website (http://iawiki.net/ Patterns for Personal Websites WebsitePatterns), a collaborative www.rdrop.com/%7Ehalf/Creations/Writin discussion space for information architects, contains gs/Web.patterns/index.html many useful resources. Among them are links to a Improving Web Information Systems with Navigational number of useful hypermedia patterns catalogs and Patterns http://www8.org/w8-papers/ repositories. Hundreds of design patterns are 5b-hypertext- media/improving/ represented: improving.html An HTML 2.0 Pattern Language Hypermedia Design Patterns Repository www.anamorph.com/docs/patterns/ www.designpattern.lu.unisi.ch/ default.html InteractionPatterns by Tom Erickson Common Ground—A Pattern Language for HCI Design www.pliant.org/personal/Tom_Erickson/ www.mit.edu/~jtidwell/interaction_patterns InteractionPatterns.html .html Web Design Patterns by Martijn vanWelie Patterns for Personal Websites www.rdrop.com/ www.welie.com/patterns/ ~half/Creations/Writings/Web.patterns/ Web Patterns for UI Design index.html http://harbinger.sims.berkeley.edu/ Indexing Pattern Language www.cs.brown.edu/ ui_designpatterns/webpatterns2/ ~rms/InformationStructures/Indexing/ webpatterns/home.php Overview.html
12.7 SUMMARY
Design patterns provide a codified mechanism for describing problems and their solution in a way that allows the software engineering community to capture design knowledge for reuse. A pattern describes a problem, indicates the context enabling the user to understand the environment in which the problem resides, and lists a sys- tem of forces that indicate how the problem can be interpreted within its context and how the solution can be applied. In software engineering work, we identify and doc- ument generative patterns that describe an important and repeatable aspect of a sys- tem and then provide us with a way to build that aspect within a system of forces that is unique to a given context. Architectural patterns describe broad-based design problems that are solved using a structural approach. Data patterns describe recurring data-oriented prob- lems and the data modeling solutions that can be used to solve them. Component patterns (also referred to as design patterns) address problems associated with the development of subsystems and components, the manner in which they communi- cate with one another, and their placement within a larger architecture. Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end users. WebApp patterns address a problem set that is encountered when building WebApps and of- ten incorporates many of the other patterns categories just mentioned. A framework www.Vidyarthiplus.com pre75977_ch12.qxd 11/27/08 3:58 PM Page 371
www.Vidyarthiplus.com CHAPTER 12 PATTERN-BASED DESIGN 371
provides an infrastructure in which patterns may reside and idioms describe pro- gramming language–specific implementation detail for all or part of a specific algo- rithm or data structure. A standard form or template is used for pattern descriptions. A pattern language encompasses a collection of patterns, each described using a standardized template and interrelated to show how these patterns collaborate to solve problems across an application domain. Pattern-based design is used in conjunction with architectural, component-level, and user interface design methods. The design approach begins with an examina- tion of the requirements model to isolate problems, define context, and describe the system of forces. Next, pattern languages for the problem domain are searched to determine if patterns exist for the problems that have been isolated. Once appropri- ate patterns have been found, they are used as a design guide.
www.Vidyarthiplus.com SDC10 9/18/07 11:04 AM Page 225
www.Vidyarthiplus.com
Design context
Designing with patterns Having established just what a design pattern is, and examined examples of how they are structured and organized, the next obvious question is ‘how do we use design patterns to solve design problems?’. In this section we examine such guidance as is available, and consider one of the consequences of pattern use, which is how these are most effectively indexed.
1 How to use patterns Books that describe design patterns, such as Gamma et al. (1995) and Buschmann et al. (1996) very much function as catalogues of design patterns. In the early chapters which looked at the wider context of software design, we observed that catalogues are more common in other domains and uncommon for software design, where most of the literature addresses design processes. Unfortunately, much as a garden catalogue full of glorious colour photographs of healthy, thriving plants provides little real aid to the task of planning a new garden, beyond telling us which plants like shade and how tall the various varieties (may) grow, so it is with design patterns. Possession of the catalogue provides a source of ideas, it provides information that helps with plan- ning and with anticipating any possible consequences, but the design task of working
www.Vidyarthiplus.com .) Their basic advice is very GoF GoF so that a client object need so that a client object , which is not to deny the use- , and that by studying patterns, , and that by studying learned (1996) advocate a rather different strategy, (1996) advocate a rather different et al. patterns). www.Vidyarthiplus.com www.Vidyarthiplus.com design or , even if over longer periods than we commonly employ when thinking employ when than we commonly over longer periods , even if architectural The authors in Buschmann How then do we use catalogues of design patterns? Well, the catalogues of design patterns? Well, How then do we use selected category. ( be able to recognize where a pattern would provide a suitable solution; be able to recognize where a pattern the pattern within the particular solution. have an understanding of how to employ be over-used. acquire a ‘vocabulary’ of design patterns; programming to an interface, not an implementation programming to an a particular request, as long actual object that is used to service not be aware of the adhere to the interface specification; as its form and behaviour inheritance favouring object composition over class but rather to observe that it should not fulness of inheritance as a reuse mechanism, 4. Compare the problem description with the available set of patterns taken from the 1. Specify the problem (and, if possible, any subproblems involved). 2. Select the category of pattern that is appropriate to the design activity involved 3. Select the problem category appropriate to the problem. although the basic conditions for pattern use are the same as those specified above. although the basic conditions for pattern given problem in the same way that the patterns They argue in favour of classifying a identifying the set of potentially useful pat- themselves are classified, as a step towards scheme of classification is that it appears terns. (One thing in favour of their suggested than that adopted by the more suited to supporting such a process process can then be summarized as follows. n n forms a useful and important step towards While indexing and cataloguing of patterns to support the other two is rather more problem- the first of these goals, finding ways of pattern use may be helpful. atical, although provision of case studies From this, we can recognize that the minimum conditions for the successful use of pat- From this, we can recognize that the terns will require that the designer should: n n n will determine the exact form that it takes.) will determine the that patterns need to be much along the lines works, and also a familiar- both insight into why the pattern the designer will acquire situations where it can be used enable he or she to recognize those ity with it that will principles of: advise the designer to follow the two to effect. They also out how to produce a particular plan of action is still a creative activity. (Actually, (Actually, activity. still a creative action is plan of particular a to produce out how exhibit and do evolve gardens one, since not a bad is gardening with the analogy behaviour take some plants of the garden, and shade new sections Trees grow about software. etc. Like the software adjacent sections, but then take over established, time to become future state, while to envisage some requires them the gardener’s planning designer, that of the materials and the quality both the conditions control of having inadequate
Design patterns 226 SDC10 9/18/07 11:04 AM Page 226 AM Page 11:04 9/18/07 SDC10 Patterns in the wider design context 227 GoF all of patterns during the design patterns in any consistent way; and www.Vidyarthiplus.com www.Vidyarthiplus.com would seem to provide better support for the design process would seem to provide better support new patterns has acted to expose two weaknesses in the ‘pattern concept’, terns in the wider design context Unfortunately, as already demonstrated, there is (at the time of writing) no widely Unfortunately, as already demonstrated, Since their categorization structure includes architectural styles as well as design styles includes architectural categorization structure Since their going to be a suitable pat- not assume that there is always Of course, we should advocated by the the more ‘implementational’ guidelines Finally, of course, process. the lack of any well-established practices for using the difficulty of indexing Indexing and classifying patterns Pat n namely: n itself. and the attractive nature of the concept The enthusiasm of the pattern community, areas of design), has led to considerable inter- (which appeals to experience in related for est in seeking new design patterns. Indeed, it can be argued that the enthusiasm writing are still applicable when using this strategy. are still applicable to address this is to index patterns in some way, these becomes strained. The only way one outlined above can be adopted. so that a design process similar to the There are also no empirical studies into the use agreed scheme for indexing patterns. establishing the most effective ways of index- of design patterns that might assist with than ease of cataloguing). In the absence of such ing patterns for ease of use (rather the two schemes examined in this chapter, the knowledge, we can only say that of one of Buschmann et al. 2 it a self-limiting aspect that is clearly difficult to The concept of patterns carries within as more patterns are identified and added to the overcome. This is the problem that, ability of the individual designer to learn corpus of pattern knowledge, so the 5. trade-offs). the design (assess liabilities benefits and Compare 6. problem. that most fits the the pattern variant Select of the previous an iterative recycling which is essentially a seventh step too, (There is patterns.) to any existing no match be found steps should that could be employed from the above process is potentially one patterns and idioms, in Figure 10.7. We might detailed program design. This is illustrated top-level down to is perhaps unexpected, given use of a top-down strategy, which also note that it implies a compositional concept. that patterns are essentially all problems into a ‘pattern a process. Indeed, trying to force tern when using such what is intended. So step 5 in to produce exactly the opposite of framework’ is likely may well need to recognize is an important one, where the designer the above process pattern for a given problem. that there is no ‘ready-made’ SDC10 9/18/07 11:04 AM Page 227 AM Page 11:04 9/18/07 SDC10 5 3 4 2 6 1 variant Specify pattern Pattern problem liabilities category Problem category of pattern Choice of document Assessment with problem classification Problem and Select pattern Select problem Select category Compare pattern pattern categories Compare benefits/ www.Vidyarthiplus.com www.Vidyarthiplus.com Patterns Patterns repository knowledge Requirements A process model for designing with patterns. Figure 10.7
Design patterns 228 SDC10 9/18/07 11:04 AM Page 228 AM Page 11:04 9/18/07 SDC10 Patterns in the wider design context 229 as a means of transferring knowledge about which comes from using a pattern seems to more which comes from design pattern www.Vidyarthiplus.com www.Vidyarthiplus.com , 2001) is overall one that is supportive of the idea that the is supportive of the overall one that , 2001) is flexibility lead to good designs. The act of designing software requires a lead to good designs. The act of designing et al. always One last question that we need to consider is how widely the pattern concept can One last question that we need to consider In that sense too, design patterns are no more a ‘silver bullet’ than are design design patterns are no more a ‘silver In that sense too, So, patterns are clearly a useful addition to the designer’s vocabulary and skill-set. a useful addition to the designer’s So, patterns are clearly Although there are many books about patterns (including books that cover quite (including books about patterns there are many books Although ware engineering practices can be said to have been subjected to any effective empirical evaluation. Summary that the pattern concept is applicable across different architectural styles, but that it is that the pattern concept is applicable will develop where there is a community that is only likely that pattern repositories by writing patterns. sufficiently motivated to share ideas 1999)). However, there is no particular argument that suggests that this is in some way 1999)). However, there is no particular this is the one where the need has been greatest. the ‘only’ architectural style; simply repositories available on the web tends to reveal a Indeed, while looking at the pattern design, there is a growing set of design preponderance of patterns for object-oriented styles or, at least, with forms of implementation patterns that are used within other objects. From this, we can perhaps conclude that are not particularly centred around we can design entirely by using patterns as it would be to expect that the use of design we can design entirely by using patterns methods will and the pattern concept is clearly one of these. wide vocabulary of ideas and techniques, styles. Much of the basic development has be applied across different architectural style (which, equally, is one that has proved been centred upon the object-oriented procedural forms for design methods (Budgen, particularly intractable for the use of Indeed, it can be argued that even if patterns are not widely employed in practice (pos- that even if patterns are not widely Indeed, it can be argued paragraph), simply studying trade-offs referred to in the previous sibly because of the thinking about design, and will the development of clearer them will itself encourage benefits of experience. convey some of the practice. It would be as naive to expect that methods, or any other systematic design than offset the greater complexity that tends to result from using a pattern rather than complexity that tends to result from than offset the greater flexibility and the complexity Indeed, this trade-off between an optimized structure. be explored more fully. is one that clearly needs to that arises from generality modified. Given the frequency with which the need for modification arises in software frequency with which the need for modified. Given the added development, the use of patterns can often result in designs that are more easily maintained and maintained that are more easily result in designs can often use of patterns *is specific to design patterns and their use. Few widely-used soft- In fairness, this is by no means a problem that Our discussion of the use of the with two design experiences has examined both the concept and also its application, along applicability examples as (rather outline) illustration. We have also briefly considered the wider style. of the pattern idea, beyond its use simply within the object-oriented architectural Neither of these weaknesses invalidates the concept, but they do raise the question of the question do raise but they concept, the invalidates weaknesses of these Neither patterns. stock of an ever-increasing is to have useful it how empirical evalu- in the way of systematic been little to date areas), there has specialized study that has been The one such the pattern concept.* effectiveness of ation of the (Prechelt conducted SDC10 9/18/07 11:04 AM Page 229 AM Page 11:04 9/18/07 SDC10 patterns to using www.Vidyarthiplus.com www.Vidyarthiplus.com patterns, it is sometimes hard to avoid the feeling that a ‘write-only’ mentality prevails that a ‘write-only’ mentality to avoid the feeling is sometimes hard patterns, it patterns is perhaps understandably a more interesting task than developing better ways task than developing a more interesting perhaps understandably patterns is new using rather too much! To really become useful, there still seems to be a need to explore and evaluate seems to be a need useful, there still much! To really become rather too concept is undoubt- So, while the pattern and classify patterns. ways to index the most effective for repertoire, the process software designer’s addition to the edly a valuable The patterns community is an enthusiastic, if often rather evangelical, one. That said, while writ- said, while one. That evangelical, often rather if an enthusiastic, is community The patterns ing of solve problems may benefit from further refinement and development. solve problems may
Design patterns 230 SDC10 9/18/07 11:04 AM Page 230 AM Page 11:04 9/18/07 SDC10 www.Vidyarthiplus.com
Reusable solutions
Design patterns were derived from ideas put forward by Christopher Alexander (Alexander et al., 1977), who suggested that there were certain common patterns of building design that were inherently pleasing and effective. The pattern is a description of the problem and the essence of its solution, so that the solution may be reused in
www.Vidyarthiplus.com www.Vidyarthiplus.com
Pattern name: Observer Description: Separates the display of the state of an object from the object itself and allows alternative displays to be provided. When the object state changes, all displays are automatically notified and updated to reflect the change. Problem description: In many situations, you have to provide multiple displays of state information, such as a graphical display and a tabular display. Not all of these may be known when the information is specified. All alternative presentations should support interaction and, when the state is changed, all displays must be updated. This pattern may be used in all situations where more than one display format for state information is required and where it is not necessary for the object that maintains the state information to know about the specific display formats used. Solution description: This involves two abstract objects, Subject and Observer, and two concrete objects, ConcreteSubject and ConcreteObject, which inherit the attributes of the related abstract objects. The abstract objects include general operations that are applicable in all situations. The state to be displayed is maintained in ConcreteSubject, which inherits operations from Subject allowing it to add and remove Observers (each observer corresponds to a display) and to issue a notification when the state has changed. The ConcreteObserver maintains a copy of the state of ConcreteSubject and implements the Update() interface of Observer that allows these copies to be kept in step. The ConcreteObserver automatically displays the state and reflects changes whenever the state is updated. The UML model of the pattern is shown in Figure 7.12. Consequences: The subject only knows the abstract Observer and does not know details of the concrete class. Therefore there is minimal coupling between these objects. Because of this lack of knowledge, optimizations that enhance display performance are impractical. Changes to the subject may cause a set of linked updates to observers to be generated, some of which may not be necessary.
different settings. The pattern is not a detailed specification. Rather, you can think of it Figure 7.10 The Observer pattern as a description of accumulated wisdom and experience, a well-tried solution to a com- mon problem. A quote from the Hillside Group web site (http://hillside.net), which is dedicated to maintaining information about patterns, encapsulates their role in reuse:
Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience.
Patterns have made a huge impact on object-oriented software design. As well as being tested solutions to common problems, they have become a vocabulary for talk- ing about a design. You can therefore explain your design by describing the patterns that you have used. This is particularly true for the best-known design patterns that were originally described by the ‘Gang of Four’ in their patterns book, (Gamma et al., 1995). Other particularly important pattern descriptions are those published in a series of books by authors from Siemens, a large European technology company (Buschmann et al., 1996; Buschmann et al., 2007a; Buschmann et al., 2007b; Kircher and Jain, 2004; Schmidt et al., 2000). Design patterns are usually associated with object-oriented design. Published patterns often rely on object characteristics such as inheritance and polymorphism to provide generality. However, the general principle of encapsulating experience in a
www.Vidyarthiplus.com www.Vidyarthiplus.com
50 D A C 25 ABCD B 0
Subject A: 40 Observer 1 B: 25 Observer 2 Figure 7.11 Multiple C: 15 displays D: 20
pattern is one that is equally applicable to any kind of software design. So, you could have configuration patterns for COTS systems. Patterns are a way of reusing the knowledge and experience of other designers. The four essential elements of design patterns were defined by the ‘Gang of Four’ in their patterns book:
1. A name that is a meaningful reference to the pattern. 2. A description of the problem area that explains when the pattern may be applied. 3. A solution description of the parts of the design solution, their relationships, and their responsibilities. This is not a concrete design description. It is a template for a design solution that can be instantiated in different ways. This is often expressed graphically and shows the relationships between the objects and object classes in the solution. 4. A statement of the consequences—the results and trade-offs—of applying the pattern. This can help designers understand whether or not a pattern can be used in a particular situation.
Gamma and his co-authors break down the problem description into motivation (a description of why the pattern is useful) and applicability (a description of situations in which the pattern may be used). Under the description of the solution, they describe the pattern structure, participants, collaborations, and implementation. To illustrate pattern description, I use the Observer pattern, taken from the book by Gamma et al. (Gamma et al., 1995). This is shown in Figure 7.10. In my descrip- tion, I use the four essential description elements and also include a brief statement of what the pattern can do. This pattern can be used in situations where different presentations of an object’s state are required. It separates the object that must be displayed from the different forms of presentation. This is illustrated in Figure 7.11, which shows two graphical presentations of the same data set. Graphical representations are normally used to illustrate the object classes in patterns and their relationships. These supplement the pattern description and add
www.Vidyarthiplus.com www.Vidyarthiplus.com
Subject Observer
Attach (Observer) Update ( ) Detach (Observer) Notify ( ) for All o in observers o -> Update ( )
ConcreteSubject ConcreteObserver
Update ( ) observerState = GetState ( ) return subjectState subject -> GetState ( ) subjectState observerState
detail to the solution description. Figure 7.12 is the representation in UML of the Figure 7.12 A UML model of the Observer Observer pattern. pattern To use patterns in your design, you need to recognize that any design problem you are facing may have an associated pattern that can be applied. Examples of such problems, documented in the ‘Gang of Four’s original patterns book, include:
1. Tell several objects that the state of some other object has changed (Observer pattern). 2. Tidy up the interfaces to a number of related objects that have often been devel- oped incrementally (Façade pattern).
3. Provide a standard way of accessing the elements in a collection, irrespective of how that collection is implemented (Iterator pattern).
4. Allow for the possibility of extending the functionality of an existing class at run-time (Decorator pattern).
Patterns support high-level, concept reuse. When you try to reuse executable components you are inevitably constrained by detailed design decisions that have been made by the implementers of these components. These range from the particular algorithms that have been used to implement the components to the objects and types in the component interfaces. When these design decisions con- flict with your particular requirements, reusing the component is either impossible or introduces inefficiencies into your system. Using patterns means that you reuse the ideas but can adapt the implementation to suit the system that you are developing. When you start designing a system, it can be difficult to know, in advance, if you will need a particular pattern. Therefore, using patterns in a design process often involves developing a design, experiencing a problem, and then recognizing that a pattern can be used. This is certainly possible if you focus on the 23 general-purpose
www.Vidyarthiplus.com www.Vidyarthiplus.com
patterns documented in the original patterns book. However, if your problem is a dif- ferent one, you may find it difficult to find an appropriate pattern amongst the hun- dreds of different patterns that have been proposed. Patterns are a great idea but you need experience of software design to use them effectively. You have to recognize situations where a pattern can be applied. Inexperienced programmers, even if they have read the pattern books, will always find it hard to decide whether they can reuse a pattern or need to develop a special- purpose solution.
Reuse From the 1960s to the 1990s, most new software was developed from scratch, by writing all code in a high-level programming language. The only significant reuse or
www.Vidyarthiplus.com www.Vidyarthiplus.com
software was the reuse of functions and objects in programming language libraries. However, costs and schedule pressure meant that this approach became increasingly unviable, especially for commercial and Internet-based systems. Consequently, an approach to development based around the reuse of existing software emerged and is now generally used for business systems, scientific software, and, increasingly, in embedded systems engineering. Software reuse is possible at a number of different levels:
1. The abstraction level At this level, you don’t reuse software directly but rather use knowledge of successful abstractions in the design of your software. Design patterns and architectural patterns (covered in Chapter 6) are ways of represent- ing abstract knowledge for reuse. 2. The object level At this level, you directly reuse objects from a library rather than writing the code yourself. To implement this type of reuse, you have to find appropriate libraries and discover if the objects and methods offer the function- ality that you need. For example, if you need to process mail messages in a Java program, you may use objects and methods from a JavaMail library. 3. The component level Components are collections of objects and object classes that operate together to provide related functions and services. You often have to adapt and extend the component by adding some code of your own. An example of component-level reuse is where you build your user interface using a frame- work. This is a set of general object classes that implement event handling, dis- play management, etc. You add connections to the data to be displayed and write code to define specific display details such as screen layout and colors. 4. The system level At this level, you reuse entire application systems. This usually involves some kind of configuration of these systems. This may be done by adding and modifying code (if you are reusing a software product line) or by using the system’s own configuration interface. Most commercial systems are now built in this way where generic COTS (commercial off-the-shelf) systems are adapted and reused. Sometimes this approach may involve reusing several different systems and integrating these to create a new system.
By reusing existing software, you can develop new systems more quickly, with fewer development risks and also lower costs. As the reused software has been tested in other applications, it should be more reliable than new software. However, there are costs associated with reuse:
1. The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs. You may have to test the software to make sure that it will work in your environment, especially if this is different from its development environment. 2. Where applicable, the costs of buying the reusable software. For large off-the- shelf systems, these costs can be very high.
www.Vidyarthiplus.com www.Vidyarthiplus.com
3. The costs of adapting and configuring the reusable software components or sys- tems to reflect the requirements of the system that you are developing. 4. The costs of integrating reusable software elements with each other (if you are using software from different sources) and with the new code that you have developed. Integrating reusable software from different providers can be diffi- cult and expensive because the providers may make conflicting assumptions about how their respective software will be reused.
How to reuse existing knowledge and software should be the first thing you should think about when starting a software development project. You should consider the possibilities of reuse before designing the software in detail, as you may wish to adapt your design to reuse existing software assets. As I discussed in Chapter 2, in a reuse- oriented development process, you search for reusable elements then modify your requirements and design to make best use of these. For a large number of application systems, software engineering really means software reuse. I therefore devote several chapters in the software technologies sec- tion of the book to this topic (Chapters 16, 17, and 19).
www.Vidyarthiplus.com www.Vidyarthiplus.com
Documenting reusable solutions
Assume you discovered a new design pattern. Or your friend wants to explain to you this cool pattern she found in a pattern repository. How do we describe patterns? There is no single, standard format for documenting design patterns. Rather, a variety of different formats have been used by different pattern authors. However, according to Martin Fowler certain pattern forms have become more well-known than others, and consequently become common starting points for new pattern writing efforts. One example of a commonly used documentation format is the one used by the book Design Patterns. It contains the following sections:
• Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern. • Intent: A description of the goal behind the pattern and the reason for using it. • Also Known As: Other names for the pattern. • Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used. • Applicability: Situations in which this pattern is usable; the context for the pattern. • Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose. • Participants: A listing of the classes and objects used in the pattern and their roles in the design. • Collaboration: A description of how classes and objects used in the pattern interact with each other. • Consequences: A description of the results, side effects, and trade offs caused by using the pattern. • Implementation: A description of an implementation of the pattern; the solution part of the pattern. • Sample Code: An illustration of how the pattern can be used in a programming language. • Known Uses: Examples of real usages of the pattern. • Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.
Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships. Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Standard patterns from GOF book
Gang of Four Design Patterns
The Gang of Four are the four authors of the book, "Design Patterns: Elements of Reusable Object-Oriented Software". In this article their twenty-three design patterns are described with links to UML diagrams, source code and real-world examples for each.
What are Design Patterns?
Design patterns provide solutions to common software design problems. In the case of object-oriented programming, design patterns are generally aimed at solving the problems of object generation and interaction, rather than the larger scale problems of overall software architecture. They give generalised solutions in the form of templates that may be applied to real-world problems.
Design patterns are a powerful tool for software developers. However, they should not be seen as prescriptive specifications for software. It is more important to understand the concepts that design patterns describe, rather than memorising their exact classes, methods and properties. It is also important to apply patterns appropriately. Using the incorrect pattern for a situation or applying a design pattern to a trivial solution can overcomplicate your code and lead to maintainability issues.
Who are the Gang of Four?
The Gang of Four are the authors of the book, "Design Patterns: Elements of Reusable Object-Oriented Software". This important book describes various development techniques and pitfalls in addition to providing twenty-three object-oriented programming design patterns. The four authors were Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
Gang of Four Design Patterns
This section gives a high-level description of the twenty-three design patterns described by the Gang of Four. Each pattern description includes a link to a more detailed article describing the design pattern and including a UML diagram, template source code and a real-world example programmed using C#.
Creational Patterns
The first type of design pattern is the creational pattern. Creational patterns provide ways to instantiate single objects or groups of related objects. There are five such patterns:
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Abstract Factory. The abstract factory pattern is used to provide a client with a set of related or dependant objects. The "family" of objects created by the factory are determined at run-time. • Builder. The builder pattern is used to create complex objects with constituent parts that must be created in the same order or using a specific algorithm. An external class controls the construction algorithm. • Factory Method. The factory pattern is used to replace class constructors, abstracting the process of object generation so that the type of the object instantiated can be determined at run-time. • Prototype. The prototype pattern is used to instantiate a new object by copying all of the properties of an existing object, creating an independent clone. This practise is particularly useful when the construction of a new object is inefficient. • Singleton. The singleton pattern ensures that only one object of a particular class is ever created. All further references to objects of the singleton class refer to the same underlying instance.
Structural Patterns
The second type of design pattern is the structural pattern. Structural patterns provide a manner to define relationships between classes or objects.
• Adapter. The adapter pattern is used to provide a link between two otherwise incompatible types by wrapping the "adaptee" with a class that supports the interface required by the client. • Bridge. The bridge pattern is used to separate the abstract elements of a class from the implementation details, providing the means to replace the implementation details without modifying the abstraction. • Composite. The composite pattern is used to create hierarchical, recursive tree structures of related objects where any element of the structure may be accessed and utilised in a standard manner. • Decorator. The decorator pattern is used to extend or alter the functionality of objects at run-time by wrapping them in an object of a decorator class. This provides a flexible alternative to using inheritance to modify behaviour. • Facade. The facade pattern is used to define a simplified interface to a more complex subsystem. • Flyweight. The flyweight pattern is used to reduce the memory and resource usage for complex models containing many hundreds, thousands or hundreds of thousands of similar objects. • Proxy. The proxy pattern is used to provide a surrogate or placeholder object, which references an underlying object. The proxy provides the same public interface as the underlying subject class, adding a level of indirection by accepting requests from a client object and passing these to the real subject object as necessary.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Behavioural Patterns
The final type of design pattern is the behavioural pattern. Behavioural patterns define manners of communication between classes and objects.
• Chain of Responsibility. The chain of responsibility pattern is used to process varied requests, each of which may be dealt with by a different handler. • Command. The command pattern is used to express a request, including the call to be made and all of its required parameters, in a command object. The command may then be executed immediately or held for later use. • Interpreter. The interpreter pattern is used to define the grammar for instructions that form part of a language or notation, whilst allowing the grammar to be easily extended. • Iterator. The iterator pattern is used to provide a standard interface for traversing a collection of items in an aggregate object without the need to understand its underlying structure. • Mediator. The mediator pattern is used to reduce coupling between classes that communicate with each other. Instead of classes communicating directly, and thus requiring knowledge of their implementation, the classes send messages via a mediator object. • Memento. The memento pattern is used to capture the current state of an object and store it in such a manner that it can be restored at a later time without breaking the rules of encapsulation. • Observer. The observer pattern is used to allow an object to publish changes to its state. Other objects subscribe to be immediately notified of any changes. • State. The state pattern is used to alter the behaviour of an object as its internal state changes. The pattern allows the class for an object to apparently change at run-time. • Strategy. The strategy pattern is used to create an interchangeable family of algorithms from which the required process is chosen at run-time. • Template Method. The template method pattern is used to define the basic steps of an algorithm and allow the implementation of the individual steps to be changed. • Visitor. The visitor pattern is used to separate a relatively complex set of structured data classes from the functionality that may be performed upon the data that they hold.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Creational Patterns
“Creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.”2 All the creational patterns define the best possible way in which an object can be created considering reuse and changeability. These describes the best way to handle instantiation. Hard coding the actual instantiation is a pitfall and should be avoided if reuse and changeability are desired. In such scenarios, we can make use of patterns to give this a more general and flexible approach. Factory Pattern
Definition The Factory pattern provides a way to use an instance as a object factory. The factory can return an instance of one of several possible classes (in a subclass hierarchy), depending on the data provided to it. Where to use •When a class can't anticipate which kind of class of object it must create. •You want to localize the knowledge of which class gets created. •When you have classes that is derived from the same subclasses, or they may in fact be unrelated classes that just share the same interface. Either way, the methods in these class instances are the same and can be used interchangeably. •When you want to insulate the client from the actual type that is being instantiated. Benefits •The client does not need to know every subclass of objects it must create. It only need one reference to the abstract class/interface and the factory object. •The factory encapsulate the creation of objects. This can be useful if the creation process is very complex. Drawbacks/consequences •There is no way to change an implementing class without a recompile.
Structure
www.Vidyarthiplus.com www.Vidyarthiplus.com
Small example This example shows how two different concrete Products are created using the ProductFactory. ProductA uses the superclass writeName method. ProductB implements writeName that reverses the name. public abstract class Product { public void writeName(String name) { System.out.println("My name is "+name); } } public class ProductA extends Product { } public class ProductB extends Product { public void writeName(String name) { StringBuilder tempName = new StringBuilder().append(name); System.out.println("My reversed name is" + tempName.reverse()); } } public class ProductFactory { Product createProduct(String type) { if(type.equals("B")) return new ProductB(); else return new ProductA(); } } Abstract Factory Pattern Definition The Abstract Factory pattern is a creational pattern which is related to the
www.Vidyarthiplus.com www.Vidyarthiplus.com
Factory Method pattern, but it adds another level of abstraction. What this means is that the pattern encapsulates a group of individual concrete factory classes (as opposed to concrete factory methods which are derived in subclasses) which share common interfaces. The client software uses the Abstract Factory which provides an interface for creating families of related or dependent objects without specifying their concrete classes. This pattern separates the implementation details of a set of objects from its general usage. Where to use The pattern can be used where we need to create sets of objects that share a common theme and where the client only needs to know how to handle the abstract equivalence of these objects, i.e. the implementation is not important for the client. The Abstract Factory is often employed when there is a need to use different sets of objects and where the objects could be added or changed some time during the lifetime of an application. Benefits Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them, even at runtime. Drawbacks/consequences As with similar design patterns, one of the main drawbacks is the possibility of unnecessary complexity and extra work in the initial writing of the code.
Structure Below you see the class diagram of the following small example.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Small example For instance, we could have an abstract class InsuranceCreator that provides interfaces to create a number of products (e.g. createCarInsurance(), createHomeInsurance(), createPersonalInsurance()). Any number of derived concrete classes of the InsuranceCreator class can be created, for example CheapInsuranceCreator, ExpensiveInsuranceCreator or ScamInsuranceCreator, each with a different implementation of createCarInsurance(), createHomeInsurance() and createPersonalInsurance() that would create a corresponding object like CheapCarInsurance, ExpensiveHomeInsurance or ScamPersonalInsurance. Each of these products is derived from a simple abstract class like CarInsurance, HomeInsurance or PersonalInsurance of which the client is aware.
The client code would get an appropriate instantiation of the InsuranceCreator and call its factory methods. Each of the resulting objects would be created from the same InsuranceCreator implementation and would share a common theme (they would all be cheap, expensive or scam objects). The client would need to know how to handle only the abstract CarInsurance, HomeInsurance or PersonalInsurance class, not the specific version that it got from the concrete factory. Builder Pattern Definition The Builder pattern can be used to ease the construction of a complex object from simple objects. The Builder pattern also separates the construction of a complex object from its representation so that the same construction process can be used to create another composition of objects. Related patterns include Abstract Factory and Composite. Where to use •When the algorithm for creating a complex object should be independent of the parts that make up the object and how they are assembled. •When the construction process must allow different representations for the object that is constructed. •When you want to insulate clients from the knowledge of the actual creation process and/or resulting product. Benefits •The built object is shielded from the details of its construction. •Code for construction is isolated from code for representation and both are easy to replace without affecting the other. •Gives you control over the construction process. •Gives you the possibility to reuse and/or change the process and/or product independently. Drawbacks/consequences Need flexibility in creating various complex objects. Need to create complex, aggregate objects
www.Vidyarthiplus.com www.Vidyarthiplus.com
Structure In the class diagram above: •The Builder specifies an abstract interface for creating parts of a Product. •The ConcreteBuilder constructs and assembles parts of the product by implementing the Builder interface. •The Director constructs an object using the Builder interface. •The Product represents the object under construction. Small example For instance to build a house, we will take several steps: 1. Build floor 2. Build walls 3. Build roof Let's use an abstract class HouseBuilder to define these three steps. Any subclass of HouseBuilder will follow these three steps to build house (that is to say to implement these three methods in the subclass). Then we use a HouseDirector class to force the order of these three steps (that is to say that we have to build walls after finished building floor and before building roof). The HouseClient orders the building of two houses, one wood house and one brick house. Even though the houses are of different types (wood and brick) they are built the same way, The construction process allows different representations for the object that is constructed.
public abstract class HouseBuilder { protected House house; protected Floor floor; protected Walls walls; protected Roof roof;
www.Vidyarthiplus.com www.Vidyarthiplus.com
public abstract House createHouse(); public abstract Floor createFloor(); public abstract Walls createWalls(); public abstract Roof createRoof(); } public class WoodBuilder extends HouseBuilder { public Floor createFloor() { floor = new WoodFloor(); return floor; } public House createHouse() { house = new WoodHouse(); return house; } public Roof createRoof() { roof = new WoodRoof(); return roof; } public Walls createWalls() { walls = new WoodWalls(); return walls; } } public class BrickBuilder extends HouseBuilder { //similar to WoodBuilder } public class HouseDirector { public House construcHouse(HouseBuilder builder) { House house = builder.createHouse(); System.out.println(house.getRepresentation()); house.setFloor(builder.createFloor()); System.out.println(house.getFloor().getRepresentation()); house.setWalls(builder.createWalls()); System.out.println(house.getWalls().getRepresentation()); house.setRoof(builder.createRoof()); System.out.println(house.getRoof().getRepresentation()); return house; } } Prototype Pattern Definition The Prototype pattern is basically the creation of new instances through cloning existing instances. By creating a prototype, new objects are created by copying this prototype.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Where to use •When a system needs to be independent of how its objects are created, composed, and represented. •When adding and removing objects at runtime. •When specifying new objects by changing an existing objects structure. •When configuring an application with classes dynamically. •When keeping trying to keep the number of classes in a system to a minimum. •When state population is an expensive or exclusive process. Benefits •Speeds up instantiation of large, dynamically loaded classes. •Reduced subclassing. Drawbacks/consequences Each subclass of Prototype must implement the Clone operation. Could be difficult with existing classes with internal objects with circular references or which does not support copying.
Structure
In the class-diagram above: •Prototype declares an interface for cloning itself. •ConcretePrototype implements an operation for cloning itself. •Client creates a new object by asking a prototype to clone itself. You could use a PrototypeManager to keep track on the different types of prototypes. The PrototypeManager maintains a list of clone types and their
www.Vidyarthiplus.com www.Vidyarthiplus.com
keys. The client, instead of writing code that invokes the "new" operator on a hard-wired class name, calls the clone() method on the prototype.
Usage example If you are designing a system for performing bank account transactions, then you would want to make a copy of the Object which holds your account information, perform transactions on it, and then replace the original Object with the modified one. In such cases, you would want to use clone() instead of new. Singleton Pattern Definition The Singleton pattern provides the possibility to control the number of instances (mostly one) that are allowed to be made. We also receive a global point of access to it (them). Where to use When only one instance or a specific number of instances of a class are allowed. Facade objects are often Singletons because only one Facade object is required. Benefits •Controlled access to unique instance. •Reduced name space. •Allows refinement of operations and representations. Drawbacks/consequences Singleton pattern is also considered an anti-pattern by some people, who feel that it is overused, introducing unnecessary limitations in situations where a sole instance of a class is not actually required. Structure
Small example package com.logica.singleton; public class FileLogger { private static FileLogger logger; // Prevent clients from using the constructor private FileLogger() { } //Control the accessible (allowed) instances public static FileLogger getFileLogger() { if (logger == null) { logger = new FileLogger(); }
www.Vidyarthiplus.com www.Vidyarthiplus.com
return logger; } public synchronized void log(String msg) { // Write to log file... } }
Structural Patterns
“In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities.”3 Structural Patterns describe how objects and classes can be combined to form structures. We distinguish between object patterns and class patterns. The difference is that class patterns describe relationships and structures with the help of inheritance. Object patterns, on other hand, describe how objects can be associated and aggregated to form larger, more complex structures.
Adapter Pattern Also known as Wrapper. Definition The Adapter pattern is used to translate the interface of one class into another interface. This means that we can make classes work together that couldn't otherwise because of incompatible interfaces. A class adapter uses multiple inheritance (by extending one class and/or implementing one or more classes) to adapt one interface to another. An object adapter relies on object aggregation. Where to use •When you want to use an existing class, and its interface does not match the one you need. •When you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces. •When you want to increase transparency of classes. •When you want to make a pluggable kit. Benefits •Highly class reusable. •Introduces only one object Drawbacks/consequences When using Java, Target must be an interface. Structure
www.Vidyarthiplus.com www.Vidyarthiplus.com
In the class-diagram above: •A Client class expects a certain interface (called the Target interface) •An available interface doesn't match the Target interface •An Adapter class bridges the gap between the Target interface and the available interface •The available interface is called the Adaptee Small example Imagine you need to develop a simple file manager to handle text documents. There is an existing resource that already handles this, but by some reason you are forced to a specific interface for your file manager. By using a class adapter we can use the forced interface and still reuse the existing functionality. In the class diagram below the interface FileManager is the target (desired interface). FileManagerUtil is the existing utility class that we would like to adapt to FileManager interface. We do the actual adaptation in the class FileManagerImpl, this class uses the desired interface and the existing functionality through inheritance, i.e. a class adapter.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Usage example The Java API uses the Adapter pattern, WindowAdapter, ComponentAdapter, ContainerAdapter, FocusAdapter, KeyAdapter, MouseAdapter, MouseMotionAdapter.
Bridge Pattern Definition Decouple an abstraction or interface from its implementation so that the two can vary independently. Bridge makes a clear-cut between abstraction and implementation. Where to use •When you want to separate the abstract structure and its concrete implementation. •When you want to share an implementation among multiple objects, •When you want to reuse existing resources in an 'easy to extend' fashion. •When you want to hide implementation details from clients. Changes in implementation should have no impact on clients. Benefits Implementation can be selected or switched at run-time. The abstraction and implementation can be independently extended or composed. Drawbacks/consequences Double indirection - In the example, methods are implemented by subclasses of DrawingAPI class. Shape class must delegate the message to a DrawingAPI subclass which implements the appropriate method. This will have a slight impact on performance. Structure
www.Vidyarthiplus.com www.Vidyarthiplus.com
In the class-diagram above: •Abstraction defines the abstract interface and maintains the Implementor reference. •Refined Abstraction extends the interface defined by Abstraction. •Implementor defines the interface for implementation classes. •ConcreteImplementor implements the Implementor interface.
Usage example Bridge pattern can be found in the AWT package. The AWT separates the general abstraction of GUI components from concrete native implementations of GUI components. Composite Pattern Definition The Composite pattern helps you to create tree structures of objects without the need to force clients to differentiate between branches and leaves regarding usage. The Composite pattern lets clients treat individual objects and compositions of objects uniformly. Where to use •When you want to represent a part-whole relationship in a tree structure. •When you want clients to be able to ignore the differences between compositions of objects and individual objects. •When the structure can have any level of complexity and is dynamic. Benefits •Define class hierarchies consisting of primitive objects and composite objects. •Makes it easier to add new kind of components. Drawbacks/consequences
www.Vidyarthiplus.com www.Vidyarthiplus.com
The Composite pattern makes it easy for you to add new kinds of components to your collection as long as they support a similar programming interface. On the other hand, this has the disadvantage of making your system overly general. You might find it harder to restrict certain classes where this would normally be desirable. Structure
In the class-diagram above, Component: •is the abstraction for all components, including composite ones, •declares the interface for objects in the composition, •implements default behavior for the interface common to all classes, as appropriate, •declares an interface for accessing and managing its child components, and •(optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate. In the class-diagram above, Leaf: •represents leaf objects in the composition, and •implements all Component methods. In the class-diagram above, Composite: •represents a composite Component (component having children), •implements methods to manipulate children, and •implements all Component methods, generally by delegating them to its children. Decorator Pattern Definition The Decorator pattern lets you attach additional responsibilities and modify an instance functionality dynamically. Decorators provide a flexible alternative to subclassing for extending functionality, using composition instead of inheritance. Where to use •When you want to add responsibilities to individual objects dynamically and transparently, without affecting the original object or other objects.
www.Vidyarthiplus.com www.Vidyarthiplus.com
•When you want to add responsibilities to the object that you might want to change in the future. •When extension by static subclassing is impractical. Benefits •More flexibility than static inheritance. •Avoids feature-laden classes high up in the hierarchy. •Simplifies coding because you write a series of classes each targeted at a specific part of the functionality rather than •coding all behavior into the object. •Enhances the object's extensibility because you make changes by coding new classes. Drawbacks/consequences One thing to keep in mind when implementing the Decorator pattern is that you need to keep the component interface simple. You want to avoid making the component interface overly complex, because a complex interface will make it that much harder to get each decorator right. Another potential drawback of the Decorator pattern is the performance overhead associated with a long chain of decorators. Structure
Facade Pattern Definition This design pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use. A facade is an object that provides a simplified interface to a larger body of code, such as a class library.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Where to use The Facade can be used to make a software library easier to use and understand, since the Facade has convenient methods for common tasks. For the same reason, it can make code that uses the library more readable. The pattern can also be used to reduce dependencies of outside code on the inner workings of a library, since most code uses the Facade it allows more flexibility when developing the system. A final usage scenario is where we can wrap several poorly-designed APIs with a single well-designed API. Benefits The main benefit with the Facade pattern is that we can combine very complex method calls and code blocks into a single method that performs a complex and recurring task. Besides making code easier to use and understand, it reduces code dependencies between libraries or packages, making programmers more apt to consideration before writing new code that exposes the inner workings of a library or a package. Also, since the Facade makes a weak coupling between the client code and other packages or libraries it allows us vary the internal components since the client does not call them directly. Drawbacks/consequences One drawback is that we have much less control of what goes on beyond the surface. Also, if some classes require small variations to the implementation of Facade methods, we might end up with a mess. Structure The class diagram of the small example described in the next section is shown below to illustrate the structure of the Facade design pattern. Small example
Consider the graphics above, where the Client classes makes calls to the
www.Vidyarthiplus.com www.Vidyarthiplus.com
BankAccountFacade class. The Facade class uses the classes AccountManager, SecurityManager, AccountReference and BankAccount to perform the appropriate actions. By using the Facade pattern we decouple the client code from the implementation and security details when performing tasks related to the bank account. Flyweight Pattern Definition Th Flyweight pattern provides a mechanism by which you can avoid creating a large number of 'expensive' objects and instead reuse existing instances to represent new ones. Where to use •When there is a very large number of objects that may not fit in memory. •When most of an objects state can be stored on disk or calculated at runtime. •When there are groups of objects that share state. •When the remaining state can be factored into a much smaller number of objects with shared state. Benefits Reduce the number of objects created, decrease memory footprint and increase performance. Drawbacks/consequences Designing objects down to the lowest levels of system "granularity" provides optimal flexibility, but can be unacceptably expensive in terms of performance and memory usage. Structure
Usage example The example used in the original GoF book for the flyweight pattern are the data structures for graphical representation of characters in a word processor. It would be nice to have, for each character in a document, a glyph object containing its font outline, font metrics, and other formatting
www.Vidyarthiplus.com www.Vidyarthiplus.com
data, but it would amount to hundreds or thousands of bytes for each character. Instead, for every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document; only the position of each character (in the document and/or the page) would need to be stored externally. Another typical example of usage is the one of folders. The folder with name of each of the company employee on it, so, the attributes of class Folder are: “Selected”, “Not Selected” and the third one is “employeeName”. With this methodology, we will have to create 2000 folder class instances for each of the employees. This can be costly, so we can create just two class instances with attributes “selected” and “not selected” and set the employee's name by a method like: setNameOnFolder(String name); This way, the instances of class folder will be shared and you will not have to create multiple instances for each employee. Proxy Pattern Definition A Proxy is a structural pattern that provides a stand-in for another object in order to control access to it. Where to use •When the creation of one object is relatively expensive it can be a good idea to replace it with a proxy that can make sure that instantiation of the expensive object is kept to a minimum. •Proxy pattern implementation allows for login and authority checking before one reaches the actual object that's requested. •Can provide a local representation for an object in a remote location. Benefits Gives the ability to control access to an object, whether it's because of a costly creation process of that object or security issues. Drawbacks/consequences Introduces another abstraction level for an object, if some objects accesses the target object directly and another via the proxy there is a chance that they get different behavior this may or may not be the intention of the creator. Behavioral Design Patterns “In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication.”4 Behavioral patterns are patterns that focuses on the interactions between cooperating objects. The interactions between cooperating objects should be such that they are communicating while maintaining as loose coupling as possible. The loose coupling is the key to n-tier architectures. In this, the implementation and the client should be loosely coupled in order to avoid
www.Vidyarthiplus.com www.Vidyarthiplus.com
hard-coding and dependencies.
Chain-of-responsibility Pattern The Chain-of-responsibility pattern lets more than one object handle a request without mutual knowledge. We avoid coupling between the sender of a request and the possible receivers. We place all receivers in a chain which lets the receiving objects pass the request along to the next receiver in the chain until one receiver handles it, or the end of the chain is reached. Where to use •When more than one object may handle a request, and the handler isn't known. •When you want to issue a request to one of several objects without specifying the receiver explicitly. •When the set of objects that can handle a request should be specified dynamically. Benefits •It reduces coupling. •It increases the flexibility of handling a request. Drawbacks/consequences Reception isn't guaranteed since a request has no explicit receiver, there's no guarantee it will be handled unless the chain is configured properly.
Usage example A good example is the creation of an error logging system. By creating different error-handlers, with differentiating responsibilities and connecting them in a chain. We can then pass, any potential errors that we want to log “down the chain” and letting the individual error-handlers handle the error. Command Pattern Definition The Command pattern is used to create objects that represents actions and events in an application. A command object encapsulates an action or event and contains all information required to understand exactly what has happened. By passing the command object as a parameter we can, anywhere needed extract information about occurred actions and events. Where to use • Where you want a action that can be represented in many ways, like dropdown
www.Vidyarthiplus.com www.Vidyarthiplus.com
menu, buttons and popup menu. • To create undo/redo functionality. Benefits • A command object is a possible storage for procedure parameters. It can be used while assembling the parameters for a function call and allows the command to be set aside for later use. • A class is a suitable place to collect code and data related to a specific action or event. •It allows the reaction to a command to be executed some time after it has occurred. •Command objects enables data structures containing multiple commands. •Command objects supports undo-able operations, provided that the command objects are stored (for example in a linked list). Drawbacks/consequences The main disadvantage of the Command pattern seems to be a proliferation of little classes that clutter up the program. However, even in the case where we have separate click events, we usually call little private methods to carry out the actual function. It turns out that these private methods are just about as long as our little classes, so there is frequently little difference in complexity between building the Command classes and just writing more methods. The main difference is that the Command pattern produces little classes that are much more readable. Structure
Iterator Pattern Definition The Iterator design pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Where to use Use to access the elements of an aggregate object sequentially. Java's collections like ArrayList and HashMap have implemented the iterator pattern. Benefits •The same iterator can be used for different aggregates. •Allows you to traverse the aggregate in different ways depending on your
www.Vidyarthiplus.com www.Vidyarthiplus.com
needs. •It encapsulates the internal structure of how the iteration occurs. •Don't need to bloat the your class with operations for different traversals. Drawbacks/consequences Not thread safe unless its a robust iterator that allows insertions and deletions. This can be be solved by letting the Iterator use a Memento to capture the state of an iteration.
Mediator Pattern Definition With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This results in a more cohesive implementation of the logic and decreased coupling between the other objects. Where to use The Mediator pattern can be used when a set of objects communicate in well-specified but complex ways and the resulting interdependencies are unstructured and hard to grasp. If it is difficult to reuse an object because it refers to and communicates with many other objects this pattern is a good solution. Communicating objects' identities will be protected when using the Mediator pattern which is good when security is important. Also, if you like to customize some behavior which is spread out between several classes without a lot of subclassing this pattern should be applied. The pattern is used in many modern systems that reflect a send/receive protocol, such as list servers and chat rooms. Another area of use is graphical user interfaces, where the mediator can encapsulate a collective behavior to control and coordinate the interactions of a group of GUI widgets. The mediator serves as an intermediary that keeps objects in the group from referring to each other explicitly. The objects only know the mediator which reduces the
www.Vidyarthiplus.com www.Vidyarthiplus.com
number of interconnections. Benefits The Mediator pattern has five benefits and drawbacks: 1. Limited subclassing, since a mediator localizes behavior that otherwise would be distributed among several objects. Changing some behavior requires us to subclass only the mediator. 2. Colleagues become decoupled which allows us to vary and reuse colleague and mediator classes independently. 3. A mediator simplifies object protocols since it replaces many-to-many interactions with one-to-many interactions between the mediator and its colleagues. One-to-many interactions are easier to understand, maintain, and extend. 4. The mediator abstracts object cooperation. The mediator lets you focus on how objects interact apart from their individual behaviors which can help clarify how objects interact in a system. 5. Centralized control is achieved by trading complexity of interaction for complexity in the mediator. A mediator encapsulates protocols and can become more complex than any individual colleague. This can make the mediator itself a very complex and large piece of code that is hard to maintain. Drawbacks/consequences Besides the benefits and drawbacks described above, one important drawback is that the Mediator pattern can have a performance impact on a system. Since all communication must go through the mediator, it can become a bottleneck.
Small example Consider a dialog where there are a display label and three buttons: view, book and search. When clicking the view button it should be disabled and its two colleague buttons should be enabled. Also, the display label should change to reflect which button was pressed. We create four classes
www.Vidyarthiplus.com www.Vidyarthiplus.com
ButtonView, ButtonBook, ButtonSearch and LabelDisplay. Then we let the button classes implement an interface Command which allows us to execute the actions of the buttons from a common interface. All of these GUI classes are unaware of each other; they should only refer to the mediator. We now create the Mediator class which holds references to all the GUI objects to control and coordinate the interactions of these objects. Finally, we create the MediatorExample class to display the components in a frame. The class implements the ActionListener interface to which all the buttons should register.
Memento Pattern Definition To record an object internal state without violating encapsulation and reclaim it later without knowledge of the original object. A memento is an object that stores a snapshot of the internal state of another object. Where to use •When letting some info in an object be available by another object. •When you want to create snapshots of a state for an object. •When you need undo/redo features. Benefits Ability to restore an object to its previous state. Drawbacks/consequences Care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object. Using memento to store large amounts of data from Originator might be expensive if clients create and return mementos frequently.
www.Vidyarthiplus.com www.Vidyarthiplus.com
In the class-diagram above: •An instance from the Originator class is the object that knows how to save itself. Uses memento to restore itself. •An instance from the Caretaker class is the object that knows why and when the Originator needs to save and restore itself. Never operates or examines the contents of memento •An instance of the Memento class is the lock box that is written and read by the Originator, and shepherded by the Caretaker. The originator is any object that has an internal state, that we want to take a snapshot of. The caretaker is going to do something to the originators state, but wants to be able to later restore the originators state. The caretaker first asks the originator for a memento object, containing the snapshot. Then it performs the sequence of operations it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. Usage example Often used in database transactions and undo/redo situations. Observer Pattern Definition An observer is a structural pattern that enables publish/subscribe functionality. This is accomplished by an autonomous object, publisher that allows other objects to attach or detach their subscription as they like. The pattern does not impose any limit to the number of observers that can attach, or subscribe, themselves for notification on future changes in the publisher's state. Where to use When an object wants to publish information and many objects will need to receive that information. Benefits Makes for a loose coupling between publisher and subscriber as the publisher does not need to know who or how many subscribers there will be. Drawbacks/consequences In a complex scenario there may be problems to determining whether the update to the publisher is of relevance to all subscribers or just some of them. Sending an update signal to all subscribers might impose a communication overhead of not needed information.
www.Vidyarthiplus.com www.Vidyarthiplus.com
State Pattern Definition The State pattern allows an object to alter its behavior when its internal state changes. By using inheritance and letting subclasses represent different states and functionality we can switch during runtime. This is a clean way for an object to partially change its type at runtime. Where to use •When we need to define a "context" class to present a single interface to the outside world. By defining a State abstract base class. •When we want to represent different "states" of a state machine as derived classes of the State base class. Benefits •Cleaner code when each state is a class instead. •Use a class to represent a state, not a constant. Drawbacks/consequences •Generates a number of small class objects, but in the process, simplifies and clarifies the program. •Eliminates the necessity for a set of long, look-alike conditional statements scattered throughout the code.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Small example This example has two states. StateA writes name in lower-case and StateB in upper-case. We start in state A and then change to state B where we stay for two calls to writeName before changing back to state A.
Strategy Pattern Definition Use strategy when you need to define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Related patterns include State, Flyweight, Decorator, Composite. Where to use •When you need to use one of several algorithms dynamically. •When you want to configure a class with one of many related classes (behaviors). •When an algorithm uses data that clients shouldn't know about. Benefits •Reduces multiple conditional statements in a client. •Hides complex, algorithmic-specific data from the client.
www.Vidyarthiplus.com www.Vidyarthiplus.com
•Provides an alternative to subclassing. •Can be used to hide data that an algorithm uses that clients shouldn't know about. Drawbacks/consequences •Clients must be aware of different strategies. A client must understand how strategies differ before it can select the appropriate one. •Increases the number of objects in an application.
In the class-diagram above: •The Strategy interface defines the behavior that is common to all the concrete implementations. •The ConcreteStrategy encapsulates an implementation of a specific algorithm or behavior that is defined through the Strategy interface. •The Context provides certain services that is defined by the Strategy interface and implemented by different ConcreteStrategy classes depending on behavior. Small example This example uses sorting algorithms. Two sorting algorithms (Bubble sort and Quick sort) are implemented and the client can select either of the algorithms. The SortInterface describes what the algorithms must be able to do, sort(). The classes QuickSort and BubbleSort both implements the SortInterface and each have their own algorithm for sorting. SortingContext maintains a reference to a Strategy object and forwards client requests to the strategy. SortingClient set the concrete strategy in the context and invokes the context to run the algorithm. Usage example The strategy pattern is used in the implementation of the LayoutManager in Java. The LayoutManager can be configured to work with different layout objects, such as FlowLayout, CardLayout, GridLayout, etc. These classes encapsulate the actual algorithms for laying out visual components that the
www.Vidyarthiplus.com www.Vidyarthiplus.com
LayoutManager uses to render the interface on the screen. By changing the Layout (algorithm) we can dynamically change how the interface is rendered.
www.Vidyarthiplus.com www.Vidyarthiplus.com
UNIT IV - FUNCTION AND SERVICE ORIENTED DESIGNS
Function-oriented Design
Structural decomposition – Detailed Design Objectives
• To explain how a software design may be represented as a set of functions which share system state information. • To introduce notations which may be used to represent a function- oriented design. • To develop an example which illustrates the process of function- oriented design. • To compare, using a common example, sequential and concurrent function-oriented design and object-oriented design.
Contents
15.1 Data-flow design 15.2 Structural decomposition 15.3 Detailed design 15.4 A comparison of design strategies
www.Vidyarthiplus.com www.Vidyarthiplus.com
A function-oriented design strategy relies on decomposing the system into a set of interacting functions with a centralised system state shared by these functions (Figure 15.1). Functions may also maintain local state information but only for the duration of their execution. Function-oriented design has been practised informally since programming began. Programs were decomposed into subroutines which were functional in nature. In the late 1960s and early 1970s several books were published which described ‘top-down’ functional design. They specifically proposed this as a ‘structured’ design strategy (Myers, 1975; Wirth, 1976; Constantine and Yourdon, 1979). These led to the development of many design methods based on functional decomposition. Function-oriented design conceals the details of an algorithm in a function but system state information is not hidden. This can cause problems because a function can change the state in a way which other functions do not expect. Changes to a function and the way in which it uses the system state may cause unanticipated changes in the behaviour of other functions. A functional approach to design is therefore most likely to be successful when the amount of system state information is minimised and information sharing is explicit. Systems whose responses depend on a single stimulus or input and which are not affected by input histories are naturally functionally-oriented. Many transaction-processing systems and business data-processing systems fall into this class. In essence, they are concerned with record processing where the processing of one record is not dependent on any previous processing. An example of such a transaction processing system is the software which controls automatic teller machines (ATMs) which are now installed outside many banks. The service provided to a user is independent of previous services provided so can be thought of as a single transaction. Figure 15.2 illustrates a simplified functional design of such a system. Notice that this design follows the centralised management control model introduced in Chapter 13. In this design, the system is implemented as a continuous loop and actions are triggered when a card is input. Functions such as Dispense_cash, Get_account_number, Order_statement, Order_checkbook, etc. can be identified which implement system actions. The system state maintained by the program is minimal. The user services operate independently and do not interact with each other. An object-oriented design would be similar to this and would probably not be significantly more maintainable.
Shared memory
F1 F2 F3
Figure 15.1 A function-oriented F4 F5 view of design
www.Vidyarthiplus.com www.Vidyarthiplus.com
loop loop Print_input_message (” Welcome - Please enter your card”) ; exit when Card_input ; end loop ; Account_number := Read_card ; Get_account_details (PIN, Account_balance, Cash_available) ; if Validate_card (PIN) then loop Print_operation_select_message ; case Get_button is when Cash_only => Dispense_cash (Cash_available, Amount_dispensed) ; when Print_balance => Print_customer_balance (Account_balance) ; when Statement => Order_statement (Account_number) ; when Check_book => Order_checkbook (Account_number) ; end case ; Eject_card ; Print (“Please take your card or press CONTINUE”) ; exit when Card_removed ; end loop ; Update_account_information (Account_number, Amount_dispensed) ; else Retain_card ; end if ; Figure 15.2 The end loop ; functional design of software for an ATM As object-oriented design has become more widely used, some people have suggested that function-oriented design is obsolete. It should be superseded by an object-oriented approach. There are several good reasons why this should not and will not happen: 1. As discussed above, there are classes of system, particularly business systems, where object-oriented design does not offer significant advantages in terms of system maintainability or reliability. In these cases, an object- oriented approach may result in a less efficient system implementation. 2. Many organisations have developed standards and methods based on functional decomposition. They are understandably reluctant to discard these in favour of object-oriented design. Many design methods and associated CASE tools are functionally oriented. A large capital and training investment in these systems has been made. 3. An enormous number of systems have been developed using a functional approach. These legacy systems will have to be maintained for the foreseeable future. Unless they are radically re-engineered, their design structure will remain functional. It is not sensible to view the function-oriented and object-oriented approaches as competing design strategies. Rather, they are applicable in different
www.Vidyarthiplus.com www.Vidyarthiplus.com
circumstances and for different types of application. Good designers chose the most appropriate strategy for the application that is being developed rather than use a single approach. In this chapter, I illustrate a function-oriented design process using a number of examples. The activities in that process are: 1. Data-flow design Model the system design using data-flow diagrams. This should show how data passes through the system and is transformed by each system function. This model may be derived from data-flow models developed during the analysis process. 2. Structural decomposition Model how functions are decomposed into sub- functions using graphical structure charts. 3. Detailed design description Describe the entities in the design and their interfaces. These descriptions may be recorded in a data dictionary. Also describe the control structure of the design using a program description language (PDL) which includes conditional statements and looping constructs. As with all design processes, these activities are not carried out in sequence but are interleaved during the design process.
15.1 Data-flow design
Data-flow design is concerned with designing a sequence of functional transformations that convert system inputs into the required outputs. The design is represented as data-flow diagrams. These diagrams illustrate how data flows through a system and how the output is derived from the input through a sequence of functional transformations. Data-flow diagrams are a useful and intuitive way of describing a system. They are normally understandable without special training, especially if control information is excluded. They show end-to-end processing. That is, the flow of processing from when data enters the system to where it leaves the system can be traced. Data-flow design is an integral part of a number of design methods and most CASE tools support data-flow diagram creation. Different methods may use different icons to represent data-flow diagram entities but their meanings are similar. The notation which I use is based on the following symbols: 1. Rounded rectangles represent functions which transform inputs to outputs. The transformation name indicates its function. 2. Rectangles represent data stores. Again, they should be given a descriptive name. 3. Circles represent user interactions with the system that provide input or receive output.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Get design name Design Figure 15.3 Data- name flow diagram of a design report Entity names generator Design Get entity Sort entity database names names
Sorted Produce names link report Link Data Lookup report dictionary entity names Link and Integrate Design entity descriptions reports descriptions Node report and Integrated Sort by Produce report type node report Node descriptions Print report
4. Arrows show the direction of data flow. Their name describes the data flowing along that path. 5. The keywords ‘and’ and ‘or’. These have their usual meanings as in boolean expressions. They are used to link data flows when more than one data flow may be input or output from a transformation. This notation is illustrated in Figure 15.3 which shows a data-flow design of a design report generator. The report generator produces a report which describes all of the named entities in a data-flow diagram. The user inputs the name of the design represented by the diagram. The report generator then finds all the names used in the data-flow diagram. It looks up a data dictionary and retrieves information about each name. This is then collated into a report which is output by the system. Data-flow diagrams show functional transformations but do not suggest how these might be implemented. A system described in this way might be implemented as a single program using functions or procedures to implement each transformation. Alternatively, it could be implemented as a number of communicating tasks.
15.2 Structural decomposition
As well as a data-flow model of a system, it is also useful to develop a structural system model. This structural model shows how a function is realised by a number
www.Vidyarthiplus.com www.Vidyarthiplus.com
of other functions which it calls. Structure charts are a graphical way to represent this decomposition hierarchy. Like data-flow diagrams, they are dynamic rather than static system models. They show how one function calls others. They do not show the static block structure of a function or procedure. A function is represented on a structure chart as a rectangle. The hierarchy is displayed by linking rectangles with lines. Inputs and outputs (which may be implemented either as parameters or shared variables) are indicated with annotated arrows. An arrow entering a box implies input, leaving a box implies output. Data stores are shown as rounded rectangles and user inputs as circles. Converting a data-flow diagram to a structure chart is not a mechanical process. It requires designer insight and creativity. However, there are several ‘rules of thumb’ which may be applied to help designers assess if their decomposition is likely to be a reasonable one: 1. Many systems, particularly business systems for which functional design is most appropriate, can be considered as three-stage systems. These are input some data, perhaps with validation and checking, process the data then output the data, perhaps in the form of a report or perhaps to some other file. A master file may also be updated. The first-level structure chart may therefore have 3 or 4 functions corresponding to input, process, master-file update and output. Figure 15.4 illustrates this structure although, in this case, there is no master file processing. 2. If data validation is required, functions to implement these should be subordinate to an input function. Output formatting, printing and writing to disk or tape should be subordinate to an output function. 3. The role of functions near the top of the structural hierarchy may be to control and coordinate a set of lower-level functions. 4. The objective of the design process is to have loosely coupled, highly cohesive components (cohesion and coupling were discussed in Chapter 10). Functions should therefore do one thing and one thing only. 5. Each node in the structure chart should have between two and seven subordinates. If there is only a single subordinate, this implies that the unit represented by that node may have a low degree of cohesion. The component may not be single function. A single subordinate means that another function has been factored out. If a node has too many subordinates, this may mean that the design has been developed to too low a level at that stage. Three process steps, which follow these guidelines, can be identified for the transformation process from data-flow diagram to structure chart: 1. Identify system processing transformations These are the transformations in the diagram which are responsible for central processing functions. They are not concerned with any input or output functions such as reading or writing data, data validation or filtering or output formatting. Group these transformations under a single function at the first-level in the structure chart.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Produce design reports entity entity names data entity entity names data
Get design Collate Generate entity names entities report
Figure 15.4 Initial Design Design Design structure chart for the name entity names report design report generator 2. Identify input transformations These are concerned with reading data, checking it, removing duplicates, etc. These should also be grouped under a single function at the first-level in the structure chart. 3. Identify output transformations These are transformations which prepare and format output or write it to the user’s screen or other device. However, there are several ‘rules of thumb’ that can be applied to help designers in this process. In the design report generator data-flow diagram (Figure 15.3), the processing functions are those which sort the input, look up the data dictionary and sort the information retrieved from the data dictionary. In the structure chart (Figure 15.4) these are collected together into a single function called Collate entities. This initial structure chart can be decomposed to show subordinate functions which also reflect transformations in the data-flow diagram (Figure 15.5). Figure 15.5 Second-level structure chart for the design report Produce sorted design reports entity generator names data names Collate sorted Get design Generate entities entity entity names report data entity names sorted names sorted entity design names entity Integrated name data data report
Get design Get entity Sort entities Get entity Sort entities Produce Print name names by name data by type integrated report report
design entity entity report name names data
www.Vidyarthiplus.com www.Vidyarthiplus.com
sorted Produce entity design reports names data names Collate sorted Get design entities Generate entity names entity data report entity names sorted sorted design names entity names data entity Integrated name data report
Get design Get entity Sort entities Get entity Sort entities Produce Print name names by name data by type integrated report report design entity entity Node design entity Link Node name names name data data data name report report Design Data Link database dictionary report Produce Produce link report node report
Figure 15.6 Final structure chart for the The input transformations stop at the function Sort entity names. In this design report case they are simply concerned with reading information. No data checking is generator required. They are represented as a function called Get design entity names. The output transformations are concerned with producing reports for link and node type, report integration and printing. These are all concerned with the formatting and organisation of design entity descriptions. These are grouped under the function Generate report. All the principal routines in the design report generator have now been identified. It only remains to add a final level of more detailed routines and to show how the system data stores are accessed. The final structure chart is shown in Figure 15.6. This chart does not show the access functions to the data dictionary and the design database. I assume that these data stores are like abstract data types and have their own access functions. Other components may be included in a structure chart which are not directly concerned with data transformation. Because they do not transform data, they do not appear on the data-flow diagram. For example, components which are concerned with logging-in and logging-out a user, system initialisation and any other components concerned with system control rather than data processing may be included at the structural decomposition level.
15.3 Detailed design description
At this stage in the design process, the designer should know the organisation of the design and what each function should do. Design entity description is concerned
www.Vidyarthiplus.com www.Vidyarthiplus.com
with producing a short design specification (sometimes called a minispec) of each function. This requires describing the function, its inputs and its outputs. Making this information explicit usually reveals flaws in the initial decomposition or functions which have been omitted. The data-flow diagrams and structure charts must be re-visited and modified to incorporate the improved understanding of the design. The best way to manage these functional descriptions is to maintain them in a data dictionary. Data dictionaries were introduced in Chapter 6 as a way of recording information in system models developed as part of the requirements analysis process. They can also be used to record information about design entities. Maintaining names and descriptions in a data dictionary reduces the chances of mistakenly reusing names and provides design readers with insights into the designer’s thinking. Data dictionary entries can vary in detail from a short informal description to a specification of the function in a design description language. Figure 15.7 shows some of the data dictionary entries that might be made for the design report generator. As you can see, it includes information about data as well as the functions in the system. Some CASE tools may include facilities which allow data dictionaries to be accessed at the same time as a design diagram. This allows information about individual entities to be viewed at the same time as the diagram showing all entities and their relationships. The tool may allow a design entity to be selected then display the corresponding information from the data dictionary. Figure 15.8 is an example of this facility. It shows a pop-up window which includes a form describing the selected transform in the data-flow diagram.
Entity name Type Description Design name STRING The name of the design assigned by the design engineer. Get design name FUNCTION Input: Design name Function: This function communicates with the user to get the name of a design that has been entered in the design database. Output: Design name Get entity names FUNCTION Input: Design name Function: Given a design name, this function accesses the design database to find the names of the entities (nodes and links) in that design. Output: Entity names Sorted names ARRAY of A list of the names of the entities in a Figure 15.7 Data STRING design held in ascending alphabetical dictionary entries for order. the design report generator
www.Vidyarthiplus.com www.Vidyarthiplus.com
Get design name Design name Entity names Design Get entity Sort entity database names names
Transform name: Sort entity names (Namelist: in out Names)
Data Description: This transform takes a list of entity names and dictionary sorts them into ascending alphabetical order. Duplicates are removed from the list.
It is anticipated that the names will be randomly ordered and Figure 15.8 that a maximum of 200 names need be sorted at one time. Information about A quicksort algorithm is recommended. design entities from a data dictionary
The next stage of the functional design process is to produce detailed designs for each part of the design. These detailed designs should include control information and more precise information about the data structures manipulated.
Figure 15.9 The Document name Known Indexes Current Indexes OIRS user interface Operations Chapter 15 Get document Qualifier Put document QUIT NEW STYLE 'SE BOOK' Search database Add index 4 documents in workspace Documents CLEAR Delete index Delete document Function-oriented design is an approach to software design where the design is decomposed into a set of interacting units where each unit has a clearly defined function. By comparison with object-oriented design, the design components in this approach are cohesive around a function wheras object-oriented cohesion is around some abstract data entity.
Function-oriented design has probably been practised informally since programming began but it was only in the late 1960s and early 1970s that it
www.Vidyarthiplus.com www.Vidyarthiplus.com
These detailed designs may be expressed using some program description language, in some more detailed graphical notation or directly in a programming language. I have already shown examples of how a PDL may be used to describe a design in Figure 15.2. Further examples are shown in Figures 15.11, 15.14 and 15.16.
15.4 A comparison of design strategies
In Chapter 14, I introduced an example of an office information system. This was used to illustrate object identification using a grammatical analysis of a system description. In this section, this example will be expanded and used to compare functional and object-oriented approaches to design. I will also show how a design can be developed for the same system using concurrent processes. The Office Information Retrieval System (OIRS) is an office system which can file documents in one or more indexes, retrieve documents, display and maintain document indexes, archive documents and delete documents. Users request operations from a menu-based interface and the system always returns a message to the user indicating the success or failure of the request. The interface to this system is a form which has a number of fields (Figure 15.9). Some of these fields are menu fields where the user can choose a particular option. Other fields allow user textual input. Menu items may be selected by pointing with a mouse or by moving a cursor using keyboard commands. The fields displayed in the form are as follows: 1. The operation field Selecting this field causes a menu of allowed operations to be displayed as shown in Figure 15.9. 2. The known indexes field Selecting this field causes a menu of existing index names to be displayed. Selecting an item from this list adds it to the current index list. 3. The current indexes field Selecting this field displays a list of the indexes where the current document is to be indexed. 4. The document name field This specifies the name of the document to be filed or the name of the document to be retrieved. If this name is not filled in, the user is prompted for a value. 5. The qualifier field This is a pattern which is used in searching. For example, the pattern ‘A-K’ may be specified with a command to look up the names of documents in the current index lists. The qualifier causes only those names which begin with a letter from A to K to be listed. Alternatively, the qualifier field might contain a keyword such as ‘Software Engineering’. An index search retrieves all documents which contain this keyword. 6. The current workspace Documents are retrieved to the current workspace that may contain several documents. The user may choose a document in the workspace by selecting its name from the workspace menu. Clicking on the Clear button in the workspace control bar removes the selection from the
www.Vidyarthiplus.com www.Vidyarthiplus.com
Current User command workspace
Document and OIRS or Document database database and and Status message Figure 15.10 Current Inputs and outputs of workspace the OIRS
workspace. Moving the cursor into the workspace causes the system to enter document edit mode. When developing a functional design, the initial stage should treat the system as a black box. It should simply show the inputs and outputs of the system with the system itself represented as a single transformation (Figure 15.10). The arc annotated with ‘or’ joining the output data flows means that one or the other but not both of these data flows occur. Notice that the document database and the current workspace are both inputs and outputs. Functional designs of interactive systems often follow a common detailed architectural model . This is a command ‘fetch and execute’ loop. Figure 15.11 describes the general form of a fetch-execute loop. The ATM design, described in Figure 15.2, is an example of this model. In this design, the Get command function has been separated from the Execute command function to allow for different types of user interface and user interface evolution. If the system is moved from a computer without a mouse to a computer with a mouse (say) only the Get command function need be changed. It is generally good design practice to separate, as far as possible, the user interface of a system from the data processing functions. This is discussed in Chapter 17. A data-flow diagram for the OIRS based on this model is shown in Figure 15.12. The central transform is concerned with command execution and further functions are incorporated to manage the database and the workspace.
procedure Interactive_system is begin loop Command := Get_command; if Command = “quit” then -- Make sure files etc. are closed properly Close_down_system ; exit ; else Input_data := Get_input_data ; Figure 15.11 Execute_command (Command, Input_data, Output_data) ; Fetch-execute model end if ; of an interactive end loop ; system end Interactive_system ;
www.Vidyarthiplus.com www.Vidyarthiplus.com
Update Document Get database database command
Current Execute Update Current workspace Command workspace workspace
Document Put status Figure 15.12 database message Top-level data-flow Status message design for the OIRS
The Execute Command transformation can now be considered in isolation and can be decomposed into simpler transformations (Figure 15.13). Figure 15.13 shows that there are three different classes of command in the OIRS. These are commands to update the workspace (Get document, Search database, Clear workspace and the implicit Edit command), commands to update the database (Put document, Delete document) and index commands (Add index, Delete index, Display index lists). For brevity, I have skipped the structural decomposition and entity description stages in the functional design process and have gone straight to detailed design description. Figure 15.14 is a design, expressed in a PDL, for the top-level of the OIRS. As discussed in the previous section, additional functions have been included for login and initialisation which are not shown in the data-flow diagram. Note that the control structure design shown in Figure 15.14 is not a syntactically correct program. It does not include declarations of the entities which are used. As discussed above, these names should be entered in a data dictionary along with a description of the entities which they identify.
www.Vidyarthiplus.com www.Vidyarthiplus.com
procedure OIRS is begin User := Login_user ; Workspace := Create_user_workspace (User) ; -- Get the users own document database using the user id DB_id := Open_document_database (User) ; -- get the user’s personal index list; Known_indexes := Get_document_indexes (User) ; Current_indexes := NULL ; -- command fetch and execute loop loop Command := Get_command ; exit when Command = Quit ; Execute_command ( DB_id, Workspace, Command, Status) ; if Status = Successful then Write_success_message ; else Write_error_message (Command, Status) ; end if ; Figure 15.14 end loop ; High-level design Close_database (DB_id) ; description of the Logout (User) ; OIRS end OIRS ;
The design process continues by decomposing each of the design components in more detail. This decomposition should stop when the design has been described at a sufficiently detailed level that a program can be developed in the chosen implementation language. This level of detail will obviously vary depending on the language used. The lower level the implementation language, the more detail is
User command Selected document Workspace Identify command type DB update Workspace update command Selected command Index update document command Workspace Update Update workspace database Update index
Status Workspace message Known Database indexes Status update request message Figure 15.13 Data-flow diagram for Execute command
www.Vidyarthiplus.com www.Vidyarthiplus.com
required in the design. 15.4.1 Concurrent systems design
The above functional design models the OIRS as a sequential system with a single control loop which fetches and executes commands in sequence. An alternative approach to the detailed design is to implement the system as a number of concurrent process. As data-flow diagrams explicitly exclude control information, they can also be the starting point for a concurrent design. A standard implementation technique for real-time systems (see Chapter 16) is to take a data- flow diagram and to implement each of its transformations as a separate process. In this case, implementing each data-flow transformation as a separate process would not be an efficient way of designing the system. There is a scheduling overhead involved in starting and stopping processes and managing process communications. Unless it is absolutely necessary because of real-time requirements, it is best to avoid decomposing a system into many small processes. However, to improve real-time response in window-based systems, it is often necessary to identify those parts of the system which must respond to user events and implement these as separate processes. This allows the system to be responsive to time-critical user events such as mouse movements. The strict sequence which is forced by a fetch-execute cycle can be avoided. In the OIRS, there are two situations where user actions cause an event to be generated: 1. When a command is selected. The user moves the cursor into a menu and makes a choice. An event is generated informing the system that a command has been chosen. 2. When the cursor is moved into the workspace and the user starts to type. The user can move the cursor between these areas at any time so the system must be able to cope with the change. This can be handled in a fetch-execute system by making sure that the workspace editor keeps track of the cursor but some code duplication in such a situation is inevitable. Given that the input processing (commands and text) is to be implemented using separate processes, it then makes sense to identify corresponding processes to handle command execution and output processing. This leads to a set of four processes as shown in Figure 15.15. Control passes from process to process in response to events such as a cursor being positioned in a workspace, a command menu being selected, etc.
www.Vidyarthiplus.com www.Vidyarthiplus.com
User Get Execute input Command command
Workspace Message Output Figure 15.15 editor message Process decomposition of the OIRS The Get command task tracks the mouse and responds to low-level mouse events. When a command area is selected, it initiates the command execution process. Similarly, the command execution process produces status messages which are processed by the output task. Workspace editing is also implemented as a parallel task. The editor is initiated and suspended as the cursor is moved in and out of the workspace window. The detailed design of the overall system and the Get command process is shown, in Ada, in Figure 15.16. This uses Ada’s facilities (tasks) for implementing parallel systems. Ada task entries correspond to procedure calls. Therefore, calling an entry Display indexes in Execute command is like calling a function of that name. Details of Ada tasking can be found in Ada textbooks (Burns and Wellings, 1990; Barnes, 1994).
www.Vidyarthiplus.com www.Vidyarthiplus.com
procedure Office_system is task Get_command ; task Process_command is entry Command_menu ; entry Display_indexes ; entry Edit_qualifier ; -- Additional entries here. One for each command end Process_commands ; task Output_message is entry Message_available ; end Output_message ; task Workspace_editor is entry Enter ; entry Leave ; end Workspace_editor ;
task body Get_command is begin -- Fetch/execute loop loop loop Cursor_position := Get_cursor_position ; exit when cursor positioned in workspace or (cursor positioned over menu and button pressed) Display_cursor_position ; end loop ; if In_workspace (Cursor_position) then Workspace_editor.Enter ; elsif In_command_menu (Cursor_position) then Process_command.Command_menu ; elsif In_Known_indexes (Cursor_position) then Process_command.Display_indexes ; elsif In_Current_indexes (Cursor_position) then ... Other commands here ... end loop ; -- Fetch/execute end Get_command ; -- other task implementations here Figure 15.16 end Office_system ; Detailed process design in Ada 15.4.2 Object-oriented design
Both the sequential and concurrent designs of the OIRS are functional because the principal decomposition strategy identifies functions such as Execute command, Update index, etc. By contrast, an object-oriented design focuses on the entities in the system with the functions part of these entities. There is not enough space here to develop a complete object-oriented design but I show the entity decomposition in this section. Notice that this is quite different from the functional system decomposition.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Document Index User Retrieval System Name Name User command File Display Get command Retrieve Delete entry Put message Archive Add entry Figure 15.17 Destroy Initial decomposition of the OIRS into classes and objects We have already seen an initial object identification for the OIRS in Chapter 14. The objects identified from that description are shown in Figure 15.17. This object decomposition leaves out entities such as the database, the workspace, etc. The reason for this is that this decomposition was based on a simple description. This description did not describe all system facilities. Nor did it describe how these facilities are presented to users. We therefore need to define further system objects as shown in Figure 15.18. Documents which are being used are held in a workspace and referenced in indexes. We therefore need objects which correspond to the workspace and each index. Index list is an object class used to create different lists of indexes. The document database is also represented as an object. The initial object decomposition was based on a simple system description. With further information we now have to revisit this decomposition and see if it is still appropriate. We know that the user interface is a graphical interface with various fields and buttons so this should be represented as an object. It can serve as a replacement for the User object so this can now be discarded and its operations incorporated into Display. As a general design guideline, displays map onto objects. Object attributes represent fields on the display. We can see an example of this in Figure 15.19 which should be compared with Figure 15.9 which shows the OIRS display. The Retrieval system object is also modified to add attributes representing the workspace and the indexes used. This object does not have any associated operations. The object is an active object which controls other objects but does not provide services to them. All its functionality is therefore concealed. The principal objects in the OIRS have now been identified. The next stage of the design process is to set out object aggregation hierarchies and how these objects interact as discussed in Section 14.3. In essence, the fetch-execute loop as
Workspace Index list Database Documents Indexes Documents Status Indexes Add index Add doc Remove index Search Remove doc
www.Vidyarthiplus.com www.Vidyarthiplus.com
Display Retrieval system Command list Buttons User command Known indexes Workspace Current indexes Known indexes Doc. name Current indexes Doc. list Qualifier WSpace status Get command Figure 15.19 Put message Modified OIRS objects discussed above is still part of the design. Commands are fetched from the display object. Services provided by the workspace, document and index objects are called on to execute these commands. Given the limited information here, it is impossible to say which design strategy is the best one for this system. The functional approach to design using data-flow diagrams is probably a more intuitive way to describe the overall design. However, the focus on function means that the reader of the design finds it more difficult to understand the entities which are manipulated by the system. The object-oriented approach solves this difficulty as it is very good for entity description. Because of information encapsulation, object-oriented design generally leads to more robust systems where system data is less likely to be corrupted in the event of a program error. It may also be easier to change although this depends on the nature of the change. However, as Fichman and Kemerer (Fichman and Kemerer, 1992) point out, decomposing a system into loosely coupled objects often means that there is no overall picture of end-to-end processing in the design. Designers must use the most appropriate approach to design. They should not be forced into the straitjacket of any particular design method or strategy. My own preference in this instance is to take a heterogeneous approach to the design. The basic functional fetch-execute loop should be retained and data-flow diagrams used to illustrate and understand the system’s processing. The display management should be implemented as a separate process. The objects identified in this section should be used and referenced from the fetch-execute loop.
KEY POINTS
• Function-oriented design relies on identifying functions which transform their inputs to create outputs. In most systems, functions share some global system state. • Many business systems which process transactions are naturally functional. Furthermore, there is a huge amount of legacy code which has been designed
www.Vidyarthiplus.com www.Vidyarthiplus.com
using this approach. For these reasons, function-oriented design will continue alongside object-oriented design as an important design strategy. • The functional design process involves identifying data transformations in the system, decomposing functions into a hierarchy of sub-functions, describing the operation and interface of each system entity and documenting the flow of control in the system. • Data-flow diagrams are a means of documenting end-to-end data flow through a system. They do not include control information. Structure charts are a way of representing the hierarchical organisation of a system. Control may be documented using a program description language (PDL). • Data-flow diagrams can be implemented directly as a set of cooperating sequential processes. Each transform in the data-flow diagram is implemented as a separate process. Alternatively, they can be realised as a number of procedures in a sequential program. • Functional design and object-oriented design usually result in totally different system decompositions. However, the most appropriate design strategy is often a heterogeneous one where both functional and object-oriented approaches are used.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Service-oriented design
Services – Service identification – Service design
Services
In the context of enterprise architecture, service-orientation and service-oriented architecture, the term service refers to a set of related software functionalities that can be reused for different purposes, together with the policies that should control its usage.
OASIS defines service as "a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." Service engineering
An enterprise architecture team will develop the organization's service model first by defining the top level business functions. Once the business functions are defined, they are further sectioned into services that represent the processes and activities needed to manage the assets of the organization in their various states. One example is the separation of the business function "Manage Orders" into services such as "Create Order," "Fulfill Order," "Ship Order," "Invoice Order" and "Cancel/Update Order."
Service description/specification
A service has a description or specification. This description consists of: An explicit and detailed narrative definition supported by a low-level (not implementation-specific) process model. The narrative definition is in some cases augmented by machine-readable semantic information about the service that facilitates service mediation and consistency checking of an enterprise architecture. A set of performance indicators that address measures and performance parameters, such as availability (when should members of the organization be able to perform the function?), duration (how long should it take to perform the function?), rate (how often will the function be performed over a period of time?), etc. A link to the organization's information model showing what information the service owns (creates, reads, updates, and deletes) and which information it references that is owned by other services. Services can be stateless and stateful. Stateless services can be services like data aggregation services. Stateful services are used for executing business logic.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Services
The development of the Web in the 1990s revolutionized organizational information exchange. Client computers could gain access to information on remote servers out- side their own organizations. However, access was solely through a web browser and direct access to the information by other programs was not practical. This meant that opportunistic connections between servers where, for example, a program queried a number of catalogs from different suppliers, were not possible. To get around this problem, the notion of a web service was proposed. Using a web service, organizations that wish to make their information accessible to other programs can do so by defining and publishing a web service interface. This interface defines the data available and how it can be accessed. More generally, a web service is a standard representation for some computational or information resource that can be used by other programs. These may be information resources, such as a parts catalog; computer resources, such as a specialized processor; or storage resources. For example, an archive service could be implemented that permanently and reliably stores organizational data that, by law, has to be maintained for many years. A web service is an instance of a more general notion of a service, which is defined (Lovelock et al., 1996) as:
“an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production”.
The essence of a service, therefore, is that the provision of the service is independ- ent of the application using the service (Turner et al., 2003). Service providers can develop specialized services and offer these to a range of service users from different organizations. Service-oriented architectures (SOAs) are a way of developing distributed systems where the system components are stand-alone services, executing on geo- graphically distributed computers. Standard XML-based protocols, such as SOAP and WSDL, have been designed to support service communication and information exchange. Consequently, services are platform and implementation-language inde- pendent. Software systems can be constructed by composing local services and external services from different providers, with seamless interaction between the services in the system. Figure 19.1 encapsulates the idea of a SOA. Service providers design and implement services and specify the interface to these services. They also publish information about these services in an accessible registry. Service requestors (sometimes called service clients) who wish to make use of a service discover the specification of that service and locate the service provider. They can then bind their application to that specific service and communicate with it, using standard service protocols. From the outset, there has been an active standardization process for SOA, working alongside technical developments. All of the major hardware and software companies are committed to these standards. As a result, SOA have not
www.Vidyarthiplus.com www.Vidyarthiplus.com
510 Chapter 19 I Service-oriented architecture
Service Registry
Find Publish
Service Service Service Figure 19.1 Service- Requestor Bind (SOAP) Provider oriented architecture (WSDL)
suffered from the incompatibilities that normally arise with technical innovations, where different suppliers maintain their proprietary version of the technology. Figure 19.2 shows the stack of key standards that have been established to support web services. Because of this early standardization, problems, such as the multiple incompatible component models in CBSE, discussed in Chapter 17, have not arisen in service-oriented system development. Web service protocols cover all aspects of SOAs, from the basic mechanisms for service information exchange (SOAP) to programming language standards (WS-BPEL). These standards are all based on XML, a human and machine-readable notation that allows the definition of structured data where text is tagged with a mean- ingful identifier. XML has a range of supporting technologies, such as XSD for schema definition, which are used to extend and manipulate XML descriptions. Erl (2004) provides a good summary of XML technologies and their role in web services. Briefly, the key standards for web SOAs are as follows:
1. SOAP This is a message interchange standard that supports the communication between services. It defines the essential and optional components of messages passed between services. 2. WSDL The Web Service Definition Language (WSDL) is a standard for service interface definition. It sets out how the service operations (operation names, parameters, and their types) and service bindings should be defined. 3. WS-BPEL This is a standard for a workflow language that is used to define process programs involving several different services. I discuss the notion of process programs in Section 19.3.
A service discovery standard, UDDI, was also proposed but this has not been widely adopted. The UDDI (Universal Description, Discovery and Integration) standard defines the components of a service specification, which may be used to discover the existence of a service. These include information about the service provider, the services provided, the location of the WSDL description of the serv- ice interface, and information about business relationships. The intention was that this standard would allow companies to set up registries with UDDI descriptions defining the services that they offered.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 19 I Service-oriented architecture 511
XML Technologies (XML, XSD, XSLT, ....)
Support (WS-Security, WS-Addressing, ...)
Process (WS-BPEL)
Service Definition (UDDI, WSDL)
Messaging (SOAP)
Figure 19.2 Web Transport (HTTP, HTTPS, SMTP, ...) service standards
A number of companies, such as Microsoft, set up UDDI registries in the early years of the 21st century but these have now all closed. Improvements in search engine technology have made them redundant. Service discovery using a standard search engine to search for appropriately commented WSDL descriptions is now the preferred approach for discovering external services. The principal SOA standards are supported by a range of supporting standards that focus on more specialized aspects of SOA. There are a very large number of supporting standards because they are intended to support SOA in different types of enterprise application. Some examples of these standards include the following:
1. WS-Reliable Messaging, a standard for message exchange that ensures messages will be delivered once and once only. 2. WS-Security, a set of standards supporting web service security including stan- dards that specify the definition of security policies and standards that cover the use of digital signatures. 3. WS-Addressing, which defines how address information should be represented in a SOAP message. 4. WS-Transactions, which defines how transactions across distributed services should be coordinated.
Web service standards are a huge topic and I don’t have space to discuss them in detail here. I recommend Erl’s books (2004; 2005) for an overview of these standards. Their detailed descriptions are also available as public documents on the Web. Current web services standards have been criticized as being ‘heavyweight’ stan- dards that are over-general and inefficient. Implementing these standards requires a considerable amount of processing to create, transmit, and interpret the associated XML messages. For this reason, some organizations, such as Amazon, use a simpler, more efficient approach to service communication using so-called RESTful services (Richardson and Ruby, 2007). The RESTful approach supports efficient service
www.Vidyarthiplus.com www.Vidyarthiplus.com
512 Chapter 19 I Service-oriented architecture
RESTful web services
REST (REpresentational State Transfer) is an architectural style based on transferring representations of resources from a server to a client. It is the style that underlies the web as a whole and has been used as a much simpler method than SOAP/WSDL for implementing web services.
A RESTful web service is identified by its URI (Universal Resource identifier) and communicates using the HTML protocol. It responds to HTML methods GET, PUT, POST, and DELETE and returns a resource representation to the client. Simplistically, POST means create, GET means read, PUT means update, and DELETE means delete.
RESTFul services involve a lower overhead than so-called ‘big web services’ and are used by many organizations implementing service-based systems that do not rely on externally provided services.
http://www.SoftwareEngineering-9.com/Web/Services/REST/
interaction but it does not support enterprise-level features such as WS-Reliability and WS-Transactions. Pautasso et al. (2008) compare the RESTful approach with standardized web services. Building applications based on services allows companies and other organiza- tions to cooperate and make use of each other’s business functions. Thus, systems that involve extensive information exchange across company boundaries, such as supply chain systems where one company orders goods from another, can easily be automated. Service-based applications may be constructed by linking services from various providers using either a standard programming language or a specialized workflow language, as discussed in Section 19.3. SOAs are loosely coupled architectures where service bindings can change dur- ing execution. This means that a different, but equivalent version of the service may be executed at different times. Some systems will be solely built using web services and others will mix web services with locally developed components. To illustrate how applications that use a mixture of services and components may be organized, consider the following scenario:
An in-car information system provides drivers with information on weather, road traffic conditions, local information, and so forth. This is linked to the car radio so that information is delivered as a signal on a specific radio channel. The car is equipped with GPS receiver to discover its position and, based on that position, the system accesses a range of information services. Information may then be delivered in the driver’s specified language.
Figure 19.3 illustrates a possible organization for such a system. The in-car soft- ware includes five modules. These handle communications with the driver, with a GPS receiver that reports the car’s position and with the car radio. The Transmitter and Receiver modules handle all communications with external services. The car communicates with an external mobile information service that aggre- gates information from a range of other services, providing information on weather,
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 19 I Service-oriented architecture 513
Road Traffic Info
Weather Facilities Road Traffic Info Info Locator Info
GPS Coord GPS Coord GPS Coord
Mobile Info Service Service Discovery Translator Collates Information Finds Available Services Language Info Info Command Stream GPS Coord
Receiver Transmitter User Interface Receives Sends Position and Receives Request Information Stream Information Request From User From Services to Services
Radio Locator Translates Digital Discovers Car Info Stream to Position Figure 19.3 A Radio Signal service-based, in-car In-Car Software System information system
traffic information, and local facilities. Different providers in different places offer these services, and the in-car system uses a discovery service to locate appropriate information services and bind to them. The discovery service is also used by the mobile information service to bind to the appropriate weather, traffic, and facilities services. Services exchange SOAP messages that include GPS position information used by the services to select the appropriate information. The aggregated informa- tion is then sent to the car through a service that translates that information into the driver’s preferred language. This example illustrates one of the key advantages of the service-oriented approach. It is not necessary to decide when the system is programmed or deployed what service provider should be used or what specific services should be accessed. As the car moves around, the in-car software uses the service discovery service to find the most appropriate information service and binds to that. Because of the use of a translation service, it can move across borders and therefore make local informa- tion available to people who don’t speak the local language. A service-oriented approach to software engineering is a new software engineering paradigm that is, in my view, as important a development as object-oriented software
www.Vidyarthiplus.com www.Vidyarthiplus.com
514 Chapter 19 I Service-oriented architecture
Service-oriented and component-oriented software engineering
Services and components obviously have much in common. They are both reusable elements and, as I discussed in Chapter 17, it is possible to think of a component as a provider of services. However, there are important differences between services and components, and between a service-oriented and a component- oriented approach to software engineering.
http://www.SoftwareEngineering-9.com/Web/Services/Comps.html
engineering. This paradigm shift will be accelerated by the development of ‘cloud computing’ (Carr, 2009), where services are offered on a utility computing infrastruc- ture hosted by major providers, such as Google and Amazon. This has had and will continue to have profound effects on systems products and business processes. Newcomer and Lomow (2005), in their book on SOA, summarize the potential of service-oriented approaches:
“Driven by the convergence of key technologies and the universal adoption of Web services, the service-oriented enterprise promises to significantly improve corporate agility, speed time-to-market for new products and services, reduce IT costs and improve operational efficiency.”
We are still at a relatively early stage in the development of service-oriented applications that are accessed over the Web. However, we are already seeing major changes in the ways that software is implemented and deployed, with the emergence of systems such as Google Apps and Salesforce.com. Service-oriented approaches at both the application and the implementation level means that the Web is evolving from an information store to a systems implementation platform.
19.1 Services as reusable components
In Chapter 17, I introduced component-based software engineering (CBSE), in which software systems are constructed by composing software components that are based on a standard component model. Services are a natural development of soft- ware components where the component model is, in essence, a set of standards asso- ciated with web services. A service can therefore be defined as the following:
A loosely-coupled, reusable software component that encapsulates discrete functionality, which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML- based protocols.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.1 I Services as reusable components 515
A critical distinction between a service and a software component, as defined in CBSE, is that services should be independent and loosely coupled; that is, they should always operate in the same way, irrespective of their execution environment. Their interface is a ‘provides’ interface that allows access to the service functional- ity. Services are intended to be independent and usable in different contexts. Therefore, they do not have a ‘requires’ interface that, in CBSE, defines the other system components that must be present. Services communicate by exchanging messages, expressed in XML, and these mes- sages are distributed using standard Internet transport protocols such as HTTP and TCP/IP. I have discussed this message-based approach to component communication in Section 18.1.1. A service defines what it needs from another service by setting out its requirements in a message and sending it to that service. The receiving service parses the message, carries out the computation and, on completion, sends a reply, as a message, to the requesting service. This service then parses the reply to extract the required information. Unlike software components, services do not use remote proce- dure or method calls to access functionality associated with other services. When you intend to use a web service, you need to know where the service is located (its URI) and the details of its interface. These are described in a service description expressed in an XML-based language called WSDL. The WSDL specifi- cation defines three things about a web service: what the service does, how it communicates, and where to find it:
1. The ‘what’ part of a WSDL document, called an interface, specifies what oper- ations the service supports, and defines the format of the messages that are sent and received by the service. 2. The ‘how’ part of a WSDL document, called a binding, maps the abstract inter- face to a concrete set of protocols. The binding specifies the technical details of how to communicate with a web service. 3. The ‘where’ part of a WSDL document describes the location of a specific web service implementation (its endpoint).
The WSDL conceptual model (Figure 19.4) shows the elements of a service description. Each of these is expressed in XML and may be provided in separate files. These parts are:
1. An introductory part that usually defines the XML namespaces used and which may include a documentation section providing additional information about the service. 2. An optional description of the types used in the messages exchanged by the service. 3. A description of the service interface; that is, the operations that the service pro- vides for other services or users. 4. A description of the input and output messages processed by the service.
www.Vidyarthiplus.com www.Vidyarthiplus.com
516 Chapter 19 I Service-oriented architecture
WSDL Service Definition
Intro XML Namespace Declarations
Type Declarations Abstract Interface Interface Declarations Message Declarations
Concrete Binding Declarations Implementation Endpoint Declarations Figure 19.4 Organization of a WSDL specification
5. A description of the binding used by the service (i.e., the messaging protocol that will be used to send and receive messages). The default is SOAP but other bindings may also be specified. The binding sets out how the input and output messages associated with the service should be packaged into a message, and specifies the communication protocols used. The binding may also specify how supporting information, such as security credentials or transaction identifiers, is included. 6. An endpoint specification which is the physical location of the service, expressed as a Uniform Resource Identifier (URI)—the address of a resource that can be accessed over the Internet.
Complete service descriptions, written in XML, are long, detailed, and tedious to read. They usually include definitions of XML namespaces, which are qualifiers for names. A namespace identifier may precede any identifier used in the XML descrip- tion, making it possible to distinguish between identifiers with the same name that have been defined in different parts of an XML description. You don’t have to under- stand the details of namespaces to understand the examples here. You only need to know that names may be prefixed with a namespace identifier and that the name- space:name pair should be unique. WSDL specifications are now rarely written by hand and most of the information in a specification can be automatically generated. You don’t need to know the details of a specification to understand the principles of WSDL so I focus here on the description of the abstract interface. This is the part of a WSDL specification that equates to the ‘provides’ interface of a software component. Figure 19.5 shows part of the interface for a simple service that, given a date and a place, specified as a town within a country, returns the maximum and minimum temperature recorded in that place on that date. The input message also specifies whether these temperatures are to be returned in degrees Celsius or degrees Fahrenheit. In Figure 19.5, the first part of the description shows part of the element and type definition that is used in the service specification. This defines the elements PlaceAndDate, MaxMinTemp, and InDataFault. I have only included the specification of PlaceAndDate, which you can think of as a record with three fields—town, country, and date. A similar approach would be used to define MaxMinTemp and InDataFault.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.1 I Services as reusable components 517
Define some of the types used. Assume that the namespace prefix ‘ws’ refers to the namespace URI for XML schemas and the namespace prefix associated with this definition is weathns.
The second part of the description shows how the service interface is defined. In Figure 19.5 Part of a WSDL description for this example, the service weatherInfo has a single operation, although there are no a web service restrictions on the number of operations that may be defined. The weatherInfo operation has an associated in-out pattern meaning that it takes one input message and generates one output message. The WSDL 2.0 specification allows for a number of different message exchange patterns such as in-only, in-out, out-only, in-optional-out, out-in, etc. The input and output messages, which refer to the definitions made earlier in the types section, are then defined. The major problem with WSDL is that the definition of the service interface does not include any information about the semantics of the service or its non-functional characteristics, such as performance and dependability. It is simply a description of the service signature (i.e., the operations and their parameters). The programmer
www.Vidyarthiplus.com www.Vidyarthiplus.com
518 Chapter 19 I Service-oriented architecture
who plans to use the service has to work out what the service actually does and what the different fields in the input and output messages mean. The performance and dependability have to be discovered by experimenting with the service. Meaningful names and documentation help with understanding the functionality that is offered but it is still possible for readers to misunderstand the service. Service identification – Service design 19.2 Service engineering Service engineering is the process of developing services for reuse in service- oriented applications. It has much in common with component engineering. Service engineers have to ensure that the service represents a reusable abstraction that could be useful in different systems. They must design and develop generally useful func- tionality associated with that abstraction and ensure that the service is robust and reliable. They have to document the service so that it can be discovered and under- stood by potential users. There are three logical stages in the service engineering process, as shown in Figure 19.6. These are as follows:
1. Service candidate identification, where you identify possible services that might be implemented and define the service requirements. 2. Service design, where you design the logical and WSDL service interfaces. 3. Service implementation and deployment, where you implement and test the service and make it available for use.
As I discussed in Chapter 16, the development of a reusable component may start with an existing component that has already been implemented and used in an applica- tion. The same is true for services—the starting point for this process will often be an existing service or a component that is to be converted to a service. In this situation, the design process involves generalizing the existing component so that application- specific features are removed. Implementation means adapting the component by adding service interfaces and implementing the required generalizations.
19.2.1 Service candidate identification The basic notion of service-oriented computing is that services should support business processes. As every organization has a wide range of processes, there are therefore many possible services that may be implemented. Service candidate iden- tification therefore involves understanding and analyzing the organization’s busi- ness processes to decide which reusable services could be implemented to support these processes.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.2 I Service engineering 519
Service Service Candidate Service Design Implementation Identification and Deployment
Service Service Interface Validated and Requirements Specification Deployed Service Figure 19.6 The service engineering process
Erl suggests that there are three fundamental types of service that may be identified:
1. Utility services These are services that implement some general functionality that may be used by different business processes. An example of a utility service is a currency conversion service that can be accessed to compute the conversion of one currency (e.g., dollars) to another (e.g., euros). 2. Business services These are services that are associated with a specific business function. An example of a business function in a university would be the regis- tration of students for a course. 3. Coordination or process services These are services that support a more general business process which usually involves different actors and activities. An example of a coordination service in a company is an ordering service that allows orders to be placed with suppliers, goods accepted, and payments made.
Erl also suggests that services can be thought of as task-oriented or entity- oriented. Task-oriented services are those associated with some activity, whereas entity-oriented services are like objects. They are associated with a business entity such as, for example, a job application form. Figure 19.7 shows some examples of services that are task- or entity-oriented. Utility or business services may be entity-or task-oriented but coordination services are always task-oriented. Your goal in service candidate identification should be to identify services that are logically coherent, independent, and reusable. Erl’s classification is helpful in this respect as it suggests how to discover reusable services by looking at business entities and business activities. However, identifying service candidates is some- times difficult because you have to envisage how the services will be used. You have to think of possible candidates then ask a series of questions about them to see if they are likely to be useful services. Possible questions that you might ask to identify potentially reusable services are:
1. For an entity-oriented service, is the service associated with a single logical entity that is used in different business processes? What operations are normally performed on that entity that must be supported?
www.Vidyarthiplus.com www.Vidyarthiplus.com
520 Chapter 19 I Service-oriented architecture
Utility Business Coordination
Task Currency converter Validate claim form Process expense claim Employee locator Check credit rating Pay external supplier
Entity Document style checker Expenses form Web form to XML converter Student application form
2. For a task-oriented service, is the task one that is carried out by different people Figure 19.7 Service classification in the organization? Will they be willing to accept the inevitable standardization that occurs when a single support service is provided? 3. Is the service independent (i.e., to what extent does it rely on the availability of other services)? 4. For its operation, does the service have to maintain state? Services are stateless, which means that they do not maintain internal state. If state information is required, a database has to be used and this can limit service reusability. In gen- eral, services where the state is passed to the service are easier to reuse, as no database binding is required. 5. Could the service be used by clients outside of the organization? For example, an entity-oriented service associated with a catalog could be accessed by both internal and external users. 6. Are different users of the service likely to have different nonfunctional require- ments? If they do, then this suggests that more than one version of a service should perhaps be implemented.
The answers to these questions help you select and refine abstractions that can be implemented as services. However, there is no formulaic way of deciding which are the best services and so service identification is a skill- and experience-based process. The output of the service selection process is a set of identified services and asso- ciated requirements for these services. The functional service requirements should define what the service should do. The non-functional requirements should define the security, performance, and availability requirements of the service. To help you understand the process of service candidate identification and imple- mentation, consider the following example:
A large company, which sells computer equipment, has arranged special prices for approved configurations for some customers. To facilitate automated order- ing, the company wishes to produce a catalog service that will allow customers to select the equipment that they need. Unlike a consumer catalog, orders are not placed directly through a catalog interface. Instead, goods are ordered through the web-based procurement system of each company that accesses the catalog as a web service. Most companies have their own budgeting and
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.2 I Service engineering 521
approval procedures for orders and their own ordering process must be fol- lowed when an order is placed.
The catalog service is an example of an entity-oriented service that supports busi- ness operations. The functional catalog service requirements are as follows:
1. A specific version of the catalog shall be provided for each user company. This shall include the configurations and equipment that may be ordered by employ- ees of the customer company and the agreed prices for catalog items. 2. The catalog shall allow a customer employee to download a version of the cata- log for offline browsing. 3. The catalog shall allow users to compare the specifications and prices of up to six catalog items. 4. The catalog shall provide browsing and search facilities for users. 5. Users of the catalog shall be able to discover the predicted delivery date for a given number of specific catalog items. 6. Users of the catalog shall be able to place ‘virtual orders’ where the items required will be reserved for them for 48 hours. Virtual orders must be con- firmed by a real order placed by a procurement system. This must be received within 48 hours of the virtual order.
In addition to these functional requirements, the catalog has a number of non- functional requirements:
1. Access to the catalog service shall be restricted to employees of accredited organizations. 2. The prices and configurations offered to one customer shall be confidential and shall not be available to employees of any other customer. 3. The catalog shall be available without disruption of service from 0700 GMT to 1100 GMT. 4. The catalog service shall be able to process up to 10 requests per second peak load.
Notice that there is no non-functional requirement related to the response time of the catalog service. This depends on the size of the catalog and the expected number of simultaneous users. As this is not a time-critical service, there is no need to spec- ify it at this stage.
19.2.2 Service interface design Once you have selected candidate services, the next stage in the service engineering process is to design the service interfaces. This involves defining the operations associated with the service and their parameters. You also have to think carefully
www.Vidyarthiplus.com www.Vidyarthiplus.com
522 Chapter 19 I Service-oriented architecture
Operation Description
MakeCatalog Creates a version of the catalog tailored for a specific customer. Includes an optional parameter to create a downloadable PDF version of the catalog.
Compare Provides a comparison of up to six characteristics (e.g., price, dimensions, processor speed, etc.) of up to four catalog items.
Lookup Displays all of the data associated with a specified catalog item.
Search This operation takes a logical expression and searches the catalog according to that expression. It displays a list of all items that match the search expression.
CheckDelivery Returns the predicted delivery date for an item if ordered that day.
MakeVirtualOrder Reserves the number of items to be ordered by a customer and provides item information for the customer’s own procurement system.
about the design of the service operations and messages. Your aim should be to min- Figure 19.8 Functional descriptions of catalog imize the number of message exchanges that must take place to complete the service service operations request. You have to ensure that as much information as possible is passed to the service in a message rather than using synchronous service interactions. You should also remember that services are stateless and managing service- specific application state is the responsibility of the service user rather than the service itself. You may, therefore, have to pass this state information to and from services in input and output messages. There are three stages to service interface design:
1. Logical interface design, where you identify the operations associated with the service, their inputs and outputs and the exceptions associated with these operations. 2. Message design, where you design the structure of the messages that are sent and received by the service. 3. WSDL development, where you translate your logical and message design to an abstract interface description written in WSDL.
The first stage, logical interface design, starts with the service requirements and defines the operation names and parameters. At this stage, you should also define the exceptions that may arise when a service operation is invoked. Figure 19.8 and Figure 19.9 show the operations that implement the requirements and the inputs, out- puts, and exceptions for each of the catalog operations. At this stage, there is no need for these to be specified in detail—you add detail at the next stage of the design process. Defining exceptions and how these can be communicated to service users is par- ticularly important. Service engineers do not know how their services will be used.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.2 I Service engineering 523
gdIn size (cID) = 6 cID: string size (catNum) = 10 catNum: string numItems > 0 numItems: integer
gdOut size (catNum) = 10 catNum: string delivDate > Today delivDate: date
Invalid company id gdFault errCode = 1 errCode: integer Invalid catalog number errCode = 2 No availability errCode = 3 Zero items requested Figure 19.9 Catalog errCode = 4 interface design
It is usually unwise to make assumptions that service users will have completely understood the service specification. Input messages may be incorrect so you should define exceptions that report incorrect inputs to the service client. It is generally good practice in reusable component development to leave all exception handling to the user of the component. The service developer should not impose their views on how exceptions should be handled. Once you have established an informal logical description of what the service should do, the next stage is to define the structure of the input and output mes- sages and the types used in these messages. XML is an awkward notation to use at this stage. I think it is better to represent the messages as objects and either define them using the UML or in a programming language, such as Java. They can then be manually or automatically converted to XML. Figure 19.10 shows the structure of the input and output messages for the getDelivery operation in the catalog service. Notice how I have added detail to the description by annotating the UML diagram with constraints. These define the length of the strings representing the company and the catalog item, and specify that the number of items must be greater than zero and that delivery must be after the current date. The annotations also show which error codes are associated with each possible fault. The final stage of the service design process is to translate the service inter- face design into WSDL. As I discussed in the previous section, a WSDL repre- sentation is long and detailed and hence it is easy to make mistakes at this stage if you do this manually. However, most programming environments that support service-oriented development (e.g., the ECLIPSE environment) include tools that can translate a logical interface description into its corresponding WSDL representation.
www.Vidyarthiplus.com www.Vidyarthiplus.com
524 Chapter 19 I Service-oriented architecture
Operation Inputs Outputs Exceptions
MakeCatalog mcIn mcOut mcFault Company id URL of the catalog for Invalid company id PDF-flag that company
Compare compIn compOut compFault Company id URL of page showing Invalid company id Entry attribute (up to 6) comparison table Invalid catalog number Catalog number (up to 4) Unknown attribute
Lookup lookIn lookOut lookFault Company id URL of page with the Invalid company id Catalog number item information Invalid catalog number
Search searchIn searchOut searchFault Company id URL of web page with Invalid company id Search string search results Badly formed search string
CheckDelivery gdIn gdOut gdFault Company id Catalog number Invalid company id Catalog number Expected delivery date Invalid catalog number No availability Number of items required Zero items requested
PlaceOrder poIn poOut poFault Company id Catalog number Invalid company id Number of items required Number of items Invalid catalog number Catalog number required Zero items requested Predicted delivery date Unit price estimate Total price estimate
Figure 19.10 UML definition of input and output messages
19.2.3 Service implementation and deployment Once you have identified candidate services and designed their interfaces, the final stage of the service engineering process is service implementation. This implemen- tation may involve programming the service using a standard programming lan- guage such as Java or C#. Both of these languages include libraries with extensive support for service development. Alternatively, services may be developed by implementing service interfaces to existing components or, as I discuss below, to legacy systems. This means that software assets that have already proved to be useful can be made more widely available. In the case of legacy systems, it may mean that the system functionality can be accessed by new applications. You can also develop new services by defining compositions of existing services. I cover this approach to service development in Section 19.3. Once a service has been implemented, it then has to be tested before it is deployed. This involves examining and partitioning the service inputs (as explained
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.2 I Service engineering 525
in Chapter 8), creating input messages that reflect these input combinations, then checking that the outputs are expected. You should always try to generate exceptions during the test to check that the service can cope with invalid inputs. Testing tools are available that allow services to be examined and tested, and that generate tests from a WSDL specification. However, these can only test the conformity of the serv- ice interface to the WSDL. They cannot test that the service’s functional behavior. Service deployment, the final stage of the process, involves making the service avail- able for use on a web server. Most server software makes this very simple. You only have to install the file containing the executable service in a specific directory. It then automat- ically becomes available for use. If the service is intended to be publicly available, you then have to provide information for external users of the service. This information helps potential external users to decide if the service is likely to meet their needs and if they can trust you, as a service provider, to deliver the service reliably and securely. Information that you may include in a service description might be the following:
1. Information about your business, contact details, etc. This is important for trust reasons. Users of a service have to be confident that it will not behave mali- ciously. Information about the service provider allows them to check their credentials with business information agencies. 2. An informal description of the functionality provided by the service. This helps potential users to decide if the service is what they want. However, the func- tional description is in natural language, so it is not an unambiguous semantic description of what the service does. 3. A detailed description of the interface types and semantics. 4. Subscription information that allows users to register for information about updates to the service.
As I have discussed, a general problem with service specifications is that the func- tional behavior of the service is usually specified informally, as a natural language description. Natural language descriptions are easy to read, but they are subject to mis- interpretation. To address this problem, there is an active research community con- cerned with investigating how the semantics of services may be specified. The most promising approach to semantic specification is based on an ontology-based descrip- tion, where the specific meaning of terms in a description is defined in an ontology. Ontologies are a way of standardizing the ways that terminology is used and they define the relationships between different terms. They are becoming increasingly used to help assign semantics to natural language descriptions. A language called OWL-S has been developed for describing web service ontologies (OWL_Services_Coalition, 2003).
19.2.4 Legacy system services Legacy systems are old software systems that are used by an organization. Usually, they rely on obsolete technology but are still essential to the business. It may not be cost effective to rewrite or replace these systems and many organizations would like
www.Vidyarthiplus.com www.Vidyarthiplus.com
526 Chapter 19 I Service-oriented architecture
«service» «service» «service» Maintenance Facilities Logging
getJob addEquipment addRequest suspendJob deleteEquipment deleteRequest completeJob editEquipment queryRequests
Maintenance Support Figure 19.11 Services Legacy Application providing access to a legacy system
to use them in conjunction with more modern systems. One of the most important uses of services is to implement ‘wrappers’ for legacy systems that provide access to a system’s functions and data. These systems can then be accessed over the Web and integrated with other applications. To illustrate this, imagine that a large company maintains an inventory of its equipment and an associated database that keeps track of equipment maintenance and repairs. This keeps track of what maintenance requests have been made for dif- ferent pieces of equipment, what regular maintenance is scheduled, when mainte- nance was carried out, how much time was spent on maintenance, etc. This legacy system was originally used to generate daily job lists for maintenance staff but, over time, new facilities have been added. These provide data about how much has been spent on maintenance for each piece of equipment and information to help to cost maintenance work to be carried out by external contractors. The system runs as a client–server system with special-purpose client software running on a PC. The company now wishes to provide real-time access to this system from portable terminals used by maintenance staff. They will update the system directly with the time and resources spent on maintenance and will query the system to find their next maintenance job. In addition, call center staff require access to the system to log maintenance requests and to check their status. It is practically impossible to enhance the system to support these requirements so the company decides to provide new applications for maintenance and call center staff. These applications rely on the legacy system, which is to be used as a basis for implementing a number of services. This is illustrated in Figure 19.11, where I have used a UML stereotype to indicate a service. New applications exchange messages with these services to access the legacy system functionality. Some of the services provided are the following:
1. A maintenance service This includes operations to retrieve a maintenance job according to its job number, priority, and geographical location, and to upload details of maintenance that has been carried out to the maintenance database.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.3 I Software development with services 527
The service also provides operations that allow a maintenance job that has started but is incomplete to be suspended and restarted. 2. A facilities service This includes operations to add and delete new equipment and to modify the information associated with equipment in the database. 3. A logging service This includes operations to add a new request for service, delete maintenance requests, and query the status of outstanding requests.
Notice that the existing legacy system is not simply represented as a single serv- ice. Rather, the services that are developed to access the legacy system are coherent and support a single area of functionality. This reduces their complexity and makes them easier to understand and reuse in other applications.
19.3 Software development with services
The development of software using services is based around the idea that you com- pose and configure services to create new, composite services. These may be inte- grated with a user interface implemented in a browser to create a web application, or may be used as components in some other service composition. The services involved in the composition may be specially developed for the application, may be business services developed within a company, or may be services from an external provider. Many companies are now converting their enterprise applications into service- oriented systems, where the basic application building block is a service rather than a component. This opens up the possibility of more widespread reuse within the company. The next stage will be the development of interorganizational applications between trusted suppliers, who will use each other’s services. The final realization of the long-term vision of SOAs will rely on the development of a ‘services market’, where services are bought from external suppliers. Service composition may be used to integrate separate business processes to pro- vide an integrated process offering more extensive functionality. Say an airline wishes to provide a complete vacation package for travelers. As well as booking their flights, travelers can also book hotels in their preferred location, arrange car rentals or book a taxi from the airport, browse a travel guide, and make reservations to visit local attractions. To create this application, the airline composes its own booking service with services offered by a hotel booking agency, car rental and taxi companies, and reservation services offered by owners of local attractions. The end result is a single service that integrates the services from different providers. You can think of this process as a sequence of separate steps as shown in Figure 19.12. Information is passed from one step to the next—for example, the car rental company is informed of the time that the flight is scheduled to arrive. The sequence of steps is called a workflow—a set of activities ordered in time, with each activity carrying out some part of the work. A workflow is a model of a business
www.Vidyarthiplus.com www.Vidyarthiplus.com
528 Chapter 19 I Service-oriented architecture
Book Book Arrange Browse Book Flights Hotel Car or Taxi Attractions Attractions
Figure 19.12 Vacation Arrival/Departure Dates/Preferences package workflow Dates/Times Hotel Location
process (i.e., sets out the steps involved in reaching a particular goal that is important for a business). In this case, the business process is the vacation booking service, offered by the airline. Workflow is a simple idea and the above scenario of booking a vacation seems to be straightforward. In practice, service composition is much more complex than this simple model implies. For example, you have to consider the possibility of service failure and incorporate mechanisms to handle these failures. You also have to take into account exceptional demands made by users of the application. For example, say a traveler was disabled and required a wheelchair to be rented and delivered to the airport. This would require extra services to be implemented and composed, and additional steps to be added to the workflow. You must be able to cope with situations where the workflow has to be changed because the normal execution of one of the services usually results in an incompati- bility with some other service execution. For example, say a flight is booked to leave on June 1st and return on June 7th. The workflow then proceeds to the hotel booking stage. However, the resort is hosting a major convention until June 2nd, so no hotel rooms are available. The hotel booking service reports this lack of availability. This is not a failure; lack of availability is a common situation. You, therefore, then have to ‘undo’ the flight booking and pass the information about lack of availability back to the user. He or she then has to decide whether to change their dates or their resort. In workflow terminology, this is called a ‘compensation action’. Compensation actions are used to undo actions that have already been completed but which must be changed as a result of later workflow activities. The process of designing new services by reusing existing services is essentially a process of software design with reuse (Figure 19.13). Design with reuse inevitably involves requirements compromises. The ‘ideal’ requirements for the system have to be modified to reflect the services that are actually available, whose costs fall within budget and whose quality of service is acceptable. In Figure 19.13, I have shown six key stages in the process of service construction by composition: 1. Formulate outline workflow In this initial stage of service design, you use the requirements for the composite service as a basis for creating an ‘ideal’ service design. You should create a fairly abstract design at this stage with the intention of adding details once you know more about available services. 2. Discover services During this stage of the process, you search service registries or catalogs to discover what services exist, who provides these services, and the details of the service provision.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.3 I Software development with services 529
Formulate Create Discover Select Refine Test Outline Workflow Services Services Workflow Service Workflow Program
Workflow Service Workflow Executable Deployable Service List Design Specifications Design Workflow Service
3. Select possible services From the set of possible service candidates that you Figure 19.13 Service construction by have discovered, you then select possible services that can implement workflow composition activities. Your selection criteria will obviously include the functionality of the services offered. They may also include the cost of the services and the quality of service (responsiveness, availability, etc.) offered. You may decide to choose a number of functionally equivalent services, which could be bound to a work- flow activity depending on details of cost and quality of service. 4. Refine workflow On the basis of information about the services that you have selected, you then refine the workflow. This involves adding detail to the abstract description and perhaps adding or removing workflow activities. You may then repeat the service discovery and selection stages. Once a stable set of services has been chosen and the final workflow design established, you move on to the next stage in the process. 5. Create workflow program During this stage, the abstract workflow design is transformed to an executable program and the service interface is defined. You can use a conventional programming language, such as Java or C#, for service implementation or a workflow language, such as WS-BPEL. As I discussed in the previous section, the service interface specification should be written in WSDL. This stage may also involve the creation of web-based user interfaces to allow the new service to be accessed from a web browser. 6. Test completed service or application The process of testing the completed, composite service is more complex than component testing in situations where external services are used. I discuss testing issues in Section 19.3.2.
In the remainder of this chapter, I focus on workflow design and testing. In prac- tice, service discovery does not appear to be a major problem. It is still the case that most service reuse is within organizations, where services can be discovered using internal registries and informal communications between software engineers. Standard search engines may be used to discover publicly available services.
19.3.1 Workflow design and implementation Workflow design involves analyzing existing or planned business processes to understand the different activities that go on and how these exchange information.
www.Vidyarthiplus.com www.Vidyarthiplus.com
530 Chapter 19 I Service-oriented architecture
Retry
Cancel No rooms Hotels. NoAvailability Hotels. Hotels. GetRequirements CheckAvailability Hotels. Rooms OK ReserveRooms
Hotels. ConfirmReservation
Customer
You then define the new business process in a workflow design notation. This sets Figure 19.14 A fragment of a hotel out the stages involved in enacting the process and the information that is passed booking workflow between the different process stages. However, existing processes may be informal and dependent on the skills and ability of the people involved—there may be no ‘normal’ way of working or process definition. In such cases, you have to use your knowledge of the current process to design a workflow that achieves the same goals. Workflows represent business process models and are usually represented using a graphical notation such as UML activity diagrams or BPMN, the Business Process Modeling Notation (White, 2004a; White and Miers, 2008). These offer similar fea- tures (White, 2004b). I think it is probable that BPMN and UML activity diagrams will be integrated in the future and a standard for workflow modeling defined will be based on this integrated language. I use BPMN for the examples in this chapter. BPMN is a graphical language that is reasonably easy to understand. Mappings have been defined to translate the language to lower-level, XML-based descriptions in WS-BPEL. BPMN is therefore conformant with the stack of web service stan- dards that I showed in Figure 19.2. Figure 19.14 is an example of a simple BPMN model of part of the above vaca- tion package scenario. The model shows a simplified workflow for hotel booking and assumes the existence of a Hotels service with associated operations called GetRequirements, CheckAvailability, ReserveRooms, NoAvailability, Confirm- Reservation, and CancelReservation. The process involves getting requirements from the customer, checking room availability, and then, if rooms are available, mak- ing a booking for the required dates. This model introduces some of the core concepts of BPMN that are used to create workflow models:
1. Activities are represented by a rectangle with rounded corners. An activity can be executed by a human or by an automated service.
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.3 I Software development with services 531
2. Events are represented by circles. An event is something that happens during a business process. A simple circle is used to represent a starting event and a darker circle to represent an end event. A double circle (not shown) is used to represent an intermediate event. Events can be clock events, thus allowing workflows to be executed periodically or timed out. 3. A diamond is used to represent a gateway. A gateway is a stage in the process where some choice is made. For example, in Figure 19.14, there is a choice made on the basis of whether rooms are available or not. 4. A solid arrow is used to show the sequence of activities; a dashed arrow repre- sents message flow between activities. In Figure 19.14, these messages are passed between the hotel booking service and the customer.
These key features are enough to describe the essence of most workflows. However, BPMN includes many additional features that I don’t have space to describe here. These add information to a business process description that allows it to be automatically translated into an executable service. Therefore, web services, based on service compositions described in BPMN, can be generated directly from a business process model. Figure 19.14 shows the process that is enacted in one organization, the company that provides a booking service. However, the key benefit of a service-oriented approach is that it supports interorganizational computing. This means that a compu- tation involves services in different companies. This is represented in BPMN by developing separate workflows for each of the organizations involved with interac- tions between them. To illustrate this, I use a different example, drawn from high-performance com- puting. A service-oriented approach has been proposed to allow resources such as high-performance computers to be shared. In this example, assume that a vector processing computer (a machine that can carry out parallel computations on arrays of values) is offered as a service (VectorProcService) by a research laboratory. This is accessed through another service called SetupComputation. These services and their interactions are shown in Figure 19.15. In this example, the workflow for the SetupComputation service requests access to a vector processor and, if a processor is available, establishes the computation required and downloads data to the processing service. Once the computation is complete, the results are stored on the local computer. The workflow for VectorProcService checks if a processor is available, allocates resources for the computation, initializes the system, carries out the computation, and returns the results to the client service. In BPMN terms, the workflow for each organization is represented in a separate pool. It is shown graphically by enclosing the workflow for each participant in the process in a rectangle, with the name written vertically on the left edge. The work- flows defined in each pool are coordinated by exchanging messages; sequence flow between the activities in different pools is not allowed. In situations where different parts of an organization are involved in a workflow, this can be shown by
www.Vidyarthiplus.com www.Vidyarthiplus.com
532 Chapter 19 I Service-oriented architecture
Restart No Processor Fail Request Setup Job Download Start Processor Parameters Data Computation OK OK
Setup Computation Store Report Results Completion
Check Allocate Initialize Compute Availability Resources
Return Results VectorProcService
separating pools into named ‘lanes’. Each lane shows the activities in that part of Figure 19.15 Interacting workflows the organization. Once a business process model has been designed, this has to be refined depend- ing on the services that have been discovered. As I suggested in the discussion of Figure 19.13, the model may go through a number of iterations until a design that allows the maximum possible reuse of available services has been created. Once the final design is available, it must then be converted to an executable pro- gram. This may involve two activities:
1. Implementing the services that are not available for reuse. As services are implementation-language independent, these services can be written in any lan- guage. Both Java and C# development environments provide support for web service composition. 2. Generating an executable version of the workflow model. This normally involves translating the model into WS-BPEL, either automatically or by hand. Although there are several tools available to automate the BPMN-WS-BPEL process, there are some circumstances where it is difficult to generate readable WS-BPEL code from a workflow model.
To provide direct support for the implementation of web service compositions, several web service standards have been developed. As I explained in the chapter introduction, the standard XML-based language is WS-BPEL (Business Process Execution Language) which is a ‘programming language’ to control interactions
www.Vidyarthiplus.com www.Vidyarthiplus.com
19.3 I Software development with services 533
between services. This is supported by additional standards such as WS- Coordination (Cabrera et al., 2005), which is used to specify how services are coor- dinated, and WS-CDL (Choreography Description Language) (Kavantzas et al., 2004), which is a means of defining the message exchanges between participants (Andrews et al., 2003).
19.3.2 Service testing Testing is important in all system development processes as it demonstrates that a system meets its functional and non-functional requirements and to detect defects that have been introduced during the development process. Many testing techniques, such as program inspections and coverage testing, rely on analysis of the software source code. However, when services are offered by an external provider, source code of the service implementation is not available. Service-based system testing cannot therefore use proven source code–based techniques. As well as problems of understanding the implementation of the service, testers may also face further difficulties when testing services and service compositions:
1. External services are under the control of the service provider rather than the user of the service. The service provider may withdraw these services at any time or may make changes to them, which invalidates any previous application testing. These problems are handled in software components by maintaining different versions of the component. Currently, however, there are no standards proposed to deal with service versions. 2. The long-term vision of SOAs is for services to be bound dynamically to service-oriented applications. This means that an application may not always use the same service each time that it is executed. Therefore, tests may be successful when an application is bound to a particular service, but it cannot be guaranteed that that service will be used during an actual execution of the system. 3. The non-functional behavior of a service is not simply dependent on how it is used by the application that is being tested. A service may perform well during testing because it is not operating under a heavy load. In practice, the observed service behavior may be different because of the demands made by other serv- ice users. 4. The payment model for services could make service testing very expensive. There are different possible payment models—some services may be freely available, some paid for by subscription, and others paid for on a per-use basis. If services are free, then the service provider will not wish them to be loaded by applications being tested; if a subscription is required, then a service user may be reluctant to enter into a subscription agreement before testing the service. Similarly, if the usage is based on payment for each use, service users may find the cost of testing to be prohibitive.
www.Vidyarthiplus.com www.Vidyarthiplus.com
534 Chapter 19 I Service-oriented architecture
5. I have discussed the notion of compensation actions that are invoked when an exception occurs and previous commitments that have been made (such as a flight reservation) have to be revoked. There is a problem in testing such actions as they may depend on the failure of other services. Ensuring that these services actually fail during the testing process may be very difficult.
These problems are particularly acute when external services are used. They are less serious when services are used within the same company or where cooperating com- panies trust services offered by their partners. In such cases, source code may be available to guide the testing process and payment for services is unlikely to be a problem. Resolving these testing problems and producing guidelines, tools, and tech- niques for testing service-oriented applications remains an important research issue.
K E Y P O I N TS
I Service-oriented architecture is an approach to software engineering where reusable, standardized services are the basic building blocks for application systems. I Service interfaces may be defined in an XML-based language called WSDL. A WSDL specification includes a definition of the interface types and operations, the binding protocol used by the service and the service location. I Services may be classified as utility services that provide a general-purpose functionality, business services that implement part of a business process, or coordination services that coordinate the execution of other services. I The service engineering process involves identifying candidate services for implementation, defining the service interface and implementing, and testing and deploying the service. I Service interfaces may be defined for legacy software systems that continue to be useful for an organization. The functionality of the legacy system may then be reused in other applications. I The development of software using services is based around the idea that programs are created by composing and configuring services to create new composite services. I Business process models define the activities and information exchange that takes place in a business process. Activities in the business process may be implemented by services so that the business process model represents a service composition.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Service composition
Definition
A service composition is an aggregate of services collectively composed to automate a particular task or business process. To qualify as a composition, at least two participating services plus one composition initiator need to be present. Otherwise, the service interaction only represents a point-to-point exchange.
Service compositions can be classified into primitive and complex variations. In early service-oriented solutions, simple logic was generally implemented via point-to-point exchanges or primitive compositions. As the surrounding technology matured, complex compositions became more common.
Much of the service-orientation design paradigm revolves around preparing services for effective participation in numerous complex compositions. So much so that the Service Composability design principle exits, dedicated solely to ensuring that services are designed in support of repeatable composition.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Service composition means composing a larger service by combining many smaller services. This is the same principle used when composing a larger software component from many smaller components. Here is a diagram illustrating service composition:
Service Composition - composing a service by combining several smaller ones.
Service Composition Performance
While service composition may look compelling on paper, just like component composition would, keep in mind that services typically communicate with each other via the network. That means that inter-service communication is much slower than typical inter-component communication, which typically takes place inside the same address space (application / process). Decomposing your larger services into too many smaller services may hurt performance. Especially if the services communicate internally via an enterprise service bus (ESB).
Introduction
The majority of SOA publications are concentrating on definition and implementations of the individual business services. Building enterprise solution(s) typically requires combining multiple existing enterprise services. These composite services can be in turn recursively composed with other services into higher level solutions, and so on. Such recursive composition of business services is one of the most important features of SOA, allowing to rapidly build new solutions based on the existing business services. As the amount of individual business services (and their compositions) grows, the easier it becomes to implement new enterprise solutions.
Services-oriented architecture (SOA) aims to provide a loosely-coupled integration of services residing on different systems, written using different programming languages and with other implementation disparities. Popularly considered as the building block of
www.Vidyarthiplus.com www.Vidyarthiplus.com
SOA, Web services (WS) are self-describing and platform-independent applications that can be invoked over the Web. Facilitating the assembly of services to form composite services is an important functionality in SOA. The problem of automatically assembling WSs to form compositions that optimize given user preferences is often referred to as the automated Web service composition problem. It involves two major challenges each with its own attendant issues:
1. automatically construct the control flow of the composition and 2. appropriately resolve the data heterogeneity between WSs participating in the composition.
The main drivers for the creation of composite-services, as defined in Toward a pattern language for Service-Oriented Architecture and Integration, are:
• Usage simplicity. When several business services are used together by multiple consumers, exposing knowledge about all participating services and their coordination rules to every consumer can make consumer implementation more complex. Creation of composite service, both encapsulating participating services and enforcing the rules of their invocation can significantly simplify their usage. • Improved reusability. New unplanned solutions can often be assembled from available services. Even though they have been designed for the construction of a specific set of solutions, existing business services can be combined in other ways to implement solutions that had not been anticipated. In addition, the availability of services suggests new solutions that might otherwise not be considered. These new solutions can often be created inexpensively and quickly through development or enhancement of relatively few services. • Solution partitioning, visibility, control and change management. Composite services can serve as a partitioning mechanism for overall solution. Similar to the case of local and remote interfaces in EJBs, introducing composite services and exposing only some of their interfaces to external users allows to control what is
www.Vidyarthiplus.com www.Vidyarthiplus.com
visible to the consumer. This supports the ability of underlying software architectures (composite services implementations) to rapidly respond to changing requirements by changing the implementations of its subordinate services, as well as the interconnection between them with minimal or no impact to the consumers.
There are two aspects of composition (as defined in Tools for Composite Web Services: A Short Overview): composition design concerned with synthesizing a specification of how to coordinate the component services to fulfill the client request; and composition implementation, concerned with how to actually achieve the coordination among services, by executing the specification produced by the composition design. In this article we will discuss the main approaches to service composition, both from design and implementation point of view.
Composition Design
Composition design is concerned with designing a solution based on a set of existing services. Its role is to specify a list of services involved in a composition, and the way they interact and the composition topology.
Service interactions There are two major design approaches to the composition interactions according to "Service–Oriented Composition in BPEL4WS":
• Hierarchical composition. • Conversational composition.
In case of hierarchical composition, the implementation of composite service is completely opaque to the service consumer (black box). A consumer invokes this type of composite service, waits until its execution completes and uses the results (either directly or in a form of side effects) of its execution (Figure 1).
Figure 1 Hierarchical service composition
This composition approach is a natural fit for implementing systems, based on the hierarchical decomposition. Every level of hierarchy is implemented as an independent composite service, coordinating execution of lower level (composite) services. It is also
www.Vidyarthiplus.com www.Vidyarthiplus.com
a common way of modeling high level solutions in workflow systems by composing a series of activities, each of which may correspond to a lower level business process, or a task to be performed by a person or a program. While any composite service may be monitored or interrupted by the outside system using it, it does not support any other functional interactions1 with the service consumer except for an original invocation.
Although the black box composition approach (hierarchical composition) is a very powerful way of dealing with complexities, there are situations when a consumer needs to control execution of the composite service based on the intermediate execution results of service execution. Such an implementation is supported by conversational composition. In this case the implementation of the composite service is also completely opaque to the service consumer, but selected intermediate execution results are exposed (grey box).
This is achieved by supporting an explicit conversation state (see [4] for distinctions between conversational and execution state) by composite service and exposing multiple interfaces to a service consumer – one for the initial service invocation and others to get intermediate results and control execution based on them (Figure 2)
Figure 2 Conversational service composition
In this type of composition, the interacting consumer and provider are viewed as peers, exchanging data and control signals.
Both interaction styles are viable ways of compositions design. Usage of a strict hierarchy is a useful approach for modeling of complex business processes, as demonstrated by the success of workflow technology. Conversations, on the other hand, have an expressiveness that makes it easy to capture common business interactions – the acts of negotiation, monitoring of results, and so on – through explicitly modeling the message interactions between a consumer and a service.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Composition topologies
The design of composite services does not only require the definition of the service interactions, but also a set of components and topologies for their implementation. There are two major design approaches to composite service topologies ("Service– Oriented Composition in BPEL4WS"):
• Mediator-based • Peer-to-Peer
Mediator-based topology (Figure 3) assumes a single service, called the mediator, which has the specialized role of interacting with the service consumer and controlling the execution of the other services (component services) participating in composition.
Figure 3 Mediator-based composition topology
In the case of mediator-based hierarchical services, the mediator implements an orchestration schema that defines invocation sequence of component services in order to achieve a specified goal within specified constraints. Different approaches, including orchestration language/engine, OWL-S compositions, Petri nets, etc. can be used for mediator implementation.
In the case of mediator-based conversational services, the mediator implements service states and states transitions, based on the consumer inputs. A typical implementation of the mediator is based on the transition systems or finite state machines.
In the case of peer-to-peer topology there is no notion of a mediator service. Every participating service (component service) can execute (partial) composite service (Figure 4).
www.Vidyarthiplus.com www.Vidyarthiplus.com
Figure 4 Peer-to-peer composition topology.
A composition, in this case, is defined as a messaging template and component services can be plugged into it. The target behavior is specified as a family of permitted message exchange sequences, which should be realized by the system. Typically this topology is used only for the implementation of the hierarchical services due to the lack of mechanisms required for support of the conversational state (requirement for conversational interactions implementation).
Composition implementation choices
It seems like the simplest way to implement a service mediator is to use a general purpose programming language (Figure 5).
Figure 5 Programmatic implementation of composite service
Unfortunately, this solution suffers from multiple drawbacks:
• It creates a fairly rigid implementation by hard-coding orchestration aspects of the composite service. Any change to composite service requires explicit reprogramming of the service mediator. • This approach often leads to "services spaghetti" implementations, where services start invoking other services in ad-hoc fashion. "Services spaghetti" usually creates tight coupling between service implementations. The network nature of services invocation and disparate teams, developing different services,
www.Vidyarthiplus.com www.Vidyarthiplus.com
typically leads to situations where "services spaghetti" become impossible to maintain. • Requirements to implement conversational composite service and synchronization of asynchronously invoked services make the overall implementation significantly more complex, requiring threading support in the composite applications. Requirements to support service context usually require creation of a specialized database for every composite service to support service context. • The composite services implementation requires implementation of some form of transactional support to ensure correct behavior in the case of failures of participating services.
Despite the fact that there are several frameworks for the implementation of composite service (for example, WS-CAF), the programmatic implementation of composite services does not seem to be the right approach.
Another possible approach to the implementation of composite services is event-based composition. This composition implementation is based on event-based service interactions: service consumers publish events to the publish/subscribe intermediary, which delivers them to the actual service consumers (Figure 6).
Figure 6 Service interaction through Pub/Sub
In this case, the pub/sub engine, as any intermediary, provides a decoupling layer between service consumers and providers, which allows for extremely flexible implementation of composite services. The composite service can be implemented as follows (Figure 7):
Figure 7 Implementing composite service using events
www.Vidyarthiplus.com www.Vidyarthiplus.com
The service consumer sends the initiating event that is delivered (through the pub/sub engine) to a set of services that have subscribed to this event. Every service can, in turn, send another message, which will invoke (through the same pub/sub engine) yet another set of services. This sequence of events effectively creates a composite service. The implementation of composite services through pub/sub has the following characteristics:
• It is significantly more flexible, compared to programmatic implementation. By changing a set of services, subscribed to a particular topic, it is possible to completely change implementation of composite services. Alternatively the same can be achieved by changing the topic to which consumer sends the original event. • Events-based implementation does not provide a well defined place for the composite service context. This makes an implementation of composite services more complex. One of the solutions is to attach the context data to the events content, which usually makes messages larger, which usually leads to increased network usage and performance degradation. • Events-based implementation does not provide the notion of the composite service instance, which makes it very difficult to coordinate events, implementing a composite services instance. • This also makes it very difficult to implement any form of transactional support to ensure correct behavior in the case of failures of participating services.
Further improvements of composite service implementation can be achieved through usage of an orchestration engine for implementation of service mediator (Figure 8).
Figure 8 Implementing composite service using orchestration engine
This implementation improves the programmatic implementation by using orchestration language instead of general programming language for composition implementation. This allows programming/maintaining composition logic using visual editors, tailored specifically to simplify this kind of programming. It also allows utilizing the power of orchestration engines providing built-in capabilities for asynchronous invocations, state
www.Vidyarthiplus.com www.Vidyarthiplus.com
management, compensation support, etc. Usage of orchestration engines for composite services implementation provides the following advantages:
• An orchestration language is better suited for implementation of the orchestration, which usually simplifies composite service implementation. • Additional programming simplification can be achieved through usage of a visual editor. • An orchestration engine natively supports orchestration instances and context, required for implementation of composite services • Compensation support, implemented in the orchestration languages, makes transactional support implementation significantly simpler.
Based on the above, out of the three discussed approaches, the orchestration-based implementation seems to be the most viable way for creation of the composite services.
Conclusion
Service composition plays a significant role in SOA implementations by providing the following benefits:
• Improved reusability. The composite service provides a natural way of reusing existing services. It allows service providers to add value through service composition. • Faster time to market. New solutions can be constructed more quickly. The existence of services at many levels (assuming they are composable) along with a mechanism for combining and managing them allows new services and solutions to be constructed with less time and effort. In particular, operating prototypes can be assembled quickly from existing production quality services. • Improved security and auditability. The composite service represents a single point of access to the set of underlying services. This single point of access provides a simple way of enforcing service invocation contracts, allowing for controlling and metering the access to the component services. • Lower duplication. Redundancy is reduced or eliminated. Instead of replicating the same business functionality multiple times, a single business service that implements required functionality can be reused in multiple compositions. • Improved modifiability. Because the same underlying service can be part of many composite services there is a single place for modifications of the functionality throughout the enterprise. Changes to the component service implementation are available to all consumers using this service.
The different design approaches for composite services described in this article are targeted to a variety of business scenarios and allow designing composite services (and their topology) to specify service composition best suited for specific business needs.
www.Vidyarthiplus.com www.Vidyarthiplus.com
choreography and orchestration choreography
Service choreography is a form of service composition in which the interaction protocol between several partner services is defined from a global perspective. The intuition underlying the notion of service choreography can be summarized as follows:
“Dancers dance following a global scenario without a single point of control"
That is, at run-time each participant in a service choreography executes its part of it (i.e. its role) according to the behavior of the other participants. A choreography's role specifies the expected messaging behavior of the participants that will play it in terms of the sequencing and timing of the messages that they can consume and produce.
As we know that Web Services are actually application components each of which normally performs one discrete functionality of the overall application. So, we definitely need some way of combining these individual components to make the entire application work. There are two popular ways of combining Web Services, which are:-
• Orchestration - we have a central controller in this case and it can be executed • Choreography - we don't have any controller here and it can't be executed directly
www.Vidyarthiplus.com www.Vidyarthiplus.com
Orchestration
In this case we have a central controller process which controls and co-ordinates all the Web Services involved in the application. This central process can be a Web Service a well. The point to note in this case is that all other Web Services don't really know that they are participating in a higher-level business process. How the participating Web Services will be called, what will be the control flow, what all transformation will take place, ... these all things are known only to the central controller process. The other Web Services simply honor the requests whenever called. The below diagram makes it quite easier to understand the overall process.
Since Orchestration provides a controlled environment hence alternative scenarios can be used in case a fault occurs in the normal flow. For example, suppose we need to call a Web Service which may result into fault and in such a case we may need to either call another Web Service OR to simply use a default value. IN case of Orchestration it's very easy to achieve - maybe by just having a switch activity to transfer the control either to the alternative Web Service OR to compute the required Default Value.
Orchestration requires a conductor. The conductor directs the orchestra during the performance.
Choreography is the process of agreeing, between the dancers, how a dance will be performed before it is performed. We don't stop during the performance of the dance to discuss alternative moves and we don't take instruction from a conductor during the dance. We listen to the music and we follow the choreography that we agreed. Importantly, if there even is an autocratic choreographer that person might even be dead during the actual performance. Likely as not the performance will differ in very subtle ways from what has been agreed. The choreography has to have built in tolerance for those differences.
We have this same idea of choreography in service orientation. Choreography means to encode in our services what the other dancers in the performance are or are doing, directly, before we perform the dance of live runtime.
When we change the dance, when we change the services that we co-operate with, we can't do that as we dance. We have to stop the dance, change the choreography, maybe practice a bit, and then start dancing again. We start a new form of the dance instead of trying to improvise the dance as we go along. Improvising might work if there are only a few participants... but if there's a whole marching band you better be sure they all know what they're doing before they start.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Choreography
Here we don't have any central controller process and hence all the participating Web Services know when to call, whom to interact, when to execute operations, etc. We can visualize choreography just like a collaborative effort of many participating Web Services and since we don't have any controller hence all the Web Services need to know the actual business process and things involved in it like message exchanges, time of call, etc. Find below a diagram depicting a typical Choreography process.
Service Orchestration and SOA
SOA, or Service Oriented Architecture, is an approach to developing enterprise systems by loosely coupling interoperable services - small units of software that perform discrete tasks when called upon - from separate systems across different business domains. SOA emerged in the early 2000s, offering IT departments a way to develop new business services by reusing components from existing programs within the enterprise rather than writing functionally redundant code from scratch and developing new infrastructures to support them. With SOA, functionalities are expressed as a collection of services rather than a single application, marking a fundamental shift in how developers approach enterprise architecture design.
A crucial aspect of SOA is service orchestration. As this article will show, enterprise systems and integration projects designed according to SOA principles depend on successful service orchestration. Finding a platform with enhanced service orchestration capabilities, then, is a high priority for enterprises looking to build their systems according to SOA.
Service Orchestration: Making SOA Work
Similar to an organizational workflow, service orchestration is the coordination and arrangement of multiple services exposed as a single aggregate service. Developers utilize service orchestration to support the automation of business processes by loosely coupling services across different applications and enterprises and creating “second- generation,” composite applications. In other words, service orchestration is the combination of service interactions to create higher-level business services.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Service orchestration works through the exchange of messages in the domain layer of enterprise applications. Since individual services are not programmed to communicate with other services, messages must be exchanged according to a predetermined business logic and execution order so that the composite service or application can run as it is demanded by the end-user. This is usually accomplished through enterprise application integration (EAI), which enables data integration, and the use of a central messaging engine such as an enterprise service bus (ESB), which routes, transforms and enriches messages.
Related to service orchestration is service choreography. Though both are employed to create composite services and applications in service oriented architectures, it it is worth pointing out the differences. A service choreography model works without a central messaging engine or orchestrator while a service orchestration model relies on a central controller to couple services. In the former, the participating services each know the business logic and sequence and timing of message exchanges. In the latter, the participating services don’t know that they are being orchestrated as part of a higher- level service; only the central controller knows the business logic and messaging sequence.
To get a better sense of service orchestration, let’s take a look at the following example. A loan broker wants to make a loan request on behalf of a customer and uses an automated Loan Request Service. The broker accesses the Loan Request Service in the enterprise system to make the initial loan request, which is sent to an orchestrator (the central messaging engine) that then calls and invokes other services in the enterprise, partner systems and/or the cloud to process that request. The individual sub- services involved in the loan request include a service to obtain credit scores from a credit agency, a service to retrieve a list of lenders, a service to request quotes from a bank service, and a service to process quotes with the data from the other services. Together, the orchestrated services comprise the Loan Request Service, which then returns a list of quotes from potential lenders to the broker who made the original request.
As the above example illustrates, service orchestration is a fundamental aspect of successfully implementing SOA. In a truly service oriented architecture, new applications are created by new orchestrations of existing services - not by writing new code.
The Challenges of Service Orchestration and SOA
From the surface, service orchestration and SOA are relatively simple concepts. For enterprises faced with integration challenges, skyrocketing IT budgets and increasingly complex infrastructures, building new applications with granular and reusable software components is an understandably attractive approach to creating more agile and competitive systems and reducing time to market.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Service orchestration and SOA, however, can be difficult to achieve without the right set of tools. In its early days, CTOs of large companies eagerly adopted SOA and went about implementing it with a rip and replace model. Such an approach resulted in high financial costs as well as major time investments since it often required developers to orchestrate services programmatically (i.e. write new code), defeating the ultimate purpose of adopting SOA.
What was needed was a simpler and more flexible way to perform service orchestrations and implement SOA. The enterprise service bus (ESB) emerged as the go-to mechanism for service orchestration and SOA.
You are under pressure to deliver applications and IT services quicker and more efficiently. Competitive pressures and the accelerating pace of business no longer allow for time-consuming, siloed, manual processes. Increasingly users expect the same levels of service in their business lives that they can get in their personal lives. They expect to be able to go online, request a new application or compute resource, and receive it in a matter of minutes, not days or weeks. When IT fails to deliver this level of service, businesses look for alternatives that will give them what they need now.
Automic Service Orchestration fully orchestrates the delivery of complex services allowing users to request services from a self service portal and then orchestrating the provisioning, updating, changing and de-provisioning of service components across business, application and infrastructure layers whether on-premise, hybrid, or in the cloud. Unlike alternatives, which are best suited to greenfield data centers, Automic Service Orchestration allows companies to evolve their existing data centers to private clouds by integrating their existing investments in IT tools rather than require a rip and replace.
• Automic Service Catalog – Allow users to request and monitor the delivery of complex service offerings from a single self-service portal • Web Services Integration – Utilize existing Self Service Portals, Service Catalogs and Workflow investments such as ServiceNow, BMC Remedy, HP Service Manager, CA Service Desk • Service Blueprints – Decouple service definitions from underlying architecture and easily offer many services variants and rapidly add or modify automation processes • Object Orientated Architecture – Create standardized service offerings quickly from a library of existing service components and allow parameters, tasks, processes to be modified during runtime • Resource Pooling and Allocation – Intelligently place services based on security, resiliency and resource usage based on real-time availability and capacity • Provision, Update, Change, De-provision a Full Stack Service – Leverage existing investments in your trusted virtualization and automation tools. • Integration with Existing IT Service Management Tools – Ensure service delivery adheres to change, configuration and incident management processes
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Analytics and Reporting – Easily analyze requests, report on SLA compliance, resource optimization and charge/show back
Using the Right Platform for Service Orchestration and SOA
ESBs and other integration platforms make the service orchestration process much simpler and eliminate the need for custom coding. ESBs enable enterprise application integration (EAI) and act as orchestrators by allowing services to communicate with each other.
Open source ESBs such as Mule offer unparalleled interoperability and flexibility by making it possible to reuse service components of any type and exchange messages of any format both within the enterprise and without. In fact, the most recent version of Mule ESB has made it easier to perform service orchestration by introducing a new way to combine services with its Flow feature. Mule Flow allows you to pick and choose components to generate a linear flow of message processes and create a composite service in an intuitive way.
With the right platform, SOA delivers on its promises to align business processes with IT systems and reduce costs while remaining agile and robust enough to handle changes in customer demands and the integration of new applications. When the composition of new business services is made simple and intuitive, SOA can be successfully adopted - one service orchestration at a time.
Service Orchestration Guidelines
In my opinion, Service Orchestration is an automated way to combine several services together to achieve new functionality. The end result is a new composite service that provides a distinct business capability and can be invoked independently. Orchestration is a technology independent concept. It can be achieved via a descriptive language such as BPEL, built-in tools within a specific platform (ESBs typically provide their own orchestration mechanisms), or programmatically. Depending on your needs, situation, or technology available, the best way to perform service orchestration may be different. Here are a few guidelines to help you create service orchestrations faster and make them more flexible, maintainable, and scalable.
• Use the platform with built-in orchestration capabilities as your first choice • Avoid implementing service orchestrations programmatically whenever possible • Choose a platform or mechanism that can easily perform flow logic, result aggregation, message transformation, and business rule application
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Ensure the composite service fits the definition of a service, i.e. has all the attributes of a service
The rationale behind the above guidelines is very simple. You want to choose a platform that already provides most of the capabilities you will need when creating new service orchestrations. You will typically need to call several services, aggregate their results in some way or chain the calls together through some kind of logic, transform the end result to match the exposed contract(s), and return it. The less work you have to do and the more you can rely on the platform’s capabilities, the more efficient your orchestration will be. If you can complete your orchestration work through a visual interface and never see the code, you are on the right path. This way, you will spend less time maintaining the orchestration, it will be easier to make changes, and you don’t have to build all the necessary mechanisms from scratch.
Many would argue that a programming language will give you the most flexibility when implementing an orchestration. While this is true, the overhead is pretty large and efficiency is low. First of all, no programming language seamlessly integrates all the mechanism you need to create an orchestration, especially in a visual way. Secondly, every time an orchestration needs to change in some way, no matter how small, new code needs to be written, deployed, and tested. While the same steps need to be performed on any orchestration platform, the level of effort will be a lot smaller on full featured orchestration platforms.
When creating service orchestrations, it is important to maintain proper relationships between composite and atomic services. The diagram below shows which services should be allowed to interact with each other.
The following list details the rules and guidelines for establishing relationships between composite and atomic services.
1. Atomic business services should not call each other. Use orchestration to combine several business services together. The goal of service orchestration is to combine several services together through a series of logical steps and expose new capability to the consumers. Orchestration platforms, as discussed above, provide a lot of functionality to make this work easy and efficient. If individual services are allowed to call each
www.Vidyarthiplus.com www.Vidyarthiplus.com
other, they would not be taking advantage of the orchestration platform’s capabilities. Furthermore, when business services call each other, it establishes a tight coupling between them, which makes them less reusable and harder to maintain. Atomic business services should provide specific, well defined business capabilities and be reusable in their own right. Reliance on other services to complete work indicates plurality of purpose and lack of specificity. 2. Business services can call Utility services. While coupling services together should be avoided as much as possible, sometimes generic, low level functionality that needs to be invoked from a business service is exposed via utility services. It would be an overkill and sometimes even impossible to use an orchestration platform in order to allow business services to take advantage of such functionality as logging, retrieving or storing configuration information, and authorization. 3. Utility services cannot call Business services. Utility services should not be tied to any business processes or capabilities. Thus, a utility service calling a business service would violate this rule. 4. Business services cannot call Composite services. The logic behind this guideline is the same as in disallowing business services call each other. A composite service is also a business service. Thus, a business service calling a composite service should not be allowed. 5. Composite services can call other Composite services. Other composite services are allowed to participate in orchestrations. They should be treated as regular atomic services in this case.
Note that, even though atomic business services and composite services are, in essence, business services, they are different and guidelines provided above are not contradictory in their treatment. There are two levels at which they should be compared -- logical and physical. From a logical perspective, atomic business services and composite services are the same. They expose some kind of unique business capability and adhere to the service definition guidelines. From a physical perspective, however, they are different. Atomic business services, as opposed to composite services, rely solely on internal business logic and direct interaction with backend data sources to perform their work. Thus, by definition, atomic business services should not call other business services as part of their implementation. By the same token, since composite services already rely on other business services to complete their work, they should not differentiate between calling atomic business services or other composite services.
Orchestration vs Choreography
Orchestration has a central controller process and all other participating Web Services don't know about the actual business process. They are called only by the controller process and they don't know anything about other Web Services involved in the application. Whereas Choreography doesn't have any controller process/service and all the participating Web Services know the actual business process and they are well aware of which all Web Services they need to interact with, when to execute the operations, etc.
www.Vidyarthiplus.com www.Vidyarthiplus.com
So, we can say that Orchestration is a controlled and co-ordinate way of utilizing the services of all the participating Web Services whereas Choreography is just a collaborative effort of utilizing the services of the participating Web Services.
Fault handling is easier in Orchestration as the execution is controlled which is not the case with Choreography. Web Services can be easily and transparently replaced in case of Orchestration as the involved Web Services don't know the actual business process whereas it'll be difficult in case of Choreography.
Thus, we see that Orchestration is having quite a few advantages over Choreography and hence Orchestration is normally preferred for business process implementations, but Choreography may certainly have its own usage in some selected scenarios.
Choreography - the art of symbolically representing dancing:
• the composition and arrangement of dances especially for ballet • a composition created by this art
Orchestration - the arrangement of a musical composition for performance by an orchestra; also: orchestral treatment of a musical composition
Orchestrations describe what an overall process appears to do without specifying how any of it is implemented.
I view choreography as a form of peer-to-peer interaction because there is no "conductor". The choreography is an agreed-upon model for interactions that may consist of a series of orchestrations.
Orchestrations are "fixed" in that there is a described set of steps and decisions. Choreographies, should be, more goal oriented and be about the co-ordination of resources towards that goal
Given the description above, it is readily apparent that Orchestration and Choreography have quite different characteristics and uses.
Orchestration:
• The composite application exists within a single ownership domain, so security of the composite application is less complex • The organization can count on a given level of performance and can increase the performance with additional investments in its own service components and systems • The organization can count on a given level of reliability
www.Vidyarthiplus.com www.Vidyarthiplus.com
• There is stability in the operation of the system from the users' perspective (it does the same thing the same way all the time). • If there are defects, the sub-organization responsible for the composite application can correct it without (formal or informal) contract negotiations. • If new technology should be inserted into one or more service components, the organization owning the composite application can implement it without reference other organizations.
Consequently, organization's should always implement composite applications supporting "business critical" processes and functions using orchestration.
Choreography:
• The composite application exists across two or more ownership domains, so that in teaming, sub-contracting, and similar situations the dynamic linkage of Choreography is very helpful. • If there is a highly specialized service component that is required to perform a particular function, then choreography is preferred. • In intelligence gathering situations • In non-core "business" functions. For example, if you are the business of manufacturing ice cream cakes, then having a full time HR function, or even accounting function may not be cost efficient and is not part of the core functions of the organization. Instead, they are sustaining functions, which can be outsourced. In smaller businesses, linking to outside HR and Accounting functions for various services may, likewise, be sensible. • Finally, if service components are treated as "apps for applications" then many of the benefits are the same as for end-user using "apps" on their wireless device.
The problem with choreography is that it is not within the control of the organization wanting to use it. Consequently:
• It can't control the policies and standards used within the service component(s) that are outside its ownership domain; it can only contract for its use. This means that it has little power to audit the service component other than for the contractual obligations, such as Service Level Agreements (SLAs). • The standards and policies to which the services are built may change, so that a customer organization may need to either change it interface, wavier one or more of its policies and standards, or discover a new service.
www.Vidyarthiplus.com www.Vidyarthiplus.com
UNIT V - USER CENTERED DESIGN AND DESIGN REVIEW
Introduction to user centered design
User-centered design (UCD) is an approach to design that grounds the process in information about the people who will use the product. UCD processes focus on users through the planning, design and development of a product.
An International Standard
There is an international standard that is the basis for many UCD methodologies. This standard (ISO 13407: Human-centred design process) defines a general process for including human-centered activities throughout a development life-cycle, but does not specify exact methods.
In this model, once the need to use a human centered design process has been identified, four activities form the main cycle of work:
1. Specify the context of use Identify the people who will use the product, what they will use it for, and under what conditions they will use it. 2. Specify requirements Identify any business requirements or user goals that must be met for the product to be successful.
www.Vidyarthiplus.com www.Vidyarthiplus.com
3. Create design solutions This part of the process may be done in stages, building from a rough concept to a complete design. 4. Evaluate designs The most important part of this process is that evaluation - ideally through usability testing with actual users - is as integral as quality testing is to good software development.
The process ends - and the product can be released - once the requirements are met.
A Typical UCD Methodology
Most user-centered design methodologies are more detailed in suggesting specific activities, and the time within a process when they should be completed. The UXPA publishes a poster, Designing the User Experience, showing a typical UCD process. In this version, the UCD activities are broken down into four phases: Analysis, Design, Implementation and Deployment, with suggested activities for each phase. They are:
Analysis Phase
• Meet with key stakeholders to set vision • Include usability tasks in the project plan • Assemble a multidisciplinary team to ensure complete expertise • Develop usability goals and objectives • Conduct field studies • Look at competitive products • Create user profiles • Develop a task analysis • Document user scenarios • Document user performance requirements
Design Phase
• Begin to brainstorm design concepts and metaphors • Develop screen flow and navigation model • Do walkthroughs of design concepts • Begin design with paper and pencil • Create low-fidelity prototypes • Conduct usability testing on low-fidelity prototypes • Create high-fidelity detailed design • Do usability testing again • Document standards and guidelines • Create a design specification
www.Vidyarthiplus.com www.Vidyarthiplus.com
Implementation Phase
• Do ongoing heuristic evaluations • Work closely with delivery team as design is implemented • Conduct usability testing as soon as possible
Deployment Phase
• Use surveys to get user feedback • Conduct field studies to get info about actual use • Check objectives using usability testing
You may notice that "usability testing" appears several times throughout the process, from the first phase to the last. Providing a great user experience is an ongoing process.
User-centered design process (UCD) is also called human-centred design process.
Human centred design processes for interactive systems, ISO 13407 (1999), states: "Human-centred design is an approach to interactive system development that focuses specifically on making systems usable. It is a multi-disciplinary activity."
In UCD, all "development proceeds with the user as the center of focus." (Jeffrey Rubin, Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, John Wiley and Sons, Inc., 1984) Rubin depicts the User-Centered Design Process as follows:
• The users are in the center of a double circle. • The inner ring contains: Context; Objectives; Environment and Goals. • The outer ring contains: Task Detail; Task Content; Task Organization and Task Flow.
"User-Centered Design (UCD) is a user interface design process that focuses on usability goals, user characteristics, environment, tasks, and workflow in the design of an interface. UCD follows a series of well-defined methods and techniques for analysis, design, and evaluation of mainstream hardware, software, and web interfaces. The UCD process is an iterative process, where design and evaluation steps are built in from the first stage of projects, through implementation." (Shawn Lawton Henry and Mary Martinson, Accessibility in User-Centered Design)
UCD Principles
1. Early focus on users and tasks o Structured and systematic information gathering (consistent across the board) o Designers trained by experts before conducting data collection sessions
www.Vidyarthiplus.com www.Vidyarthiplus.com
2. Empirical Measurement and testing of product usage o Focus on ease of learning and ease of use o Testing of prototypes with actual users 3. Iterative Design o Product designed, modified and tested repeatedly. o Allow for the complete overhaul and rethinking of design by early testing of conceptual models and design ideas.
Usability
The goal of UCD is to produce products that have a high degree of usability. ISO 9241- 11 (1998) defines usability as the "extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use."
Jeffrey Rubin describes usability objectives as:
• Usefulness - product enables user to achieve their goals - the tasks that it was designed to carry out and/or wants needs of user. • Effectiveness (ease of use) - quantitatively measured by speed of performance or error rate and is tied to a percentage of users. • Learnability - user's ability to operate the system to some defined level of competence after some predetermined period of training. Also, refers to ability for infrequent users to relearn the system. • Attitude (likeability) - user's perceptions, feelings and opinions of the product, usually captured through both written and oral communication.
UCD seeks to answer questions about users and their tasks and goals, then use the findings to drive development and design.
UCD seeks to answer questions such as:
• Who are the users of the document? • What are the users’ tasks and goals? • What are the users’ experience levels with the document, and documents like it? • What functions do the users need from the document? • What information might the users need, and in what form do they need it? • How do users think the document should work? • What are the extreme environments? • Is the user multitasking? • Does the interface utilize different inputs modes such as touching, spoken, gestures, or orientation?
www.Vidyarthiplus.com www.Vidyarthiplus.com
UCD can improve the usability and usefulness of everything from "everyday things" (D. Norman) to software to information systems to processes. . . anything with which people interact. As such, User-Centered Design concerns itself with both usefulness and usability. Elements
As examples of UCD viewpoints, the essential elements of UCD of a web site are considerations of visibility, accessibility, legibility and language.
Visibility
Visibility helps the user construct a mental model of the document. Models help the user predict the effect(s) of their actions while using the document. Important elements (such as those that aid navigation) should be emphatic. Users should be able to tell from a glance what they can and cannot do with the document.
Accessibility
Users should be able to find information quickly and easily throughout the document, regardless of its length. Users should be offered various ways to find information (such as navigational elements, search functions, table of contents, clearly labeled sections, page numbers, color-coding, etc.). Navigational elements should be consistent with the genre of the document. ‘Chunking’ is a useful strategy that involves breaking information into small pieces that can be organized into some type meaningful order or hierarchy. The ability to skim the document allows users to find their piece of information by scanning rather than reading. Bold and italic words are often used.
Legibility
Text should be easy to read: Through analysis of the rhetorical situation, the designer should be able to determine a useful font style. Ornamental fonts and text in all capital letters are hard to read, but italics and bolding can be helpful when used correctly. Large or small body text is also hard to read. (Screen size of 10-12 pixel sans serif and 12-16 pixel serif is recommended.) High figure-ground contrast between text and background increases legibility. Dark text against a light background is most legible.
Language
Depending on the rhetorical situation, certain types of language are needed. Short sentences are helpful, as are well-written texts used in explanations and similar bulk- text situations. Unless the situation calls for it, jargon or technical terms should not be used. Many writers will choose to use active voice, verbs (instead of noun strings or nominals), and simple sentence structure.
www.Vidyarthiplus.com www.Vidyarthiplus.com
There are four important UCD principles:
• A clear understanding of user and task requirements • Incorporating user feedback to refine requirements and design • Active involvement of user to evaluate designs • Integrating user centred design with other development activities
www.Vidyarthiplus.com www.Vidyarthiplus.com User Centered Design Methods
UCD Method Description # of Users Pros and Cons Empirical Methods (obtaining data directly from users through observations and interviews) Card Sort Items of information are written on individual index 10-20 users (+) quick and cheap cards which are then sorted by users into categories (+) no technology required, so highly portable according to predetermined criteria; users explain (-) challenging to capture results from a complex session why they have categorized the items in a particular (-) does not reveal interface problems way Contextual Inquiry A specialized form of field study where designers Varies (+) provides an opportunity to see actual users perform their actual work and project team members visit actual users in their (few-many) in their actual environment workplace to analyze their work habits, activities, (+) helpful in earliest stages of design for a new system or overhaul of an flows, and environmental factors. existing system (-) can be time-consuming and challenging to arrange (-) little structure to observations
Focus Group Users participate in a facilitated discussion where 6 -10 (+) raises objections and insecurities regarding a system or its use that they share their ideas and opinions about the system. users/group might not be discovered through other means Meet with groups until responses become repetitive (+) can generate large amounts of data in a relatively short time (-) requires an experienced facilitator (-) subject to ‘domination effect’ in which one participant sways the discussion to a single point of view (-) subject to known inconsistencies between what people will say in a group and what their actual behavior may be Interview Interviewer asks semi-structured questions either Varies (+) low-cost, direct way to gather data face-to-face or by telephone. Those interviewed may (few-many) (+) effective for identifying users’ needs and opinions include stakeholders, content experts, support staff, (-) will not reveal any information that subjects wish to remain hidden or and users themselves. Both parties may choose to that they do not consciously know view a system online during part of the interview. (-) dependent on participant’s memory and willingness to contribute (-) can be challenging to schedule with busy users (-) can be challenging to both record data and facilitate the interview (audio-taped transcripts are recommended for long interviews)
©2002. Usability Consulting Services, Indiana University Acknowledgement: This list benefited from work done by Usability Research Group, University of Washington http://www.indiana.edu/~usable www.Vidyarthiplus.com www.Vidyarthiplus.com User Centered Design Methods
UCD Method Description # of Users Pros and Cons Log File Analysis User’s actions with a system are collected from None (+) provides a historical trace of usage traffic for a system server logs and examined later for usage patterns and (+) quick, easy way to gather data on user behavior without having to potential problem areas. actually recruit users. (-) log files do not indicate why users made certain actions or avoided making others (-) log files do not indicate if and how users recovered from errors Paper Prototype Test Users try out a low fidelity version of the system, 5-7 users/ (+) cheap and fast to conduct explaining their choices and interpretations as they group (+) allows quick testing of individual components of a software design use the system to complete given tasks. without the investment of actual coding (+) low fidelity encourages users to freely comment and suggest changes (unlike a polished product which may seem like it is already finished) (-) it is de-contextualized; individual components should be tested again in the real product (-) can be difficult to accommodate designs that offer users multiple paths Survey Users are asked a standard set of questions on paper, Varies (+) can gather data from many users quickly in person, by telephone, or by electronic mail. (-) can be a challenge to develop a reliable instrument (-) self-reporting may not be an accurate representation of user behavior (-) dependent on users choosing to participate in the survey (-) most valuable questions (open-ended) are often left unanswered Task Analysis Through observation and/or interviews with both At least 5 (+) can reveal new information that is exploitable in the software design expert and novice users, designers identify all the users/group (e.g. short cuts that expert users take) steps required for users to reach their goal(s) using (-) can be time consuming to carry out the system. (-) if not observing an expert user, you can inadvertently reproduce an inefficient way to complete a task (-) if you do observe an expert user, you may not find out the problems specific to beginners Usability Test Users work with a computer prototype to perform 5-12 users (+) a small number of users can identify numerous problems in a relatively (electronic prototype) given tasks. Evaluators and designers observe users’ short amount of time performances and behaviors using the actual system (+) finds more authentic problems than inspection methods to determine usability problems. Having users ‘think- (-) user’s performance may be affected depending on the perceived aloud’ helps the observers understand the users’ unreality of the session, their nervousness, and the effect of being observed actions. (-) the meaningfulness of the data collected rests on the authenticity of the users and tasks involved (-) time consuming to plan and analyze
©2002. Usability Consulting Services, Indiana University Acknowledgement: This list benefited from work done by Usability Research Group, University of Washington http://www.indiana.edu/~usable www.Vidyarthiplus.com www.Vidyarthiplus.com User Centered Design Methods
UCD Method Description # of Users Pros and Cons Inspection Methods (means to obtain data indirectly from users, often referred to as discount usability methods) Expert Review Design experts examine the system or a prototype of 3-5 (+) resolves some issues that users should not have to worry about in later it and comment in detail on its adherence to usability testing principles of good design based on their expertise. (-) constrained by the expert’s knowledge of the audience for which the Multiple experts are recommended to increase the system is intended probability that they will identify the main problems. (-) not sufficient on its own (developers will not catch the same problems as users will)
Guided Walkthrough Facilitator leads a user through a representation of Varies (+) does not require a high-fidelity prototype the system asking questions either during or after the (few-many) (+) can reveal attitudes and expectations that the user might not otherwise walkthrough to gauge the user’s understanding of the express system (-) must be conducted carefully to avoid accidentally leading users to conclusions or misinterpreting their actions (-) subjective point of view will keep developers from recognizing some problems (-) user performance may be effected by observation, nervousness, or other assessment factors Heuristic Evaluation A team of evaluators with HCI experience 3-5 (+) inexpensive, quick, and easy way to identify usability problems systematically apply a set of user-centered heuristics (-) constrained by the evaluator’s knowledge of HCI and knowledge of the in order to evaluate the system. Multiple experts are audience for which the system is designed recommended to increase the probability that they (-) possible to identify usability problems that actually may not be a will identify the main problems. problem of the user (-) not sufficient on its own (developers will not catch the same problems as users will)
©2002. Usability Consulting Services, Indiana University Acknowledgement: This list benefited from work done by Usability Research Group, University of Washington http://www.indiana.edu/~usable www.Vidyarthiplus.com www.Vidyarthiplus.com
Use in context
Modern HCI realizes that a user interface (UI) is to be used by users, so it is appropriate that the design process be centered on the user, called user-centered design. McCracken and Wolf list the attributes of user-centered design:
• User-centered design is user centric, not data centric. It involves users as much as possible in the process in creating the interface. Involvement varies from observing users, expert users designing and evaluating the prototypes • User-centered design is interdisciplinary, draws on knowledge from art, psychology, technical writing, and computer science. • User-centered design is highly interactive and involves many testing and revisions.
The general user-centered process follows these steps:
1. Analyses: Needs, User, Tasks, Functional, Requirements 2. Setting Usability Specifications 3. Design 4. Prototyping 5. Evaluation
Needs analysis summarizes the goals of the interactive system. It gives a general description of the system and identifies the primary users. The document is typically only a paragraph.
User analysis characterizes the people who will use the product and identifies the other stakeholders. The document will identify stakeholders’ goals or how they will be affected by the product.
Task analysis identifies the tasks and sequence of tasks to achieve the users’ goals. This is a longer document and uses scenario descriptions to describe the tasks.
Functional analysis identifies the computer services, deciding what can be automated by computers and what requires user inputs. This analysis is close to a system design. In this document uses cases can be used to describe the functions and division between computer and user.
Requirement analysis is the formal specifications of the system. The document includes object modeling, UML. Requirement analysis may include identifying resources such as data bases and dictionaries. If the software uses a database then entity- relationship diagrams will be included in the document.
Setting usability specifications defines how the product will be evaluated, including performance and preference measures. Performance measures aspects of software
www.Vidyarthiplus.com www.Vidyarthiplus.com
use such as time to perform a task. Preference measures how satisfied the user is while using the software.
Design is the preparation for prototyping. It describes how the product how will look and work. It will include drawings and description of use.
Prototypes can be global or local. Global prototypes depict the entire system at various levels of fidelity. Local prototypes model specific parts of the system. Early prototypes should be low fidelity global prototypes to insure a cohesive general design. Higher fidelity local prototypes can be used to test specific usability. Also prototyping can be throw-away, incremental and evolutionary.
After a prototype is constructed the product can be evaluated by users.
Other User Centered Design Process
There are other forms of UI development. For example participatory design which constantly involves the potential users or clients.
• Scenario Based Design which focuses on scenarios, short descriptive alternative descriptions of use, to develop the design. During the course you will use frequently use scenario based design to inform and describe your designs. • eXtreme programming which focuses on the actual process of implementation. • Conceptual design which is centered on developing ideas for the UI. • Data centered design which focuses on presenting the data and interacting with data. • There is also task centered which concentrates on performing the task efficiently and reliably.
Contexts of use
ISO’s Human-centered design processes for interactive systems identifies the first step in design as understanding and specifying the context of use. The attributes suggested are:
Table : Context of use from ISO standard for user-centered design
www.Vidyarthiplus.com www.Vidyarthiplus.com
It is useful to split the user context into its two constituent parts (user type and role) and then to consider the relationships between all four contexts:
Figure 2 shows that every task is performed in a role taken by a user within an environment. These contexts correspond to the RUP artifacts as shown in Table 4.
Each of these contexts could have a significant impact on the design of an appropriate user interface. As a result we are faced with a potentially large number of permutations. Even for a small system, there may be 2 environments (e.g. office and customer site), 3 types of user (sales novice, sales expert and management) and 6 roles (telephone sales assistant, external sales representative, etc.). That means up to 36 potential variations per task, although the set of realistic combinations is usually much smaller.
Clearly tasks must be described individually, but a single description is unlikely to be appropriate for all permutations. One approach is to factor the user and environment contexts into the role description. This is the solution adopted by Constantine and Lockwood It involves providing a separate "user role" for each significant permutation of role, user and environment, then naming the resulting user role with a descriptive phrase, rather than a simple noun. Compare, for example, the role “Customer” with the user roles “Casual Customer”, “Web Customer”, “Regular Customer” and “Advanced Customer”.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Each user role description includes details of the role itself plus its users (referred to as role incumbents) and environment. This approach can be adopted with the RUP by choosing actors that correspond to user roles.
Problems of User Centered Design
• Users may be wrong • Users may be resistant to change • Users may expect disadvantages (e.g. being replaced by software) • Be aware – you are expected to create an optimal system with regard to the goals specified – this is unfortunately NOT necessarily the system users would like to have (e.g. trade-off between employers and employees)
www.Vidyarthiplus.com www.Vidyarthiplus.com
Interface and interaction
User-interface design
Users understand and interact with a system through its user interface. The concepts, images and terminology presented in the interface must be appropriate to users’ needs. For example, a system that allows customers to buy their own tickets would be very different to one used professionally by ticket sales staff. The main differences are not in the requirements or even the detailed use cases, but the characteristics of the users and the environments in which the systems might operate.
The user interface must also cater for a potentially wide range of experience along at least two dimensions, computer and domain experience, as shown in Figure 1 below. Computer experience includes not only general familiarity with computers, but also experience of the system under development. Users with little experience of either computers or the problem domain, in the near left corner of the figure, will require a substantially different approach in the user interface to expert users, shown here in the far right corner.
Figure 1: The effects of computer and domain experience on ease of learning versus ease of use
Beware that it is not a foregone conclusion that inexperienced users will become experts over time. A number of factors may conspire to prevent this, for example low frequency of use, low motivation or high complexity. Conversely some systems may have predominately expert users. Factors here might be training, high frequency of use or high motivation (job dependence). Some of these issues and their effects on user- interface design are shown in Table 1.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Interactive systems must either be designed to cater for an appropriate range of user experience and circumstances, or steps must be taken to restrict the design universe. For instance, training can be used to reduce the requirement for ease of learning in a complex system. Alternatively a system might be reduced in its scope in order that it better meets the core requirements of its users
www.Vidyarthiplus.com www.Vidyarthiplus.com
1 Chapter 29 Interaction Design
29 Interaction Design
Interface and interaction
Contents
29.1 Design issues 29.2 The user interface design process 29.3 User analysis 29.4 User interface prototyping 29.5 Interface evaluation
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 2
Computer system design encompasses a spectrum of activities from hardware design to user interface design. While specialists are often employed for hardware design and for the graphic design of web pages, only large organisations normally employ specialist interface designers for their application software. Therefore, software engineers must often take responsibility for designing the interaction between users and the application as well as for the design of the software that implements the system functionality. I prefer to use the term ‘interaction design’ rather than ‘user interface design’ as it is important that designers think holistically about how users interact with applications and not simply focus on developing an attractive user interface. Even when software designers and programmers are competent users of interface implementation technologies, such as Java’s Swing classes (Elliott, et al., 2002) or XHTML (Musciano and Kennedy, 2002), the interfaces they develop are often unattractive and inappropriate for their target users. I focus, therefore, on the design process for interaction rather than the software that implements the user interfaces that support that interaction. Because of space limitations, I only consider interaction using graphical user interfaces. I don’t discuss interfaces that require special (perhaps very simple) displays such as mobile cell phones, music players, DVD players, televisions, and printers. Naturally, I can only introduce the topic here and I recommend texts such as those by Dix et al(Dix, et al., 2004), Weiss (Weiss, 2002) and Shneiderman (Shneiderman, 1998) for more information on this topic. Careful interaction design is an essential part of the overall software design process If a software system is to achieve its full potential, it is essential that its user interface should be designed to match the skills, experience and expectations of its anticipated users. Good interaction design is critical for system dependability. Many so-called ‘user errors’ are caused by the fact that user interfaces do not consider the capabilities of real users and their working environment. A poorly designed user interface means that users will probably be unable to access some of the system features, will make mistakes and will feel that the system hinders rather than helps them in achieving whatever they are using the system for. When making interaction design decisions, you should take into account the physical and mental capabilities of the people who use software. I don’t have space to discuss human issues in detail here but important factors that you should consider are: 1. People have a limited short-term memory—we can ‘instantaneously’ remember about seven items of information (Miller, 1957). Therefore, if you present users with too much information at the same time, they may not be able to take it all in. 1. We all make mistakes, especially when we have to handle too much information or are under stress. When systems go wrong and issue warning messages and alarms, this often puts more stress on users thus increasing the chances that they will make operational errors. 2. We have a diverse range of physical capabilities. Some people see and hear better than others, some people are colour-blind, some are better than others at physical manipulation. You should not only design for your own capabilities and assume that all other users will be able to cope.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
3 Chapter 29 Interaction Design
Principle Description User familiarity The interaction should be based on terms and concepts drawn from the experience of the people who will make most use of the system. Consistency The interface should be consistent in that, wherever possible, comparable operations should be activated in the same way. Minimal surprise Users should never be surprised by the behaviour of a system. Recoverability The interface should include mechanisms to allow users to recover from errors. User guidance The interface should provide meaningful feedback when errors occur and provide context-sensitive user help facilities. Figure 29.1 User diversity There should be appropriate interaction facilities for Interaction design different types of system users. principles
3. We have different interaction preferences. Some people like to work with pictures, others with text. Direct manipulation is natural for some people but others prefer a style of interaction that is based on issuing commands to the system. These human factors are the basis for the design principles shown in Figure 29.1. These general principles are applicable to all interaction designs and should normally be instantiated as more detailed design guidelines for specific organisations or types of system. User interface design principles are covered in more detail by Dix et al. (Dix, et al., 2004). Shneiderman (Shneiderman, 1998) gives a longer list of more specific user interface design guidelines. The principle of user familiarity suggests that users should not be forced to adapt to an interface because it is convenient to implement. The interface should use terms that are familiar to the user and the objects manipulated by the system should be directly related to the user’s working environment. For example, if a system is designed for use by air traffic controllers, the objects manipulated should be aircraft, flight paths, beacons and so on. Associated operations might be increase or reduce aircraft speed, adjust heading and change height. The underlying implementation of the interface in terms of files and data structures should be hidden from the end-user. The principle of user interface consistency means that system commands and menus should have the same format, parameters should be passed to all commands in the same way, and command punctuation should be similar. Consistent interfaces reduce user learning time. Knowledge learned in one command or application is therefore applicable in other parts of the system or in related applications. Interface consistency across applications is also important. As far as possible, commands with similar meanings in different applications should be
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 4
expressed in the same way. Errors are often caused when the same keyboard command, such as ‘Control-b’ means different things in different systems. For example, in the word processor that I normally use, ‘Control-b’ means embolden text, but in the graphics program that I use to draw diagrams, ‘Control-b’ means move the selected object behind another object. I make mistakes when using them together and sometimes try to embolden text in a diagram using the key combination. I then get confused when the text disappears behind the enclosing object. You can normally avoid this kind of error if you follow the command key shortcuts defined by the operating system that you use. This level of consistency is low-level consistency. Interface designers should always try to achieve this in a user interface. Consistency at a higher level is also sometimes desirable. For example, it may be appropriate to support the same operations (print, copy, etc.) on all types of system entities. However, Grudin (Grudin, 1989) points out that complete consistency is neither possible nor desirable. It may be sensible to implement deletion from a desktop by dragging entities into a trashcan. It would be awkward to delete text in a word processor in this way. Unfortunately, the principles of user familiarity and user consistency are sometimes conflicting. Ideally, applications with common features should always use the same commands to access these features. However, this can conflict with user practice when systems are designed to support a particular type of user such as graphic designers. These users may have evolved their own styles of interactions, terminology and operating conventions. These may clash with the interaction ‘standards’ that are appropriate to more general applications such as word processors. The principle of minimal surprise is appropriate because people get very irritated when a system behaves in an unexpected way. As a system is used, users build a mental model of how the system works. If an action in one context causes a particular type of change, it is reasonable to expect that the same action in a different context will cause a comparable change. If something completely different happens, the user is both surprised and confused. Interface designers should therefore try to ensure that comparable actions have comparable effects. Surprises in user interfaces are often the result of the fact that many interfaces are moded. This means that there are several modes of working (e.g., viewing mode and editing mode) and the effect of a command is different depending on the mode. It is very important that, when designing an interface, you include a visual indicator showing the user the current mode. The principle of recoverability is important because users inevitably make mistakes when using a system. The interface design can minimise these mistakes (e.g., using menus means avoids typing mistakes), but mistakes can never be completely eliminated. Consequently, you should include interface facilities that allow users to recover from their mistakes. These can be of three kinds: 1. Confirmation of destructive actions If a user specifies an action that is potentially destructive, the system should ask the user to confirm that this is really what is wanted before destroying any information.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
5 Chapter 29 Interaction Design
1. The provision of an undo facility Undo restores the system to a state before the action occurred. Multiple levels of undo are useful because users don’t always recognise immediately that a mistake has been made. 2. Checkpointing Checkpointing involves saving the state of a system at periodic intervals and allowing the system to restart from the last checkpoint. I have already discussed this in Chapter 13 as a dependability engineering technique for recovering from systems failures. Then, when mistakes occur users can go back to a previous state and start again. Many systems now include checkpointing to cope with system failures but, paradoxically, they don’t allow system users to use them to recover from their own mistakes. A related principle is the principle of user assistance. Interfaces should have built-in user assistance or help facilities. These should be integrated with the system and should provide different levels of help and advice. Levels should range from basic information on getting started to a full description of system facilities. Help systems should be structured so that users are not overwhelmed with information when they ask for help. The principle of user diversity recognises that, for many interactive systems, there may be different types of users. Some will be casual users who interact occasionally with the system while others may be ‘power users’ who use the system for several hours each day. Casual users need interfaces that provide guidance but power users require shortcuts so that they can interact as quickly as possible. Furthermore, users may suffer from disabilities of various types and, if possible, the interface should be adaptable to cope with these. Therefore, you might include facilities to display enlarged text, to replace sound with text, to produce very large buttons and so on. This reflects the notion of Universal Design (UD) (Preiser and Ostoff, 2001), a design philosophy whose goal is to avoid excluding users because of thoughtless design choices. The principle of recognising user diversity can conflict with the other interface design principles because some users may prefer very rapid interaction over, for example, user interface consistency. Similarly, the level of user guidance required can be radically different for different users, and it may be impossible to develop support that is suitable for all types of user. You therefore have to make compromises to reconcile the needs of these users.
29.1 Design issues
Before going on to discuss the process of interaction design, I discuss some general design issues that have to be considered. Essentially, the designer of a user interaction with a computer is faced with two key questions: 1. How should the user interact with the computer system? 2. How should information from the computer system be presented to the user?
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 6
A coherent user interface must integrate user interaction and information presentation. This can be difficult because the designer has to find a compromise between the most appropriate styles of interaction and presentation for the application, the background and experience of the system users, and the equipment that is available.
29.1.1 User interaction User interaction means issuing commands and associated data to the computer system. On early computers, the only way to do this was through a command-line interface and a special-purpose language was used to communicate with the machine. However, this was geared to expert users and, a number of approaches have now evolved that are easier to use. Shneiderman (Shneiderman, 1998) has classified these forms of interaction into five primary styles: 1. Direct manipulation The user interacts directly with objects on the screen. Direct manipulation usually involves a pointing device (a mouse, a stylus, a trackball or, on touch screens, a finger) that indicates the object to be manipulated and the action, which specifies what should be done with that object. For example, to delete a file, you may click on an icon representing that file and drag it to a trashcan icon. 2. Menu selection The user selects a command from a list of possibilities (a menu). The user may also select another screen object by direct manipulation and the command operates on that object. In this approach, to delete a file, you would select the file icon then select the delete command. 3. Form fill-in The user fills in the fields of a form. Some fields may have associated menus and the form may have action ‘buttons’ that, when pressed, cause some action to be initiated. You would not normally use this approach to implement the interface to operations such as file deletion. Doing so would involve filling in the name of the file on the form then ‘pressing’ a delete button. 4. Command language The user issues a special command and associated parameters to instruct the system what to do. To delete a file, you would type a delete command with the filename as a parameter. 5. Natural language The user issues a command in natural language. This is usually a front end to a command language; the natural language is parsed and translated to system commands. To delete a file, you might type ‘delete the file named xxx’. Each of these styles of interaction has advantages and disadvantages and is best suited to a particular type of application and user (Shneiderman, 1998). Figure 29.2 shows the main advantages and disadvantages of these styles and suggests types of application where they might be used. Of course, these interaction styles may be mixed, with several styles used in the same application. For example, Microsoft Windows supports direct manipulation of the iconic representation of files and directories, menu-based
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
7 Chapter 29 Interaction Design
Interaction Main advantages Main disadvantages Application examples style Direct Fast and intuitive May be hard to Video games manipulation interaction implement CAD systems Easy to learn Only suitable where there is a visual metaphor for tasks and objects Menu selection Avoids user error Slow for experienced Most general-purpose Little typing required users systems Can become complex if many menu options Form fill-in Simple data entry Takes up a lot of screen Stock control Easy to learn space Personal loan Checkable Causes problems where processing user options do not match the form fields Command Powerful and Hard to learn Operating systems language flexible Poor error management Command and control systems Figure 29.2 Advantages and Natural Accessible to casual Requires more typing Information retrieval disadvantages of language users Natural language systems interaction styles Easily extended understanding systems are unreliable
command selection and, for commands such as configuration commands, the user must fill in a special-purpose form that is presented to them. In principle, it should be possible to separate the interaction style from the underlying entities that are manipulated through the user interface. This was the basis of the Seeheim model (Pfaff and ten Hagen, 1985) of user interface management. In this model, the presentation of information, the dialogue management and the application are separate. In reality, this model is more of an ideal than practical, but it is certainly possible to have separate interfaces for different classes of users (casual users and experienced users, say) that interact with the same underlying system. This is illustrated in Figure 29.3, which shows a command language interface and a graphical interface to an underlying operating system such as Linux. Web-based user interfaces are based on the support provided by HTML or XHTML (the page description languages used for web pages) along with languages such as Java, which can associate programs with components on a page. Because these web-based interfaces are usually designed for casual users, they mostly use forms-based interfaces. However, using approaches such as AJAX, it is now much easier to construct direct manipulation interfaces in web browsers and these will be increasingly developed over the next few years. Furthermore, because of the range of experience of web users and the fact that they come from many different
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 8
Graphical user Unix shell interface interface (Gnome/KDE) (ksh/csh)
X-windows GUI Command manager language interpreter
Figure 29.3 Multiple user Linux operating system interfaces
cultures, it is difficult to establish a user interface metaphor for direct interaction that is universally acceptable. To illustrate the design of web-based user interaction, I discuss the approach used in a system called LIBSYS. This system allows library users to find and access documents from other collections and ensures that all appropriate copyright permissions are maintained. There are two fundamental operations that need to be supported: 1. Document search where users use the search facilities to find the documents that they need 2. Document request where users request that the document be delivered to their local machine or server for printing The LIBSYS user interface is implemented using a web browser, so, given that users must supply information to the system such as the document identifier, their name and their authorisation details, it makes sense to use a forms-based interface. Figure 29.4 shows a possible interface design for the search component of the system. In forms-based interfaces, the user supplies all of the information required
Figure 29.4 A forms-based interface to the LIBSYS system
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
9 Chapter 29 Interaction Design
Information to Presentation be displayed software
Figure 29.5 Information presentation Display
then initiates the action by pressing a button. Forms fields can be menus, free-text input fields or radio buttons. In the LIBSYS example, a user chooses the collection to search from a menu of collections that can be accessed (‘All’ is the default, meaning search all collections) and types the search phrase into a free-text input field. The user chooses the field of the library record from a menu (‘Title’ is the default) and selects a radio button to indicate whether the search terms should be adjacent in the record.
29.1.2 Information presentation All interactive systems have to provide some way of presenting information to users. The information presentation may simply be a direct representation of the input information (e.g., text in a word processor) or it may present the information graphically. A good design guideline is to keep the software required for information presentation separate from the information itself. Separating the presentation system from the data allows us to change the representation on the user’s screen without having to change the underlying computational system. This is illustrated in Figure 29.5. The MVC approach (Figure 29.6), first made widely available in Smalltalk (Goldberg and Robson, 1983), is an effective way to support multiple presentations of data. I introduced this approach in Chapter 7, where I discussed the design patterns used in its implementation. Users interact with each presentation in a style
User Controller state view modification View state inputs messages
Controller methods View methods
Model queries and updates Model edits Model state Figure 29.6 The MVC model of user Model methods interaction
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 10
that is appropriate to the presentation. The data to be displayed is encapsulated in a model object. Each model object may have a number of separate view objects associated with it where each view is a different display representation of the model. Each view has an associated controller object that handles user input and device interaction. Therefore, a model that represents numeric data may have a view that represents the data as a histogram and a view that presents the data as a table. The model may be edited by changing the values in the table or by lengthening or shortening the bars in the histogram. To find the best presentation of information, you need to know the users’ background and how they use the system. When you are deciding how to present information, you should bear the following questions in mind: 1. Is the user interested in precise information or in the relationships between data values? 2. How quickly do the information values change? Should the change in a value be indicated immediately to the user? 3. Must the user take some action in response to a change in information? 4. Does the user need to interact with the displayed information via a direct manipulation interface? 5. Is the information to be displayed textual or numeric? Are relative values of information items important? You should not assume that using graphics makes your display more ‘interesting’. Graphics take up valuable screen space (a major issue with portable devices) and can take a long time to download if the user is working over a slow, wireless connection on a mobile device. Information that does not change during a session may be presented either graphically or as text depending on the application. Textual presentation takes up less screen space but cannot be read ‘at a glance’. You should distinguish information that does not change from dynamic information by using a different presentation style. For example, you could present all static information in a particular font or colour, or you could associate a ‘static information’ icon with it. You should use text to present information when precise information is required and the information changes relatively slowly. If the data changes quickly or if the relationships between data rather than the precise data values are significant, then you should present the information graphically. For example, consider a system that records and summarises the sales figures for a company on a monthly basis. Figure 29.7 illustrates how the same information can be presented as text or in a graphical form. Managers studying sales figures are usually more interested in trends or anomalous figures rather than precise values. Graphical presentation of this information, as a histogram, makes the anomalous figures in March and May stand out from the others. Figure 29.7 also illustrates how textual presentation takes less space than a graphical representation of the same information. In control rooms or instrument panels such as those on a car dashboard, the information that is to be presented represents the state of some other system (e.g.,
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
11 Chapter 29 Interaction Design
Jan Feb Mar April May June 2842 2851 3164 2789 1273 2835
4000
3000
2000
1000 Figure 29.7 Alternative information 0 presentations Jan Feb Mar April May June
the altitude of an aircraft) and is changing all the time. A constantly changing digital display can be confusing and irritating as readers can’t read and assimilate the information before it changes. Such dynamically varying numeric information is therefore best presented graphically using an analogue representation. The graphical display can be supplemented if necessary with a precise digital display. Different ways of presenting dynamic numeric information are shown in Figure 29.8. Continuous analogue displays give the viewer some sense of relative value. In Figure 29.9, the values of temperature and pressure are approximately the same. However, the graphical display shows that temperature is close to its maximum value whereas pressure has not reached 25% of its maximum. With only a digital value, the viewer must know the maximum values and mentally compute the relative state of the reading. The extra thinking time required can lead to human errors in stressful situations when problems occur and operator displays may be showing abnormal readings. When large amounts of information have to be presented, abstract visualisations that link related data items may be used. This can expose relationships that are not obvious from the raw data. User interface designers should be aware of the possibilities of visualisation especially when the system user interface must represent physical entities. Examples of data visualisations are: 1. Weather information, gathered from a number of sources, is shown as a weather map with isobars, weather fronts and so on. 2. The state of a telephone network is displayed graphically as a linked set of nodes in a network management centre. 3. The state of a chemical plant is visualised by showing pressures and temperatures in a linked set of tanks and pipes.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 12
1 01020 42
Figure 29.8 3 Methods of presenting dynamically varying numeric Dial with needle Pie chart Thermometer Horizontal bar information
4. A model of a molecule is displayed and manipulated in three dimensions using a virtual reality system. 5. A set of web pages is displayed as a hyperbolic tree (Lamping, et al., 1995). Shneiderman (Shneiderman, 1998) includes a good overview of approaches to visualisation and identifies classes of visualisation that may be used. These include visualising data using two- and three-dimensional presentations and as trees or networks. Most of these are concerned with the display of large amounts of information managed on a computer. However, the most common use of visualisation in user interfaces is to represent some physical structure such as the molecular structure of a new drug, the links in a telecommunications network and so on. Three-dimensional presentations that may use special virtual reality equipment are particularly effective in product visualisations. Direct manipulation of these visualisations is a very effective way to interact with the data. In addition to the style of information presentation, you should think carefully about how colour is used in the interface. Colour can improve user interaction by helping users understand and manage complexity. However, it is easy to misuse colour and to create user interfaces that are visually unattractive and error-prone. Shneiderman gives 14 key guidelines for the effective use of colour in supporting interaction. The most important of these are: 1. Limit the number of colours used and be conservative how these are used You should not use more than four or five separate colours in a window and no more than seven in a system interface. If you use too many colours or if the colours are too bright, the display may be confusing. Some users may find masses of colour disturbing and visually tiring. User confusion is also
Figure 29.9 Pressure Temperature Graphical 0 100 200 300 400 0 25 50 75 100 information display showing relative values
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
13 Chapter 29 Interaction Design
Factor Description Context Wherever possible, the messages generated by the system should reflect the current user context. As far as is possible, the system should be aware of what the user is doing and should generate messages that are relevant to their current activity. Experience As users become familiar with a system they become irritated by long, ‘meaningful’ messages. However, beginners find it difficult to understand short, terse statements of a problem. You should provide both types of message and allow the user to control message conciseness. Skill level Messages should be tailored to the users’ skills as well as their experience. Messages for the different classes of users may be expressed in different ways depending on the terminology that is familiar to the reader. Style Messages should be positive rather than negative. They should use the active rather than the passive mode of address. They should never be insulting or try to be funny. Culture Wherever possible, the designer of messages should be familiar with the culture of the country where the system is sold. There are distinct cultural differences between Europe, Asia and America. A suitable message for one culture might be unacceptable in another.
Figure 29.10 Design factors in possible if colours are used inconsistently. message wording 2. Use colour change to show a change in system status If a display changes colour, this should mean that a significant event has occurred. Thus, in a fuel gauge, you could use a change of colour to indicate that fuel is running low. Colour highlighting is particularly important in complex displays where hundreds of distinct entities may be displayed. 3. Use colour coding to support the task which users are trying to perform If they have to identify anomalous instances, highlight these instances; if similarities are also to be discovered, highlight these using a different colour. 4. Use colour coding in a thoughtful and consistent way If one part of a system displays error messages in red (say), all other parts should do likewise. Red should not be used for anything else. If it is, the user may interpret the red display as an error message. 5. Be careful about colour pairings Because of the physiology of the eye, people cannot focus on red and blue simultaneously. Eyestrain is a likely consequence of a red on blue display. Other colour combinations may also be visually disturbing or difficult to read. In general, you should use colour for highlighting but you should not associate meanings with particular colours. About 10% of men are colour-blind and may misinterpret the meaning. Human colour perceptions are different and there are different conventions in different professions about the meaning of particular colours. Users with different backgrounds may unconsciously interpret the same
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 14
Please type the patient’s name in the box then click on OK
Patient’s name MacDonald, R. Figure 29.11 An input text box used by a OK Cancel nurse
colour in different ways. For example, to a driver red usually means danger. However, to a chemist, red means hot. As well as presenting application information, systems also communicate with users through messages that give information about errors and the system state. A user’s first experience of a software system may be when the system presents an error message. Inexperienced users may start work, make an initial error and immediately have to understand the resulting error message. This can be difficult enough for skilled software engineers. It is often impossible for inexperienced or casual system users. Factors that you should take into account when designing system messages are shown in Figure 29.10. You should anticipate the background and experience of users when designing error messages. For example, say a system user is a nurse in an intensive- care ward in a hospital. Patient monitoring is carried out by a computer system. To view a patient’s current state (heart rate, temperature, etc.), the nurse selects ‘display’ from a menu and inputs the patient’s name in the box, as shown in Figure 29.11. In this case, let’s assume that the nurse has misspelled the patient’s name and has typed ‘MacDonald’ instead of ‘McDonald’. The system generates an error message. Error messages should always be polite, concise, consistent and constructive. They must not be abusive and should not have associated beeps or other noises that might embarrass the user. Wherever possible, the message should suggest how the error might be corrected. The error message should be linked to a context-sensitive online help system. Figure 29.12 shows examples of good and bad error messages. The left- hand message is badly designed. It is negative (it accuses the user of making an error), it is not tailored to the user’s skill and experience level, and it does not take context information into account. It does not suggest how the situation might be rectified. It uses system-specific terms (patient id) rather than user-oriented
User-oriented error message System-oriented error message
Error #27 R. MacDonald is not a registered patient Figure 29.12 Invalid patient id Click on Patients for a list of patients System and Click on Retry to re-input the patient’s name user-oriented Click on Help for more information error messages OK Cancel Patients Help Retry Cancel
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
15 Chapter 29 Interaction Design
Figure 29.13 The interaction design process
language. The right-hand message is better. It is positive, implying that the problem is a system rather than a user problem. It identifies the problem in the nurse’s terms and offers an easy way to correct the mistake by pressing a single button. The help system is available if required.
29.2 The interaction design process
Interaction design is an iterative process where users interact with designers and interface prototypes to decide on the features, organisation and ‘look and feel’ of the system user interface. Sometimes, the interface is separately prototyped in parallel with other software engineering activities. More commonly, especially where iterative development is used, the interaction design proceeds incrementally as the software is developed. In both cases, however, before you start programming, you should have developed and, ideally, tested some paper-based designs. The overall interaction design process is illustrated in Figure 29.13. There are three core activities in this process: 1. User analysis In the user analysis process, you develop an understanding of the tasks that users do, their working environment, the other systems that they use, how they interact with other people in their work and so on. For products with a diverse range of users, you have to try to develop this understanding through focus groups, trials with potential users and similar exercises. 2. System prototyping Interaction design and development is an iterative process. Although users may talk about the facilities they need from an interface, it is very difficult for them to be specific until they see something
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 16
Jane is a religious studies student writing an essay on Indian architecture and how it has been influenced by religious practices. To help her understand this, she would like to access pictures of details on notable buildings but can’t find anything in her local library. She approaches the subject librarian to discuss her needs and he suggests search terms that she might use. He also suggests libraries in New Delhi and London that might have this material, so he and Jane Figure 29.14 A log on to the library catalogues and search using these terms. They find some library source material and place a request for photocopies of the pictures with interaction architectural details, to be posted directly to Jane. scenario
tangible. Therefore, you have to develop prototype systems and expose them to users, who can then guide the evolution of the interface. 3. Interface evaluation Although you will obviously have discussions with users during the prototyping process, you should also have a more formalised evaluation activity where you collect information about the users’ actual experience with the interface. The scheduling of interaction design within the software process depends, to some extent, on other activities. Prototyping may be used as part of the requirements engineering process and, in this case, it makes sense to start the interaction design at that stage. In iterative processes, discussed in Chapters 2 and 3, user interface design is integrated with the software development. Like the software itself, the user interface and user interactions may have to be refactored and redesigned during development.
29.3 User analysis
A critical interaction design activity is the analyses of the user activities that are to be supported by the computer system. If you don’t understand what users want to do with a system then you have no realistic prospect of designing an effective user interface. To develop this understanding, you may use techniques such as task analysis, ethnographic studies, user interviews and observations or, commonly, a mixture of all of these. A challenge for engineers involved in user analysis is to find a way to describe user analyses so that they communicate the essence of the tasks to other designers and to the users themselves. Notations such as UML sequence charts may be able to describe user interactions and are ideal for communicating with software engineers. However, other users may think of these charts as too technical and they do not understand them. Because it is very important to engage users in the design process, you therefore usually have to develop natural language scenarios to describe user activities. Figure 29.14 is an example of a natural language scenario that might have been developed during the specification and design process for the LIBSYS
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
17 Chapter 29 Interaction Design
system. It describes a situation where LIBSYS does not exist and where a student needs to retrieve information from another library. From this scenario, the designer can see a number of requirements: 1. Users might not be aware of appropriate search terms. They may need to access ways of helping them choose search terms.
2. Users have to be able to select collections to search.
3. Users need to be able to carry out searches and request copies of relevant material. You should not expect user analysis to generate very specific interaction requirements. Normally, the analysis helps you understand the needs and concerns of the system users. As you become more aware of how they work, their concerns and their constraints, your design can take these into account. This means that your initial designs (which you will refine through prototyping anyway) are more likely to be acceptable to users and so convince them to become engaged in the process of design refinement.
29.3.1 Analysis techniques As I suggested in the previous section, there are three basis user analysis techniques namely task analysis, interviewing and questionnaires, and ethnography. Task analysis and interviewing focus on the individual and the individual’s work, whereas ethnography takes a broader perspective and looks at how people interact with each other, how they arrange their working environment and how they cooperate to solve problems. There are various forms of task analysis (Diaper, 1989), but the most commonly used is Hierarchical Task Analysis (HTA). HTA was originally developed to help with writing user manuals but it can also be used to identify what users do to achieve some goal. In HTA, a high-level task is broken down into subtasks and plans identified that specify what might happen in a specific situation. Starting with a user goal, you draw a hierarchy showing what has to be done to achieve that goal. Figure 29.15 illustrates this approach using the library scenario introduced in Figure 29.14. In the HTA notation, a line under a box normally indicates that it will not be decomposed into more detailed subtasks. The advantage of HTA over natural language scenarios is that it forces you to consider each of the tasks and to decide whether or not these should be decomposed. With natural language scenarios, it is easy to miss important tasks. Scenarios also become long and boring to read if you want to add a lot of detail to them. The problem with this approach to describing user tasks is that it is best suited to tasks that are sequential processes. The notation becomes awkward when you try to model tasks that involve interleaved or concurrent activities or that involve a very large number of subtasks. Furthermore, HTA does not record why tasks are done in a particular way or constraints on the user processes. You can get a partial view of user activities from HTA, but you need additional information to develop a fuller understanding of the UI design requirements.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 18
Retrieve pictures from remote libraries do 1, 2, 3 until pictures found, 4
1 Discover 2Establish 3 4. Request Search for possible search photocopies pictures sources terms of found items
do 3.1, 3.2, 3.3 until pictures found, 3.4 if necessary, 3.5
3.1 3.2 3.3 3.4 3.5 Record Select Log in to Search for Modify relevant library catalogue pictures search terms items
do 3.3.1, 3.3.2, 3.3.3
3.3.1 3.3.2 3.3.3 Figure 29.15 Enter search Hierarchical task Initiate Review terms analysis search results
Normally, you collect information for HTA through observing and interviewing users. In this interviewing process, you can collect some of this additional information and record it alongside the task analyses. When interviewing to discover what users actually do, you should design interviews so that users can provide any information that they (rather than you) feel is relevant. This means you should not stick rigidly to prepared list of questions. Rather, your questions should be open-ended and should encourage users to tell you why they do things as well as what they actually do. Interviewing, of course, is not just a way of gathering information for task analysis—it is a general information-gathering technique. You may decide to supplement individual interviews with group interviews or focus groups. The advantage of using focus groups is that users stimulate each other to provide information and may end up discussing different ways that they have developed of using systems. Task analysis focuses on how individuals work but, of course, most work is actually cooperative. People work together to achieve a goal and users find it difficult to discuss how this cooperation actually takes place. Therefore, direct observation of how users work and use computer-based systems is an important additional technique of user analysis. One approach to direct observation that has been used in a wide variety of settings is ethnography (Suchman, 1983) (Hughes, et al., 1997) (Crabtree, 2003). I discussed ethnography in Chapter 7 as a technique that supports requirements
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
19 Chapter 29 Interaction Design
Air traffic control involves a number of control ‘suites’ where the suites controlling adjacent sectors of airspace are physically located next to each other. Flights in a sector are represented by paper strips that are fitted into wooden racks in an order that reflects their position in the sector. If there are not enough slots in the rack (i.e. when the airspace is very busy), controllers spread the strips out on the desk in front of the rack. When we were observing controllers, we Figure 29.16 A noticed that controllers regularly glanced at the strip racks in the adjacent sector. report of We pointed this out to them and asked them why they did this. They replied observations of that, when the adjacent controller has strips on his or her desk, then this means air traffic that a lot of flights will be entering their sector. They therefore tried to increase control the speed of aircraft in the sector to ‘clear space’ for the incoming aircraft.
engineering. Ethnographers closely observe how people work, how the interact
with others and how features in the workplace are used to support their work. The
advantage of ethnography is that the ethnographer can observe intuitive actions and informal collaborations that can then spark further discussions about the work. As an example of how ethnography can influence user interface design, Figure 29.16 is a fragment from a report of an ethnographic study on air traffic controllers in which I was involved (Bentley, et al., 1992). We were interested in the interface design for a more automated ATC system and we learned two important things from these observations: 1. Controllers had to be able to see all flights in a sector (this was why they spread strips out on the desk). Therefore, we should avoid using scrolling displays where flights disappeared off the top or bottom of the display. 2. The interface should have some way of telling controllers how many flights are in adjacent sectors so that controllers can plan their workload. Checking adjacent sectors was an automatic controller action and it is very likely that they would not have mentioned this in discussions of the ATC process. It was only through direct observation that we discovered these important requirements. None of these user analysis techniques, on their own, give you a complete picture of what users actually do. They are complementary approaches that you should use together to help you understand what users do and get insights into what might be an appropriate user interface design.
29.4 User interface prototyping
Because of the dynamic nature of user interfaces, textual descriptions and diagrams are not good enough for expressing user interface requirements. Evolutionary or exploratory prototyping with end-user involvement is the only practical way to design and develop graphical user interfaces for software systems. Involving the user in the design and development process is an essential aspect of user-centred design (Norman and Draper, 1986), a design philosophy for interactive systems.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 20
The aim of prototyping is to allow users to gain direct experience with the interface. Most of us find it difficult to think abstractly about a user interface and to explain exactly what we want. However, when we are presented with examples, it is easy to identify the characteristics that we like and dislike. Ideally, when you are prototyping a user interface, you should adopt a two- stage prototyping process: 1. Very early in the process, you should develop paper prototypes—mock-ups of screen designs—and walk through these with end-users. 2. Refine your design and develop increasingly sophisticated automated prototypes, then make them available to users for testing and activity simulation. Paper prototyping is a cheap and surprisingly effective approach to prototype development (Snyder, 2003). You don’t need to develop any executable software and the designs don’t have to be drawn to professional standards. You can draw paper versions of the system screens that users interact with and design a set of scenarios describing how the system might be used. As a scenario progresses, you sketch the information that would be displayed and the options available to users. You then work through these scenarios with users to simulate how the system might be used. This is an effective way to get users’ initial reactions to an interface design, the information they need from the system and how they would normally interact with the system. Alternatively, you can use a storyboarding technique to present the interface design. A storyboard is a series of sketches that illustrate a sequence of interactions. This is less hands-on but can be more convenient when presenting the interface proposals to groups rather than individuals. After initial experiments with a paper prototype, you should implement a software prototype of the interface design. The problem, of course, is that you need to have some system functionality for the users to interact with. If you are prototyping the UI very early in the system development process, this may not be available. To get around this problem, you can use ‘Wizard of Oz’ prototyping. In this approach, users interact with what appears to be a computer system but their inputs are actually channelled to a hidden person who simulates the system’s responses. They can do this directly or by using some other system to compute the required responses. In this case, you don’t need to have any executable software apart from the proposed user interface. To implement a prototype, you may use a conventional programming language such as Java but aim for ‘quick and dirty’ development without regard for normal programming standards. Alternatively, you may use a specialized toolkit for creating user interfaces or a web-based plug-in such as Flash to prototype animation. Prototyping is obviously closely associated with interface evaluation. Formal evaluation is unlikely to be cost-effective for early prototypes, so what you are trying to achieve at this stage is a ‘formative evaluation’ where you look for ways in which the interface can be improved. As the prototype becomes more complete, you can use systematic evaluation techniques, as discussed in the following section.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
21 Chapter 29 Interaction Design
Attribute Description Learnability How long does it take a new user to become productive with the system? Speed of operation How well does the system response match the user’s work practice? Robustness How tolerant is the system of user error? Figure 29.17 Recoverability How good is the system at recovering from user errors? Usability attributes Adaptability How closely is the system tied to a single model of work?
29.5 Interface evaluation
Interface evaluation is the process of assessing the usability of an interface and checking that it meets user requirements. Therefore, it should be part of the normal verification and validation process for software systems. Neilsen (Neilsen, 1993) includes a good chapter on this topic in his book on usability engineering. Ideally, an evaluation should be conducted against a usability specification based on usability attributes, as shown in Figure 29.17. Metrics for these usability attributes can be devised. For example, in a learnability specification, you might state that an operator who is familiar with the work supported should be able to use 80% of the system functionality after a three-hour training session. However, it is more common to specify usability (if it is specified at all) qualitatively rather than using metrics. You therefore usually have to use your judgement and experience in interface evaluation. Systematic evaluation of a user interface design can be an expensive process involving cognitive scientists and graphics designers. You may have to design and carry out a statistically significant number of experiments with typical users. You may need to use specially constructed laboratories fitted with monitoring equipment. A user interface evaluation of this kind is economically unrealistic for systems developed by small organisations with limited resources. There are a number of simpler, less expensive techniques of user interface evaluation that can identify particular user interface design deficiencies: 1. Questionnaires that collect information about what users thought of the interface; 2. Observation of users at work with the system and ‘thinking aloud’ about how they are trying to use the system to accomplish some task; 3. Video ‘snapshots’ of typical system use; 4. The inclusion in the software of code which collects information about the most-used facilities and the most common errors.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
Chapter 29 Interaction Design 22
Surveying users by questionnaire is a relatively cheap way of evaluating an interface. The questions should be precise rather than general. It is no use asking questions like ‘Please comment on the usability of the interface’ as the responses will probably vary so much that you won’t see any common trend. Rather, specific questions such as ‘Please rate the understandability of the error messages on a scale from 1 to 5. A rating of 1 means very clear and 5 means incomprehensible’ are better. They are both easier to answer and more likely to provide useful information to improve the interface. Users should be asked to rate their own experience and background when filling in the questionnaire. This allows the designer to find out if users from any particular background have problems with the interface. Questionnaires can even be used before any executable system is available if a paper mock-up of the interface is constructed and evaluated. Observation-based evaluation simply involves watching users as they use a system, looking at the facilities used, the errors made and so on. This can be supplemented by ‘think aloud’ sessions where users talk about what they are trying to achieve, how they understand the system and how they are trying to use the system to accomplish their objectives. Relatively low-cost video equipment means that you can record user sessions for later analysis. Complete video analysis is expensive and requires a specially equipped evaluation suite with several cameras focused on the user and on the screen. However, video recording of selected user operations can be helpful in detecting problems. Other evaluation methods must be used to find out which operations cause user difficulties. Analysis of recordings allows the designer to find out if the interface requires too much hand movement (a problem with some systems is that users must regularly move their hand from keyboard to mouse) and to see if unnatural eye movements are necessary. An interface that requires many shifts of focus may mean that the user makes more errors and misses parts of the display. Instrumenting code to collect usage statistics allows interfaces to be improved in a number of ways. The most common operations can be detected. The interface can be reorganised so that these are the fastest to select. For example, if pop-up or pull-down menus are used, the most frequent operations should be at the top of the menu and destructive operations towards the bottom. Code instrumentation also allows error-prone commands to be detected and modified. Finally, it is easy to give users a ‘gripe’ command that they can use to pass messages to the tool designer. This makes users feel that their views are being considered. The interface designer and other engineers can gain rapid feedback about individual problems. None of these relatively simple approaches to user interface evaluation is foolproof and they are unlikely to detect all user interface problems. However, the techniques can be used with a group of volunteers before a system is released without a large outlay of resources. Many of the worst problems of the user interface design can then be discovered and corrected.
©Ian Sommerville 2009
www.Vidyarthiplus.com www.Vidyarthiplus.com
23 Chapter 29 Interaction Design
KEY POINTS
. User interface principles covering user familiarity, consistency, minimal surprise, recoverability, user guidance and user diversity help guide the design of user interfaces. . Styles of interaction with a software system include direct manipulation, menu systems, form fill-in, command languages and natural language. . Graphical information display should be used when it is intended to present trends and approximate vales. Digital display should only be used when precision is required. . Colour should be used sparingly and consistently in user interfaces. Designers should take account of the fact that a significant number of people are colour-blind. . The user interface design process includes sub-processes concerned with user analysis, interface prototyping and interface evaluation. . The aim of user analysis is to sensitise designers to the ways in which users actually work. You should use different techniques—task analysis, interviewing and observation—during user analysis. . User interface prototype development should be a staged process with early prototypes based on paper versions of the interface that, after initial evaluation and feedback, are used as a basis for automated prototypes. . The goals of user interface evaluation are to obtain feedback on how a UI design can be improved and to assess whether or not an interface meets its usability requirements.
www.Vidyarthiplus.com www.Vidyarthiplus.com
User centered design principles
Figure 4. User-centered system design (UCSD) is a process focusing on usability throughout the entire development process and further throughout the system life cycle.
The design principles are
Use both knowledge in the world and knowledge in the head
Users are more comfortable and confident in doing tasks if the knowledge needed is available. The needed knowledge can be in the head like constraints or manuals or in the world where the user can make a conceptual models and mappings. What should be taken care of is that the knowledge in the world should be available in a way that users can estimate all possible actions and their outputs. The design should not limited users to perform a certain sequence of actions. Experienced users do not need to take all the small steps that beginners do, they need shorter paths. There should be a possibility to go back and forth using both knowledge in the world and in the head depending on which one is more available.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Simplify the structure of tasks
Users like to do simple task with the least effort, tasks needing planning and being divided to sub tasks confuse the user. Avoid complexity and reconstruct tasks in to simpler ones. Overloading short term or long term memory can cause complexity, a person is not able to remember more than 5 unrelated items by her short memory at one time; thus the system should provide some aids to help reminding. Long term memory is also erroneous thus the system should apply the knowledge in the world to help the user to know what he is able to do and how it can be done.
Make things visible, including the conceptual model of the system, the alternative actions, and the results of actions
Bridge the gulf of execution and evaluation, the user should be able to see the currents state of the system, the possible actions that can be done and the output of each action. There should be a clear sequence of actions that leads the user to the intended result.
Get the mappings right
Exploit natural mappings. Make sure that the user can determine the relationships: _ Between intentions and possible actions _ Between actions and their effects on the system _ Between actual system state and what is perceivable by sight, sound, or feel _ Between the perceived system state and the needs, intentions, and expectations of the user
Exploit the power of constraints, both natural and artificial
Exploit the power of constraints to reduce the amount of possible action to the fewest possible ones. For example a slider which is designed in a way which can only have horizontal movements stops the user from doing other movements such as rotation. Having seen it the very first time the user knows how to interact with it and in most cases induces the common mappings such as ”left is less, right is more” to it.
Design for error
Imagine the situation that the user makes any possible error in the system. Plan for it and make the design in a way that the possibility that the user commits the error is
www.Vidyarthiplus.com www.Vidyarthiplus.com
reduced, make the design as clear as the user is able to understand what has happened and how she can avoid the error next time she is using the system or what is the way to recover from it. Make reversible operations easy and the irreversible ones hard.
When all else fails, standardize
Standardization is applied when something cannot be designed without using arbitrary mappings. The experience of standardization has shown that once people learn it they start to use it forever. A good example can be traffic signs. Applying the mentioned rules, the designer makes the knowledge needed available and simplify the tasks by making them visible and using clear mappings. Errors are prevented mostly by constraints and there is a solution for every possible error. Last but not least standards are used to provide usage regulation.
The work practices of the users control the development.
Early focus on users and tasks. The designer must understand the users, their cognitive
behavior, attitudes and the characteristics of their work tasks. Appropriate allocation of function
between the user and the system is also important to prevent unnecessary control;
Active user participation throughout the project, in analysis, design, development and evaluation. This requires a careful user selection process emphasizing the skills of typical users, including both:
work domain experts (continuously through the development project);
actual end-users (for interviews and observations as well as evaluation of design results).
Early prototyping to evaluate and develop design solutions and to gradually build a shared understanding of the needs of the users as well as their future work practices;
Continuous iteration of design solutions.
A cyclic process of design, evaluation and redesign should be repeated as often as necessary. The evaluation process should include empirical measurement in which tests are conducted where users perform real tasks on prototypes. The users’ reactions and attitudes should be observed and analysed;
Multidisciplinary design teams.
Mainly achieved by including a usability designer in the process;
www.Vidyarthiplus.com www.Vidyarthiplus.com
Integrated design.
The system, the work practices, on-line help, training, organization, etc. should be developed in parallel.
Conclusion the design principles are
• User focus – the goals of the activity, the work domain or context of use, the users’ goals, tasks and needs should early guide the development • Active user involvement – representative users should actively participate, early and continuously throughout the entire development process and throughout the system lifecycle • Evolutionary systems development – the systems development should be both iterative and incremental • Simple design representations – the design must be represented in such ways that it can be easily understood by users and all other stakeholders • Prototyping – early and continuously, prototypes should be used to visualize and evaluate ideas and design solutions in cooperation with the end users • Evaluate use in context – baselined usability goals and design criteria should control the development • Explicit and conscious design activities – the development process should contain dedicated design activities • A professional attitude – the development process should be performed by effective multidisciplinary teams • Usability champion – usability experts should be involved early and continuously throughout the development lifecycle • Holistic design – all aspects that influence the future use situation should be developed in parallel • Processes customization – the UCSD process must be specified, adapted and/or implemented locally in each organization • A user-centered attitude should always be established.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Task analysis
A task analysis is an important process that determines whether human performance requirements match operator needs and capabilities. In a task analysis, functions performed by the system are broken down into tasks and subtasks. A task can be a type of individual work in the organization or the work of the organization as a whole. This kind of analysis can be used to determine the goals, intentions, methods, input, and output associated with any kind of work. It is used to identify the specific behaviors that will be required of the human operators, and to estimate operator workload and error rates on the various tasks. Task analysis is similar to a function analysis. However, a task analysis analyzes a specific task and its associated subtasks, whereas a function analysis analyzes the system as a whole. While a function is performed by the system, a task is something that is performed by a specific component of the system, whether human or machine.
– How are the tasks learned? – Where are they performed? – What are the properties of the data? – What other tools? – How do users communicate? – What are the time constraints? – What can go wrong?
The first step in conducting a task analysis involves data collection. Information must be gathered about the task in question and/or about the workers performing the task. This may be done by asking workers verbally for information or by having them fill out a questionnaire. Another method is to observe workers performing the task and record their activities via video/audio tape, or take notes. It may also be necessary to measure physiological variables, behavioral traits of the workers, and/or psychophysical reactions during or after task execution. Descriptions of the operational sequences of tasks to be performed should then be documented. Finally, the data must be organized in a meaningful way that allows individual tasks to be broken down into their subtask components.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Step-by-step instructions for conducting a task analysis are provided on the next screen. It is important to follow these steps in the specified order since omission of some steps could disqualify the evaluation results. Also, if this kind of analysis is not performed very early in the design process, financial or scheduling conflicts could prevent important changes from being made on certain design features.
Task Identification and Description
Task analysis is the activity that is intended to produce the foundation for design and evaluation. One product of a task analysis is task identification, whereby various tasks that must be performed by TMC operators are identified. These tasks are ones that are to be performed across all envisioned scenarios in a TMC environment. Task analysis drives TMC design by identifying the task sequences that must be streamlined by the design to alleviate workload problems, and identifying the errors that must be prevented or mitigated.
Another product of the task analysis is the task description. Descriptions of all of the activities that must be performed should be documented, including the operational sequences of tasks. The table below provides a list of descriptive categories that may be used when organizing information about a given task.(6)
Information Requirements
The identification of the specific information requirements of the TMC operator represents another task analysis product. Each information requirement must be fulfilled by an information element in the TMC system, whether a display or control. The presence of each information element is traceable to one or more information requirements, which are traceable to one or more tasks, which are, in turn, associated with one or more functions that are required to perform the specified missions (i.e., work
www.Vidyarthiplus.com www.Vidyarthiplus.com
scenarios). In short, information requirements specify the information elements that must be supported by TMC controls and displays to facilitate operator performance across a variety of tasks.
Use the questions below to guide the documentation of information requirements in the TMC work environment:
• What information is to be presented on the display? • How should each information element be represented? • How should the information elements be organized spatially? • How should the information elements be organized temporally?
The design effort must simultaneously address the representation of each information element, as well as organization of all elements. Information representation is determination of the design technique (coding technique) that will be used to represent, and hence convey, the information to the operator.
Organizing Task Analysis Data
A flow process chart is one way to organize task analysis data. A flow process chart graphically depicts different types of tasks and determines the specific components involved in a particular task. Information is organized sequentially, as subtasks occur over time. Symbols that are commonly used in flow process charts are presented below.
A time-line analysis is another way to organize task analysis data. This kind of organization shows when different tasks are conducted by different operators, and if there is any overlap in the time spent on tasks.(6) Time-line analyses may be useful when trying to determine how tasks are performed over time, which tasks are performed concurrently (by the same operator or different operators), and which tasks are performed sequentially (by the same operator or by different operators). For example, the operator monitoring a particular geographic region may need to communicate regularly with an operator monitoring a different region about traffic conditions that could affect both areas. If this communication frequently occurs at a time when the second operator is performing other tasks, the message may not be effectively communicated and appropriate actions may not be taken.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Task analysis is the process of learning about ordinary users by observing them in action to understand in detail how they perform their tasks and achieve their intended goals. Tasks analysis helps identify the tasks that your website and applications must support and can also help you refine or re-define your site’s navigation or search by determining the appropriate content scope.
Task analysis the analysis of how a task is accomplished, including a detailed description of both manual and mental activities, task and element durations, task frequency, task allocation, task complexity, environmental conditions, necessary clothing and equipment, and any other unique factors involved in or required for one or more people to perform a given task. Task analysis emerged from research in applied behavior analysis and still has considerable research in that area.
Task analysis analyses what a user is required to do in terms of actions and/or cognitive processes to achieve a task. A detailed task analysis can be conducted to understand the current system and the information flows within it. These information flows are important to the maintenance of the existing system and must be incorporated or substituted in any new system. Task analysis makes it possible to design and allocate tasks appropriately within the new system. The functions to be included within the system and the user interface can then be accurately specified.
Benefits
Provides knowledge of the tasks that the user wishes to perform. Thus it is a reference against which the value of the system functions and features can be tested.
The reader should be aware that task analysis can be a very time consuming activity if used with a high degree of detail on complex problems. ... It is possible to get caught in what is loosely termed ‘analysis paralysis’, where more and more detail is investigated.
Purpose of Task Analysis
• What your users’ goals are; what they are trying to achieve • What users actually do to achieve those goals • What experiences (personal, social, and cultural) users bring to the tasks • How users are influenced by their physical environment • How users’ previous knowledge and experience influence: o How they think about their work o The workflow they follow to perform their tasks
Types of Task Analysis
There are several types of task analysis but among the most common techniques used are:
www.Vidyarthiplus.com www.Vidyarthiplus.com
• Cognitive Task Analysis is focused on understanding tasks that require decision-making, problem-solving, memory, attention and judgement. • Hierarchical Task Analysis is focused on decomposing a high-level task subtasks.
How to Conduct a Task Analysis
1. Identify the task to be analyzed. 2. Break this high-level task down into 4 to 8 subtasks. The subtask should be specified in terms of objectives and, between them, should cover the whole area of interest. 3. Draw a layered task diagram of each subtasks ensuring that it is complete 4. Produce a written account as well as the decomposition diagram. 5. Present the analysis to someone else who has not been involved in the decomposition but who knows the tasks well enough to check for consistency
ADVANTAGES
• Through a task analysis you can attain a clear definition of what resources, processes, and results are related to current tasks that are (or will be) related to your program or project. • By using a task analysis to systematically review the completion of current tasks and their results your needs assessment will be better prepared to make recommendations regarding changes to current procedures and/or new tasks. • A task analysis will help you identify both what is working well and what is not working as well within the current organization.
DISADVANTAGES
• Effective task analyses require do require time and resources that may not have been included in your initial planning. • It can be challenging to determine if and how the completion of tasks would change due to needs assessment recommendations, and how those results may impact on other parts of the system.
www.Vidyarthiplus.com www.Vidyarthiplus.com
TASK ANALYSIS TECHNIQUES
1. Introduction
Task analysis is a fundamental methodology in the assessment and reduction of human error. A wide variety of different task analysis methods exist, and it would be impracticable to describe all these techniques here. Instead, the intention is to describe representative methodologies applicable to different types of task.
The term Task Analysis (TA) can be applied very broadly to encompass a wide variety of human factors techniques. Nearly all task analysis techniques provide, as a minimum, a description of the observable aspects of operator behavior at various levels of detail, together with some indications of the structure of the task. These will be referred to as action oriented approaches. Other techniques focus on the mental processes which underlie observable behavior, e.g. decision making and problem solving. These will be referred to as cognitive approaches.
TA methods can be used to eliminate the preconditions that give rise to errors before they occur. They can be used as an aid in the design stage of a new system, or the modification of an existing system. They can also be used as part of an audit of an existing system.
Task analysis can also be used in a retrospective mode during the detailed investigation of major incidents. The starting point of such an investigation must be the systematic description of the way in which the task was actually carried out when the incident occurred. This may, of course, differ from the prescribed way of performing the operation, and TA provides a means of explicitly identifying such differences. Such comparisons are valuable in identifying the immediate causes of an accident.
2. Action Oriented Techniques 2.1 Hierarchical Task Analysis (HTA)
Hierarchical Task Analysis is a systematic method of describing how work is organized in order to meet the overall objective of the job. It involves identifying in a top down fashion the overall goal of the task, then the various sub-tasks and the conditions under which they should be carried out to achieve that goal. In this way, complex planning tasks can be represented as a hierarchy of operations - different things that people must do within a system and plans - the conditions which are necessary to undertake these operations.
Hierarchical Task Analysis commences by stating the overall objective that the person has to achieve. This is then redescribed into a set of sub-operations and the plan specifying when they are carried out. The plan is an essential component of HTA since it describes the information sources that the worker must attend to, in order to signal the need for various activities. Each sub-operation can be redescribed further if the analyst requires, again in terms of other operations and plans. Figure 1.1 shows an example HTA for the task of isolating a level transmitter for maintenance.
www.Vidyarthiplus.com www.Vidyarthiplus.com
The question of whether it is necessary to break down a particular operation to a finer level of detail depends on whether the analyst believes that a significant error mode is likely to be revealed by a more fine grained analysis. For example, the operation ‘charge the reactor’ may be an adequate level of description if the analyst believes that the likelihood of error is low, and/or the consequences of error are not severe.
If the consequences of not waiting until the pressure had dropped were serious and/or omitting to check the pressure was likely, then it would be necessary to break down the operation ‘charge reactor’ to its component steps. Unfortunately, until the analyst has broken down the operation further, it is difficult to envision how a sub-operation at the next lower level of breakdown might fail, and what the consequences of this failure might be.
In practice, a consideration of the general quality of the PIFs (e.g. training, supervision, procedures) in the situation being evaluated will give a good indication of the overall likelihood of error in the specific operation being evaluated. Similarly, the consequences of errors can be evaluated in terms of the overall vulnerability to human error of the subsystem under consideration. By considering these factors together, it is usually obvious where the analysis should be terminated. Differing levels of detail may be necessary for different purposes, e.g. risk analysis, training specification or procedures design.
There are two main ways for representing a HTA description: the diagrammatic and tabular format. Diagrams are more easily assimilated but tables often are more thorough because detailed notes can be added.
Advantages of Hierarchical Task Analysis
• HTA is an economical method of gathering and organizing information since the hierarchical description needs only to be developed up to the point where it is needed for the purposes of the analysis. • The hierarchical structure of HTA enables the analyst to focus on crucial aspects of the task which can have an impact on plant safety. • When used as an input to design, HTA allows functional objectives to be specified at the higher levels of the analysis prior to final decisions being made about the hardware. This is important when allocating functions between personnel and automatic systems. • HTA is best developed as a collaboration between the task analyst and people involved in operations. Thus, the analyst develops the description of the task in accordance with the perceptions of line personnel who are responsible for effective operation of the system. • HTA can be used as a starting point for using various error analysis methods to examine the error potential in the performance of the required operations.
Disadvantages of Hierarchical Task Analysis
• The analyst needs to develop a measure of skill in order to analyze the task effectively since the technique is not a simple procedure that can be applied immediately. However, the necessary skills can be acquired reasonably quickly through practice. • Because HTA has to be carried out in collaboration with workers, supervisors and engineers, it entails commitment of time and effort from busy people
www.Vidyarthiplus.com www.Vidyarthiplus.com
2.2 Operator Action Event Trees (OAET)
OAETs are tree-like diagrams which represent the sequence of various decisions and actions that the operating team is expected to perform when confronted with a particular process event. Any omissions of such decisions and actions can also be modeled together with their consequences for plant safety.
Figure 1.3 gives an example of an OAET for events that might follow release of gas from a furnace. In this example a gas leak is the initiating event and an explosion is the final hazard. Each task in the sequence is represented by a node in the tree structure. The possible outcomes of the task are depicted as ‘success’ or ‘failure’ paths leading out of the node. This method of task representation does not consider how alternative actions (errors of commission) could give rise to other critical situations. To overcome such problems, separate OAETs must be constructed to model each particular error of commission.
By visual inspection of an OAET it is possible to identify the elements of a task which are critical in responding to an initiating event. An important issue in the construction of OAETs is the level of task breakdown. If the overall task is redescribed to very small sub-tasks it might be difficult to gain insights from the OAET because it can become relatively unwieldy.
Care should also be taken in the use of recovery factors, because these can exert a significant effect. In general, recovery paths are appropriate where there is a specific mechanism to aid error recovery i.e. an alarm, a supervising check, a routine walk round inspection and so on. While OAETs are best used for the qualitative insights that are gained, they can also be used as a basis for the quantitative assessment of human reliability. By assigning error probabilities to each node of the event tree and then multiplying these probabilities, the probability of each event state can be evaluated.
Advantages of OAETs
• The OAET is a logical method of structuring information concerning operator actions resulting from a particular initiating event.
• OAETs help to identify those tasks which are important in responding to particular initiating events.
Disadvantages of OAETs
• The approach is not a satisfactory method of identifying mistaken intentions or diagnostic errors. • OAETs are best suited to represent errors of omission. The important errors of commission (ie. alternative actions which may be performed) are difficult to include satisfactorily.
www.Vidyarthiplus.com www.Vidyarthiplus.com
• No assistance is provided to guarantee that the data used in the modeling process is complete and accurate. Therefore, the comprehensiveness of the final OAET will be a function of experience of the analyst (This criticism applies to all HRA techniques). • The OAET approach does not address error reduction or make any attempt to discover the root causes of the human errors represented.
www.Vidyarthiplus.com www.Vidyarthiplus.com
2.3 Decision/action flow diagrams
These are flow charts which show the sequence of action steps and questions to be considered in complex tasks which involve decision-making. Decision/Action Flow Diagrams are similar to the flow charts used in computer program development. Both charts are based on binary choice decisions and intervening operations. In general, the binary decision logic in Decision/Action charts expedites communications through the use of simple conventions and provides for easy translation of Decision/Action charts into logic flow charts for computerized sections of the system.
Decision/Action charts can be learned easily and workers usually find them useful in formulating for the analyst their mental plans which may involve decision-making, time-sharing, or complex conditions and contingencies. Figure 1.4 shows a Decision/Action chart for a furnace start-up operation. Decision/Action charts have only a single level of task description, and when complex tasks are analyzed the diagrams become unwieldy and difficult to follow. Also, it is possible to lose sight of the main objectives of the task. To this extent, HTA is more appropriate because the task can be represented in varying degrees of detail and the analyst can get a useful overview of the main objectives to be achieved during the performance of the task.
Although little training is required to learn the technique, Decision/Action charts should be verified by different operators to ensure that a representative view of the decision task is obtained.
Advantages of flow diagrams
• Decision/Action charts can be used to represent tasks which involve decision-making, time-sharing, or complex conditions and contingencies. • Workers find it easy to express their work methods in terms of flow diagrams. This representation can then provide input to other Task Analysis methods. • They can be used to identify critical checks that the workers have to carry out to complete a process control task. • For fault-diagnostic tasks, they can help the analyst to identify whether new staff members make effective use of plant information.
Disadvantages of flow diagrams
• Decision/Action charts are linear descriptions of the task, and provide no information on the hierarchy of goals and objectives that the worker is trying to achieve. • For complex tasks, the diagrams can become unwieldy. • They offer no guidance concerning whether or not a particular operation or decision should be redescribed in more detail.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Start
Ensure that m inimum tips & plugs are fitted for start-up
Light selected burner
Is it th e Is burner YES NO la s t Select next burner fla m e O K ? burner?
NO YES
Exit Shut burner cock
In je c t s te a m in burner
Is it th e YES firs t a tte m p t to NO lig h t s e le c te d burner?
Figure 1.4: Decision / Action Flow Diagram of a Furnace Start-Up Operation
3. Cognitive Task Analysis Techniques
The task analysis techniques described in the previous section are mainly oriented towards observable actions, although Hierarchical Task Analysis (HTA) allows it to address functional requirements as well as the specific actions that are required to satisfy these requirements.
Cognitive task analysis techniques attempt to address the underlying mental processes that give rise to errors rather than the purely surface forms of the errors. This is particularly important where the analysis is concerned with higher level mental functions such as diagnosis and problem solving. As plants become more automated, the job of the process plant worker is increasingly concerned with these functions and it is therefore necessary to develop analytical methods that can address these aspects of plant control. For example, the worker is often required to deal with abnormal plant states which have not been anticipated by the designer. In the worst case, the worker may be required to diagnose the nature of a problem under considerable time stress and develop a strategy to handle the situation. It is clearly desirable in these situations to provide appropriate decision support systems and training to improve the likelihood of successful intervention. It is also necessary to be able to predict the types of decision errors that are likely to occur, in order to assess the consequences of these failures for the safety of the plant. In all of these areas, task analysis
www.Vidyarthiplus.com www.Vidyarthiplus.com
techniques which address the covert thinking processes, as opposed to observable actions, are necessary.
The problems associated with the analysis of cognitive processes are much greater than with action oriented task analysis methods. The causes of ‘cognitive errors’ are less well understood than action errors, and there is obviously very little observable activity involved in decision making or problem solving. These difficulties have meant that very few formal methods of cognitive task analysis are available.
Despite these difficulties, the issue of cognitive errors is sufficiently important that we will describe some of the approaches that have been applied to systems. These techniques can be used in both proactive and retrospective modes, to predict possible cognitive errors during predictive risk assessments, or as part of an incident investigation. 3.1 Critical Action and Decision Evaluation Technique (CADET)
This method is based on the Rasmussen step ladder model. The basic units of CADET are the critical actions or decisions (CADs) that need to be made by the operator usually in response to some developing abnormal state of the plant. A CAD is defined in terms of its consequences. If a CAD fails, it will have a significant effect on safety, production or availability.
The following approach is then used to analyze each CAD. The first stage consists of identifying the CADs in the context of significant changes of state in the system being analyzed. The approach differs from the OAET in that it does not confine itself to the required actions in response to critical system states, but is also concerned with the decision making which precedes these actions. Having identified the CADs that are likely to be associated with the situation being analyzed, each CAD is then considered from the point of view of its constituent decision/action elements. These are derived from the Rasmussen Step Ladder model and reproduced in linear form in Figure 1.5. The potential failures that can occur at each of these elements are then identified.
To illustrate how CADET can be applied to decision analysis Figure 1.6 describes a hypothetical example an experienced worker who has to diagnose a plant failure (e.g. top reflux pump failure in a distillation column). A column is created for each decision/action element of the Rasmussen decision ladder to allow an extensive description of how the worker processes diagnostic information and eliminates an initial set of possible equipment failures to arrive at the actual problem. CADET presents the analyst with a structured list of questions about potential diagnostic errors. The protocol in Figure 1.5 shows a good diagnostic strategy in which the worker is looking initially for spurious indications before drawing any conclusions about the state of process equipment. CADET can be used both to evaluate and to support human performance in terms of training exercises.
The CADET technique can be applied both proactively and retrospectively. In its proactive mode, it can be used to identify potential cognitive errors, which can then be used to help generate failure scenarios arising from mistakes as well as slips. Errors arising from misdiagnosis can be particularly serious, in that they are unlikely to be recovered. They also have the potential to give rise to unplanned operator interventions based on a misunderstanding of the situation. The technique can also be applied retrospectively to identify any cognitive errors implicated in accidents.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Decision/ Action Objective Typical Error Patterns Element
Initial Alert Alerting/Signal Distraction/ Absent-Mindedness/ Low Detection of initial Alertness stages of problem Observation Observation/ Data Unjustified Assumptions/ Familiar Collection from Associations/ instruments Identification Identify System State Information Overload Time Delay Interpretation Interpret what has Failure to Consider Alternative Causes/ happened and its Fixation on the Wrong Cause implications Evaluation Evaluation and Failure to Consider Side Effects/ Focusing on Selection of Main Event Alternative Goals Planning Plan success path Wrong Task May be Selected due to Shortcuts in Reasoning and Stereotyped Response to Familiar State Procedure Selection/ Choosing or Procedural Steps Omitted/ Reversed Formulation formulating a (Particularly if ‘Isolated’) procedure to achieve required objective Execution Executing chosen Reversals of Direction or Sign (Up/Down, procedure Left/Right) when carrying out action. Habit Intrusion Feedback Observe change of Feedback ignored or misinterpreted state of system to indicate correct outcome of actions
Figure 1.5: Decision/ Action Elements of the Rasmussen Model (Embrey, 1986)
www.Vidyarthiplus.com www.Vidyarthiplus.com
3.2 The Influence Modelling and Assessment Systems (IMAS)
Reference has already been made to the difficulty of accessing the mental processes involved in diagnosis and decision-making. We can, however, be certain that success in these activities is likely to be dependent on the worker having a correct understanding of the dynamics of what is likely to happen as an abnormal situation develops. This is sometimes referred to as the worker’s ‘mental model’ of the situation. Knowledge of the mental model possessed by the operator can be extremely useful in predicting possible diagnostic failures.
The IMAS technique is used to elicit Subjective Cause-Consequence Models (SCCM) of process abnormalities from personnel, a SCCM is a graphical representation of the perceptions of the operating team regarding:
• The various alternative causes that could have given rise to the disturbance • The various consequences which could arise from the situation • Indications such as VDU displays, meters and chart recorders available in the control room or on the plant that are associated with the various causes and consequences A specific example of the Subjective Cause-Consequence Model derived by this approach is given in Figure 1.7. This was developed for a process plant in which powders are transferred by a rotary valve to a slurry mix vessel. Because of the flammable nature of the powders, they are covered with a blanket of nitrogen. Any ingress of air into the system can give rise to a potential fire hazard, and hence an oxygen analyzer is connected to the alarm system. Because the system can only be entered wearing breathing apparatus, it is monitored via closed circuit television (CCTV) cameras. The situation under consideration occurs when there is a failure to transfer powder and the model represents the various causes of this situation and some of the possible consequences. Any node in the network can be either a cause or a consequence, depending on where it occurs in the causal chain. It can be seen that the various indicators (given in square boxes) are associated with some, of the events that could occur in the situation.
The SCCM may be developed using the expertise of an individual or several workers in a team. In developing the SCCM, the analyst begins at a specific point in a process disturbance (e.g. an increase of pressure in a line), and asks the worker what the event stems from, leads to, or is indicated by. Repeated applications of these questions produce a network of the ‘mental model’ of the operating team or the individual process worker. As can be seen from Figure 1.7, an event can stem from more than one alternative cause, and lead to more than one outcome. The task of the worker is to identify which of the alternative causes gave rise to the pattern of observed indicators.
Application of IMAS
One of the major problems in training personnel to acquire diagnostic skills is the difficulty of knowing whether or not their understanding of process disturbances is sufficiently comprehensive in terms of alternative causes and possible consequences. Elicitation of the SCCM at various stages of training enables the trainer to evaluate the development and accuracy of the workers’ mental models of a range of process disturbances. A set of SCCMs developed using experienced operational teams can be used as standards to define the knowledge requirements to handle critical plant disturbances. Comparison of the trainees’ mental models with these SCCMs will indicate where further training is required.
Since the SCCM explicitly identifies the information needed to identify the causes of disturbances (and to distinguish between alternative causes), it can be used to specify the
www.Vidyarthiplus.com www.Vidyarthiplus.com
Task Analysis Techniques critical variables that need to be readily available to the process controller at the interface. This information can be used as an input to the design and upgrading of interfaces, particularly when new technology is being installed.
Cause or consequence Manual valve closed FDC filter door not closed correctly Indicator of plant state Nitrogen supply Auto valve Loose clips on exhausted closed flexible hose
Level indicator Indicated on Rotary valve rubber in tank alarm log sleeve loose
Rotary valve rubber Reduced sleeve burst Material consistency nitrogen supply abnormal (damp: fine) CCTV visual Air leakage indication of split powder Blockage in line Blockage in hopper High oxygen reading from analyser VDU line VDU line pressure - low pressure - high VDU Oxygen Oxygen level - analyser faulty high
Rotary valve problem Valve closed
VDU may show on graphic or Material flow in digital line interrupted No material transferring from hopper to slurry- mix vessel FDC filter FDC filter blocked and completely filling VDU blocked and full No mass change Mass discrepancy noted
Figure 1.7: Example of a Mental Model Elicited by IMAS (Embrey, 1985)
www.Vidyarthiplus.com www.Vidyarthiplus.com
Evaluation
We use the term user-centered evaluation to refer to evaluating the utility and value of software to the intended end-users. While usability (software ease of use) is certainly a
www.Vidyarthiplus.com www.Vidyarthiplus.com
necessary condition, it is not sufficient. Software may be aesthetically pleasing, effective and efficient using traditional usability methods yet these do not guarantee utility. Without supporting the primary tasks and work processes within software, beautifully designed software may be useless for its intended users. The software must provide the end-user utility or value.
User-centered evaluation prerequisites an understanding of users, their primary goals and tasks. By engaging directly and meaningfully with users, these goals can be derived overtime.
In the early stages of user-centered evaluation, we need to understand enough about our users to define high level metrics to use for evaluations. These metrics then need to be translated into data that can be captured in the software to implement the metric. During the design and evaluation life-cycle, periodic evaluations are used to ensure that the software design and implementations are making improvements on the metrics for utility. What sort of metrics might be used to measure utility? Productivity and quality are certainly categories for utility metrics. Different types of productivity might be producing reports more quickly or closing cases more quickly or analyzing data more quickly. Quality measures might be increased confidence in the recommendations made in a report. Deterrence measures could be used- using resources more effectively so that fewer crimes are committed in a given area.
Software development should be guided by the overall user goals and the difficulties users have in achieving these goals. User-centered evaluation measures the utility of software against user goals through the utility metrics obtained from user research.
Usability is a measure of interface quality that refers to the effectiveness, efficiency and satisfaction with which users can perform tasks with a tool. Evaluating usability is now considered an essential part of the system development process and a variety of methods and have been developed to support the human factors professional in this work.
Historically, the concept of usability has been defined in multiple ways, usually on one of the following bases:
• Semantics: in this case usability is equated to terms such as 'ease of use' or 'user-friendliness', without formal definition of the properties of the construct. • Features: here, usability is equated to the presence or absence of certain features in the user interface such as Windows, Icons, Menus or Pointing devices. • Operations: where the term is defined in terms of performance and affective levels manifest by users for certain task and environmental scenarios.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Evaluating usability
There exist multiple methods of evaluating usability depending on available resources (time facilities and labor), evaluator experience, ability and preference, and the stage of development of the tool under review. In broad terms it is worth making the following distinctions between evaluation methods:
• 1. User-based: where a sample of the intended users try to use the application • 2. Expert-based: where an HCI or usability expert makes an assessment of the application • 3. Model-based: where an HCI expert employs formal methods to predict one or more criteria of user performance
1. User-based methods
Testing an application with a sample of users performing a set of pre-determined tasks is generally considered to yield the most reliable and valid estimate of an application's usability. Performed either in a usability test laboratory or a field site, the aim of such a test is to examine the extent to which the application supports the intended users in their work. Tightly coupled to the operational approach to usability definition, the user- based approach draws heavily on the experimental design tradition of human factors psychology in employing task analysis, pre-determined dependent variables and, usually, quantitative analysis of performance supplemented with qualitative methods.
In a typical user-based evaluation, test subjects are asked to perform a set of tasks with the technology. Depending on the primary focus of the evaluator, the users' success at completing the tasks and their speed of performance may be recorded. After the tasks are completed, users are often asked to provide data on likes and dislikes through a survey or interview, or may be asked to view with the evaluator part of their own performance on video and to describe in more detail their performance and perceptions of the application. In this way, measures of effectiveness, efficiency and satisfaction can be derived, problems can be identified and re-design advice can be determined. In certain situations, concurrent verbal protocols might be solicited to shed light on users' thought processes while interacting with the tool so that issues of comprehension and user cognition can be addressed. In a usability lab, the complete interaction is normally video recorded for subsequent analysis of transactions, navigation, problem handling etc. However more informal approaches are also possible. Some user-based tests are unstructured, involving the user and the evaluator jointly interacting with the system to gain agreement on what works and what is problematic with the design. Such participative approaches can be very useful for exploring interface options in the early stages of design where formal quantitative assessments might be premature.
In an ideal world user testing with a large sample of the intended user population would routinely occur, however due to resource limitations, user-based tests are often constrained. As a result, there is considerable interest among HCI professionals in determining how to gain the most information from the smallest sample of users. While
www.Vidyarthiplus.com www.Vidyarthiplus.com
popular myths exist about being able to determine a majority of problems with only 2 or 3 users, Lewis (1994) has shown that the sample size requirement is largely dependent on the type of errors one seeks to identify and their relative probability of occurrence. Whereas 3 users might identify many problems in a new application, substantially more users will be required to tease out the remaining problems in a mature or revised product.
2. Expert-based methods
Expert-based methods refers to any form of usability evaluation which involves an HCI expert examining the application and estimating its likely usability for a given user population. In such cases, users are not employed and the basis for the evaluation lies in the interpretation and judgment of the evaluator. There is considerable interest in this form of evaluation since it can produce results faster and presumably cheaper than user-based tests.
In HCI, two common expert-based usability evaluation methods are Heuristic evaluation (e.g., Nielsen, 1994), and Cognitive Walkthrough (Wharton et al, 1994). Both methods aim to provide evaluators with a structured method for examining and reporting problems with an interface. The Heuristic method provides a simple list of design guidelines which the evaluator uses to examine the interface screen by screen and while following a typical path through a given task. The evaluator reports violations of the guidelines as likely user problems. In the Cognitive Walkthrough method, the evaluator first determines the exact sequence of correct task performance, and then estimates, on a screen by screen basis, the likely success or failure of the user in performing such a sequence. In both methods, the expert must make an informed guess of the likely reaction of users and explain why certain interface attributes are likely to cause users difficulties.
These methods differ in their precise focus. Heuristic methods are based on design guidelines and ultimately reflect the expert's judgment of how well the interface conforms to good design practice. The Cognitive Walkthrough method concentrates more on the difficulties users may experience in learning to operate an application to perform a given task. In practice, usability evaluators tend to adapt and modify such methods to suit their purpose and many experts who perform such evaluations employ a hybrid form of the published methods.
3. Model-based methods
Model-based approaches to usability evaluation are the least common form of evaluation but several methods have been proposed which can accurately predict certain aspects of user performance with an interface such as time to task completion or difficulty of learning a task sequence. In such cases, the evaluator determines the exact sequence of behaviors a user will exhibit through detailed task analysis, applies an analytical model to this sequence and calculates the index of usability.
www.Vidyarthiplus.com www.Vidyarthiplus.com
The most common model-based approach to estimating usability is the GOMS method of Card et al (1983), a cognitive psychology-derived framework that casts user behavior into a sequence of fundamental units (such as moving a cursor to given screen location or typing a well-practiced key sequence) which are allocated time estimates for completion based on experimental findings of human performance from psychology. In this way, any interface design can be analyzed to give an estimate of expert users' time to complete a task. The model has shown itself to be robust over repeated applications (see e.g., Gray et al 1993), though it is limited to predicting time and only then, for error- free performance in tasks involving little or no decision making.
Heuristic evaluation
Heuristic evaluation is a form of usability inspection where usability specialists judge whether each element of a user interface follows a list of established usability heuristics. Expert evaluation is similar, but does not use specific heuristics.
Usually two to three analysts evaluate the system with reference to established guidelines or principles, noting down their observations and often ranking them in order of severity. The analysts are usually experts in human factors or HCI, but others, less experienced have also been shown to report valid problems.
A heuristic or expert evaluation can be conducted at various stages of the development lifecycle, although it is preferable to have already performed some form of context analysis to help the experts focus on the circumstances of actual or intended product usage.
Benefits
• The method provides quick and relatively cheap feedback to designers. The results generate good ideas for improving the user interface. The development team will also receive a good estimate of how much the user interface can be improved. • There is a general acceptance that the design feedback provided by the method is valid and useful. It can also be obtained early on in the design process, whilst checking conformity to established guidelines helps to promote compatibility with similar systems. • It is beneficial to carry out a heuristic evaluation on early prototypes before actual users are brought in to help with further testing. • Usability problems found are normally restricted to aspects of the interface that are reasonably easy to demonstrate: use of colors, lay-out and information structuring, consistency of the terminology, consistency of the interaction mechanisms. It is generally agreed that problems found by inspection methods and by performance measures overlap to some degree, although both approaches will find problems not found by the other.
www.Vidyarthiplus.com www.Vidyarthiplus.com
• The method can seem overly critical as designers may only get feedback on the problematic aspects of the interface as the method is normally not used for the identification of the ‘good’ aspects.
Method
This method is to identify usability problems based on established human factors principles. The method will provide recommendations for design improvements. However, as the method relies on experts, the output will naturally emphasise interface functionality and design rather than the properties of the interaction between an actual user and the product.
1. Planning
The panel of experts must be established in good time for the evaluation. The material and the equipment for the demonstration should also be in place. All analysts need to have sufficient time to become familiar with the product in question along with intended task scenarios. They should operate by an agreed set of evaluative criteria.
2. Running
The experts should be aware of any relevant contextual information relating to the intended user group, tasks and usage of the product. A heuristics briefing can be held to ensure agreement on a relevant set of criteria for the evaluation although this might be omitted if the experts are familiar with the method and operate by a known set of criteria.
The experts then work with the system preferably using mock tasks and record their observations as a list of problems. If two or more experts are assessing the system, they should not communicate with one another until the assessment is complete. After the assessment period, the analysts can collate the problem lists and the individual items can be rated for severity and/or safety criticality.
3. Reporting
A list of identified problems, which may be prioritized with regard to severity and/or safety criticality is produced.
In terms of summative output the number of found problems, the estimated proportion of found problems compared to the theoretical total, and the estimated number of new problems expected to be found by including a specified number of new experts in the evaluation can also be provided.
A report detailing the identified problems is written and fed back to the development team. The report should clearly define the ranking scheme used if the problem lists have been prioritized.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Introduction to design review
A design review is a milestone within a product development process whereby a design is evaluated against its requirements in order to verify the outcomes of previous activities and identify issues before committing to - and if need to be re-prioritize - further work. The ultimate design review, if successful, therefore triggers the product launch or product release.
The conduct of design reviews is compulsory as part of design controls, when developing products in certain regulated contexts such as medical devices.
By definition, a review must include persons who are external to the design team.
Design reviews can fill a number of purposes, such as: • Ensuring that the proposed design will meet the requirements • Ensuring that the design can be implemented in the required time • Ensuring that the design will have the needed interfaces with other systems • Ensuring the design will be consistent with technical goals of the organization • Ensuring the design will follow established software design principles Design reviews can be at various levels, corresponding to the level of detail of the design being evaluated. At the highest level, the overall architecture is reviewed; lower level design reviews focus on specific features or specific technical aspects of a system design. Design reviews can also differ with respect to the audience and timing. Very early in the design process it is often useful to present a design to intended users or customers to determine if the requirements will be met. Later in the design process the audience is usually limited to the team that will be doing the implementation.
Contents of a design review
In order to evaluate a design against its requirements, a number of means may be considered, such as:
• Physical tests. • Engineering simulations. • Examinations (Walk-through).
Timing of design reviews
Most formalized systems engineering processes recognize that the cost of correcting a fault increases as it progresses through the development process. Additional effort spent in the early stages of development to discover and correct errors is therefore likely to be worthwhile. Design reviews are an example of such an effort. Therefore, a
www.Vidyarthiplus.com www.Vidyarthiplus.com
number of design reviews may be carried out, for example to evaluate the design against different sets of criteria (consistency, usability, ease of localization, environmental) or during various stages of the design process.
The participants of a design review should not be expected to imagine alternative solutions. Only if the feature being implemented is very simple it would be possible to propose entire new designs during the review. Any interesting feature requires a considerable amount of effort to obtain a good design. The consequence is that in this “single design” approach the solution being “reviewed” will almost always be approved with minor changes.
Therefore, effective design reviews must include the presentation of several alternatives. The discussion should not be if a particular design satisfies or not the requirements. Correctness is the most fundamental attribute of a solution, so the diverse design choices must differ on some other attributes that can be compared. In other words, each option has its advantages and disadvantages, and by choosing one of them we are actually deciding which attributes are the most important ones, but all options must be correct.
In this “multiple-choice” approach, the goal of the design review is to analyze several alternatives and understand their different implications. Then, if there is a solution that is clearly better than all others, according to some criteria, it should be the chosen one. Otherwise, we should try to look for additional options.
Design review is the process in which the design is evaluated against the requirements presented before. This includes the presentation of planned software design at early stages of the lifecycle so that changes can be made easily. These can be conducted at all levels including high level to check for the overall architecture and at lower level to check for certain specifications.
Purpose served by Design Reviews:
● They ensure that the proposed design will meet the specified requirements.
● They ensure that the technical goals of the organization will be met.
www.Vidyarthiplus.com www.Vidyarthiplus.com
● They ensure that the software design principles will be met.
Use of design reviews:
The design reviews show how the software will be structured and how various components will interact. They also help to identify the alternate approaches for designing.
Design review is conducted as follows:
Agenda: The agenda for the design review is structured and is distributed before the meeting. This will contain the topics that are to be discussed and the feedback is required.
A design review should be tightly structured to ensure that it results in useful feedback. An agenda should be distributed prior to the meeting. This agenda should identify the topics that will be presented and the specific issues that require discussion and feedback.
Presenter: The person who has the exact knowledge of the design presents the review. He is generally the author of the design.
Ordinarily the design is presented by the author of the design or the person most technically aware of all aspects of the design. More than one person may present a shared design.
Presentation: The presentation is given in order to make people understand how the design should work.
The objective of the presentation is to discuss the design in sufficient detail to enable the audience to understand how the design is intended to work, at a much higher level than a code review. Usually UML diagrams are provided and discussed, with sufficient detail to show the critical components of the design. However, these diagrams should omit extensive details that could distract the audience. Highly detailed UML diagrams can be kept on hand in case they are needed to answer questions raised in the discussion.
Invitees: the people attending this meeting are the stakeholders and all the people who are technically involved in the project.
The audience for a design review should consist of stakeholders (i.e. people whose work is affected by the design being reviewed) and all attendees should have a technical awareness of the issues being discussed. The audience should be kept small enough to ensure that all participants can express technical concerns with the design.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Requirements: This design review should take place when the requirements are formulated so that any changes if required could be made.
It is important that design reviews take place at a time when the software requirements have been formulated, although these requirements may not be finalized; and, in fact, one consequence of a design review may be to change the requirements if it is found that the existing requirements cannot be met. A written copy of the requirements (in their current state) should be available for discussion during the design review.
Background information: Prior to the meeting, attendees should be given a written statement of the proposed design, including UML and other diagrams and any relevant requirements. In addition, it is often useful to provide preliminary design information, such as the results of a prototyping effort, relevant performance measurements, and even customer feedback, at a design review. Visual aids can help clarify complicated aspects of the design.
Outcome: The people attending the meeting should write all the relevant issues arising during the meeting so that a report can be created and the changes be implemented.
An attendee involved in the design should write minutes, and/or make notes of any issues that arise during the meeting. Action items should identify persons responsible for resolving issues identified in the meeting. A summary of the meeting results and follow-up issues should be distributed to attendees, and others affected by the results, after the meeting.
Software Design Reviews-Best Practices
1. Everything in moderation and nothing to excess
Too many designers solve problems that don’t exist, reinterpret requirements to fit their preconceived idea of an appropriate solution, or refuse to take advantage of new techniques in the name of risk reduction. Every solution and technique has an appropriate range of applicability, going beyond this range generally causes more problems than it solves. Practicality and reasonableness coupled with a willingness to use new techniques if they are better than old ones are characteristics that all systems designers would do well to cultivate.
2. A good system design is based on a sound conceptual model (Architecture) a system design which has no conceptual structure and little logic to its organization is going to be ultimately unsuccessful.
3. A sound conceptual model accounts for all system requirements at a reasonable level of abstraction
www.Vidyarthiplus.com www.Vidyarthiplus.com
What constitutes a reasonable level of abstraction will obviously vary from system to system and will necessarily depend on the requirements, but in general I believe a reasonable level of abstraction is reached when a balance is achieved between specificity and generality.
3.1 A conceptual model is sufficiently generalized when it can account for all significant use cases in a concise way that reduces complexity by consolidating similar features.
There are two important concepts here. The first is the concept of a significant use case. For any given system there are a vast number of potential use cases only some of which are significant. Determining the relative significance of use cases is an art not a science. Ultimately only the user of the system can determine the relative significance of use cases. However, most users concentrate on the normal operation of the system being designed and fail to consider more exceptional scenarios. It is up to the system designer to include use cases that go beyond the normal operation of systems. System designers commonly fail to do this and often neglect system validation (testing), installation, commissioning or recovery from failure when defining use cases.
The second important concept is that of reducing complexity by consolidating similar features.
If there are three or more features of a system that display significant similarity it is worth considering consolidating them into a single, more generalized, feature. However a reduction in complexity that leads to a corresponding reduction in fidelity should be avoided.
3.2 A conceptual model is sufficiently specific when it is possible to demonstrate how a system design based on the model will achieve measurable targets for required system attributes
A clear understanding of the difference between functional requirements and system attributes is required to appreciate this statement. A functional requirement can only be present or absent – a system is capable of performing a function or it is not. Functional requirements can be derived from use cases they describe the behaviors the system is capable of displaying.
By contrast system attributes, or qualities as they are sometimes called, define the way in which the system performs its functions. Attributes commonly include qualities like reliability, recoverability and availability , but can include more exotic qualities if needed, such as traceability, augmentability, and autonomy.
4. A good conceptual model is easy to communicate
A sound conceptual model that accounts for all the system requirements at a reasonable level of abstraction is only half the battle. It must also be understandable. All
www.Vidyarthiplus.com www.Vidyarthiplus.com
too often a great architecture leads to a mediocre design, a poor implementation and an unsatisfactory solution. At each stage something gets lost. Extreme programming techniques can help but even then solutions don’t always live up to the original concept. The most commonly required system attribute is also one of the least often considered – Ease of communication of the conceptual model on which the design is based is essential for successful solutions.
there are three ways to improve the ease with which a conceptual model can be communicated.
4.1 A conceptual model is easier to understand and communicate if it is; coherent, Logical in the relationship of its parts, Aesthetically consistent.
4.2 A conceptual model is easier to understand and communicate if it is analogous to a commonly experienced, tangible, real world system.
4.3 A conceptual model is easier to understand and communicate if it is anthropomorphized: Made to mimic human behavior, characteristics and modes of interaction.
If the conceptual model for a system is deliberately made analogous to a real world, commonly experienced, system and that system is one that involves social interaction (i.e. it is anthropomorphized), then communicating the design becomes a great deal easier. Another interesting feature of such conceptual models is that the analogy itself often suggests possible enhancements and steers the designer or implementer away from problem areas. In defining use cases it is common practice to identify actors. When faced with design decisions it is often helpful to ask “what would this actor want to do in this situation?” or “Is this responsibility in keeping with the personality of this actor”.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Testing the design
Design is subjective. What I like you may well hate and vice versa. Design can often lead to arguments between client and designer about what direction the design should take.
Focusing on the user just shifts the argument from what the design should be to what the user wants. The only way to resolve this is to test.
The normal route for resolving this problem is to focus on what the user wants, rather than what the client or designer thinks is best. However, often all this does is shift the argument about what the design should be like to what the user will want! The only way of resolving this is to test.
The root of the problem is that design is a subjective thing. Although there are underlying principles of good design a lot of it comes down to what people personally like or dislike. This makes deciding on a design a potential stumbling block.
Asking users what they think isn’t enough
It is not enough to just show users a design and ask them if they like it or not. This approach creates two problems.
Whether a user likes a design is not the only criteria by which to judge it.
First, whether they like a design is not the only criteria by which to judge it. For example a user might not personally like the design of a law firm (finding it too formal for their personal preferences) but it may still leave them with the right feeling about the company (that it is professional and trustworthy).
Second, when asked what they think users fallback on comments such as “I don’t like the green.” Comments like this aren’t particularly helpful. You need to know what it is about the green that is a problem.
Techniques for testing design
1. A/B tests
The most basic test is a simple A/B test. This is ideal when you are not sure of the best approach. Sometimes you can go different directions with a design and you are unsure which is best suited. In this case a simple A/B test maybe the answer.
Normally the A/B test simply involves presenting two designs to a user and asking which they prefer. This is perfectly adequate, but you might wish to go a step further.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Instead of asking them which they prefer, show them your list of brand words and ask which they feel best represents the list. This moves the conversation on from simple likes and dislikes, to something directly related to your brand.
2. Semantic differential survey
In this test you present the user with either single or multiple designs and rate them against opposing words.
For example is your design formal or casual, minimal or busy. These choices can be either a black and white choices or a sliding scale.
3. Competitor reaction
Another approach is to see how well your new design performs compared to the competition.
This is a great way of seeing whether you are outperforming the competition. It also will flag up a common problem where designs within a sector all end up looking the same.
4. Snap test
You show the user your design for only 1 or 2 seconds and then get their reaction.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Because of the short timeframe you may find that users struggle to judge the design against your list of keywords. However, you can at least discover whether they had a positive or negative reaction to what they have seen.
www.Vidyarthiplus.com www.Vidyarthiplus.com
Walkthroughs
A design walkthrough is a quality practice that allows designers to obtain an early validation of design decisions related to the development and treatment of content, design of the graphical user interface, and the elements of product functionality. Design walkthroughs provide designers with a way to identify and assess early on whether the proposed design meets the requirements and addresses the project's goal.
Design Walkthroughs
• Objective - Check the architecture of the design for: o Flaws o Weaknesses o Errors o Omissions • Participants o User o Analyst o Senior designer o Project designers • Objects o Structure charts, detailed design documents, ...
For a design walkthrough to be effective, it needs to include specific components. The following guidelines highlight these key components. Use these guidelines to plan, conduct, and participate in design walkthroughs and increase their effectiveness.
1. Plan for a Design Walkthrough
A design walkthrough should be scheduled when detailing the micro-level tasks of a project. Time and effort of every participant should be built into the project plan so that participants can schedule their personal work plans accordingly. The plan should include time for individual preparation, the design walkthrough (meeting), and the likely rework.
2. Get the Right Participants
It is important to invite the right participants to a design walkthrough. The reviewers/experts should have the appropriate skills and knowledge to make the walkthrough meaningful for all. It is imperative that participants add quality and value to the product and not simply 'add to their learning.'
3. Understand Key Roles and Responsibilities
www.Vidyarthiplus.com www.Vidyarthiplus.com
All participants in the design walkthrough should clearly understand their role and responsibilities so that they can consistently practice effective and efficient reviews.
4. Prepare for a Design Walkthrough
Besides planning, all participants need to prepare for the design walkthrough. One cannot possibly find all high-impact mistakes in a work product that they have looked at only 10 minutes before the meeting. If all participants are adequately prepared as per their responsibilities, the design walkthrough is likely to be more effective.
5. Use a Well-Structured Process
A design walkthrough should follow a well-structured, documented process. This process should help define the key purpose of the walkthrough and should provide systematic practices and rules of conduct that can help participants collaborate with one another and add value to the review.
6. Review and Critique the Product, not the Designer
The design walkthrough should be used as a means to review and critique the product, not the person who created the design. Use the collective wisdom to improve the quality of the product, add value to the interactions, and encourage participants to submit their products for a design walkthrough.
7. Review, do not Solve Problems
A design walkthrough has only one purpose, to find defects. There may, however, be times when participants drift from the main purpose. A moderator needs to prevent this from happening and ensure that the walkthrough focuses on the defects or weaknesses rather than identifying fixes or resolutions.
In addition to these guidelines, there are a few best practices that can help you work towards effective design walkthroughs:
• The document or work product for the design walkthrough should be complete from all respects including all the necessary reviews/filters. • Plan for a design walkthrough in a time-box mode. A session should be scheduled for a minimum of one hour and should not stretch beyond two and a half hours. When walkthroughs last more than three hours, the effectiveness of the design walkthrough and the review process decreases dramatically. • It is best to work with 5-10 participants to add different perspectives to the design walkthrough. However, with more than 15 participants, the process becomes slow and each participant may not be able to contribute to their full capacity. • Design walkthroughs planned for morning sessions work better than afternoon sessions.
www.Vidyarthiplus.com www.Vidyarthiplus.com
• A design walkthrough should definitely include the instructional designers, graphic artists, course architects, and any other roles that have been instrumental in creating the design. You may also want to invite designers from other projects to add a fresh and independent perspective to the review process. • Involving senior management or business decision makers in a design walkthrough may not always be a good idea as it can intimidate the designers and they may feel that the senior management is judging their competencies in design. With senior management in the room, other participants and reviewers may also be hesitant in sharing problems with the design. • Effective design walkthroughs rely on a 'moderator' who is a strong Lead Reviewer and is in charge of the review process. It is critical that the group remains focused on the task at hand. The Lead Reviewer can help in this process by curbing unnecessary discussions and lead the group in the right direction. • Design walkthroughs are more effective if the reviewers use specific checklists for reviewing various aspects of the work product. • It is a good practice to involve the potential end users in the design walkthrough. However, in most situations it is difficult to get access to the end users. Therefore, you may request reviewer(s) to take on the role of the end user and review the product from the end-user perspective. These reviewers may be Subject Matter Experts or practitioners in the same field/industry who have an understanding of the audience profile for the product. • The effectiveness of a design walkthrough depends on what happens after the defects have been identified in the meeting and how the defects are addressed and closed in the work product. The team needs to prioritize the defects based on their impact and assign responsibility for closing the defects.
Design walkthroughs, if done correctly, provide immediate short-term benefits, like early defect detection and correction within the current project and offer important long-term returns. From a long-term perspective, design walkthroughs help designers identify their mistakes and learn from them, therefore moving towards continuous improvement. During the process, designers are also able to unravel the basic principles of design and the key mistakes that violate these principles. By participating in walkthroughs, reviewers are able to create a mental 'catalogue of mistakes' that are likely to happen and are therefore more equipped to detect these early in any product. By analyzing the kind of defects made by designers, over time, reviewers can use this information to support root-cause analysis and participate in organization-wide improvement initiatives.
Effective design walkthroughs are one of the most powerful quality tools that can be leveraged by designers to detect defects early and promote steps towards continuous improvement.
www.Vidyarthiplus.com www.Vidyarthiplus.com
A "walkthrough" is a review of a product/system by peers: the participants, who are approximately at the same level in the organization, meet to review and discuss systematically a piece of software. Here, we study a software design from the perspective of the user. The "Structured Walkthrough"s (Yourdon, 1979) have been proven to be one of the most effective methods to obtain feedback and improve the quality of software. The rules are very simple but very important: the groups must be small (3 to 7 persons), group members must be of the same level, the presenter must prepare work in advance, everyone must be on time, and the session should be limited to one hour maximum. The purpose of the walkthrough is to identify as many problems as possible, not to discuss possible solutions. Critiques must be as positive as possible and should be limited to the part presented by the presenter.
Roles: Each group member has a specific role for each walkthrough. Presenter Selects that which must be presented Presents it to the group Scribe Takes note of the comments Coordinator Ensures that the discussion is concentrated on the software Ensures that the session lasts exactly x minutes (max 1 hour) Guardian of standards Asks questions based on the specifications of the project.
Preparation: Make several copies of your scenario (one for each member of your group, plus one copy to cut if you reuse text).
Procedure: The presenter acknowledges scenario and organizes screenshots (or videos) that are necessary for a user to perform each step of the scenario. The scribe notes the basic information on the attached page.
Result: Move so that everyone can see images of the presenter screen. The presenter begins by describing the scenario quickly and present the first image that the user sees. He or she shows what the user needs to do, step by step, to execute the script. At each step, the examiners/participants will ask questions and make constructive criticism of each screen or the general usability of the software. Do not criticize the authors, focus on the prototype. The scribe should make a list of design issues that were identified and include them in the report. At the end, the group must decide if the software is acceptable, or if it needs minor or major revisions.
The aim is to identify problems, not solve them!!!
www.Vidyarthiplus.com www.Vidyarthiplus.com
Eg : Design Walkthrough Group: evaluated by groups:
Coordinator: Scribe:
Start time: End time:
Criteria used:
Design Problems found:
www.Vidyarthiplus.com www.Vidyarthiplus.com
Review against check lists
When the design change request are raised, design change are happen for the product or process that parameters of the process and product with new changed are need to review to ensure the all changes made is in line with requirements or the changes made for the product / process are covered all the requirements. Design review is important part that can be consider as the audit part or inspection part of the design changes. For the compliance of the requirement of the audit or inspection of design review that design change review checklist points are given as below as sample:
1. Product Number and name 2. Date of reviewed 3. product Description 4. part number 5. Part name & part descriptions 6. Type of part 7. process Details 8. Checklist information / points 9. Standard & deviations 10. Compliance / Non compliance 11. Non compliance Note
Design Review Checklist
1. Are the following attributes well-defined for each design entity? a. Identification (unique name) b. Type (describing what kind of design entity it is) c. Purpose (describing why it was introduced, in terms of the requirements) d. Function (summarizing what the component does) e. Dependencies (possibly `none'; describing the requires or uses relationship) f. Interface (provided by the design entity) g. Processing (including autonomous activities) h. Data (information `hidden' inside) 2. Is the relationship to the requirements clearly motivated? Is it clear why the proposed architecture realizes the requirements? 3. Is the software architecture as simple as possible (but no simpler)? o No more than 7 loosely-coupled coherent high-level components. o Lower-level components possibly clustered into high-level components (hierarchy). o Using standard(ized) components. o Is deviation from intuitively obvious solution motivated? 4. Is the architecture complete? o Are all requirements covered?
www.Vidyarthiplus.com www.Vidyarthiplus.com
o Trace some critical requirements through the architecture (e.g. via use cases). 5. Are the component descriptions sufficiently precise? o Do they allow independent construction? o Are interfaces and external functionality of the high-level components described in sufficient detail? o Interface details: . Routine kind, name, parameters and their types, return type, pre- and post-condition, usage protocol with respect to other routines. . File name, format, permissions. . Socket number and protocol. . Shared variables, synchronization primitives (locks). o Have features of the target programming language been used where appropriate? o Have implementation details been avoided? (No details of internal classes.) 6. Are the relationships between the components explicitly documented? o Preferably use a diagram 7. Is the proposed solution achievable? o Can the components be implemented or bought, and then integrated together. o Possibly introduce a second layer of decomposition to get a better grip on achievability. 8. Are all relevant architectural views documented? o Logical (Structural) view (class diagram per component expresses functionality). o Process view (how control threads are set up, interact, evolve, and die). o Physical view (deployment diagram relates components to equipment). o Development view (how code is organized in files). 9. Are cross-cutting issues clearly and generally resolved? o Exception handling. o Initialization and reset. o Memory management. o Security. o Internationalization. o Built-in help. o Built-in test facilities. 10. Is all formalized material and diagrammatic material accompanied by sufficient explanatory text in natural language? 11. Are design decisions documented explicitly and motivated? o Restrictions on developer freedom with respect to the requirements. 12. Has an evaluation of the software architecture been documented? o Have alternative architectures been considered? o Have non-functional requirements also been considered? o Negative indicators:
www.Vidyarthiplus.com www.Vidyarthiplus.com
. High complexity: a component has a complex interface or functionality. . Low cohesion: a component contains unrelated functionality. . High coupling: two or more components have many (mutual) connections. . High fan-in: a component is needed by many other components. . High fan-out: a component depends on many other components. 13. Is the flexibility of the architecture demonstrated? o How can it cope with likely changes in the requirements? o Have the most relevant change scenarios been documented?
Preliminary Design Review
1. Traceability o Did you ensure traceability of the design back to the systems specification and statement of requirements? o Is a scheme used for naming of modules, data, and interfaces? o Are all modules, data, and interfaces uniquely identified? 2. Consistency o Is the data structure consistent with the information domain? o Is the data structure consistent with software requirements? o Is a standard design representation used? o Is a standard data usage representation used? 3. Completeness o Are software requirements reflected in the software architecture? o Are all referenced data defined? o Are all defined data used? o Are all referenced modules defined? o Are all defined modules used? o Are interfaces defined for modules and external elements? o Has maintainability been considered? o Have quality factors been explicitly assessed? 4. Efficiency o Are data grouped for efficient processing? o Are storage requirements allocated to design? o Is effective modularity achieved? Are modules functionally independent?
www.Vidyarthiplus.com www.Vidyarthiplus.com
Design Review Checklist
Checklist Description: This checklist captures common elements that should be present in any design. It is presented during the Design Review process to stimulate thought, guide brainstorming, and to ensure the design being outlined contains all proper design considerations. As the project architecture, system, and application design is being reviewed, assess the design considerations that apply to your subject matter expertise and business/technical needs. Project Name: Review Date:
Assessment and Recommendations: Notes: Approved without revision Approved with revisions (see Notes) Not approved Reviewer: Signature:
Artifacts Reviewed: Conceptual Architecture Review Checklist Technical Design Specification Requirements Traceability Matrix Implementation Plan General Design Comments Does the design support both product and project goals? Is the design feasible from a technology, cost, and schedule standpoint? Have known design risks been identified, analyzed, and planned for or mitigated? Are the methodologies, notations, etc. used to create and capture the design appropriate? If possible, were proven past designs reused? Does the design support proceeding to the next development step? Have proper fallback consideration been made? Design Considerations Comments Does the design have conceptual integrity (i.e., does the whole design tie together)? Can the design be implemented within technology and environmental constraints? Does the design use standard techniques and avoid exotic, hard-to-understand elements? Is the design unjustifiably complex? Is the design lean (i.e., are all of its parts strictly necessary)? Does the design create reusable components if appropriate? Will the design be easy to port to another environment if appropriate? Does the design allow for scalability? Are all time-critical functions identified, and timing criteria specified for them? Are the hardware environment completely defined, including engineering change levels and constraints? Are the pre-requisite and co-requisite software and firmware clearly identified, including release levels and constraints? Requirements Traceability Comments Does the design address all issues from the requirements?
© 2012 Regents of the University of Minnesota. All rights reserved. Revised September 13, 2014 Page 1 www.Vidyarthiplus.com www.Vidyarthiplus.com
Design Review Checklist Does the design add features or functionality, which was not specified by the requirements (i.e., are all parts of the design traceable back to requirements)? If appropriate, has requirements coverage been documented with a completed requirements traceability matrix? Are all of the assumptions, constraints, design decisions, and dependencies documented? Have all reasonable alternative designs been considered, including not automating some processes in software? Have all goals, tradeoffs, and decisions been described? Has the Risk Plan been modified with any new risks posed by the design? Have all interfacing systems been identified? Are the error recovery and backup requirements completely defined? Have the infrastructure e.g. backup, recovery, checkpoints been addressed?
Consistency Comments Does the design adequately address issues that were identified and deferred at previous upstream levels? Is the design consistent with related artifacts (i.e., other modules, designs, etc.)? Is the design consistent with the development and operating environments? Performance Reliability Comments Are all performance attributes, assumptions, and constraints clearly defined? If appropriate, are there justifications for design performance (i.e., prototyping critical areas or reusing an existing design proven in the same context)? Capacity Planning Comments Does the design improve productivity? Is scalability development into the plan and is maintainable? Is Total Cost of Ownership (TCO) controlled or reduced?
Maintainability Comments Does the design allow for ease of maintenance? If reusable parts of other designs are being used, has their effect on design and integration been stated? Does the design resist erosion in the correctness of its content over time?
Compliance Comments Does the design follow all standards necessary for the system? (i.e., date standards) Have legal/regulatory requirements been assessed and accounted for? Modeling and Design Views Comments When appropriate, are there multiple, consistent, models and/or views that represent the design (i.e., static vs. dynamic)? Where there are multiple models of the software (i.e., static and dynamic) are those models consistent with each other?
© 2012 Regents of the University of Minnesota. All rights reserved. Revised September 13, 2014 Page 2 www.Vidyarthiplus.com