DESIGN PATTERNS DESIGN PATTERNS AND REUSABILITY

Transcription

1 D DESIGN PATTERNS We do a lot of things in our daily lives according to certain patterns even though we may not be aware of it. For example, each working adult performs similar activities every working day wake up, have breakfast, go to work, take a lunch break, come home, and so on. If you look at these daily activities at a high (abstract or conceptual) level, they follow pretty much the same pattern for every working individual, even though at a lower (detail) level, the particulars differ what kind of breakfast each person has, how they go to work (e.g., on foot, by bicycle, or by car), when the person has a lunch break, and so on. Patterns occur in many contexts. The world-famous architect, Christopher Alexander (1), first introduced the notion of design patterns in the context of architecture. He and his colleagues (2) used patterns to describe the structural elements of buildings and towns; and they specify a pattern language to describe the high-level patterns for rooms, buildings, gardens, towns, and so on. Important principles of architectural design are captured by several interacting design patterns. Each of these architectural design patterns represents a solution to a recurring design problem at the conceptual level. Specific details of the design are not included in the abstraction of the pattern. Design patterns in architecture are basically a description of accumulated practices, experience, and wisdom that have been employed to solve common architectural problems so that other people can reuse them in different settings. There are many similarities between architectural design and software design. They are each creative activities in which the resulting designs must satisfy customers requirements, while working within a design space with many competing and conflicting constraints. There were many efforts in the 1980s toward using the ideas of patterns for software development, and eventually four computer scientists Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides adopted and adapted the ideas put forward by Alexander et al. and popularized the use of patterns for software design. Their pioneering work on design patterns culminated in their seminal book (3), and they have since been referred to by people in the software community as the Gang-of-Four 1. The design patterns they specify in their book are known as the Gang-of-Four or GoF patterns, which describe patterns for the solution of commonly occurring problems in the object-oriented software design. Since that time, many 1 A humorous reference to the historic Gang-of-Four four Chinese Communist Party leaders Jiang Qing, Wang Hongwen, Yao Wenyuan, and Zhang Chunqiao, who were arrested and removed from their party positions after the death of the party chairman, Mao Zedong in 1976 and also a tie to the Three Amigos Grady Booch, Ivar Jacobson, and James Rumbaugh, who developed and popularized UML (4). software engineers have proposed literally hundreds of different design patterns, and patterns for other aspects of the software development process such as requirements, testing, and implementation. DESIGN PATTERNS AND REUSABILITY Reusability is one of the key attributes of software quality. There are two very different aspects of reusability reusing existing things and creating reusable things. It is usually much easier to reuse existing things than to create things that are reusable. Most artifacts of the software development process can be reused requirements templates, models, architecture, designs, code, test strategies, and so on. Code reuse is supported by programming language idioms, libraries, class library toolkits, and functional interfaces such as the application programming interface (API). Frameworks provide a higher level of reuse in software architecture for a specific application domain. Reuse can also occur at a conceptual level solutions and ideas to common problems in the software development process and this is the level at which design patterns fit. Design patterns provide a set of structures, often used in toolkits and frameworks, to solve common general design problems, at a level higher than that of data structures. Although toolkits and frameworks are pluggable components of executable software needing little or no modification, design patterns, in contrast, are codified knowledge and experience that can be used to structure the software component so that it is easy to understand, more flexible, modular, and maintainable. Besides software design, design patterns are also used to identify commonalities in different phases of the software development lifecycle, including requirements analysis, software architecture, and implementation. We can reuse design patterns and their associated pseudo-code skeletons, test strategies, and documentation from system to system, either to provide similar services or to handle similar difficulties. Patterns can be combined and made to interact with each other. Usually, patterns may fit the new system at an abstract level, but they will require modifications in detail design, implementation, and testing to fit the specifics of the new system. Design patterns are not code, but they provide a structure and a set of relationships for the code. For example, the observer pattern provides a structure in which one class notifies other classes when data change or events occur. Not only will the data that must be conveyed differ, but security, timeliness, and platform concerns may affect even the way in which the messages are sent. DESIGN PATTERN SPECIFICATIONS Wiley Encyclopedia of Computer Science and Engineering, edited by Benjamin Wah. Copyright # 2008 John Wiley & Sons, Inc. 1 A developer selects a pattern that solves a design problem by consulting the documentation of the candidate patterns.

