Software patterns are widely adopted to manage the rapidly increasing complexity of software. Despite their popularity, applying software patterns in a software model remains a time-consuming and errorprone manual task. In this paper, we argue that the relational nature of both software models and software patterns can be exploited to automate this cumbersome procedure. First, we propose a novel approach to selecting applicable software patterns, which requires only little interaction with a software developer. Second, we discuss how relational learning can be used to further automate this semi-automated approach.
The complexity of both software and the software development process has increased rapidly over the past decades because of three reasons. The rst reason is the steadily increasing complexity of the problems that software tackles. The second reason is the shift towards distributed software, which entails a number of additional issues to account for. The third reason is the relatively long lifetime of software, which is often much longer than that of the hardware it was originally developed for and which requires it to adapt to an ever changing environment.
Software patterns provide established solutions to recurring issues in software
development [
In this paper, we argue that the relational nature of both software models and software patterns can be exploited to automate this cumbersome procedure. We apply inductive logic programming techniques for representing these models and patterns as well as reasoning about them. First, we propose a semi-automated approach to selecting applicable patterns in a graphical software model. Our approach relies on a concise relational representation of both the available software patterns and a software model. The approach requires only little interaction with a software developer whereas current pattern selection procedures rely on an extensive speci cation of the design problem. Second, we brie y share ideas on how relational learning techniques can further automate our approach and hence reduce the amount of user interaction. 2
On a very high level, designing software is gathering requirements and ensuring these requirements are met in the nal software system. Software developers typically identify a number of components, which each satisfy a subset of the requirements, in order to manage the complexity of software. Components o er their functionality through one or more interfaces via which they collaborate.
Software developers formally capture their design decisions in graphical
models. Each model element can be annotated with additional information (e.g.,
implementation details) that is required during the development process. Although
our approach is applicable to multiple types of software models, we restrict
ourselves to the Component-and-Connector Model, which is one of the most
important types of models during software development. Figure 1 shows an excerpt of
a digital newspaper system, inspired by [
Software patterns o er established solutions to recurring design issues. Alongside a unique name, a software pattern comprises a generic description of both the design issue it addresses and the solution it proposes (i.e., independent of any concrete design and/or implementation decision). Furthermore, a software pattern contains an overview of its consequences and trade-o s, which is helpful to decide on the most appropriate software pattern.
Automatically selecting applicable software patterns requires a formal
representation of either the design issue a software pattern addresses or the solution it
proposes. Our approach leverages Zdun and Avgeriou's concept of primitives [
Figure 2 shows the Client-Dispatcher-Server pattern, which comprises
the Client, Dispatcher and Server primitives [
Current pattern selection techniques require either an extensive speci
cation of the design problem (e.g., [
Although automated pattern selection has only been given little attention to
date, the idea of tackling software engineering issues using machine learning is
not new. One area of interest is that of software pattern detection, where the
task is to identify applied software patterns when re-engineering legacy software.
Correa et al. [
This section discusses the two main contributions of this paper. First, we propose Semi-Automated Role-Based Pattern Selection (SARBPS), a novel semiautomated approach for selecting applicable software patterns in software models. The approach exploits the relational nature of both software patterns and software models to signi cantly reduce the time required to decide which software patterns are applicable in a given software model. Second, we discuss how relational learning can be used to further automate our approach and hence reduce the amount of user interaction. 4.1
We now discuss the three steps of the SARBPS approach in turn. The rst step concerns representing the available software patterns as sets of primitives, where each primitive ful lls one or more roles. SARBPS represents this information as a knowledge base consisting of two classes of facts. The rst class is the class of entity facts that enumerate the available patterns, primitives and roles. The second class is the class of relation facts that de ne relations between patterns and primitives on one hand and primitives and roles on the other hand. These relations express which primitives each pattern comprises and which role(s) each primitive ful lls. Roles are only meaningful if ful lled by at least one primitive.
The second step involves annotating the components and interfaces of the software model with additional information. A software developer employs the requirements that the components and interfaces satisfy to assign one or multiple roles, which describe their properties and characteristics. Roles indicate which application-independent function the annotated element ful lls in a software system. For example, a component that provides services to other components can be assigned the ServiceProvider role. Only roles de ned in the knowledge base constructed in the previous step can be assigned.
The third step involves selecting applicable patterns by establishing a mapping between the roles of the elements in the software model on one hand and the roles of the available patterns on the other hand. For each of the available patterns, SARBPS veri es whether it is applicable. A pattern is applicable if and only if each of the software model's roles is ful lled by at least one of the pattern's primitives. SARBPS achieves this by querying the knowledge base it constructed in the rst step using the roles assigned during the second step.
SARBPS uses two queries to retrieve all applicable patterns from the knowledge base. The rst query returns for a given pattern and a given role which of the pattern's primitives ful lls this role or fails when no primitive is found. The second query returns a list of applicable patterns for a given set of roles by iteratively calling the rst query for any possible combination of an available pattern and a given role.
Example 1. In order to illustrate our approach, we use the software model and software pattern shown in Figures 1 and 2 respectively. Due to space constraints, we only provide a high-level discussion in this paper.2 In the rst step, we add the Client-Dispatcher-Server pattern and the three primitives this pattern comprises, Client, Dispatcher and Server, to the knowledge base. We also add the roles ServiceProvider and ServiceRequester, which the Server and Client primitives ful ll respectively. In the second step, we assign the ServiceProvider role to both the NewspaperService and ClientManagement components, and the ServiceRequester role to the Client component. In the third step, querying the knowledge base for applicable software patterns returns the Client-Dispatcher-Server pattern.
Although our semi-automated pattern selection approach saves signi cant amounts of precious development time, manually assigning roles to components and interfaces is still an error-prone and time-consuming task, especially for large, real-world software systems. Therefore, we propose using relational learning to automate this task and share some ideas on how to do this in what follows. 4.2
When annotating a component or an interface with one or multiple roles, software developers leverage the descriptions of the requirements each component or interface ful lls. These descriptions are mostly free text but they tend to have a simple structure. For example, one of the requirements in our running example states that a journalist must be able to add an article to the system. In a medical system, a requirement could be that the medical sta must be able to add a new patient le to the system. Although the descriptions of these requirements are completely di erent, it is clear that they can be written as instances of the same abstract pattern since they share a common structure.
The missing building block is a convenient formal language for representing software requirements. Once we have such a language, we can naturally model requirements in a relational learning system and pose the assignment of roles to components and interfaces as a collective classi cation task. We can then represent components and interfaces as entities, and collaborations amongst these components and interfaces as relations. The classi cation task boils down to learning one or multiple roles for each component. The key idea is to leverage the expert knowledge and previous role labeling e orts of software engineers, who can possibly already assign roles to some of the components and interfaces.
The kernel-based relational learning framework kLog [
Our main research direction is further automating the approach using relational learning techniques. The key challenge is designing a convenient formal language for representing software requirements in a relational learning framework. Furthermore, we aim to limit the number of proposed patterns by incorporating each pattern's trade-o s and consequences.
Acknowledgments. We thank Paolo Frasconi and Luc De Raedt for providing access to the kLog implementation.