URN Model and AoURN Model Files:

JUCM

PDF

HTML

CCCMS.jucm

CCCMS.pdf

CCCMS

CCCMS - UCM only.jucm

CCCMS - UCM only.pdf

CCCMS - UCM only

CCCMS - goals.jucm

CCCMS - goals.pdf

CCCMS - goals

 

 

The jUCMNav tool occasionally diverges from the official standard URN language and AoURN.

The following syntax is used by the tool:

1)      only static, dynamic, and pointcut stubs are properly identified – all other types are indicated in the label of the stub

2)      the anything pointcut element is shown as a static stub with the label “…”

3)      local start/end points are shown with the label “<<local>>”

4)      pointcut (deletion) markers are not properly shown on AoGRL pointcut graphs

 

 

Mapping from the CCCMS case study document to the UCM model:

Use Case

Use Case Map Model

Resolve Crisis

Resolve Crisis, Execute Mission, Default, Confirm Arrival, Confirm Departure, Update Mission Info

Capture Witness Report

Capture Witness Report

Assign Internal Resource

Assign Internal Resource, Accept Mission

Request External Resource

Request External Resource

Execute Mission

dynamic stub ExcecuteResourceMission on Execute Mission map

Execute Super Observer Mission

Execute Super Observer Mission, 3 superobserverInitiated branches on Execute Mission map, newCrisisAndMissionInfoAvailable start point on Resolve Crisis map

Execute Rescue Mission

Execute Rescue Mission

Execute Helicopter Transport  Mission

Helicopter Transport Mission, Execute Helicopter Transport Mission (only empty path modeled)

Execute Remove Obstacle Mission

Execute Remove Obstacle Mission (only empty path modeled)

*) All use cases are well encapsulated except for Execute Super Observer Mission which requires portions of the maps of two other use cases and Execute Helicopter Transport Mission which requires a portion of the map of another use case. The interaction points between use cases, however, are generally modeled explicitly with the help of stubs.

 

 

The following errors in the CCCMS case study document were corrected in the models:

1)      The case study document was not clear on whether the Super Observer has the power to create new missions or whether the Coordinator has final say over which mission to create. It was assumed that the Coordinator has final say while the Super Observer merely informs the system of the desired missions because the Super Observer does not have any information about resource availabilities.

2)      It was assumed that the Helicopter Transport Mission and the Remove Obstacle Mission follow the same pattern as the two missions described in more detail in the document (i.e., recommend strategy / request resources / confirm arrival / execute specific mission / confirm departure / mission wrap-up). For example, steps 6a.1 and 6a.2 map onto the recommendMission(s) and selectMission(s) responsibilities of the Resolve Crisis map.

3)      It was assumed for efficiency reasons that internal and external resources can be assigned/requested in parallel instead of first internal resources and then external resources afterwards.

4)      It was assumed for logical reasons that the system selects an appropriate external resource before issuing a request to that resource.

5)      Finally, it was assumed for logical reasons that the system may suggest crisis-specific missions to the Super Observer more than once (i.e., step 3 of the Super Observer use case may also be repeated).

6)      Furthermore, some responsibilities were added to the UCM model for consistency reasons to complement already existing functionality: setResourceStatusToArrived, setResourceStatusToDeparted, releaseResource, and setCrisisStatusInactive.

 

 

Differences between the use cases and the UCM model:

Since UCMs are a technique that models a complete system view in addition to scenario views, a few subtle differences exist between the use cases and the UCM model:

1)      The basic and exceptional flows of the Assign Internal Resource use case are described more formally with a timer in the UCM model.

2)      Arrival of a resource at the crisis location (steps 6, 6b, and 6c of Resolve Crisis) is described more formally with a timer in the UCM model.

3)      Departure of a resource from the crisis location (steps 8, 8a, and 8b of Resolve Crisis) is described more formally with a timer in the UCM model.

4)      A waiting place was added to the Helicopter Transport Mission map to indicate that the original mission is put on hold until the helicopter mission succeeds in transporting the original resource to the crisis location. At this point, the original mission is restarted and continues as if the helicopter was not required.