2 2 DESIGN PATTERNS Design patterns are documented using templates that consist of many elements. The GoF specify patterns with four essential elements: The pattern name is an identifier that allows efficient communication about the pattern. A problem statement that describes the context, situation, or condition of when to apply the pattern. A solution that provides the abstract description of the elements that make up the design, their relationships, responsibilities, and collaborations. The consequences of applying the pattern, including tradeoffs and impacts on a system. These elements constitute the template of a design pattern. Templates can provide many sections or headings with details of the pattern so that it will be easy for the users to decide whether the pattern is an appropriate solution to their problem. For example, the GoF included additional entries such as motivation, applicability, structure, participants, collaborations, consequences, and implementation for their templates. Ideally, a pattern description should also include contraindications situations in which the pattern probably should not be applied; this is part of the motivation for description of anti-patterns common solutions for common problems that happen to be wrong, ineffective, inefficient, or misleading. A designer can use the template to determine whether the pattern is applicable to the current design problem in the current context. Conversely, if an additional recurrent problem is isolated (by focusing on essential characteristics), a new pattern codifying an approach to its solution may be discovered, and a new template may be documented to specify its attributes and usability. The interactions of classes and objects of the design pattern are specified by an object-oriented design approach and notation, often the Unified Modeling Language [UML (4)]. UML is a standard modeling language widely used in object-oriented system design and development. UML provides mechanisms that can be used to depict design patterns in diagrams with graphical and textual notations; other model-driven representations can also be used for this purpose. Such an encoding helps to communicate the pattern and specifies how the pattern works and can be used. The combination of name and notation also helps designers to communicate about design problems and possible solutions. GOF DESIGN PATTERN CATALOG There are many commonly occurring problems in software design. The GoF catalogued 23 patterns in Ref. 3 and classified them into three categories according to their purpose: creational, structural, and behavioral: Creational patterns separate the creation of classes or objects from their use or implementation in the system. Structural patterns provide ways to compose classes or objects into larger structures. Behavioral patterns deal with the assignment of responsibilities between objects and the interactions among objects to achieve some desired behavior of the system. The design patterns were also classified into scope, which specifies whether the pattern applies primarily to classes or to objects. Most scope is at the object level. The following list provides the names of the GoF patterns together with their intents under each of the categories. Creational Patterns The creational design patterns deal with instantiations. A class creational pattern uses inheritance to provide variation, whereas an object creational pattern uses delegation. Factory Method Define an interface for creating an object, but let subclasses decide which class to instantiate. The factory method lets a class defer instantiation to subclasses (5). For example, a database client can create a query without worrying about whether the database interface uses relational or some other database architecture. Abstract Factory Provide an interface for creating families of related or dependent objects without specifyingtheirconcreteclasses(5). Itgeneralizesthe factory method to allow creation of a set of related objects. The client callsthe abstract factoryto create all the objectsof interest, and then calls the created objects through their superclasses. For example (6), implementation of a socket in Java needs to create three objects: an input stream, an output stream, and the socket itself. The user should not have to know whether the socket (and, therefore, the streams) are sent in the clear, compressed, or encrypted, nor whether the socket class includes bookkeeping (such as counting bytes or profiling traffic) that also requires changes in the two stream classes. The client can call the abstract factory to create the three objects (of some subclasses), and then the client can access the returned objects simply as a socket, an input stream, and an output stream. Builder Separate the construction of a complex object from its representation so that the same construction process can create different representations. A different approach to building a set of related objects as a composite perhaps an object with object-valued fields. The builder object essentially calls the factory methods for each component and returns the composite. The user then calls the components through field references of that abstract composite object. Prototype Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype (5). Prototype is an alternative to the use of a constructor in object-oriented language such as Cþþ. A simple example of prototype: we can create a default linked-list node, with default data value (e.g., zero) and null as the next pointer. When we need a new node, we copy the default node (note: not just by copying the reference) and modify the fields.

