Modelling Human Factors using the Systems Modelling Language

More documents

Recommendations

Info

HFIDTC/2/WP2.8.9/1Version 2/ 24th September 2008Case. This will be illustrated in the following sections. Indeed, textual descriptions areoften inadequate in explaining complex interactions and should be superseded by furtherdiagrams. A number of scenarios are usually considered within a Use Case detailingpossible pre- and post-conditions.7.2.1.1 Value addedThe Use Case Diagrams in this section represent the H-Fly system at the highest level ofabstraction. They are an important foundation for the modelling that we will do in latersections and they will be referred to as a source of information for other diagrams. Theymay also be updated if subsequent modelling reveals any deficiencies in them.The Glossary of terms has been updated for the new terms introduced in the Use Casediagrams and in doing this we are promoting a common understanding.7.2.2 Modelling ScenariosThe section above shows how Use Case Diagrams can be used to organise and analyserequirements. Once this has been done, other SysML diagrams can be used to modelscenarios. A scenario examines a particular aspect of the system’s performance and is aninstance of a Use Case. To continue with the case study example we can use a SequenceDiagram to further analyse the system’s operation.Figure 7-4 shows a Sequence Diagram that models a scenario for the ‘Request SituationAwareness Information’ Use Case, which is represented in Figure 7-3.Sequence Diagrams represent the flow of control between the interacting entities thatmake up the system (Actors and Blocks). These are represented as ‘Lifelines’ on thediagram with the messages between them represented by horizontal lines (calls andreplies). The grey boxes on the Lifelines (activations) indicate that the Lifeline is busy.Time runs from top to bottom in the diagram. The messages represent ‘calls for service’,e.g. the provision of SA information by the CGS, and the grey boxes indicate that the callis being serviced. It is possible here to add further requirements, e.g. that servicing a callfor SA information should take no longer than 20 seconds.The diagram represents a scenario where troops on the ground come under fire, and aftertaking cover request the GCS to provide them with SA information (i.e. video and mapinformation to indicate the location and strength of the enemy forces). After the GCSacknowledges the request the GD will need to supply further details, such as theirestimate of the enemy location and strength, the urgency of the request etc. The request isthen assessed by the GCS who decides if it can be complied with. In the scenario therequest is accepted and a confirmation message sent to the requestor. Note that aSequence Diagram represents a single scenario associated with that Use Case andtypically a number of scenarios would be identified and modelled.20
HFIDTC/2/WP2.8.9/1Version 2/ 24th September 2008Figure 7-4 – Sequence Diagram – Request SA InformationThe diagram illustrates the first use of stereotypes to classify some of the elements thatmake up the diagram. A stereotype represents a variation on an existing model element,so in the diagram above there are blocks representing the ‘Ground Deployment’ and the‘Ground Control Segment’, and a block is an existing model element within the SysMLlanguage. These have been stereotyped as ‘Organisational Units’; this is indicated byincluding the text between chevrons as, . The SysML is nowread as, “There is block called GD that happens to be an Organisational Unit”. That termis taken from the MODAF Human View HV-D and defined in the Human Views MetaModel in Figure 9-1, which shows it to have sub-types, ‘Unit’, ‘Team’ or ‘Post’. Themessages between the Organisational Units are stereotyped as , whichshows we are currently assuming that this communication will be via radio. By usingstereotypes we are providing additional information about what type of thing a diagramelement is.The production of this Sequence Diagram has added some further understanding of therequirements. We now know that there is a requirement for voice communicationbetween the GD and the GCS, and that the GCS will need to assess requests and makedecisions as to whether the information can / should be provided.21
Page 1 and 2: Modelling Human Factors usingthe Sy
Page 4 and 5: HFIDTC/2/WP2.8.9/1Version 2/ 24th S
Page 8: HFIDTC/2/WP2.8.9/1Version 2/ 24th S
Page 17: HFIDTC/2/WP2.8.9/1Version 2/ 24th S
Page 74 and 75:
HFIDTC/2/WP2.8.9/1Version 2/ 24th S
Page 76:
HFIDTC/2/WP2.8.9/1Version 2/ 24th S
show all

Modelling Human Factors using the Systems Modelling Language

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?