Information Technology Reference
In-Depth Information
As for the corporate glossary, common terms already in use include
“Use
Cases”, “Functional Test”, “Compatibility Test”
etc. These terms find their way
as wiki categories. Hierarchical relationships among categories are captured by
describing a category as a child of the parent category (e.g.,
“Test” ← “Functional
Test”
). Wiki articles are denoted as
bubbled
nodes (e.g.,
“Requirements analysis”
stands for an article which is categorised as
“Deliverable”
). The title of a node
behaves as an identifier, so that two
FreeMind
nodes placed differently but with
the very same title, stand for the same notion. This permits the
Content
graph
to be flattened as a
FreeMind
tree.
It can look odd to introduce articles at wiki inception since wiki's
raison
d'etre
is precisely collaborative article editing. Indeed, we do not expect too
many articles to be introduced at scaffolding time. However, the need to come
up with some articles might be known from the very beginning. The scaffolding
permits so by introducing a node whose title becomes the title of the wiki article.
For instance, the node
“Software design”
yields a wiki article with the namesake
title. Even more, some relationships might be known at the outset. For instance,
trace requirements made advisable to keep a hyperlink between the
“Purchase
entry test”
and the
“Purchase entry UC”
. This is depicted as an arrow between
the node counterparts.
Based on preliminary user feedback, we also consider article content to be
known at scaffolding time. This is realized as a child of the given article (together
with the
“info”
icon ). Fig. 3 illustrates the two options. The content of
“Purchase entry test”
is explicitly provided as the text of its child node. By
contrast, the content of
“Purchase rejection test”
is already available at the
company as a
Word
document.
FreeMind
permits to introduce hyperlinks as
node content (denoted through a small red arrow). This facility is used to our
advantage to link
“Purchase rejection test”
to the external document holding its
content. Likewise, corporate guidelines can find their way as wiki templates. So
far,
WSL
only supports
Word
documents (exported as
XML
). At deployment
time (i.e., when the
WSL
map is enacted), these external documents are turned
into either, article content or wiki templates. Fig. 6 provides a screenshot of the
main page as generated by the WSL engine. The rest of this section provides a
detail account of
WSL
expressivity.
4.2
WSL Concrete Syntax
WSL
abstract syntax is realized as a
graphical
concrete syntax. A mapping is
then set between elements of the abstract syntax and their visual counterparts
in
FreeMind
. These “visual counterparts” are set by the
FreeMind
metamodel.
Therefore, a set of mappings between elements of the
WSL
metamodel and
elements of the
FreeMind
metamodel is realized. Additionally, some constraints
need to restrict the expressiveness of
FreeMind
to result in valid “scaffolding
maps” (i.e., compliant with the
WSL
metamodel).
FreeMind
metamodel (see fig. 4). A Map is a compound of Nodes.Nodes
have a title and might hold a
link
to an external document (local or remote) as
well as a set of properties mainly referring to rendering concerns. For instance,
