Information Technology Reference
In-Depth Information
design alternatives are resolved. Here the modeler can make use of all available
support for working with i models such as label propagation algorithms for com-
puting overall satisfaction of softgoals [ 16] . The second, automated step generates
a Matlab/Simulink skeleton model from the i model. Since the conceptual model
behind block diagrams and thus Simulink models is rather simple, the matching
of concepts is straight forward. Most importantly, various i relationships such as
is-part-of, decomposition, and means-ends are mapped on the nesting of correspond-
ing blocks. Resource and task dependencies result in signals that are exchanged
between components. And goals and softgoals are mapped to model verification
or simple model information elements as suitable hints for the developer of the
mathematical model. This mapping is encoded in the generic feature of answer for-
mats [ 18] and thus can easily be adapted to accommodate any other formalism in a
different (interdisciplinary) setting. Eventually, an interactive step allows the engi-
neer to incorporate existing hardware and platform components into the skeleton by
replacing some of the generic empty blocks. For a concrete SME, there are poten-
tially libraries of sensor and actuator components that are usually combined with a
particular hardware platform (such as an RCP system).
Thus regarding the development process, the SME derives the decision for a
particular platform from the non-functional requirements on costs, environment
conditions, available installation space, safety and reliability constraints, scalability
etc. [ 31] . Accordingly, suitable controller solutions can be considered [ 10] . Since
due to the complexity of real-time constraints often only simulations can reveal the
best choice, the engineer might choose to create several different variants (in paral-
lel or iteratively) to be evaluated during the later development that from here on can
proceed as usual.
3.3 Experience-Based Domain Model Evolution
The previous section has described the intended process an SME has to follow for
a new customer request. In addition to this customer-driven activity, the SME must
strategically manage the knowledge and experiences it gains throughout many indi-
vidual customer projects. The domain model is a suitable means to structure this
knowledge and have it influence the development immediately. But the usefulness
of the domain model depends heavily on its adequacy for supporting the day-to-
day work of the engineers. Neither overly large nor too small domain models are
helpful. In the first case eliminating the unnecessary parts takes too much time
and in the second case known information needs to be added over and over again.
Instead, a domain model must be continuously tailored to the particular needs of
the SME. Concrete SMEs will specialize a domain model with regard to the par-
ticular methods, tools, and experiences available to them, e.g. particular sensors
and actuators. Other sources for changes to the domain knowledge are advances
in technology. But the most interesting changes are the ones that result from cus-
tomer projects over the years. These changes lead to an evolution of the artifacts
Search WWH ::




Custom Search