Previous article

Next article


Object-Oriented Design Patterns for Detailed Design

W. Al-Ahmad, NYIT - Bahrain Campus, School of Engineering and Technology, Manama, Bahrain

space ARTICLE

PDF Icon
PDF Version

Abstract
This paper discusses the use of design patterns during the transition phase from analysis to design of object-oriented systems. Pattern mining, which is the process of finding and documenting design patterns, usually takes place during or after the development of a software system. This paper introduces several new design patterns that were discovered through the experience of teaching object-oriented analysis and design in both industry and academia. These are low level design patterns that can be used in almost every application. Finally, a tool will be proposed to automate the application of these patterns when creating a detailed design model.


1 INTRODUCTION

There is increasing pressure on software developers to produce quality software in as short a time as possible. This necessitates the reuse of previously developed or commercially available software elements to expedite the development process. The most common form of reuse is the reuse of code in a fine-grain manner such as objects in the object-oriented paradigm or a large-grain manner such as components in the component-oriented paradigm. With the advent of design patterns [Gamm95] and the pattern-oriented software development methodologies, techniques, and principles [Busc01, Fowl97, Lee03, Shal02, Yaco04], the reuse of designs became possible. Reuse of designs is not as popular as reuse of code because the pattern-oriented approach for software development is still in its infancy. Moreover, constructing generic designs to be later instantiated is a complex issue. There is still a long way to go before pattern-oriented design becomes mainstream with fully-fledged methodologies, tools, and principles.

Usually, the software development life cycle includes the phases of analysis and design regardless of the methodology used (waterfall, iterative, etc.) in the development of the software. This paper follows the Rational Unified Process (RUP) [Rati00] for software development and uses its terminology. RUP is an object-oriented software engineering process that is iterative and incremental. In RUP, analysis and design is one discipline that aims at transforming the requirements of the system into a design of the system to be built and to adapt the design to match the implementation environment [Rati00]. Understanding and documenting the requirements of the system is the purpose of the requirements discipline, which precedes the analysis and design activities.

Although the line between analysis and design is blurred, there are activities that belong to analysis and other activities that belong to design. Identifying key abstractions of the problem domain and creating a conceptual model are analysis activities, while refining the conceptual (analysis) model by adding more information to it (adding attributes, mapping class responsibility to operations, etc.) are design activities. Refining association multiplicity, adding extra operations related to nonfunctional requirements, optimizing the design model to easily map it to the target language are required to create a detailed design. The focus of this paper is on mining design patterns that recur during these activities. Whereas the majority of the design patterns in the literature focus on high level process activities [Busc01, Gamm95, Larm02, Shal02], the patterns introduced in this paper are low level patterns, focusing on low level design activities. In fact, the patterns introduced in this article can be used in detailing the high-level design patterns.

This paper is structured as follows: section 2 briefly explains the problem statement and introduces a conceptual model to model the problem domain. This conceptual model will form the context of the discovered patterns. Section 3 introduces the concept of design patterns and their importance in the development of good design models. Section 4 discusses the new patterns and presents a catalog of these patterns. Section 5 discusses a tool support for automating the incorporation of these patterns into a detailed design model. Finally, section 6 introduces some conclusions and glimpses about future work.

2 CASE STUDY: STUDENT REGISTRATION SYSTEM

This paper uses an on-going example to create a context for the different patterns that will be mined from it. This example is related to the development of a student registration system for a university [Rati00]. To better understand the design models that will be presented in this paper, the relevant part of the problem statement is stated below:

A student registration system is needed that will allow students to register for courses and view report cards. Professors will be able to access the system to sign up to teach courses as well as record grades. The system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case the student cannot be assigned to a primary selection. For each semester, there is a period of time that students can change their schedule by adding or dropping courses [Quat00].

It is not the objective of this paper to explain the different activities involved to produce the analysis model shown in Figure 1. At the end of the Use Case Analysis activity in RUP, a VOP (View of Participating Classes) or a conceptual model is produced. The VOP is basically a UML class diagram. In Figure 1, the VOP is limited to the key abstractions in the problem domain (entity classes in RUP terminology); it is just a subset of the actual conceptual model produced for the problem at hand. The control and boundary classes are not shown in the diagram since the patterns are independent of the type of class involved.

