Several tools support the development and use of OWL (see W3C’s website2 for a list). The
Prot´eg´e IDE is perhaps the most well known [71]. There are also several implementations of reasoners supporting OWL (e.g., Chainsaw, FaCT++, JFact, HermiT, Pellet, RacerPro). Two reasoners stand apart from the others, namely HermiT (used in Prot´eg´e), and Apache Jena. Apache Jena is an open-source framework for Java which supports creating, manipulating and querying RDF (and OWL) ontologies.
Another alternative to interaction with ontologies is the OWL API [55]. It is another open source Java framework with the same objectives of Apache Jena. Both frameworks would suit the approach needs. The selected tool to support the proposed work is Apache Jena. First, it supports the creation of ontologies, as required by the proposed approach. Second, being an Apache framework, it will continue to have support and updates, as the Apache projects tend to be reliable.
Since is part of the objectives to have a tool which supports the inference process, Apache Jena seems to be an adequate way to integrate OWL specification and query mechanisms into Java applications.
2.4.3
Discussion
In order to represent requirements information, knowledge bases are a recurrent approach. It is possible to find several works addressing such representations resorting to ontologies. Ontologies are expressive enough to handle such specifications, while providing query mechanisms.
Regarding the proposed approach, these works provide valuable insights on how to perform the formalization of the information, and which kind of verification techniques it is possible to apply. They further provide hints on which specific technologies are most common, as is the case of OWL and SPARQL. Despite none of the works addressing specifically the representation of use cases, they provide valuable hints on how to achieve such, and regarding the viability of such approach. Both exploring the capability of OWL to represent requirements’ information, and SPARQL’s capability to query them is proposed.
2.5. SOFTWARE PATTERNS 27
2.5
Software Patterns
This section presents an overview on software patterns’ related works. Approaches concerning their definition, representation, instantiation, usage and inference are presented, in order to discuss the viability of formalize and operationalize them. Not an extensive amount of works can be traced in all areas, but some insights can be obtained from the existing ones.
2.5.1
Patterns
The term Pattern can be traced back to Christopher Alexander’s work [1]. A pattern is defined as a well known solution, for a given kind of problem, that arises in a specific context. Given a problem, patterns enable solutions to be reused without the need to recreate them all over again. Patterns exist within a certain context. Hence, given a problem/context pair, patterns provide the corresponding solution (c.f. Figure 2.7). Such an idea of a pattern was later adopted to software engineering by Gamma et al. [41]. Since then, there have been a large amount of works related with patterns [96].
Figure 2.7: Patterns as bridges between problems/contexts and solutions.
In software engineering patterns appear in several flavors, depending on their objectives. Two kind of patterns are specially relevant in the context of this work. First, are the requirements patterns. Specifically, for a given set of stakeholders needs, the matching requirement patterns present a good requirements specification. The second relevant kind consists of design and architectural patterns. Design patterns provide solutions for common issues which occur at the design level (i.e. organizations of classes). Architectural patterns produce solutions for issues which occur at a higher architectural level (i.e. organizations of classes groups).
2.5.2
Requirement Patterns
Requirement patterns are both applicable on software engineering and requirements engineering, with works addressing their specification, management and application. While not as popular as other kinds of patterns (e.g. design and architectural patterns), several works regarding requirement patterns can be found. Requirement patterns are referred to in literature also as software requirement patterns. In this work, in order to differentiate them from patterns which describe solutions (e.g. design and architectural patterns), they are simply referred to as requirement patterns.
A systematic literature review on requirement patterns was performed by Silva and Benitti [29]. Three interesting outputs resulted from the literature review.
• As expected, the usage of templates in order to specify requirement patterns is common practice;
• While some authors focus on the specification of non functional requirements with re- quirement patterns, there is evidence that they can also be used to specify functional requirements;
• Requirement patterns should support composition processes.
Regarding the proposed objective, it is relevant the fact that there is evidence of their usage, specifically to specify functional requirements.
Several authors address the definition and specification of requirement patterns [119, 40]. A rele- vant contribution is provided by Withal [120], which presents a catalog of requirement patterns, addressing aspects such as their usage, classification and identification. Another relevant work is presented by Yan, which catalogs and classifies 72 eCommerce patterns [123].
The organization of requirement patterns in catalogs has been addressed by several works in order to support different scenarios. Apart from the aforementioned work by Withal [120] (one of the most complete, with 41 patterns, distributed by 8 categories as depicted in Figure 2.8), it is possible to find catalogs which document domain specific patterns, as Content Management Systems (CMS) [93], or address specific aspects of the systems, as usability [16], trust [54], sustainability [97] or legal aspects [53].
2.5. SOFTWARE PATTERNS 29
Analysis on the adoption of requirement patterns shows that, despite the difficulties, they are being adopted as recurrent practice, for instance in the industry [39, 30]. Works which address the usage of requirement pattern in systematic ways contribute to their adoption. Authors present approaches to formalize requirements, and to reason about them [39, 30]. Existing approaches tend, however, to focus in the requirements engineering aspects. Tools and approaches focus in handling, managing and analyzing requirements and their relations (e.g. support for reuse), as means to support the software development process. In the context of this work, the inference of requirement patterns from requirement specifications is proposed, in order to automate the analysis of requirements.
Analysis of existing works on requirement patterns shows that authors are concerned mostly with the analysis and verification of specifications, in order to improve the specifications them- selves. It was not possible to find, however, works providing a systematic and automated oriented transition process from requirement patterns to software specifications. Since requirement pat- terns represent aspects of the final solution, implementing such a transition provides support to generate solutions closer to the intended specifications.
2.5.3
Patterns Categorization
The pattern instantiation process consists in producing specific outputs (e.g. models, or code), from a pattern specification. In the context of this work, the instantiation of software patterns, in order to produce architectural models, is proposed.
Opposing to requirement patterns, the quantity of works concerning software patterns is exten- sive, therefore, it is not trivial to find a clear categorization of existing works. A literature review was performed in the context of this work. From this review two relevant outputs were produced. First, a template was specified with the intent of supporting all kind of patterns. Second, two levels of patterns were defined, namely Patterns and Patterns Sets, in which existing approaches can be categorized. Figure 2.9 presents the result of the categorization process.
The Pattern sets are subdivided in three categories. Pattern Catalogs consist in a set of software patterns described and organized according to their nature, in order to support their usage. Pattern Languages consist in subset of patterns and their relations. Pattern compounds are small sets of patterns which are usually found together, or are known for producing good solutions when combined.
The patterns themselves can represent information at different levels of abstraction. Requirement patterns, as aforementioned, represent common requirements found in different specifications. Analysis patterns represent knowledge at analysis level, without concerning source code or im- plementation. Architectural Patterns, as presented for instance by Buschmann et al. [15], present architectural solutions for specific situations, with corresponding forces and drawbacks. Design Patterns, as proposed by Gamma et al., define design-level solutions for well known problems for Object Oriented projects. Finally, Idioms define platform specific solutions.
Figure 2.9: Categorization of software patterns, according to their abstraction level (higher on the bottom, lower on the top) [27].
Regarding the production of models as input for the MDA process, they are achieved by com- posing software patterns. Thus, apart from the requirement patterns, two other patterns are of special interest. On the one hand, architectural patterns which specify how to organize groups of classes, at a high level of abstraction. On the other hand, design patterns specify how the individual classes should be organized. More information can be found in the technical report resulting from the literature review [27].
2.5.4
Pattern Inference
The inference of patterns from knowledge bases has already been the subject of study. It is possible to find works from the late 90’s regarding pattern inference on several formats [113]. For the proposed approach, the objective consists in the inference of requirement patterns, which in their genesis are similar to software patterns. As result, presented work focuses in software patterns.
One of the most influential works regarding software patterns, specifically design patterns, was presented by Gamma et al. [41]. Such work, in a form of a pattern catalog, defined the basis for many following works. There are other influential works describing software patterns at other levels of abstraction, as is the case of architectural patterns [37, 15] and requirement patterns [119]. The definition of patterns is essential in order to perform their inference. When patterns started to be defined, several works emerged regarding their inference (see, for instance, [96] for a survey). Software pattern inference was addressed in several aspects. Some
2.5. SOFTWARE PATTERNS 31
authors propose their inference by analyzing source code in which they are are contained [113, 100]. These approaches are mostly useful for documentation and reengineering tasks, since they provide a better understanding of the source code organization. Directly analyzing the source code avoids the need to pre-process the code and apply transformation techniques. The analysis is made directly in the artifacts themselves.
An alternative to analyzing only the source code, is to generate an intermediary representation. An example of such is to generate a UML model from the respective source code, and map it into a ontology, written for instance in Prolog [68]. Creating an intermediary representation, as a knowledge base, is more expressive, but there is the need to apply an analysis process to the source code, prior to generating the knowledge base. This translation process represents an additional cost, and might lead to loss of information. In the case of analyzing only source code, there are also tools supporting software pattern inference. An example is the Ptidej tool suite, with the objective of evaluating and enhancing software quality through patterns [48].
Previous works by the authors provided relevant background to support the objectives proposed in this thesis [22, 23]. The authors developed an approach to analyze Java source code, generate high level models (class diagrams), and in those models infer the existence of design patterns, resorting to a knowledge base and an inference engine, as depicted in Figure 2.10. These works provided knowledge in order to extend such approach, and support the proposed objectives.
Figure 2.10: Design pattern inference approach, adapted from [22].
The specific inference of software patterns from OWL knowledge bases has also been addressed [69, 59]. The approaches analyze source code in order to generate intermediary representations, which are next formalized in OWL. Resorting to OWL’s inference engine, the authors are able to perform software pattern inference. These works are of special interest, since the proposed approach requires support for inferring requirement patterns from a knowledge base.
As part of the objectives proposed in this work, several approaches were presented which can be adjusted in order to support the formalization of requirements in OWL. The aforementioned approaches all deal with software patterns. For requirement patterns, specially considering their
inference, there are not a large amount of works available. However, since requirement patterns are similar to software patterns, it is possible to develop a new inference approach based on the existing ones.