3 DESIGN PATTERNS 3 Singleton Ensure a class only has one instance, and provide a global point of access to it (5). The singleton pattern is an alternative to a static object, which is a standard coding idiom in introductory programming courses. Using singleton allows inheritance and virtual methods, and it may provide more support for information hiding and self-documentation. Access is through a single static reference to the actual object. For example, in a corporate application, there is only one corporation (at a time), with various attributes such as name, address, , business plan, and so on. Rather than making these attributes static fields of a class, we can create a singleton corporation object. On the other hand, singleton has some associated costs and should not be used for all unique objects indiscriminately immutable objects and collections of properties really associated with the class rather than an object should, for example, probably be realized not as a singleton but as a set of static fields. All of the creational patterns interact at both class and object level; however, the factory method is usually considered at the class level, and the others at the object level, the factory method decides which subclasses to create, and the others are primarily used to build (or in the case of singleton, manage) objects. Structural Patterns The structural design patterns are concerned with the composition of classes and objects in structural relationships such as generalization, aggregation, and composition. Adapter Convert the interface of a class into another interface that the client expects. The adapter lets classes work together that could not otherwise because of incompatible interfaces (5). The adapter has many applications, including interacting with locale-variant services such as computing appropriate sales taxes on purchases, dealing with different database layouts when querying a federated database, and handling network traffic encrypted with different algorithms. Bridge Decouple an abstraction from its implementation so that the two can vary independently (5). For a simple example, consider a client needing line drawings with many different shapes, and there may be multiple approaches to drawing, each of which is applicable to most or all shapes. A simple implementation results in quadratic or even exponential growth in subclasses (depending on the number of implementation classes needed for each abstract object). In a bridge, each abstract object (e.g., a rectangle) references its implementation; changing the draw method or draw tool simply modifies that reference. Composite Compose objects into tree structures to represent part whole hierarchies. The composite lets clients treat individual objects and compositions of objects uniformly (5). The composite can be used to represent parse trees, complex data structures, and even deferred structured computation (in combination with the command pattern). There is some overhead to using composite instead of just a data structure, so composite should be used only where either the structure is complex or there is a need to add functionality to a data structure. Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality (5). A decorator is a reasonable way to emulate some kinds of multiple inheritance; for example, one can create various interactive windows with various graphics by decorating an abstract window, first with functionality, and then with the graphics (border, colors, font, etc.). Façade Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher level interface that makes the subsystem easier to use (5). It supports information hiding the client does not need to know all of the entry points for the service class or package; rather, all calls are made to the façade, and the façade (on the server side) will direct the call to the appropriate class and method. Flyweight Use sharing to support large numbers of fine-grained objects efficiently (5). It is used in particular to share strings, images, and similar structures, as well as immutable objects. An object pool is created for these shared objects, and each other object that contains a shared item receives a reference rather than a copy of the object, saving memory and preserving consistency by preventing data corruption. Field access is replaced by method calls not a noticeable difference where implementation style regularly uses get() and set() methods in place of field accesses. Proxy Provide a surrogate or placeholder for another object to control access to it (5). The client accesses the proxy, which controls or masks access to the object. This pattern has many uses. Some examples are as follows: for security and access control, returning an error message or default value when the client is not authorized to perform the requested action, or in database, to redirect queries to an appropriate view instead of underlying tables; to generate code or manage interaction for remote access in a distributed environment; and to add bookkeeping or other information to a reference without changing the definition of the underlying class for example, to add a reference count, or to count the number of accesses, or in the case of a query, to keep statistics on the size of the result or the time spent in computation. The adapter has both class and object variants since you may need to reference static methods or constructors, but more likely are using object methods and fields. All other structural patterns are object patterns. Behavioral Patterns The behavioral design patterns specify algorithms for operations and the assignment of responsibility for providing communication among objects. Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object