Conceptual models and design models should not be developed independently. In RUP, the analysis model evolves to become the design model; the two models are not independent or separate. Object-oriented analysis is supposed to model the problem space; object-oriented design then models the solution space. In the current state of the art, the transition from a conceptual model into a design model is done manually. Typically, people first develop a conceptual model, and then start developing a design model from scratch without a proper binding between both models. In fact, the analysis phase is often skipped in practice, or only a brief study of the problem domain is carried out before turning to the design. This is an inappropriate approach to software development. This way of working does not address the evolutionary nature of the software life-cycle because of problems in traceability between the two phases.

Figure 1: Partial Analysis Model for the Registration System

3 PATTERN-ORIENTED DESIGN

Before we go any further, it is imperative to first define the concept of a design pattern. The GoF book [Gamm95] defines design patterns as "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context." A design pattern names, abstracts, and identifies the key aspects of a common design structure that makes it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and their instances, their roles and collaborations, and the distribution of responsibilities. Each design pattern focuses on a particular object-oriented design problem or issue. It describes when the pattern applies, whether or not it can be applied in view of other design constraints, and the consequences and trade-offs of its use. Since we must eventually implement our designs, a design pattern also provides a sample code to illustrate an implementation. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all aspects of software development.

Patterns for software development are one of the latest emerging approaches for software design. Recent work [Yaco04] has recognized the importance of object-oriented design patterns and introduced a methodology for software development with patterns. This paper views object-oriented design as a pattern-based software process in which different types of patterns are successively applied to software artifacts. Each pattern captures a solution to a common object-oriented design problem that is imposed by a particular structure.

In the literature, there are different description formats for documenting design patterns [Gamm95, Larm02, Shal02]. The description of a design pattern might include items such as the name, problem addressed, context or applicability, forces, solution, structure, etc. In this paper, the description will be limited to the 4 basic elements: context-problem-solution-structure:

  • Context: the preconditions under which the problem and its solution seem to recur, and for which the solution is desirable. It can be thought of as the initial design before the pattern is applied to it. Context refers to a recurring set of situations in which a pattern applies. The context of the patterns described in this paper is clear from the analysis model given in Figure 1 and therefore will not be included in the pattern description.
  • Problem: a statement of the problem which describes its intent: the goals and objectives it wants to reach within the given context. Often the problem includes the applicability of the pattern. It could be phrased as a question.
  • Solution: static relationships and dynamic rules describing how to realize the desired outcome, i.e., solve the problem. Sometimes possible variants or specializations of the solution are also described.
  • Structure: describes the static structure of the pattern in terms of classes and their associations. It is usually shown using a UML class diagram.

4 THE CATALOG OF DESIGN PATTERNS

This section presents some patterns that capture solutions to problems that frequently occur (within structures, i.e. relations that exhibit the property of existential dependency and constraints of multiplicity) during software design. These patterns may specify a baseline for developing a design pattern language for detailed design.

The design model of every software application has to deal with associations among classes. An association is a structural relationship that specifies that objects of one class are connected to objects of another class. An association can be decorated with multiplicity, role names, and an association name. The multiplicity determines the minimum and maximum number of objects of one class that can be linked with one object of the other class. Each end of an association has one multiplicity. It has also a role name (optional) which determines the role that a class plays in the association. During detailed design, an association may be refined into a dependency, an aggregation, or a composition relationship. In this section, the author will identify a few patterns related to the refinement of associations and their decorations such as multiplicity refinement. The quest for the patterns will result in discovering a few low level structural and behavioral patterns.

Structural patterns address issues concerned with the way in which classes are organized. To describe such patterns, object-oriented constructs and mechanisms such as inheritance, composition, aggregation, etc. are usually used. An example of such patterns is the Composite Pattern [Benn02]. Behavioral patterns, on the other hand, address the problems that arise when mapping responsibilities to operations in classes and when designing algorithms for the operation implementation. They usually describe how objects communicate to perform the system functionality. An example of such patterns is the State Pattern [Benn02].

