Information Technology Reference
In-Depth Information
Payment
Security
Payment
Security
Pay Good
is-part-of
occupies
Software
Some+
Review
Team
Software
Engineer
Professio-
nal
Some-
Pay by
Credit Card
Pay by
Cash
Authorise
Credit Card
is-a
ins
QA
Engineer
Judy
Validate
Payment
Order
Payment
Fig. 4 Examples of structuring mechanisms: SA diagram [40] ( left ) and SR-module [21] ( right )
Research directions. Basically we foresee two types of structuring mechanisms:
domain-independent and domain-dependent.
Domain-independent. The last three proposals fall into this first category and
show a way to go. To sum up, the basic need is: (1) grouping dependencies
that are related; (2) grouping related intentional elements inside an SR diagram;
(3) defining submodels. Another related work could be analyzing if the aspect-
oriented approach could be integrated with them, since both types of modularity
constructs seem complementary. However, careful validation about usability of
the resulting proposal should be conducted.
Domain-dependent. The service concept as mentioned by Estrada is one example
of concept that may be introduced. If we try to abstract from the service-oriented
context to a general, open scope, we could think of introducing a generic struc-
turing mechanism able to be instantiated by any kind of concept, in a way that
this instantiation establishes: (1) the kind of i model elements that may take part
of the module; (2) the relationships that need to be fulfilled.
In both cases, the following issues must be considered:
Structuring mechanisms exist in virtually all modelling languages; therefore a
systematic literature review is needed to learn how they do it, and to try to align
to their principles. In particular, the analysis of the UML notion of package seems
amust.
The structuring mechanisms need to be introduced into the i metamodel in a
non-intrusive way. Then structuring mechanisms become first-class citizens in
the framework, whilst not interfering with the semantics of the intentional part.
There is a need of defining the semantics of: (1) the modules themselves; (2) the
module-combination operations (e.g., creation of a new module by the combina-
tion of existing ones); (3) the module application operation (i.e., the model that
results from applying the stepwise refinement step implied by a module, over
an element of the departing model). As essential part of this issue, the classical
model merging problem needs to be tackled [ 58] .
 
Search WWH ::




Custom Search