Managing and Viewing i* models

General view of HiME Working with models
Working with Inheritance
i* Framework
The main window is divided in two parts:

Managing i* models

This tool manages models and store this information in text files, HiME uses iStarML format for the storage of information.

Creating models

Models are created on the tool using option New of menu Model or the toolbar button .

Follow this link to obtain detailed information about the creation of extra properties.

Saving and loading models

Models are stored as text files, therefore the user will be asked for the file name to save the model on the tool or to load one.

For storing the model there is two options: Save or Save As options from menu File depending if the user is saving the current model in a file with the same name or a new one. These options can be also directly accessed from the toolbar buttons and respectively. Note that the first time that the model is stored, a name is asked although the option used has been save.

Further information about iStarML format in iStarML web site.

Viewing i* models

i* models are represented in the application in a tree-view form. All element links which are not decomposition or means-end are represented by the duplication of the target node, for example a dependum is duplicated in the depender and the dependee actors.

The operation that can be done on the model are grouped depending on the node where they can be iniciated:

This node represents the whole diagram. The only child kind this node admits is the actor. Therefore, it is not possible to draw i* elements which are not related to an actor. The allowed operations are adding actor, edit model information and deleting all model content.

This node represents an actor of the i* diagram. You can create several i* SR elements which are direct childs of the actor. This means that an actor can have more than just one root SR element. The childs the actor node admits can be either SR Elements or dependencies with other actors to get or provide a dependum. The allowed operations are creating main intentional elements, links and dependencies with other actors, editing its fields and removing it from the model.

This node represents a goal, a kind of SR Elements which represents a condition to be achieved. This can be described through goal decomposition. The allowed operations are adding a dependency link to other actor and a mean-end link with a new intentional element (goal decomposition), editing its fields and removing it from the model.

This node represents a softgoals, similar to (hard) goals except that the criteria for the goal's satisfaction are not clear-cut, it is judged to be sufficiently satisfied from the point of view of the actor. The means to satisfy such goals are described via contribution links from other elements. The allowed operations are adding dependency link to other actor and contribution links from other intentional elements in the same actor, editing its fields and removing it from the model.When a softgoal has contributions, they are represented adding the intentional elements as children as is shown in the image below. When a child node is selected, its is possible to go to the original intentional element.

This node represents a task,a kind of SR Elements which represents a way to reach a condition or a procedure that is done. A description of the specifics of the task may be described by decomposing the task into further sub-elements. The allowed operations are adding dependency link to other actor and a task-decomposition link with a new intentional element, editing its fields and removing it from the model.

This node represents a resource, an entity of the model. The actor desires the provision of some entity, physical or informational. According to i* syntax, this element can not have any kind of decomposition. The allowed operations are adding dependency link to other actor, editing its fields and removing it from the model.

Dependency nodes are represented with intentional elements icon empty, depending on its type. A dependency can be from and to an actor or on an intentional element. In both situations, the linked actor appears as a child in the dependum.

When both strengths has the default value they are not shown (left figure), otherwise the strenghts are shown (rigth figure).