You are on page 1of 6

User Driven Modelling - Background Information

Explanation of the Problem to be Addressed Research Aim
This research arises out of work to create systems to facilitate management of design and cost related knowledge within those organisations, with the aim of using this knowledge to reduce the costs of manufacturing products. This thesis identifies ways that problems arising from the model development process can be addressed by a new way of providing for the creation of software. With experience from projects, which have used a combination of proprietary software solutions and bespoke software, it is possible to identify the approach of User Driven Programming (UDP). This research unites approaches of Object Orientation, the Semantic Web, and Relational Databases and event driven programming. The approach encourages much greater user involvement in software development. Software development is time consuming and error prone because of the need to learn computer languages. If people could instruct a computer without this requirement they could concentrate all their effort on the problem to be solved. This is termed User Driven Programming (UDP) within this thesis, and for the examples demonstrated the term User Driven modelling (UDM) is used to explain the application of user driven programming to model development. This research aims to create software that enables people to program using visual metaphors. Users enter information in a diagram, which for these examples is tree based. The program translates this human readable representation into computer languages.

Research Approach
This research demonstrates how a taxonomy can be used to automatically produce software. This technique is most suitable at present to modelling, visualisation, and searching for information. The thesis explains the technique of User Driven Model Development that could be part of a wider approach of User Driven Programming. This approach involves the creation of a visual environment for software development, where modelling programs can be created without the requirement of the model developer to learn programming languages. The theory behind this approach is explained and also the main practical work in creation of this system. The basis of this approach is modelling of the software to be produced in Ontology systems such as Jena and Protégé. The research applies this User Driven technique to aerospace engineering but it should be applicable to any subject. The basis of the research is the need to provide better ways for people to specify what they require from computer software using techniques that they understand instead of needing to take the intermediate steps of either learning a computer language(s) or explaining their requirements to a software expert. These intermediate steps are expensive in terms of time, cost, and level of misunderstanding. If users can communicate intentions directly to the computer they can receive quick feedback and be able to adapt their techniques in a quick and agile way in response to this feedback. An absolute requirement of this research is that no compromise is made in the openness of the source code of the application or of the information represented within the application. It is proposed that software and information represented by the software be separated but represented in the same open standard searchable way. This makes 'meta-programming' possible. Meta programming is writing of programs by other programs. The purpose of this is to provide a cascading series of layers that translate a relatively easy to use visual representation of a problem to be modelled into code that can be run by present day compilers and interpreters. This is to make it easier for computer literate non-programmers to specify instructions to a computer without learning and using computer languages. To achieve this any layer of software must be able to read the code or the information represented in any other. Code and information are only separated out as a matter of design choice to aid human comprehension, they should be represented by the same languages and in the same way. The methods used for this representation and translation will be explained in the rest of this document.

The role of the developer would then become more that of a mentor and enabler rather than someone who has to translate all the ideas of the expert into code themselves. The research involves developing ways of automatically translating this information into program code in a variety of computer languages. and a software developer cannot have expertise in every domain to which software might apply. To achieve this visual editors are used to create and edit taxonomies to be translated into code. The research mainly concentrates on using the above technique for modelling. and event driven programming. The proportion of domain experts in a particular domain (aerospace engineering) for example who can develop their own programs is fairly low. Tim Berners-Lee defined the semantic web as 'a web of data that can be processed directly or indirectly by machines' http://www. Firstly it is necessary to find a way for people with little programming expertise to use an alternative form of software creation that can later be translated into program code. In . These communities could include both software experts. If more users of software are involved in creation of software and the source of the code is open this allows for the creation of development communities that can share ideas and code and learn form each other. So it is important to make it possible for software to be created using methods as close as possible to that which the domain expert normally uses. although others may investigate a natural language approach. but the proportion that are computer literate in the every day use of computers is much higher. the semantic web. A translation method can then be provided that converts this representation into program code in a number of languages or into a Meta-language that can then be further translated. u Criteria necessary for User Driven Model Development This chapter explains the factors necessary to make the User Driven Model Development approach later outlined possible. This is very important and useful for many employees that have insufficient time to learn programming languages. by providing templates to enable nonprogrammers to develop modelling software for the purposes that interest them. and visualisation techniques to create a human computer interface that allows non experts to create software. and enabling processing and searching of the information to provide a modelling capability.org/People/BernersLee/Weaving/Overview. The domain experts can then explore a problem they are trying to solve and produce code to solve it. If this computer literacy is harnessed to allow the domain experts to develop and share models. User Driven Model Development The intention of the research into User Driven Modelling (UDM) and more widely User Driven Programming (UDP) is to enable non-programmers to create software from a user interface that allows them to model a particular problem or scenario. To make this possible it is also important to examine visualisation. The research examines ways of structuring information.html. the productivity for software development will be increased and the proportion of misunderstandings between domain experts and developers reduced.Why a different approach is needed User involvement is important in the development of software but a domain expert does not necessarily possess expertise in software development. relational databases. The main approach taken was the use of visual metaphors to enable this creation process. This research unites approaches of object orientation. searching and sorting. This involves a user entering information visually in the from of a tree diagram. and domain experts who are much more able to attain the expertise to develop their own models than they are using current software languages. The technique should be usable for other types of program development. UDM could also help increase user involvement in software. Research relevant to User Driven Programming in general is covered as this could be applied to the problem in future.w3.