4 4 DESIGN PATTERNS a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it (5). As a real-world example, consider a customer s request to a waitress; she gives the order to the chief chef; the person who eventually fulfills the customer s request may be the assistant chef, the chief chef, or even the manager. This is also easy to see in terms of the decorator. The client knows about only the outermost decorator, but the actual information needed to handle the request may live further in, even in the base object. From the client s point of view, it is only looking for a reasonable response and is not interested in where the request was actually handled. Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations (5). Database transactions are typical examples of command combined with memento, providing all-or-nothing functionality. Command can also be used to defer actions, to queue requests from different clients (or callbacks from services), and to allow complex actions to be passed as parameters with the current state, as a closure. For example, a disk controller can reschedule requests for file access depending on process priority and the location of the data; this is only possible if there is some means of encoding and deferring requests. Interpreter Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language (5). This is very much a special-purpose pattern, used primarily to handle general user or client input, such as a complex query where there is no database management system. The application must parse the input and determine what action to take on that basis that is, form an access plan typically by using a syntax-directed translation. Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation (5). This pattern has the same purpose as the iterators or enumerations built into programming languages. As an example, one can traverse a list without knowing whether it is implemented as an array, a linked list, a binary search tree, or some even more complex data structure. Even with implementations in libraries the iterator is still useful when multiple kinds of traversal of the same data structure are needed, perhaps following different links or even requiring generation of a temporary data structure. Mediator Define an object that encapsulates how a set of objects interact. The mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently (5). Important uses include allowing peers to collaborate without knowing each other s identities or subclasses, handling complex relationships with observers (e.g., many-to-many relationships and updates triggered by complex events or conditions), and as a bidirectional analog for façade for systems such as those constructed with builder. The mediator should be used with discretion, and only if the complexity of the interaction without the mediator would be worse than the complications introduced by the mediator itself. Memento Without violating encapsulation, capture and externalize an object s internal state so that the object can be restored to this state later (5). It is commonly used to support transaction management, snapshots for statistical performance analysis, and application-supported fault tolerance and recovery. Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically (5). The observer is one of the most common and most useful patterns. It can be used, for example, to maintain the analog of the catalogue for a database. We can maintain counts on collection size by notifying an observer every time an object is added to or deleted from that collection, specifying the action, and the time for the most recent change. More complex observers can be used to implement database views, to handle events (like Java listeners), or to be triggered by complex assertions in the values of fields (e.g., to note violation of a precondition). A single object can have multiple observers, but the mediator can be used with the observer to make an observer respond to changes or events in multiple objects. State Allow an object to alter its behavior when its internal state changes. The object will appear to change its class (5). Here is an example to illustrate the concept: Consider a matrix class with conceptual subclasses for SparseMatrix and DenseMatrix. Rather than implementing subclasses directly, and needing to cast back and forth, design using the state pattern gives a matrix object a state field, which is a reference to a separate object implementing either the sparse matrix operations or the dense matrix operations. In general, a good approach for the equivalent of variant records objects with a tag and a variant part, where the tag and variant can change dynamically. The clients need not know the state, and thus, they will not know the actual method used to implement a virtual method call. Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it (5). Where state handles variation in method structure dependent on object properties or state, strategy addresses variation and dependence on system state (e.g., space-time tradeoffs) or dynamic system configuration (e.g., network routing). It can also be used to handle deadline-precision tradeoffs, or dependence on the nature and form of information supplied by services if multiple services are used. As in state, the clients need not know the actual method used to implement a virtual method call. Template Method Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. The template method lets subclasses redefine

5 DESIGN PATTERNS 5 certain steps of an algorithm without changing the algorithm s structure (5). The idea here is that multiple virtual method realizations for a given operation (function) may share most of their structure. Hoisting the common code into the superclass and inserting calls to variant parts saves code space, and more importantly, it isolates the regions that need to be modified when a new subclass is defined, or inspected, when an implementation error is found. Visitor Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates (5). Visitor is in some ways the analog of the iterator for complex structures, but visitors do not just iterate through collections; they perform an operation on the structure. Moreover, the visitor may visit and compute at the same node of a complex structure (perhaps realized with composite) several times, or short-circuit visits to some substructure as not needed for the given operation. For example, a recursive computation of the shortest path between two nodes in a graph with non-negative weights could in principle be realized by a visitor from a given node, visit a successor, and then return and update the value at the node. Once the target node is reached, or the current shortest path length is exceeded, the successors will not be explored. The interpreter and the template method are at the class level interpreter creates a new class to handle the syntax-directed translation and does not involve any objects explicitly. The template method changes method bodies in existing classes, but it does not add objects or modify the object state. All of the other behavioral patterns are objectlevel patterns. A DETAILED EXAMPLE Here is an illustrated example of using a design pattern. We solve a simple publish-subscribe problem using the observer pattern, similar to the example given by the Gang-of- Four. The Publish Subscribe Problem There is an object that holds a set of data, and other objects depend on this dataset for their own purpose. Let us call the object that holds the dataset the publisher and the other objects the subscribers. Specifically, the publisher contains a set of data, with two subscribers responsible for displaying the data in two different formats: a bar chart and a pie chart, respectively. The requirement is that whenever the publisher s data changes, the two subscribers must be informed. Then each subscriber will query the publisher to synchronize its state with the state of the publisher. To support reuse, the relationship between the publisher and the subscribers should not be tightly coupled. That is, the publisher knows about a list of subscribers, but we can add a new subscriber (e.g., a line graph) or delete any existing subscriber at any time Publisher A = 50% B = 30% C = 20% Subscriber 1 Subscriber 2 A B C Figure 1. The conceptual diagram of the publish subscribe problem. (From Ref. 5, reproduced by permission of Pearson Education, Inc.) In addition, we can modify either the publisher (e.g., add other data not being displayed) or a subscriber (e.g., change the pie chart color scheme) without affecting the other components as long as they still provide their required services to the publisher. The conceptual diagram of the relationships between the publisher and the subscribersisshowninfig.1. In this simple example, it is easy to see that the intent of the observer pattern fits the description of this problem. It defines a one-to-many relationship between an object (the publisher) and a set of other objects (the subscribers). When the state of the publisher changes, all of the other dependents of the publisher are notified, and the dependents are updated themselves automatically. Class Diagram The UML class diagram for the observer pattern is shown in Fig. 2. A class diagram shows the classes and their static relationships participating in the structure of the pattern. Four classes are shown: a Subject, an Observer, a ConcreteSubject, and a ConcreteObserver. Subject and Observer are abstract classes together with their abstract methods (abstract class and abstract method names are in italics). The Subject and Observer abstract classes are reusable and generic classes. The Subject allows implementation of its operations by ConcreteSubject class so that the ConcreteObserver objects can register themselves as observers or remove themselves from being observers. A Subject may be observed by any number of Observers. The Observer allows implementation of its operation by the ConcreteObserver class so that the ConcreteObserver objects must be notified of state changes in the ConcreteSubject object. ConcreteSubject and ConcreteObserver are concrete subclasses of Subject and Observer, respectively. The ConcreteSubject object (the subject) stores a state of interest for the ConcreteObserver objects (the observers). A C B

