This approach is based on creation of systems that can be customised to produce other systems and models, and translation from abstract diagrammatic representations to computer representations.The conclusion explains how this approach to modelling and end-user programming enables interoperability, and collaboration, and that this assists with Maintenance, Extensibility, Ease of Use, and Sharing of Information.
This methodology can be seen as an attempt to semi-automate knowledge acquisition and representation approaches such as the SEPA Funnel (Systems Engineering Process Activities) . This methodology was prototyped in the research that led to the User Driven Modelling/Programming Approach. This provides a translation process from Knowledge Acquisition to modelling (User Driven Modelling), and automated translation of model to software (User Driven Programming), and so takes this SEPA Funnel to a further stage of translation/transformation of the model/system design specification. This can be facilitated by using XML (eXtensible Markup Language) as a programming language, for the representation of data and formulae, and of the user interface e.g. XAML (eXtensible Application Markup Language).
The methodology suits top-down ontology and model creation e.g. from those responsible for the root item in a product data structure downwards, and bottom-up ontology development, e.g. alternative solutions, tagging of items to allow discussion and enable disambiguation, and agreement on terminology, and mapping of alternative names to each other. This dual approach is facilitated by the translation being provided in both directions.
This model-driven approach examines how links between engineers and modellers/modelling tools can be improved, by visualising a modelling structure that mirrors the structure of the engineering product design. This provides traceability for calculation and decision making in a more clear, structured and visualised way than the audit trail in spreadsheets. This work concentrates mainly on requirements (Airbus, Rolls-Royce), software, and HCI aspects of systems. The main method for this is diagrammatic modelling which was used in gathering requirements, and is also implemented within the modelling system developed.
Making the structure of a model be the same as the structure of the engineering component modelled, and visualising both turns two 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 for feedback and refinement.
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. This would make it possible for emergent properties of a system to become known.
Despite object-oriented programming techniques being heavily influenced by the approach used by engineers for Bill of Materials/Product Data Structure modelling this link is 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 not fully understood. So the classes/objects must be visualised, even if the user does not intend to change their contents, then the user of objects has sufficient understanding of how to use them. This would improve the link and co-operation between engineers and modellers/models. The advantage is that engineers can iterate back and forth between problem and solution, this avoids two risks - going straight to a solution too early, or the problem being so abstract that no solution is achieved. Rapid iteration that semi-automating of the system provides enables an improved chance for finding a good solution. This approach is particularly suitable to taxonomy tree structures, so is best applied for process modelling (business and engineering), product data and work breakdown structures, and scientific taxonomies/phylogenies.
A requirement for use of such a system by engineers (or business and science) is to eliminate or minimise the need for code writing. This then would enable engineers to create models by linking of formulae, as they do when using spreadsheets, but provide a more structured (tree based) representation and visualisation of model(s). To find alternative ways of representing models that do not require the user to write code it must be easier to interact with and change the models, and to share and develop information with colleagues. It would also be useful to more closely align and link UML, and code development environments. Too much need for coding leads engineers to lose influence on the system to be developed, as the model needs to be created by software experts who have less understanding of the engineering problem.
Conclusion
This work involved development of a system for creating systems. Advantages of this approach are Maintenance, Extensibility, Ease of Use, and Sharing of Information. The use of open standards and representation enables this system to interact and interoperate with other systems and enable collaboration. This makes this system a ‘white box’ which can interact with and be viewable to other systems rather than a proprietary ‘black box’. This systematic design and representation of engineering modelling systems, enables semi-automated translation. This enables rapid iteration around a cycle of knowledge acquisition, specification of the problem, prototypes, and alternate potential solutions. This assists with deciding when to adapt and re-use existing solutions and when to innovate.
Such a system could be used to rebuild the system engineering for aerospace capabilities at UWE, and is being developed further at Bath University. A further advantage of the approach outlined here is that it shows promise for use in the SALT (Sharing Approaches to Learning and Teaching) project and for the Tearfund disaster relief project, so the flexibility built into it makes the process applicable to problems for which it was not envisaged and designed. Although these tools can be regarded as software related, they are also and more importantly a way of empowering computer literate end-users (e.g. engineers) with the autonomy to collaboratively model problems more free of constraints of software development. This enables better collaboration across disciplines and more independent of management structure and hierarchy.
SEPA Funnel - http://www.umcs.maine.edu/~ftp/wisr/wisr9/final-papers/Barber.html - K. Suzanne Barber, Thomas J. Graser, and Stephen R. Jernigan.
Systems Engineering MSc Module Assignment - Main part - http://docs.google.com/View?id=dgp7zcg6_344cxn8sxhs - Appendix - http://docs.google.com/View?id=dgp7zcg6_352c8j2w5cg.
No comments:
Post a Comment