In this paper, we combine MOF-based software representations and description logic-based mechanisms for facilitating software reuse. All software representations (requirements speci cations, design models, code) arising from one project are combined in a software case and stored in a repository for later retrieval. For reuse purposes, we use requirements as search indexes. We map metamodel-based requirements speci cations to an ontology and use a Description Logic reasoner for classi cation. This makes implicit taxonomical relations explicit. The inferred taxonomical hierarchy is then used to compute the taxonomical similarity between the current (initial) requirements and those in the repository. Doing so, we retrieve software cases with a high reuse potential. This approach has already been validated in an industrial context.
The underlying goal of our work is to enable reuse of model-based software
development artifacts. For this task, we combine all artifacts that arise in the course
of a software development project in a \software case". A software case is a set
of interlinked models and code written in textual and graphical languages that
have their syntax de ned formally (normally with a metamodel or a context-free
grammar). The contents of a software case are manifested through the contained
requirements model, which is speci ed using a precise and semantic-oriented
requirements language. In this language, meaning of words is de ned by linking
them to WordNet [
The retrieval of similar software cases from the repository is a key
prerequisite for this reuse approach. In order to retrieve such similar software cases we
compare requirements models. This is based on the assumption that cases with
similar requirements models can have similar design models, too. The retrieval
uses a combination of di erent similarity measures [
Such an ontology-based similarity measure requires the representation of all software cases (more precisely their requirements models) in an ontology. One resulting advantage of representing them in an ontology is the availability of reasoning techniques provided by Description Logic (DL) reasoners like Pellet or Racer3. One of these reasoning techniques (namely classi cation) supports our similarity measure. The classi cation makes implicit relations between elements in the ontology explicit by changing the taxonomical hierarchy. These newly inferred relations can then be used by our ontology-based similarity measure.
The rest of this paper is structured as follows: Section 2 sketches the facilities Description Logics supply and elaborates on main questions that have to be answered when Description Logics are applied in a certain domain. In Section 3, we introduce the general reuse approach in which our ontology-based similarity measure is embedded and we describe the MOF-based requirements speci cation language (RSL). In order to realize the similarity measure we had to construct an ontology containing all requirements models, the related metamodel, and the linked elements from WordNet (see Section 4 for details). The use of classi cation as a reasoning technique for supporting software retrieval is explained in Section 5. Our ontology-based similarity measure uses this inferred taxonomic hierarchy (Section 6). Section 7 describes the validation experiments as well as rst results. Finally, the approach is discussed (Section 8) and a summary concludes the paper. 2
For our current task (ontology-based similarity measure), we need to select from a diverse range of modeling and reasoning facilities of Description Logic. It provides facilities to de ne concepts and roles (or sometimes called properties) between two concepts. A concept (given with a unique name) indicates the set of individuals that belongs to it, and a role indicates a relationship between concepts. Concepts and roles are combined via constructors to so-called descriptions. Typical constructors are those of ALCHIF , i.e. Attributive Language with universal restrictions, existential quali cation, concept intersection (ALC), role hierarchy (H), inverse roles (I), and functional properties (F ). With these constructors, one can de ne a specialization relation between concepts, which provides superconcepts and subconcepts in a taxonomy, i.e. general or speci c concepts. Furthermore, a Description Logic allows to distinguish between primitive (i.e. necessary) and de ned (i.e. necessary and su cient) concepts, indicated with implies and equivalent, respectively. If several somehow combined roles are su cient for a concept, an individual who ful lls such roles would be part of the set the concept describes. If an instance belongs to a concept, the instance ful lls the necessary roles of that concepts.
Given such modeling facilities, DL reasoners provide reasoning techniques.
Examples are (see www.w3.org/Submission/owl11-tractable/ or [
{ Instance Checking: Given an individual a and a concept A, verify whether a is an instance of A. { Ontology Consistency: Check whether a given ontology is not contradictory. { Concept Satis ability: Given a concept A, verify whether the description of
A yields a non-empty set of individuals. { Conjunctive Query Answering: Given an ontology O and a conjunctive query q, return the answers of the query with respect to O.
Generally, when ontologies should e ectively be applied in a task, like here in ontology-based similarity computation, four design decisions are concerned: 1. What reasoning techniques should be used for supporting the solution of the task? In our case, classi cation is used (see Section 5 for details). 2. What entities should be mapped to the ontology? In our case, what elements of a software case are relevant for realizing the reasoning technique? Section 3 introduces the main elements of a software case and Section 4 explains the mapping to the ontology. 3. What concepts should be modeled as de ned concepts and which should be necessary? Especially de ned concepts enable reasoning tasks (Section 4). 4. Which logical language should be used for solving the task (see Section 4 for details)? This comes from previous decisions which impact the expressiveness of the language and computational e ciency. 3
Figure 1 shows an example of a software case. Elements of the requirements model within the software case (R) are interlinked with appropriate elements of the design model (D), which, in turn, are re ected in code (C). Design and code form a solution to the software problem manifested by the requirements. The initial requirements for a new problem (Q) can be compared with the requirements models of already existing software cases. Thus, the requirement models serve as indexes to the design models which facilitates searching and retrieval of past solutions that can be applied to the current problem. For the indexing mechanism to work properly we have designed a special-purpose Requirements Speci cation Language (RSL). Its syntax contains detailed constructs which allow for automatic comparison and transformation to the design models.
RSL enables two scenarios of software development: constructing and storing a software case, and retrieving a software case. When starting a new software project, initially we create its requirements model (see R21 in Figure 1). The model contains the description of the application logic with a separate description of the problem domain. Such a complete requirements model written in controlled language, is automatically transformed into the design model (see D21). This model can be manually updated to conform to certain non-functional constraints. Then, the code (see C21) is generated, which includes also some of the contents of the methods (the application logic). Finally, all these artifacts, together with the mappings generated between them are stored in a software case repository.
WordNet terminology
Q1
UserInterface:: UIComponent
«interface» CourseManagement:
IAddNewCourse + entersCourse() + wantsToAddCourse()
UI IAddNewCourse CourseManagement IChangeCourseData
IShowOwnedCourses «interface» CoursesServices:
ICourseList + builds(CourseListDTO)
ICourseList
ICourse BusinessLogic:: CoursesServices
«interface» CoursesServices:
ICourse + registers(CourseDTO) + verifies(CourseDTO)
D21
C21 course manager :course manager wants to see course list()
UIComponent :UIComponent
UI :UI
«interface» IShowExtendedCourseList :IShowExtendedCourseList «interface» ICourseList :ICourseList wantsToSeeCourseList() showsCourseList() builds(CourseListDTO) package coursesServices; interface ICourse { void registers(CourseDTO c); void verifies(CourseDTO c); } package courseManagement; interface IAddNewCourse { void entersCourse(); void wantsToAddCourse(); }
After some time, when we start a next project, we write an initial requirements model which is used to build a query (see Q1) to search for past solutions that can be reused. The query engine compares the query with the requirements models of past software cases. The most similar software cases or their parts are picked by the team and copied to the current workspace for merging with the current project. After merging, the newly created software case can be stored in the repository for further reuse.
Figure 1 explains the details of RSL. It shows three use cases (see boxes with tabs within Q1 and R21) which are the basic units of functionality in RSL. Use cases have their detailed representations in the form of textual scenarios (graphical versions also can be used). Every such scenario is a sequence of numbered Requirements
Requirement
UseCase
UseCase +scenarios 0..*
RequirementRepresentation ConstrainedLanguageScenario +subject 1
PhraseHyperlink *
Subject +scenarioSteps 1..*
1..* SVOSentence
PhraseHyperlink *
Predicate +1verbWithObjects
Project specific vocabulary
Terminology
Phrase
VerbPhrase 1 1
1
SimpleVerbPhrase
sentences in the SVO grammar { consisting of a subject (S), a verb (V) and one
or two objects (O), e.g. System shows course list. Actually, scenario sentences are
not pure text but they are built of hyperlinks pointing to notions in a domain
vocabulary (e.g. course list ). These notions can have their de nitions speci c
to the system's problem domain. Notions can also contain domain statements
which are verb phrases associated with the given notion (e.g. show course list ).
An example domain vocabulary is shown in Figure 1 to the left of the scenarios.
In order to make requirements models comparable for reuse purposes, we have
to additionally link all elements of the domain vocabulary to one global
terminology, like WordNet [
To facilitate automatic transformations, the RSL syntax is de ned through
a meta-model in MOF. This was a natural choice which facilitates constructing
transformations to design models written in the MOF-based UML. It also
allows for mapping RSL to an ontology. For transformations we use the MOLA
transformation language (see [
A relevant fragment of the RSL metamodel expressed in MOF is presented in
Figure 2. The metamodel is composed of three parts, divided with metaclasses
constituting hyperlink relations. First part is the requirements part (left frame).
In RSL, requirements can be modeled as general requirements written in natural
language (not included in Figure 2) or as use cases with scenarios de ned in
constrained language. Scenarios (ConstrainedLanguageScenario4 metaclass) are
composed of SVOSentences. Every such sentence is composed of a Subject and
a Predicate which are in fact hyperlinks to de nitions of the proper phrases in a
4 With this font we will denote elements of the RSL metamodel.
vocabulary (center frame). The Subject points to a Phrase containing one Noun
and optionally one Modi er and one Determiner. The Predicate points to one of
the two VerbPhrase subclasses. It contains the VO(O) part of the sentence. If the
sentence contains only the direct object (SVO sentence), the predicate points to a
SimpleVerbPhrase. This subtype of VerbPhrase contains a Noun (inherited from
the Phrase) and an additional Verb added before the Noun (eg. ,,add user").
Phrases containing both the direct and indirect object (VOO) are stored in
a ComplexVerbPhrase. This subtype of the VerbPhrase links an instance of a
SimpleVerbPhrase (the VO part of the phrase) followed by a Preposition and an
indirect object (the Noun inherited from the Phrase, eg. ,,add user to user list").
In RSL, the vocabulary is project speci c and contains notions' and phrases'
de nitions characteristic to the current problem domain. All the words used
in the project-speci c phrases are summarized in a terminology (see the right
frame). The TermHyperlinks connect the Phrases and the Terms. Each Term links a
WordNet element (by referring to its ID) in order to de ne the terms's meaning
in a general context. WordNet is a sematic lexicon which currently consists
of more than 200.000 synonyms grouped in more than 100.000 synonym sets
(called synsets, see [
This three-level language infrastructure enables clear separation between the behavior speci cation (use case scenarios' steps) and the description of the domain (vocabulary). The third level { the terminology { de nes the meaning of words in a global context and thus gives the possibility to perform meaningful comparison of di erent requirements models.
For expressing design models within software cases, we use a subset of UML
elements de ned through a pro le. A design model is generated automatically
as a result of a transformation that takes a requirements model in RSL as its
source. The transformation procedure adds to the information contained in
requirements all the details of the technical solution: the architectural style, design
patterns, etc. In the example we present the results of a transformation from
requirements R21 to design D21. The example uses a 3-tier architectural model
as the transformation target. Use cases are transformed into interfaces of the
application logic layer and domain element are transformed into interfaces of
the business logic layer and also into data access objects. Sequences of scenario
sentences can be transformed into sequence diagrams on the architectural level.
For more details on the transformation rules see [
Validation e orts conducted in the industrial context proved that despite of
its very detailed meta-model, the language is readable and understandable for
its users (see [
Mapping the MOF-based Models to an Ontology
In order to use the classi cation facilities provided by DL reasoners we had to
represent the RSL metamodel, the requirements models and the linked
WordNet elements in an ontology using ontology languages like OWL [
The RSL metamodel consists of 127 classes, sub- and superclasses, and many associations between them. These classes and associations are represented in the ontology as follows: classes of the metamodel are represented with concepts, generalization relations are represented with specialization relations, and associations are represented with roles. Furthermore, the associations of a class in the metamodel de ne the class, i.e. if an object with such relations exists, then it belongs to that class and if an object belongs to a class it has the relations of that class (see Figure 3). The classes of the RSL metamodel are furthermore disjoint, because every element of a requirements model is an instance of exactly one class of the metamodel.
Although navigation across associations is bidirectional in the RSL metamodel, we do not use inverse roles in the ontology since the similarity computation only requires roles directing down from the concept representing the requirements model to the synsets of WordNet. Likewise, we avoided a role hierarchy because only a relatively at hierarchy of associations is given in the RSL metamodel. Finally, functional properties are not needed for de ning concepts because they relate a class to a primitive type not to another concept. Thus, we can use the DL language ALC instead of the more complex language ALCHIF . 4.2
The requirements models of speci c software cases are represented through instances of classes of the RSL metamodel. This is illustrated in Figure 4. The RSL metamodel can be found on M2 while the speci c requirements models are located on M1 (in the context of the MDA metamodeling layers). Thus, the SVO sentences de ned in a particular requirements model are instances of the class SVOSentence in the RSL metamodel. Please note that we represent these instances with further concepts in the ontology. They are mapped to subconcepts of the concepts representing the classes of the RSL metamodel. This is
M3 M2 M1
EMOF SDSL metamodel
RSL metamodel Requirements Model C1
Requirements Model Cn
WordNet
Represented in ontology illustrated in Figure 5 which shows a part of an ontology, which we created manually for illustration purposes. Concepts for SVO sentences are coded by a software case id starting with C and a readable string re ecting the text of the sentence (e.g. SVOSentenceC2GuestChoosesEquipment5). The concept SVOSentence is the superconcept of four SVO sentences contained in distinct requirements models.
As a result, the concepts representing the classes of the RSL metamodel form the upper part of our ontology. Thus, the part of the ontology representing the model from the M2 level is called upper model of the ontology. The concepts representing the elements of speci c requirements models from the M1 level are modeled as specializations of these concepts and form the lower part of our ontology.
We do not use individuals for representing the elements of particular speci cations because taxonomical relationships cannot be computed between individuals. In our approach this is the key to infer taxonomical relationships between the elements of requirements models, because the similarity is based on taxonomical relations.
Thus, each class of a speci c requirements model is mapped to a concept with a unique id as its name and the corresponding upper model concept as its superconcept. The concepts representing the elements of requirements models 5 With this font we will denote elements de ned in the ontology.
element from M2 level elements from M1 level Fig. 5. Concepts in the ontology representing classes from the M2 and the M1 level. (equivalent SVOSentenceC2GuestChoosesEquipment (and SVOSentence (some subject SubjectC2Guest) (some predicate PredicateC2ChoosesEquipment))) (equivalent PredicateC2ChoosesEquipment (and Predicate
(some verbPhrase SimpleVerbPhraseC2Choose))) (equivalent SimpleVerbPhraseC2Choose (and SimpleVerbPhrase (some verb PhraseVerbLinkC2Choose) (some object NounPhraseC2Equipment))) (equivalent PhraseVerbLinkC2Choose (and PhraseVerbLink
(some linkedVerb VerbC2Choose))) (equivalent VerbC2Choose (and Verb
(some termLinksToWordnetEntry ChooseSelectSynset))) (equivalent NounPhraseC2Equipment (and NounPhrase
(some noun NounLinkC2Equipment))) (equivalent NounLinkC2Equipment (and NounLink
(some linkedNoun NounC2Equipment))) (equivalent NounC2Equipment (and Noun
(some termLinksToWordnetEntry EquipmentSynset))) are related through roles de ned in the upper model. Furthermore, these roles de ne the requirements model concepts (see Fig. 6). Thus, not only necessary relations (i.e. subclass) but necessary and su cient relations are used for relating software cases. This modeling enables the reasoning techniques described in the Section 5.
This general mapping can be used to convert all elements of a requirements
model to our ontology. However, this is not necessary since RSL requirements
models contain some elements not relevant for our ontology-based similarity
measure like all TermHyperlinks in Figure 2 (see [
The WordNet metamodel consists of several classes like Synset, Wordform, Gloss etc. NounSynsets are related via the relation hyponym and hypernym in a taxonomy. Classi cation only requires this taxonomical relation between synsets and the fact that synsets are distinct. Thus, we only map synsets from WordNet. They are represented with concepts and the synset taxonomy is represented with the subconcept relation.
The role termLinksToWordNetEntry relates each term of a requirements model to a synset (see Fig. 6). However, it is not necessary to map all synsets of WordNet (i.e. almost 117.000) into the ontology. For our purposes, it is only necessary to map the synsets that are linked by a term and all the predecessors of these synsets in the synset taxonomy. Synsets have only taxonomical relations between (implies ChooseSelectSynset VerbSynset) (implies FixSynset VerbSynset) (implies PersonSynset NounSynset) (implies ComputerUserSynset PersonSynset) (implies System_AdministratorSynset ComputerUserSynset) (implies UserSynset PersonSynset) (implies ConsumerSynset UserSynset) (implies CustomerClientSynset ConsumerSynset) (implies GuestSynset CustomerClientSynset) (disjoint ComputerUserSynset UserSynset) (disjoint ChooseSelectSynset FixSynset) themselves (i.e. no further roles). Thus, the taxonomical relations are necessary conditions, i.e. implies is used for describing them. Furthermore, synsets that are siblings are disjoint to each other (see Fig. 7). 5
In this section, we show what can be gained by classifying the constructed ontology. Using the mapping described in the previous section we can represent requirements models with concepts and roles in an ontology. However, the requirements models do not contain information that directly relates the diverse concepts of distinct requirements models. As a result, all concepts are direct subconcepts of upper model concepts. In Figure 5 e.g., all SVO sentences are direct subconcepts of the upper model concept SVOSentence. In this initial ontology, only the synset taxonomy provides a hierarchical structure (see Fig. 8, left side).
Figure 8 shows the SVO sentences from Figure 5 plus some additional concepts but after classi cation. The synset taxonomy provided by WordNet and the fact that the Pre-classification: Post-classification: c1 c2 Distance (c1, c2) = 2 Tax-Sim (c1, c2) = 0.644 c2 c1
Distance (c1, c2) = 1 Tax-Sim (c1, c2) = 0.761
Distance (c1, c2) = 2 Fig. 8. Left side: synset taxonomy mapped from WordNet. Right side: cutout of inferred hierarchy: classi cation results are emphasized in gray and blue font. concepts representing a requirements model are de ned concepts and thus, strongly related between each other, allow for the classi cation described in the following.
Our mapping of RSL metamodel and requirements models enables a DL reasoner to use the synset taxonomy in order to classify the concepts of the requirements models, i.e. to compute, which concepts are equivalent (Fig. 8, upper part in gray marked by ) or, which concepts can be taxonomically structured (Fig. 8, lower part in blue). Relations of the synset taxonomy are propagated one by one to the subjects of requirements models of C1, C2, C3, and C4. Namely, SubjectC3Client and SubjectC4System Administrator are subconcepts of the concept SubjectC1Person due to the fact that CustomerClientSynset and System AdministratorSynset are subconcepts of PersonSynset, respectively. Thus, after classifying the ontology, the taxonomy de ned in WordNet is also re ected in the concepts representing the speci c requirements models. Even more interesting is the impact on structural concepts like SVOSentence. In Figure 8 for example, the SVO sentences of case C2 and C3 are classi ed as subconcepts of the SVO sentence of case C1. This is due to the fact that in both sentences a speci c type of person (being either a guest or a client) chooses an type of equipment. Since the SVO sentence of C4 is about xing a printer instead of selecting one, the sentence is not a subconcept of the SVO sentence of case C1. Thus, classifying the ontology makes these taxonomical relations explicit. Please note that Figure 8 shows only parts of this information.
This kind of classi cation takes the structure, i.e. the roles between the concepts, into account. Through this classi cation, a di erent taxonomical distance between the concepts of requirements models is introduced and will lead to di erent similarities. Before classifying the ontology, the taxonomical distance between all SVO sentences was equal (see Fig. 5). Classi cation reduces the distance between SVO sentences of C2 and C1 while it increases the distance between sentences of C2 and C4 (comp. Fig. 5 and Fig. 8). This e ect of classi cation on distances is sketched in the box in Figure 8. By using the WordNet link and the provided mapping, our similarity measure considers the meaning de ned in the requirements models. 6
Once the ontology has been constructed and classi ed we use the inferred taxonomical hierarchy for computing similarity values. For this purpose, a query is compared with each requirements model contained in the repository where the query is a (potentially partial) requirements model. The goal of similarity computation is to get a value between 0 and 1 that indicates the similarity between a query and a software cases; 0 denoting no similarity and 1 denoting that the query is completely contained in the software case.
Please note that our measure di ers from most similarity measures. Typically,
similarity measures positively correlate with the amount of commonality between query
and case and at the same time negatively correlate with the amount of di erence (see
[
The assumption made here is that the taxonomical distance between two concepts
can be the basis of such a similarity measure. Our similarity measure compares pairs of
concepts in the classi ed taxonomy. This comparison includes both the concept
placement in the taxonomical hierarchy (distance-based similarity ) and the roles and role
llers that the concepts de ne (role-based similarity ) (see [
For computing the distance-based similarity between two concepts c1 and c2, the distance of both concepts to the least common subsumer (LCS) is computed, both values are added and a value describing the distance-based similarity is returned: 1. lcs = leastCommonSubsumer(c1, c2) 2. distance1 = pathLength(c1, lcs) 3. distance2 = pathLength(c2, lcs) 4. distance = distance1 + distance2
1 5. return ln(distance+e) The algorithm has the following properties: The division ensures values between 0 and 1. The further away the concepts are from each other, the smaller the similarity value gets. The logarithm ensures higher similarity values for low distances, than, for 1 example, distance would provide. Finally, the addition of e ensures a similarity value of 1 for distance 0, i.e. if c1 and c2 are in fact the same concept. The box in Figure 8 illustrates the e ect of classi cation on the distance-based similarity measure. By classi cation the distance between c1 and c2 is reduced from 2 to 1. The associated similarity values of the distance-based measure are also given in the gure.
The basic idea of role-based similarity is that the similarity of two concepts depends on the similarity of their subgraphs. When comparing roles, their most important aspects are their llers: concepts or concrete domains that specify the value of a role. When comparing two concepts, the function of role-based similarity is recursively applied. The recursion terminates when two concepts without roles are compared; their similarity is given by the distance-based similarity function. The roles of both concepts are recursively compared and similarities are summed up for every concept. A value describing role-based similarity is returned: 1 means both concepts have the same roles, and the smaller the value, the less their roles have in common.
Both aspects can be computed independently from each other. Therefore, we dened two algorithms, one computing the distance-based similarity between two concepts and another one comparing the common roles of concepts. The similarity between two concept de nitions is the sum of the distance-based similarity and the role-based similarity divided by two. 7
During the development of our approach we used small examples for testing and illustration purposes (see previous sections). In order to evaluate the presented similarity measures we conducted two types of experiments. On the one hand, we produced several small software cases by varying speci c elements e.g. of a sentence, in order analyze the impact of these modi cations. On the other hand, we applied the approach to software cases produced by software development teams in the industrial context (see Acknowledgements).
Technical Setting. The RSL metamodel was implemented as part of a comprehensive
tool suite [
A JAVA-based converter maps the RSL metamodel and the requirements models to an OWL ontology by using the mapping described in this paper. For debugging the OWL ontology we use Protege. Protege also provides interfaces to the DL reasoners Pellet and Racer. For debugging inference behavior we apply Pellint.6 The similarity computation is a further JAVA-component developed by us. It traverses the classi ed ontology for computing similarity values as presented in Section 6. This similarity measure is combined with other measures and integrated in the above mentioned software development tool.
Experiments. Firstly, we created almost 50 small, arti cial requirements models. These models vary only in particular elements e.g. one word is added, one word is replaced by a more speci c term, one sentence is added etc.. Comparing the similarity values for these requirements models we could analyze the impact of particular modi cations in detail. Furthermore, we could show that the ontology-based similarity measure computes the same similarity ranking for these test cases as considered plausible by us beforehand.
For applying the approach in a broader scale, 16 industrial software cases have been created by four software development organizations using the above mentioned tool. The application domains are in the area of internet banking, investment funds management, emergency systems, forestry systems, nancial contract systems, and funding systems. The requirements models contained 261 requirements written in RSL in total, which mapped to more than 30.000 de ned concepts. We were able to reduce the number of de ned concepts to about 8.000 by converting only concepts that are relevant for the ontology-based similarity computation (see Section 4).
In addition, 8 more partial requirements models were created. These models were
used to query the repository of the above mentioned cases. The development teams
were to determine the compliance of their understanding of similarity and the
computed measures. This was subject to UTAUT analysis [
As can be seen in Figure 4 the constructed ontology crosses the border between the
levels M1 and M2. This is due to the fact that the instance-of relationship between an
element on Level M1 (e.g. a speci c SVO sentence) and its class (like the RSL class
SVOSentence) on Level M2 is mapped to a specialization relation of appropriate
concepts in the ontology. Or, as we introduced it in Section 4, the metamodel of RSL is
represented as an upper-model in the ontology. By doing so, de nitions of the metamodel
can be used within the ontology, i.e. by reasoning techniques. This mapping is slightly
di erent from those described in [
are not subconcepts of the root Thing but of speci c concepts like SVOSentence or VerbPhrase. The preclassi cation provokes that the taxonomical distance between different elements is higher than it would have been without preclassi cation where all elements are subconcepts of Thing.
Other reasoning techniques like Instance Checking could be used for verifying if a given requirements model complies to the RSL metamodel (i.e. model con rmation). However, this is not needed in our case, since the software development tool mentioned above already ensures that each requirements model is compliant with the RSL metamodel.
Some approaches allow the user to use natural language (e.g. [
ORE [
In this paper, we presented our new combination of MOF-based requirements models and reasoning techniques from Description Logic for supporting the reuse of similar software cases. We showed how we represent the MOF-based models in an ontology. Special in our approach is that we combine elements from di erent levels (i.e. M2 and M1) within one taxonomy in our ontology. Doing so, we are able to infer taxonomical relations implicitly contained in requirements models. These inferred taxonomical relations are used by our ontology-based similarity measure. Current experiments using industrial software cases show promising validation results.
Acknowledgments. This work is partially funded by the EU: Requirements-Driven Software Development System (ReDSeeDS) (contract no. IST-2006-33596 under 6FP). The project is coordinated by Infovide, Poland with technical lead of Warsaw University of Technology and with University of Koblenz-Landau, Vienna University of Technology, Fraunhofer IESE, University of Latvia, HITeC e.V. c/o University of Hamburg, Heriot-Watt University, PRO DV, Cybersoft and Algoritmu Sistemos.