object-oriented modeling of software patterns.pdf

7/28/2019 Object-Oriented Modeling of Software Patterns.pdf

1/10

Object-Oriented Modelingof Software PatternsTakashi Kobayashi Masahiko Kamo Takayuki Sanui Motoshi Saeki

Dept. of Computer Science, Tokyo Instituteof TechnologyOokayama 2- 12- , Meguro-ku, Tokyo 152-8552, apanTel: +81-3-5734-2192 Fax:+81-3-5734-2917/ {tkobaya,saeki}@cs.titech.ac.jp

AbstractThi s paper di scusses a technique to model software pat-terns such as Gang-OF -F our (GO F ) design patterns forsupporting pattern based software development. Softwarepatterns are general structures that requently appear in thearti facts and encourage effective reuse of past successful ex-perience. To support pattern based software development,we model the patterns r om object-oriented viewso that ma-chine processing is possible. In our approach, we considerthat a pattern consists of a pattern structure ( a class dia-gram) and manipulation operationson the pattern structurein order to use it. These manipulations are classijied intothree types: attern instantiation (applying a pattern to anactual problem, i .e. fil ling their hot spots), pattern com-bination (combining several patterns into larger one) andpattern refinement (refine a pattern into more concrete one).These manipulation operations are specijic to patterns andeach pattern is a class which they are encapsulated into.We have described 22 Gang-Of-Four design patterns withJ ava and developed a supporting tool fo r using patterns.The tool has been developed by using our approach itselfand it shows the usefulness of our approach.K eyword: Design Pattem, Object-Oriented M odeling,Software Pattem, J ava

1 IntroductionSoftware patterns such as Gang-of-Four (GOF) designpattern[4], Fowlers analysis pattern[3] and architecturalpattems[l ] are one of the promising techniques to developsoftware of high quality efficiently. They are general andabstract structures that frequently appear in past experiencesin developing well-structured and maintainable artifacts andcan be efficiently re-used for new software developmentprojects.A lthough many researchers and practitioners jointly havemuch efforts on collecting and cataloguing pattems [7], itmay be difficult for software developers to select suitablepattems and use efficiently them, when we only provideinformal descripti ons of the pattems like textbooks. T osupport software development based on patterns, we shouldmodel the patterns as formally or semi-formally as comput-ers can manage, so that a computerized tool like [2] can

support software development processes based on softwarepattems.In this paper, we propose a modeling technique of soft-ware patterns from object-oriented viewpoint, and describethem with the programming language J ava, a formal lan-guage. Describing pattems with J ava all ows us to executethe pattems and the execution of the patterns means their ap-plications during actual development processestocompletean artifact. I t leads the enactment of software developmentprocesses based on patterns. Therest of the paper is orga-nized as follows. In the next section, we show the basic ideaof object-oriented modeling for sof tware pattems. A pattemhas a specific structure and specific manipulation operatorstochange its structure. During a pattern-based developmentprocess, the structure of the applied pattern is incrementallybeing changed as the process goes by. M anipulation oper-ators specify how we can change the structure of a patternwhen it is applied, and these operators are specific to apattern. From object-oriented view, a pattern is modeled asa class encapsulating the operators that are for f il ling its hotspotswhen we apply it to software development, and we callthis type of operation instantiation. Sections 3 and4discussthe other two types of manipulation operators for evolvingpattems ;combination (combining patterns to have a largerpattern) and refinement (refining a pattern to more concreteone). Pattem combination and refinement can be modeledas aggregation and specialization (inheritance) of patternsrespectively. In section 5, we will introduce the experi-ence in describing 22 GOF design patterns with Java andin developing a supporting tool for pattern-based softwaredevelopment. We have applied our modeling technique tothe development of the tool itself. Finally we discuss thistechnique and list up the future work.2 Object-Oriented Model for Software Pat-terns2.1 Command Pattern Example

Before modeling software pattems, we consider a simpleexample of G OF design pattern. Figure 1(a) and (b) illus-trate Command Pattem and the way to use it, respectively.Command Pattem has several commands as classes, whichhas the same interface execute(). When I nvoker wantsto execute a command, it sends the message execute()

0-7695-0906-1/01$10.000 2001IEEE 100
mailto:cs.titech.ac.jpmailto:cs.titech.ac.jpmailto:cs.titech.ac.jp


2/10

(a) Command Pdlem

duu

Figure 1. Command Pattern

