Modeling Systems Using Design Patterns

Transcription

1 Modeling Systems Using Design Patterns Jaroslav JAKUBÍK Slovak University of Technology Faculty of Informatics and Information Technologies Ilkovičova 3, Bratislava, Slovakia Abstract. The possibility of the re-use of the design patterns brings into patterns more than it might seem. We use design patterns in method named pure design patterns phase. In described method we seek to take advantage of design patterns composition for complex solution of closer problems. We modified standard software development process with use of special phase, which by using design patterns as elementary modeling unit purport to describe majority of solution. In this paper we describe basic notation for model in this phase. Based on example with patterns Composite and Iterator we define general relation between any two patterns. 1 Motivation Current phases of software development process are fairly delimitated and defined except for some experimental projects. To find the exact limits between phases is becoming harder and harder, however. After business processes were defined and requirements were concretized, there was a place for analysts and designers to create a model of reality. In this phase, there is a need for narrow communication about modeled problems between analysts and designers. Designers need to zoom in reality described in the analysis. Based on the analysis, the designers need to define the design model. It is very important to remove all communication differences between the analysts and the designers as well as those between designers themselves. We want to be able to create a communication bridge between analysts and designers to define a terminological glossary, basic modeling units etc. We create a model in which analysts can find their required functionality and which offers designers view the realization of the defined functionality. There are several resources Supervisor: doc. Ing. Jana Minárová, PhD., Institute of Informatics and Software Engineering, Faculty of Informatics and Information Technologies STU in Bratislava M. Bieliková (Ed.), IIT.SRC 2005, April 27, 2005, pp

2 152 Jaroslav Jakubík how to attain this bridge. In this method the concept of design patterns according to catalogue [1] is used. By the described method, we want to refine differences between the analysis and the design to quickly come to an agreement between the analysts and the designers concerning the design model. 2 Introduction to problem Analysts know what and designers know how. There is a need to join these two views together into one model where analysts can see which part of the system is able to provide a required functionality and designers can have an apparent method how this model can be transform into a design. For this context we use older concept of design patterns. In each catalogue of design patterns, a lot of patterns described with various UML diagrams, examples and recommendations of use can be found. We can process this additional information and get a list of functionality which using of each design pattern brings. From an analyst s point of view, we have design pattern functionalities. On the other side, from the point of view of a designer, we have a way to implement a current pattern, entire view of a design and an implementation of the application, a way in which an application will be expandable in future and a lot of information from many experts in the domain of object oriented software development. 3 Related works There exist a lot of theories about design patterns composition. The main idea of these theories is that pattern glue with another (or the same) pattern together solves largest scope of problems. Whereas majority of publication concentrate on composing design patterns on class level such as [6] and that argue by various mathematical theories, we want to look on composition of design patterns on view of their functionality. We enable analysts and designers to speak the same language, which lighten and simplify mutual understanding. Concept of modeling with pure design patterns was used in [7, 8]. Authors based on publication of Alexander [9] defined two ways of composing design patterns. Straight modeling was distributed to two phases. In the first phase Analysis analysts list all related patterns. In second phase high level design designers keep patterns selected by analytics to three models Pattern-Level Model, Pattern-Level with Interfaces and Detailed Pattern-Level model. In each model designer explore new details of pattern and application domain. The last model can be transformed directly to class diagram. This method is very similar like our approach but it is concerned on special group of patterns named constructional patterns. Authors in thesis don t define any relations between patterns. There are many notations of saving metainformation about design patterns in concrete design. There are two mainly ways of these notations. First way is to extend

