INTERNATIONAL JOURNAL OF COMPUTERS Issue 3, Volume 2, 2008 A Fundamental Modeling Concept Approach for Modeling UML Design Patterns A. Spiteri Staines structural. Abstract— Traditionally software design patterns were Behavioral Design Patterns describe behavior. Some developed to create software artifacts efficiently and effectively. behavioral patterns are i) chain of responsibility, ii) command, Patterns are represented using UML notations and formal models. iii) interpreter, iv) iterator, v) visitor, etc. Unfortunately these do not always suffice to analyze behavior. There Creational design patterns focus on using abstract classes are various problems related to visualization, abstracting, mapping the design to the implementation, etc. Various approaches have been to create objects that are managed independently from the tried out. Most methods are too complex and do not offer proper originator requesting their use. Some common creational visualization. This paper promotes the use of Fundamental Modeling design patterns are i) abstract factory, ii) builder, iii) prototype Concepts to support design patterns. These offer better visualization and iv) singleton. and simplicity over the mainstream approaches. Some examples are Structural design patterns focus on the interaction structure presented. from the system point of view. These patterns describe the components of a system. Some structural design patterns are i) Keywords—Design Patterns, Fundamental Modeling Concepts, adapter, ii) bridge , iii) composite, iv) proxy, etc. Software Engineering, UML. Some findings about design patterns and the UML are presented below: I. INTRODUCTION UML patterns are implemented as packages OFTWARE design patterns are standard solutions to Patterns can be composed of several classes recurring problems over different application domains S Patterns should exist at a higher level of [18]. Software patterns are defined as reusable micro abstraction than the actual class architectures. Unfortunately they are not pluggable solutions Patterns should be independent of implementation, in most cases. Users might be using these patterns without technologies and programming languages knowing it. The patterns presented in [8]–[15] explain how to In the mindset of the software engineer thinking in resolve software design problems from both the i) system and terms of ‘patterns’ simplifies the solution to a ii) programming point of view. Design patterns attempt to particular problem implement efficient and effective inexpensive solutions. They Conceptual thinking is a different way of obviate the need to re-invent a solution. A well defined design abstracting a problem where patterns can be used. pattern should be implemented regardless of the software platform used. Thinking in terms of patterns simplifies III. FINE VS COARSE GRANULARITY problem solving. Patterns can communicate knowledge and architectural design between different users. Knowledge can Fine granularity describes a system in detail, very close to be stored as a pattern in one’s mind without knowing it. This the actual implementation. Conversely coarse granularity requires that patterns are easily visualized and specified. depicts a system at a higher level of abstraction. Depending on the application being developed, different levels of granularity can be considered. E.g. for a simple application with no more II. DESIGN PATTERNS AND UML than five classes a fine grain approach is suitable. On the other The UML is the de facto standard used to describe recurrent hand for complex applications exhibiting different types of design patterns for various reasons [8],[12]-[13]. UML behavior, a coarse grained approach is preferred. diagrams are based on visual notations. There exist different These patterns also describe complex system interaction. classes of design patterns E.g. GOF, POF, observer, adaptor, Patterns can explain packages, clusters etc. [8]. Design etc. Design patterns can be classified into three subcategories Patterns can be linked to coarse granularity. A ‘class’ might [10],[14]-[15]. These are a) behavioral b) creational and c) actually be too small to model complex behavior. The UML is well suited to describing fine granularity, because it actually Manuscript received March 28, 2008; Revised version received Aug. 19, 2008 represents the implementation. Design Patterns abstracted at a A. Spiteri Staines is with the Department of Computer Information high level require a different treatment. Systems, Faculty of ICT, University of Malta, Msida, MSD 2080, Malta, Europe. phone: 00356-21373402; fax: 21312110; (e-mail: [email protected], [email protected]) 231 INTERNATIONAL JOURNAL OF COMPUTERS Issue 3, Volume 2, 2008 IV. ISSUES AND PROBLEMS presented. Although this is a valid approach it can become Development of information systems for large quite complex for large systems. organizations is a complex task. It is not easy to visualize the Design patterns from the Gof can be formalized in the B complete information system complete with functionality. language [9]. Other valid approaches are using UML-B. These Systems are composed of several viewpoints. The application are more suited for formal verification than visualization. In domain influences these views. Most system stakeholders are [10] a better solution is proposed where Le PUS3 / Class-Z non technical persons. It is possible to create business models are combined to model design patterns. Interesting diagrams that will be used to develop a system model. Well defined which are easily readable are presented but these are still too design patterns can support both system and software close to the implementation, hence a fine grained approach. modeling. Design patterns are again formalized in [11] using the To encourage the use of design patterns these should be Disco approach considering the subject vs observer well understood. Understanding system functionality implies viewpoints. that: i) the problem statement and ii) the solution are separate Visual notations help to reduce ambiguity that might be issues. Different approaches have been formulated to present in formal approaches. In [17] extensions to the UML represent design patterns. These are i) formal models [8]-[11], using a profile are suggested to visualize design patterns. This ii) visual notations. Formal models encompass logic-based is a valid solution. The FMC notations [1] presented in this languages and specification languages e.g. DPML. Formal paper strive to offer simpler solutions. FMC notations have notations are not comprehended by many stakeholders. been used in industry. Some of the techniques discussed above Consequently they are unsuitable for visualization and any can be used in conjunction with FMC notations. small change requires re-specification. Visual notations are found in the UML and other methods supporting natural VI. A FUNDAMENTAL MODELING CONCEPT SOLUTION languages. Most approaches do not properly show separate A possible solution to these issues is to use Fundamental pattern behavior from its static representation like in a class Modeling Concepts (FMC) developed at Hasso-Plattner- diagram. Institute Potsdam and presented in [1]-[7]. FMC and FMC- Some problems with pattern representation are :i) the UML visualization guidelines are useful to create more focuses on communication at a class level not pattern level, ii) comprehensible and constructible models. FMC are composed patterns can preserve hidden properties, iii) reverse of three main notations: i) Compositional Structures, ii) engineering might be impossible, iv) UML does not clearly Dynamic Structures and iii) Value Range Structures. The specify how to represent these patterns, lacking precise UML design patterns can be represented as compositional semantics, v) binding the pattern to the actual structures. The compositional structures are supported using software/hardware implementation is difficult to achieve [8]. dynamic structures which are place transition Petri nets. These The UML has a set of notations for specifying both the i) diagrams focus on system structures rather than software Static Composition and ii) Dynamic behavior of systems. structures making them suitable to describe ‘a larger granule The UML has a variety of notations for describing of organization’. Recurring patterns can be easily identified. similar system activities. This creates a dilemma as which to In literature it seems that FMC are well suited to model select. Consistency between different notations normally conceptual patterns [1],[4]. Design patterns can also be involves a lot of work, rework and resolution of structural modeled. clashes. The FMC dynamic structures clearly identify and capture Notwithstanding these problems, the UML still remains the behavior of the design pattern. FMC notations have valid as the starting point for describing system behavior. evolved over a number of years. The diagram notations like the dynamic structures are based on place transition Petri nets V. RELATED WORK that have over three decades of coverage and vast literature. Most of the work for design patterns is based on UML FMC diagrams are more practical to use when describing notations. In most cases the UML is insufficient to represent systems at a high level. They support communication between the semantic expression of a design [19]. To solve this technical people and system stakeholders for different system problem different methods are proposed. requirements. FMC are based on important