Fusing Logic And Control With Local Transformations: An Example Optimization

Programming supports the separation of logical concerns from issues of control in program construction. While this separation of concerns leads to reduced code size and increased reusability of code, its main disadvantage is the computational overhead it incurs. Fusion techniques can be used to combine the reusability of abstract programs with the efficiency of specialized programs. In this paper we illustrate some of the ways in which rewriting strategies can be used to separate the definition of program transformation rules from the strategies under which they are applied. Doing so supports the generic definition of program transformation components. Fusion techniques for strategies can then be used to specialize such generic components. We show how the generic innermost rewriting strategy can be optimized by fusing it with the rules to which it is applied. Both the optimization and the programs to which the optimization applies are specified in the strategy language Stratego. The optimization is based on small transformation rules that are applied locally under the control of strategies, using special knowledge about the contexts in which the rules are applied

On the Notion of Abstract Platform in MDA Development

Although platform-independence is a central property in MDA models, the study of platform-independence has been largely overlooked in MDA. As a consequence, there is a lack of guidelines to select abstraction criteria and modelling concepts for platform-independent design. In addition, there is little methodological support to distinguish between platform-independent and platform-specific concerns, which could be detrimental to the beneficial exploitation of the PIM-PSM separation-of-concerns adopted by MDA. This work is an attempt towards clarifying the notion of platform-independent modelling in MDA development. We argue that each level of platform-independence must be accompanied by the identification of an abstract platform. An abstract platform is determined by the platform characteristics that are relevant for applications at a certain level of platform-independence, and must be established by balancing various design goals. We present some methodological principles for abstract platform design, which forms a basis for defining requirements for design languages intended to support platform-independent design. Since our methodological framework is based on the notion of abstract platform, we pay particular attention to the definition of abstract platforms and the language requirements to specify abstract platforms. We discuss how the concept of abstract platform relates to UML

An Approach to Flexible Multilevel Modelling

Multilevel modelling approaches tackle issues related to lack of flexibility and mixed levels of abstraction by providing features like deep modelling and linguistic extension. However, the lack of a clear consensus on fundamental concepts of the paradigm has in turn led to lack of common focus in current multilevel modelling tools and their adoption. In this paper, we propose a formal framework, together with its corresponding tools, to tackle these challenges. The approach facilitates definition of flexible multilevel modelling hierarchies by allowing addition and deletion of intermediate abstraction levels in the hierarchies. Moreover, it facilitates separation of concerns by allowing integration of different multilevel modelling hierarchies as different aspects of the system to be modelled. In addition, our approach facilitates reusability of concepts and their behaviour by allowing definition of flexible transformation rules which are applicable to different hierarchies with a variable number of levels. As a proof of concept, a prototype tool and a domain-specific language for the definition of these rules is provided.publishedVersio

Weaving of Aspects in Business Process Management

Separation of cross-cutting concerns is an important issue in business process management, where Aspect-Oriented Business Process Modeling (AO-BPM) aims to support this separation through a new form of encapsulation technique. Although different researchers have investigated how these models can be designed to support separation of non-retroactive cross-cutting concerns, there is no study that defines the separation of retroactive ones. The lack of a unified definition of the syntax and the operational semantics for these models hinders their enactment in practice as well. As a result, the perceived usefulness and usability of these approaches have not yet been investigated so far. Thus, this article fills this gap by formalizing an AO-BPM language and the semantics that can support enactment of such models. The semantics is validated through the state-space analysis technique, and the feasibility of the implementation is also demonstrated. The perceived usefulness and easy to use of the AO-BPM is evaluated by applying the Technology Acceptance Model during a workshop session. The result shows that participants perceived the approach usable and easy to use

“You Keep Using That Word”: Why Privacy Doesn’t Mean What Lawyers Think