3 Modeling Systems Using Design Patterns 153 UML with resource exactly to extend UML for example UML Collaboration Notation [3], Stereotype annotation [4], Tagged Pattern Annotation [2]. Second way is to define visualization of design pattern in class diagrams for example Venn Diagram-Style Pattern Annotation [5], Dotted Bounding Pattern Annotation [4], Pattern: Role Annotation [5]. Basic modeling units in all of these notations are class, method or attribute in dependence of concrete notation. For our using there are all notations too detailed and didn t defined relations and their notations on pattern level. 4 Pure design patterns phase We define phase of software development process which fall into analysis and into design too. We named this phase as pure design patterns phase. In this phase we will not speak about classes and relations between them but we will speak about design patterns and relations between patterns. We create model in which we used only design patterns. Analysts know functionality of each pattern so they can create list of patterns which cover required functionality. Designers, based on other view of analysis and personal know-how, can define other patterns which can be added to analysts patterns for covering other problems. We have got a group of patterns which cover part of required functionality. The bigger is part covered with patterns the fewer problems in next phase of design. We used skills of other experts for support or fully ensure required functionality. 4.1 Relations between design patterns In following progress of pure design patterns phase based on analysts and designers is a need to define relationships between patterns. In general we can separate relationships to two groups: 1. general relationships - include relations between any of patterns except special cases 2. concrete relationships - is assigned to a enumerated group of patterns, where each pattern has its own role in relation Now, for express relation between two patterns we used continuous line, which says nothing about concrete relation between patterns and neither about role of pattern (or class as a part of pattern) in relation. We can conceive pattern as a subsystem which insure defined and known functionality. With this generalization we have got model, which consist of group of patterns expressed with subsystems and elementary relations between patterns expressed with continuous line.

4 154 Jaroslav Jakubík Fig. 1: Model of simple graphics editor in pure design patterns phase Now we can say that based on this model we came near from analysis to design as far as to implementation. This model doesn t represent material for definitive transformation from model of pure design patterns to concrete design. General relations between design patterns can be interpreted in different concept. We don t want go in this way. When we created model in pure design patterns phase with sufficient metainformation it must be definitive transformation and interpretation of this model to class diagram. In comparison with elementary relationship there is a need to have concrete definition of relations between patterns. 4.2 Example of defining relation between patterns As example of defining relation between patterns we define general relation based on principle of defining design patterns. In this process of definition we came out of our experiences of using patterns Composite and Iterator. Based on example of concrete relation we attempt to define general relation. Class Composite in design pattern Composite must wrap services of Container such as getting and iterating through elements from composite. With continuous iterating through elements of composite can class Composite use Iterator pattern. Class Composite of pattern Composite is in role of Client in Iterator pattern. This relation on class level is render on figure 2. Fig. 2: Join of design patterns Composite and Iterator through Client class in Iterator pattern on class layer

5 Modeling Systems Using Design Patterns 155 We informally define concrete relation between Composite and Iterator pattern. We split generalization of this concrete relation to two phases. In first phase we generalize pattern Composite to pattern A, which uses services of container or iterating through elements of container. Pattern A is in role of Client in pattern Iterator. For example we use pattern Iterator with pattern Interpreter according to figure 3. Fig. 3: Join of design patterns Interpreter and Iterator through Client class in Iterator pattern on class layer Based on first generalization we know how to use any pattern with pattern Iterator (if it is necessary). The next step in process of generalization is to generalize pattern Iterator to pattern B. Now we can compose any patterns by role of client. For example, rendered in figure 4, class Leaf from Composite pattern can be client in Strategy pattern. Class Leaf from Composite pattern is in role of Client in Strategy pattern. Let s name this relationship as follows: pattern A with class A1 used pattern B. Fig. 4: Relationship pattern A with class A1 uses pattern B explained on pattern Composite with class Leaf uses pattern Strategy on class layer

