An important quality aspect for conceptual models (such as {_ models) is the quality of textual labels. Naming conventions are aimed to make sure that labels are used in a consistent manner. We present a tool that checks automatically whether a textual label in an {_ model adheres to a set of naming conventions. This does not only help to enforce the use of a consistent labelling style, it also helps to detect modelling errors such as goals in {_ models that should be softgoals (or vice versa).
{_ is a frequently used visual language for modelling the social relationships
between actors. The language contains graphical symbols for various concepts (such
as goal or task) which have to be used correctly if the model should be useful.
In [
We believe that a way to reduce such problems can be to use a consistent labelling style throughout the model. By forcing the modeler to think whether an element should be named \reduce waste" or \waste to be reduced", he or she is also forced to think whether the concept should be represented as a task or as a goal. Furthermore, the usage of common labelling styles can reduce the di culty to understand a model.
[
Resource
subject + \be" + verb softgoal [topic] verb + object
Noun
[
Result be correct
Improve [IT skills] Fill out application form
Con rmation
In the above tables, parentheses are used to denote optional elements; brackets are part of the label. To our best knowledge, current {_ modelling tools are not able to validate labels with respect to such conventions. However, there is a great amount of work on checking the labels in business process models. When developing our approach for style checks of {_ labels, we made use of the experiences with tools developed in this context (see [5{7]; the last reference contains an overview on more papers on the topic).
Although the styles shown in the above tables seem to be quite similar, a closer look shows that there are subtle di erences. Let's assume that a Resource label should be a \name of the object". This is more restrictive than saying it should be a noun, because nouns can be accompanied by articles, attributive and adjectives. In that case \mail" would be valid, but \sent mail" won't. Similarly, if we would require that a Softgoal should rather be labeled with a quality attribute than with a Goal syntax, \usable" would be valid, but not \User interface is usable". For this reason, we decided to regard a label as having the correct style if it adheres to the following superset of style rules:
Syntax object + passive verb quality attribute (+ object) (+ complement) goal syntax (+ complement) verb (in present form) + object (+ complement) object
3 3.1
Third-Party Frameworks for Natural Language Processing
To analyse, process and validate a label, we rst need to know what kinds of
words it contains. This process is called part-of-speech (POS) tagging.
POStaggers typically combine lexical databases with statistical algorithms to
determine the kind of a word, a part-of-speech or even a phrase within a sentence[
Our Approach Our goal is to compare the label of an {_ model element to the style rules for this element type. For this purpose, we make use of the Stanford Parser, a statistical parser that works out the grammatical structure of sentences. It can recognize which groups of words go together as phrases and which words are the subject or object of a verb2.
The parser provides viable results when the input is a complete sentence. However, this is unfortunately often not the case for a label in an {_ model. Assume that a Resource is labeled with \log message". This phrase is ambiguous, because \log" can be either a verb or a subject. To determine the correctness, the parser needs more context information, which we can derive from the element type. By analysing \log message" only, the parser will nd that \log" is a verb and \message" is a noun. In that case, it cannot recognize that this phrase is 2http://nlp.stanford.edu/software/lex-parser.shtml 3http://www-nlp.stanford.edu/ 4http://wordnet.princeton.edu/ 5http://www.b ow.org/ an object which is valid for a Resource label. Similar problems exist with other element types. To deal with such problems, we have decided to add additional words to the labels, thus trying to create complete sentences.
Our general approach can be summarized as follows: First, we complement
the label with a pre x that depends on the element type such that for correctly
named labels, we get a complete sentence. For the label to be valid, the
resulting sentence has to be syntactically correct. In the next step, the Stanford
Parser processes the sentence and creates the so-called phrase structure tree of
the sentence. It assigns to each word a part-of-speech (POS) tag such as CC
(coordinating conjunction), DT (determiner), EX (existential there), IN
(preposition), JJ (adjective), NN (noun), VB (verb), VBN (Verb, past participle) and
VBZ (verb, 3rd person singular present)[
We de ne a pattern of valid sequences of POS tags for each type of modelling element. The label is regarded as valid if its POS tags match this pattern, allowing that the label may contain additional words after the pattern (this way both \Test database" as \Test database for consistency" would be regarded as a task).
We describe the style rules by a pattern in the Extended Backus-Naur Form. At rst, we describe the POS tags of an Object. Examples of valid objects and the corresponding sequences of POS tags are:
bank NN test run NN NN list of credit cards NN IN NN NN list of valid credit cards NN IN JJ NN NN summarized balance sheet JJ NN NN
NNSEQ := NN, fNNg; (examples: \bank", \test run") JNS := [JJ, fJJg], NNSEQ; (examples: \cheque", \valid cheque") OBJECT := [DT], JNS, [IN, JNS]; (example: \a complete list of valid credit cards") Resource style check Given a label L, we complement it with the pre x \There is a" and the su x \." (period), i.e. the parser analyses the (potential) sentence \There is a L." . We conclude that the label is correct, if L matches the pattern of an object.
We use \There is" as pre x in order to increase the probability of identifying \is" as the only verb of the sentence. For instance, if we have to validate the label \summarized balance sheet", \summarized" (without this pre x) would be wrongly tagged as verb.
Task style check Given a label L, the parser analyses the (potential) sentence \I L."
TASK := VB, [IN], OBJECT; (examples: \Test database", \Add to score") Goal style check A Goal label is required to match the pattern:
GOAL := OBJECT, (\is" j \are"), VBN; (example: \Results are corrected") Softgoal style check Because there are two competing rules, the validation is done in two steps. First, the label is validated by the \quality attribute" rule. For this purpose, the parser analyses the (potential) sentence \It is L.". Second, it is checked whether the label is a goal, followed by an arbitrary complement.
L is required to match the pattern of a Softgoal (possibly followed by an arbitrary complement): SG := QA j GOAL; (quality attribute or goal) QA := JJ, fJJg, [OBJECT]; (example: \inexpensive delivery")
Fig.1 shows the validation result of a model from our tool within the {_ modelling tool openOME 6.
6http://www.cs.toronto.edu/km/openome/
In this paper, we presented a set of POS tag patterns that can be used to validate the adherence of {_ labels to a set of style recommendations. We derive the correctness of a label from its element type and the related style recommendation. We achieved reliable results by complementing the given (normally short) labels to (potentially) whole sentences.
These patterns have been implemented using the tool qap that provides an API to WordNet and the Stanford Parser. Our tool prototype is both extensible as con gurable. It is easy to change our patterns, remove or add new ones. Though we tested our patterns within openOME, there is no technical dependency between openOME and our prototype. qap and our style checks can be used with any other tool as well.
A drawback we observed quite often is an incorrect spelling which aws the reliability of the checks. For instance, \relevant advices" will lead to another result than \relevant advises" because the POS tagger cannot identify the word correctly.
In future, we plan to add additional linguistic analysis functionality to our tool in order to make more sophisticated analysis possible.