Multiplicity Refiner

One-to-many relationships are very common in object-oriented models. In the model shown in Figure 1, many classes are associated with other classes with multiplicity 0 .. *. This means that zero or more objects of one class are associated with one object of the other class participating in the same relationship. For example, a professor may teach one or more course sections and no sections at all if he or she is on sabbatical. This multiplicity needs to be refined during the class design activity of RUP. This requires the introduction of a container class with operations to add and remove objects from the container. It might have operations to check the number of objects in the container, and maybe iterator operations. The Multiplicity Refiner pattern will help achieve this task.

Problem:

How to refine a one-to-many relationship between two classes during class design?

Solution:

The solution of this problem is obtained by introducing a container class to store the objects of the class that must be linked with the object of the other class. The container couples a participating object with an unlimited number of refined objects. The container class should add operations to retrieve the information needed from the container object.

Structure:

Figure 2 illustrates the structure of this pattern involving class A whose objects are associated with an unlimited number of objects of class B. The container class BList is added to store the objects of class B which are associated with one object of class A.

Figure 2: Structure of the Multiplicity Refiner Pattern.

Example:

Given the following portion of the model shown in Figure 1:

Applying the Multiplicity pattern produces the model in Figure 3:

Figure 3: Application of the Multiplicity Refiner Pattern.

Genericity Refiner

Usually common container classes, such as List, are available from existing libraries. These classes can be used and should not be modeled. The container class of the Multiplicity Refiner can instantiate a parameterized (generic) class if the implementation language provides generic container classes.

Problem:

How can a container class be mapped to a standard generic class in the implementation language during class design?

Solution:

Instantiate the standard container class using the refined class (whose objects must be contained) as the parameter.

Structure:

Figure 4 illustrates the structure of this pattern involving class List which is assumed to be a standard container class provided by the target language. The objects contained in the container class are objects from class B.

Example:

Given the model shown in Figure 3, the application of the Genericity Refiner pattern will produce the model in Figure 5.

Figure 5: Application of the Genericity Refiner Pattern.

Optionality Refiner

In addition to showing the number of objects participating in a relationship, multiplicity answers the question whether or not the relationship is optional. This is usually indicated by using the multiplicity of 0..1.

Problem:

How can optional relationships given by the 0..1 multiplicity be refined during class design?

Solution:

Add the following operations to manipulate an optional relationship:

  • addRefinedObject: to attach an object of the refined class to the object of the other participating class.
  • removeRefinedObject: to detach the refined object from the other participating object.
  • isRefinedObjectAssigned: to check if a refined object is attached to the other participating object.

Structure:

Figure 6 illustrates the structure of this pattern.

Figure 6: Structure of the Optionality Refiner Pattern.

Example:

Applying the Optionality Refiner pattern to the following association would produce the model in Figure 7.

Figure 7: Application of the Optionality Refiner Pattern.

Association Class Refiner

When an attribute belongs to the association rather than to any of the two participating classes, an association class is added to include such an attribute. Figure 8 illustrates this by adding the association class PrimaryScheduleOfferingInfo to include the grade attribute.

Figure 8: Association Class ScheduleOfferingInfo.

Problem:

How can an association class be refined during class design?

Solution:

Insert the association class between the two participating classes and switch multiplicities.

Structure:

Figure 9 illustrates the structure of this pattern involving the asscoiation class C with an attribute associationAttr which belongs to the association between class A and class B.

Figure 9: Structure of the Association Class Refiner Pattern.

Example:

Applying the Association Class Refiner pattern to the situation depicted in Figure 8 would produce the model in Figure 10.

Figure 10: Application of the Association Class Refiner Pattern.

Dependency Selector

Dependency is a relationship between two model elements in which a change to one element (the supplier) may affect or supply information needed by the other element (the client) [Rumb05]. During analysis, many of the relationships between classes ar assumed to be structural relationships (associations). During detailed design, it should be decided what type of relationship is required; i.e. a structural or non-structural (dependency) relationship. A dependency relationship is the cheapest to maintain, easiest to utilize and benefits from the principle of encapsulation. Therefore, an association needs to be replaced by a dependency whenever possible. Usually, this step should be done after the define operations and methods step of class design in RUP, where the signature of each operation is fully specified and the algorithms for implementing the operations are determined. All non-field (local, global, parameter) visible associations should be replaced by dependency. One type of dependency relationships is addressed by the current pattern.

