Abstract
Rules that define relationships between objects are an important part of the specifications of software systems. However, support for the explicit representation of those rules in modelling languages is still immature and there is little support to assist software engineers in implementing them. The result of this practice is hand-crafted and error-prone applications. In this chapter, we analyse some common patterns used to implement rules and discuss the shortcomings associated with those patterns. We then discuss several options to explicitly represent rules, and how to automate the generation of application code from rules.
TopIntroduction
Object-oriented programming (OOP) has become the dominant programming paradigm over the last twenty years. OOP facilitates the modularisation and reuse of software, and supports the “divide and conquer” approach to master large and complex software engineering projects. Several modelling techniques have been proposed in order to support object-oriented software engineering, the most successful ones being the Unified Modelling Language (UML) (UML, 2004) and the Eclipse Modeling Framework (EMF) (Budinsky, Brodsky, Merks, Ellersick & Grose, 2003). As far as modelling is concerned, models such as UML diagrams provide a useful level of abstraction from the programming language used. While it was very common in the early years of object-oriented programming and design to manually translate these models into programming language artefacts, code generation has become more and more common. The Model Driven Architecture (MDA) (http://www.omg.org/mda/) initiative of the Object Management Group (OMG) aims at embedding this practise into a conceptual framework that is based on the idea of model transformations.
In general, the gap between modelling and programming has narrowed significantly in recent years as the abstraction level of programming languages has gone up. Programming language features related to low level resource management like explicit memory management (destructors) have disappeared from modern languages and have been replaced by services provided by compilers, virtual machines or application servers. New features have been added to languages like Java and C# to make them more modelling like. For instance, annotations can be used to stereotype artefacts, assertions and test cases can be used to express constraints and therefore method semantics, and generic types facilitate the representation of one-to-many relationships.
However, there is one aspect where a deep conceptual gap between modelling languages and programming languages remains: relationships. While relationships are first-class citizens in modelling languages like UML, EMF and ER, they are not explicitly represented in modern programming languages. The state of the art is that relationships are manually coded. This is an error-prone process, and the hand-crafted code resulting from it is hard to maintain. In particular, it is very difficult to reverse engineer models from this code. Østerbye (2007) has compared this practice with “translating while loops into goto statements”. The situation can be improved by generating code, and many case tools contain simple, template-based code generators for this purpose. There has been research into adding explicit relationships to programming language starting with Rumbaugh’s Data Structure Manager (DSM) (Rumbaugh, 1987). A more recent approach to add relationships to the Java language is RelJ (Bierman & Wren, 2005). An alternative solution that has been explored is to add relationships libraries to Java (Østerbye, 2007) and AspectJ (Pearce & Noble, 2006). Code generation patterns for relationships have been investigated by Noble (1997) and Genova, del Castillo and Llorens (2003). The focus of this research is the representation of explicit relationships between objects. However, in many cases relationships are not explicitly defined but instead specified by rules. The support modelling languages have to express this kind of rules is weak. UML for instance has the concept of derived association for this purpose. The isDerived attribute in Association is defined as a boolean that “specifies whether the association is derived from other model elements such as other associations or constraints” (UML, 2004). However, this definition is very vague and hardly suitable to automate the implementation of derived associations.
In this paper we investigate several commonly encountered implementation patterns for rules defining relationships between objects. We then point out the weaknesses of this approaches and discuss several alternative strategies. Finally, we present a simple scripting language for rules and a rule compiler that addresses the problems discussed earlier.
Key Terms in this Chapter
External Fact Store: An external fact store is a data store that provides facts that are referenced in rules. External fact stores can be queried using network protocols. Facts stored in external fact stores are often volatile, the number of facts stored is usually large and the organisation owning the applications querying the external fact stores are not in control of those fact stores.
Antipattern: An antipattern is a structure used in software design that seems to be beneficial initially, but has significant, unintended negative consequences.
Dynamic Rule Compilation: Applications reference artefacts that represent rules through interfaces. The integration between application code and interfaces happens at system build time, while the instantiation of these interfaces is done with artefacts that are generated at runtime. Dynamic compilation introduces loose coupling between applications and rules by providing stable interfaces through which applications communicate with artefacts representing rules.
Domain Specific Language: A domain specific language (DSL) is formal language designed for a special domain, the opposite of a general purpose programming language.
Static Rule Compilation: Applications reference classes and other artefacts that represent rule directly. The integration between application code and these artefacts happens at build time. Applications and rules are tightly coupled.
Rule Compiler: A rule compiler is a computer program that translates rules represented in a formal language such as a domain specific language (DSL) for rules or XML into a general purpose programming language.
Design Pattern: A design pattern is a reusable solution for a software design problem. Patterns are platform independent, the same pattern can be used in different environments.
On Demand Computing: Refers to an application design where expensive computations and access to external resources is delayed until it becomes really necessary. This is similar to the lazy initialization design pattern used in programming. A good example for on-demand-computing is how internet search engines handle queries and display only the first chunk of results.