Formal Specification Of Design Patterns: A Comparison Of Three Existing Approaches And Proposing Two-Level Grammars As A New Approach

Patterns are Object-Oriented reusable units. The principal idea behind patterns is to capture and reuse the abstractions that have been formed by expert programmers and designers to solve problems that occur in particular contexts. These abstractions capture the valuable experiences of experts in solving problems. Although patterns are currently being used successfully, there is no general agreement among the software community as to how patterns should be formalized or represented. Various formal specification schemes have been proposed to complement the natural language description of patterns in order to alleviate the ambiguities inherent in the natural language description by rigorously reasoning about the structural and behavioral aspects of patterns. Existing formal specification languages of design patterns have generally failed to provide a standard definition, specification, or representation for patterns because there is no general agreement as to how patterns should be formalized. Also, each formal specification is generally based on a different mathematical formalism and when pattern users want to understand a pattern, first they have to understand the respective mathematical formalism. In addition to comparing three existing formal specification schemes, the main objective of this research work was to lay the foundation for developing a formal specification scheme that could be understandable without having to delve into the details of the underlying formalism. This research work attempted to capture and represent the structural aspects of design patterns since capturing the behavioral aspects of design patterns is a semantic issue and is beyond the scope of this work. Two-Level Grammar (TLG) was used to capture and represent the structural aspects of design patterns. This study was conducted using the GoF design patterns [Gamma et al. 1995]. It has already been demonstrated that TLGs have the capability to represent the building blocks of object-oriented software systems. The primary advantage of TLGs in defining design patterns is that specifications written in TLGs are understandable due to their natural-language-like vocabulary [Edupuganty 1987] [Lee 2003] [Maluszynski 1984]. The TLG representation of the observer pattern was developed to gauge the feasibility of the proposed pattern representation scheme. TLGs could help pattern users understand the formalized version of patterns more readily compared to other formal specification methods that are difficult to understand due to their arcane mathematical notations.Computer Science Departmen

Développement logiciel par transformation de modèles

La recherche en génie logiciel a depuis longtemps tenté de mieux comprendre le processus de développement logiciel, minimalement, pour en reproduire les bonnes pratiques, et idéalement, pour pouvoir le mécaniser. On peut identifier deux approches majeures pour caractériser le processus. La première approche, dite transformationnelle, perçoit le processus comme une séquence de transformations préservant certaines propriétés des données à l’entrée. Cette idée a été récemment reprise par l’architecture dirigée par les modèles de l’OMG. La deuxième approche consiste à répertorier et à codifier des solutions éprouvées à des problèmes récurrents. Les recherches sur les styles architecturaux, les patrons de conception, ou les cadres d’applications s’inscrivent dans cette approche. Notre travail de recherche reconnaît la complémentarité des deux approches, notamment pour l’étape de conception: dans le cadre du développement dirigé par les modèles, nous percevons l’étape de conception comme l’application de patrons de solutions aux modèles reçus en entrée. Il est coutume de définir l’étape de conception en termes de conception architecturale, et conception détaillée. La conception architecturale se préoccupe d’organiser un logiciel en composants répondant à un ensemble d’exigences non-fonctionnelles, alors que la conception détaillée se préoccupe, en quelque sorte, du contenu de ces composants. La conception architecturale s’appuie sur des styles architecturaux qui sont des principes d’organisation permettant d’optimiser certaines qualités, alors que la conception détaillée s’appuie sur des patrons de conception pour attribuer les responsabilités aux classes. Les styles architecturaux et les patrons de conception sont des artefacts qui codifient des solutions éprouvées à des problèmes récurrents de conception. Alors que ces artefacts sont bien documentés, la décision de les appliquer reste essentiellement manuelle. De plus, les outils proposés n’offrent pas un support adéquat pour les appliquer à des modèles existants. Dans cette thèse, nous nous attaquons à la conception détaillée, et plus particulièrement, à la transformation de modèles par application de patrons de conception, en partie parce que les patrons de conception sont moins complexes, et en partie parce que l’implémentation des styles architecturaux passe souvent par les patrons de conception. Ainsi, nous proposons une approche pour représenter et appliquer les patrons de conception. Notre approche se base sur la représentation explicite des problèmes résolus par ces patrons. En effet, la représentation explicite du problème résolu par un patron permet : (1) de mieux comprendre le patron, (2) de reconnaître l’opportunité d’appliquer le patron en détectant une instance de la représentation du problème dans les modèles du système considéré, et (3) d’automatiser l’application du patron en la représentant, de façon déclarative, par une transformation d’une instance du problème en une instance de la solution. Pour vérifier et valider notre approche, nous l’avons utilisée pour représenter et appliquer différents patrons de conception et nous avons effectué des tests pratiques sur des modèles générés à partir de logiciels libres.Software engineering researchers have long tried to understand the software process development to mechanize it or at least to codify its good practices. We identify two major approaches to characterize the process. The first approach—known as transformational—sees the process as a sequence of property-preserving transformations. This idea was recently adopted by the OMG’s model-driven architecture (MDA). The second approach consists in identifying and codifying proven solutions to recurring problems. Research on architectural styles, frameworks and design patterns are part of this approach. Our research recognizes the complementarity of these two approaches, in particular in the design step. Indeed within the model-driven development context, we view software design as the process of applying codified solution patterns to input models. Software design is typically defined in terms of architectural design and detailed design. Architectural design aims at organizing the software in modules or components that meet a set of non-functional requirements while detailed design is—in some way—concerned by the contents of the identified components. Architectural design relies on architectural styles which are principles of organization to optimize certain quality requirements, whereas detailed design relies on design patterns to assign responsibilities to classes. Both architectural styles and design patterns are design artifacts that encode proven solutions to recurring design problems. While these design artifacts are documented, the decision to apply them remains essentially manual. Besides, once a decision has been made to use a design artifact, there is no adequate support to apply it to existing models. As design patterns present an ‘‘easier’’ problem to solve, and because architectural styles implementation relies on design patterns, our strategy for addressing these issues was to try to solve the problem for design patterns first, and then tackle architectural styles. Hence, in this thesis, we propose an approach for representing and applying design patterns. Our approach is based on an explicit representation of the problems solved by design patterns. Indeed, and explicit representation of the problem solved by a pattern enables to: 1) better understand the pattern, 2) recognize the opportunity of applying the pattern by matching the representation of the problem against the models of the considered system, and 3) specify declaratively the application of the pattern as a transformation of an instance of the problem into an instance of the solution. To verify and validate the proposed approach, we used it to represent and apply several design patterns. We also conducted practical tests on models generated from open source systems