Problem:

When can an association be replaced by a dependency during class design?

Solution:

One case that is clear is between a container class and a class whose objects are supposed to be contained.

Structure:

Figure 11 illustrates the structure of this pattern.

Figure 11: Structure of the Dependency Selector Pattern.

Example:

Applying the Dependency Refiner pattern to the situation depicted in Figure 5 would produce the model in Figure 12.

Figure 12: Application of the Dependency Selector Pattern.

Navigability Refiner

The navigability property on an association end indicates that it is possible to navigate from one class to the target class using the association. An arrowhead on the association end is used to show the navigable association direction. During analysis, the arrowheads are suppressed, meaning that associations are navigable in both directions. However, during class design, navigability should be reduced to one-way whenever it is possible because two-way associations are more expensive to implement. Representing a relationship between objects should be explicit, i.e., defining direction of navigation. It is usually not an easy task to determine the direction of navigability. However, it is clear in some cases such as a whole-part relationship, where the navigability is usually from the whole to the part. Another case is addressed by the current pattern.

Problem:

How can association navigability be determined during class design?

Solution:

One case is a one-to-many association, where the navigability is from the class representing the one to the class representing the many.

Structure:

Figure 13 illustrates the structure of this pattern.

Figure 13: Structure of the Navigability Refiner pattern.

Example:

Applying the Navigability Refiner pattern to the situation depicted in Figure 3 would produce the model in Figure 14.

Figure 14: Application of the Navigability Refiner pattern.

5 TOOL SUPPORT

Having introduced a catalog of design patterns for detailed design activities in the previous section, the need for a CASE tool that will automate their usage, i.e., transformations is discussed in this section. Moreover, the key elements and requirements for such a tool will be identified. In fact, there is no lack of pattern catalogs in the literature that span all activities of software development: requirements specification, analysis, design, implementation, architecture, etc. There is however a lack of successful supporting CASE tools and methodologies that facilitate the construction of software from patterns.

Automated tool support for object-oriented methods is vital to the development of today’s complex software systems. In fact, there is consensus on the importance and suefullness of tool support for patterns [Brag03, Budi96, Corn00, Flor97, Mape02]. Currently the pattern-based approach is done manually. Composing design patterns to develop application designs is a tedious task that involves integration of patterns. A tool support for development with patterns will eventually facilitate the analysis and design phases. It is believed that such automated tools will help designers concentarte on the big picture.

In fact, the majority of existing tools to support design patterns focus on support for high level patterns. For example, the tool proposed in [Yaco00] aims to integrate patterns at the architecture level. On the other hand, the tool proposed in this article aims to integrate design patterns such as the patterns described in this article at the detailed design level. One of the advantages of having tool support for detailed design activities is expedite the design phase. Even though such a tool can never replace a human expert, it can help him to identify types of design patterns that can be used to solve a particular design problem. The tool can also help to compare design alternatives by evaluating each alternative in terms of quality factors and by evaluating the results.

The ultimate objective is to develop an approach that scales up to large industrial software systems. Our aim is to improve the software development process by focusing on the cyclic and evolutionary nature of the software life cycle. The focus of this paper is on developing patterns of relationships between classes and objects that define preferred solutions to common object-oriented design problems. The next step, work already started, will be the development of a prototype of a tool (wizard) that will take an analysis model and transform it to a detailed design model. Such a tool will allow a designer to select an association from an analysis model and then apply any of the described patterns. The tool will automatically replace the classes with the necessary refined classes and their operations.

An advantage of using the patterns introduced in the previous section is that they make the design model close to the implementation model, thereby facilitating optimal code generation for a target language. Note that no new language constructs are needed to implement these patterns in the target language. A disadvantage of implementing these patterns, on the other hand, is that the design model will become bigger and therefore more complex. This necessitates the use of a tool to introduce the patterns and manage the model. Moreover, the tool will allow the designer the option of viewing the model with or without these low level patterns.

