Goal-Based Domain Modeling as a Basis for Cross-Disciplinary Systems Engineering - Intentional Perspectives on Information Systems Engineering - page 92

suits the new control system. But the similarity search automates the identification
of finalized projects containing potentially reusable artifacts and thus reduces sig-
nificantly the number of finalized projects the engineer has to inspect. This in turn
increases the chances that all reusable artifacts are actually found and provides the
senior engineer with more time to decide on the actual reusability. Additionally, even
if a component is not reusable the project documentation may allow the engineer to
better estimate the required efforts and thus also leads to a better cost calculation.
The domain model forms a necessary premise for the similarity search since it
ensures consistency of modeling across several projects. Two projects are called
similar, if indications exist that parts of the control system software of one project
could be reused for the other. An indication is given, if parts of the requirements
models of the projects match. Since the requirements models are (via i ∗ )formal-
ized in the knowledge representation language Telos [ 26] , we can employ for this
comparison task the deductive object manager ConceptBase [ 18] that implements
Telos. The selection is based on pre-defined and ad-hoc comparison queries. The
pre-defined comparison queries focus on the particular domain model. For example,
a query can be formulated that computes the kind of fuel the combustion engine
in a particular project uses by identifying all task elements that are parented by
“combustion engine block” and are or-decomposed from the “fuel” task element
(for Telos details see [ 39] ). This returns a subset of “diesel”, “gasoline”, “gas”,
and “biodiesel” (see Fig. 4 upper right, next to “customer”) plus potential project-
specific extensions. The returned set for the current project can then be compared
with the returned sets for earlier projects. Up to now, eleven of such domain model-
specific queries are pre-defined for the combustion engine domain model shown in
Fig. 4. Additionally, the user can extend this set by ad-hoc queries targeting project-
specific extensions. The aggregation of the weighted answers of all queries results
in an overall ranking for each project. The projects containing similarities within the
highly weighted areas of the new project's requirements model are ranked higher.
Accordingly, these are the models the engineer should investigate first.
The requirements model for the concrete customer problem together with the
results of the similarity search enable the SME to outline a first solution idea that
especially indicates which components can be reused and which ones have to be
developed newly. On top of these findings, the SME can produce a reliable and
hopefully competitive cost calculation that is sent as an offer to the customer.
3.2.3 Integration with Further Development
Only when the customer accepts the offer of the SME, the development process
continues. As elaborated before and in contrast to normal software development,
after capturing the requirements, the control system engineers continue the devel-
opment by building mathematical models. A continuous model-based development
approach has to map the requirements to an initial Matlab/Simulink model that then
can be enriched with the mathematical equations suitable for the particular prob-
lem. By again building on the formalization in Telos, partially automated support
for this transformation is provided [ 40] . During a first manual transformation step,