The entities visualization plugin neither generates nor manipulates the internal data. Its sole purpose is to provide a simple overview of the extracted data to support a preliminary validation step. Indeed, no input is required by the user in this step to proceed with the process.
4.4
Ontology Creation
Creating the ontology that represents the requirements information is possible by automatically analyzing the RUS specifications. It is, however, necessary to have the specification of the types for the extracted entities. Two sources provide the types information, namely the domain model, and manual user input.
4.4.1
Types Definition
The automatic types information extraction is supported by the query presented in Listing 4.2. The query extracts all the types for all the entities in the domain model. Specifically, all the subject and objects, related via an association of the TypeOf category are requested. This results in the list of all instances and associated known types (see Appendix A.3 for the remaining queries).
PREFIX : < http :// www . rmsc . com # > SELECT ? s u b j e c t ? type
WHERE { ? s u b j e c t ? p r e d i c a t e ? type .
FILTER (? p r e d i c a t e rdf : type : TypeOf ) }
Listing 4.2: SPARQL query to identify types for individuals.
The previously presented query can be further specialized in order to return only the types for a specific entity. Thus, in Listing 4.3 the query has been tailored by changing the ?subject variable to User. The result of the query will provide the known types for User. The presented query does not address transitivity of properties. Consequently, if an entity User is known to have the type of another entity Actor, and Actor is known to have another type, e.g. Object, it is not assumed that User has the type Object. However, it is worth noting that SPARQL has enough expressiveness to handle such an extension to support transitivity analysis.
PREFIX : < http :// www . rmsc . com # > SELECT ? type
WHERE { : User ? p r e d i c a t e ? type .
FILTER (? p r e d i c a t e rdf : type : TypeOf ) }
Listing 4.3: SPARQL query to identify the types for User.
Depending on the level of detail of the domain model, it might not be possible to infer all the types information. In that case, users will have to manually specify the missing types. uCat contains
a plugin which simultaneously supports the analysis of the extracted types, and specification of new ones. The types definition plugin is depicted in Figure 4.7. On the left the individuals, and corresponding inferred types are show. On the right, the types used to specify those individuals are presented.
Figure 4.7: Types definition plugin, with the automatically extracted information.
As it is possible to see in Figure 4.7, there are some missing types. Manually specifying the types corresponds to the second step of the types definition process. In this step the user has also the possibility to check if the types’ association is correct, and adjust it if necessary. Here, there are two options available. The first one requires the user to manually specify each missing type. The second one disregards the individuals’ types, considering that all have a generic type. SCARP supports both kinds of information for the process of generating architectural prototypes. By following the manual types definition approach, the types Action, Collection, Object, Data and Property were defined and associated with the respective individuals. Figure 4.8 presents the complete types table.
After the definition and attribution of the types to the individuals, the plugin updates the internal representation of the use cases data. This adds more information, that is essential in order to proceed with the SCARP process.
4.4. ONTOLOGY CREATION 85
Figure 4.8: Types definition plugin with all types defined.
4.4.2
OWL Ontology Generation
Combining the declared instances, object properties and types information supports the creation of ontologies, as is the case with the one presented in Listing 4.4 (see Appendix A.4 for the full specification). At this point the ontology is ready to be used, in the case of SCARP, ready to be queried. The ontology can also be exported to be used in other tools (e.g. Prot´eg´e).
The achieved ontology contains the RUS representation of the Add product to cart use case (as presented in Figure 4.5), enhanced with the types information. Combining this information with OWL’s query capabilities establishes the basis to apply inference techniques.
The ontology generation uCat plugin was implemented, to support parametrization and gener- ation of OWL ontologies, by combining the previously extracted information. The users have the possibility to define both the name and the Uniform Resource Locator (URL) to identify the elements in the ontology. Figure 4.9 shows the user interface for this plugin.
After selecting the option to create the ontology, the tool automatically creates and shows a graphical representation of the ontology. However, the representation is only useful when consid- ering small use case examples. When considering several use cases, the diagrams tend to become too complex. In any case, the main objective is to process it automatically. The tool provides also the possibility to see the source code of the generated ontology, in RDF/XML. Generating
the ontology is required in order to proceed with SCARP.
Prefix : j .0: < http :// www . url . com / R e q u i r e m e n t s / > O n t o l o g y : < http :// www . url . com / Re quirements > A n n o t a t i o n P r o p e r t y : rdfs : c o m m e n t D a t a t y p e : rdf : P l a i n L i t e r a l O b j e c t P r o p e r t y : j .0: s e l e c t s A n n o t a t i o n s : rdfs : c o m m e n t "1" O b j e c t P r o p e r t y : j .0: shows A n n o t a t i o n s : rdfs : c o m m e n t "2" Class : j .0: Object Class : j .0: Actor I n d i v i d u a l : j .0: p r o d u c t Types : j .0: Object I n d i v i d u a l : j .0: syst em Types : j .0: Actor Facts : j .0: shows j .0: p r o d u c t I n d i v i d u a l : j .0: user Types : j .0: Actor Facts : j .0: s e l e c t s j .0: p r o d u c t (...)