This post discusses how links between engineers and modellers/modelling tools can be improved, using an approach of visualising a modelling structure that mirrors the structure of the engineering product design. The main method for this is diagrammatic modelling.
Making the structure of a model be the same as the structure of the engineering component modelled turns 2 problems into one. This speeds up co-operation in prototyping of both the software model and the component. Both rapid prototyping and rapid application design/development involve iterative fast development with prototypes communicated. Requirements emerge gradually as part of this process, so early stage design can begin, in co-operation with life-cycle management, marketing accounts etc. To get full benefit from this all staff who are part of this design process, manufacturing, management, and life-cycle management need to be able to access the models. The longer term aim is to enable direct modelling/prototyping of this by customers of the modelling tool e.g. engineers/end-user programmers. Such a system documents itself as the structure of the engineering product and software model are displayed/visualised.
Integration of information representation UML/Doors (http://www-01.ibm.com/software/awdtools/doors/productline/) is progress towards this. Also a user interface is required that makes it easier for engineers to model using such a combined UML/Doors solution
Despite object-oriented programming techniques being heavily influenced by the approach used by engineers for Bill of Materials/Product Data Structure modelling this link has become difficult. Much of object-oriented programming was developed before graphical user interfaces became practical and common. So objects/classes are often represented mainly by text with visualisation/representation being added as an afterthought. This is not useful for engineers who are used to objects being physical things, or at least diagrams. A further problem has been an over-emphasis on encapsulation (hiding an objects' details, while creating an interface for its use), and re-use. This can lead to errors due to re-use of objects that are not fully understood. So the classes/objects need to be visualised, even if the user does not intend to change their contents, so the user of objects has sufficient understanding of how to use them.
The above steps would improve the link and co-operation between engineers and modellers/models.
This blog is about my PhD research (now finished) at University of the West of England into User Driven Modelling. This is to make it possible for people who are not programmers to create software. I create software that converts visual trees into computer code. My web site is http://www.cems.uwe.ac.uk/~phale/. I'm continuing this research and the blog. My PhD is at http://eprints.uwe.ac.uk/17918/ and a journal paper at http://eprints.uwe.ac.uk/17817/.
Subscribe to:
Post Comments (Atom)
3 comments:
I get the point of turning two models into one - but it is more than just a desire, there needs to be a collaboration portal between the groups to enable direct modelling.
We are only doing this for processes at the moment, but you can get a gist of what we are at here
www.demoprocessmaster.com/main.html
Alan Crean
I've looked at your comments and this is of interest to me. I'm hoping to start a new project soon and would then be interested in your tool, which is very relevant.
Peter Hale
Hi Peter, my email is alan dot crean at processmaster dot com.
drop me a line and we can get started
Post a Comment