Enabling multi-stakeholder cooperative modelling in automotive software development and implications for model driven software development
Authors: Grimm, F., Phalp, K., Vincent, J. and Beier, G.
Journal: CEUR Workshop Proceedings
Volume: 376
ISSN: 1613-0073
Abstract: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.
https://eprints.bournemouth.ac.uk/11347/
Source: Scopus
Enabling Multi-Stakeholder Cooperative Modelling in Automotive Software Development and Implications for Model Driven Software Development
Authors: Grimm, F., Phalp, K.T. and Vincent, J.
Conference: MDABIZ 2008: 1st International Workshop on Business Support for MDA co-located with TOOLS EUROPE 2008
Dates: 30 June-4 July 2008
Publisher: CEUR-WS
Place of Publication: On-line
Abstract: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.
https://eprints.bournemouth.ac.uk/11347/
http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-376/paper4.pdf
Source: Manual
Preferred by: Keith Phalp
Enabling Multi-Stakeholder Cooperative Modelling in Automotive Software Development and Implications for Model Driven Software Development
Authors: Grimm, F., Phalp, K.T. and Vincent, J.
Conference: MDABIZ 2008: 1st International Workshop on Business Support for MDA co-located with TOOLS EUROPE 2008
Publisher: CEUR-WS
Abstract: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.
https://eprints.bournemouth.ac.uk/11347/
http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-376/paper4.pdf
Source: BURO EPrints