Analysis Model - PIM

Analysis Model is specification of a system that abstracts from implementation de-tails. In the context of the MDA approach, Analysis Model corresponds to PIM. In pre-sented approach the model consists of:

 Information Model defines structure of information processed within the system, which is expressed by UML class diagram [11] (example is shown in Figure 1), together with lifecycles’ specifications defined in form of State-Machines;

 Use-case Model defines UseCases and Actors, i.e. functionalities of the system and users who use those functionalities. A functionality is specified by: (a) use-case scenario, i.e. interactions between Actors and the system, mod-elled by an Activity, and (b) user interface model, i.e. graphical user interface and navigation paths between elements of user interface.

Use-case scenario is specified by means of Activities – each UseCase has an Activi-ty as the classifierBehavior properActivi-ty defining its flow. The following section explains proposed extensions of an Activity’s model elements that are used in the use-case sce-nario’s specification to enable the PIM to PSM transformation. Activity diagram show-ing an example of use of described constructions is shown in Figure 2. Relations be-tween Activities and other elements of Analysis Model are provided in [5].

Adapting Scrum Method to Academic Education ... 103

An Activity is divided into ActivityPartitions, which represent participants of the behavior and group Actions for which they are responsible. Partitions used in the pre-sented approach represents: actor’s actions, behavior of a system presentation layer, behavior of a system logic layer.

An Actor is responsible for data input action, data modification, selection of data to further processing, option selection or decision confirmation. A presentation layer is responsible for actions, like data presentation, allowing data edition and option selecting etc. Business logic is specified in a logic layer, by means of read or write persistent data actions, data transformation or verification, calls to external system services etc.

Use-case scenario defined by an Activity starts from event received by an AcceptE-ventAction that represents a UseCase’s trigger. The AcceptEAcceptE-ventAction is marked by user-defined «UseCaseTrigger» stereotype.

Model elements of an Activity allow to specify all a UseCase’s flows (i.e. main, al-ternate and exception) within an Activity. The DecisionNode separates particular flows, which may be steered by:

 Results of system processing, i.e values generated by previously exe-cuted Actions are used in evaluation of conditions of edges outgoing from the DecisionNode;

 User interface’s events triggered by a user (like pressing a button) ex-pressed by a DecisionNode with outgoing edges for each event definition. To make explicit connection between flows and user interface’s elements, stereo-type «EventDriven», pointing to pressed button (defined by event tagged value), is attached to each outgoing edge;

 An actor’s decision on Actions to be taken, which is expressed by a DecisionNode with outgoing edges without any conditions.

Objects flows within an Activity are expressed by notion of Pins (InputPin, Output-Pin and ValueOutput-Pin), whose type must be a kind of Class from Information Model [11].

For the sake of readability and to enable the PIM to PSM transformation, following notation conventions and extensions are used:

 All explicit objects processed with an Action are available via Input-Pins and all needed objects related to those explicit are obtained by dot-notation within Classes of Information Model;

 All results of an Action processing are stored in OutputPins of the Ac-tion;

 To simplify frequent access to particular objects (in particular in case of multiple “temporary” data modification), a DataStore with «UseCaseLocal-Variable» stereotype defined in presented approach is used;

 For an Action in the presentation layer, only InputPins are defined, which correspond to values to be displayed by elements of graphical user inter-face;

 For an Action in the actor layer, only OutputPins are defined, which correspond to values provided or selected by an Actor;

 For an Action accessing persistent objects, InputPins correspond to parameters of persistent objects selection criteria, while OutputPins contains se-lected persistent objects;

104 From Requirements to Software: Research and Practice

 For an Action storing persistent objects, InputPins contain objects to be persisted. OutputPins are defined conditionally, when persistent objects are modified within the Action, and contain input and modified objects;

 For an Action, which transforms or computes values and/or objects, InputPins contains computation input parameters, while results are stored in OutputPins of the Action.

Figure 2. Analysis Models - Use-Case scenario example

Actions defined within the presentation layer might be refined by following stereo-types:

– «Presentation» – an Action is realized by a user interface’s element specified by elementUI tagged value;

– «PresentationMessage» – an Action, which displays various types of messag-es, like information, warning, error messages to a user. Message content is provided in message tagged value, while dialogType tagged value points to message dialog;

– «ValidateMessage» – an Action is responsible for presentation of validation messages within user interface.

Adapting Scrum Method to Academic Education ... 105

In order to make processing logic detailed, precise and unambiguous, Actions de-fined within the logic layer are complemented by rules and constraints on data pro-cessing. Thereby Actions are specified by Object Constraint Language (OCL) [10]

statements, where an Action’s InputPins and OutputPins correspond to input and output parameters respectively.

For the sake of specification readability and precision, following notation conven-tions and extensions as well as interpretation are assumed:

 operation allInstances() – returns all persistent objects of a given Class;

 operation oclIsNew() – verifies whether the object is new (created in the Action, not persisted yet), whether properties of the object have default val-ues, and the object is in an initial State with respect to a corresponding State-Machine;

 expression: out=in – states that the out object is the in object, which properties might be modified in remaining part of a OCL statement.

Following stereotypes are available for all Actions presented in logic layer:

 «Select» – an Action selects persistent objects. A criterion of selection is given in criterion tagged value, which might be parameterized by values of InputPins. Example statements for «Select» Actions from the Activity on Figure 2 are given below:

 ‘Read product categories’: criterion = out=Category.allInstances()->select(active),

 ‘Read products catalog’: criterion = out=Product.allInstances()->select(standard),

 ‘Select a process salesman for the RQF’: criterion = out=SalesRegion.allInstances()->select(active and

postcodes->includes(in.postcode))->flatten()->any(true)

 «Set» – an Action sets properties values of a processed object. The values are defined using OCL statements. Example statements for «Set» Actions from the Activity on Figure 2 are given below:

 ‘Set the assistant of the RFQ’: expression= out=in and out.assistant=spe

 ‘For each RQFDetails set a production process’: expression

=

 «Save» – an Action persists an object. It is assumed that properties of the stored object are computed in predecessor Actions on the logic layer and

106 From Requirements to Software: Research and Practice

Actions on the actor layer related to providing data via user interface, but also they results from constraints on Information Model, like {id};

 «Delete» – an Action deletes a persistent object. It also remove recur-sively all constituent objects, i.e. related by means of composite association;

 «Validate» – an Action validates data provided by an Actor using user interface’s elements according to validation rules;

 «Email» – an Action sends e-mail message. A message of an e-mail is defined in text tagged value, and the email recipient in email tagged value.