Tutorial - Requirements Model
In UWE the requirements modelling consists of two parts:
- Use cases of the application and their relationships
- Activities describing use cases in detail
Use Cases
Our example is quite simple, therefore it is not absolutely necessary to start modelling use cases, but they are used to show the functionalities of our address book: the user should be able to search in the address book and delete contacts from it. In addition, contacts can be created and updated and these changes may be saved or cancelled. Feel free to model your own use case diagram including more features!
In UWE the use cases are distinguished by the stereotypes «browsing» and «processing» to indicate whether an application modifies the persistent data of the application or not. "SearchContact" for example, models the search for contacts and has the stereotype «browsing» because during a search the database is only read and presented to the user. The other use cases, however, model data changes and therefore they are typed with «processing».
| stereotype-names and their icons | |
|---|---|
 browsing |
 processing |
 webUseCase |
|
Activities
Since only few information can be captured with use cases, each use case can be described more accurately by a process flow. Thus, the actions within a use case as well as the data presented to the user and the required input can be modeled.
| stereotype-names and their icons | |
|---|---|
 userAction |
 systemAction |
 displayAction |
 navigationAction |
 displayPin |
 interactionPin |
First, the two stereotypes «user Action» and «system Action» can be used analogously to process flows. The «user Action» stereotype is used to indicate user interactions on the web page initiating a process or responding to an explicit requirement of information. By contrast, «system Action» describes actions, which are executed by the system. Both types of actions can be inserted using the toolbar. Details of the used data structures can be represented by object nodes and action pins. The object node is used to model content classes and the pins their attributes.
During requirements engineering it is usually also useful to specify which data is presented where and when. For the modelling of presentation groups in UWE the stereotype «display Action» is used, while the two action pin stereotypes «display Pin» and «interaction Pin» are used to model the output and input elements. Finally there is the stereotype «navigation Action», which can be used to model the navigation options and the associated presentation elements.
Since these stereotypes are used to note presentation elements during the requirements engineering, tagged values can be added to specify RIA features and the type of presentation element.
As an example, we model two activities of our address book web application. First, we look at the activity of the use case "CreateContact". In the beginning it should show a form that allows the user to enter a name, an email address, two addresses and phone numbers and the upload of an image file. Thereby the email should be validated during input and the addresses should be completed automatically. Then the form is filled out by the user and finally stored in the applications database.
The second use case that is refined is named "SearchContacts". Because for this use case only presentation elements are of interest we will restrict the diagram to them. Initially, the presentation consists of a simple form used to enter keywords and a button initiating the display of the contact list.
The main part of the presentation, however, consists of a list of contacts, which are modelled with the action "Contacts". The presentation elements can be grouped additionally by creating actions within a higher-level action, as shown at the addresses and phone numbers.
The two actions of the stereotype «navigation Action» model transitions to other use cases. This is modelled by adding the activity of the target use case as a behaviour of the action.
Transformations
Once the requirements are modeled, there are two ways the development of the further models (content, navigation, presentation and process) can be simplified:
- Instead of creating a model and the corresponding diagram manually, it can also be generated with a transformation from the data of the requirements model.
- Additionally, a previously generated model can be extended by new classes transformed from the requirements model or by adding new model-dependent data to existing classes.
