We present a visual formalism for the specification of object -oriented design and architectures . LePUS diagrams effectively capture and convey a concise description of design patterns. LePUS diagrams also offer lucid "roadmaps " ("architectural schemata") for elaborated libraries and frameworks, and make a documentation tool that is more powerful, concise, and comprehensive than existing techniques. We demonstrate the formalism's merit in representing the Observer design pattern, as well as manifesting idioms in Enterprise JavaBeans^TM and Java^TM Swing.

Software engineering aims at techniques for producing better software products with less resources. A central concept for achieving this goal is a product line architecture. Frameworks are a popular object-oriented way to implement product line architectures. However, frameworks are often difficult to learn and their specializations consist of small and crosscutting logical entities that overlap with other design solutions of the software product. Implementation becomes fragmented, difficult to trace, and the original reasoning of the design is easily forgotten. Thus, the essential problems to be solved are the following: • How to teach the software developer to understand different frameworks and design principles in the context of her software product? • How to guide the software developer to use frameworks and product line architectures? • How to maintain and document implemented design solutions and framework specializations? In this

This document formally defines the elements in the syntax and the semantics of LePUS3 and the Class-Z specification languages. It was designed to satisfy the rigid requirements of mathematical logic, and it is therefore unsuitable for learning LePUS3 and Class-Z. To learn LePUS3 and Class-Z please see the Tutorial. To learn about the background and motivation see the About page. A legend offering a key to the language's symbols is also available.

Abstract—In order to characterize and improve software architecture visualization practice, the paper derives and constructs a qualitative framework, with seven key areas and 31 features, for the assessment of software architecture visualization tools. The framework is derived by the application of the Goal Question Metric paradigm to information obtained from a literature survey and addresses a number of stakeholder issues. The evaluation is performed from multiple stakeholder perspectives and in various architectural contexts. Stakeholders can apply the framework to determine if a particular software architecture visualization tool is appropriate to a given task. The framework is applied in the evaluation of a collection of six software architecture visualization tools. The framework may also be used as a design template for a comprehensive software architecture visualization tool. Index Terms—Software architecture, visualization, visualization methodologies, visualization assessment. Ç

Abstract. We distinguish three abstraction strata in software design statements: (i) Strategic design statements (‘architectural design’) determine global constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities. (ii) Tactical design statements (‘detailed design’) determine local constraints, such as design patterns, programming idioms, and refactorings. (iii) Implementation statements determine specific properties of the implementation, such as class diagrams and program documentation. Seeking to ground the distinction between Strategic, Tactical, and Implementation statements in a well-defined vocabulary, we define criteria of distinction in mathematical logic. We present the Intension/Locality Hypothesis, postulating that the spectrum of software design statements is divided into three well-defined ‘abstraction classes ’ as follows: (i) The class of non-local statements (a_) contains Strategic statements; (ii) The class of local and intensional statements (_\) contains Tactical statements; (iii) The class of ‘local and extensional ’ statements (_X) contains Implementation

Abstract. Design patterns are traditionally outlined in an informal manner. If they could be formalised, we could derive tools that automatically recognise design patterns and refactor designs and code accordingly. The approach we use is to deploy predicate logic to specify conditions on the class diagrams with which the design patterns are commonly described. This not only enables us to recognise design patterns, but also to reason about design patterns, so we can detect when one pattern is a special case of another. The paper reports our specification of the original 23 design patterns.

Design patterns are used extensively in the design of software systems. Patterns codify effective solutions for recurring design problems and allow software engineers to reuse these solutions, tailoring them appropriately to their particular applications, rather than reinventing them from scratch. In this paper, we consider the following question: How can system designers and implementers test whether their systems, as implemented, are faithful to the requirements of the patterns used in their design? A key consideration underlying our work is that the testing approach should enable us, in testing whether a particular pattern P has been correctly implemented in different systems designed using P, to reuse the common parts of this effort rather than having to do it from scratch for each system. Thus in the approach we present, corresponding to each pattern P, there is a set of pattern test case templates (PTCTs). A PTCT codifies a reusable test case structure designed to identify defects associated with applications of P in all systems designed using P. Next we present a process using which, given a system designed using P, the system tester can generate a test suite from the PTCTs for P that can be used to test the particular system for bugs in the implementation of P in that system. This allows the tester to tailor the PTCTs for P to the needs

Abstract Model-Driven Development (MDD) is an emergent approach to software engineering which is based on the systematic use of software modeling as a primary form of expression. The central focus in MDD is on models, as opposed to source code in the traditional conception of software development. However the introduction of models in the software life cycle poses new issues and challenges that current state-of-the-art development tools do not support adequately. In this paper we investigate some of these challenges, taking into account the role played by models. Then we propose a unified framework which integrates different verification methods with the intent to check (UML) models against consistency issues and design defects. Our approach aims to integrate traditional techniques with model-based ones, keeping the advantages of both static and dynamic verification methods in order to increase the proficiency of the MDD activities. Model-Driven Development (MDD) is an emergent approach to software engineering which is based on the systematic use of software modeling as a primary form of expression. The central focus in MDD is on models, as opposed to source code in the traditional conception of software development. However the introduction of models in the software life cycle poses new issues and challenges that current state-of-the-art development tools do not support adequately. In this paper we discuss some of these challenges and how the practice of MDD affects software development tools. We start analyzing the role of models, that are a better medium than source code to express abstractions, which are the fundamental element of the software engineering practice [14,24]. Then we proceed addressing other issues concerned with models, the traditional activities of design, validation and verification (V&V). Taking into account these challenges allow us to identify the key features for developing a unified framework suitable to tailor the development process in the context of model-driven development environments, with particular attention to UML models.

. Rather than describing a specific implementation, Perry and Wolf [1] have established that architectural specifications set forth abstract constraints that need be met, thereby specifying a set of programs indirectly by means of desired properties (also intentional specifications.) The appropriate level of abstraction may vary, but specifications must not include details that unnecessarily constrain the design and implementation processes that follow. D. Concise. Various function and object calculi and extensions thereof, such as ?-calculus, F <: , and Ob <: [5], provide a rigorous system for assigning a well-defined interpretation to predefined subsets of certain programming languages. Despite their contribution, these formalisms suffer from one glaring flaw: Their verbosity. Often, a few lines of source code translate into three pages of dense mathematical symbols, thereby defying the very attempt at achieving insights into the program. To preserve clarity and manageability, we co...

Rapport sur l’implémentation des micro patterns sous Ptidej