Geri Georg

UML2Alloy: a challenging model transformation

Alloy is a formal language, which has been applied to modelling of systems in a wide range of application domains. It is supported by Alloy Analyzer, a tool, which allows fully automated analysis. As a result, creating Alloy code from a UML model provides the opportunity to exploit analysis capabilities of the Alloy Analyzer to discover possible design flaws at early stages of the software development. Our research makes use of model based techniques for the automated transformation of UML class diagrams with OCL constraints to Alloy code. The paper demonstrates challenging aspects of the model transformation, which originate in fundamental differences between UML and Alloy. We shall discuss some of the differences and illustrate their implications on the model transformation process. The presented approach is explained via an example of a secure e-business system.

On challenges of model transformation from UML to Alloy

The Unified Modeling Language (UML) is the de facto language used in the industry for software specifications. Once an application has been specified, Model Driven Architecture (MDA) techniques can be applied to generate code from such specifications. Since implementing a system based on a faulty design requires additional cost and effort, it is important to analyse the UML models at earlier stages of the software development lifecycle. This paper focuses on utilizing MDA techniques to deal with the analysis of UML models and identify design faults within a specification. Specifically, we show how UML models can be automatically transformed into Alloy which, in turn, can be automatically analysed by the Alloy Analyzer. The proposed approach relies on MDA techniques to transform UML models to Alloy. This paper reports on the challenges of the model transformation from UML class diagrams and OCL to Alloy. Those issues are caused by fundamental differences in the design philosophy of UML and Alloy. To facilitate better the representation of Alloy concepts in the UML, the paper draws on the lessons learnt and presents a UML profile for Alloy.

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.

Using aspects to design a secure system

Developers of complex systems have to address concerns such as security, availability of services, and timeliness that often are non-orthogonal to traditional design structures, that is, the concerns cross-cut traditional design units. We illustrate how an aspect-oriented approach to modeling allows developers to encapsulate such design concerns so that they can be woven into a design in a systematic and consistent manner. The paper focuses on the use of aspects for modeling and weaving in security concerns.

An aspect-based approach to modeling access control concerns

Specifying, enforcing and evolving access control policies is essential to prevent security breaches and unavailability of resources. These access control design concerns impose requirements that allow only authorized users to access protected computer-based resources. Addressing these concerns in a design results in the spreading of access control functionality across several design modules. The pervasive nature of access control functionality makes it difficult to evolve, analyze, and enforce access control policies. To tackle this problem, we propose using an aspect-oriented modeling(AOM) approach for addressing access control concerns. In the AOM approach, functionality that addresses a pervasive access control concern is localized in an aspect. Other functional design concerns are addressed in a model of the application referred to as a primary model. Composing access control aspects with a primary model results in an application model that addresses access control concerns. We illustrate our approach using a form of Role-Based Access Control. q 2003 Elsevier B.V. All rights reserved.

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.

An aspect-oriented methodology for designing secure applications

We propose a methodology, based on aspect-oriented modeling (AOM), for incorporating security mechanisms in an application. The functionality of the application is described using the primary model and the attacks are specified using aspects. The attack aspect is composed with the primary model to obtain the misuse model. The misuse model describes how much the application can be compromised. If the results are unacceptable, then some security mechanism must be incorporated into the application. The security mechanism, modeled as security aspect, is composed with the primary model to obtain the security-treated model. The security-treated model is analyzed to give assurance that it is resilient to the attack.

Cost-benefit trade-off analysis using BBN for aspect-oriented risk-driven development

Security critical systems must perform at the required security level, make effective use of available resources, and meet end-users expectations. Balancing these needs, and at the same time fulfilling budget and time-to-market constraints, requires developers to design and evaluate alternative security treatment strategies. In this paper, the authors presented a development framework that utilizes Bayesian belief networks (BBN) and aspect-oriented modeling (AOM) for a cost-benefit trade-off analysis of treatment strategies. AOM allows developers to model pervasive security treatments separately from other system functionality. This eases the trade-off by making it possible to swap treatment strategies in and out when computing return on security investments (RoSI). The trade-off analysis is implemented using BBN, and RoSI is computed by estimating a set of variables describing properties of a treatment strategy. RoSI for each treatment strategy is then used as input to choice of design.

Verifiable composition of access control and application features

Access control features are often spread across and tangled with other functionality in a design. This makes modifying and replacing these features in a design difficult. Aspect-oriented modeling (AOM) techniques can be used to support separation of access control concerns from other application design concerns. Using an AOM approach, access control features are described by aspect models and other application features are described by a primary model. Composition of aspect and primary models yields a design model in which access control features are integrated with other application features. In this paper, we present, through an example, an AOM approach that supports verifiable composition of behaviors described in access control aspect models and primary models. Given an aspect model, a primary model, and a specified property, the composition technique produces proof obligations as the behavioral descriptions in the aspect and primary models are composed. One has to discharge the proof obligations to establish that the composed model has the specified property.