to the object which is stored in the variable command, i.e.we write the statement command.execute() in the methodof Invoker class. T he class Command is an abstract classand has no implementation of the method execute(). Toimplement execute(), we add a concrete class as a sub-class of the Command class and i t has the implementation,i.e. the source code of execute(). As shown in Figure1 (b), we can have ConcreteCommandA as a subclass. Ifwe create an object of ConcreteCommandA and assign i tto the variable command , Invoker can call execute() ofConcreteCommandA without any change of the source codeof Invoker. If we would like to have a new command tobe executed by Invoker, we only add the correspondingconcrete class, say ConcreteCommandB, and update thevariable command to an object of ConcreteCommandB be-fore invoking its execution. T he important point isthat wedo not need change the source code of Invoker because bothof the commands has the same interface, i.e. execute().This structure allows us todynamically switch the contentsof the commands to be executed.

T o use Command Pattern, we should add as the sub-classes of an abstract class the concrete classes that havethe same interface to command execution. I t is the onlypart where we can change the structureof Command Patternwhen we use it. This kind of changeable parts are calledhor spots. Which parts are hot spots in a pattern and howto f i l l the hot spots greatly depend on the pattern. In theexample of Command Pattern, the way how to fill the hotspots is adding a subclass having execute() to an abstractclass Command. A dding a subclass to a class can beconsidered as one of basic operations on the structure of apattern and we can define how to fill the hot spots with asequence of basic operations. We call this kind of operationto f i l l the hot spots insruntiationoperations. Sinceapatternhas a specific structure as shown in Figure 1 (a) and itsinstantiation operations arealsospecific to it, we can modela pattem with a pair of its structure and the instantiationoperations. The detailed definitions of the operations can beencapsulated into the definition of patterns. That is to say,we can model a pattern as a class (say, pattern class) from

. InstantiationMethods-peration#()(1) cls=createClass2) cmd.addSubClass(cls)(ConcreteCommand).....)Operation#P()()......

Figure 2. Object-Oriented Modeling of Pat-terns

object-oriented viewpoint. In this modeling, the structureofapattern is produced by executing its constructor (amethodfor object creation) and the operations are considered asmethods of a pattern class (instance methods). SeeFigure2. When we use a pattern, first of all we execute a con-structor of this pattern class and generate an instance of theclass. The generated pattern instance has its initial structureas shown in Figure 1 (a). We incrementally change itsstructure, i.e. fill its hot spots by using i ts instantiationoperations and get the final artifact of the system to bedeveloped.Although we can have various kind of representationtechniques of pattem structures, e.g. usecase diagrams foruse case patterns [6], we use class diagrams because classdiagramsare widely used and almost all of patterns areonclass diagrams.2.2 BasicOperations

As we discussed in the last section, the operations tochange pattern structuresareon class diagrams. The typicalexamples of basic manipulation operators on class diagramsare listed up below. Wehave implemented these operationswith Java, All of the operations to change pattern structurescan be defined by using these basic operations.Creating a class whose name is Name. (Constructor ofClass)Adding aclass Class2 as asubclassof Class,.Adding a classClass2as asuper classof Classl.

0 createClass(Name)0 Class1 addSubclass(Classz)0 Class1 addSuperclass(Class2)0 Class1 addA ssociation(Association, Classz)

101


3/10

Adding an association Association between Class] andClass*.Class1 addAggregation(Classz)Addinganaggregation between Class1 and Classz.createMethod(definiti0n)Creatinga method whose code is definition. (Constructorof Methods)Classl addMethod(Method)Addinga method M ethod toClass]Classl addAttribute(,lttributel)Adding an attributeAttribute1 toClass].

How to use these basic operations will be discussed inthe next subsection. Note that these basic operations canbe considered as constructors of class diagrams and thatthe effects of executing the operations follow the usualsemantics of J ava programs.2.3 Describing Pattern Structures

