Attribute Enabled Software Development

Attribute-Oriented Programming (@OP)

Attribute Enabled Programming (AEP)

Attribute Enabled Software Development (AESD)

The book examines the software engineering aspects of deploying attribute programming to software development and provides solutions that enable scaling attribute programming in medium and large software projects, such as, product lines.

Buy the Book

Attribute Enabled Software Development - Book Cover Attribute Enabled Software Development
Illustrated with mobile software applications

Attribute Enabled Programming (AEP) is a wide-spreading technique that uses attributes to decorate existing code entities. AEP is supported in several general purpose languages, such as, .NET and Java, and by modeling languages, such as, MOF / UML.

Attribute annotations may, however, fail to scale. Attribute dependencies complicate the interpretation and add-hoc solutions are difficult to maintain. A well defined development methodology that covers all the steps of Attribute Enabled Software Development (AESD) needs to be applied.

This book focuses on the domain of mobile device software applications, based on Java Micro Edition (Java ME), and discusses the complete steps of applying AESD to model domain specific abstractions. Relation to product-lines is explored, and a concept of attribute-supported mobile containers to organize domain services, adapted from the enterprise containers, such as, Java EE and COM+, is presented. A structured methodology to transform attribute-based abstractions that warranties termination is introduced and illustrated.

The book targets software professionals, and researchers in software engineering, programming languages, and graph transformations.

Preview Table of Contents. More details about the book contents follow.

To order the book, search at with ISBN 978-3836410168 to find the on-line stores that sell it. Price around 68.00 € (Euro)


Attribute Enabled Programming (AEP)

Attribute Enabled Programming (AEP) is a wide-spreading technique that uses explicit attributes directly in the programming language level to decorate code existing entities, in order to modify their semantics. Attributes are of form of graph labelling and enable the creation of custom (layered) hypergraphs. Attributes can selectively change the semantics of the decorated elements in arbitrary ways.

AEP is supported in several general purpose languages, such as .NET (attributes) or Java (annotations). AEP is also supported by modeling languages, such MOF, UML (tagged values, stereotypes). AEP enables developers to enhance the semantics of an existing language with embedded domain specific language (EDSL) constructs, without any need to change the language grammar. Developers can use AEP to customize a language to fit their needs, without having to worry about parsing and grammar rules.

AEP is not a mainstream methodology, rather it complements ubiquitously existing programming methodologies. It can be appended in the top of any existing programming model (methodology), such as, object-oriented programming (OOP), or aspect-oriented programming (AOP). Hence, the name Attribute Enabled Programming - AEP is preferred, and not something else, such as, Attribute Oriented Programming.

Several names are used to refer to the explicit attributes, such as, attributes, annotations, tags, or labels. All these names are heavily overloaded with many meanings in the everyday and the scientific use. The term attributes is preferred to the other terms, because of historic ties that have to do with the name used for attribute grammars in the early 1960s. The term tagged grammars is, however, preferable for programming language grammars with explicit support for attributes. The use of attributes (or tags) to denote additional semantics about an object of interest is intuitive for humans and is not bound to any specific technology.

The semantics associated with an attribute can be arbitrary, and so is the level of automation that an attribute can introduce. While attributes are used to model conceptual entities, their usage is aspectual. AOP techniques can be used to specify attributes. On the other hand, attributes can be used to explicitly express AOP pointcuts, which are either too complicated, or too fragile to be expressed otherwise. Because attributes combine explicit and aspectual programming models, developers can select either an explicit or an aspectual programming model to use with AEP, based on their preferences and the concrete use case.

Any invasive transformation framework that enables assessing some form of the abstract syntax tree (AST) of a program either before, or after compilation, or at run-time (reflection) can be used to process the program entities decorated (annotated) with attributes. There is a trend with several popular generic purpose languages, such as, .NET and Java, to include attribute and AST processing capabilities, as part of the technology that comes with the core language supported by the corresponding language vendor. The default langauge support for attributes removes the dependency on third-party tools or language extensions, making AEP more acceptable and available to a wider set of developers.

Attribute Enabled Software Development (AESD)

As AEP becomes more widely used, it can be easily overused and attribute annotations may fail to scale. Attributes are very easy to introduce, and depending on the automation associated with them, cheap to process. This could result in a large number of attributes used in unstructured ways within a project, or, in the general case, within a product-line made up of several related projects. The interpretation of many inter-related attributes could also become a bottleneck. Attribute dependencies further complicate the interpretation and add-hoc programming solutions cannot scale. A well defined development methodology that covers all the steps of Attribute Enabled Software Development (AESD) needs to be applied.

There are three main aspects how AESD can be structured:

Attribute Enabled Software Development (AESD)
  • Modeling domain specific abstractions (DSA) with attributes. Attribute introduction can follow feature-oriented diagrams (FODA). Attributes can be organized in a tree-like structure with nested namespaces, where each tree models the features of a given domain asset. Such trees will be called attribute families. An attribute family represents the variation of a single domain concern. Sub-attributes model the fine-grained variability of a family, and attribute parameters support the variability of a single (sub) feature. Nested namespaces within a family promote name reuse, similar to name scope nesting in a programming language.

  • Organizing domain concerns as container services. Object-oriented (OO) libraries can be used to organize the logic related to the common domain assets. OO libraries, however, lack well-defined extension points. The common domain functionality can be presented as services of an open and extensible software container. The container manages the different services and the transformation workflow. The services are transparently injected into the decorated components. The actual container design and implementation may vary depending on the use case, e.g., it can be lightweight and supported only by code generation, or implemented as a run-time extension.

  • Having a structured methodology to transform attribute-based DSA. The domain knowledge can be utilized to define the transformation dependencies between the different attribute families, and to organize the transformation workflow. Each transformation unit can address a single attribute family. The inter-transformation semantics could be expressed as inner attributes, resulting in a uniform attribute-driven transformation model. The features of the programming language meta-model can further be used to introduce a vertical layering on the workflow. Finally, meta-attributes (attributes that decorate attributes) can be used to model the transformation cross-cutting concerns (CCCs) in a uniform way that fits to the overall AESD model.