Enabling multi-stakeholder cooperative modelling in automotive software development and implications for model driven software development

This source preferred by Keith Phalp

Authors: Grimm, F., Phalp, K.T. and Vincent, J.

http://eprints.bournemouth.ac.uk/11347/

http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-376/paper4.pdf

Start date: 30 June 2008

Publisher: CEUR-WS

Place of Publication: On-line

One of the motivations for a model driven approach to software development is to increase the involvement for a range of stakeholders in the requirements phases. This inevitably leads to a greater diversity of roles being involved in the production of models, and one of the issues with such diversity is that of providing models which are both accessible and appropriate for the phenomena being modelled. Indeed, such accessibility issues are a clear focus of this workshop.

However, a related issue when producing models across multiple parties,often at dierent sites, or even dierent organisations is the management of such model artefacts. In particular, different parties may wish to experiment with model choices. For example, this idea of prototypingprocesses by experimenting with variants of models is one which has been used for many years by business process modellers, in order to highlight the impact of change, and thus improve alignment of process and supporting software specications. The problem often occurs when such variants needed to be merged, for example, to be used within a shared repository.

This papers reports upon experiences and ndings of this merging problem as evaluated at Bosch Automotive. At Bosch we have dierent sites where modellers will make changes to shared models, and these models will subsequently require merging into a common repository. Currently, this work has concentrated on one type of diagram, the class diagram. However, it seems clear that the issue of how best to merge models where collaborative multi-party working takes places is one which has a significant potential impact upon the entire model driven process, and, given the diversity of stakeholders, could be particularly problematic for the requirements phase. In fact, class diagrams can also be used for information or data models created in the system analysis step. Hence, we believe that the lessons learned from this work will be valuable in tackling the realities of a commercially viable model driven process.

This data was imported from Scopus:

Authors: Grimm, F., Phalp, K., Vincent, J. and Beier, G.

http://eprints.bournemouth.ac.uk/11347/

Journal: CEUR Workshop Proceedings

Volume: 376

ISSN: 1613-0073

Summary. One of the motivations for a model driven approach to software development is to increase the involvement for a range of stakeholders in the requirements phases. This inevitably leads to a greater diversity of roles being involved in the production of models, and one of the issues with such diversity is that of providing models which are both accessible and appropriate for the phenomena being modelled. Indeed, such accessibility issues are a clear focus of this workshop. However, a related issue when producing models across multiple parties, often at different sites, or even different organisations is the management of such model artefacts. In particular, different parties may wish to experiment with model choices. For example, this idea of prototyping processes by experimenting with variants of models is one which has been used for many years by business process modellers, in order to highlight the impact of change, and thus improve alignment of process and supporting software specifications. The problem often occurs when such variants needed to be merged, for example, to be used within a shared repository. This papers reports upon experiences and findings of this merging problem as evaluated at Bosch Automotive. At Bosch we have different sites where modellers will make changes to shared models, and these models will subsequently require merging into a common repository. Currently, this work has concentrated on one type of diagram, the class diagram. However, it seems clear that the issue of how best to merge models where collaborative multi-party working takes places is one which has a significant potential impact upon the entire model driven process, and, given the diversity of stakeholders, could be particularly problematic for the requirements phase. In fact, class diagrams can also be used for information or data models created in the system analysis step. Hence, we believe that the lessons learned from this work will be valuable in tackling the realities of a commercially viable model driven process.

The data on this page was last updated at 04:49 on July 15, 2018.