A Formal Approach to Design Pattern De nition ... - CiteSeerX

A Formal Approach to Design Pattern De nition & Application P.S.C. Alencar y

D.D. Cowan z D.M. German x K.J. Lichtner { C.J.P. Lucena k L.C.M. Nova  August 9, 1995

Abstract

In this paper we present a formal approach to de ne and apply design patterns that is both process- and reuse-oriented. Initially we use a process program based on design pattern primitive tasks or constructors to describe how to instantiate a pattern. As we develop the patterns we introduce a formal model for the interconnected objects that constitute the instantiation. The formal model which is based on Abstract Data Views divides designs into both objects and views in order to maintain a separation of concerns. We have chosen a formal model for pattern de nition and application since it allows us to specify the steps in pattern instantiation unambiguously and to reason about the completed design. Furthermore, a formal statement of the application of a design pattern can provide the foundation on which to build tools to assist the programmer in code generation.

1 Introduction Design patterns[GHJV95, CS95, Coa95] can be viewed as an approach to encapsulating \good practice" in object-oriented programming, where the patterns indicate to the programmer how carefully engineered collections of objects can be used to produce programs. Design patterns add another reuse dimension to object-oriented programming since they present a way to use repeatedly the experience of the best programmers in structuring programs. The work described here has been supported by the Natural Sciences and Engineering Research Council of Canada (NSERC), the National Research Council of Brazil (CNPq), and WATCOM. y P.S.C. Alencar is a Visiting Professor in the Computer Science Department at the University of Waterloo, Waterloo, Ontario, Canada. Email: [email protected] z D.D. Cowan is a Professor in the Computer Science Dept. at University of Waterloo. [email protected] x D.M. German is a PhD candidate in the Computer Science Dept. at University of Waterloo. [email protected] { K.J. Lichtner is a PhD candidate in the Computer Science Dept. at University of Waterloo and holds a doctoral fellowship from NSERC. [email protected] k C.J.P. Lucena is a Professor in the Departamento de Inform atica, Pontifcia Universidade Catolica do Rio de Janeiro, Brazil, and an Adjunct Professor in the Computer Science Department at the University of Waterloo. Email: [email protected]  L.C.M. Nova is a PhD candidate in the Computer Science Dept. at University of Waterloo and holds a doctoral fellowship from CNPq. [email protected] 

1

Design patterns were partially inspired as an outgrowth of the MVC model[KP88] which is a programming model to achieve a separation of concerns and allow the de nition of the user interface (controller and view) to be separated from the application (model). Even though the MVC model provided the inspiration, some of the examples found in [GHJV95] do not uphold this principle of separation between the model and the controller/view. Currently design patterns have been grouped into three major categories and been informally described in a catalogue[GHJV95] using text and diagrams. The descriptions can be viewed as an informal recipe or process for producing instantiations of speci c patterns in languages such as Smalltalk or C++. An examination of design patterns prompts the question: \Can we describe design patterns more formally, and is there any advantage in such a description?" There are two aspects to design patterns that could be considered for formalization: the process of producing speci c instantiations, and the use of formally de ned components to substitute in these instantiations. If the process is de ned through a process programming language with formal syntax and semantics, then any ambiguities in the process of design pattern instantiation should be eliminated. Eliminating ambiguity should make it easier to derive code consistently and perhaps even lead to some automation of the production of code for the particular instantiation of a design pattern. Substituting formally de ned components into an instantiation could permit a formal reasoning process about the resulting system. We currently have established two dierent frameworks for reasoning about designs[ACL95, BACL95] of this type. Recent investigations[BACL95] have shown how both a formal model and a prototype can be derived from a single component-based speci cation, thus providing a strong link between formalism and implementation. The instantiation of components is based on the Abstract Data View (ADV) approach[CILS93a, CILS93b, CL95] which uses a formal model to achieve separation by dividing designs into two types of components: objects and views, and by strictly following a set of design rules. Speci c instantiations of views as represented by Abstract Data Views (ADVs) and objects called Abstract Data Objects (ADOs) are substituted into the design pattern realization while maintaining a clear separation between view and object. This approach creates patterns that provide the same functionality as the ones in[GHJV95], but produce instances which are not structurally identical. Each design pattern has an associated process program that describes how to substitute these components to create a speci c instantiation. In this paper we describe the ADV formal model and the associated formal schemas for ADVs and ADOs. Some of the patterns are then used to illustrate a formal approach to the process of constructing instantiations of design patterns. Finally we present a case study based on the editor described in [GHJV95].

2 The Abstract Data View (ADV) and Abstract Data Object (ADO) Concepts A model of the ADV/ADO concept showing how these two types of objects interact is presented in Figure 1. An ADO is an object that manages the state of an application and has no direct contact with the \outside" world. As an object an ADO has a state and a public interface that can be used to query or change this state; an ADO is abstract since we are only interested in the 2

public interface. An ADV is an ADO augmented to support the development of general \views" of ADOs, where a view could include a user interface or an adaptation of the public interface of an ADO to change the way the ADO is \viewed" by other ADOs. A view may change the state of an associated ADO either through an input action (event) as found in a user interface or through the action of another ADO. Objects

ADO

ADO

Public

Public

Effectual Action Mapping Effectual Action

Mapping

Effectual Action

Vertical Consistency

Effectual Action

Input Event (Causal Action)

Output Event

Horizontal Consistency

Owner

Owner ADV

ADV Object Views

Figure 1: An ADV/ADO interaction model Both ADVs and ADOs can be acted upon by actions to change or query their state. Actions can be divided into two categories: causal actions and eectual actions. We use the term causal actions to denote the input events acting on an ADV when it is acting as a user interface or interface to some other media. Causal actions are triggered from outside the system and internal objects are not able to generate this type of action. A keystroke or a mouse click are simple examples of input events that are causal actions. Eectual actions are the actions generated directly or indirectly by a causal action, and are supported by both the ADVs and ADOs. The triggering of an eectual action by another action will normally be a synchronous process. An eectual action can be viewed as the activation or call of a method or procedure that is part of the public interface of an ADO or ADV. In an ADV/ADO con guration only causal actions can change the state of the system. In other words, a causal action can make an eectual action occur, but an eectual action can not make a causal action occur. Since causal actions come from outside the system, causal actions can not cause other causal actions. If we visualize a tree of actions occurring over time, then a causal action can only appear at the root of a tree of actions. Since an ADV is conceived to be separate from an ADO and yet specify a view of an ADO, the ADV should incorporate a formal association with its corresponding ADO. The formal association consists of: a naming convention, a method of ensuring that the ADV view and the ADO state are consistent, and a method of changing the ADO state from its associated ADV. The form of this 3

association does not violate encapsulation as we compose ADOs and ADVs to make larger systems. An ADV knows the name of any ADO to which it is connected, but an ADO does not know the name of its attached ADVs. In the formal schema for an ADV, the names of the connected ADOs are represented by placeholder variables that are collectively labeled \owner" in Figure 1. This naming convention allows the connection of objects without violating encapsulation. If the state of an ADO is changed then any part of the state that is viewed by a connected ADV must be consistent with that change. A morphism or mapping is de ned between the ADV and ADO that expresses this invariant and of course uses the naming convention previously described. This mapping or morphism provides the ADV with access to the part of the state that is accessible through the ADO public interface, and so preserves encapsulation. The mapping is a design concept, and several strategies are available for its implementation. In addition, an ADV may query or change the state of a connected ADO through its normal public interface. Because of the separation between view and object it possible to use several ADVs to create dierent views for a single collection of ADOs. In this case both ADOs and their associated views represented by ADVs must be consistent. For example where ADVs are part of a user interface, a clock ADO could have a digital view, an analog view or both, and they must show the same time. We call consistency among the dierent ADVs horizontal consistency, while consistency between the visual object (ADV) and its associated ADO is called vertical consistency. These consistency properties which are illustrated in Figure 1 must be guaranteed by the speci cation of ADVs, ADOs, and their environment. Since ADVs are also objects they can be encapsulated and connected to other ADOs or ADVs by ADVs. Thus, if our views are placed in a distributed system, and become separated from their corresponding objects we can introduce the concept of time delay into the speci cation through auxiliary ADVs. Figure 1 illustrates many of these concepts. The user depicted in the Figure causes an input event (causal action) that is received by the ADV acting as a user interface. This action can cause an eectual action in which the ADV changes or queries the state of itself or the associated ADO. If the state of the ADO changes through some other action then the mapping ensures that the ADO and the user interface ADV are consistent. The other ADV in Figure 1 acts as an interface between two ADOs and changes in the ADO are similarly re ected in this ADV through the mapping. Thus, the mapping can force an eectual action to occur which changes another ADO.

3 Speci cation Schemas for ADVs and ADOs In this section we describe abstract schemas for the speci cation of ADVs and ADOs [ACLN95]. These schemas are useful tools for both formal and informal program speci cations [CGH92, FHW93], and are based on the ones described in [CGH92, GCH93, GVH+ 94]. A schema for an object in a system describes how that object modi es its state through its associated actions. Components of the ADV model are called objects since their schema speci cations describe behavior over the lifetime of the object, and involve both static and dynamic properties. Both interface and application components are composed of dynamic properties that specify changes in the attributes representing the state memory of the objects. ADVs and ADOs have distinct roles in a software system and, as a consequence, they are 4

ADO ADO Name Declarations Data Signatures Attributes Eectual Actions Nested ADOs Static Properties Constraints Derived Attributes Dynamic Properties Interconnection Valuation Behavior End ADO Name

- sorts and functions - observable properties of objects - list of possible eectual actions - allows composition, inheritance, sets, ... - constraints in the attributes values - non-primitive attribute descriptions - description of the communication process among objects - the eect of events on attributes - behavioral properties of the ADO

Figure 2: A descriptive schema for an ADO. described by dierent schemas. These schemas are not the actual objects inside a system, but rather provide descriptions of their static and dynamic properties and declarations of entities that are used within the scope of the object. The speci cation syntax of the whole schema is presented essentially through a temporal logic formalism [ACLN95, MP92]. Every ADV or ADO structure is subdivided into three sections: declarations, static properties, and dynamic properties. A declaration part contains a description of all the elements that compose the object including sorts, functions, attributes, and actions. They have a public status unless explicitly declared as private. The static properties part de nes all the properties which do not aect the state of the object. Their de nitions are always based on values stored by primitive attributes. Dynamic properties establish how the states and attribute values of an object are modi ed during its lifetime.

3.1 Schemas for ADOs

Figure 2 shows the structure of the schemas to be used in the speci cation of ADOs. The data signature section of an object consists of a set S of sort names, and a set F of functions. A sort declaration represents an association of a set of values to a sort name. A function speci cation associates a speci c operation to a function name and its declaration in the schemas has the form f : s1 ; : : :; sn ?! s0 , with si 2 S for i = 0; : : :; n, where s1 ; : : :; sn is called the domain of f , s0 is called the codomain of f , and n is the arity of f . We use the pair in our object speci cations for establishing the available types and operations on the values that are stored in the attributes. Among sort expressions we may have the basic abstractions such as integer and string, and the application-speci c abstractions including object instances or user-de ned sorts. Sort constructors, such as set and union, can also be applied to compose complex sort expressions, since the semantics involved in a sort signature are associations of a set of values with a sort expression. The functions, denoting operations over given values, are also part of the data signature section. Attributes denote the state or the set of features of an object that can change over time. Attributes can be used by other objects to report on the current state of an object, since At5

tributes are its observable properties. Attributes are represented as a set of declarations of the

form g : s1 ; : : :; sn ?! s0 , with si 2 S for i = 0; : : :; n, where g is an attribute name, s1 ; : : :; sn (n  0) denote optional parameter sorts of the attribute, and s0 is a sort determining the range of the attribute. Actions are represented as a set of declarations of the form [constr]a : s1 ; : : :; sn , with si 2 S for i = 0; : : :; n, where a is an action name, and s1 ; : : :; sn (n  0) represent the optional parameter sorts of the action. Note that attribute values can only be aected by local actions, which are the actions de ned in the same schema as the attribute to be changed. Additionally, we can subdivide types of actions into two subtypes: observer and change actions. The set of actions includes create and destroy which are object management procedures for objects derived from this speci cation. Additional meaning can be added to actions by two speci cation constructors represented by constr in the previous syntactic formula. The creation and destruction constructors may precede the action name declaration in order to specify that such actions are triggered at the birth or death of the object containing the declaration. The initialization of an object is de ned by means of actions that, in general, initialize attribute values of this object. In the Nested ADO section we can introduce the list of all the component objects of a composite ADO with the speci cation constructors that support nesting. Therefore, we specify the syntax of this section by the expression [constr][alias of]obj , where constr is a speci cation constructor, alias is an optional name by which the nested object is referenced inside the composite object, and obj denotes the nested ADO name. All objects are components of some composite object; objects which do not belong to a composite object are a component of the operating environment or \system." Composite objects are responsible for creating an instance of a component. Since the creation action can happen only once in a life of any object, then a component object can never be nested in two distinct composite objects. The rules used here for ADOs also apply to ADVs. The static properties of an object are represented by closed formulas. Constraint formulas refer to properties that must be true for all time, and derived attribute formulas de ne the derivation rules for the non-primitive attributes from the primitive (base) attributes. A derived attribute is an attribute in that it is a property of the object, but computing the derived attribute does not change the state of the object [Rum91]. Constraints are represented by the temporal logic expression 2, where  is an invariance property, and 2 is the temporal logic operator \always". Derived attributes are also expressed by means of temporal logic formulas. The interconnection section is described by morphisms of actions and attributes. These morphisms or mappings have several uses. They can establish how component objects relate to the composite object, how ADVs are associated with an ADO1 , or they can be an instrument to de ne synchrony between actions of dierent objects. The intended interpretation of a morphism is that the mapped attributes must always have the same values and the mapped actions must happen simultaneously. The de nitions of morphism are organized by objects and, the morphisms between the current object and each other object are speci ed by expressions of the form element1 7?! element2 where element2 always refers to attributes or actions which are de ned inside the current object. In the interconnection section there is a description of which attributes and actions in one object have

This interpretation only occurs in the schema for an ADV since ADOs do not know of the identity of their views (ADVs). 1

6

a synchronous correspondence with the attributes and actions in any other object. An important consideration is that an ADO schema cannot contain a reference to any ADV element, since the ADO has no knowledge about the existing ADVs. The valuation properties of an object describe the changes occurring in attribute values of this object as an immediate consequence of a triggered action. However, the valuation rules are applied only if all the speci ed pre-conditions for the occurrence of the action are satis ed. The valuation for an action a is described by means of temporal formulas of the forms: a ! att1 = value1 ^ : : : ^ att1 = valuen and a ! att1 = value1 ^ : : : ^ attm = valuem . The rst form of temporal formula de nes n pre-conditions on the occurrence of the action named a. The second form of temporal formula establishes m post-conditions on the occurrence of an action. Such formulas show the eects of an action over the attribute values of the object, since the temporal logic symbol means \at the next moment." The expressions that will determine new attribute values and pre-conditions are to be evaluated before the action occurrence. Behavior description is in general a complex task. Most of the object-oriented models represent system behavior by means of transition networks, which are augmented state-machine diagrams [dCLF93]. We have chosen temporal logic formulas to describe the object behavior. However, there are a number of graphical representation languages that we could have chosen instead to describe the behavior of objects [CCL93, Har87, CHB92, Che91]. The behavior section de nes the sequencing of the actions and changes in the state of the object. A behavior expression is described by pre state ^ action name ! post state, where pre state and post state are states of the object that are declared in the data signature section as boolean functions, and action name is an action of the object. Figure 3 contains a sample speci cation for a stack ADO that illustrates most of the material already presented. The Static Properties and Interconnection sections are not included in this speci cation since the ADO is not connected to any other ADO or ADV. In addition, we have not included the Data Signature in order to simplify the presentation. The stack element can be of any type and would be de ned separately. There is no behavior section because the entire state of the ADO is contained in the stack and not in the program steps. Each Eectual Action is de ned in the Valuation section where we show the result of its application.

3.2 Schemas for ADVs as User-Interface Views

Figure 4 contains a schema for an ADV as a user interface view, and as we can see by comparing Figures 2 and 4, the ADO and ADV schemas are similar, since they both incorporate object properties. However, there are some structural distinctions that clearly dierentiate the roles of ADOs and ADVs. One structural dierence is found in the header of the schemas. Since an ADO has no knowledge about the existence of ADVs, the header of an ADO schema contains only the de nition of the ADO name. On the other hand, the header of the ADV schema might contain both ADV Name and ADO Name declaring an association of the ADO with an ADV. The ADV Name and ADO Name are separated by either the phrase For or On. These phrases indicate the mode of the interconnection between an ADV and its corresponding ADO which can be by either a tightly-coupled (aggregation) or a loosely-coupled (acquaintance) relationship. The whole description of this association is normally de ned further in the interconnection section. An alternative structure to 7

ADO Stack Declarations Attributes Pos: nat; ElementType: ADO Element; Eectual Actions Creation Init; Push: ADO Element; Pop: ! ADO Element; Top: ! ADO Element; Empty: ! boolean; Nested ADOs Sequence Stack of ElementType; Dynamic Properties Valuation Init ! Pos = 0; Push(E) ! Stack[Pos+1] = E ^

Pos = Pos+1; Pop ! Pos > 0 ^

Pop = Stack[Pos] ^

Pos = Pos - 1; Top ! Top = Stack[Pos]; Empty ! Empty = (Pos = 0); End Stack

Figure 3: An ADO speci cation for a stack ADV ADV Name [For j On] ADO Name Declarations Data Signatures - sorts and functions Attributes - observable properties of objects Causal Actions - list of possible input actions Eectual Actions - list of possible eectual actions Nested ADVs - allows composition, inheritance, sets, ... Static Properties Constraints - constraints in the attributes values Derived Attributes - non-primitive attribute descriptions Dynamic Properties Interconnection - description of the communication process among objects Valuation - the eect of events on attributes Behavior - behavioral properties of the ADV End ADV Name

Figure 4: A descriptive schema for an ADV. 8

represent the interconnections between an ADV and an ADO could use another ADV to specify this relationship. This approach allows more exibility in describing the interconnection. Another distinction between ADV and ADO schemas is in the sections related to the declaration of actions. An ADO has no de nition of causal actions in its structure, thus every ADO action is eectual. However, ADVs as user interfaces may receive causal (external) actions, which should be declared in a particular section of the schema. This distinction clari es that the ADO has no interface properties.

3.3 Schemas for ADVs as Views Between ADOs

ADVs can also be used to specify the way one ADO views another. In this context the ADV schema can be modi ed to specify the relationship between ADOs. For example, in Figure 5 the client ADO labeled ADOi views the component ADO labeled ADOj using ADVij and thus, ADVij supports the detailed de nition of a view between the modules represented by ADOi and ADOj . Mapping Views

ADOi (Client)

ADV ij

Effectual Action

ADOj

(Component)

Figure 5: An ADV providing a view between two ADOs Figure 6 contains a modi ed version of the ADV schema from Figure 4, and this new de nition supports the concept of a view between ADOs. In this extension to the ADV approach, the view (ADV) knows the identity of the two participating ADOs, but the two ADOs do not know the identity of the view (ADV). Thus in the syntax of the modi ed schema, the representation relation requires that both the client ADO name and the component ADO name be speci ed in the ADV. The client and the component ADO name should appear in the ADV declaration, and the component ADO name should also appear in the eectual actions section. Whenever the ADO names are declared in the ADV header, two pseudo-variables client owner and component owner become available inside an ADV instance. The variables client owner and component owner are associated with the client and component ADO instances respectively. These pseudo-variables refer to the two ADO instances and allow controlled access and naming. The pseudo-variable component owner connects an instance of the ADV to an instance of the component ADO and provides access to its view. Note that the concept of component owner is not required in the ADV when it is used as an interface to an external medium because there is no corresponding ADO. This method of specifying the connection to the component ADO instance ensures that the client instance has no knowledge of the view of the component ADO instance. The pseudo-variable client owner associated with an instance of the client ADO is made available inside the ADV. This pseudo-variable refers to the client ADO instance and allows access to the state of the client ADO instance that is accessible through its public interface. This access allows the ADV to return values to the client ADO from the component ADO. The client owner pseudo-variable can then be used in the state invariant for the ADV instance, and in the pre- and 9

ADV ADV Name For ADO Client Name; ADO Component Name Declarations Data Signatures ... Attributes ... Eectual Actions Action 1 For ADO Component Name; ... Action N For ADO Component Name; Dynamic Properties Interconnection ... Valuation ... Behavior ... End ADV Name

Figure 6: An ADV schema for a view. post-conditions. This connection between the client ADO instance and ADV instance ensures that the both the ADV and client ADO instances have current knowledge of each others state. The schema which supports interfaces between ADOs contains only eectual actions, since there is no causal action to trigger an event which would cause input. ADO instances do not trigger events and ADV instances as views between ADOs connect only ADO instances together. There can be multiple eectual actions with the same client ADO instance since dierent changes in a client ADO instance can trigger dierent component ADOs. From an operational viewpoint the ADV can be viewed as a process which responds to changes in the client ADO state and responds to these changes by activating the interface of the component ADO and returning any values caused by this activation. In summary we observe that there are two types of ADVs: an ADV which acts as an interface between two dierent media and has both causal and eectual actions, and an ADV which supports only eectual actions and acts as an interface between two ADOs operating in the same medium. Although two types of ADVs exist, they are natural extensions of each other.

3.4 The speci cation schemas for ADV and ADO class templates

So far, we have introduced the concept of formal speci cation schemas or object templates for ADVs and ADOs. We now extend these concepts with the notion of formal classes, which are the abstractions that support the management of objects de ned by the formal speci cation schemas. Object management relates primarily to creation and destruction of objects and provides a method such as new, which when invoked creates an object instance. We use the same speci cation schemas to describe the management roles of classes. Each class schema which is pre xed by the phrase Class of is used to de ne the properties of an object. 10

Class of ADV ADV Name Declarations Data Signatures Attributes Actions Nested ADV Static Properties Constraints Derived Attributes Dynamic Properties Interconnection Valuation Behavior EndClass

- sorts and functions - there is an attribute to control object instances - actions to manage the creation and destruction process of objects - contains a list of references - constraints in class attributes values - non-primitive class attribute descriptions - interconnection with ADV speci cation actions - valuation properties of creation and destruction actions - describe the sequencing of actions

Figure 7: A schema for classes of ADVs. Each class template refers to exactly one object speci cation, and no object speci cation can be referenced by more than a single class template. As a consequence, we consider an object class to be de ned by the pair consisting of a class and an object schema, where the rst represents the management properties of the object, and the second de nes the object properties. Class and object schemas are similar, since classes are also objects in the same sense as discussed in [BGHS91]. Classes have the same structure as object schemas in that they have the three sections named declarations, static properties and dynamic properties, and each section has the same subsections. Class templates support inheritance and nesting so that they can be derived from existing class templates. This class concept as illustrated by an example in Section 4.2, supports the formal description of creational design patterns [GHJV95]. This type of pattern requires the speci cation of metalevel requirements such as a limit to the number of instances produced from a speci c schema. For example, the singleton pattern requires that only one copy of a pattern be produced, while the abstract factory is an abstract class that restricts the number of its instances to zero. The class template for an ADV is described in Figure 7; the schema structure is the same as the schema for an ADV object except that in a speci c use of this class we are describing the class speci cation related to object management. In addition, the object speci cation associated with this class, in this case an ADV, is declared after the Class of constructor. An object is created from within the class template by using the name of the speci cation for that object (ADV or ADO) and invoking the action or method Add Object.

4 Design Patterns The ADV model supports reuse since it divides an application into a set of specialized objects (separation of concerns) each of which may be used in other designs. However, we would like to \glue" these objects into reusable systems, that is systems which are easily maintained over time. Design patterns as proposed in [GHJV95] provide this form of reuse. Each design pattern is a 11

meta-description of a solution for a small problem that occurs frequently in software design. The application of the meta-description results in a collection of a few objects that form a speci c instantiation of such a design problem.

4.1 Design Pattern Constructors

The acceptance of reusable descriptions, such as design patterns, is highly dependent on easily comprehensible de nitions and unambiguous speci cations. We address both issues in a single formalism for design pattern application. In order to formalize the application of design patterns we introduce development constructors which are based on schemas that indicate how to apply a pattern. We de ne design pattern constructors to consist of a language-independent part and a product text speci cation, where a speci c language is adopted; this approach is similar to that described in [LS94]. The language-independent part of the structure should clearly de ne the characteristics of a design pattern. According to [GHJV95], a pattern is composed of four essential elements: pattern name, problem statement, solution, and consequences. Appropriate pattern names are usually important factors to assist developers in the speci cation of a system. In the case of reusable modules, the vocabulary of patterns could be one way of guiding the user to choosing suitable modules for the solution of particular problems. Operator Pattern Name Objective - description of the intent of the pattern Parameters - external elements used in the pattern de nition Subtasks - description of pattern in primitive constructors Consequences - how the pattern supports its objective Product Text - language-dependent speci cation of pattern End Operator

Figure 8: Development constructor structure for a design pattern. A problem statement is a description of the circumstances in which to apply a design pattern, and clari es describe the pattern objectives. In the development constructor structure shown in Figure 8, such a statement is described by an Objective section. Applying a pattern in the context of a speci c problem requires a process description, and so we specify this process in terms of primitive development constructors and parameters. The primitive constructors applied to pattern construction are organized in a section of the schema called Subtasks, while input parameters used in this process are declared in the Parameters section. The consequences of an application of a pattern provide a description of the results of using such structure in a software system. The roles of the components within the pattern objectives are also illustrated. This section may be helpful in evaluating the suitability of a pattern in a speci c context. These rami cations are speci ed in the Consequences section of a pattern schema. The language-dependent part of the pattern constructors describes the result of the application of a pattern as a speci c formal representation. Since design patterns are solution abstractions, a template of the pattern should be a helpful instrument in guiding the user to a particular speci ca12

tion. Such templates are illustrated in the pattern development constructors using the formalism of ADV/ADO schematic representations described in Section 3.

4.2 Examples of Design Pattern Constructors

In this section we describe how to specify the adapter, state, observer, decorator, facade, singleton and composite design patterns based on the pattern constructor described in Figure 8. We have chosen several patterns to illustrate how the pattern constructor is applied in each of the three categories in [GHJV95]. There is a substantial dierence between the pattern speci cations presented in [GHJV95], and the speci cations introduced in this paper. The patterns in [GHJV95] are based on OMT diagrams, informal descriptions in English and C++ templates, and are much closer to the implementation level than the version of the pattern descriptions we present in this paper. Our version of the patterns is based on the speci cation formalism associated with the ADV design approach. In the following design pattern examples the pattern speci cations provide explanations and directions to instantiate a design through the use of well-de ned development operators and incomplete object schemas. The development operators are sequentially numbered in a section called Subtasks, while the object schemas are de ned in the language-dependent section called Product Text, which provides reusable patterns for the system design. Other sections complete the design pattern speci cations by providing additional information. The rst pattern we describe is the adapter, and its corresponding speci cation schema is shown in Figure 9. The objective of the adapter is to modify the interface of a given object to conform to the needs of a client object. It is generally used to produce compatibility between two objects. The adapter might be seen as an object which is a wrapper for another object, and it can be used for adaptations of interface objects (ADVs) as well as application objects (ADOs). An adapter object could also be regarded as a view (ADV) for an application object (ADO). The subtasks which specify how to instantiate a pattern are given in a task or function notation of the form: f : x ! y where f is a function, x is a list of parameters for the function f , and y is the result of applying the function f. In the adapter pattern the function \Create Object" returns a copy of the ADAPTER Product Text while the function \Inherit Objects" takes the two arguments TARGET and ADAPTER and returns the modi ed Product Text for ADAPTER. In the context of C++ the ADAPTER text would have the words \inherit from TARGET" inserted in the appropriate location. Another useful design pattern speci ed in Figure 10 is called state. This pattern allows an object to modify its behavior based on its current state. The design relies on an abstract class called state that encapsulates the interface of the concrete objects implementing the behaviors of another object called context. Because of its behavioral nature, such a pattern is particularly useful for the design of application objects (ADOs). The observer design pattern, illustrated in Figure 11, is an example of a connecting pattern. The main objective of this pattern is to de ne a one-to-many dependency between objects, so that the dependent objects can monitor changes in one object. In the speci cation introduced here, we assume that observer objects are views (ADVs) of application objects, which we call subject in the pattern constructor. The current speci cation approach diers from the design proposed in [GHJV95], in that the link 13

Operator Design Pattern Adapter Objective Modify the interface of an object Parameters Objects: ADAPTEE, TARGET; Subtasks 1 - Specify Adaptation Object: ADAPTEE, TARGET ! ADAPTER 1.1 - Create Object: ! ADAPTER 1.2 - Compose Objects: ADAPTEE, ADAPTER ! ADAPTER 1.3 - Inherit Objects: TARGET, ADAPTER ! ADAPTER 1.4 - Specify Links: ADAPTEE, ADAPTER ! ADAPTER Consequences

ADAPTER will contain most of ADAPTEE functionality available through the TARGET object interface

Product Text

ADV/ADO ADAPTER Declarations :::

Nested ADVs/ADOs Compose ADAPTEE; Inherit TARGET; :::

Dynamic Properties :::

End Operator

Interconnection With ADV/ADO ADAPTEE TargetActions 7?! AdapteeActions; End ADAPTER

Figure 9: Speci cation of adapter pattern constructor. between a view and its application object is represented by the ADV mapping design mechanism, which was explained in Section 2. This approach does not describe the implementation of the link, but indicates a mapping or morphism between elements of the objects involved. In contrast, the design described in [GHJV95] proposes a design technique that is closer to the implementation than the proposed mapping. Figure 12 illustrates how a design pattern called decorator extends the functionality of a module. The extension is made dynamically by concrete objects that inherit their interface from the abstract class called decorator, which is also linked to the original functions de ned in the component objects. The concrete component objects, as de ned in the pattern constructors, are the ones that will have their responsibilities extended. Objects derived from the decorator pattern are particularly suitable when subclassing is not a practical option for functional extensions of objects. They are useful elements for both applications and views. The facade pattern although simple to describe, has structuring characteristics that can be of great value in a system design. Shown in Figure 13, such a pattern statically composes many interface modules in a single structure. The facade might also be viewed as an adaptive pattern, since it can represent several interface modules and make them conform to speci cation requirements. The singleton pattern in Figure 14 illustrates the use of class templates to describe the creation or instantiation process for an object of a given type. The purpose of the singleton is summarized 14

Operator Design Pattern State Status Complete Objective Allow an object to alter its behavior when its internal state changes Parameters Objects: STATE; Subtasks 1 - Create Object: ! CONTEXT 2 - Compose Objects: CONTEXT, STATE ! CONTEXT 3 - De ne Behaviors: ConcreteSTATEs 4 - Associate Behaviors With Object States: ConcreteSTATEs, CONTEXT ! CONTEXT Consequences

CONTEXT will have a dierent behavior for each of its state. Such behaviors are speci ed by instances of interface object STATE

Product Text

ADO ConcreteSTATEs Declarations :::

Nested ADOs Inherit STATE; :::

End ConcreteSTATEs ADO CONTEXT Declarations :::

Attributes BehaviorSpec: ADO STATE; Nested ADOs Compose BehaviorSpec; Dynamic Properties :::

End Operator

Valuation ToStateA ! BehaviorSpec = ConcreteSTATEa; ToStateB ! BehaviorSpec = ConcreteSTATEb; Behavior StateA ^ ToStateB ! StateB; StateB ^ ToStateA ! StateA; End CONTEXT

Figure 10: Speci cation of state pattern constructor.

15

Operator Design Pattern Observer Objective De ne dependency between objects Parameters Objects: SUBJECT; Subtasks 1 - Specify Observers to Objects: SUBJECT ! OBSERVERs 1.1 - Create Object: ! OBSERVERs 1.2 - Compose Objects: SUBJECT, OBSERVERs ! OBSERVERs 1.3 - Specify Links: OBSERVERs ! OBSERVERs Consequences OBSERVERs monitor changes in the state of SUBJECT to update its own state Product Text

ADV OBSERVERs forADO SUBJECT Declarations :::

Attributes ObserverAttributes; Actions ObserverQueryActions; ObserverChangeActions; :::

Dynamic Properties Interconnection With ADO SUBJECT SubjectAttributes 7?! ObserversAttributes; SubjectQueryActions 7?! ObserversQueryActions; SubjectChangeActions 7?! ObserversChangeActions; :::

End Operator

End OBSERVERs

Figure 11: Speci cation of observer pattern constructor.

16

Operator Design Pattern Decorator Objective Attach additional responsibilities to an object dynamically Parameters Objects: COMPONENT; Subtasks 1 - Instantiate Concrete Object: COMPONENT ! ConcreteCOMPONENT 2 - Create Interface Object: COMPONENT ! DECORATOR 3 - Instantiate Concrete Object: DECORATOR ! ConcreteDECORATOR Consequences You can attach dynamically ConcreteCOMPONENT functionality to ConcreteDECORATOR objects Product Text

ADV/ADO DECORATOR Declarations :::

Attributes ComponentType: ADO COMPONENT; Nested ADVs/ADOs Compose ComponentType; Inherit Component; :::

End DECORATOR ADV/ADO ConcreteCOMPONENT Declarations :::

Nested ADVs/ADOs Inherit Component; :::

End ConcreteCOMPONENT ADV/ADO ConcreteDECORATOR Declarations :::

Eectual Actions AttachComponent: ADO COMPONENT; Nested ADVs/ADOs Inherit Decorator; Dynamic Properties :::

Valuation AttachComponent(ComponentType) !

ComponentType = ProvideInstance(COMPONENT); :::

End Operator

End ConcreteDECORATOR

Figure 12: Speci cation of decorator pattern constructor.

17

Operator Design Pattern Facade Objective Provide a uni ed interface to a set of interfaces in a subsystem Parameters Objects: SubSys1, dots, SubSysN; Subtasks 1 - Create Object: ! FACADE 2 - Compose Objects: SubSys1, dots, SubSys, FACADE ! FACADE Consequences

FACADE is a higher-level interface object shielding many other subsystem interfaces

Product Text

ADV/ADO FACADE Declarations :::

Nested ADVs/ADOs Compose SubSys1, dots, SubSysN; :::

End Operator

End FACADE

Figure 13: Speci cation of facade pattern constructor. by the temporal logic statement de ned in the Class Constraints section, which restricts to one, the number of instances of objects speci ed by SINGLETON. The Product Text in the singleton pattern does not represent a speci c object, but the class template for creating an object. The subtask indicates that the name of the object to be instantiated only once, is substituted when an instance of the design pattern is created. Figure 15 describes the speci cation of the composite design pattern. This pattern de nes a hierarchical structure of objects sharing part-whole relationships. In such a relationship between objects, a composite object performs the \whole" role, while leaf and other composite objects represent the \parts". The elements composing the resulting tree structure have uniform interfaces, since all of them inherit the tree interface from the abstract class called component. Additionally, these elements might be de ned by ADVs or ADOs as well, since the composite design pattern might be used to structure both user interface objects and application objects.

5 A Case Study In this section we present a partial case study based on the editor structure described in [GHJV95]. The design patterns used in this case study are described in Section 4 and although similar in intent to the ones used in [GHJV95], we have adapted them to conform to the concepts introduced through the ADV design approach. The static structure of the system is described in terms of an OMT diagram notation [Rum91] extended to use the ADV approach to design. The objects in this extended notation are represented either by ADV boxes or ADO boxes, while dashed arrows are used to represent the mapping between an ADV and its corresponding ADO. Checks should be applied to designs using this notation to ensure that horizontal and vertical consistency constraints are maintained. The lozenge and the triangle in the OMT diagram represent aggregation and inheritance respectively. The small black 18

Operator Design Pattern Singleton Objective Ensures that there will be only one instance of a certain object speci cation Parameters Objects: SINGLETON; Subtasks 1 - Create Class of an Object: SINGLETON ! Class of SINGLETON Consequences Product Text

End Operator

Class of SINGLETON will describe the instantiation process for the objects speci ed by SINGLETON Class of ADV/ADO SINGLETON Declarations Attributes NumberOfMembers: nat; Actions Creation CreateClass; Destruction DestroyClass; AddObject: nat; RemoveObject: nat; Nested ADVs/ADOs Sequence Object of SINGLETON; Static Properties Constraints 2 NumberOfMembers  1; Dynamic Properties Valuation CreateClass ! NumberOfMembers = 0; AddObject(N) ! NumberOfMembers = NumberOfMembers +1; RemoveObject(N) ! NumberOfMembers = NumberOfMembers ?1; Interconnection AddObject(N) 7?! Object(N).Creation Actions; RemoveObject(N) 7?! Object(N).Destruction Actions; EndClass SINGLETON

Figure 14: Speci cation of singleton pattern constructor.

19

Operator Design Pattern Composite Objective Compose objects into tree structures to represent part-whole hierarchies Parameters Objects: COMPONENT; Subtasks 1 - Create a Tree Structure. 1.1 - Instantiate Concrete Object: COMPONENT ! COMPOSITE 1.2 - Instantiate Concrete Object: COMPONENT ! LEAFs 1.3 - Compose Objects: LEAFs, COMPOSITE ! COMPOSITE 1.4 - If Subtree is needed: 1.4.1 - Recursively Create SubTrees (Step 1) 1.4.2 - Compose Objects: SubCOMPOSITE, COMPOSITE ! COMPOSITE Consequences A tree structure composed of LEAF objects and COMPOSITE objects is created, where the last ones represent the internal nodes of the tree Product Text

ADV/ADO COMPOSITE Declarations :::

Attributes ComponentType: ADO COMPONENT; Nested ADVs/ADOs Set CompSet of ComponentType; Inherit Component; :::

End COMPOSITE ADV/ADO LEAF Declarations :::

Nested ADVs/ADOs Inherit Component; :::

End Operator

End LEAF

Figure 15: Speci cation of composite pattern constructor.

20

ADV

GlyphInterface

ADV

PictureView

ADV

CharView

ADV

CompositeView

ADV ADO

Picture

ADO

DocumentView

Char

ADO

ADO

Element

Document

Figure 16: The document editor structure circle represents zero or more associations. Thus, in Figure 16, Document is an aggregation of zero or more Element(s) and Composite View inherits from Document View. After the description of the editor using OMT diagrams, each of the objects composing the design is speci ed by means of the schematic structures introduced in Section 3. The case study object speci cations are left incomplete and somewhat simpli ed, so that the basic concepts represented by the ADV approach and the formal expression of design patterns can be easily understood. The rst OMT diagram to be introduced in the editor speci cation is the one describing the basic data structure. This structure is de ned using the composite design pattern, and is illustrated in Figure 16. This structure is used to build a document and its view from basic elements, which in our example are characters and pictures. While the application objects (ADOs), de ned in Figure 17, are oriented toward sequencing of document elements, the interface objects (ADVs), speci ed in Figure 18, represent the user views of the document, consisting of columns and lines of text. Thus, we used the ADV/ADO schemas to maintain a separation of concerns between objects and views of those objects. The sequence of elements is stored in the Document ADO, while the organization of the text in columns and lines is de ned by the composite design pattern, which consists of ADV objects. Character and picture views are represented by CharView and PictureView ADVs, respectively, while the document hierarchy is de ned by CompositeView ADVs. All of these ADVs have interfaces de ned by the GlyphInterface abstract class. 21

ADO Document Declarations Attributes DocType: string; Eectual Actions InsertElement: index, ADO Element; DeleteElement: index; Nested ADOs Sequence ElemSeq of Element; End Document

ADO Element Declarations Eectual Actions SetCode: nat; SetFileName: string; SetFormat: string; End Element

ADO Char Declarations Attributes Code: nat; Eectual Actions Element.SetCode: nat; Nested ADOs Inherit Element; End Char ADO Picture Declarations Attributes FileName: string; Format: string; Eectual Actions Element.SetFileName: string; Element.SetFormat: string; Nested ADOs Inherit Element; End Picture

Figure 17: Basic ADOs of the document editor The command pattern de nes how the document editor functions associated with the user interface buttons are encapsulated inside objects. While the ButtonsView ADV composes a set of Button ADVs to create menus or any other user interface objects, the Command ADV de nes an abstract class that speci es the interface of the objects that will implement the respective button operations. Additionally, the Button ADV composes objects that inherit the Command interface in order to call the functions associated with these objects. In Figure 19 we show the OMT diagram containing the application of the command design pattern to the case study. The diagram shows the objects described in the previous paragraph together with two examples of interface objects inheriting from the Command ADV, namely ChangeFont and CutText. While the former ADV is related to the CharView ADV, from which it triggers methods that changes the character font, the CutText ADV performs its operations based on its relation to the DocumentView ADV. All of these objects have their speci cation schemas described in Figure 20. In this case study, we use the decorator design pattern to add border and scroll bars to the user view of the editor. Using the de nition of this pattern in Figure 12 together with the diagrams and schemas shown in Figure 21, we see that the EnhancedDocumentView ADV de nes the embellished user view of the editor. Such an ADV inherits its interface from the Decorator ADV, which has the responsibility of de ning links between the DocumentView ADV and the EnhancedDocumentView ADV. The facade pattern is the fourth pattern used in our speci cation and it has a very simple role. It composes the functions of the EnhancedDocumentView and ButtonsView ADVs in order 22

ADV DocumentView ForADO Document Declarations Attributes CompositeView.GlyphInterface.Child: ADV GlyphInterface; Eectual Actions CompositeView.GlyphInterface.InsertChild: ADV GlyphInterface, index; CompositeView.GlyphInterface.RemoveChild: index; CompositeView.GlyphInterface.Draw: window, position; CreateElement: index, ADV GlyphInterface, ADO Element; RemoveElement: index; Nested ADVs Inherit CompositeView; End DocumentView ADV GlyphInterface Declarations Eectual Actions SetFont: string; Draw: window, position; InsertChild: ADV GlyphInterface; RemoveChild: ADV GlyphInterface; End GlyphInterface

ADV PictureView ForADO Picture Declarations Attributes Size: nat; Eectual Actions GlyphInterface.Draw: window, position; Nested ADVs Inherit GlyphInterface; End PictureView

ADV CharView ForADO Char Declarations Attributes Font: string; Eectual Actions SetFont: string; GlyphInterface.Draw: window, position; Nested ADVs Inherit GlyphInterface; End CharView

ADV CompositeView Declarations Attributes GlyphInterface.Child: ADV GlyphInterface; Eectual Actions GlyphInterface.InsertChild: ADV GlyphInterface; GlyphInterface.RemoveChild: ADV GlyphInterface; Nested ADVs Inherit GlyphInterface; Sequence ChildSeq of GlyphInterface.Child; End CompositeView

Figure 18: ADVs forming the composite pattern

23

ADV

ButtonsView

ADV

ADV

Button

Command

ADV

ChangeFont

...

ADV

CutText

ADV

ADV

CharView

DocumentView

Figure 19: The command design pattern application to present the user interface as a single structure. Such a pattern and the ADV it introduces are shown in Figure 22.

6 C++ Code Schemas In this section we illustrate two C++ schemas for the element in the glyph editor and the glyph interface. We use these two examples to indicate a possible approach to converting the ADV/ADO schemas of the glyph editor application into a working program in a conventional programming language. First we create abstract or base classes for both ADOs and ADVs so that any objects which inherit from those base classes conform to the ADV/ADO model. Of course every object must inherit from either an ADV or ADO base class in order to maintain the integrity of the model. In the design pattern approach there will normally be ADV or ADO base classes for each pattern used in a design. The Element ADO described in Figure 17 is translated into a C++ abstract class with the same name in Figure 23, and is a base ADO class for the simple design pattern used to describe the document structure. The virtual methods declared in this abstract class correspond to the actions in the ADO schema. All ADOs for document elements inherit their properties from Element; Figure 23 also contains the class for the Char ADO. The C++ schema for the glyph interface in Figure 24 is a base class for ADVs which are composed into a structure through the application of the Composite pattern. Since CharView de ned in Figure 24 is in this structure it inherits from this base class. The mapping which provides the consistency between objects and views is implemented in the ADO and ADV abstract classes and is based on the Observer design pattern. Although we have de ned the base classes for the ADV approach, we do not present them here. These classes in eect provide an objectoriented implementation infrastructure for the ADV/ADO model and are much too detailed to 24

ADV Command ADV ButtonsView Declarations Declarations Eectual Actions Attributes Execute; CommandName: ADV Command; End Command Eectual Actions AssociateCommToButton: ADV Command; ADV ChangeFont Nested ADVs Declarations Set ButtonSet of Button; Attributes Dynamic Properties FontName: string; Interconnection Eectual Actions WithADV Button Change: string; SetCommand 7?! AssociateCommToButton; Command.Execute; End ButtonsView Nested ADVs Inherit Command; Dynamic Properties Interconnection WithADV CharView SetFont 7?! Change; ADV Button End ChangeFont Declarations ADV CutText Attributes Declarations ButtonName: string; Attributes Position: position; PosInit: nat; CommandName: ADV Command; PosEnd: nat; Causal Actions Eectual Actions Pressed: boolean; Remove: index; Eectual Actions Command.Execute; SetCommand: ADV Command; Nested ADVs Nested ADVs Inherit Command; Compose CommandName; Dynamic Properties Dynamic Properties Interconnection Interconnection WithADV DocumentView WithADV Command RemoveElement 7?! Remove; Execute 7?! Pressed; End CutText End Button

Figure 20: Objects of the command design pattern application

25

ADV

GlyphInterface

ADV

ADV

Decorator

CompositeView

ADV

ADV

DocumentView

Enhanced DocumentView

ADV Decorator Declarations Attributes Doc: ADV GlyphInterface; Eectual Actions GlyphInterface.Draw: window, position; Nested ADVs Compose Doc; Inherit GlyphInterface; End Decorator ADV EnhancedDocumentView Declarations Attributes ScrollText: index; Decorator.Doc: ADV GlyphInterface; Eectual Actions Decorator.GlyphInterface.Draw: window, position; DrawBorder; DrawScrollBar: position; Nested ADVs Inherit Decorator; Dynamic Properties Behavior Idle ^ Decorator.GlyphInterface.Draw ! Started; Started ^ Decorator.Doc.Draw ^ DrawBorder ^ DrawScrollBar ! Idle; End EnhancedDocumentView

Figure 21: The decorator design pattern

ADV EditorView Declarations Nested ADVs Compose EnhancedDocumentView, ButtonsView; End EditorView

ADV

EditorView

ADV

Enhanced DocumentView

ADV

ButtonsView

Figure 22: The facade design pattern 26

present. Implementation strategies other than those based on the Observer pattern have also been investigated. Code schemas such as the ones illustrated can be easily generated from the ADV/ADO schemas and can form a skeleton that can be completed by the programmer using the temporal logic de nitions as a guide; a similar approach has been described in [dCLF93]. We are currently examining the degree of automation that may be applied to this process.

7 Conclusions We describe in this paper a formal approach to using \good" programming practice as embodied in design patterns. Design patterns are described using a process programming description which helps in clarifying the intent of each type of pattern. In addition, the patterns have been speci ed so as to incorporate the concept of objects (ADOs) and views (ADVs). Our process-oriented approach to design patterns allows us to de ne primitive design pattern tasks or constructors that can be used in the development of speci c instantiations. We believe that this approach clari es both the application and structure of the design patterns. Using this formal approach including objects and views directs us toward several important results. By using components we are able to reason about the design and prove formally speci ed properties as shown in [ACL95, BACL95]. Of course systems often do not yield to formal approaches because of their size and complexity. However, the formal approach could still produce useful results in that the models generated could be used to aid in the testing process [BACL95] by serving as a basis for test case generation [Kor90], or by providing a means for measuring test coverage. Experiments with the process program description has shown that design patterns can yield corresponding C++ schemas which can be completed by the designer through an interactive dialogue. We are completing our experiments with C++ code generation and have started work on an interactive tool to ll in and generate the schemas. The relationship of objects and views to subject-oriented programming [HO93] has been explored in [ACC95], where ADV classes, ADOs and ADVs could be interpreted as formal descriptions of subjects, objects and subject activations respectively. Thus, we believe we can link the component-based reuse approach embodied in subject-oriented programming to the process-based reuse of designs as exempli ed in design patterns.

8 Note to the Reader Many of the technical reports mentioned in this paper are available via anonymous ftp from [csg.uwaterloo.ca] at the University of Waterloo. The names of the technical reports are in the le \pub/ADV/README" and electronic copies of the reports in postscript format are in the directories \pub/ADV/demo", \pub/ADV/theory", and \pub/ADV/tools". These reports are also on the World Wide Web at http://csg.uwaterloo.ca:80/ADV.html or ftp://csg.uwaterloo.ca/pub/.

27

/////////////////////////////////////////////////////////////////////// // ADO Element // The class representing the elements of the document. /////////////////////////////////////////////////////////////////////// class Element : public ADO { public: // Class constructor Element(); // Functions virtual void virtual void virtual void

which produce element state changes setCode(unsigned char); setFileName(const char*); setFormat(const char*);

// Class destructor virtual ~Element() {} }; /////////////////////////////////////////////////////////////////////// // ADO Char // The object representing character document elements. /////////////////////////////////////////////////////////////////////// class Char : public Element { // private unsigned char code; public: // Class constructor Char(unsigned char c) : code(c) {} // Modify our character value if a new one is specified void setCode(unsigned char c) { if (code != c) { code = c; // Notify any ADV's of a change in our state via // the ADO base class operation 'stateChange()' stateChange(); } } // Class destructor ~Char() {} };

Figure 23: Code schemas for element

28

/////////////////////////////////////////////////////////////////////// // ADV GlyphInterface // The class representing an object view for an Element ADO /////////////////////////////////////////////////////////////////////// class GlyphInterface : public ADV { public: // Register the view for the object GlyphInterface(const ADO* ado) : ADV(ado) {} // Functions virtual void virtual void virtual void virtual void

which produce GlyphInterface state changes setFont(const char*); draw(Window& win, const Position& pos); insertChild(GlyphInterface* child); removeChild(GlyphInterface* child);

// Class destructor ~GlyphInterface() {} };

/////////////////////////////////////////////////////////////////////// // ADV CharView // The object view for a character document element. /////////////////////////////////////////////////////////////////////// class CharView : public GlyphInterface { // private const char* font; public: // Register the view for the object and initialize the font CharView(const Char* c, const char* f = 0) : GlyphInterface(c), font(f) {} // Associate a new font with the current view void setFont(const char* _font) { if (strcmp(_font, font) != 0) { font = _font; stateChange(); } } // Class destructor ~CharView() {} };

Figure 24: Code schemas for glyph interface

29

References [ACC95] P.S.C. Alencar, D.D. Cowan, and Lucena C.J.P. Abstract Data Views as a Formal Approach to Subject-Oriented Programming. Technical Report CS-95-19, University of Waterloo, Waterloo, Ontario, Canada, May 1995. [ACL95] P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. A Logical Theory of Interfaces and Objects. Technical Report CS-95-15, University of Waterloo, Waterloo, Ontario, Canada, 1995. submitted to IEEE Transactions on Software Engineering. [ACLN95] P.S.C. Alencar, D.D. Cowan, C.J.P. Lucena, and L.C.M. Nova. Formal speci cation of reusable interface objects. In Proceedings of the Symposium on Software Reusability (SSR'95), pages 88{96. ACM Press, 1995. [BACL95] P. Bumbulis, P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. Combining Formal Techniques and Prototyping in User Interface Construction and Veri cation. In 2nd Eurographics Workshop on Design, Speci cation, Veri cation of Interactive Systems (DSV-IS'95). Springer-Verlag Lecture Notes in Computer Science, 1995. to appear.

[BGHS91] G. Blair, J. Gallagher, D. Hutchison, and D. Shepherd. Object-Oriented Languages, Systems and Applications. Pitman, 1991. [CCL93] L. M. F. Carneiro, D. D. Cowan, and C. J. P. Lucena. ADVcharts: a Visual Formalism for Describing Abstract Data Views. Technical Report 93{20, Computer Science Department and Computer Systems Group, University of Waterloo, Waterloo, Ontario, Canada, 1993. [CGH92] Stefan Conrad, Martin Gogolla, and Rudolf Herzig. TROLL light: A core language for specifying objects. Technical Report 92-02, Technische Universitat Braunschweig, December 1992. [CHB92] Derek Coleman, Fiona Hayes, and Stephen Bear. Introducing objectcharts or how to use statecharts in object-oriented design. IEEE Transactions on Software Engineering, 18(1):9{18, January 1992. [Che91] George W. Cherry. S-R Machines: a Visual Formalism for Reactive and Interactive Systems. ACM Software Engineering Notes, 16(3):52{55, July 1991. [CILS93a] D. D. Cowan, R. Ierusalimschy, C. J. P. Lucena, and T. M. Stepien. Abstract Data Views. Structured Programming, 14(1):1{13, January 1993. [CILS93b] D. D. Cowan, R. Ierusalimschy, C. J. P. Lucena, and T. M. Stepien. Application Integration: Constructing Composite Applications from Interactive Components. Software Practice and Experience, 23(3):255{276, March 1993. [CL95] D.D. Cowan and C.J.P. Lucena. Abstract Data Views: An Interface Speci cation Concept to Enhance Design. IEEE Transactions on Software Engineering, 21(3):229{243, March 1995. 30

[Coa95] [CS95] [dCLF93] [FHW93] [GCH93] [GHJV95] [GVH+ 94] [Har87] [HO93] [Kor90] [KP88] [LS94] [MP92] [Rum91]

P. Coad. Object Models: Strategies, Patterns & Applications. Yourdon Press, 1995. J.O. Coplien and D.C. Schmidt, editors. Pattern Languages of Program Design. Addison-Wesley, 1995. Dennis de Champeaux, Douglas Lea, and Penelope Faure. Object-Oriented System Development. Addison-Wesley, Reading, Massachusetts, 1993. B. Fields, M. Harrison, and P. Wright. From Informal Requirements to Agent-based Speci cation: an Aircraft Warnings Case Study. Technical report, University of York, August 1993. Martin Gogolla, Stefan Conrad, and Rudolf Herzig. Sketching Concepts and Computational Model of TROLL Light. In Proceedings of Int. Conf. Design and Implementation of Symbolic Computation Systems (DISCO'93), Berlin, Germany, March 1993. Springer. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company, Reading, Massachusetts, 1995. M. Gogolla, N. Vlachantonis, R. Herzig, G. Denker, S. Conrad, and H.D. Ehrich. The KORSO approach to the development of reliable information systems. Technical Report 94-06, Technische Universitat Braunschweig, June 1994. David Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8(3):231{274, June 1987. William Harrison and Harold Ossher. Subject-Oriented programming (A Critique of Pure Objects). In OOPLSA'93. ACM, 1993. Bogdan Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870{879, August 1990. Glenn E. Krasner and Stephen T. Pope. A Cookbook for Using the Model-ViewController User Interface Paradigm in Smalltalk-80. JOOP, pages 26{49, August 1988. N. Levy and G. Smith. A Language Independent Approach to Speci cation Construction. In Proceedings of the SIGSOFT'94, New Orleans, LA, USA, December 1994. Zohar Manna and Amir Pnueli. The temporal logic of reactive systems: Speci cation. Springer-Verlag, 1992. James Rumbaugh. Object-oriented modeling and design. Prentice Hall, 1991.

31