Design patterns are a standard means to create large software systems. However, with standard object-oriented techniques, typical implementations of such patterns are not themselves reusable software entities. Evolution of a program into a ‘patterned ’ form (also known as ‘refactoring to patterns’) and subsequent evolution of a ‘patterned ’ design is largely left to the programmer. Due to their ability to encapsulate elements that crosscut different modules, aspect languages have the potential to change this situation. For many interesting patterns, a large part of the process of refactoring to patterns can already be implemented modularly in aspects. Still, existing aspect languages can only express a small number of typical patterns implementations in a generally reusable way. In many cases, evolution of an application that uses one pattern variant into one that uses another one cannot be achieved at all. In others, it requires duplicating parts of the aspect implementation, thus creating scattered code in the aspects and hindering their further evolution. In this paper, we argue that aspect languages need to provide genericity in order to support reusable pattern implementations. We sketch the main features of the generic aspect language LogicAJ, and show how it supports software evolution. In particular, we demonstrate how LogicAJ enables evolution of a non-patterned implementation to a patterned one and easy transition from one patterned implementation to another. 1.

Software pattern designers and users have few resources available to support pattern-based development practices. Patterns are currently disseminated in disjoint collections in various publishing mediums with little or no technology support. As the number of patterns and diversity of pattern types continue to proliferate, pattern users and developers are faced with difficulties of understanding what patterns already exist and when, where, and how to use or reference them properly. This defeats the very purpose of patterns as a medium to encapsulate and disseminate recurring design experiences. In this paper, an initial study is done among a set of pattern collections is performed to better understand the difficulties related to improve pattern-based support for support software development activities. Based on the empirical survey, challenges are identified that define impediments to the federation of software patterns into an interconnected body of knowledge. A Semantic Web ontology is presented as an initial attempt at solving some of these issues through the use of Web-based ontologies. 1. Software Patterns in Practice Software patterns encapsulate proven solutions extracted from the experiences of software

ABSTRACT. Design patterns have greatly helped spreading a limited number of well-tried solutions to recurring object-oriented problems. But as new patterns are introduced at a steady rate, the concept must evolve so that tools can help programmers not to be lost, facing a host of patterns. In this paper, we propose that design patterns be systematically analyzed and reformulated to exhibit a reasoning binding solutions to precisely stated problems, given a set of mechanisms. We show on some creational patterns how these mechanisms can be described as program transformations and how an assistant tool could systematically explore the set of potential solutions induced by these transformations. This would both help the selection and the instantiation of the appropriate patterns. NOTE. — This paper is an improved and at least twice longer version of [ZIA 00]. RÉSUMÉ. Les modèles de conception ont largement participé à la diffusion de solutions éprouvées à des problèmes récurrents de conception et de programmation à objets. Pourtant le concept doit à présent évoluer pour que les programmeurs puissent gérer le nombre croissant de ces modèles. Dans ce papier nous proposons que les modèles de conception soient systématiquement analysés et reformulés pour exhiber un raisonnement liant les solutions à des problèmes décrit précisément, étant donné un ensemble de mécanismes. Nous montrons sur certains modèles créateurs comment ces mécanismes peuvent être décrits comme des transformations de programmes et comment un outil d'assistance pourrait systématiquement explorer l'ensemble des solutions possibles induit par ces transformations. Ceci faciliterait la sélection mais aussi l'instanciation des modèles appropriés.

Java Reflection in Action is unique in presenting a clear account of all the cool things you can do with reflection, and at the same time providing the sound conceptual basis that developers need to create advanced applications. The book includes careful explanations of sometimes perplexing programming techniques along with enough background to understand how to extend and vary them. This book overcomes reflection’s reputation as a mysterious and esoteric philosophical pursuit, or as a set of messy error-prone coding tricks. As reflection becomes increasingly common and useful in all sorts of applications, it is great to finally have a book that features disciplined yet still creative and fun software engineering practices based on reflection. Even occasional users will immediately adopt the book’s patterns and idioms to solve common problems. Many of the examples can be directly adapted for customized solutions in diverse areas such as XML processing, automated software testing, and program analysis tools. Readers will also find underlying rationales for code performing introspection, proxies, class loading, and so on, that are often seen but not often explained well in everyday Java programs. And even experts will find new ideas and well-thought out advice for using some of the more subtle aspects of reflection. —Prof. Doug Lea, SUNY Oswego, author of Concurrent Programming in Java Java has brought reflection to the programming masses, but they're still struggling with it. The Formans turn struggle into adventure as they guide you through one compelling example after another, each one illustrating reflection’s power while avoiding its pitfalls.

The design and development of real-time software (i.e. software that must ensure timeliness while interacting with an external environment) is more difficult than for most other software. Modeling tools help deal with this complexity, allowing developers to view the system at various levels of abstraction, animate the models in a simulation environment, and even generate the code for a variety of target hardware/RTOS configurations. A natural extension to these tools is to provide support for design patterns (a method of documenting experience in the form of problem/context/solution triples for recurring problems). Such an extension provides yet another layer of abstraction to the models, and makes explicit the application of design patterns.

Abstract not found

Abstract not found

A lot of activity is currently going on to replace the SNMP management architecture with a solution better suited to managing modern IP networks and systems. New candidates include Management by Delegation, active networks, and Web-based management. In this exercise, the management community runs the risk of throwing the baby out with the bath water by focusing too much on a few well-known problems exhibited by SNMP (e.g., its poor scalability) and neglecting most of its other characteristics, including those that contributed to its success (e.g., the reasons why it is simple). One way to avoid this is to explicitly capture the experience gained in the management of IP networks and systems with SNMP. In this paper, we make one step in this direction by studying the SNMP management architecture through a software engineer's eyes: we identify in SNMP some of the fundamental architectural and design patterns defined in the literature. Patterns are schematic, proven solutions to recurring problems. By characterizing the current management architecture in terms of patterns, we help retain the strengths of SNMP-based management in future management architectures. We also make it easier for new software engineers to move to network and systems management by characterizing this application domain in standard pattern terms, as opposed to using the jargon understood solely by the SNMP community.

ed by its subtypes, and that you should be able to substitute subtype objects for supertype objects without affecting client code. If those properties hold, you avoid the wrath of Liskov. Good thing, too, because there may be splendid reasons to declare child-oriented operations in the Component interface. In the context of COMPOSITE, the primary reason is to achieve a key aspect of the pattern's intent---uniformity. Pattern Hatching Java Report September 2001 Here again is the full Intent statement as doctored up last time: Assemble objects into tree structures. COMPOSITE simplifies clients by letting them treat individual objects and assemblies of objects uniformly. The trouble with barring child-related operations from the Component interface is that it defeats the very uniformity we seek. So why would one want to do it? Apart from blind obedience to LSP, the most common pretext is static type safety, or at least the hope of it. To wit, if appears in Composite interfaces

Extensibility and maintainability of software becomes more an issue as the complexity of the software development process rises. Design patterns in the sense of [3] aid in reducing the problem of architectural decay. However, new publications steadily increase the number of documented patterns. This makes the automated and toolsupported processing of design patterns more important as well as supporting the learning process for the understanding of concrete patterns. Here, the definition of pattern templates receives prominent relevance. This paper supports the definition of pattern templates by distinguishing several types of corresponding pattern and source code elements. Considering semantic elements and corresponding annotations allows for explicitly declaring the sense/intention and the meaning of pattern and program parts. This leads to the possibility of toolsupported selection of applicable patterns and assists in their application and detection.