6 156 Jaroslav Jakubík We have got whole definition of relation between two patterns, but how can we write information about relationship to pure design patterns model? We need notation for writing relation to model. What kind of information we need to know for transform defined relation to class diagram? In this occurrence answer is very simple. We need to know pattern A and pattern B, which are connected with relation, and class A1 which is in Client role of pattern B. The last problem of definition process is graphical formulation of defined relation. We use current notation of UML and pattern express as subsystems as we defined before. Fig. 5: Notation of relationship pattern A with class A1 uses pattern B We express relation pattern A with class A1 uses pattern B as a continuous line ended with arrow in pattern B. We must now reflect necessary metainformation in model. In this case it s only class A1. We inscribe class A1, which is Client in pattern B, above continuous line expressed relation near pattern A. Example of this notation is on figure Verification The suggested approach into the software development and modeling has not been verified in a commercial project, yet. This approach was used in two smaller experimental projects but in these cases, the exactly defined relationships were not used. We used patterns Iterator, Composite, Adapter, Strategy, Builder and Singleton to reach the required functionality. The phase of pure design patterns was used in the development of both systems. Our phase has brought former comprehension of the design problems by analysts and vice versa the comprehension of analytical requests by designers. The statement cannot be generalized about all projects but the phase of pure designed patterns seems to quicken the process of understanding the requests, reduce the communication gap between analysts and designers and facilitate the partial automation of transition from an analytical model into a designed one. This can happen mostly in case that the phase of pure designed patterns is exactly defined and it additionally includes other rules. 5 Future work This work brings a new view on the concept of the design patterns. However, this brings a lot of problems that have to be solved before the final use of this method in commercial projects. Firstly, a large variety of relationships among patterns is

7 Modeling Systems Using Design Patterns 157 necessary to be defined. The definition is requested to be eloquent and concrete enough mainly for the necessity of unambiguous transformation of the model of pure designed patterns into the class diagram. While defining the relationships, it is possible to follow the mentioned example. Secondly, a lot of relationships demand an exact and expandable definition of notation. Due to this definition, the essential data can be properly displayed or hidden in a particular moment. We are conscious of the fact that the defined method of the approach to the software development is only experimentally proved on few models and that the attempt to define this phase into the projects in progress and backwards creating the models of existing systems is essential. This approach to verification of our method seems to be the best alternative in confirming or refuting of the conclusions of the defined procedure. 6 Conclusion The proposed method tries to utilize as much as possible from the wide potential of patterns. Furthermore, at the basis of the requested functionality, a model is being created only by using designed patterns. This covers irrelevant details in the phase of analysis and an initial design and on the other side it displays the essential details for the transformation in the later design. In comparison with POAD method from [7] and [8] our method in using design patterns join both approaches in composing design patterns whether directly by gluing patterns together to stringing patterns or with use of new defined relationships for creating overloaded patterns. The main idea of our method is very similar like idea of POAD method. Both approaches have some equivalent phases like analysis, in which analysts define list of patterns to cover requested functionality, and phase of design refinement, which comes after transformation of pure design patterns model to class diagram. Our approach unlike POAD method defines only one model in difference of three models in POAD. Each refinement creating in models of POAD is substitute by using strictly defined relationships between patterns. The mentioned approach to the software development or transition from an analysis to a design based on the defined phase appears to be the appropriate alternative to the traditional approach. This issue is not being sufficient for the purposes of the real use. However, the missing relationships among patterns should be defined upon the work experience of either commercial or experimental projects. Acknowledgement: This work has been partially supported by the Grant Agency of Slovak Republic grant No. VG1/0162/03. References 1. Gamma, E. et al.: Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company, 1995, ISBN

8 158 Jaroslav Jakubík 2. Dong, J.: Representing the Applications and Compositions of Design Patterns in UML. In: Symposium on Applied Computing, 2003, pp Object Management Group: Unified Modeling Language Specification. Version 1.4, 2001, 4. Dong, J.: UML Extensions for Design Pattern Compositions. In: Journal of Object Technology, Vol. 1, No. 5 (2002), Vlissides, J.: Notation, Notation, Notation. In: C++ Report, Vol. 10 (April 1998), McC. Smith, J., Stotts, D.: Elemental Design Patterns: A Formal Semantics for Composition of OO Software Architecture. In: Software Engineering Workshop, Proceedings. 27 th Annual NASA Goodard/IEEE, pp Yacoub, S. M., Ammar, H. H.: Pattern-Oriented Analysis and Design (POAD): A Structural Composition Approach to Glue Design Patterns. In: Technology of Object-Oriented Languages and Systems, 2000, pp Yacoub, S. M., Ammar, H. H.: UML Support for Designing Software Systems as a Composition of Design Patterns. In: UML 2001 The Unified Modeling Language, Modeling Languages, Concepts, and Tools, 2001, pp Alexander, C. et al.: A pattern language. Towns, Buildings, Construction. Oxford University Press, New York, 1977, ISBN