Index terms: Object oriented design, design patterns, theoretical foundations, software architecture ..... A more suitable specification language would impose a constraint, such as: First- ...... Thus, for instance, the relation β+ is represented by adding a double arrow head to ..... http://www.math.tau.ac.il/~eden/dissertation.pdf.
MOTIFS IN OBJECT ORIENTED ARCHITECTURE Amnon H. Eden,i Joseph (Yossi) Gilii Yoram Hirshfeldiii Amiram Yehudai iv
Abstract We observe recurring, fundamental motifs in object oriented architectures, discuss the possibility of their rigorous representation, and offer criteria for the evaluation of possible languages for their specification, such as expressiveness and completeness. We define a symbolic logic language, LePUS, whose basic abstractions are the motifs observed. By comparing them to the original text, we demonstrate that LePUS expressions can accurately and faithfully represent numerous design patterns. We show how predicate calculus can be used to define refinement and projection relations among patterns, and apply this technique to discover relations among GoF patterns. We conclude by illustrating a tool that supports the application and validation of patterns.
Index terms: Object oriented design, design patterns, theoretical foundations, software architecture
1.
Introduction
Abstraction techniques idiosyncratic to object oriented (O-O) programming (e.g., inheritance, encapsulation) seek to reduce the complexity inherent in the construction, maintenance, and reuse of large software systems at the programming language level. O-O programs are specified by means of abstract constructs, such as classes and objects, which promote the understandability of the code and the overall system. While having useful abstractions at the programming language level, the O-O paradigm lacks abstractions on the architectural level. OOP accords with various modularization techniques, which divide systems into functionally independent components, often by language mechanisms (e.g., Java™ packages, C++ namespaces), or by heterogeneous techniques (e.g., component software [1]). However, characteristic aspects of software archi-
i
Computer Science Department, Tel-Aviv University, Israel, and Department of Computing Systems, Uppsala University, Sweden.
ii
IBM Watson Research Center and Technion.
iii
Department of Pure Mathematics, Tel Aviv University.
iv
Computer Science Department, Tel-Aviv University.
-1-
tecture, such as recurring design motifsi and patterns of data and control flow, occur across the boundaries of functional partitions. Consequently, these properties of object systems cannot be accounted for, or implemented by modules of any ordinary sense [2], and require abstractions of an altogether different nature. Design and architecture patterns are, in essence, the result of an attempt towards alleviating this deficiency in OOP. Patterns document abstractions that are not limited to functional units. Patterns may be adequately viewed as aspects or themes of software architecture, thereby best construe the essentials of well-organized architecture (e.g., [3]). Patterns raise the abstraction level of object oriented systems. Each pattern identifies a “design theme” (also “microarchitecture”), a prevalent design technique, proved to be applicable in a variety of application domains. Collections of patterns elaborate, name, and catalog design techniques, thereby introducing a common “vocabulary” for design themes which can be used to construct new systems and to document the architecture of existing ones. Motivation Specifications provided by design and architecture patterns lack in two aspects: 1. The specifications are, at best, informal; carried out by means of concrete examples and by appealing to intuition, they attempt to converge towards the desirable generalizations. 2. More importantly, patterns’ authors have failed to recognize recurring motifs in their abstractions. Consequently, each pattern is veritably defined independently to othersii. Due to their imprecise specification, microarchitectures prescribed by design patterns serve as prototypical abstractions of high intuitive appeal, yet they lack a more definitive foundation. Consequently, many ambiguities arise while no accepted means of resolving them appear to exist. For example, despite the existence of designated discussion forums [4; 5], users often have a difficulty to agree whether a particular piece of code manifests an instance of one design pattern or the other (also the problem of validation). Another confusion that originates from such ambiguities is repeatedly exemplified by peers that ask whether one pattern is a special case of another (also the problem of specialization), often without any satisfactory answer given.
i
mo·tif (m-tf) n. 1.a. A recurrent thematic element in an artistic or literary work. b. A dominant theme or central idea. 2. ... 3. A repeated figure or design in architecture or decoration. (The American Heritage Dictionary, Houghton Mifflin Company, electronic edition.)
ii
With the weak exception of Related Patterns, a subsection in the GoF patterns’ specifications [7] which merely mentions patterns that may relate.
-2-
In another example, the thesis made by Agerbo and Cornils [6] states that a majority of the patterns defined in [7] consists of “refinements” (meaning special cases) of a few “fundamental patterns.” This controversial claim was not readily accepted by the relevant authors; nonetheless, due to the absence of formal specifications accepted on either side of this debate, this discussion has no simple means of resolution. An additional example of the difficulty caused by imprecise specifications was provided by the authors of the seminal Design Patterns: Elements of Reusable Object Oriented Software [7]. The four exhibit substantial (and well-documented) difficulty to agree on the question whether a proposed (MULTICAST) is indeed a special case (specialization) of a previously defined abstraction (OBSERVER). The discussion – reported by one of the participants in two intriguing articles [8; 9] – took several months and involved numerous informal and often strained arguments. We demonstrate how this debate could have been resolved using LePUS specifications in a straightforward manner on section 8.2. In light of the disagreement among the very authors of a pattern, it is not surprising that many have difficulties in answering questions stemming from similar ambiguities. Where principal abstractions are inaccurately described, such disagreements are bound to make the rule rather than the exception. Structure and Contents of this Paper We is a list of the contributions described in this paper, following its structure: In section 2 we illuminate key normative and descriptive issues in the formal representation of patterns, and establish a basic vocabulary. In section 3 we propose criteria for evaluating prospective pattern specification languages, which can also be used to compare their relative merits. Section 4 surveys other attempts to deliver precise and formal representations of patterns and their deficiencies. The direct contributions of our research are depicted in the next two sections as follows: Fundamental “motifs”: Section 5 describes a small set of rudimentary abstractions (“design motifs”) which serve as building blocks that jointly account for numerous design and architecture patterns. Formal specification language: In section 6 we define LePUS, a compact fraction of higher order monadic logic (HOML) that can concisely account for the above mentioned abstractions and the relations of interest thereof. In section 7 we demonstrate the specification of several prominent GoF patterns in LePUS and illustrate the projection relation between the FACTORY METHOD and the ABSTRACT FACTORY patterns, which is implicit within the original specifications and hard to prove by the contemporary means of the specification of patterns. The benefits of LePUS are further demonstrated in section 8, which depicts a prototype of a tool that supports the application and recognition of patterns, as well as validation of their instances in programs. We also demonstrate in this section how LePUS can be em-3-
ployed to resolve debates and ambiguities that stem from informal specifications, and to establish the following properties: ♦
That one pattern refines (is a special case of) another;
♦
That one pattern is projected (reoccurs in unbounded number) in another; and
♦
That a particular implementation conforms to the specification of a given pattern.
We conclude by enumerating the contributions made by our research and include an appendix of additional GoF patterns to reinforce our case on the expressiveness of our language. Caveat The following clarifications limit the scope of our work:
LePUS' expressions are restricted to O-O motifs, as opposed to other attempts towards representations of components of software architecture (e.g., [10]).
LePUS definitions do not pretend to replace natural language specifications; formal definitions are complementary to the existing means (natural language, code samples, etc.)
We are aware that, by definition, descriptions in natural language cannot always be fully formalized, in a manner that is universally accepted. In some cases, formalization is difficult, and there is a definite limit to what can be specified in LePUS. Nonetheless, LePUS diagrams convey significant and essential information about the microarchitectures intended.
We only treat the solution part of the pattern specifications (see “leitmotif” below). We are not aware of any attempt to formalize the Intent, or any other segment in the conventional specification of patterns. Perhaps a different approach can be used in the future for the remaining elements of pattern specification.
LePUS only accounts for approximately two thirds of the GoF patterns and few architectural patterns. It remains to be proved that the rest are unambiguous and formalizeable, and whether LePUS can contribute to that.
Leitmotifs Different pattern authors describe their compositions in different formats. Basically, every description combines a problem and a solution, occasionally under different names, and often accompanied by additional sections (notably examples and forces). Focusing our research on the solutions provided by patterns, we should not contribute to the confusion between a pattern and the solution in dictates, in particular when opponents of formalization base their objections on the (false) claim that the formalization attempts necessarily demonstrate such confusion. -4-
From a different angle, the term solution does not adequately reflect the constructs we seek to formalize. Consequently, the abstraction that manifests the elements in the structure and behavior of the implementations of the solution provided by the pattern is referred to as its leitmotif. Nonetheless, having made our purpose clear, we allow ourselves in this article to refer to the leitmotifs of patterns simply as "patterns." Thus, our attempts focus on the formalization of the leitmotifs of dominant and welldefined patterns.
2.
Discussion
This section brings forth a discussion in principal issues related to the formal representation of leitmotifs.
2.1
Can Leitmotifs Be Formalized?
In this section, we discuss the extent to which the representation of leitmotifs can be formalized. Inspection the manuscripts of “Design Patterns: Elements of Reusable Object Oriented Software” [7] reveals that its authors made an effort to render their descriptions as definite and conclusive as possible without loosing generality. Nevertheless, accuracy is only achieved to a varying degree of success within this catalog. Looking to estimate the accuracy of the specifications made in this catalog, we identified six categories of verbal descriptions with respect to precision and formality. The results of our analysis, published in [11], are summarized in Table 1. The first three categories of Table 1 comprise the relatively “precise” statements made throughout the verbal descriptions. Note that “precision” does not necessarily indicate a singular implementation in every conceivable O-O programming language. Detailed implementation instructions are relatively infrequent and accomplished almost exclusively by quoting the implementation itself in one language of choice, thereby restricting the generality of the design pattern. A verbal specification is considered “precise” if it has a ‘compact’ set of interpretations in several ‘conventional’ O-O programming languages. This “definition” is demonstrated in Table 2 using C++, Smalltalk, and Eiffel implementations of quotation given in Table 1. Empirical Results Our analysis indicated the following that with the majority of GoF patterns, most of the specifications of their leitmotifs are “precise,” that is, descriptions which fall under categories 1, 2, and 3 of Table 1. As of the remaining text extracts, we reached the following conclusions, ordered by their categories: -5-
Interpretation Category
Examples (extracts from [7])
1. Precise, singular
• (DECORATOR) “maintains a reference to a Component object” • (VISITOR’s ConcreteElement) “implements an Accept operation that takes a visitor as an argument”
2. Enumerated alternatives
• (FACTORY METHOD’s Creator) “may call the factory method to crate a Product object” • (STRATEGY, Collaborations) “Alternatively, the context can pass itself as an argument to Strategy operations” • (DECORATOR, Collaborations) “It may optionally perform additional operations before and after forwarding the operations.”
3. Precise generalization
• (VISITOR) “declares a Visit operation for each class of ConcreteElement in the object structure” • (DECORATOR) “defines an interface that conforms to Component’s interface”
4. Technical terms, yet open to various interpretations
• (PROXY) “Virtual proxies … cache additional information about the real subject so they can postpone accessing to it”
5. Fuzzy, informal, or teleologic description
• (ADAPTOR’s Adaptee) “defines an existing interface that needs adapting”
• (PROTOTYPE) “implements an operation for cloning itself” • (MEMENTO) “stores internal state of the Originator object.”
• (COMPOSITE’s Component) “implements default behavior for the interface common to all classes, as appropriate” • (OBSERVER’s Collaborations) “ConcreteObserver uses this information to reconcile its state with that of the subject.”
6. Deliberate omission of detail
• (STATE) “The State pattern does not specify which participant defines the criteria for state transitions”
Table 1: Categories in the GoF specification of design patterns
Category 4 (technical terms): If infinite interpretations exist, the formalization effort can focus on representing well-defined subsets of interpretations, and declare each as a separate pattern. For instance, a widely accepted interpretation for “caching”, as the CACHE-PROXY description specified, was implemented and reported in [12]. -6-
Verbal Description “pass itself as an argument”
Conforming Implementations • aStrategy.algorithm(*this) • aStrategy algorithm: self
“forwarding the operation”
• operation(arg: ARGUMENT): RETURN is do Result := the_component.operation(arg); Current.register; end
“a conforming interface”
• Base & Component::operation(Argument) const; Derived & Decorator::operation(Argument) const; • Component>>operation: Decorator>>operation:
Table 2: Descriptions vs. conforming implementations
Category 5 (teleologic and fuzzy specifications): We consider such sentences as impossible to be rendered precise by “simple” means at this point. Category 6 (deliberate omission): Details are omitted as means of abstraction, since patterns describe generalizations of implementations. We conclude that descriptions that fall under this category are similar to excerpts of category 3. Since only statements that fall under category 5 are deemed too difficult or impossible to formalize, and as the frequency of the specifications that fall under this category is kept low in this catalog, we conclude that rigorous, faithful representation of the leitmotifs described is feasible.
2.2 Contemporary Pattern Representation and Specification Languages This section discusses patterns’ specification languages, both in practice and hypothetical, and analyzes their inadequacies. We explain why contemporary means of specifications, as well as proposals for formal specification languages, fail to represent the microarchitectures manifested in patterns. Common Means of Specification Patterns (leitmotifs) are abstractions of O-O techniques of design and architecture, generalizations of repeated motifs in O-O systems. As such, they stand in a meta-level with respect to concrete programs, since any motif can be implemented by an unbounded number of programs. It directly follows that O-O programming languages (e.g., C++, Smalltalk, Java™), modeling notations (e.g., OMT [13], UML [14]), and any other language whose constructs dictate concrete programs rather than motifs thereof, is of the wrong abstraction level. -7-
Nonetheless, in the absence of adequate specification languages, patterns specifications commonly draw from the descriptions of prototypical instances rather than the generalizations intended (e.g., [7; 15]). Thus, instances of the pattern illustrated are given using source code of an implementation or by a class/object diagram, depicting a certain conforming scenario. It is important to notice that none of the included diagrams accounts for the generic leitmotif. Despite the misleading titles, used within the Structure section of the GoF articles (e.g., Figure 1), class diagrams depict a specific instance of the solution rather than its general structure. Alternative Specification Languages Formal specification languages, either modal-based such as Z, or algebraic such as Larch, can be useful to represent abstractions over types. These languages, however, are inappropriate for accounting for the abstractions we observed as the building blocks of design patterns (section 5). Architectural Description Languages (ADL) are generally aimed at the specification the architecture of software systems. ADLs, however, are designed to describe properties of software modules and their interactions, focusing either on static properties, such as Intercol [16], or dynamic properties, such as Rapide [17]. The abstractions (“motifs”) we observed in patterns, however, occur across the boundaries of modules, and their description involves classes, methods, and relationships amongst them, which cannot be naturally conveyed by any of these ADLs. Object Notations and their Inadequacies This section explains why object notations are insufficiently expressive to account for the motifs that we look to represent. For instance, one may ask, why not use UML [14] for the specification of patterns? (Arguments below were partially discussed in [18]).
Object notations can only account for first order sets and their members and relationships among them, while the specification of patterns must account for the occurrence of relations between higher order sets, as demonstrated in section 5.2.
Object notations do not incorporate variables, but only concrete entities such as classes and objects. This deficiency prevents, for instance, making expressions such as “every method f in class c invokes another method f’ defined in class c’ such that name(f)=name(f’).
Patterns are represented by means of a small, fixed number of kinds of relationships that may be hard to be pinned down as syntactic constructs. These relations are teleologically meaningful associations rather than syntactically identifiable entities, as required by object notations. Furthermore, the small number of the relations commonly involved calls for introducing them into the specification language.
Object notations lack abstraction expressions that are required to account for the generalizations, while the specification of design patterns involves imposing con-8-
straints which can be satisfied by versatile manners. For example, a constraint such as the first formal argument of f is of class c cannot be expressed (formally) by object notations; instead they can specify a certain signature for f, such as: “foo(C)”, to which legal variations such as “foo(C,C)” do not conform. A more suitable specification language would impose a constraint, such as: FirstArgument(f,c), which captures all conforming cases.
2.3
Object notations do not represent procedures (also function members, methods) as first order entities but as mere properties of classes. Consequently, procedures cannot be characterized as necessary and key properties thereof can only be specified informally. The only method to express the following sample facts is by means of informal notes: “Method f2 invokes another method f1”, or “Method f2 incorporates a statement which creates an object of class c”.
Terminology
In this section we attempt to structure the terms used with respect to patterns in an informal manner. We do not deliver precise definitions at this point but adhere to the loose descriptions which appear in the literature. Further in this article we will attach formal definitions to some of these terms. The description in [7] of the solutions delivered by patterns invariably involves a set of participants, which are agents that carry out designated roles, and a set of certain collaboration in which the participants are involved. (These patterns are also described by additional means). In other words, a pattern specifies the ‘conforming’ implementations by specifying as a set of constraints on relations that must exist between constructs of programs. Accordingly, the description of a pattern can be abstracted as follows: ♦
The pattern’s participants is a sequence of “entries”, or variables, each characterized by type (e.g., class, object, method);
♦
The pattern’s collaborations describe the expected behavior of the participants and the relations amongst them.
Patterns convey regularities, motifs, or abstractions of recurring themes of programs, rather than concrete instances thereof. Thus, most patterns have each an unbounded number of conforming implementations, usually in several programming languages and application domains. The following terms are commonly used within the daily practice of patterns:
-9-
♦
A context in a program p would be an ordered sequence of concrete elements ω1…ωn in p, such as classes, methods, and so forth.
♦
An instancei (also a witnessii, an implementation) ω of a pattern π in a program p would be any context in p that “conforms” to the description of π, in the sense that each of ω1…ωn has the type as specified by the respective participant of π, and that ω1…ωn collaborate as specified by π.
♦
The object (target) language of an implementation in a program p is the OOP language of p.
→
Activities We also label activities with relation to the use of patterns as follows: →
Application (also implementation, instantiation) of a pattern π in the context ω : What is considered as the original purpose of patterns is to provide software designers with mechanisms that resolve forces in a given context. Thus, once π is selected as the appropriate at a any point during the evolution of a program, its des→
ignated solution is carried out in a certain context ω , whereby ω1…ωn take the roles of “participants” in π and being assigned by “roles” accordingly. A process →
that modifies and/or extends the constructs in ω to accommodate to their newly assigned roles in π is termed an application of π in this context. For instance, as the outcome of “applying” the OBSERVER pattern [7] in the context of the given classes S, O1, and O2, we get the result that O1 and O2 become “observers” of S, i.e., relate to it as specified by the pattern. The application of a pattern often takes place in a context of a size that is smaller than the number of the actual participants required, during which process new constructs are created. →
Validation: Given a context ω and the pattern π, we are interested to know whether →
ω is an instance of π.
Recognition: Given a program p and a pattern π, we are interested to know whether there is an instance of π in p, and if so, which. Discovery: Given a program p, we are interested to know whether some set of contexts thereof can be abstracted as patterns “of interest,” and if so, which are these patterns and contexts. This activity is commonly referred to as “pattern mining” (e.g., [19]).
i
The term also used by Smolàrova, Nàvrat & Bielikova [98].
ii
As termed by van Emde Boas [97].
- 10 -
In section 8.1 we demonstrate how statements in LePUS, our proposed specification language, can be straightforwardly implemented in the construction of tool support for the (semi-) automation of some of these activities. Relations Questions also arise with respect to possible relations that exist between patterns, such as: Refinement (also specialization): Two articles, one by Agerbo and Cornils [6] and the other by Vlissides [8; 9], discuss cases where one pattern is said to refine another. Using the above terminology, it can be said that pattern πs refines (is a special →
case of) pattern πg if every witness ω of πs is also a witness of πg. In section 8.2 we demonstrate how LePUS can be used to establish with greater simplicity the refinement relation between the patterns in the debate documented by Vlissides [8; 9]. Projection: A special case of Refinement of particular interest exists where the pattern that is "refined" contains an unbounded number instances of another pattern. For instance, any number of instances of the FACTORY METHOD pattern can occur within one instance of the ABSTRACT FACTORY pattern. In section 7 we describe how LePUS can be employed to establish that the FACTORY METHOD results from the projection of the ABSTRACT FACTORY.
2.4
Normative Questions
Based on the terms defined above, we now discuss the cons and pros of the formalization of the specification of patterns. The general agreement on its purpose, among research towards precise and formal languages for the representation of patterns is to promote the following objectives: i.
Resolving the question of validation;
ii. Establishing means to determine relationships between patterns, such as refinement
and projection; iii. Allowing tool support in the activities related to patterns, primarily with their ap-
plication and validation, and possibly with their recognition and discovery as well. Attempts towards precise specification of design patterns have encountered strong opposition. Objections to this approach are voiced along the following lines:
Patterns are recipes that describe solutions to a broad category of problems. Pairing a solution with the relevant problems is inherent benefit of using patterns, which is lost by focusing only on the solutions.
Formal specifications contribute little or nothing to the understanding when and how to use a pattern. “Formalizing the solution makes it harder to grasp the key - 11 -
ideas of the pattern…Programmers need concrete information that they can understand, not an impressive formula.” [20, p. 427]
Patterns are abstractions, or generalizations, and therefore are meant to be vague, ambiguous, and imprecise. If there were specified in a precise form, or expressed in mathematical terms, they would no longer be patterns. “Formalizing the solution makes it harder … to create valid variants. A formalized solution may thus narrow the applicability of the pattern unnecessarily. …Formalisms tend to describe particular issues very precisely, but do not allow for the variation that is inherently embedded into every pattern.” [20, p. 427]
There is no fixed element in patterns, and everything can be changed about them. In other words, if “the basic structure is fixed … this isn’t patterns any more” [21].
Patterns are a quasicorporeal concept whose essence is intangible, elusive, and hence beyond the scope of a literal expression. A “good” pattern departs from mere micro-architectural prescription by some immaterial quality that cannot be explicitly expressed, a “quality without a name”i, and therefore cannot be interpreted outside its context or taken apart.
A critical review of these objections was published in the article Giving “The Quality” a Name [11]. These objections are answered, respectively, as follows:
Precise specification of the solution segment alone does not indicate that the problem specification is unimportant. We focus on the solutions as a first step towards precise specification of the complete pattern, and do not look to diminish the significance of the problem and other elements in the structure of software patterns. It is worth noting, however, that even indeed we view the solution as the dominant element in a design pattern. Consider the definitions of design patterns that appear in the literature (e.g., [7; 22; 23]; definitions surveyed in [24]) which demonstrate that many prominent pattern writers think equally, as well as each and every one of the researchers that looked to deliver precise specification for design patterns (reviewed in section 4). Whenever tool support or a formal language is proposed, it is hardly ever mentioned that it focuses solely on the specification of the structure and behavior manifested in the solutions.
i
It is primarily a matter of opinion, or rather of personal intuition, whether formal languages are more “comprehensible” than natural language. Nevertheless, ambiguous descriptions are an obstacle in resolving details of implementation, which requires complete and accurate understanding of the solution indicated, even if a different solution is selected.
As this property was termed by Alexander. Jim Coplien’s “The Column Without a Name” published in C++ Report is named after this concept.
- 12 -
Note that we do not seek to replace the contemporary means of specification with LePUS or any other formal specification language, but rather add to them. LePUS diagrams should clarify and pin down the specification of the solution, which is already described in the pattern.
This objection stems from a confusion made between detailed as opposed to accurate descriptions: It is wrongly assumed that exact (or formal) specifications can only describe concrete entities, and in order to be general one has to be vague. This is wrong, of course, since a specification can be precise and general at the same time. As an example for a simple generalization, LePUS specification of the FACTORYMETHOD pattern maintains that the Creation relation is an isomorphism between the set factory-methods and products. This specification is clearly a generalization to which any natural number of (factory-method,product) pairs conforms. More generally, every constraint imposed by a formal specification allows an unbounded number of variations, which nonetheless satisfy the specified constraints. For instance, if a pattern specifies 3 participating classes and 4 specific relations amongst them, additional classes or relations can be added without violating. To summarize, statement number 3 and its variations appear to reflect the ignorance of the speaker in formalisms rather than carry any weigh.
If this statement is true, there is no way patterns can be well defined or understood. This objection appears be a variation on the “quality without a name” (number 5 above), and is answered as such (see below).
This opinion is expressed repeatedly by many members of the patterns community. Unfortunately it is usually carried as an oral tradition or stated in informal occasions, such as mailing lists [5]. As such, it cannot be properly quoted. The opinion that a particular phenomenon cannot be rationally explained has never proved fruitful (except maybe to greedy clergyman). Clearly, the irrational and mystical approach to patterns is unscientific and nonproductive, as only systematic investigation can adequately resolve the open questions, such as validation and relationships between patterns. Such statements cannot be justified within academic context.
These and other arguments in support of precise specification (of design motifs prescribed by design patterns and other architectural specifications) appear in literature [25; 11; 26]. We conclude that more accurate means of specification are highly desirable, if not inevitable.
- 13 -
3.
Criteria for the Evaluation of a Specification Language
Looking to compare different pattern specification and representation languages and to compare their relative contributions, we make below several definitions and offer criteria for the evaluation of prospective languages. More specifically, we attempt to create below a well-defined vocabulary that allows a discussion in pattern specification languages without making too many assumptions on these languages. We also seek to provide criteria that are sufficiently general for the comparison of different specification languages, and provide means for carrying out discussions that are not limited to assumptions idiosyncratic to LePUS. Patterns as Sets of Programs Patterns were informally regarded as sets in numerous occasions. For instance, Cargill [27] presents three design patterns as separate categories of implementations, further refined by additional patterns. Vlissides [9] has also named his article: “Multicast – Observer = Typed Message”, suggesting subtraction between sets. van Emde Boas [25] describes how, using effective encoding, all programs that can be written in potential object languages comprise an enumerable, infinite set, to be designated here as 3. Similarly, the (microarchitecture dictated by a) pattern π can be represented as the subset of 3 comprising the (often infinitely many) programs that incorporate an instance of that pattern. We designate this subset as 3|π. This leads us to the next and very general definition of a pattern specification language: Definition I: Pattern Specification Language Given a set of programs 3, a pattern specification language Λ is a language whose expressions specify subsets of 3. From this point, pattern specification languages would also be referred to simply as “languages”. We say that a program p∈ 3 satisfies an expression ϕ in Λ if p belongs to the subset defined by ϕ. The set of programs in 3 that satisfy ϕ is designated [3]ϕ. Naturally, different languages give rise to different sets of 3, and for this reason are of varying degrees of descriptiveness. Given a finite set of patterns, we can measure the extent to which a pattern specification language is descriptive as the extent to which it accounts for these patterns. Formally:
- 14 -
Definition II: Descriptive and Complete Languages Given a language Λ, a set of programs 3, and a set of patterns Π⊂23, Λ measures as descriptive with respect to Π to the rate of patterns π in Π such that there exists an expression ϕ in Λ such that 3|π =[ 3]ϕ . We say that Λ is complete with respect to Π iff this rate is 1. Given these definitions, refinement can be redefined as a problem of reasoning about sets. Objective Criteria Given a set of patterns Π, we define the properties of a prospective pattern specification language Λ as follows: Λ is expressive to the extent that it accurately and correctly conveys the following: ♦
Abstractions, or building blocks as listed in section 5 (namely: uniform sets; ground and set relations; inheritance hierarchies; and method families);
♦
Generalizations (descriptions that fall under categories 3 and 6 in section 2.1).
Λ is descriptive with respect to Π to the extent that it delivers expressions that accurately describe the patterns in Π (Definition II). Λ is complete with respect to Π if its descriptive rate is 1 (Definition II). Λ is concise with respect to Π if the specification of its patterns in Λ is also “simple”i Λ is compact if it does not allow the specification of sets that do not make “reasonable” patterns. While it is possible to verify expressiveness with certain confidence, it is less obvious how to determine conclusively the extent to which a particular language is descriptive, concise, or compact. This difficulty stems, in part, from the use of the expression “existing body of patterns” which is not well defined. In this article we used the seminal GoF catalog for the purpose of a well-defined “body of patterns” to measure LePUS, our proposed language, thereby allowing us to demonstrate LePUS’ qualities with relative simplicity. In other words, we shall demonstrate that LePUS is a formal specification language that is expressive, descriptive, concise, and compact, as defined above. Furthermore, we demonstrate in section 8 that LePUS provides means to reason on the relationships between patterns and for the implementation of tool support in related activities.
i
“Simple” is used here in as an intuitive notion which applies to constructs made of relatively few components.
- 15 -
4.
Related Work
This section reviews the attempts towards precise or formal specification languages and their deficiencies. The LayOM [28] extends the classic object model with the concepts of states and layers to support the specification of patterns. Similarly, Alencar, Cowan and Lucena [29] propose an environment that comprises “Abstract Data Views” and “Abstract Data Objects” (ADV/ADO), specified in a specialized “scheme” language. The mapping of the fundamental constructs of both specialized models onto those of common OOPLs is much elaborated and not self-sufficient. Klarlund, Koistinen and Schwartzbach [30] present a specialized language of parse trees, CDL, that can be used to validate design constraints. CDL formulae are proposed to express constraints over the behavior and relations of collaborators in a design pattern in terms of the language by which they are implemented. CDL create a direct connection to the implementation language for each specification rather to the general concept, and do not provide insight on the general specification of a pattern, nor cannot account for it. Neither of the above mentioned works demonstrates wide applicability to design patterns, not provides a well-defined and complete specification of the representation language. Helm, Holland and Gangopadhyay [31] defined “Contracts”, an extension to 1st order logic with representations for function calls, assignments, and an ordering relation between them. The “behavioral compositions” described do not address structural relations, which are a fundamental part of design patterns and the resulting specifications are detailed and elaborated as well. Furthermore, the language does not seem to provide means to account for relations between patterns. Finally, the dynamic specification provided by Contracts need be verified dynamically, thereby is unsuitable for the implementation and recognition of patterns. Lauder and Kent [26] propose constraint diagrams as a visual specification language for design patterns. Indeed, constraint diagrams incorporate quantifiers over first order sets, as demonstrated to be one of the fundamental abstractions required. The article, however, does not account for sets of higher order, which are portrayed in many patterns. Furthermore, the construct provided by constraint diagrams are of an abstraction level that is too low for the specification of design patterns, and the specification of each pattern requires several diagrams and numerous symbols. Finally, Lauder et. al do not recognize the abstractions we observed or reflect them in their specificationi. Florijn, Meijers, and van Winsen [32] propose tool support for the application of design patterns, which represents them using the “Fragments Model”, described in detail by [33]. A “fragment” is in fact a semantic net, or a graph with labeled arcs, whose nodes stand for the participants, and the arcs describe the node’s role in the pattern. Each fragment, however, represents not a "true" pattern but only a version thereof. Every fragment specifies the number of its participants (e.g., one “observer” and two “concrete observer”), and i
It is worth noting also that the pattern which is depicted in the sample role diagram [Lauder and Kent 98] is the FACTORY-METHOD pattern and not the ABSTRACT FACTORY as the authors claim.
- 16 -
therefore does not provide an adequate abstraction. Finally, the model does not suggest any means for reasoning about patterns, their relationships, and so forth. Mikkonen [34] demonstrates the use of a symbolic logic language, DisCo, which appears to be an extension of first order predicate calculus (the language is not defined in the article), in representing the structure and behavior of patterns. The article demonstrates the specification of relations between records (designated “classes”), such as extension, and predicates on the preconditions and results of procedures (which can serve as multimethods). The article, however, does not demonstrate sufficient constructs that can account for the structure of the behavior of patterns, nor does it provide insights on their specifications. The lack of a definition of the language proposed also leaves open basic questions regarding the expressiveness of the language. Allen and Garlan [35] describe a structured extension to a subset of Hoar’s process algebra – CSP, which can be used to rigorously account for the interactions between components in various architectures (e.g., pipes and filters, client-server). Nevertheless, Allen and Garland’s language merely provides a means for the description of the dynamic behavior of agents in programs structured in conformance to a particular architecture, and do not account for the static composition of such programs, in particular those written by object-oriented principles. The tools supporting the application of design patterns proposed by Eden, Gil and Yehudai [12], by Pal [36], by Budinsky, Finnie, Vlissides, and Yu [37], and by Quintessoft Inc. [38] are reviewed in [39] and their shortcomings are discussed. Another relevant tool is PSiGene [40], whose authors did not produce an explicit representation for patterns.
5.
Observations
This section introduces fundamental motifs in O-O systems: abstractions that we observed to be fundamental building blocks in design and architecture patterns. We illustrate these abstractions using an intuitive definition of the graphical representation of LePUS, the specification language we propose. The formal definition of the constructs of LePUS and their graphical counterparts is given in section 6. Setting the Scene The most basic elements in the specification of patterns are the class and method variables, and relations that may be held between them. We also describe uniform sets, namely sets that contain either classes of methods, and two kinds of relations between them: total (functional) and isomorphic relations. We introduce these constructs by closely following how the specifications of sample GoF design patterns are transformed to a formal specification. We begin by demonstrating the simplest (“ground”) constructs in LePUS: the class and method variables, and ground relations. Diagram 1 depicts the LePUS specification of a formula which indicated the existence of a method creator, defined in class enclosing, - 17 -
which “creates” and object of class product. (The precise indication of the Creation relation, as well as the remaining concepts, will be defined later.)
Creator
product
de -in ed fin →
enclosing
Diagram 1: Ground variables and ground relations
The following abstractions are demonstrated in the context of GoF design patterns [7]. The expressive power of LePUS is illuminated by comparing LePUS specifications of these patterns with those in the GoF.
5.2
Sets, Relations, Exclusive Relations, and Isomorphisms
Figure 1 depicts the original specification of the PROXY pattern:
- 18 -
Participants ♦
Proxy maintains a reference that lets the proxy access the real subject. Proxy may refer to a Subject if the RealSubject and Subject interfaces are the same. provides an interface identical to Subject's so that a proxy can by substituted for the real subject. controls access to the real subject and may be responsible for creating and deleting it. −
…
♦
Subject defines the common interface for RealSubject and Proxy so that a Proxy can be used anywhere a RealSubject is expected.
♦
RealSubject defines the real object that the proxy represents.
Collaborations ♦
Proxy forwards requests to RealSubject when appropriate, depending on the kind of proxy.
Structure
Figure 1: GoF specification of the PROXY pattern [7, p. 209]
Compare the original specification of the PROXY (Figure 1) with its specification in LePUS (Diagram 2):
- 19 -
Subject Requests-Int
me e S a rfac te In
Proxy
RealSubject Requests-For Requests-Imp
! create
Diagram 2: LePUS diagram of the PROXY
We describe the contents of the PROXY’s diagram following the elements mentioned in its original description: Participants The patterns’ participants are represented as variables, as follows: ♦
The three Participants are represented as class variables (depicted as rectangles), designated Subject, Proxy, and RealSubject. LePUS’ textual version declares them as follows:
∃ Subject, Proxy, RealSubject ∈ & Unlike OMT and other object notations used to describe patterns, methods are first order citizens in LePUS. These are represented as method variables, depicted as an ellipses. ♦
create designates the method that is responsible for the creation of an instance of RealSubject. Thus, the textual equivalent of this item would be this:
∃ create ∈ ) Set variables represent uniform sets in LePUS. In the case of a set of methods, it indicates the set consists solely of methods, depicted as a shaded ellipse: ♦
Requests-Int, Requests-Imp, Requests-For represent each a set of methods. The textual version indicates the three sets as follows: ∃ Requests-Int, Requests-Imp, Requests-For ∈ 2)
Collaborations Collaborations amongst the Participants are specified in LePUS as relations defined on the variables. Thus: - 20 -
♦
Inheritance arrows indicate that both Proxy and RealSubject inherit from Subject, textually specified as follows: Inherit(Proxy, Subject) ∧ Inherit(RealSubject, Subject) A relation that involves two variables (also ground variables), such as Inheritance above, is designated ground relation.
♦
Since only the Proxy class may hold a reference to an object of type RealSubject, the Reference-To-Single relation in Diagram 2 is marked as exclusive by the exclamation mark, textually formatted as follows: Reference-To-Single(Proxy!, RealSubject)
♦
Every “request” defined in the Proxy class “forwards” the call to a method defined in the Subject, specified as follows: Forward↔(Requests-For, Requests-Imp) The double arrow next to the relation ↔ indicates an isomorphism, an invertible function between the set variables. Thus we say that the Forwarding is an isomorphism between the two sets of methods.
The complete textual version of the Proxy formula appears in Formula 10.
5.3
Hierarchies and Method Families
The next abstraction we discuss is the hierarchy. Different forms of inheritance hierarchies appear in O-O literature, in accordance with the diverse roles inheritance plays in O-O programs [41]. One particular structure, however, appears within design patterns significantly more than any others do: The “hierarchy” we observed consists of a single “abstract” class, also designated the root class, and any number of classes that inherit (possibly indirectly) from the root. We designate this construct simply as hierarchy, depicted as a rectangle. We demonstrate hierarchy variables in the context of the VISITOR pattern, whose original specification appears in Figure 2:
- 21 -
Participants ♦
Visitor ♦
♦
declares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited.
ConcreteVisitor ♦ implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class of object in the structure.
♦
Element ♦
♦
defines an Accept operation that takes a visitor as an argument.
ConcreteElement ♦
implements an Accept operation that takes a visitor as an argument.
… Collaborations ♦
When an element is visited, it calls the Visitor operation that corresponds to its class. The element supplies itself as an argument to this operation to let the visitor access its state …
Structure
- 22 -
Figure 2: The description of the VISITOR pattern [7, p. 209]
Compare the original specification of the VISITOR with its formal description in LePUS:
Visit(E l e m e n t s)
accept(Visitors)
Visitors
Elements
Diagram 3: LePUS diagram of the VISITOR
The explanation of Diagram 3 is structured following the description of the pattern’s participants and collaborations: Participants ♦
The Visitors classes and the visited “Elements” classes mentioned in the pattern’s specification, are represented by two inheritance variables, each depicted as a triangle in. Textually, hierarchy variables are defined similarly to other variables, as follows:
∃ Visitors,Elements ∈
+
♦
The Accept methods are a set with a special property: Since they are meant to bind dynamically, they share the same signature, and each is (re)defined in a different Element class. We say that Accept makes a clan in Elements, indicated in Diagram 3 by superimposed ellipse.
♦
Since a set of Visit methods are (re)defined in each Visitors’ class, they jointly make a set of clans, in Visitors. We say that Visit is a tribe in Visitors, depicted in Diagram 3 as a shaded ellipse that is superimposed on Visitors.
Collaborations The means of collaborations are specified using three isomorphisms: ♦
Note that the Invocation relation correlates each element in accept (a method) with one element in Visit (a set of methods, or a clan). Therefore Invocation is an isomorphic relation between Visit and accept, depicted in Diagram 3 as a thick arrow between the respective variables. Textually, this relation is specified as follows: - 23 -
Invocation↔(Visit, accept) ♦
Every clan in Visit has a different first argument, in correspondence with one element class. Thus First-Argument is another isomorphism between the two sets, as indicated by the thick line under the parenthesized “Elements” in Diagram 3, and textually specified as follows: First-Argument↔(Visit, Elements)
♦
Finally, every Visit clan “accesses” the corresponding element class, indicated by another isomorphism as follows: Invocation↔(Visit, Elements) Figure 3 illustrates how the sets Visit, accept, and Elements correlate.
visit (element1 )
accept 1 (Visitors) element1
Visitors accept n (Visitors)
visit (elementn )
element n
Figure 3: An illustration (“unfolding”) for Diagram 3
The DECORATOR Pattern Next we bring forth the LePUS specification of the DECORATOR, which demonstrates a highly condensed depiction of the microarchitecture conveyed by the pattern (Diagram 4). Below we illuminate two of the constructs that partake in the diagram: ♦
Forward↔(Requests,Operation): As the two tribes are connected by a “forward” isomorphism, this implies that – 1. The tribes Requests, Operation are of equal size (and so are their clans); and 2. For each request there exists a respective operation that has an identical signature (as implied by the forward relation amongst the two) to which the message is forwarded.
♦
Reference-To-Single→Η (Decorators,Components): As a relation that involves (one or more) hierarchies, the Reference-To-Single arc in Diagram 4 (indicated by a diamond on one end) has a special meaning, indicated by the symbol →Η. It designates that every leaf in Decorators stands in this relation Reference-To-Single with - 24 -
the Component’s root. Indeed, the class’ specification indicates that each decorator class holds a reference to the abstract Component [7, pp. 175].
Operations
Components Requests
Decorators Diagram 4: LePUS diagram of the DECORATOR
6.
Formal Specification
We move to deliver a complete definition of the textual and visual versions of LePUS. LePUS formulae manifest design patterns as statements in higher order monadic logic (HOML) [42]. More specifically, patterns are represented as formulae and programs as models (Definition III). Thus, in conformance with the general approach described in section 2.3: Given a pattern π that is represented as LePUS formula ψ, we say that a program p conforms to pattern π iff the model of p satisfies ψ. LePUS is a small fragment of HOML. HOML is too rich and expressive a language for our purposes, thereby is neither compact nor concise by the criteria defined in section 3. Our contribution, as described in this section, lies primarily in expressing a well-defined subset of HOML that is only a fraction thereof, yet effectively accounts for most patterns of interest and the motifs observed within. In conformance with the GoF specification of the microarchitecture dictated by a pattern, every formula in LePUS has the following form (Formula 1): ♦
a declaration of typed variables, standing for a list of participants; and
♦
the relations held amongst.
6.1
The Universe of Discourse
We assume that a program is represented as an object oriented structure or model (Definition III): a collection of ground (atomic) entities, namely classes and methods (also member-functions, routines) and a list of relations that hold amongst. A model that arises from program p shall contain the classes and methods defined in p and the relations - 25 -
thereof. These relations will most often include unary relations such as “c is a class”, “f is abstract”, and the binary relations “c1 inherits from c2”, “f is defined in c”, “c is the first argument of f”, and other relations as necessary. A detailed model of the STATE pattern implementation in C++ can be found in [43]. A model can also be viewed as a classic relational database, which consists of elements (classes and methods) and tables that correspond to the relations of our model. We designate our two-sorted universe of discourse by the symbol 3, the set of the ground entities that are classes as &, and the set of the ground entities that are methods by ). Both ) and & are referred to as types or domains with respect to the variables and relations in LePUS. Definition III: Model A model M is a pair where 3 is a collection of ground entities, each is either a method or a class, and 5 = R1,…,Rn is the set of relations amongst them. We reflect the notion of nested sets through the definition of dimension: Definition IV: Dimension The dimension of an entity is defined inductively: ♦
Ground entities have dimension '0'
♦
A set of entities of dimension d and a uniform type is an entity of dimension d+1
The domain of classes (methods) of dimension 1 is denoted 2& (2)), of dimension 2 as 2
2&
2)
(2 ), and so forth.
6.2
LePUS Formulae
Each LePUS formula stands for the complete and final representation of a single design pattern, namely, specifying the Participants and Collaborations. In accordance with this formulation, a formula in LePUS consists of variables and relations, which correspond to the aforementioned building blocks respectively. More specifically: Variables are – ♦
ground variables, ranging over ground entities;
♦
higher dimension variables, ranging over higher dimension (i.e., sets of) entities, or
♦
hierarchy variables, ranging over inheritance class hierarchies.
- 26 -
Relations are – ♦
ground relations, corresponding to those in 5 , including transitive relations;
♦
generalized relations, which derive systematically from the ground relations, or
♦
commuting relation.
A formula in LePUS has the following general form:
∃ (x1,… xn) :
∧ ℜ (yi ,... yi ) i
1
Formula 1: General form
ni
Where ℜi are relation symbols of the above types, and x1,…xn are all the free variables. In other words, a LePUS specifies the pattern’s participants and collaborations. Variables Ground variables are typed, and each stands for a ground entity of the respective type. To deal with higher dimension entities, LePUS incorporates higher order, typed variables; C1 (F1) vary over sets of classes (methods); C2 (F2) range over sets of sets of classes (methods), and so forth. Lowercase c (f ) are shorthand for C0 (F0), and C (F) as shorthand for C1 (F1). Lowercase w, v, v1 ,…,vn designate ground variables of any type and uppercase V, W designate 1-dimensional variables of any type. Hierarchy variables shall be defined later (Definition X). Ground and Transitive Relations Ground relations represent all possible association between single Participants in the model, or in the GoF’s terminology, their Collaboration. For every binary relation β of 5 we define a transitive counterpart β + as the transitive closure of β . By ground relations we denote the relation symbols for the relations in 5 and their transitive counterparts (whenever definable). Example 1: Abstract Class Representation Abstract(c) is a ground relation, and is satisfied by a (0-dimensional) class c of 3 if it is abstract. Example 2: Transitive Inheritance The (possibly indirect) inheritance relation between concrete-class and abstract-class transcribes to the predicate: Inheritance+(concrete-class,abstract-class). Implementations of Ground Relations For some OOPLs (O-O programming languages) and for some relations there exists a well-defined and simple mapping between the linguistic construct and the relation in LePUS. For instance, a Reference-To-Single relation is manifested in Eiffel as an attribute, - 27 -
a definite syntactical construct. This, however, is not true for every relation or every programming language. A relation can have more than one interpretation (such as Inheritance in Java) or several implementations (such as Creation in C++). In principle, we require a canonical, “simple” implementation possible for every relation of 5, and therefore rule out meaningless relations such as “Interesting(x)”. As design patterns are generalizations, however, a discussion about them is essentially about abstractions, that is, it involves discarding irrelevant details. In our universe of discourse we aim at the level between the technically detailed programming language (that is too concrete) and the “abstractness” of natural language (that is too vague). We consider relations such as “f creates an object of c” and “c1 inherits from c2” as abstractions of the right level for our discussion and prove them to be sufficient building blocks for the specification of many design patterns and for establishing relations thereof. Total Relations and Isomorphisms All set relations allowed in LePUS derive systematically from the ground relations in one of the methods defined below. We consider the benefit of simplicity of LePUS in taking this strong limitation yet retaining sufficient expressiveness for the specification of the design patterns of interest. We define below the indication of generalized relation applied to variables of dimension 1, but each definition extends naturally to higher dimensions. Let α denote a ground unary relation, β a ground binary relation. Definition V: Set Relations The following set relations are admitted: unary
α(V)
total
β →(V,W)
isomorphic
::= ∀v∈V :α(v) ::= ∀v∈V ∃ w∈W : β (v,w)
β ↔(V,W) ::= β is an invertible function (1:1 and onto, also isomorphism) from V to W
A total relation may be applied to variables of different dimensions with the intuitive interpretationi. Example 3: Total Relation in the BRIDGE. Each one of the Operation methods implements an abstract operation by invoking some sequence of Operation-Imp methods in the BRIDGE pattern (Formula 7). This description can be translated to Predicate 1: Invocation→(Operations,Operations-Imp) i
β →(V,w)::= ∀v∈V: β (v,w); β →(v,W)::= ∃w∈W: β (v,w) - 28 -
Predicate 1
Example 4: Total Relation in Inheritance Class Hierarchy. Predicate 2 below indicates an inheritance class hierarchy whose base is root and each class of Nodes inherits (possibly indirectly) from root (root is treated here as a singleton set). This predicate also serves us in the definition of hierarchy entities (Definition X). Inheritance+→(Nodes1 ,root0 )
Predicate 2
Example 5: Isomorphism in the FACTORY-METHOD. The FACTORY-METHOD pattern specifies that every method of the set FactoryMethods creates exactly one class of Products, and that every Products’ class is created by exactly one FactoryMethods’ method. To represent exactly this we specify a isomorphic Creation relation between the sets, as in Predicate 3: Creation↔(FactoryMethods1, Products1)
Predicate 3
Example 6: Isomorphism in OBSERVER. The OBSERVER pattern specifies an update method defined in each observer class. Defining Update1 as a set of methods and Observers1 as a set of classes, we see that Defined-In is a isomorphism between the sets (see also Example 11). Exclusive Relations Restrictions on the elements that may partake in a relation are specified through exclusive relations: Definition VI: Exclusive Relation For a set relation ℜ we define the following exclusive relation on V: ℜ(V!,W) ::= ℜ(V,W) ∧ [∀v : ℜ(v,w) ∧ (w∈W)→ (v∈V)] We say that ℜ is exclusive to V with respect to W. The dual case is defined for ℜ(V,W!), and ℜ(V!,W!) is equivalent to ℜ(V!,W) ∧ ℜ(V,W!). Exclusive relations reflect access restrictions on hidden (“private”) or implementation section of a class. Example 7: Exclusive Relation in PROXY In the Proxy design pattern, the proxy object is expected to “control access to the subject [7]”, namely, to be the sole object that creates and refers to the subject. This property is reflected by Predicate 4 and Predicate 5: Creation (proxy0!, subject0) - 29 -
Predicate 4
Reference(proxy0!, subject0)
Predicate 5
Example 8: Exclusive Relation in FAÇADE The FAÇADE (Formula 6) pattern requires that instances of Subsystem-Classes may be created only by the Creators methods that are defined in the façade class, and no others [7]. This requirement can be represented by a (total) Creation relation that is exclusive to Creators1 with respect to Subsystem-Classes1, as specified in Predicate 6: Creation →(Creators 1!,Subsystem-Classes1)
Predicate 6
Commutativity Morphisms in category theory [44] are said to commute if they are equal in the category of reference. Similarly, we look to state that particular isomorphisms commute (overlap) in a given domain. Such statements are declared as follows: Definition VII: Commuting Relations Given the variables V, W, and the binary isomorphisms β1↔, β2↔ (each may be a composition of isomorphisms), to indicate that β 1 and β 2 are equal in V,W we specify: Commuteβ 1, β 2(V,W) Commute may apply to more than two relation symbols and more than two variables. To clarify this definition we use an analogy from graph theory by representing isomorphisms as edges and variables as vertices: In the graph defined by the vertices V 1 ,…Vn and the edges β1…βn , Commuteβ 1…β n (V 1 ,…Vn) indicates that for every pair of vertices Vi and Vj, all the paths in the graph from Vi to Vj are equal, in the sense that each path in the graph determines a (composition of) relation and these relations are equal in Vi and Vj. Thus, for instance, the four relations commute in the VISITOR pattern (Diagram 3). Example 9: Commuting Relations in FACTORY-METHOD To illustrate commutativity we reuse the example that originated from the FACTORYMETHOD. The pattern requires a isomorphism between FactoryMethods1 and Products1 such that the following two conditions hold: 1.
object(s) of each class in Products1 are being created by exactly one method of FactoryMethods1, and
2.
the return type of each method of FactoryMethods1 equals the class of the object created thereof (which belongs to Products1).
Predicate 3 transcribes part (i) of this requirement. To specify part (ii) we must add Predicate 7: Return-Type↔(FactoryMethods 1,Products1) - 30 -
Predicate 7
Even so, we haven’t satisfy requirement (ii) above, as we haven’t forced the return type each of method in FactoryMethods1 to equal the type of the Products1 objects created thereof. To guarantee this property we additionally require the two relations to commute as follows: CommuteReturn-Type,Creation(FactoryMethods1, Products1)
Predicate 8
Predicate 7 and Predicate 8 are portrayed in Formula 3. Finally, a predicate that combines any relation symbol ℜ is well formed if it is declared on variables of number, type, and dimension as specified by ℜ. Thus, a well-formed formula in LePUS consists only of well formed predicates. Method Families Clans are sets of methods of particular interest due to the role of dynamic dispatch in OOP. All methods in a clan share the same return type and its arguments’ types and number. A clan is always declared with respect to a particular set of classes C. Definition VIII: Clan Fd is a clan in Cd iff Fd consists of methods of identical signature, each of which is defined in a different class of Cd. Formally: Clan(Fd,Cd) ::= Defined-In↔(Fd ,Cd) ∧[∀F1d- 1,F2d-1 ∈Fd : Same-Signature→(F1d- 1,F2d-1 )] Example 10: Clan in STRATEGY The STRATEGY pattern (Formula 10) defines the ConcreteAlgorithm methods to override the algorithm such that each “implements the algorithm using the Strategy interface [7]”. Thus, we define Algorithms to be a clan in the Strategies hierarchy. Example 11: Clan in the OBSERVER Since an update operation is defined in each observer class of the OBSERVER pattern, update is a clan of dimension 1 with respect to the Observers set of classes, reflected by the following predicate: clan(update,Observers). Example 12: Clan in the FACTORY-METHOD The set of factory-methods of the FACTORY-METHOD pattern (Formula 3) is manifested as a clan in the Creators set of classes.
- 31 -
Example 13: Clans in the VISITOR The VISITOR pattern (Diagram 3) requires that for every class elementi there is a method Visit(elementi) defined in the root of the Visitors hierarchy and redefined in every class in the hierarchy. Thus, the set of Visit(elementi) methods forms a clan in the Visitors hierarchy. A tribe is a set of clans, all of which are defined with respect to the same set of classes: Definition IX: Tribe Fd+ 1 is a tribe in Cd iff every method Fd∈Fd+ 1 is a clan in Cd In the trivial case where d=0, tribe(F,c) means that all methods in F are defined in c. Note that the elements of a tribe do not necessarily have the same signature, as elements of a clan do. Example 14: Tribe in the VISITOR Since a Visit(elementi) clan is defined for every class elementi of the Elements hierarchy (Example 13), the set of all Visit methods makes a tribe in the Visitors hierarchy. Example 15: Tribe in the ABSTRACT FACTORY In a different example, each Creators’ method of the ABSTRACT FACTORY pattern (Formula 4) produces objects of different class hierarchy of Products, thereby forming a clan per Products hierarchy. The set of all Creators clans gives rise to a tribe in Factories, giving rise to Predicate 9: Tribe(Creators2, Factories1)
Predicate 9
Example 16: Tribe in the BRIDGE Operation-Imp is a set of methods defined in the root class of the Implementors hierarchy, each redefined in every node of the hierarchy. Thus each separately forms a clan, and jointly a tribe in Implementors. Hierarchies Inheritance class hierarchies (or hierarchies) are treated as encapsulated abstractions in LePUS:
- 32 -
Definition X: Hierarchy A hierarchy variable represents a set of ground classes that constitutes a ground class hr0 and a set of remaining elements hN1, that conform to the following conditions: i. Inheritance+ →(hN1 ,hr0 ) ii. Abstract(hr0 )
We require that such hr0 class is unique in h. Hitherto our universe consisted only of methods and classes; we now extend our model M = < 3, 5 > to account for hierarchy entities. This extension does not effect the entities that previously populated our universe.
+
+
By we denote the set of all hierarchies, giving: ⊂ 2&. A "ground" hierarchy has dimension '1' (as it is a class of dimension 1), and a set of hierarchies of dimension d is a hierarchy of dimension d+1. We represent the extended model by the tuple < 3, 5 , >. We add to our language ground hierarchy variables which range over the domain , denoted by the lowercase letters h, h1 ,…, and define their dimension as 1. Consecutively, hierarchy variables Hd of dimension d range over hierarchies of dimension d. Thus, the two statements in Formula 2 are equivalent:
+
Formula 2-I: ∃Observers∈
+
Formula 2: Hierarchy Variables
+
Formula 2-II: ∃ObserversN ∈2&,Observersr∈C : Inheritance+ →(ObserversN ,Observersr) ∧ Abstract(Observersr) Example 17: More Hierarchy Variables. There is an overwhelming number of examples of class hierarchies in the GoF catalog, as almost every pattern incorporates at least one: The Observers set of the OBSERVER pattern (Diagram 13) makes a hierarchy which is rooted in the Observer abstract class and the Concrete-Observers as leaves; the Visitors and Elements of the VISITOR pattern (Diagram 3) make two separate class hierarchies; the Products set of the ABSTRACT FACTORY pattern (Formula 4) consists of a set of hierarchies, objects of each are produced by a different clan (Definition VIII) in the creators class hierarchy. Relations on Hierarchies Although hierarchy variables are a special case of class sets, they may not participate in total relations; instead, they can be declared in H-total relations. With respect to isomorphic relations, hierarchies are interpreted as ordinary class sets where the root classes stand in the specified relation. - 33 -
Example 18: H-Isomorphism in FACTORY-METHOD The FACTORY-METHOD pattern (Diagram 5) requires that objects of each class of Products are “produced” by a different “factory method”, each of which is defined in a different “creator” class. Thus, both Creators and Products are hierarchy variables in the pattern’s formula:
∃ factory-method∈2), Creators,Products∈
+:
clan(factory-method,Creators) ∧ Production↔(factory-method,Products) ∧ Return-Type↔(factory-method,Products) ∧ CommuteReturn-Type,Creation(factory-method,Products)
Formula 3: FACTORYMETHOD
Example 19: H-isomorphism in ABSTRACT FACTORY An isomorphism also manifests the correlation in the ABSTRACT FACTORY pattern (Formula 4) between the Creators tribe and Products, a set of hierarchies. The isomorphism indicates a 1:1 and onto Production relation is declared between each Creators’ clan and a hierarchy in Products, manifested in Predicate 10: Production↔(Creators2,Products2)
Predicate 10
Hierarchy variables may participate in isomorphisms (interpreted as class sets of the equivalent dimension), but instead of total they may only partake in H-total relations: Definition XI: H-total generalization The H-total generalization of a binary ground relation β is a relation β →Η with the following indication, depending on its arguments:
β →Η (V,h) ::= β →(V,root(h)) β →Η (h,V) ::= β →(Nodes(h),V) β →Η (h1,h2)
::= β →(Nodes(h1),root(h2))
As in the case of total relations, a single class is interpreted as a set that consists of one class. Thus, an H-total relation combining a hierarchy variable with a single class has the obvious interpretationi. Example 20: H-total Relations in OBSERVER To specify the OBSERVER pattern (Diagram 13) we use both predicates: Reference→Η (subject 0,Observers1)
i
β →Η (h,w)::=β →(Nodes(h),w); β →Η (v,h)::=β →(v,root(h)) - 34 -
Predicate 11
thereby indicating that subject holds a reference of type root(Observers), and Reference→Η (Observers 1,concrete-subject0)
Predicate 12
thereby indicating that each class of Nodes(Observers) holds a reference of type concrete-subject. Example 21: H-total Relation in BRIDGE To specify a reference to the root of the Implementors hierarchy in the abstraction class of the BRIDGE pattern (Formula 7) holds we use an H-total relation, as demonstrated in Predicate 13: Reference-To-Single→Η (abstraction0, Implementors1)
Predicate 13
Example 22: H-total Relation in STRATEGY Since a client of the STRATEGY pattern (Formula 10) “configures context with a ConcreteStrategy object [7]”, we expect the client class to hold a set of methods such that each of which creates an object of some Strategy class. To specify the suitable Creation relation we define ConfigureContext as a set of methods and Strategies as a hierarchy, and set an H-total creation relation as Predicate 14 depicts: Creation→Η (ConfigureContext, Strategies)
6.3
Predicate 14
Visual Notation
In order to allow highly concise expressions for design patterns and to promote the readability of formulae, we have granted graphic representation to a selection of LePUS’ elements. The diagrams in sections 5 and 7 demonstrate the use of the graphic language to effectively account for versatile design patterns. Diagrams A well formed diagram in LePUS is equivalent to a well formed formula. Figure 4 lists the figures of the graphical notation and the linguistic construct delineated by each, where ♦
icons stand for variables
♦
unary relation marks stand for unary relations
♦
edges stand for binary relations applied to the variables they connect
♦
commute designation(s) circumscribe the relations and domains (sets) of commuting
- 35 -
Variables
class
Classes-Set
function
Function -Set
hierarchy
Set-OfHierarchies
Unary Relation
Binary Relation
α
β →
Commutative ( Sub ) Diagram
Figure 4: Basic graphic symbols of LePUS
A diagram in LePUS is a graph whose vertices are icons (variables), possibly adorned with a unary relation marks, and whose edges are each labeled by a (possibly generalized) binary relation. An edge ρ, connecting vertices v1, v2, gives rise to the predicate: ρ (v1, v2). A well formed diagram gives rise only to well formed formulae (Formula 1). Thus, for instance, Inheritance edges must connect class icons. A r g u m e n t- 1
function (a r g)
and
Ground, Total, and H-total Relations:
→ return-type
Return-Type Regular Return-Type
⇒ return-type
Regular A r g u m e n t- 1
function (a r g)
Reference-ToOne Reference-ToMany
function
Invocation Forwarding
Generalizations:
Creation
( thick line ) R e g u l a r Production ( double arrow ) T r a n s i t i v e
!
Inheritance
( exclamation ) E x c l u s i v e
Assignment
Figure 5: Graphic synonyms for predominant relations. The direction of the binary relation edges is left to right
- 36 -
Graphic Synonyms We define special edge styles for relations of predominant interest (e.g., Inheritance) and relation modifiers adornments standing for generalized relations. An intuitive description of each of the relations of Figure 5 appears in [43]. Generalized relations are depicted as relation modifiers, adornments that are added to the arrows. Thus, for instance, the relation β + is represented by adding a double arrow head to the edge (or multiplying the arrow head if there exists one) which stands for β . Similarly, isomorphisms are signified by widening the edge’s line, and exclusive relations are marked by adding the exclamation mark next to the exclusive variable. A segment of a diagram that is also a well formed diagram may be circumscribed by the commutative designator, indicating that the isomorphisms thereof commute over the indicated domains (variables). Graphic synonyms were also defined for clans (Definition VIII) and tribes (Definition IX). The superimposition of the method [set] ellipse on a class of any dimension designates a clan [tribe] in this set, as defined in Figure 6.
f
f
f
f
c
C
h
H
F
F
F
F
c
C
h
H
f is a clan in c
F is a tribe in c Figure 6: Superimpositions represent clans and tribes
7.
Case Studies
This section delivers case studies in LePUS representations of patterns, mainly from the GoF’s catalog [7]. We first depict two similar patterns: the FACTORY-METHOD (Diagram 5), whose textual representation was already given in Formula 3 above and the ABSTRACT FACTORY (Diagram 6 and Formula 4). While the relation between the patterns is obvious in their original specification (“Implements-Using”, back cover), the LePUS reveals a much closer relation, which we designated projection in this article (section 2.3), since the second diagram is identical to the first except in the dimension of two out of its three variables, which is
- 37 -
raised in 1. A formal specification of the Projection relation and this particular instance thereof are discussed in section 8.2 and its definition is given in Definition XIII.
factory-methods ⇒ Products
Products
Creators
Diagram 5: LePUS diagram of the FACTORY-METHOD
Factory-Methods ⇒ Products
Products
Creators
Diagram 6:LePUS diagram of the ABSTRACT FACTORY
+
∃ Factory-Methods∈22 , Creators∈ ,Products∈2+ : )
tribe(Factory-Methods,Creators) ∧ Production↔(Factory-Methods,Products) ∧ Return-Type↔(Factory-Methods,Products) ∧ CommuteReturn-Type,Creation(factory-method,Products)
Visit(E l e m e n t s)
Visitors
a c c e p t(Visitors)
Elements
Figure 7: LePUS diagram of the VISITOR pattern
- 38 -
Formula 4: ABSTRACT FACTORY
)
∃ Visit∈22 ; accept∈2); Visitors, Elements∈
+:
tribe(Visit,Visitors) ∧ clan(accept,Elements) ∧ First-Arg→Η (accept,Visitors) ∧ First-Arg↔(Visit,Elements) ∧ Invocation↔(accept,Visit) ∧ Invocation↔(Visit,Elements) ∧ CommuteFirst-Arg,Invocation,tribe,clan(Visit,Elements,Visitors,accept)
Formula 5: VISITOR
The VISITOR pattern depicts an elaborated case of commutativity involving four isomorphisms and four sets. Despite the differences in dimensions, the two hierarchies and the respective methods are tightly coupled in the equivalence, as also indicated by the circular commutativity. A note on the Invocation relation which involves a class: Invocation(f,c) is a syntactic sugar for an invocation relation between f and a method that is defined in c. façade SubsystemClasses
!
Creators
Implementations
!
Manipulators
Figure 8: LePUS diagram of the FAÇADE pattern
∃ Implementation, Creators, Manipulators∈2); Subsystem-Classes ∈2&;
Formula 6: FAÇADE
façade∈ & : clan(Implementations, Subsystem-Classes) ∧ tribe(Creators, façade) ∧ tribe(Manipulators, façade) ∧ Creation→(Creators!, Subsystem-Classes) ∧ Invocation→(Manipulators!, Implementations)
The specification of the FAÇADE pattern involves two exclusive relations, which conveys the intent of the pattern: To hide a set of implementations. The pattern demonstrates the expressiveness of the exclusive qualifier (depicted as an exclamation mark), which serves a purpose that is similar to the principle of information hiding [45].
- 39 -
8.
Applications
In this section we demonstrate the usefulness of LePUS by delineating the main applications for the language: Tools that support the exercise of design patterns and reasoning about the relationships between them.
8.1
Tool Support
An important way to prove the utility of LePUS is through actual application of its possible uses. One important use is tool support in pattern related activities, which was very straightforward thanks to the affinity between HOML specifications and the PROLOG programming language. More specifically, LePUS specifications straightforwardly transcribe into structural statements, defining the constructs that a tool should apply, recognize, or discover. Furthermore, since LePUS formulae are purely symbolic logic statements, they easily translate into PROLOG predicates. In our implementation, we used a statically typed, object-oriented version of the language [46]. Example 23: FACTORY-METHOD definition in PROLOG Below is the definition of the FACTORY-METHOD pattern (Diagram 5) as a PROLOG rule: FactoryMethod(hierarchy_structure (Creators_root, Creators_Leaves), hierarchy_structure (Products_root, Products_Leaves), FactoryMethods) :clan(FactoryMethods, [Creators_root|Creators_Leaves]), isomorphic(production, FactoryMethods, [Products_root|Products_Leaves]).
Since set relations in LePUS are either total [H-total] or isomorphic of ground relations, it is sufficient to code a rule that generalizes a given relation as isomorphism, and another rule that extends a given ground relation to total. Example 24 demonstrates the rule for isomorphisms. Example 24: Isomorphic Rule Generalization in PROLOG Visual PROLOG [46] allows the generalization of a “ground” relation to be defined as a PROLOG rule. Thus, rather than specifying two different rules: one for Inheritance and the other for Inheritance↔, for example, we use the following rule to deduce the relation ↔ Relation from Relation: isomorphic(_,[],[]) :- !. isomorphic(Relation,L1,L2) :member(E1,L1), member(E2,L2), Relation(E1,E2), Remainder1 = minus(L1,[E1]), Remainder2 = minus(L2,[E2]), isomorphic(Relation,Remainder1,Remainder2),!.
- 40 -
Additional details of the tool’s implementation, as well as additional rules, are given in [43]. To summarize its contribution, our tool supports the following activities: ♦
Validation: A witness is manifested as a sequence of atoms a1 ,…an. To validate it satisfies a pattern, which is specified as a PROLOG predicate, we simply execute a PROLOG query which attempts to unify the entities a1 ,…an with the predicate.
♦
Recognition: The search for the presence of (an instance of) a pattern in a given model is equivalent to the search for facts database in PROLOG. For this purpose we employ another aspect of PROLOG – execution of a query with variables rather than atoms. A variable in a PROLOG query is interpreted as a request to match all elements of the database that satisfy the rule that may successfully replace this variable through unification.
♦
Application: Applying a pattern involves mechanisms only a slightly different from the ones used for validating or recognition. While the goal incorporates a design pattern predicate, the actual arguments thereof which do not designate entities already recorded in the facts database indicate entities that need be generated. In an application, the predicates testing for the existence for relations are replaced with assertions that add them to the database.
8.2
Relationships Between Patterns
Relationships between design patterns were discussed in several publications. Kim and Benner [47] discuss variations of the OBSERVER [7] pattern, and Rohnert [48] discuss variations of the PROXY [7]. Cargill [27] describes three patterns, each of which is further “refined” to several others. The GoF [7] discussed associations between the patterns (“Organizing the Catalog” [7, pp. 9-11]; “Design Patterns Relationship” [7, pp. 11-13]). Zimmer [49] divides the relations between the patterns of [7] into 3 types: “X is similar to Y”, “X uses Y”, and “Variant of X uses Y”. The relationship issue is a key notion in the understanding of design patterns and their usage. Very often members of the patterns community debate over questions pertaining to relationship between patterns, such as: ♦
What is the difference between pattern π1 and π2?
♦
Is pattern π1 a special case of π2? (Designated above as refinement)
♦
Does the program clip p contain an instance of pattern π? (Designated above as the question of validation)
Conclusive answers to these questions are of great significance, as they determine “true” understanding of each pattern. Since design patterns serve for communication and education, thorough understanding thereof is a prerequisite to their success.
- 41 -
Example 25: The MULTICAST vs. OBSERVER Debate Vlissides [8; 9] reports in detail a discussion about the similarity between MULTICAST, a candidate design pattern, and the established OBSERVER [7]. The participants of this discussion were the four authors of the original catalog, debating the specification of the MULTICAST which was made using the common means in the specification of design patterns, namely, verbally accounted examples and class diagrams. The four confer and disagree about the extent of similarity between the patterns. The discussion spreads over a number of pages, where each author stresses in words and puts up examples to stress the distinctions or commonalties. We demonstrate below how LePUS specifications contribute to the resolution of the debates as the one reported in Example 25 and in the related questions. Refinement Following are the results of employing LePUS in illuminating the debate reported in Example 25, thereby demonstrating how it can facilitate establishing relations between patterns. These results were also reported in [50]. The refinement relation between patterns (as defined in section 2.3) can be easily determined provided their LePUS specifications ϕ , φ. Refinement can be established using predicate calculus, since, clearly, [ 3]ϕ ⊂[ 3]φ iff ϕ →φ. Formally: Definition XII: Refinement Given two formulae ϕ , φ, we say that ϕ refines φ iff ϕ →φ. Thus, given the LePUS specifications (Diagram 7, Diagram 8) for the patterns MULTICAST and TYPED MESSAGE, we can easily establish that 1. TYPED MESSAGE is indeed a refinement of MULTICAST, and that 2. MULTICAST and OBSERVER (Diagram 13) are indeed very different, as originally claimed by Vlissides.
- 42 -
Messages
receive (M e s s a g e s )
multicast Senders
Receivers
Diagram 7: LePUS diagram of TYPED MESSAGE. Note that operation was renamed to multicast only to emphasize the similarity to MULTICAST; naturally, a consistent renaming of the variables has no effect on the formula.
Messages
receive (M e s s a g e s)
multicast Senders
Registry
register (Receivers)
Receivers
Diagram 8: LePUS diagram of the MULTICAST candidate pattern.
Projection A clear case of projection relation as described in section 2.3 is illustrated in the diagrammatic specification of the FACTORY METHOD (Diagram 5) and ABSTRACT FACTORY (Diagram 6) patterns. The ABSTRACT FACTORY results from “lifting” the dimension of two of the FACTORY METHOD’s variables. Thus, the FACTORY METHOD results from "projecting" two of the variables of the ABSTRACT FACTORY. Alternatively we can say that the ABSTRACT FACTORY results from "lifting" two of the variables that occur in the FACTORY METHOD. We define projection as an operation on the dimension of the variables:
- 43 -
Definition XIII: Projection Given two formulae ϕ , φ, we say that ϕ is a projection of φ iff φ results from raising the dimension of (some or all of) the variables in ϕ in a constant k. Note that the relations that are defined between variables in the “projected” formula are valid in the resulting formula. Validation Discussions among members of the patterns community, as well as among its leading figures (e.g., in Vlissides [51], or carried over the gang-of-four mailing list [4]), often concern a particular implementation and the question which pattern(s) it gives rise to. We designated it as the question of validation in 2.3. We demonstrate below how LePUS can be used to establish an example of a case of validation. Entities (also atoms) Classes (&) ♦
Node
♦
Link
♦
File
♦
Directory
Methods ()) ♦
streamIn
♦
streamOut
♦
getChild
♦
adopt
♦
Directory::streamIn
♦
Directory::streamOut
♦
Directory::getChild
♦
Directory::adopt
♦
File::streamIn
♦
File::streamOut
♦
Link::streamIn
♦
Link::streamOut
♦
getSubject
Relations (5)
- 44 -
♦
Defined-In(streamIn,Node)
♦
Defined-In(streamOut,Node)
♦
Defined-In(getChild,Node)
♦
Defined-In(adopt,Node)
♦
Defined-In(Directory::streamIn,Directory)
♦
Defined-In(Directory::streamOut,Directory)
♦
Defined-In(Directory::getChild,Directory)
♦
Defined-In(Directory::adopt)
♦
Defined-In(File::streamIn,File)
♦
Defined-In(File::streamOut,File)
♦
Defined-In(Link::streamIn,Link)
♦
Defined-In(Link::streamOut,Link)
♦
Defined-In(getSubject,Link)
♦
Abstract(Node)
♦
Inherit(Link,Node)
♦
Inherit(File,Node)
♦
Inherit(Directory,Node)
♦
Reference-To-Many(Directory,Node)
♦
Reference-To-Single(Link,Node)
♦
Assignment(adopt,Directory,Node)
♦
Return-Type(Link::getChild,Node)
♦
Same-Interface(Link::getChild,getChild)
♦
Forward(Directory::streamIn,streamIn)
♦
Forward(Directory::streamOut,streaOut)
♦
Forward(Link::streamIn,streamIn)
♦
Forward(Link::streamOut,streamOut)
Table 3: The model described in [51, p.29].
Vlissides [51, p.29] discusses a sample implementation which, as it is claimed, gives rise to both the COMPOSITE and the PROXY. We shall prove below that his implementation indeed conforms to the specification of both patterns, as specified in LePUS in Diagram 2 and Diagram 10. The program described in the above mentioned manuscript is modeled textually in Table 3 and graphically in Figure 9.
- 45 -
adopt getChild → Node streamIn streamOut Node
streamIn streamOut Link
streamIn
streamIn
streamOut File
streamOut
adopt getChild → Node
Directory Figure 9: Visual depiction of the model of Table 1
To demonstrate that the model of Table 1 satisfies the formulae of both the PROXY (Diagram 2) and the COMPOSITE (Diagram 10) patterns, we will point out the key elements in the unification:
9.
♦
The COMPOSITE pattern: The Components hierarchy can be unified with the concrete classes Link and File, and the abstract class Node at the hierarchy’s root. The Composite class variable unifies with the Directory class, which holds the required Inherits and Reference-To-Many relations to Node. The Directory::adopt method satisfies the Attach method and Assignment relation, and the methods Directory::streamIn, Directory::streamOut satisfy the Operations-f set as they are forwarded to streamIn, streamOut respectively.
♦
The PROXY pattern: Both RealSubject and Subject unify with the Node class, and the requests unify with the steamIn and streamOut methods which hold the Forwarding relations to their Node counterpart. Finally, the Link class holds the reference to Node as required.
Conclusions
We began by providing a foundation for a discussion in representation of patterns, and described a list of abstractions that can serve as building blocks in the specification of microarchitectures dictated by the solutions provided by design and architecture patterns. We defined a pattern specification language, LePUS, that is concise, descriptive, and expressive. Finally, we demonstrated how LePUS achieves the goals set for a pattern speci- 46 -
fication language, namely, for establishing relations between patterns, for resolving the question of validation, and for providing tool support in the practice of patterns.
Appendix Following is the LePUS specification of additional GoF patterns, most of which are used to demonstrate the properties of the language:
abstraction Operations
Operation-Imp
Refined-Abstractions
Implementors
Clients
Figure 10: LePUS diagram of the BRIDGE pattern
)
∃ Clients, Operation-Imp∈22 ;
Formula 7: BRIDGE
Operations∈2);
abstraction∈ &; Refined-Abstractions∈2&; Implementors∈ : tribe(Operation-Imp, Implementors) ∧ tribe(Clients, Refined-Abstractions) ∧ tribe(Operations, abstraction) ∧ Invocation→(Operations, Operation-Imp) ∧ Invocation→(Clients, Operations) ∧ Inheritance→(Refined-Abstractions, abstraction) ∧ Reference-To-Single→Η (abstraction, Implementors)
+
- 47 -
operation A l g o r i t h m s(context) context
client Strategies
Configure_ Context
Figure 11: LePUS diagram of the STRATEGY pattern
∃
context, client∈ &; operation∈ ); Algorithms, ConfigureContext∈2); Strategies∈ : clan(operation, context) ∧ clan(Algorithms, Strategies) ∧ tribe(Configure-Context, client) ∧ Invocation→(operation, ConfigureContext) ∧ Invocation+ → (Algorithms, context) ∧ First-Arg→(Algorithms, context) ∧ Creation→Η (ConfigureContext, Strategies) ∧ Assigment →Η(Context,ConfigureContext,Strategies) ∧ Reference-To-Single↔(context, Strategies)
+
defined-in →
template-method P r i m i t i v e - Op h Figure 12: LePUS diagram of TEMPLATE METHOD
- 48 -
Formula 8: STRATEGY
∃ template-method∈ ); Primitive-Op∈2); h∈
+:
clan(Primitive-Op,h) ∧ Invocation→(template-method,Primitive-Op) ∧ Defined-In→( template-method,h)
create-iterator ⇒ Iterators
Formula 9: TEMPLATE METHOD
Itertion-Ops
Aggregates
Iterators
Agg-Elements
Diagram 9: LePUS diagram of the ITERATOR
∃ Subject, Proxy, RealSubject∈ &; create∈ );
Formula 10: PROXY
Requests-Int, Requests-Imp, Requests-For∈2) : Inherit(Proxy, Subject) ∧ Inherit(RealSubject, Subject) ∧ Tribe(Requests-Int, Subject) ∧ Tribe(Requests-Implementation, RealSubject) ∧ Tribe(Requests-For, Proxy) ∧ Same-Interface(Requests-Int, Requests-For) ∧ Forward↔(Requests-For, Requests-Imp) ∧ Reference-To-Single(Proxy!, RealSubject)
- 49 -
Components Operations
Composite O peration-f
Attach (C o m p o n e n t s ) get-child
→ Components Diagram 10: LePUS diagram of the COMPOSITE
SpecificRequests
Client
Adaptee Requests
Target&Adapter
SpecificRequests
Client
Adaptee Requests
Target&Adapter
Diagram 11: LePUS diagram of the CLASS and OBJECT ADAPTER.
- 50 -
invoker
client
set_receiver
Assign_Command
Commands execute
receiver
Diagram 12: LePUS diagram of the COMMAND
subject detach (observers ) attach (observers ) notify Observers Update (subject ) concrete-subject get-state Set-State
Diagram 13: LePUS diagram of the OBSERVER
Acknowledgments Many thanks to Yonat Sharon and Eric Ernst for their insightful and very detailed comments.
- 51 -
References 1
C. Szyperski (1998). Component Software. Addison-Wesley.
2
D. L. Parnas (1972). “On the Criteria To Be Used in Decomposing Systems into Modules”. Communications of the ACM, Vol. 15, No. 12, December 1972 pp. 1053 1058.
3
M. Shaw (1996). “Architectural Patterns.” In: [15].
4
gang-of-four-patterns. Mailing list: http://hillside.net/patterns/Lists.html#gang-of-4
5
pattern-discussion. Mailing list: http://hillside.net/patterns/Lists.html#patterns-discussion
6
E.Agerbo, A. Cornils. (1998). “How to Preserve the benefits of Design Patterns”. OOPSLA 98.
7
E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley.
8
J. Vlissides (1997a). “Multicast”. C++ Report, Sep. 97. SIGS Publications.
9
J. Vlissides (1997b). “Multicast - Observer = Typed Message”. C++ Report, Nov.Dec. 97. SIGS Publications.
10 M. Shaw, D. Garlan (1995). "Formulations and Formalisms in Software Architecture". Computer Science Today, Lecture Notes in Computer Science Vol. 1000, Springer-Verlag. pp. 307-323. 11 A. H. Eden (1998d). “Giving ‘The Quality’ A Name”. Journal of Object Oriented Programming, guest column, June 98. SIGS Publications. http://www.math.tau.ac.il/~eden/bibliography.html#joop98
12 A. H. Eden, J. Gil, A. Yehudai (1997c). “Precise Specification and Automatic Application of Design Patterns”. The 12th IEEE International Automated Software Engineering Conference - ASE 1997. http://www.math.tau.ac.il/~eden/bibliography.html#ase
13 J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen (1991). Object Oriented Modeling and Design. Prentice Hall. 14 G. Booch, I. Jacobson , J. Rumbaugh (1999). “The Unified Modeling Language Reference Manual”. Addison-Wesley. 15 J. M. Vlissides, J. O. Coplien, N. L. Kerth (1996, eds.) Pattern Languages in Program Design 2. Addison-Wesley. 16 W. F. Tichy (1980). “Software Development Control Based on Systems Structure Description.” Ph.D. Thesis, Carnegie-Mellon University, Computer Science Department, January 1980. - 52 -
17 D. C.Luckham, J. Vera (1995). “An Event Based Architecture Definition Language.” IEEE Transactions on Software Engineering, Vol. 21, No. 9, pp. 717-734. 18 J. Gil, D. Lorenz (1998). “Design Patterns Vs. Language Design”. IEEE Computer, March 98. 19 J. Coplien (1995). “Pattern Mining”. C++ Report, Oct. 1995. SIGS Publications. 20 F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal (1996). PatternOriented Software Architecture - A System of Patterns. Wiley and Sons. 21 J. Coplien (1996). “Code Patterns”. The Smalltalk Report, Dec. 1996. SIGS Publications. 22 D. C.Schmidt, R. E. Johnson, M. Fayad (1996). “Software Patterns”. Guest editorial, Communications of the ACM, Vol. 39, No. 10, October 1996. 23 R. Johnson, W. Cunningham (1995). "Introduction". in: [15]. 24 A. H. Eden, A. Yehudai (1997b). “Patterns of the Agenda”. In: Bosch J., S. Mitchell (1997, eds.) Object-Oriented Technology – ECOOP’97 Workshop Reader. Lecture Notes in Computer Science no. 1357. Berlin: Springer-Verlag. http://www.math.tau.ac.il/~eden/bibliography.html#ecoop97
25 P. E. van Emde Boas, (1997). “Resistance is Futile; Formal Linguistic Observations on Design Patterns”. Technical Report CT-1997-03, The Institute For Logic, Language, and Computation (ILLC), University of Amsterdam. 26 A. Lauder, S. Kent (1998). “Precise Visual Specification of Design Patterns”. ECOOP'98. 27 T. Cargill (1996). “Localized Ownership: Managing Dynamic Objects in C++”. In: [15]. 28 J. Bosch (1996). Language Support for Design Patterns. TOOLS Europe '96. 29 P. S. C.Alencar, D. D. Cowan, C. J. P. Lucena (1996). “A Formal Approach to Architectural Design Patterns”. Proceedings of the 3rd International Symposium of Formal Methods Europe, pp. 576-594. 30 N.Klarlund, J. Koistinen, M. I. Schwartzenbach (1996). “Formal Design Constraints”. Proceedings of ACM SIGPLAN Conference On Object-Oriented Programming Systems, Languages and Applications 1996. 31 R. Helm, I. M. Holland, D. Gangopadhyay (1990). Contracts: Specifying Compositions in Object Oriented Systems. Proceedings of OOPSLA 1990, SIGPLAN Notices, vol. 25 no. 10. 32 G. Florijn, M. Meijers, P. van Winsen (1997). Tool Support in Design Patterns. In: Askit M., S. Matsuoka (1997, eds.) Proceedings of the 11th European conference on Object Oriented Programming – ECOOP 97. Lecture Notes in Computer Science no. 1241. Berlin: Springer-Verlag. - 53 -
33 M. Meijers (1996). “Tool Support for Object Oriented Patterns”. Masters’ thesis, Dept. of Computer Science, Utrecht University INF-SCR-96-28. 34 T. Mikkonen (1998). “Formalizing Design Patterns”. Proceedings of ICSE 98, IEEE Computer Society Press, pp. 115-124. 35 Allen R, D. Garlan (1997). “A Formal Basis For Architectural Connection”. ??? 36 P. P. Pal (1995). “Law-Governed Support for Realizing Design Patterns”. TOOLS USA 17. 37 F. J. Budinsky, M. A. Finnie, J. M. Vlissides, P. S. Yu (1996). “Automatic code generation from design patterns”. Object Technology, Vol. 35, No. 2. 38 Quintessoft Engineering, Inc. (1997). C++ Code Navigator 1.1. http://www.quintessoft.com
39 A. H. Eden, Y. Hirshfeld, A. Yehudai (1999a). “Towards a Mathematical Foundation for Design Patterns”. Technical report 1999-004, Department of Information Technology, Uppsala University. http://www.math.tau.ac.il/~eden/bibliography.html#ecoop99
40 M. Schütze, Riegel, J. P., Zimmermann G. (1999). "PSiGene - A Pattern-Based Component Generator for Building Simulation". Theory and Practice of Object Systems (TAPOS), Vol. 5, No. 2, 1999. 41 A. Taivalsaari (1996). "On the Notion of Inheritance". ACM Computing Surveys 28 (3) pp. 438-479. 42 J. Barwise (1976, ed.) Handbook of Mathematical Logic, pp. 4-56. 43 Eden A. H. (1998f). Ph.D. Dissertation Draft, Tel Aviv University. http://www.math.tau.ac.il/~eden/dissertation.pdf
44 C. B. Pierce (1993). Basic Category Theory for Computer Scientists. MIT Press. 45 R. Wirfs-Brock, B. Wilkerson, L. Wiener (1990). Designing Object Oriented Software. Prentice Hall. 46 Visual Prolog 5.0 (1997). Prolog Development Center A/S. http://www.pdc.dk 47 J. J Kim., K. M. Benner (1996). “Implementation Patterns for the Observer Pattern”. In: [15]. 48 H. Rohnert (1996). The Proxy Design Pattern Revisited, in: [15]. 49 W. Zimmer (1995). Relationships Between Design Patterns. In: Coplien J. O., D. C. Schmidt (1995, eds.) Pattern Languages of Program Design. Addison Wesley. 50 A. H. Eden, Y. Hirshfeld, A. Yehudai (1998c). “Multicast - Observer ≠ Typed Message”. C++ Report, October 1998, SIGS Publications. http://www.math.tau.ac.il/~eden/bibliography.html#cppr98
51 J. Vlissides (1998). Pattern Hatching. Addison-Wesley. - 54 -