6 6 DESIGN PATTERNS Subject * Observer attach(observer) detach(observer) notify( ) send update( ) to all the observers update( ) ConcreteObserver ConcreteSubject subjectstate getstate( ) setstate( ) return subjectstate observerstate update( ) send getstate( ) to subject; observerstate = subjectstate Figure 2. The class diagram for the observer pattern. (From Ref. 5, reproduced by permission of Pearson Education, Inc.) Besides implementing the attach() and detach() methods, ConcreteSubject implements the notify() method, used to notify all the registered observers whenever the state of the subject changes. The ConcreteSubject can have other operations such as setstate() and getstate(). The setstate() operation is used for inquiry from an observer and get- State() operation represents a query that an observer makes to learn about the subject s current state. Similarly, the ConcreteObserver implements the update() method, and when an observer receives an update message, it maintains a state consistent with the state of the subject. It should be noted that more than one ConcreteSubject and ConcreteObserver could exist. When this observer pattern applies to the publish subscribe problem, we substitute the subject for the publisher and substitute the observers for the subscribers. The interactions between the subject and the observers are the behaviors of the publisher and its subscribers as they are described in the publish subscribe problem. As shown by the structure of the class diagram, the interdependency between subject and observers is minimum so the classes can be reused easily, since loosely coupled objects increase the reusability and modifiability of the objects in this case, the same observers can be used to provide graphs for any spreadsheet object. Sequence Diagram The UML sequence diagram is used to show a specific instance of interaction among the instance (i.e., objects) of the classes in the class diagram. Figure 3 shows the communications of one anonymous object of ConcreteSubject (the publisher) and two anonymous objects of ConcreteObserver (the two subscribers). It demonstrates the interactions between the publisher and the two subscribers. The first subscriber initiated a change request (setstate()) and wait until notified by the publisher before update occurs. When the subscriber receives an update message, it sends a message (getstate()) to the publisher to get the latest data so that the states of the publisher and :ConcreteSubject :ConcreteObserver :ConcreteObserver setstate() notify() update() update() getstate() getstate() Figure 3. A sequence diagram for the publish subscribe problem. (From Ref. 5, reproduced by permission of Pearson Education, Inc.)

