System Scenario Modelling
Overview
This activity coordinates the production of a stable high level scenario model of the solution. It relies on the use of scenario Modelling techniques. It can be executed concurrently with the System Domain Modelling, and results in the production of a System Scenario Model using textual descriptions and the UML sequence or collaboration diagrams.
While the early versions of the System Domain Model are being produced, the Architect will produce one or more iterations of the System Scenario Model. A System Scenario Model represents a dynamic view of the solution at a high level. System Scenarios illustrates `how' the System Domain Model is capable of delivering the functionality from the Requirements Model. A system scenario can be textual, graphical or a combination of both and is documented in the System Scenario Model deliverable. Refer to the System Scenario Model template for ideas of suitable items to include in each section of this deliverable. However if a Tool is being used to generate the model then it may be possible to get the Tool to generate a suitable report containing the required information, rather than completing the System Scenario Model deliverable by hand.
Figure : The tasks of the System Scenario Modelling activity
Inputs
· Requirements Model
· System Architecture (if available)
· System Domain Model (if available)
Tasks
· Explore Requirements
· Identify System Scenarios
· Develop System Scenarios
· Develop Interaction Diagrams
· Verify Correctness
· Map System Scenarios to Business Use Cases
· Document External System Interfaces
Roles
Responsible Role(s)
· System Modeller
Participant Role(s)
· Designer
Deliverables
· System Scenario Model
Tailoring Guidelines
This is a key Activity in the Process Unit and all tasks should be undertaken. The depth and detail to which the System Scenario Model is documented depends greatly on the size and complexity of the project. For small and medium sized systems there may only be a few (10-20) key scenarios that need to be developed in any detail. For large systems this activity is absolutely vital to understanding the expected behaviour of the system. More key scenarios will need to be described in detail, particularly the architectural/infrastructure scenarios. Many more scenarios may need to be described in lesser detail to make sure that the system can exhibit this behaviour. Great care is required in documenting the classes/packages and making the interactions between them very clear.
Detailed Task Description
Task 1: Explore Requirements
Explore the Requirements, particularly the Business Functional Requirements and Graphical Use Case Diagrams to identify the scope of the System Scenario Model.
The purpose of this task is become familiar with the Business Use Cases and scope the extent of the System Scenario Model. This step exists to allow the System Modellers to work with the Architect to determine the level of completeness that the model is to achieve.
A scenario model may be anything from a complete textual description of `how' the System Domain Model delivers the functionality of the Requirements Model, to a set of graphical diagrams that illustrate `how' the System Domain Model delivers the key mechanisms required to support the functionality of the Requirements Model. It is important to establish the number and scope of the Scenarios that are to be developed in the Model.
Fill in Section 1 of the System Scenario Model deliverable.
Task 2: Identify System Scenarios
Identify the Key System Scenarios and document within Section 3 (System Scenarios) of the System Scenario Model.
The purpose of this task is to identify and document the Key System Scenarios that are to be developed in the System Scenario Model. The System Modeller needs to identify both the Key Business Use Cases (Use Cases) and the Key Scenarios from an Architectural perspective early on in the System Scenario Modelling process.
Once the level of completeness has been established, the key scenarios can be identified. These scenarios should then be explored and documented one by one to ensure coverage of the model. As well as identifying the Key Business Use Cases that the system will have to support, it is important to identify those scenarios that exercise key areas of the architecture. This will ensure that early product increments explore all the main risk factors associated with the architecture as well as the Business Requirements.
A sub-section of Section 3 should be created for each identified scenario and preliminary information entered for each one.
Task 3: Develop System Scenarios
Further develop the Key System Scenarios and document within Section 3 (System Scenarios) of the System Scenario Model.
The purpose of this task is to define the sequence of activities for each of the Key System Scenarios.
The System Modeller uses this task to understand and describe how each Key System Scenario will be carried out. Each Key System Scenario is usually expressed in terms of sequence or collaboration diagrams. Sometimes a pure textual description is enough. In both cases the Key System Scenarios will be documented through the use of the system scenario template.
Developing a Scenario
Within the context of developing a scenario, there are 4 sub-tasks that must be completed :
· Identify classes/components and objects involved in the scenario
· Identify events (messages) required to trigger delivery of functionality
· Allocate operations (to deliver functionality when triggered)
· Document the scenario
These steps should be repeated for each scenario identified. Once completed, the class specification for each class will support all the necessary operations required to complete the scenarios. Note that during the analysis activity it is important not to be too concerned with the detail of the scenario. Concentrate on the system/user/external-system conversations and the key component interactions rather than the detailed internal design scenarios. Providing the implementation detail is an activity to be completed during the design phase(s) of the software engineering process. Note also that the following descriptions use the word class to include classes, packages, components and subsystems. For initial, high-level, scenario Modelling the distinctions between these different types of participants is not particularly important.
Step 1 - Identify classes involved in the scenario
Begin by identifying the classes involved in the scenario. The classes involved in a given scenario should be a subset of the class dictionary developed in the System Domain Model.
Step 2 - Identify events sent between classes
Having identified the classes involved in the scenario, the scenario should be developed by stepping through the activities of the scenario identifying the interactions between the classes. Often the initiation or termination of part of an activity can be thought of as an event which triggers further behaviour. A scenario will always be triggered by some event (normally by an actor or boundary class in the case of the solution of a business use case) which will cause some activity in one of the classes. The completion of this activity will trigger (send an event, or message) to another class, and so on until the sequence of activities in the scenario has been completed. Each event should have a sender and a receiver and may have parameters. It should be possible to mentally walkthrough the completed scenario from beginning to end to check that the scenario meets the requirements of the business use case it is solving or has the correct functional effect for a system-level activity.
Step 3 - Allocate events as operations on the classes
Having completed the scenario, the events can be allocated as operations on classes. Each event received by a class is an operation on that class. This process can be accomplished by following the line representing a class in the scenario and allocating an operation to the class for every incoming event.
Once the operation is allocated to a class it can be specified in more detail. This can be achieved using English description, pseudo-code or formal specifications. The English description and pseudo-code should be captured in the class specification.
Step 4 - Document the scenario
Document the scenario to the level of detail specified in accordance with the System Scenario template (or as generated from a tool).
Package the individually documented System Scenarios as a System Scenario Model in Section 3 of the System Scenario Model deliverable.
Task 4: Develop Interaction Diagrams
Develop Interaction Diagrams for the Key System Scenarios and document within Section 3 (System Scenarios) of the System Scenario Model.
The purpose of this task is to draw interaction diagrams that describe each of the Key System Scenarios. The System Modeller uses these diagrams to better visualise the activities in each scenario.
Interaction diagrams describe the dynamic behaviour of classes in a system. There are two types of interaction diagrams in the UML: sequence diagrams and collaboration diagrams.
Sequence Diagrams
Sequence diagrams show events, their sequence and the classes/components involved in a given scenario. A sequence diagram shows classes as vertical lines and events as directed arcs from one class/component to another. The event is labelled with a name and possibly parameters. Time is shown moving from the top to the bottom of the page. The sequence of a scenario thus runs from top to bottom.
Figure : An example of a sequence diagram.
Collaboration Diagrams
Like sequence diagrams, collaboration diagrams show the interactions that occur between the objects as they deliver a set piece of functionality. A collaboration diagram illustrates the events (messages), their sequence and the objects involved in a given scenario. A message is labelled with a name and possibly a statement on the parameters that are passed. Time is shown through the use of sequence labels (i.e.. 1, 2, 2.1, 2.2, 3) that are attached to each message.
Figure : An example of a collaboration diagram.
In theory, sequence diagrams and collaboration diagrams represent the same dynamic view of system behaviour. However collaboration diagrams can be used to help visualise the interactions that a particular object has with other objects in the solution. Whereas sequence diagrams help you visualise the path of execution through a set of objects in the solution. Both of these may be appropriate for particular purposes during scenario Modelling. Most tools can generate one diagram from the other so it is only necessary to draw one then ask the tool for the other.
Developing a Sequence Diagram
These are the detailed steps in developing a sequence diagram. Similar steps will be required to develop a collaboration diagram. Within the context of developing a scenario, there are 4 sub-tasks that must be completed :
· Identify classes/components and objects involved in the scenario
· Identify events (messages) required to trigger delivery of functionality
· Allocate operations (to deliver functionality when triggered)
· Document the scenario
These steps should be repeated for each scenario identified. Once completed, the class specification for each class will support all the necessary operations required to complete the scenarios. The interaction (sequence or collaboration) diagram documents the message passing sequence that has been designed for the scenario.
Note that during the analysis activity it is important not to be too concerned with the detail of the scenario. Concentrate on the system/user/external-system conversations and the key component interactions rather than the detailed internal design scenarios. Providing the implementation detail is an activity to be completed during the design phase(s) of the software engineering process. Note also that the following descriptions use the word class to include classes, packages, components and subsystems. For initial, high-level, scenario Modelling the distinctions between these different types of participants is not particularly important.
Step 1 - Identify classes involved in the scenario
Begin developing a sequence diagram by identifying the classes involved in the scenario. These classes should be represented as vertical dashed lines. The classes involved in a given scenario should be a subset of the class dictionary developed in the System Domain Model.
Step 2 - Identify events sent between classes
Having identified the classes involved in the scenario, the scenario should now undergo a walkthrough review. Events that complete some task described in the scenario, should also be identified. The event should have a sender and a receiver and may have parameters. The event should be recorded as an arrow on the sequence diagram going from the sender to the receiver.
Step 3 - Allocate events as operations on the classes
Having completed the diagram for the scenario, the events can be allocated as operations on classes. Each event received by a class is an operation on that class. This process can be accomplished by following the line representing a class in the scenario and allocating an operation to the class for every incoming event.
Once the operation is allocated to a class it can be specified in more detail. This can be achieved using English description, pseudo-code or formal specifications. The English description and pseudo-code should be captured in the class specification.
Step 4 - Document the scenario
Document the scenario to the level of detail specified in accordance with the System Scenario template (or as generated from a tool). Add the graphical representation of the scenario (using the selected diagramming technique) to the scenario description. Add any extra text in the appropriate places in the template.
Task 5: Verify Correctness
Verify the correctness of the Key System Scenarios and document the results within section 3 (System Scenarios) of the System Scenario Model.
The purpose of this task is to check that the System Scenario Model is correct in the sense of being consistent with other Models, e.g. the System Domain Model. The System Modeller needs to develop some confidence in the validity of the System Scenario Model.
Cross-check the System Scenario Model with the System Domain Model. For example:
· All objects/classes in the interaction diagrams should appear in the class diagram
· Every message originating from a class must have a corresponding operation in the class to generate the message
· Every receiver of a message must have an operation to act on the message
· Every argument in a message must be available in the sending class
Task 6: Map System Scenarios to Business Use Cases
Map the Key System Scenarios to Business Use Cases and document within section 4 (Business Use Case Correlation) of the System Scenario Model. Also construct a matrix identifying the classes/packages used by each Business Use Case and document within section 5 (Business Use Case to Packages Used Matrix) of the System Scenario Model
The purpose of this task is to validate the System Scenarios against the Business Use Cases. The System Modeller needs to do this in order to check that the System Scenarios do actually provide solutions to the Requirements represented by the Use Cases.
For each Business Use Case identify the System scenario(s) that purport to satisfy it. One method of doing this is to create a table with the Business Use Case names in the first column and identify the appropriate System Scenarios against each Business Use Case giving explanations as necessary in the comments column, e.g.
|
Business Use Case to System Scenario Map |
|
Business Use Case |
System Scenario |
Comments |
|
Identify Use Case |
Identify system scenarios that cover the functionality of this business Use Case |
make note of any important information that relates to the correlation |
It is also important to identify which classes/packages are used by each Business Use Case as this will help to define the build strategy and build order for the Development Phase of the Life-Cycle, e.g.
|
Business Use Case to System Package/Class Map |
|
Business Use Case |
Package/Class Name |
Package/Class Name |
... |
|
Identify Use Case |
X |
X |
... |
|
Identify Use Case |
|
X |
... |
Task 7: Document External System Interfaces
Identify any interactions with external systems and document within section 6 (External System Interfaces) of the System Scenario Model.
The purpose of this task is to make sure that information about interactions with external systems are documented in the System Model and cross referenced with the appropriate External Interface Specification deliverable.
Document any External System Interfaces that have been assumed or identified during development of the System Scenarios and validate against the messages identified in the External Interface Requirements.
|
External System Interfaces |
|
System |
Interface |
Key Attributes |
Attribute Description |
|
Identify the system |
name the external interface that applies |
confirm the attributes that are used by the interface |
describe each attribute |