The tool being developed is meant to be integrated with an object-oriented software modeling tool to fully benefit from the patterns discussed in this article. This can be achieved by extending an existing visual modeling tool such as IBM Rational Rose with the functionality provided by this tool. In this case, the work to be done to include support for automatic implementation of these patterns would be minimal.

6 CONCLUSIONS AND FUTURE WORK

This paper has introduced a catalog of patterns for detailed design. The catalog consists of six related patterns that recur in every application. This pattern catalog can form the basis of a pattern language for detailed design. The pattern catalog is not complete in the sense that it can be extended with other patterns for generalization/specialization relationship as well as the refinement of association into dependency, aggregation, and composition relationships. It is believed that such a pattern language will help create detailed design models that are close to the implementation language, which will facilitate the generation of code from the design model easily and more efficiently. A CASE tool is being designed to automate the transformation of an analysis (initial design) model to a detailed design model using the proposed pattern catalog. Such a tool will improve the productivity of the developers and shorten the time needed to complete the design.


REFERENCES

[Benn02] Bennett S. et al, “Object-Oriented Systems Analysis and Design Using UML”, McGrawHill, 2002.

[Brag03] Brag R. and Masiero P, “Building a Wisard for Framework Instantiation Based on a Pattern Language”, Proceedings of OOIS 2003, 2003.

[Budi96] Budinsky F. et al, “Automated code generation from design patterns”, IBM Systems Journal, 1996.

[Busc01] Buschman F. et al, “Pattern-Oriented Software Architecture”, Wiley, 2001.

[Corn00] Cornils A. and Hendin G., “Tool Support for Design Patterns based on Reference Attribute Grammers”, Proceedings of WGA00, 2000.

[Flor97] Florijn G. et al, “Tool support for object-oriented patterns”, Proceedings of ECOOP’97, 1997.

[Fowl97] Fowler M., “Analysis Patterns: Reusable Object Models”, Addison-Wesley, 1997.

[Gamm95] Gamma E. et al, “Design Patterns: Elements of Reusable Object-Oriented software”, Addison-Wesley, 1995.

[Larm02] Larman C., “Applying UML and Patterns”, Prentice Hall, 2002.

[Lee03] Lee T. et al, “Object-Oriented Design of RTI Using Design Patterns”, Proceedings of OOIS2003, 2003.

[Mape02] Mapelsden D. et al, “Design Pattern Modeling and Instantiation using DPML”, Proceedings of Tools Pacific’02, 2002.

[Quat00] Quatrani T., “Visual Modeling with Rational Rose 2000 and UML”, Addison-Wesley, 2000.

[Rati00] Rational University, “Object-Oriented Analysis and Design Using UML, Student Manual”, Version 2000, Part# 800-011765-002, 2000.

[Rumb05] Rumbaugh J. et al, “The Unified Modeling Language Reference Manual”, Second Edition, Addison-Wesley, 2005.

[Shal02] Shalloway A. and Trott J., “Design Patterns Explained”, Addison-Wesley, 2002.

[Yaco00] Yacoub S., Xue H., and Ammar H. “Automating the Development of Pattern-Oriented Designs for Application Specific Software Systems”, Proceedings of ASSET’00, 2000.

[Yaco04] Yacoub S. and Ammar H., “Pattern-Oriented Analysis and Design”, Addison-Wesley, 2004.

About the author





Walid Al-Ahmad is an associate professor of Computer Science. He is currently working at New York Institute of Technology - Bahrain Campus. He is the coordinator for the School of Engineering and Technology. His research centers around improving support for object-oriented concepts and principles in OOPLs as well as new emerging software approaches such as components, design patterns and web services. He can be reached at w.alahmad@nyit.edu.bh

 


Cite this article as follows: W. Al-Ahmad: “Object-Oriented Design Patterns for Detailed Design”, in Journal of Object Technology, vol. 5, no. 2, March-April 2006, pp. 155-169 http://www.jot.fm/issues/issue_2006_03/article3


Previous article

Next article