Instantiating and detecting design patterns: putting bits and pieces together

Albin-Amiot, Hervé; Cointe, Pierre; Guéhéneuc, Yann‐Gaël; Jussien, Narendra

doi:10.1109/ase.2001.989802

Cited by 51 publications

(26 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…To limit or avoid this risk, some works help the use of the patterns. In particular, patterns were classified and described in several manners to help their selection [3] [4] [1] [5] [6] [7] [8] [9], for example, in classifying the patterns according to their intent or in formalizing the problem they solve. Another way is to check how a pattern can be well-integrated in an existing solution [10] [11] [12] [13] [14].…”

Section: Introductionmentioning

confidence: 99%

Sharing bad practices in design to improve the use of patterns

Bouhours

Leblanc

Percebois

2010

Proceedings of the 17th Conference on Pattern Languages of Programs

View full text Add to dashboard Cite

In order to guarantee the use of good analysis and design practices and an easier maintenance of software, analysts and designers may use patterns. To help them, we propose models inspection in order to detect instantiations of "spoiled pattern" and models reworking through the use of the design patterns. As a design pattern allows the instantiation of the best known solution for a given problem, a "spoiled pattern" allows the instantiation of alternative solutions for the same problem: requirements are respected, but architecture is improvable. We have collected a set of alternative solutions and deduced the corresponding spoiled patterns. We have defined a first catalog of these improvable practices from several experiments with students. To overcome the limits imposed by this method (restricted public, limited problems and tiresome validation process), we would like open this problematic to the expert community. To achieve this, we propose a collaborative website sharing bad practices in object oriented design to improve the use of patterns.

show abstract

Section: Introductionmentioning

confidence: 99%

Sharing bad practices in design to improve the use of patterns

Bouhours

Leblanc

Percebois

2010

Proceedings of the 17th Conference on Pattern Languages of Programs

View full text Add to dashboard Cite

show abstract

“…The patterns community catalogs useful design fragments and the context that guides their use. Approaches to formalizing patterns address pattern detection on source code [49] or supporting the work with patterns in integrated development environments [50] [51]. Our work intends to formalize variability analysis on the architectural level.…”

Section: Formalization Of Architectural Styles and Design Patternsmentioning

confidence: 99%

Formalization of Federated Schema Architectural Style Variability

Hasselbring¹

2015

JSEA

View full text Add to dashboard Cite

Data integration requires managing heterogeneous schema information. A federated database system integrates heterogeneous, autonomous database systems on the schema level, whereby both local applications and global applications accessing multiple component database systems are supported. Such a federated database system is a complex system of systems which requires a well-designed organization at the system and software architecture level. A specific challenge that federated database systems face is the organization of schemas into a schema architecture. This paper provides a detailed, formal investigation of variability in the family of schema architectures, which are central components in the architecture of federated database systems. It is shown how the variability of specific architectures can be compared to the reference architecture and to each other. To achieve this, we combine the semi-formal object-oriented modeling language UML with the formal object-oriented specification language Object-Z. Appropriate use of inheritance in the formal specification, as enabled by Object-Z, greatly supports specifying and analyzing the variability among the studied schema architectures. The investigation also serves to illustrate the employed specification techniques for analyzing and comparing software architecture specifications.

show abstract

“…PatternsBox [AACGJ01] provides a way of instantiating design patterns. It uses a library of design patterns and a set of requirements; for example, a composite pattern can be created by instantiating a new Composite() and subsequent operations could be added to it dynamically.…”

Section: Pattern Specificationmentioning

confidence: 99%

“…Other works have focussed on introducing design patterns into existing applications [OC00, AACGJ01,Tok99] and there may well be crossover between HEDGEHOG's approach and some of the other existing approaches for introduction of design patterns.…”

Section: Automated Introduction Of Design Patternsmentioning

confidence: 99%

Automatic verification of design patterns in Java

Blewitt

Bundy

Stark

2005

Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering

View full text Add to dashboard Cite

Design patterns are widely used by designers and developers for building complex systems in object-oriented programming languages such as Java. However, systems evolve over time, increasing the chance that the pattern in its original form will be broken.To verify that a design pattern has not been broken involves specifying the original intent of the design pattern. Whilst informal descriptions of patterns exist, no formal specifications are available due to differences in implementations between programming languages. This thesis shows that many patterns (implemented in Java) can be verified automatically.Patterns are defined in terms of variants, mini-patterns, and artefacts in a pattern description language called SPINE. These specifications are then processed by HEDGEHOG, an automated proof tool that attempts to prove that Java source code meets these specifications.iii

show abstract

Instantiating and detecting design patterns: putting bits and pieces together

Cited by 51 publications

References 4 publications

Sharing bad practices in design to improve the use of patterns

Sharing bad practices in design to improve the use of patterns

Formalization of Federated Schema Architectural Style Variability

Automatic verification of design patterns in Java

Contact Info

Product

Resources

About