This article explores how the need to define privacy has impeded our ability to protect it in law. The meaning of “privacy” is notoriously hard to pin down. This article contends that the problem is not with the word “privacy,” but with the act of trying to pin it down. The problem lies with the act of definition itself and is particularly acute when the words in question have deep-seated and longstanding common-language meanings, such as liberty, freedom, dignity, and certainly privacy. If one wishes to determine what words like these actually mean to people, definition is the wrong tool to use. The exact wrong way to go about understanding privacy is by supplying one’s own definition; that is unscientific. Since words in a living language mean many things (e.g., what does “cool” mean?), the act of definition reduces the multiple meanings of the defined word to a specified meaning. Each increase in precision comes with a corresponding separation from some set of meanings that would have applied to the living, undefined version of the word. The resulting defined word may be more precise but is often crippled, isolated, and bereft of the connections and connotations that made it part of a rich and living language. Like Procrustes, who strapped his victims to a bed and then either lopped off their feet if they stuck out or stretched the person on a rack if they were too short, lawyers are specifically trained to stretch and cut words. Tools of definition are badly suited to determine what people mean when they say “privacy.” For example, the actual meaning of “privacy” might better be explored through the tools of linguistics or cultural anthropology than through the tool of legal definition. This article therefore recommends that lawyers should set aside the flawed tool of definition and pick up the tool of analogy when they ask what words like privacy mean. This article asks why privacy has been uniquely pressed by concerns about supposed imprecision. For example, we do not stop our search for “security” because of a supposed lack of definition of the word. If privacy must have a definition to be operationalized, it will remain be conveniently narrow. moribund. And if privacy requires narrowing to be operationalized, any operationalization will be conveniently narrow. “You keep using that word. I do not think it means what you think it means.

“You Keep Using That Word”: Why Privacy Doesn’t Mean What Lawyers Think

This article explores how the need to define privacy has impeded our ability to protect it in law. The meaning of “privacy” is notoriously hard to pin down. This article contends that the problem is not with the word “privacy,” but with the act of trying to pin it down. The problem lies with the act of definition itself and is particularly acute when the words in question have deep-seated and longstanding common-language meanings, such as liberty, freedom, dignity, and certainly privacy. If one wishes to determine what words like these actually mean to people, definition is the wrong tool to use. The exact wrong way to go about understanding privacy is by supplying one’s own definition; that is unscientific. Since words in a living language mean many things (e.g., what does “cool” mean?), the act of definition reduces the multiple meanings of the defined word to a specified meaning. Each increase in precision comes with a corresponding separation from some set of meanings that would have applied to the living, undefined version of the word. The resulting defined word may be more precise but is often crippled, isolated, and bereft of the connections and connotations that made it part of a rich and living language. Like Procrustes, who strapped his victims to a bed and then either lopped off their feet if they stuck out or stretched the person on a rack if they were too short, lawyers are specifically trained to stretch and cut words. Tools of definition are badly suited to determine what people mean when they say “privacy.” For example, the actual meaning of “privacy” might better be explored through the tools of linguistics or cultural anthropology than through the tool of legal definition. This article therefore recommends that lawyers should set aside the flawed tool of definition and pick up the tool of analogy when they ask what words like privacy mean. This article asks why privacy has been uniquely pressed by concerns about supposed imprecision. For example, we do not stop our search for “security” because of a supposed lack of definition of the word. If privacy must have a definition to be operationalized, it will remain be conveniently narrow. moribund. And if privacy requires narrowing to be operationalized, any operationalization will be conveniently narrow

Early aspects: aspect-oriented requirements engineering and architecture design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications

An Analysis of Composability and Composition Anomalies

The separation of concerns principle aims at decomposing a given design problem into concerns that are mapped to multiple independent software modules. The application of this principle eases the composition of the concerns and as such supports composability. Unfortunately, a clean separation (and composition of concerns) at the design level does not always imply the composability of the concerns at the implementation level. The composability might be reduced due to limitations of the implementation abstractions and composition mechanisms. The paper introduces the notion of composition anomaly to describe a general set of unexpected composition problems that arise when mapping design concerns to implementation concerns. To distinguish composition anomalies from other composition problems the requirements for composability at the design level is provided. The ideas are illustrated for a distributed newsgroup system