5)      Steps 7, 8, and 8a.1 of the Execute Super Observer Mission use case cannot be shown on the Execute Super Observer Mission map as this can logically only happen once the resources of the desired mission have been assigned/requested, the desired mission was completed, or the desired mission failed, respectively. Therefore, these steps are shown on the Execute Mission map.

6)      Step 8a.1 of the Execute Super Observer Mission use case requires the Coordinator to be informed of the mission failure. This is not shown on the Execute Super Observer Mission map as this behavior is already captured by the newCrisisAndMissionInfoAvailable start point and the waiting place on the Resolve Crisis map.

7)      Steps 9 and 12 of the Resolve Crisis use case are both modeled by the newCrisisAndMissionInfoAvailable start point and the waiting place on the Resolve Crisis map, thus simplifying the model.

 

 

Aspect-oriented assessment of the UCM model:

Use Case

Recommend Strategies

Resource Management

Coordination

Communication

Resolve Crisis (Resolve Crisis map)

recommendMission(s)

 

X

CaptureWitnessReport stub, assessNewCrisis­AndMissionInfo (including the AND-fork, waiting place, and starting point)

Resolve Crisis (Execute Mission map)

 

RequestResource(s) stub, substituteInternal­WithExternal­Resource, releaseResource

X

receiveMissionCreated, ConfirmArrival stub, ConfirmDeparture stub, Update Mission Info, submitFinalMissionReport, receiveMissionSuccessful, receiveMissionFailed 

Resolve Crisis (Confirm Arrival map)

 

 

setResourceStatus­ToArrived

X

Resolve Crisis (Confirm Departure map)

 

 

setResourceStatus­ToDeparted

X

Resolve Crisis (Update Mission Info map)

 

 

 

X

Capture Witness Report (Capture Witness Report map)

 

 

assignEmergencyLevel, setCrisisStatusActive

X

Assign Internal Resource (Assign Internal Resource map)

 

X

 

 

Assign Internal Resource (Accept Mission map)

 

X

 

assessMissionInformation, acceptMission, rejectMission

Request External Resource (Request External Resource map)

 

X

 

assessERSMission­Information, approveERSMission, approvePartialERSMission, denyERSMission

Execute Super Observer Mission (Execute Super Observer Mission map)

recommendMission(s)

 

X

provideCrisisSpecific­ChecklistFor­SuperObserver, enterCrisisSpecificInfo, enterMission(s)SpecificInfo

Execute Rescue Mission (Execute Rescue Mission map)

 

 

X

enterInjuryInfo, enterVictimID, provideMedicalHistory, assessMedicalHistory, confirmDepartureToHospital, confirmArrivalAtHospital

Execute Helicopter Transport Mission (Helicopter Transport Mission map)

 

 

X

 

Execute Helicopter Transport Mission (Execute Helicopter Transport Mission map)

 

 

X

 

Execute Remove Obstacle Mission (Execute Remove Obstacle Mission map)

 

 

X

 

*) X indicates that this map belongs to the concern, including all map elements except for those listed in the same row under a different concern.

*) Default is a common utility map that is not assigned to any concern.

*) The Communication concern also appears in each and every interaction between the system and actors. As the UCM model abstracts from the details of these interactions, they manifest themselves in the UCM model as paths crossing from one UCM component to another. The following interactions occur:

1)      System – Coordinator

2)      System – Phone Company

3)      System – Surveillance System

4)      System – Super Observer

5)      System – Resource

6)      System – CMS Employee

7)      System – External Resource System

8)      System – First Aid Worker

9)      First Aid Worker – Hospital Resource Systems (via System, not shown in UCM model as it abstracts from this)

*) The responsibilities in the UCM model that were assigned to the Communication concern all deal with information exchange between actors and the system. In some cases, these responsibilities cannot be clearly assigned to just the Communication concern as they are an integral part of the mission that is executed (see shaded responsibilities in the above table). Given that the Communication concern covers all interactions at the data exchange level anyway as explained in the previous point, it was decided to not include the shaded responsibilities in the Communication concern because they reflect more the missions themselves.

*) The three superobserverInitiated branches on the Execute Mission map belong to the Super Observer Mission.

*) The TransportWithHelicopter stub belongs to the Helicopter Transport Mission.