Diplomarbeit, 2007, 108 Seiten
List of Figures
4.1 The semiotic triangle (inspired by [52, 1]) . . . . . . . . . . . 20
5.1 Screenshot of the Prot´ eg´ e ontology editor . . . . . . . . . . . 30
6.1 The parent classes of the three hierarchies Design Patterns, Design Problems and Problem Concepts. . . . . . . . . . . . . 44
building blocks and means of reuse in software design. A design pattern “systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems” . While the GOF-book “only” contains 23 design patterns, the authors state that “it might be hard to ﬁnd the one (design pattern) that addresses a particular design problem especially if the catalogue is new and unfamiliar to you.” . This statement has become particularly signiﬁcant with the emergence of new design patterns since the publication of the GOF-book in 1995. Current design patterns have appeared in speciﬁc application domains (J2EE patterns [10, 11, 25], User-Interface patterns ), as language dependent patterns (also called idioms), as patterns at diﬀerent abstraction levels (analysis, architectural patterns), or simply as large collections of design patterns in pattern catalogues [17, 50]. The mere number of available design patterns complicates the decision-making which design pattern to choose and demands tools assisting in this process. In addition, the structure of design pattern representations in pattern catalogues as narrative text serves as documentations to be read by humans. It is not a suitable representation to be used by tools. For this reason, a knowledge-based formal representation of design patterns is needed, a representation that is accessible by tools.
The goals of this work are:
• to classify the 23 GOF design patterns with respect to their intent,
• to derive an ontology formalizing the developed classiﬁcation,
• to build a prototypical tool using the ontology that suggests design patterns for given design problems.
The rest of this work is organized as follows: Chapter 2 describes related work. This work either presents approaches of classifying design patterns according to diﬀerent criteria or it presents approaches of formalizing the structure of design patterns by means of ontologies and other formal languages. Chapter 3 introduces the concept of design patterns. We furthermore present the intent and the applicability of the 23 GOF design patterns. Chapter 4 introduces ontologies. We give a deﬁnition and present some of the established ontology languages. Chapter 5 presents tools that are used in ontology engineering. This includes the ontology editor Prot´ eg´ e, reasoners and query languages for querying the ontology. In Chapter 6 we describe the development of the Design Pattern Intent Ontology. Domain and scope of the ontology are conﬁned, the methodology of the development process is introduced and important concepts of the ontology are enumerated. Chapter 7 presents the evaluation of the developed ontology. In Chapter 8 we introduce the idea of the Design Pattern Wizard, a tool utilizing the developed ontology. We describe the architecture, design decisions and some features of the user interface. Finally, Chapter 9 discusses the results of this work and presents ideas and prospects on future work.
Creational class patterns defer a part of object creation to subclasses, whereas creational object patterns defer it to another object. Structural class patterns use inheritance to build a structure whilst structural object patterns use object reference for the same purpose. Behavioral class patterns distribute responsibility using inheritance to describe control ﬂow and the handling of algorithms whereas behavioral object patterns use cooperating objects to carry out a task that no single object can carry out alone.
Zimmer  takes the graph of relationships as a base of his work. He enhances the relationship graph from  by adding classiﬁcations to the relationships. He deﬁnes three categories of these connections: help to solve the problem that is addressed by X. Y can be used as part of the solution of X. A development tool can utilize this knowledge by checking the relationship in existing designs.
• X is similar to Y indicates a similarity in the problem solved by pattern X and Y. Thus, this relationship indicates an alternative or a choice of design patterns.
• The relationship X can be combined with y can help in ﬁnding other design patterns which are useful to combine with an existing one and thereby supports the retrieval of design patterns from catalogues.
• The layer Basic design patterns and techniques contains many patterns that are connected by other patterns from higher layers by
2.1. CLASSIFICATION OF DESIGN PATTERNS 5
uses-relationships. This means that the basic patterns help other patterns to solve their subproblems. tains more speciﬁc patterns with respect to the lower level. It is not used by patterns from the basic layer, but from patterns of the same layer and above. contains the most speciﬁc patterns. Thus, it contains only one pattern from the general purpose GOF-catalogue, the Interpreter design pattern.
Noble in  takes a similar approach Zimmer’s in classifying design patterns according to the relationships between patterns. He identiﬁes three main relationships: uses, refines and conflicts:
• The refines-relationship denotes that one pattern is a specialization of a more general, more simple, or more abstract pattern. We can say that X extends pattern Y. This relationship is similar to the inheritance mechanisms of object oriented programming languages.
• The conflicts-relationship implies that patterns provide mutually exclusive solutions to similar problems. A design pattern that conﬂicts with another one is an alternative solution for the same problem. For example, the Factory Method design pattern conﬂicts with the Prototype pattern because both provide a solution to the problem of subclasses redeﬁning the classes of objects created in superclasses.
The relationships Noble developed are useful to relate diﬀerent patterns to each other. When a software developer has found an appropriate design pattern for his design problem he could review related patterns to ﬁnd possible alternatives. However, these relationships do not help the software developer with ﬁnding this initial pattern.dent parts such that the parts can be built, changed, replaced, and reused independently;
• variant management whose patterns treat diﬀerent but related objects uniformly by factoring out their commonalities;
• state handling whose patterns allow the generic manipulation of object state;
• control whose patterns are used to control execution and method selection;
• virtual machine whose patterns simulate processors and interpret the grammar of a language;
• convenience patterns that are used to simplify coding by placing often-repeated code into a common place;
• compound patterns whose patterns themselves are composed of other design patterns;
• concurrency which controls parallel and concurrent execution, and
• distribution whose patterns solve problems germane to distributed systems.
2.2. ONTOLOGICAL AND OTHER FORMAL APPROACHES 7
Another interesting work was done by Birukou et al. in 2006 . Their motivation is the unexperienced programmer who wants to choose the right design pattern for a given design problem. Instead of concentrating on an organizing principle for a pattern catalogue, they developed a system that assists the programmer in the choice of the right pattern. The system suggests a pattern based on the decision that other programmers have made in choosing a suitable pattern. This approach instruments the social and community aspects of programming. However, the authors assume a formal or semiformal description of the design problem to exist. Moreover, the system only works after the learning phase of the system is completed, i.e. a suﬃcient number of experienced programmers have contributed to the history of the selection process. The authors also have not evaluated the system with real users yet. It remains to be seen how good the system works in a real setting.
Henninger et al.  is using an ontology-based metamodel to for- describe software patterns. The goal is to develop intelligent tools that provide a computational basis utilizing software patterns. As an use case they mention usability patterns. They base their core metamodel on properties such as hasProblem, hasSolution, hasContext, hasRationale, hasForces, properties that are developed from the original structure of the pattern description of . They extend the core metamodel with properties that describe the relationships between patterns, such as uses, requires, alternative, and conflictsWith. The ontology they have developed does not so much concentrate on the support of selecting a suitable pattern for a given problem, but rather on the relationships between patterns. Furthermore, Henninger et.al. concentrate on the domain of usability patterns of web sites, but not on GOF patterns or design patterns in general. The main goal of their work is to deﬁne a shareable vocabulary in the domain of usability patterns. Furthermore, they do not describe how to query their ontology, nor do they describe how to model design problems in an ontology. A very similar approach to  is . They use ontologies to formalize hypermedia and web design patterns. The vocabulary is almost identical to  but includes additional concepts such as PatternComponent, Category, Problem and Solution. The scope of their work is the support of and an integration into hypermedia design tools.
The work of Dietrich et al.  uses OWL to formally describe design patterns. However, only the structure of design patterns is considered, not the intent or applicability. They use their ontology to detect patterns in a piece of software, not to help in the selection process of a design pattern. Other approaches that use formal languages to describe the structure of design patterns include  who developed a design pattern modeling language DPML, and [43, 53]. What is common to all this work is the sole concentration on the structural aspects of design patterns and the omission of the intent of design patterns.
The intent of Abstract Factory is to “provide an interface for creating families of related or dependent objects without specifying their concrete classes”. Abstract Factory belongs to the group of Creational Patterns. The main focus of the pattern lies in the creation of product families. A typical example is the creation process of diﬀerent look-and-feel classes for graphical user interfaces (GUI). There, the Abstract Factory interface provides the methods for creating the diﬀerent theme widgets, and concrete factories are responsible for creating concrete widget classes of a speciﬁc theme. Clients are isolated from the product creation process, the responsibility of it is encapsulated in the concrete factory. This makes it easy to exchange complete families of products, by simply exchanging a single concrete factory. On the other hand, it is diﬃcult to add new kind of products, because in this case the interface of the abstract factory has to be changed or extended. Furthermore, all concrete factories that have implemented the Abstract Factory interface have to be altered as well.
The intent of Builder is to “separate the construction of a complex object from its representation so that the same construction process can create diﬀerent representations”. The Builder belongs to the group of Creational Patterns. The pattern is applicable when the construction process should be independent of the representation of a complex object. This enables the existence of several representations of the complex object, without revealing the internal structure of the creation process. Often, the Builder is used for converters. Each converter encapsulates the process of creating a complex object. Clients can use diﬀerent converters through a single interface. The Builder pattern serves a similar purpose as Abstract Factory in constructing complex objects. However, the Builder focusses more on constructing a complex object step by step, while the Abstract Factory constructs families of products.
The Factory Method “deﬁnes an interface for creating an object, but lets subclasses decide which class to instantiate”. It belongs to the group of Creational Patterns and enables classes to defer the instantiation process to subclasses. It is therefore also called a virtual constructor. Often, this pattern is used together with the Abstract Factory as the method that actually creates concrete classes. The Factory Method pattern can be applied when classes responsible for creating objects do not know the class of these objects and subclasses should be able to decide which objects to create. Thispattern is often used in frameworks and class libraries.
3.1. THE GOF PATTERN CATALOGUE 11
The Prototype pattern “speciﬁes the kinds of objects to create using a pro- instance, and creates new objects by copying this prototype”. It belongs to the group of Creational Patterns. The key idea in this pattern is to create new instances of classes by copying (“cloning”) a prototypical instance. Thereby, the prototypical instance is getting copied and parameterized with new values. The Prototype pattern is a competing pattern to Abstract Factory, but it can also used by Abstract Factory in providing new cloned instances from a prototypical object. The Prototype pattern is applicable when new instances of classes are expensive to create and all objects are similar to each other or when instances of classes only have a few diﬀerent combinations of state.
The Singleton “ensures a class only has one instance, and provides a global point of access to it”. It belongs to the group of Creational Patterns. Whenever it is important for a class that only one object is created from it, the Singleton pattern is the right choice. It provides a global view on this object and a well-deﬁned access point for other objects. The Singleton has full control over how and when the single object is accessed. It can also be used to create more than one instance of a Singleton. In this case, the pattern controls how many instances are allowed of this class. The pattern is the implementation basis for many other patterns such as Abstract Factory, Builder and Prototype.
The Adapter “converts the interface of a class into another interface clients expect”. It belongs to the group of Structural Patterns. Often, the Adapter is used in the domain of toolkits and frameworks. Communication between classes is based on well-deﬁned interfaces. These interfaces cannot be altered easily, because often they are provided by a third party. The Adapter pattern enables classes with incompatible interfaces to work together by adapting one interface to the other. Another application area of the Adapter is the design of reusable classes that must be able to cooperate with unrelated or unforeseen classes.
The intent of Bridge is to “decouple an abstraction from its implementation so that the two can vary independently”. It belongs to the group of Structural Patterns. The Bridge pattern enables the separation of an abstractionfrom its implementation. This can be useful, if there is the need for more
The intent of Composite is to “compose objects into tree structures to repre- part-whole hierarchies”. It belongs to the group of Structural Patterns and allows clients to treat single objects as well as compositions of objects uniformly. The Composite pattern is applied whenever part-whole hierarchies are needed and to represent tree structures. The key idea of the Composite pattern is to represent both primitive objects and their containers through an abstract interface. The operations deﬁned in the abstract component interface deﬁnes methods for both handling primitives and composite objects in a uniﬁed way. The Decorator is often used together with Composite. In such a design, an abstract class will have some subclasses that are Decorators, and some that are Composites. While Composite is responsible for the object aggregation, Decorator adds, alters or extends responsibilities.
The Decorator pattern “attaches additional responsibilities to an object dy- It belongs to the group of Structural Patterns and depicts a ﬂexible alternative to subclassing for extending functionality of a class. This is especially useful if the additional functionality is not needed for every instance of a class, but only for individual objects. Because Decorators use the same interface as the class to be decorated, the decoration of an object is transparent to the client. Decorator delegates calls to the client by either only forwarding these calls or performing additional operations before forwarding. One disadvantage is that every method deﬁned in the interface has to be forwarded whether it is being altered or only forwarded. Whereas Adapter changes the interface of an object, Decorator leaves the interface the same but changes the object’s responsibility.
The intent of Facade is to “provide a uniﬁed interface to a set of interfaces in a subsystem”. It belongs to the group of Structural Patterns. A facade is a higher-level interface that eases the use of a subsystem by providing a
3.1. THE GOF PATTERN CATALOGUE 13
The intent of Flyweight is to “use sharing to support large numbers of ﬁne- objects eﬃciently”. It belongs to the group of Structural Patterns. This pattern is useful when a large amount of objects is needed in an application, but the naive implementation would result in a high cost of memory. For example, the terminal symbols of the abstract syntax tree of an Interpreter can be shared by using Flyweights. A Flyweight is a shared object that encapsulates some state that can be shared across some context. It is useful when the outsourcing of this state results in a decline in the number of objects needed.
The intent of Proxy is to “provide a surrogate or placeholder for another object to control access to it”. It belongs to the group of Structural Patterns and defers the control of an object to a proxy object. The Proxy pattern can be used when the cost of creation and initialization is expensive. The Proxy pattern can defer the creation process until the object is actually needed. The Proxy object acts as an image that stands for the real object. There are several other use cases when to use Proxy: a protection proxy restricts the access of the original object, when objects have diﬀerent access rights. A proxy can also be used as a smart reference to the original object by counting the number of references and freeing the object when there are no more references. A buﬀer proxy caches the access to the original object, a logging proxy logs the access and a remote access proxy provides the access to a remote object.
The Chain of Responsibility “avoids coupling the sender of a request to its receiver by giving more than one object a chance to handle the request”. It belongs to the group of Behavioral Patterns. By chaining receiver objects that are all able to handle the request, Chain of Responsibility decouples
The intent of Command is to “encapsulate a request as an object, thereby letting us parameterize clients with diﬀerent requests, queue or log requests, and support revocable operations”. It belongs to the group of Behavioral Patterns. The Command pattern is applicable as an objectiﬁed callback function, when the creation of a command is not chronologically coupled with the execution of it, or if the execution of the command takes place in a diﬀerent context. For example, an action is triggered in a user interface in response to some user input. If the action is put into a command object, the object can be passed around like any other object and can be executed in another part of the application. Mementos can be used together with the Command pattern to maintain state for revocable operations.
The intent of Interpreter is to “deﬁne a representation for the grammar of a given language along with an interpreter that uses the representation to interpret sentences in the language”. It belongs to the group of Behavioral Patterns. A recurring problem such as the searching for strings can be expressed as a simple language. The grammar of this language can be interpreted by the Interpreter pattern. Interpreter deﬁnes the grammar, represents sentences in this language and does the interpretation of them. This pattern makes it easy to change or extend the grammar of languages. Interpreter is applicable when the grammar is simple and eﬃciency is not a critical concern.
Der GRIN Verlag hat sich seit 1998 auf die Veröffentlichung akademischer eBooks und Bücher spezialisiert. Der GRIN Verlag steht damit als erstes Unternehmen für User Generated Quality Content. Die Verlagsseiten GRIN.com, Hausarbeiten.de und Diplomarbeiten24 bieten für Hochschullehrer, Absolventen und Studenten die ideale Plattform, wissenschaftliche Texte wie Hausarbeiten, Referate, Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Dissertationen und wissenschaftliche Aufsätze einem breiten Publikum zu präsentieren.
Kostenfreie Veröffentlichung: Hausarbeit, Bachelorarbeit, Diplomarbeit, Dissertation, Masterarbeit, Interpretation oder Referat jetzt veröffentlichen!