As discussed before,apattern structure is generated as aninstance when we use the pattern. In the case of C ommandPattern, its initial structure has the classes Invoker andCommand, the method execute() in C ommand class, andthe association command. Thus we can describe the initialpattern structure as a constructor CommandPattern() byusing basic operations as follows;CommandPat t ern ext ends Pat t ernc l ass (

publ i c PMCl ass ac ommand, ;pub l i c PMCl ass i nvoker ;publ i c PMAssoci at i on i nvokerTocommand ;pub l i c CommandPat t er n0 (set Name( C0mmandPat t er n ) ;

i nvoker = c r e a t e Cl a s s ( 1 nv ok er ) ;ac omman d = cr eateC l ass ( Command ) ;i nvoker Tocommand =i n vo ke r . a dd As s o c i a t i o n(PMMet hod m =ac ommand. addMet hod( m1) ;

/ * set t he name of t h i s p at t e r n */

c r e a t e As s o c i a t i o n( Co mma nd ) ;i nvok er Toc ommand, aco mmand) ;c r e a t e Me t h o d ( e x e c ut e 0 + nul l ) ;

1...Note that, to avoid the conflicts to the reserved wordsof J ava such as class, in J ava source codes we attachedthe prefix PM for the words denoting the constituentsof pattems. For example, PM Class stands for the type ofclass appearing in a class diagram of a pattern structure.PM Method and PMA ssociation are used for method typeand association one respectively. The class Patternclasshas these definitions in addition to basic operations.We can get the ini tial structure of Command Patternshown in Figure 1 (a), by executing the above sequenceof basic operations. The global variable acommandholds the information for the reference to the abstract classCommand and the other operations can access it through

this variable. Class invoker is the declaration of thevariable invoker to which an object of C lass is assigned

as the constituent Invoker of the pattern. The operationcreateClass(1nvoker) generates an object of Class whosename is Invoker. That is to say, constituents of a classdiagram such as classes, methods and associations areconsidered as the objects that a class diagram contains.Method ml has a method name execute(), while itsmethod body is none (nul l) because it i s an abstract method.Note that the operator +stands for the concatenation ofstring data. For example, the expression fooM ethod(intA) +fooM ethodBody results in foomethod(int A) {returnA } where the string { return A } is assigned to thevariable fooM ethodBody.2.4 Instantiation Operation

How to describe instantiation operations as methods ofa pattern class is presented in this section by using theexample of Command Pattem. The essential point of theinstantiation operation on Command Pattern is adding aconcrete class ConcreteClass having the implementation ofexecute(). Therefore we can get the following source codeasan instance method of pattern class CommandPattern ;cr eat eCommand( St r i ng new- command) (P MCl a s s c c l a s s =

acommand. addSubcl ass( ccl ass) ;PMMet hod c met hod =cc l ass . addMet hod( cmethod) ;

cr eat eCl ass ( new- command + Command ) ;

c r e a t e Me t h o d ( e x e c ut e 0 + nul l ) ;12.5 Meta Model of Patterns

Figure 3shows the overview of the constituents and theirrelationships that our model of software pattems consist of.I t is represented in a form of class diagram and called a metamodel of software pattems. It is considered as a schemaof object base with which a pattern catalog or library isimplemented in a support tool for pattern based softwaredevelopment.

Figure 3. Overview of a Meta Model of Soft-ware PatternsI n the figure, the Role class expresses what roles the

classes and the objects appearing in a pattern play and it isused for accessing constituents of the pattern, i.e. Class,

102


4/10

Association, Method and Attribute objects in the pattem. Itcorresponds to global variables of a pattem class written inJava. Remember the global variables acommand, invokerand invokerTocommand of Command Pattem descriptionin section 2.3.3 Pattern Combination

The example of Command Pattem was a very simplepattem and was usedjust for the explanation of our modelingtechnique. In actual setting, we always design softwarecombining several exi sting design patterns, and furthermoresometimes register the combinations of patterns as newpattems. These larger and more complicated pattems areuseful to develop larger and/or domain-specific softwaresystems [ 5 ] . The combination of patterns is also a pattemforcomposing coarse grain patterns from finer grain ones.Consider a simple example of a pattem combination ofCommand pattern and Composite pattem of GOF designpatterns. This pattem is often used to design graphic ed-itors like Tgi f, X fig and V isio, for inputting and editinggraphical objects such as polygons and circles. Figure 4ill ustrates how to combine Command and Composite Pat-tems. Composi te Pattern is frequently used to design theobjects having recursive structure such as tree structure. Inthis example, it is used to represent graphic objects hier-archically. The graphic editor has a function of groupingseveral graphic objects into one and a group of the objectscan be designed as a class Composite in the pattem. Ifan operation is invoked to a composite object, its executionis repeated on. all of the elements in the composite object.For example, when Invoker is requested to perform thecommand of moving a selected graphic object on the dis-play screen, it sends the message execute() to a concretecommand Movecommand, in order to invoke the move op-eration. M ovecommand sends the message move() to theselected object which is specified through the associationrefer from Command class toComponent class. Compos-ite class distributes i t to all of its children objects (foreacho E children o.move()).These children objects know howto execute the move operation by themselves. For example,the circle objects change the X and Y coordinates of theircenters, while in the case of the polygons, all of their ver-tices should be moved. Note that the hot spot of CompositePattern is the subclass of the abstract class of Componentand we can add various kind of classes of graphic objectssuch asEllipse and Triangle.The hot spots of a combined pattern result from thehot spots of patterns that it contains. Thus the patternCommand-Composite Pattern has as its hot spots both ofCommand and Composite pattems hot spots. For exampleif we need a new command of resizing graphic objects, wecan add the concrete command class ResizeCommand asa subclass of Command by using the instantiation operationof Command Pattern as shown in section 2.4. We canalso extend the design of the graphic editor so that it canmanipulate polygon objects by adding a subclass Polygonto Composite class. I t can be done by the instantiationoperationof Composite Pattern.

~

Although we can fill the hot spots of Command Pattemand Composite Pattem independently by using their instan-tiation operations, we may frequently fill more than one hotspots, because each hot spot has a dependency relationshipto the other spots in this combined pattem. For example, ifthe concrete class M ovecommand has been already added,any concrete classof graphic objects should have the oper-ation move() that really moves the object. Assume thatwe add a new command that resizes the selected object,by using the instantiation operation of Command Pattern.The effect of adding the new command on the CommandPattem should be propagated to the combined CompositePattern part. More concretely, we should add to each classthe method resize() which changes the size of the graphicobjects, and its contents, i.e. source code depend on theclass.Thus an instantiation operation createcommand() forthe combined patterns 1) invokes the createcommand()toCommand Pattern part, and then 2) performs the operationfor adding a method resize() to all of the concrete classesand Composite class. Thus we can get the description ofthis combined pattem as fol lows;Command- Composi t e- Patt ern ext ends Patt er ncl ass

(pub l i c Pat t ern commandpat t er n ;publ i c P at t e r n c omp os i t e - p at t e r n ;p ub l i c P MAs s o c i a t i o n r e f e r ;/ * Co ns t r u c t o r */publ i c Command-Composi t e- Pat t er n0 (command- patt er n = new CommandPat t er n0 ;co mp os i t e - p at t e rn = new Compos i t ePat t ern ;r e f e r = c r eat e As s oc i at i on( r e f e r ) ;I

publ i c cr eat eCommand( St r i ng new- command) (commandpat t er n. cr eat eCommand0 ;PMMet hod m = cr eat eMet hod( new- command + nul l ) ;f o r ( i = 0 ;i < c o mp os i t e - p at t e r n . l e af . s i z e 0;i ++)( ( ( c o mpo s i t e- p at t er n . l ea f ). a t E l e me nt ( i ) ) . a dd Me t h od ( m ) ) ;PMMet hod m2 = cr eat eMet hod( new- command + nul l ) ;

( c omp os i t e - p a t t e r n . c omp one nt ) . addMet hod( m2) ;PMMet hod m3 = cr eat eMet hod(new- command + f o r e ach c i n chi l d re n ( c . n ew- co mma nd ) ) ;( c omp os i t e - p a t t e r n . c omp os i t e ) . addMet hod( m2) ;1

1If we send the message createCommand(resize) tothe instance of Command-Composite Pattern, we can get theinstantiated pattern or the design that the resize command isembedded. In the code, we use the access to the constituentsof the patterns such ascomposite-pattem.componentandcomposite-pattern.leaf. The former expression is foraccessing Component class of Composite Pattern part ofFigure4,and the latter forasetof concrete classes connectedto Component as its subclasses. The concrete classes arestored in the variable leu of type Vector and we use themethod atElement to get the i-th element of the connected

103


5/10

CompositePattern. .ommand Pattem ............................ ~ ~ _ i

dcpcndencyberwccn Cammand and Composite

Figure 4. Command-Composite Pattern : Combining Command and Composi te Patternsconcrete classes.Pattern.The following is the part of the definition of CompositeCompos i t ePat t ern extends Pat t ernc l ass {/ * Gl o ba l Va r i a bl e s f o r Acce s s i n gCo ns t i t u en t s of t h e P a t t e r n * /pub l i c PMCl ass c omponent , compos i t e ;p ub l i c Ve c t o r l e af = n ew v e c t o r 0 ;p ub l i c PMAs s o c i a t i o n ch i l d re n ;/ * Co ns t r u c t o r */Co mp o s i t e P at t e r n 0 {s e t N a me ( Co mp 0s i t e P at t e rn ) ;co mponen t = c r e a t e C l a s s ( Co mp on en t ) ;compos i t e = c r e a t e C l a s s ( Co mp os i t e ) ;

component. addAssoci at i on( chi l dren, composi t e) ;c hi l dr e n = c r e at e As soci a t i o n( c hi 1d r en ) ;)...

Note that in this combined pattern we can also define theinstantiation operation of adding graphic object classes toComposite class and it can have propagate the ripple effectscaused by this addition.A lthough how to combine patterns greatly depends onthe dependency relationship between the two patterns andthe relationships can be complicated, in our approach wecan specify them because we write them as Java programfrom operational view to keep consistency among the pat-terns. To model pattern combination, we used aggregationrelationships onpatterns. Figure 5illustrates this techniqueof pattern combination. Suppose that we combine the pat-terns # 1 and #2. We introduce a new pattern and createthe aggregation relationships from the new one to #1 and to#2. That is to say, the patterns #1 and #2 are constituents

- ombined Pattcm I

Figure 5. Model of Pattern Comb ination

of the new pattern. This can be considered asa pattern evo-lution technique that can provide larger and coarse-grainedpatterns such as application f ramework.4 PatternRefinement

In this section, we introduce third type of pattern ma-nipulation operations called refinement by using a simpleexample.4.1 What isRefinement?

Software development processes can be considered asthe successive refinement of artifacts. For example, a re-quirements specification is refined to its design one, and

104


6/10

the design is to a source code. A s mentioned before, wehave various kind of software pattem, e.g. Fowlers anal-ysis pattern for requirements analysis phase, GOF designpattern for object-oriented design and architectural patternfor architecture design. Similar to the refinement of theartifacts, software patterns are refined along the progressof software development. Suppose that a developer usesanalysis pattems to model his problem domain from object-oriented view in requirements analysis step. In his designstep, he applies design patterns to the model and gets itsdesign specif ication. In this process, there must be someguidelines or know-how to apply design patterns to theanalysis pattems. That is to say, the analysis pattern seemsbe refined to the patterns than can be used in design step,according to some rules. We will i llustrate more concreteexample of pattern refinement in the next two sections.4.2 Analysis Pattern Example

Figure6shows one of the simplified versions of AnalysisPatterns (by Fowler) that are used in requirement analysisstep, and called Party-A ccountability Pattern. It is usedfor specifying an organizational structure and relationships(accountability relationships) among persons in the orga-nization, and has a flexible structure that can handle withdynamic changes the organizations and the relationships.For example, it is possible to add new accountability re-lationships and delete the relationships in the organizationduring the developed system are being executed. In thefigure, accountability type declares what kind of relation-ships among the organizational units (e.g. department andbranch etc.) and persons (we call together them parties)exist, while accountability specifies which party types canparticipate in the accountability type.

1 Accountability

Figure 6. Party-Accountabilit y Pattern (Simp-lifi ed Version)

For example, consider that we express the simple or-ganizational structure shown in Figure 7 with the Party-Accountability Pattern. In the figure, you can find twoaccountability relationships lecture-to and supervise.To specify that they are the accountability relationshipsbetween the party types Professor and Student, he cor-responding instances of Accountabil ity (expressed with ***in the figure) have the links to Professor and Student.The hot spots of the Party-Accountability Pattern are

Figure7. SpecificationAccountability Type, A ccountabili ty and Party, andwhat kind of instantiation operations can be made on eachhot spot depend on the hot spot. In the example of Fig-ure7, as shown in Figure 8, the instantiation operation iscomposed from a sequenceof three operations; 1) addingas a subclass of Party an entity class that the organizationconsists of (adding the classes Professor and Student tothe Party as its subclass), 2)creating accountability relation-ship types as instances of A ccountability Type (creating therelationships supervise and lecture-to), and 3) creatingthe instances of Accountabili ty corresponding to the gen-erated A ccountabil ity Type instances, and linking them toParties (creating two A ccountabil ity instances correspond-ing to supervise and lecture-to and linking them toStudent and Professor).

Acco untabi t y Type 1 Accountability

I

Figure8. Instantiation of Party- Account abilityPatternThe following is the description of Party-A ccountabilityPattern together with the instantiation operation.

c l a s s Pa r t y - Ac c oun t abi l i t y - Ana l y s i s P at t e r nextends PMPatt er n {P MCl a s s a cco un t a bi l i t y - T yp e ;P MCl a s s a c c ou nt a b i l i t y ;PMCl ass part y ;V ec t o r co nc re t e pa r t y = n e w v e c t o r 0 ;i nt i ;I ns t a nt i at e - P ar t y ( s t r i ng Concret epar t y - name) (

cr eat eCl ass ( C0ncr e tePar t y - name) ;co nc r e t e P ar t y . a t E l e me nt ( i ) =p ar t y . ad dS ub Cl as s ( Con cr e t e P a r t y ) ;i = i + l ;1I ns t a n t i a t e - A cc ou nt a b i l i t y ( Re l a t i o ns hi p,P ar t i c i pa nt #l ,

105


7/10

~a r t i c i p an t #2 )Accou nt a b i l i t y - T yp e xAc c ount a bi l i t y y = new Ac c ou nt a bi l i t y 0 ;y . a ddAs s oc i a t i o n( c r e at e As s oc i a t i o n( n u l l ) , x ) ;y . a ddAs s oc i a t i o n( c r e at e As s oc i a t i o n( n u l l ) ,y . a ddAs s oc i a t i o n( c r e at e As s oc i a t i o n( n u l l ) ,

= new Ac c ount a bi l i t y - Ty pe ( Re l a t i o ns h i p) ;

P ar t i c i pa nt #1) ;P ar t i c i p an t #2 ) ;I

/ * Def i ni t i on of I n ne r Cl a s s e s */c l a s s Ac c ount a bi l i t y (1 .. .c l a s s Ac c ou nt a b i l i t y - T yp e (

A- -

For example, to make the accountabil ity su-pervise, we create an instance of Party-AccountabilityA nalysisPattern class and send it a messageI nstanti ateAccountabi l i ty( supervi se ,Professor, Student).Note that we had inner class defini tions class Account-ability { ... } and class Accountabili ty-Type { ... },because we need generating instances of Accountabil ity andAccountability-Type classes.

4.3 Pattern Refinement Example

Lets suppose that we proceed the design task onParty-A ccountabil ity Pattern. To make use of this Party-Accountabil ity Pattern in the structure of a design specifi-cation, we refine Accountabil ity T ype and Accountabili tyclasses so that they possesses the mechanism to createinstances (e.g. creating A ccountabil ity T ype instances su-pervise and lecture-to, etc.).The refinement rule of the analysis model to a designmodel is that we add a class Creator that creates Account-

abili ty Type instances and associate it with Accountabili tyclass. T his refinement process is depicted in Figure 9. Inthe pattern, i.e. Figure 9 (a),the class Creator is an abstractclass, and its concrete class is made as its subclass whencreating the instances of A ccountabil ity during the instanti-ation process. For example, by introducing Accountabil ityType instance supervise, we add a concrete class Cre-atorSupervise that is for generating the links between aStudent instance and a Professor one. The reason why weuse an abstract class is that we can write a single codeof making links between party instances independently ofAccountabil ity Types. T his is the same strategy of FactoryMethod of GOF design pattems.The way how to refine an analysis model into a designmodel depends on what instantiations have been done onParty-A ccountabil ity Pattern in the analysis model, and the

pattern can have several refinement operations according todesign strategies.

1II party 1a) Fattem n DesignCreator

CreateAcwuntabd tyOsup emse

CreateAcEuuntab l i t)@) I nstanti ati on

Figure 9. Re nement Example of Party-Accountability Pattern

4.4 Modeling Pattern RefinementThe way how to refine patterns is also specif ic to apattern,and can be specified as a series of manipulation operationson a pattern structure (class diagram) in the similar way tothe definition of i nstantiation operations. Pattern refinementcauses not only the change of a pattern structure but alsothe change of instantiation operations. Therefore addingmethods andlor modifying source codes in the methods in apattern class is alsonecessary for a pattern refinement.

Pattern #2+xnstanti ati onZ#I ) OP?#C2) OP?#D

OP2KInstanhahonl#I ) I nslanti auonn?#2) OPWE

Figure 10. Pattern RefinementThe refinement keeps whole of or a part of the patternstructure. Comparing Figure 9 (a)with Figure 6, the read-ers can recognize that the structure of Party-A ccountabil ity

Pattern is stil l included in its refinement. T hus we use spe-cialization relationship on pattern classes to model pattern

106


8/10

refinement. Suppose that pattern# is refined into pattern#2. The pattem #2 is oneof the specializations of pattern #1,and the structure and the instantiation operations of pattern#2 is inherited from pattern #I . The pattern structure andthe operations of pattern #2 can be changed. To achievethese changes, we override the definitions of pattern #I inthe same way as the override mechanism of super-subclassinheritance. That is to say, we override the constructors forstructural changes and the methods for changes of instan-tiation operations. Figure 10illustrates these two changesof a pattern structure and of the methods as instantiationoperations.In the example of Figure 9, we have the followingchanges; 1 ) change of a pattern structure : the classCreator that generates Accountabil ity instances is con-nected to Accountabil ity class (ovemding the construc-tors), and 2) change of an instantiation operation Instanti-ateAccountabili ty : the Party classes participating in gen-erated Accountabil ity instances are added, and the methodfor associating the accountability with the parties is added(overriding the instantiation operations). In this case, sincethe analysis pattern can appear in adesign pattern as it is, wecan get the design pattern by inheriting the analysis pattern.We capture a specialization (inheritance) relationship asanrefinement relationship. That is to say, a pattern class isrefined into the pattern that is its subclass. T he constructorof Ref i nedPart y-Account abi l i t yAnal ysi sPat t ern (Figure 9(a)) and its instantiation operation are newly defined, i.e.the definitions of Part y-Accountabi l i ty- Analysi sPatternareoverridden.Re f i ned- Par t y - A cc ount a bi l i t y - A na l y s i s Pat t e r nextends Par t y - A cc ount a bi l i t y - A na l y s i s Pat t e r n (

PMCl ass cr eator ;/ * New Const r uct or of P a t t e r n */P ar t y - A cc ount a b i l i t y - De s i g nP at t e r n0 I/ * p ro du c i n g t h e s t r u c t u r e of

s u p e r 0 :/ * Co nn ec t i n g Cr e at o r t o Acco u nt a bi l i t y Cl a s s */c r e a t o r = c r e at e Cl a s s( Cr e a t 0r ) ;Ac c ount a bi l i t y . a dd Ag gr e g at i o n( c r e a t o r ) :/ * Ad d a n a bs t r a c t me t h od C re a t o r Acco u nt a bi l i t y( I nt e r f a ce onl y ) */PMMet hod m = cr eateMet hod(

P ar t y - A cc ou nt a b i l i t y Pa t t e r n * /

c r e at e Ac c ount a bi l i t y ( P ar t y p l ,P ar t y p 2 ) ( 1 ) ;cr eator . addMet hod( m) :1/ * Ne w I n s t a nt i a t i o n Op era t i o n *// * Ma ki n g u p Re l a t i o ns h i p t h e r e l a t i o ns h i pb et we en Pa r t i c i p an t #l a nd Pa r t i c i p an t #2 */I ns t a nt i a t e- Ac c ount a bi l i t y ( r e l a t i o ns hi p,pa r t i c i p an t #1,p ar t i c i p an t #2 ) {s upe r . I n st a n t i a t e - Ac c ou nt a bi l i t y ( r e l a t i o ns hi p,pa r t i c i pa nt #l ,p ar t i c i p an t #2 ) ;

/ * Connect i ng Concr eteCreator as a subc l ass */c o nc r e t e c r e at o r =Cr e a t e Cl a s s ( Cr e at 0 r + r e l at i o ns hi p) ;

creat o r . add .Subc l ass (concre teCrea to r ) ;PMMet hod m = c rea teMethod( addLi nk( P ar t y pl ) (

1 )a c co unt a bi l i t y . a dd Me t hod ( m/ * Addi ng a met hod to Creat orT hi s n e w me t h od i s t o as s o c i a t e Re l a t i o ns h i pwi t h P a r t i c i p an t s s 1 a nd P ar t i c i p an t #2 */

PMMet hod m = c r e at e Me t h od ( c r e at e Ac c ou nt a bi l i t y ( + p ar t i c i p an t #l + p l , + p ar t i c i p an t #2 + p2, ) ,(Ac c oun t a bi l i t y r e 1 = n ew Ac c o un t a bi l i t y ( ) ;r e l . addAccoun tabi l i t yType ( r e l a t i onshi p ) ;r e l . a dd Li nk ( p 1) ;r e l . a ddL i n k( p 2) :1 ) :concr eteCreator . addMethod(m

11The Part y-Accountabi l i t yDesi gnPat t ern class has theconstructor Part y-Accountabi l i tyDesi gnPatt ern() and itcalls the constructor of its super class Party-Accountabi l i ty- Anal ysi sPatt ernat first. A fter creating aninstance of Party-Accountabili ty A nalysi sPattem, the classCreator is generated and embedded into the instance ofthe pattern. This operator is the result of overriding theconstructor of the analysis pattem in the design pattern.The class Accountabili ty, which is one of the ele-ments of the pattern, has the method addA ccountabili-tyType(Relationship), and the method is used for relatingRelationship (A ccountabili ty Type, i.e. the name of ac-countabili ty) to the Accountabili ty i nstance. By using thismethod, we can set the name of Accountabil ity superviseto the generated A ccountabil ity instance. The method ad-dL ink is used formaking alink between two instances. I f weexecute rel.addLink(p1) (strictly saying, send a messageaddLink(p1) to the object rel) and rel.add(p2). we establishthe two links of Accountabil ity instances to Party instancespl and p2 respectively. W hen we perform the instantiationoperation I nstant i ateAccountabi l i ty( supervise Professor,Student) on the Party-Accountabil ityA nalysisPattern, the

method createAccountability(Professor pl , Student p2),where pl and p2 are a Professor i nstance and a Studentone respectively, is automatically installed to the concreteclass Creatorsupervise. The concrete class CreatorSuper-vise is created at the invocation of creatorClass(Creator +relationship) where the variable relationship has the valueSupervise.5 SupportingTool5.1 Implementinga Supporting Tool

As one of the application of our modeling technique, wehave developed aprototypeof a tool for supporting softwaredesign based on GOF design patterns. The tool has twoparts ;one is an editor of class diagrams with graphical userinterface and the other one is a manger of design patterns.

107


9/10

Figure 11. SupportingTool

We have described 22 GOF design patterns with Java byusing our description technique mentioned in section 2.Figure11shows asnapshot of using the tool. A developerchoosesa suitable design pattern by clicking the fifth buttonfrom the top in the left li ne. The initial structure of thechosen pattern is displayed on the screen. In this example,he chose Command Pattern (displayed on the left side) andthen Composite Pattern (right side).Whenever he wants to change the names of the classes,operations and attributes in the displayed class diagram,he can do that. When he has a double click on the

class, a dialog box to enter new names appears. In thefigure, one of ConcreteCommand classes has been re-namedto MoveCommand. Furthermore he can add and deleteclasses, operations, attributes, associations, aggregationrelationships and specialization ones ashe uses ausual classdiagram editor, because each of them can be consideredas a pattern by itself. After choosing the two patterns, headded an association between the Command Pattern and theComposite Pattern.If he wants to fill the hot spots of the pattern, he putsa mouse cursor on any constituents of the pattern andclicks it. He can see a list of allowable instantiationoperations of the pattern. In the figure, createcommand andcreateCommandwithReceiver are shown as the allowableoperations of the Command Pattern. When he selects one ofthem, the selected operation, written with J ava, is executed

and a concrete command class is automatically added anddisplayed on the screen.

5.2 ExperienceAfter developed this prototypetool,we have re-designeditby using thetoolitself . Figure 12showsapartofthedesignof the tool by using it. I t is the partof a pattern model and thereaders can recognize the same structure as the meta modelof patterns shown inFigure3.The result of re-designing had

37classes, and 34classes of the37belong tothe constituentsof GOF design patterns. They have been derived only by theinstantiation operations on the design patterns. Eight designpatterns such as Command, Composite, State, Singleton,Observer etc. were applied and the hot spots of the 7design pattems of the8were completely fi lled by using ourpre-defined instantiation operations. This result means thatapplying our modeling technique to GO F design pattemsworks well and this kind of tool is useful tosupport pattern-based software development. The shortcomings of the toolis that it has no support of re-doing design tasks when adeveloper recognizes that he used unsuitable patterns duringhis design task. However, thetool can record a sequence ofapplying instantiation operations as the history of a designtask. T o analyze the sequence, it seems to be possible tosupport how thedeveloper can go back and re-do his designtask without abandoning all of the constituents in the designspecification.6 Conclusion

In our approach, we considered that a software patternconsists of a pattern structure (class diagram) and manipu-lation operations on the pattern structure. T hese operationsare for pattem instantiation (filling hot spots). We modeledthem with object-oriented technique encapsulating these op-erations into patterns, and described patterns with J ava-likeobject-oriented language. In addition, we have explored twotype of pattem manipulation; pattern combination and pat-tern refinement. These have been modeled as aggregationand specialization of pattern classes respectively.We can pick up the research agenda for future work asfollows.Supporting toolsof refinement on pattem:By using the supporting tool, users can select pattemsand combine them into the pattern suitable for theirapplication domain. They are also supported to in-stantiate and to adapt the pattern with its instantiationoperations. Furthermore the tool provides the candi-date of patterns that can be used in the next step. Itis done by applying the refinement operations of thepattern.Consistency check of pattem combination and pattemrefinement:When we combine several patternsorevolve the patterninto a new one, we should check if the new pattern hasno inconsistency, in particular behavioral aspects. Forexample, the behavioral property of the new pattemshould be satisfied with the old pattern when we changethe old pattern into the new one. We wil l consider how

108


10/10

Figure 12. Design of the Tool

a

to provide the formal semantics of pattern behavior byusing a formal method such as i~alculus.Developing pattern base:Pattern base is a kind of database system for patternstogether with three types of operation on pattems andplays an important role on the supporting tool forpattern based software development. It will be imple-mentedonanobject base systemsuch asPCTE/OMS(Portable Common Tool Environment / Object Man-agement System). And embedding the support forre-doing design tasks into our prototype tool is alsofuture study.

[5] W. Pree. Design Patterns for Object-Ori ented SoftwareDevelopment. Addison-Wesley, 1995.[6] M . Saeki. Reusing Use Case Descriptions for Require-ments Specification: Towards Use Case Patterns. InProc. o 6th Asia Pacijic Software Engineering Confer-ence (AP SE C'99),pages 309- 316, 1999.[7] J . V il issides and et. al., editors. Pattern Languages ofPr igram Design I , 2, 3. Addison Wesley, 1995, 1995,1998.

ReferencesF. Buschmann, R. M eunier, H. Rohnert, P. Sommerlad,and M. Stal. Pattern-Oriented Software Architecture :A System o Patterns. Wiley, 1996.G. F lorij n, M. M eijers, and P. W insen.Tool Support forObject-Oriented Pattems. In Lecture Notes in ComputerScience (E COOP '97), volume 1241, pages 472- 495,1997.M. Fowler. Analysis Patterns :Reusable Object Mod-els. Addison-Wesley, 1997.E. Gamma, R. Helm, R. J ohnson, and J . Vlissides.Design Patterns :Elements of Reusable 00Software.Addison-Wesley, 1995.

109

object-oriented modeling of software patterns.pdf

Documents