Sudipto Ghosh

A UML-based pattern specification technique

Informally described design patterns are useful for communicating proven solutions for recurring design problems to developers, but they cannot be used as compliance points against which solutions that claim to conform to the patterns are checked. Pattern specification languages that utilize mathematical notation provide the needed formality, but often at the expense of usability. We present a rigorous and practical technique for specifying pattern solutions expressed in the unified modeling language (UML). The specification technique paves the way for the development of tools that support rigorous application of design patterns to UML design models. The technique has been used to create specifications of solutions for several popular design patterns. We illustrate the use of the technique by specifying observer and visitor pattern solutions.

Model-driven development using UML 2.0: promises and pitfalls

Experience indicates that effective complexity management mechanisms automate mundane development tasks and provide strong support for separation of concerns. For example, current high-level programming languages and integrated development environments provide abstractions that shield developers from intricate lower-level details and offer automated support for transforming abstract representations of source code into faithful machine-executable forms. The Object Management Group initiated the Unified Modeling Language 2.0 effort to address significant problems in earlier versions. While UML 2.0 improves over earlier versions in some aspects, its size and complexity can present a problem to users, tool developers, and OMG working groups charged with evolving the standard.

Aspect-oriented approach to early design modelling

Developers of modern software systems are often required to build software that addresses security, fault-tolerance and other dependability concerns. A decision to address a dependability concern in a particular manner can make it difficult or impossible to address other concerns in software. Proper attention to balancing key dependability and other concerns in the early phases of development can help developers better manage product risks through early identification and resolution of conflicts and undesirable emergent behaviours that arise as a result of interactions across behaviours that address different concerns. The authors describe an aspect-oriented modelling (AOM) approach that eases the task of exploring alternative ways of addressing concerns during software modelling. The paper focuses on use of the AOM approach to produce logical, aspect-oriented architecture models (AAMs) that describe how concerns are addressed in technology-independent terms. An AAM consists of a set of aspect models and a base architecture model called the primary model. An aspect model describes how a dependability concern is addressed, and a primary model describes how other concerns are addressed. Composition of the aspect and primary models in an AAM produces an integrated view of the logical architecture described by the AAM. Composition can reveal conflicts and undesirable emergent properties. Resolving these problems can involve developing and analysing alternative ways of addressing concerns. Localising the parts of an architecture that address pervasive and nonorthogonal dependability concerns in aspect models allows developers to more easily evolve and replace the parts as they explore alternative ways of balancing concerns in the early stages of development.

Directives for composing aspect-oriented design class models

An aspect-oriented design model consists of a set of aspect models and a primary model. Each aspect model describes a feature that crosscuts elements in the primary model. Aspect and primary models are composed to obtain an integrated design view. In this paper we describe a composition approach that utilizes a merging algorithm and composition directives. Composition directives are used when the default merging algorithm is known or expected to yield incorrect models. Our prototype tool supports default class diagram composition.

Test adequacy criteria for UML design models

Systematic design testing, in which executable models of behaviours are tested using inputs that exercise scenarios, can help reveal flaws in designs before they are implemented in code. In this paper a technique for testing executable forms of UML (Unified Modelling Language) models is described and test adequacy criteria based on UML model elements are proposed. The criteria can be used to define test objectives for UML designs. The UML design test criteria are based on the same premise underlying code test criteria: coverage of relevant building blocks of models is highly likely to uncover faults. The test adequacy criteria proposed in this paper are based on building blocks for UML class and interaction diagrams. Class diagram criteria are used to determine the object configurations on which tests are run, while interaction diagram criteria are used to determine the sequences of messages that should be tested. Copyright

A Generic Approach for Automatic Model Composition

Analyzing and modelling a software system with separate views is a good practice to deal with complexity and maintainability. When adopting such a modular approach for modelling, it is necessary to have the ability to automatically compose models to build a global view of the system. In this paper we propose a generic framework for composition that is independent from a modelling language. We define a process for adapting this framework to particular modelling language (defined with a metamodel) and illustrate how the generic composition has been specialized for class diagrams.

Barriers to systematic model transformation testing

Introduction Model Driven Engineering (MDE) techniques support extensive use of models in order to manage the increasing complexity of software systems. Appropriate abstractions of software system elements can ease reasoning and understanding and thus limit the risk of errors in large systems. Automatic model transformations play a critical role in MDE since they automate complex, tedious, error-prone, and recurrent software development tasks. Airbus uses automatic code synthesis from SCADE models to generate the code for embedded controllers in the Airbus A380. Commercial tools for model transformations exist. Objecteering and Together from Borland are tools that can automatically add design patterns in a UML class model. Esterel Technologies have a tool for automatic code synthesis for safety critical systems. Other examples of transformations are refinement of a design model by adding details pertaining to a particular target platform, refactoring a model by changing its structure to enhance design quality, or reverse engineering code to obtain an abstract model. These software development tasks are critical and thus the model transformations that automate them must be validated. A fault in a transformation can introduce a fault in the transformed model, which if undetected and not removed, can propagate to other models in successive development steps. As a fault propagates across transformations, it becomes more difficult to detect and isolate. Since model transformations are meant to be reused, faults present in them may result in many faulty models. Model transformations constitute a class of programs with unique characteristics that make testing them challenging. The complexity of input and output data, lack of model management tools, and the heterogeneity of transformation languages pose special problems to testers of transformations. In this paper we identify current model transformation characteristics that contribute to the difficulty of systematically testing transformations. We present promising solutions and propose possible ways to overcome these barriers.

Mining system tests to aid software maintenance

Maintainers can use information from test analysis tools to help them understand, debug, and retest programs. The authors describe techniques and tools in Bellcores /spl chi/Suds, a system for understanding and diagnosing software bugs, including Y2K problems in legacy applications.

Model Composition Directives

An aspect-oriented design model consists of a set of aspect models and a primary model. Each of these models consists of a number of different kinds of UML diagrams. The models must be composed to identify conflicts and analyze the system as a whole. We have developed a systematic approach for composing class diagrams in which a default composition procedure based on name matching can be customized by user-defined composition directives. This paper describes a set of composition directives that constrain how class diagrams are composed.

Providing Support for Model Composition in Metamodels

In aspect-oriented modeling (AOM), a design is described using a set of design views. It is sometimes necessary to compose the views to obtain an integrated view that can be analyzed by tools. Analysis can uncover conflicts and interactions that give rise to undesirable emergent behavior. Design models tend to have complex structures and thus manual model composition can be arduous and error- prone. Tools that automate significant parts of model composition are needed if AOM is to gain industrial acceptance. One way of providing automated support for composing models written in a particular language is to define model composition behavior in the metamodel defining the language. In this paper we show how this can be done by extending the UML metamodel with behavior describing symmetric, signature-based composition of UML model elements. We also describe an implementation of the metamodel that supports systematic composition of UML class models.