Goals All three aspects of a behavior interface can be coordinated by defining the goal of the behavior. namely that a position is . Web pages are a useful mechanism for this as they are widely accessible. This article examines interfaces to behavior. thereby simplifying the process of analysis and design. and consequently cannot affect the choice of parameters. which include the object hosting the operation. data flow. and examined one of those models more closely. suppose we are defining a business model containing an operation for hiring staff. The parts of a behavior interface are reviewed. how they can be used in an object-oriented way. addressed their unification. The first three reviewed traditional categories of behavior model. What task is to be done. 1. For example. specify what the task will operate on or with. Goal-driven Modeling This is the fourth article in a series on modeling behavior in the context of object orientation.order to achieve this it is necessary for the translator to understand and interpret equations that relate objects in the visual definition and obtain the results. These possibilities add power and provide guidance in using it. but in any case the method-dispatch technique is not at all related to the task or what it operates on. Goals describe the state of objects or data that a behavior is intended to achieve. 2. Focusing on goals coordinates the choices involved in designing behavior interfaces. The operation name specifies the task to be done. This depends only on the type of object hosting the operation. there is only one method dispatch technique. the choice of operation name and parameters are completely independent because a name has no structure. Its goal is to fill a position in a company. Interfaces to Behavior Regardless of which model is used to define a behavior (control flow. or state machine [1]). That these three aspects of behavior interfaces are independent in object-orientation makes them harder to use than if they were related under a more comprehensive methodology. there are at least three parts to such an interface: 1. For example. independently of which model is used to define them. What the task is to operate on or with. In order for the user to understand the translation that has been performed it is then important to visualise the translated code and this must be accessible to others who use the translated implementation. and no standard for multiply-classified objects. For example. 3. The goal constrains the state of a company after the goal is attained. links them more closely to the object model. Likewise. The purpose of this article is to describe a spectrum of possibilities in which object-orientation resides. This might be augmented with preconditions and postconditions to further specify the task. The parameters of the operation. object-orientation defines behavior interfaces like this: The above aspects are not coordinated in object-oriented methodologies. more colloquially called the message. In general. A method dispatch technique determines how the task will be carried out. How the task is to be carried out. 3. and places object-orientation within a spectrum of modeling styles that includes event-driven and rule-based approaches. at least for singly-classified objects. and a goal-based technique for defining them is presented. 2. it is always invoked through an interface that does not vary as the underlying behavior is changed.

so operation names are not easily integrated into a structured methodology and certainly cannot be support by tools. but goal-driven modeling guides the choice of parameters. This is not a goal of the operation. Figure 1 shows the FILL operation using a combination of UML Activity Diagram and Martin/Odell Event Diagram notation [3]. where they might otherwise be omitted. let's say to find a staff member for a particular position. their parameters. In the hiring example. But if parameters are chosen in a goaldirected way. the parameters are clear: an in parameter for the position. only a constraint on its execution.filled. This distinguishes them from postconditions generally. the FILL operation may specify that the remaining money in the budget only decrease by a certain amount during the execution of the operation. Goals are a specific kind of postcondition describing the desired result. and their methods. like FILLPOSITION suggests to the reader the intent of the operation. so the reduction is not arbitrary. because goals are constraints on behavior that are expressed in a purely object-centric way. in other words. A well-chosen operation name. and often only well-trained humans and sometimes only the author. only humans can interpret an operation name. not how the result is achieved. . Operation Parameters Goals are able to bridge the gap between operations. An important advantage of proper parameter specification is that it requires explicit modeling of associations and attributes in an object model. This derivation is most easily done with an association between each position and its superior. This effect would happen with any reduction in the number of parameters. that is. because the choice of goals is more narrow than parameters. if a manager were passed into the operation. the choice of parameters is much wider and more arbitrary. Once we choose a specific goal. an organization chart (see right side of Figure 2). and out parameter or return value for the person hired. Let's return to the example business model that contains an operation for hiring staff. Figure 1: Operation with Goal Goals do not restrict how the behavior is carried out. or other related data? Should it take a department rather than a position? Focusing on the goal of the operation reduces this complexity. Should the operation also take as input the hiring manager. the association between a position and its superior would not necessarily be modeled in objects (see left side of Figure 2). Postconditions may contain any sort of constraint on an operation [4]. there is a recruitment cap. the hiring manager needs to be derived from the input position during the execution of the behavior. Without a goal. For example. Goals are a formalization of what is usually implicit in the name of an operation. However. a budget.

This compacts the top-level use case so we can show more steps: . the modeler defines the FILLPOSITION operation because of the common pattern of going through a list of possible hires. go back to step 7. The director chooses one from this list.Figure 2: Parameter/Association Tradeoff The above tradeoff between parameter choice and object modeling is familiar to anyone who faces the problem of defining operations. 2. 8. The director makes an offer. choosing one. The producer of the film chooses one from this list. 4. 9. To begin translating the use case to an object model. The producer gets funding for the film. The producer makes an offer. 5. It is also common in translating use cases to software models [5][6]. The producer of the film gets a list of directors. like this one for staffing a film project: 1. and making an offer. If the cinematographer does not accept. 7. 10. and so on. If the director does not accept. the hiring operation example might have been defined during the formalization of a raw use case. The director gets a list of cinematographers. go back to step 3. 6. For example. 3.

and methods. The entire use case can be translated to an algorithm that recursively descends the organization chart. The task of the modeler. 4. The director hires actors. This is confirmed by the success of using goal-driven techniques in use-case development. 5. The director hires the cinematographer. The producer gets funding. The operation defined this way takes the position and hiring manager as input. The cinematographer hires the camera and lighting people. with each person hiring those below them. 2. is to translate procedures like the film staffing example into objects. in part by resolving the tradeoff between parameters and associations. Now when we let goals drive the parameter definition.1. operations. and eliminate the input hiring manager. The narrative aspect of use cases reflects the fact that professionals in domains other than computer science tend to explain their knowledge in procedural terms . 3. The producer hires the director. who is called the knowledge engineer in expert system methodology. we can create an organization chart as described before. Goal-driven operation definition structures this process. .