7 DESIGN PATTERNS 7 the subscribers are synchronized (observerstate ¼ subject- State). The class and sequence diagrams show that in this instance, the observer pattern is used to solve the problem of displaying different charts of data from another object and satisfies the requirements specified by the problem. The design of the solution can also be carried over to implementation; program code can be generated from the class and sequence diagrams. The class diagram for the observer pattern shows the basic structure of the pattern. Variations can be made to this basic structure to accommodate additional requirements and other constraints to the publish subscribe problem. For example, the implementation of the update() operation depends on the particular ConcreteObserver to which it belongs because observers may not related to each other and they can do different processing decision in response to notification by the subject. The Gang-of-Four gives more details about the consequences, implementation, and other considerations in their description of the observer pattern. The crucial point is that many related problems can be solved by using this same design pattern, or minor variations of it. The pattern can be used, and the steps outlined above can be followed, regardless of whether we are considering graphical presentation of data, logging of shipments from a warehouse, or notifying patrons when requested library books are available. OTHER PATTERNS The GoF design patterns are generic design patterns. They are meant to solve many general problems in objectoriented software design. Since the pioneering work of the Gang-of-Four, many patterns encompass other aspects of software engineering and application domains were discovered for a broad variety of problems. For instance, Larman (7) provides general guidelines for assigning responsibilities to classes for responsibility-driven objectoriented design. For different phases of the software development lifecycle, Hagge and Lappe (8) use patterns for requirements engineering, Fowler (9) specifies analysis patterns, Binder (10) discusses patterns in testing, and Berczuk and Appleton (11) present patterns for configuration management. Buschmann et al. (12) apply patterns to software architecture. Ambler (13) collects process patterns for building large-scale systems. There are also domainspecific or feature-specific design patterns; for example, domain-specific database patterns are specified by Nock (14). Alur et al. (15) discuss enterprise patterns in the context of multitier applications. Tidwell (16) presents user interface design patterns. Even the opposite of design patterns has been investigated. As the name suggests, anti-patterns (17) are the reverse of design patterns. Design patterns represent and encode approaches to design solutions for common problems, whereas anti-patterns represent the worst practices including misuse or overuse of patterns being too clever for one s own good or destructive organizational behavior. They are valuable because they identify design temptations that need to be resisted. BENEFITS OF DESIGN PATTERNS Design patterns have obvious benefits. They enable novices and experienced users to acquire expert knowledge in design, increase software development efficiency, provide documentation, promote reuse, and facilitate communication about problems, solutions, variations, and tradeoffs. Finally, they allow designers to avoid dead-ends and suboptimal solutions. Many more patterns are sure to be discovered in the future, especially for specific domains or applications. Together with lower level structures (idioms, libraries, toolkits, and frameworks) and patterns for other aspects of software engineering, design patterns are likely to bring component-based software engineering (18) designing systems largely by composing reusable components closer to reality. Design patters are thus an important contributor in trying to fulfill the objectives of software engineering increasing software productivity, improving software quality, simplifying software maintenance and evolution, and shortening the software development lifecycle. BIBLIOGRAPHY 1. C. Alexander, The Timeless Way of Building, Oxford, UK: Oxford University Press, C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel, A Pattern Language: Towns, Buildings, Construction, Oxford, UK: Oxford University Press, E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, New York: Addison-Wesley, J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual, 2nd ed., New York: Addison- Wesley, E. Gamma, R. Helm, and J. Vlissides, Design Patterns, Pearson Education, Inc., 1995, pp. 8,9, W. Grosso, Java RMI, Sebastopol, CA: O Reilly Media, Inc., C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd ed., Upper Saddle River, NJ: Prentice Hall, L. Hagge and K. Lappe, Sharing requirements engineering experience using patterns, IEEE Software, , M. Fowler, Analysis Patterns: Reusable Object Models, New York: Addison-Wesley, R. Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools, New York: Addison-Wesley, S. P. Berczuk and B. Appleton, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, New York: Addison-Wesley, F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture: A System of Patterns, New York: Wiley, S. W. Ambler, Process Patterns: Building Large-Scale Systems Using Object Technology, Cambridge, UK: Cambridge University Press, C. Nock, Data Access Patterns: Database Interactions in Object- Oriented Applications, New York: Addison-Wesley, 2003.

8 8 DESIGN PATTERNS 15. D. Alur, J. Grupi, and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, 2nd ed., Upper Saddle River, NJ: Prentice Hall PTR, J. Tidwell, Designing Interfaces: Patterns for Effective Interaction Design, Sebastopol, CA: O Reilly Media, W. J. Brown, R. C. Malveau, W. H. Brown, H. W. McCormick, III, and T. J. Mowbray, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, New York: Wiley, G. T. Heineman and W. T. Councill, Component-Based Software Engineering: Putting the Pieces Together, New York: Addison-Wesley, FURTHER READING C. Alexander, The origins of pattern theory: the future of the theory, and the generation of a living world, IEEE Software, , E. Braude, Software Design: From Programming to Architecture, New York: Wiley, E. Freeman and E. Freeman, Head First Design Patterns, Sebastopol, CA: O Reilly Media, C. Horstmann, Object-Oriented Design & Patterns, 2nd ed., New York: Wiley, J. Kerievsky, Refactoring to Patterns, New York: Addison-Wesley, A. Shalloway and J. R. Trott, Design Patterns Explained: A New Perspective on Object-Oriented Design, 2nd ed., New York: Addison-Wesley, CYRIL S. KU William Paterson University Wayne, New Jersey