Crisis Management SystemsA Case Study for Aspect-Oriented Modeling

Jorg Kienzle1, Nicolas Guelfi2, and Sadaf Mustafiz1

1 School of Computer Science, McGill University, Montreal, CanadaJoerg.Kienzle@mcgill.ca, sadaf@cs.mcgill.ca

2 Laboratory of Advanced Software Systems, University of Luxembourg, LuxembourgNicolas.Guelfi@uni.lu

Abstract. The intent of this document is to define a common case study for theaspect-oriented modeling research community. The domain of the case study iscrisis management systems, i.e., systems that help in identifying, assessing, andhandling a crisis situation by orchestrating the communication between all par-ties involved in handling the crisis, by allocating and managing resources, and byproviding access to relevant crisis-related information to authorized users. Thisdocument contains informal requirements of crisis management systems (CMS)in general, a feature model for a CMS product line, use case models for a carcrash CMS (CCCMS), a domain model for the CCCMS, an informal physicalarchitecture description of the CCCMS, as well as some design models of a pos-sible object-oriented implementation of parts of the CCCMS backend. AOM re-searchers who want to demonstrate the power of their AOM approach or tech-nique can hence apply the approach at the most appropriate level of abstraction.

1 Introduction

The need for crisis management systems has grown significantly over time. A crisis canrange from major to catastrophic affecting many segments of society. Natural disasters(e.g. earthquakes, tsunamis, twisters, fire, floods, etc...), terrorist attacks or sabotage(explosions, kidnapping, etc...), accidents (plant explosion, pollution emergency, a carcrash, etc...), and technological disruptions are all examples of emergency situationsthat are unpredictable and can lead to severe after-effects unless handled immediately.Crisis management involves identifying, assessing, and handling the crisis situation. Acrisis management system facilitates this process by orchestrating the communicationbetween all parties involved in handling the crisis. The CMS allocates and managesresources, and provides access to relevant crisis-related information to authorized usersof the CMS.

Different existing AOM approaches and techniques are meant to be used duringdifferent phases of software development. As a result, different AOM approaches workwith different kinds of models and modeling notations. In order to make sure that allAOM approaches and techniques are somehow applicable to this case study, we presenta collection of models that describe the CMS at different levels of abstraction:

1. Short, informal requirements text describing the domain of crisis management sys-tems in more detail. It also mentions some non-functional requirements of a CMS,

e.g. security and dependability. This text, presented in Section 2 on page 2, proba-bly contains information that is important to everyone who wants to work on thiscase study.

2. Feature diagrams highlighting the software product line aspect of crisis manage-ment systems. Crisis management systems can be used to handle many types ofcrises (e.g., natural disasters, epidemics, accidents, attacks, etc...) and may have tointerface and interoperate with different types of external services (e.g., militarysystems, police systems, government, medical services, etc...). The feature diagrammodels are presented in Section 3 on page 6.

3. Use cases describing a particular CMS suitable for dealing with car crash crises.The Car Crash CMS (CCCMS) use case model description can be found in Sec-tion 4 on page 8.

4. A domain model of the car crash crisis management system that documents the keyconcepts, and the domain-vocabulary of the CCCMS is presented in Section 5 onpage 16.

5. An informal description of a possible physical architecture for the car crash crisismanagement system is presented in Section 6 on page 18.

6. Some detailed design models for the car crash crisis management system backendare given in Section 7 on page 19.

2 Crisis Management System: Requirements

The user requirements outlined in this section are based on a draft of a real requirementsdocument for crisis management systems created by the company Optimal Security [1].The general objectives of a crisis management system (CMS) include the following:

– To help in the coordination and handling of a crisis;– To ensure that an abnormal or catastrophic situation does not get out of hand;– To minimize the crisis by handling the situation using limited resources;– To allocate and manage resources in an effective manner;– To identify, create, and execute missions in order to manage the crisis;– To archive the crisis information to allow future analysis.

2.1 Crisis Scenario of a Car Crash Crisis Management System

A crisis management scenario is usually triggered by a crisis report from a witnessat the scene. A coordinator, who is in charge of organizing all required resources andtasks, initiates the crisis management process. The coordinator has access to the cam-era surveillance system. The surveillance system is an external system used to monitortraffic on highways or other busy routes. The cameras are installed only in specific lo-cations. If a crisis occurs in locations under surveillance, the crisis management systemcan request video feed that allows the coordinator to verify the witness information.

A super observer, an expert in the field (depending on the kind of crisis), is assignedto the scene to observe the emergency situation and identify the tasks necessary to copewith the situation. The tasks are crisis missions defined by the observer. The coordinatoris then required to process the missions by allocating suitable resources to each task.

2

Depending on the type of crisis, human resources could include firemen, doctors,nurses, policemen, and technicians, and hardware resources could include transporta-tion systems, computing resources, communication means (such as PDAs or mobilephones), or other necessities like food or clothes. Animals, for instance police dogs,are also used as resources in some situations. The human and animal resources act asfirst-aid workers. Each first-aid worker is assigned a specific task which needs to beexecuted to recover from the abnormal situation. The workers are expected to reporton the success or failure in carrying out the missions. The completion of all missionswould allow the crisis to be concluded.

2.2 Scope of the CMS

A crisis management system (CMS) should include the following functionalities:

– initiating a crisis based on an external input from a witness,– processing a crisis by executing the missions defined by a super observer and then

assigning internal and/or external resources,– wrapping-up and archiving crisis,– authenticating users,– handling communication between coordinator/system and resources.

A CMS replaces existing crisis management systems that a) still manually keeptrack of important crisis-related information and that b) operate largely without auto-mated support for crisis resolution strategies in order to respond to a crisis.

2.3 Non-functional Requirements of the CMS

The crisis management system shall exhibit the following non-functional properties:

– Availability• The system shall be in operation 24 hours a day, everyday, without break,

throughout the year except for a maximum downtime of 2 hours every 30 daysfor maintenance.

• The system shall recover in a maximum of 30 seconds upon failure.• Maintenance shall be postponed or interrupted if a crisis is imminent without

affecting the systems capabilities.– Reliability

• The system shall not exceed a maximum failure rate of 0.001%.• The mobile units shall be able to communicate with other units on the crisis site

and the control centre regardless of location, terrain and weather conditions.– Persistence

• The system shall provide support for storing, updating and accessing the fol-lowing information on both resolved and on-going crises: type of crisis; lo-cation of crisis; witness report; witness location; witness data; time reported;duration of resolution; resources deployed; civilian casualties; crisis manage-ment personnel casualties; strategies used; missions used; location of superobserver; crisis perimeter; location of rescue teams on crisis site; level of emis-sions from crisis site; log of communications; log of decisions; log of problemsencountered.

3

• The system shall provide support for storing, updating and accessing the fol-lowing information on available and deployed resources (both internal and ex-ternal): type of resource (human or equipment); capability; rescue team; loca-tion; estimated time of arrival (ETA) on crisis site.

• The system shall provide support for storing, updating and accessing the fol-lowing information on crisis resolution strategies: type of crisis; step-by-stepguide to resolve crisis; configuration of missions required; links to alternatestrategies; applications to previous crises; success rate.

– Real-time• The control centre shall receive and update the following information on an on-

going crisis at intervals not exceeding 30 seconds: resources deployed; civiliancasualties; crisis management personnel casualties; location of super observer;crisis perimeter; location of rescue teams on crisis site; level of emissions fromcrisis site; estimated time of arrival (ETA) of rescue teams on crisis site.

• The delay in communication of information between control centre and rescuepersonnel as well as amongst rescue personnel shall not exceed 500 millisec-onds.

• The system shall be able to retrieve any stored information with a maximumdelay of 500 milliseconds.

– Security• The system shall define access policies for various classes of users. The ac-

cess policy shall describe the components and information each class may add,access and update.

• The system shall authenticate users on the basis of the access policies whenthey first access any components or information. If a user remains idle for 30minutes or longer, the system shall require them to re-authenticate.

• All communications in the system shall use secure channels compliant withAES-128 standard encryption.

– Mobility• Rescue resources shall be able to access information on the move.• The system shall provide location-sensitive information to rescue resources.• Rescue resources shall communicate their location to the control centre.• The system shall have access to detailed maps, terrain data and weather condi-

tions for the crisis location and the routes leading to it.– Statistic Logging

• The system shall record the following statistical information on both on-goingand resolved crises: rate of progression; average response time of rescue teams;individual response time of each rescue team; success rate of each rescue team;rate of casualties; success rate of missions.

• The system shall provide statistical analysis tools to analyse individual crisisdata and data on multiple crises.

– Multi-Access• The system shall support at least 1000 witnesses calling in at a time.• The system shall support communication, coordination and information access

for at least 20000 rescue resources in deployment at a time.• The system shall support management of at least 100 crises at a time.

4

• The system shall support management of at least 200 missions per crisis at atime.

– Safety• The system shall monitor emissions from the crisis site to determine safe oper-

ating distances for rescue resources.• The system shall monitor weather and terrain conditions at crisis site to ensure

safe operation and withdrawal of rescue resources, and removal of civilians andcasualties.

• The system shall determine a perimeter for the crisis site to ensure safety ofcivilians and removal of casualties to a safe distance.

• The system shall monitor criminal activity to ensure safety of rescue resources,civilians and casualties.

• The safety of rescue personnel shall take top priority for the system.– Adaptability

• The system shall recommend alternate strategies for dealing with a crisis asthe crisis conditions (e.g., weather conditions, terrain conditions, civilian orcriminal activity) change.

• The system shall recommend or enlist alternate resources in case of unavail-ability or shortage of suitable resources.

• The system shall be able to use alternate communication channels in case ofunavailability or shortage of existing channels.

• The system shall be able to maintain effective communication in areas of highdisruption or noise at the crisis site.

– Accuracy• The system shall have access to map, terrain and weather data with a 99%

accuracy.• The system shall provide up-to-date information to rescue resources.• The system shall record data upon receipt without modifications.• The communication between the system and rescue resources shall have a max-

imum deterioration factor of 0.0001 per 1000 kilometres.

2.4 Car Crash Crisis Management SystemSome of the models presented in this paper focus on one particular CMS: the car crashcrisis management system (CCCMS). The CCCMS includes all the functionalities ofgeneral crisis management systems, and some additional features specific to car crashessuch as facilitating the rescuing of victims at the crisis scene and the use of tow trucksto remove damaged vehicles.

Scope of the CCCMS A car accident or car crash is an incident in which an auto-mobile collides with anything that causes damage to the automobile, including otherautomobiles, telephone poles, buildings or trees, or in which the driver loses control ofthe vehicle and damages it in some other way, such as driving into a ditch or rollingover [2]. Sometimes a car accident may also refer to an automobile striking a human oranimal.

Our CCCMS addresses car crashes involving single or multiple vehicles, humans,or other objects. This case study is however limited to management of human victims

5

only and does not provide rescue missions specifically for animals. First-aid animalworkers are not included in the scope of this case study either.

Car crash specific functionalities include the following:

– facilitating the rescue mission carried out by the police by providing them withdetailed information on the location of the crash;

– managing the dispatch of ambulances or other alternate emergency vehicles totransport victims from the crisis scene to hospitals;

– facilitating the first-aid missions by providing relevant medical history of identifiedvictims to the first-aid workers by querying databases of local hospitals;

– facilitating the medical treatment process of victims by providing important infor-mation about the crash to the concerned workers, i.e. paramedics, doctors, uponarrival at the hospital;

– managing the use of tow trucks to remove obstacles and damaged vehicles from thecrisis scene.

CCCMS Actors The actors involved in the CCCMS are defined in this section.

– Coordinator oversees management of the crisis by coordinating the resources andcommunicating with all the CMS employees and external workers.

– Super Observer is dispatched to the crisis scene to evaluate the situation and definethe necessary missions to cope with the crisis.

– CMS Employee is an internal human resource who is qualified and capable ofperforming missions related to his field of expertise. The worker acts as a facilitatoractor when he is in charge of or operating local resources (for example, tow trucksor ambulances).

– External Worker is an external resource who is specialized and capable of per-forming missions related to his field of expertise. The worker acts as a facilitatoractor when he is in charge of or operating external resources (for example, policetrucks or fire trucks).

– System Admin is the specialist who maintains the system and creates all profilesof workers and resources to feed the crisis management database.

– Witness is the person who reports the crisis by calling the crisis management cen-ter.

– Phone Company is an external entity contacted for verification of witness pur-poses.

– Surveillance System is an external entity which monitors traffic in highways andcities with the use of cameras.

3 Crisis Management System: Feature Models

Since there are so many different kinds of crises, the domain of crisis management sys-tems is very broad. However, any crisis management system has a common set of re-sponsibilities and functionalities. It is therefore natural to build a framework or productline of crisis management systems, which can be specialized to create crisis manage-ment systems for a particular kind of crisis and a particular context. A feature diagram

6

Ref: productLone-react-v07.pdf Print date: 2009-03-11

Title: Software Product Line Analysis

and Design of REACT Author(s): Optimal Security Page: 14/30

14

Figure 7: Crisis Management System, Part 3

Figure 8 presents the full feature diagram of the crisis management system.

Fig. 1. Crisis Management Systems Feature Diagram – Part 1Ref: productLone-react-v07.pdf Print date: 2009-03-11

Title: Software Product Line Analysis

and Design of REACT Author(s): Optimal Security Page: 12/30

12

!"#$#$%&'(')*+*(,%

-.$,*+

!"#$#$%/.0*$

-122*(%!"#$*$ -+342*"#()%!"#$*$

&'(2',3".

50,#3('4

64,*"(',#7*%893":

;*)*(2

<',1"'4%=#$'$,*"$

/*""3"#$,%6,,'>?

@4'(,%AB043$#3(@"321>,%

/'+0*"#()

-'C3,')*

AB*>1,#7*%?#2('00#()

D3$,#4*%/'?*37*"

A(7#"3(+*(,'4%-0#44

/*>E(343).%=#$"10,#3(

$,3"+

E1""#>'(* $(3F$,3"+

&'G3"%6>>#2*(,

!'"%!"'$E

@4'(*%!"'$E

H3+C%',,'>?

!E*+#>'4%

',,'>?

*0#2*+#>

<1>4*'"%@4'(,%

AB043$#3( !E*+#>'4%@4'(,%

AB043$#3(

/"'2#,#3('4%@4'(,%

AB043$#3(

I#"*I4332

*'",EJ1'?*

6"*'

$+'44 +*2#1+ 4'")*

Figure 5: some types of crises

The next feature diagram describes the “services” which can be used to deal with a crisis. The

diagram is depicted in Figure 6.

!"#$#$%&'(')*+*(,%

-.$,*+

AB,*"('4%-*"7#>*$%

1$*2

K37*"(+*(,'4%

-*"7#>*$

&'(2',3".

50,#3('4

64,*"(',#7*%893":

;*)*(2

&*2#>'4%-*"7#>*$

L#"*+'(

@34#>*+'(

@1C4#>%D3$0#,'4% M(2*0*(2*(,%

L#"$,N6#2%

=3>,3"

@"#7',*%D3$0#,'4

L#"*%

2*0'",+*(,

@34#>*

6"+.

<'7.

/E*%6"+. 6#"%L3">*

;3)#$,#>%

O*E#>4*

-342#*"

6#"%L3">*%

-342#*"

<'7.%

-342#*"

C3',

@34#>*%

-0*>#'4%P(#,

L3>1$%3(%,E*%"*$31">*$

L#"*%/"1>?

D3$0#,'4

Q3"?*"

L#"$,N6#2%

=3>,3"

L#"$,N6#2%

Q3"?*"

@"#7',*%

'+C14'(>*%

>3+0'(.

0"#7',*%

'+C14'(>*%

'+C14'(>*%

AB,*"('4%

!3+0'(.

*4*>,"#>#,.

,*4*>3+

6"+.%

-0*>#'4%P(#,

6#">"'I,D*4#>30,*"

!'")3N

'#">"'I,

L4.#()M,*+

K'"')*

/3F%/"1>?

Figure 6: Resources Needed

Fig. 2. Crisis Management Systems Feature Diagram – Part 2

7

Ref: productLone-react-v07.pdf Print date: 2009-03-11

Title: Software Product Line Analysis

and Design of REACT Author(s): Optimal Security Page: 12/30

12

!"#$#$%&'(')*+*(,%

-.$,*+

!"#$#$%/.0*$

-122*(%!"#$*$ -+342*"#()%!"#$*$

&'(2',3".

50,#3('4

64,*"(',#7*%893":

;*)*(2

<',1"'4%=#$'$,*"$

/*""3"#$,%6,,'>?

@4'(,%AB043$#3(@"321>,%

/'+0*"#()

-'C3,')*

AB*>1,#7*%?#2('00#()

D3$,#4*%/'?*37*"

A(7#"3(+*(,'4%-0#44

/*>E(343).%=#$"10,#3(

$,3"+

E1""#>'(* $(3F$,3"+

&'G3"%6>>#2*(,

!'"%!"'$E

@4'(*%!"'$E

H3+C%',,'>?

!E*+#>'4%

',,'>?

*0#2*+#>

<1>4*'"%@4'(,%

AB043$#3( !E*+#>'4%@4'(,%

AB043$#3(

/"'2#,#3('4%@4'(,%

AB043$#3(

I#"*I4332

*'",EJ1'?*

6"*'

$+'44 +*2#1+ 4'")*

Figure 5: some types of crises

The next feature diagram describes the “services” which can be used to deal with a crisis. The

diagram is depicted in Figure 6.

!"#$#$%&'(')*+*(,%

-.$,*+

AB,*"('4%-*"7#>*$%

1$*2

K37*"(+*(,'4%

-*"7#>*$

&'(2',3".

50,#3('4

64,*"(',#7*%893":

;*)*(2

&*2#>'4%-*"7#>*$

L#"*+'(

@34#>*+'(

@1C4#>%D3$0#,'4% M(2*0*(2*(,%

L#"$,N6#2%

=3>,3"

@"#7',*%D3$0#,'4

L#"*%

2*0'",+*(,

@34#>*

6"+.

<'7.

/E*%6"+. 6#"%L3">*

;3)#$,#>%

O*E#>4*

-342#*"

6#"%L3">*%

-342#*"

<'7.%

-342#*"

C3',

@34#>*%

-0*>#'4%P(#,

L3>1$%3(%,E*%"*$31">*$

L#"*%/"1>?

D3$0#,'4

Q3"?*"

L#"$,N6#2%

=3>,3"

L#"$,N6#2%

Q3"?*"

@"#7',*%

'+C14'(>*%

>3+0'(.

0"#7',*%

'+C14'(>*%

'+C14'(>*%

AB,*"('4%

!3+0'(.

*4*>,"#>#,.

,*4*>3+

6"+.%

-0*>#'4%P(#,

6#">"'I,D*4#>30,*"

!'")3N

'#">"'I,

L4.#()M,*+

K'"')*

/3F%/"1>?

Figure 6: Resources Needed

Fig. 3. Crisis Management Systems Feature Diagram – Part 3

listing many possible features of a crisis management system is given in Figs. 1 to 3. Ithas been taken from [3].Selection of some features requires the selection of other features. Examples of suchdependencies are:

– Natural Disasters requires Fire Department and External Company– Terrorist Attack requires Army Special Unit and Police and Police Special Unit and

Public Hospital– Major Accident requires Police and Fire Department and Public Hospital and Pri-

vate Hospital and Independent First-Aid Doctor and Private Ambulance Company– Plant Explosion requires Police and Fire Department and Public Hospital– Nuclear Plant Explosion requires The Army and Army Special Unit

Fig. 4 presents a possible set of features selected for the car crash CMS.

4 Car Crash Crisis Management System: Use Cases

Use cases [4, 5] are a widely used formalism for discovering and recording behavioralrequirements of software systems, since they can be effectively used as a communi-cation means between technical as well as non-technical stakeholders of the softwareunder development. In short, use cases are stories of using a system to meet goals. Theyare in general text-based, but their strength is that they both scale up or scale down interms of sophistication and formality, depending on the need and context.

8

Ref: productLone-react-v07.pdf Print date: 2009-03-11

Title: Software Product Line Analysis

and Design of REACT Author(s): Optimal Security Page: 24/30

24

5) Examples of Product

5.1) Car Crash Management System

Figure 16 presents the set of selected features corresponding to the car crash management

system product.

!"#$#$%&'(')*+*(,%

-.$,*+

/0,1*(,#2',#3(%

-.$,*+

4','5'$*%

-.$,*+

6789:,#3(

&#$$#3(

;*$20*

95$*"<*

;*+3<*%

95$,'2=*

,"'($:3",

#(<*$,#)',#3(

>0"$*%,1*%

?30(@*@

-3",%,1*%

?30(@*@

A-&

B3()8@#$,'(2*%2'==

CD,*"('=%-*"<#2*$%

0$*@

A3<*"(+*(,'=%

-*"<#2*$ &*@#2'=%-*"<#2*$

E#"*+'(

F3=#2*+'(

F05=#2%G3$:#,'=%

E#"*%

@*:'",+*(,F3=#2*

G3$:#,'=

H3"I*"

E#"$,8/#@%

H3"I*"

F"#<',*%

'+50='(2*%

23+:'(.

'+50='(2*%

CD,*"('=%

!3+:'(.

!"#$#$%7.:*$

-0@@*(%!"#$*$

&'J3"%

/22#@*(,

!'"%!"'$1

-0"<*#=='(2*%

-.$,*+

/"*'

$+'==

G0+'(%K#2,#+$ H#,(*$$

!33"@#(',3"

35$*"<*"

H3"I*"

6(,*"('=;*$30"2*

E/8

H3"I*"

-.$,*+/@+#(

E#"$,/#@

&',*"#'= G0+'(

;*$30"2*

A'"')*

73?%7"02I

Figure 16: Set of Features corresponding to the Car Crash Management System

After the selection of these features, we automatically obtain the full analysis model (class

diagram) of the Car Crash Management system.

Fig. 4. Car Crash Crisis Management Systems Feature Diagram

9

Crisis Management System: Car Crash Case Study

<<include>>

<<include>>

<<include>>

<<inc

lude>

>

Resolve Crisis

Capture Witness Report

AssignIntResource

RequestExtResource

Execute Mission

Execute Helicopter Transport Mission

ExecuteRescue Mission

Execute SuperObserver

Mission

1

Coordinator

1

SuperObserver

*

CMSEmployee

AuthenticateUser

ExecuteRemove Obstacle

Mission

ExternalResourceSystem

*

1

PhoneCompany

*

SurveillanceSystem

<<include>>

<<include>>

1..*

Witness

*

FirstAidWorker

1

Pilot

*

HospitalResourceSystem

*

Resource

Fig. 5. CCCMS: Standard Use Case Diagram

Fig. 5 shows the use cases related to the summary-level goal Resolve Crisis in theCCCMS by means of a use case diagram.

Details of all the use cases that directly relate to the summary level use case ResolveCrisis are given in section 4.1. The listed use cases are: Resolve Crisis, Capture WitnessReport, Assign Internal Resource, Assign External Resource, Execute Mission, ExecuteSuperObserver Mission, Execute Rescue Mission, and Authenticate User.

Use cases describing other missions, such as the Execute Helicopter Transport Mis-sion, or Execute Remove Obstacle Mission are not shown for space reasons. Likewise,details of use cases related to the management of the resource database are not includedfor space reasons. Such use cases would, for instance, include:

– Creating records for CMSEmployees– Managing access rights of CMSEmployees– Updating the availability of CMSEmployees due to sickness or vacation– Dealing with problems of the CMS-controlled vehicles that are not related to a

crisis

Finally, following a dependability-oriented requirements engineering process suchas DREP [6], exceptional situations that a CMS might be exposed to should also beconsidered. For this case study, several exceptional situations were discovered that af-fect the context in which the system operates, and that require the system to react in acertain way to continue to provide reliable and safe service. The situations are:

– Severe Weather Conditions: Bad weather makes helicopter transportation impossi-ble.

– Strike: A strike affects the availability of CMS employees and external workers.– Risk of Explosion: Leaking gas and open fire threatens the safety of workers.

10

– VIP Victim: One of the crash victims is a VIP (such as for instance, the president).Handling of the crisis should therefore be coordinated by the appropriate office.

– Criminal Case: The reason for the crash is of criminal nature, and therefore therescue missions have to be carried out accordingly.

To detect and to handle the above situations, we added the following exceptional ac-tors: WeatherInformationSystem, NationalCrisisCenter. The detailed handler use casesthat describe the functionality that such a reliable CCCMS is to provide are not de-scribed in this document for space reasons.

4.1 Textual Use Cases

The use cases presented here follow a textual template. The main success scenario isa numbered list of lines of text (subsequently named steps) that describes the possi-ble interactions between the primary actor, potential secondary actors and the CCCMS(subsequently named System) that occur to reach a particular goal. Alternate ways ofachieving a goal, or situations in which the goal can not be reached, are described in theextension part of the template.

Resolve Crisis

Use Case 1: Resolve CrisisScope: Car Crash Crisis Management SystemPrimary Actor: CoordinatorSecondary Actor: ResourceIntention: The intention of the Coordinator is to resolve a car crash crisis by asking employees

and external workers to execute appropriate missions.Main Success Scenario:

Witness places a call to the crisis centre, where it is answered by a Coordinator.1. Coordinator captures witness report (UC 2).2. System recommends to Coordinator the missions that are to be executed based on thecurrent information about the crisis and resources.3. Coordinator selects one or more missions recommended by the system.For each mission in parallel:

4. For each internal resource required by a selected mission,System assigns an internal resource (UC 3).

5. For each external resource required by a selected mission,System requests an external resource (UC 4).

6. Resource notifies System of arrival at mission location.7. Resource executes the mission (UC 5).8. Resource notifies System of departure from mission location.9. In parallel to steps 6-8, Coordinator receives mission status updates from System.10. In parallel to steps 6-8, System informs Resource of relevant changes to mission

or crisis information.11. Resource submits the final mission report to System.

12. In parallel to steps 4-8, Coordinator receives new crisis-related information from System.13. Coordinator closes the file for the crisis resolution.Use case ends in success.

11

Extensions:1a. Coordinator is not logged in.

1a.1 Coordinator authenticates with System (UC 10).1a.2 Use case continues with step 1.

4a. Internal resource is not available after step 4.4a.1 System requests an external resource instead (i.e., use case continues

in parallel with step 5).

5a. External resource is not available after step 5.5a.1 Use case continues in parallel with step 2.

6a. System determines that the crisis location is unreachable by standard transportation means,but reachable by helicopter.

6a.1 System informs the Coordinator about the problem.6a.2 Coordinator instructs System to execute a helicopter transport mission (UC 09).6a.3 Use case continues with step 6.

6b. Resource is unable to contact System.6b.1 SuperObserver notifies System that resource arrived at the mission location.

6c. Although Resource should be at mission location by now, Resource has not yet notifiedSystem.

6c.1 System requests Resource to provide an update of its location.6c.2 Use case continues at step 6.

7a. One or more further missions are required in step 6.7a.1 Use case continues in parallel with step 2.

7b. The mission failed.7b.1 Use case continues with step 2.

8a. Resource is unable to contact System.8a.1 SuperObserver notifies System that resource is leaving the mission location.

8b. Although mission should be completed by now, Resource has not left mission location.8b.1 System requests Resource to provide the reason for the delay.8b.2 Use case continues at step 7.

9a. Changes to mission are required.9a.1 Use case continues in parallel with step 2.

11a. Resource never files a mission report.11a.1 Mission use case ends without mission report.

12a. Changes to mission are required.12a.1 Use case continues in parallel with step 2.

Capture Witness Report

Use Case 2: Capture Witness ReportScope: Car Crash Crisis Management SystemPrimary Actor: CoordinatorSecondary Actor: PhoneCompany, SurveillanceSystemIntention: The Coordinator intends to create a crisis record based on the information obtained

from witness.Main Success Scenario:

Coordinator requests Witness to provide his identification.1. Coordinator provides witness information1 to System as reported by the witness.

12

2. Coordinator informs System of location and type of crisis as reported by the witness.In parallel to steps 2-4:

2a.1 System contacts PhoneCompany to verify witness information.2a.2 PhoneCompany sends address/phone information to System.2a.3 System validates information received from the PhoneCompany.

3. System provides Coordinator with a crisis-focused checklist.4. Coordinator provides crisis information2 to System as reported by the witness.5. System assigns an initial emergency level to the crisis and sets the crisis status to active.Use case ends in success.

Extensions:1a,2a. The call is disconnected. The base use case terminates.In parallel to steps 3-4, if the crisis location is covered by camera surveillance:

3a.1 System requests video feed from SurveillanceSystem.3a.2 SurveillanceSystem starts sending video feed to System.3a.3 System starts displaying video feed for Coordinator.

4a. The call is disconnected.4a.1 Use case continues at step 5 without crisis information.

5a. PhoneCompany information does not match information received from Witness.5a.1 The base use case is terminated.

5b. Camera vision of the location is perfect, but Coordinator cannot confirm the situationthat the witness describes or the Coordinator determines that the witness is calling in a fakecrisis.

5b.1 The base use case is terminated.

1Witness information includes the first name, last name, phone number, and address.2Crisis information includes the details about the crisis, the time witnessed, etc...

Assign Internal Resource

Use Case 3: Assign Internal ResourceScope: Car Crash Crisis Management SystemPrimary Actor: NoneSecondary Actor: CMSEmployeeIntention: The intention of System is to find, contact, and assign a mission to the most appro-

priate available CMSEmployee.Main Success Scenario:

System selects an appropriate CMSEmployee based on the mission type, the emergency level,location and requested expertise. In very urgent cases, steps 1 and 2 can be performed forseveral CMSEmployees concurrently, until one of the contacted employees accepts the mis-sion.1. System sends CMSEmployee mission information.2. CMSEmployee informs System that he accepts the mission.Use case ends in success.

Extensions:1a. CMSEmployee is not logged in.

1a.1 System requests the CMSEmployee to login.1a.2 CMSEmployee authenticates with System (UC 10).1a.3 Use case continues at step 1.

1b. CMSEmployee is unavailable or unresponsive.1b.1 System selects the next appropriate CMSEmployee.

13

1b.2 Use case continues at step 1.1b.1a No other CMSEmployee is available. Use case ends in failure.

2a. CMSEmployee informs System that he cannot accept the mission.2a.1 System selects the next appropriate CMSEmployee.2a.2 Use case continues at step 1.

2a.2a No other CMSEmployee is available. Use case ends in failure.

Request External Resource

Use Case 4: Request External ResourceScope: Car Crash Crisis Management SystemPrimary Actor: CoordinatorSecondary Actor: ExternalResourceSystem (ERS)Intention: The System requests a mission from an external resource, such as a fire station, police

station or external ambulance service.Main Success Scenario:

1. System sends mission request to ERS, along with mission-specific information1.2. ERS informs System that request can be processed.Use case ends in success.

Extensions:2a. ERS notifies System that it partially approves request for resources. Use case ends in de-graded success.2b. ERS notifies System that it can not service the request. Use case ends in failure.

1Mission-specific information includes things such as the location and emergency level ofthe mission, the quantity of vehicles requested, special characteristics of the aid worker orvehicle, etc...

Execute Mission

Use Case 5: Execute MissionIntention: The Resource executes a mission in order to help resolve a crisis. ExecuteMission is

an abstract use case. The details of the interaction for specific missions are presented in childuse cases such as ExecuteSuperObserverMission (UC 6), or ExecuteRescueMission (UC 7).

Execute SuperObserver Mission

Use Case 6: Execute SuperObserver MissionScope: Car Crash Crisis Management SystemPrimary Actor: SuperObserverSecondary Actor: NoneIntention: The intention of the SuperObserver is to observe the situation at the crisis site to be

able to order appropriate missions.Main Success Scenario:

SuperObserver is at the crisis location.1. System sends a crisis-specific checklist to SuperObserver.2. SuperObserver feeds System with crisis information.3. System suggests crisis-specific missions to SuperObserver.Steps 4-8 is repeated as many times as needed.4. SuperObserver notifies System of the type of mission he wants to create.

14

5. System sends a mission-specific information request to SuperObserver.6. SuperObserver sends mission-specific information1 to System.7. System acknowledges the mission creation to SuperObserver.8. System informs SuperObserver that mission was completed successfully.9. SuperObserver judges that his presence is no longer needed at the crisis location.Use case ends in success.

Extensions:7a. Mission cannot be created and replacement missions are possible.

7a.1 System suggests replacement missions to SuperObserver.7a.2 Use case continues with step 4.

7b. Mission cannot be created and no replacement missions are possible.7b.1 System suggests notifying the NationalCrisisCenter.7b.2 Use case continues with step 4.

8a. Mission failed.8a.1 System informs SuperObserver and Coordinator about mission failure.8a.2 Use case continues with step 4.

1Mission-specific information includes things such as the quantity of vehicles requested,special characteristics of the aid worker or vehicle, etc...

Execute Rescue Mission

Use Case 7: Execute Rescue MissionScope: Car Crash Crisis Management SystemPrimary Actor: FirstAidWorkerSecondary Actor: HospitalRSIntention: The intention of the FirstAidWorker is to accept and then execute a rescue mission

that involves transporting a victim to the most appropriate hospital.Main Success Scenario:

FirstAidWorker is at the crisis location.1. FirstAidWorker transmits injury information of victim to System.Steps 2 and 3 are optional.2. FirstAidWorker determines victim’s identity and communicates it to System.3. System requests victim’s medical history information from all connected HospitalRe-sourceSystems.FirstAidWorker administers first aid procedures to victim.4. System instructs FirstAidWorker to bring the victim to the most appropriate hospital.5. FirstAidWorker notifies System that he is leaving the crisis site.6. FirstAidWorker notifies System that he has dropped off the victim at the hospital.7. FirstAidWorker informs System that he has completed his mission.Use case ends in success.

Extensions:4a. HospitalResourceSystem transmits victim’s medical history information to System.

4a.1 System notifies FirstAidWorker of medical history of the victim relevant to his injury.4a.2 Use case continues at step 4.

Execute Helicopter Transport Mission

Use Case 8: Execute Helicopter Transport MissionScope: Car Crash Crisis Management System

15

Primary Actor: PilotSecondary Actor: NoneIntention: The intention of the Pilot is to accept and then execute a transport mission that in-

volves transporting a CMSEmployee to and from a mission location.Main Success Scenario: To be defined.

Execute Remove Obstacle Mission

Use Case 9: Execute Remove Obstacle MissionScope: Car Crash Crisis Management SystemPrimary Actor: TowTruckDriverSecondary Actor: NoneIntention: The intention of the TowTruckDriver is to accept and then execute a remove obstacle

mission that involves removing a crashed car from a mission location.Main Success Scenario: To be defined.

AuthenticateUser

Use Case 10: AuthenticateUserScope: Car Crash Crisis Management SystemPrimary Actor: NoneSecondary Actor: CMSEmployeeIntention: The intention of the System is to authenticate the CMSEmployee to allow access.Main Success Scenario:

1. System prompts CMSEmployee for login id and password.2. CMSEmployee enters login id and password into System.3. System validates the login information.Use case ends in success.

Extensions:2a. CMSEmployee cancels the authentication process. Use case ends in failure.3a. System fails to authenticate the CMSEmployee.

3a.1 Use case continues at step 1.3a.1a CMSEmployee performed three consecutive failed attempts.

3a.1a.1 Use case ends in failure.

5 Car Crash Crisis Management System: Domain Model

The domain model offers insight into the problem domain, in our case the car crashcrisis management system. Taking the form of a UML class diagram, it provides adescription of the concepts of the problem domain relevant to the CCCMS, by repre-senting the concepts as classes, attributes and associations between classes. Althoughany domain concept could be added to the domain model, we decided to include hereonly concepts that must define information that must be recorded for the purpose offulfilling the system’s responsibilities over time. In other words, the domain model pre-sented here only contains concepts that are used to describe the necessary informationto fulfill system goals.

Because of size constraints, the domain model is split into two parts. The top part ofFig. 6 depicts the Crisis and Mission concepts and how they relate to the other concepts,whereas the bottom part shows the generalization/specialization hierarchies inherent inthe domain of the CCCMS.

16

observedBy1..*

10..*witnessCL

1missionCL 1

CheckListCrisisType

CarCrash

0..*

1

WorkeremergencyLevellocationstartTimeendTimestatusdetailedInfo

Mission involvedW0..*

ExternalWorkerCMSEmployee

ExternalResourceSystem

1 employer0..*

MobileEmployee0..*0..1transportedByVehicle

missionLeader 1

0..* crashedVehicle

Victim involvedVictim0..*

0..1wasIn

Medium gatheredMedium0..* emergencyLevel

affectedAreastartTimeendTimestatusdetailedInfo

Crisis

assignedTo1Coordinator

Witness

nameaddressidentificationphonedateOfBirth

Person

 Witness

gsmexpertise

Worker

loginIdpasswordaccessRightsstatus

CMSEmployeeidcurrentLocation

ExternalWorker

 Coordinator

 SuperObserver

 Pilot

deceasedconciousmobileinjury

Victim

 SysAdmin

currentLocationpdaNumber

MobileEmployee

 Logistician

 FirstAidWorker

nameaddressphone

ExternalResourceSystem

MedicalRS GovernmentRS LogisticRS

HospitalRS PrivateAmbulanceRS

PoliceRS FireDepartmentRS

MechanicRS

TowingRS

CleaningRS

RoadRepairRS

licenseserialNumbercolor

Vehicle

 Car

 Truck

 Bike

 Train

 Helicopter

 Ambulance

 Medium

 Photo

 Movie

 Sound

SurveillanceRS

Fig. 6. CCCMS Domain Model

17

6 Car Crash Crisis Management System:Informal Physical Architecture Description

A typical architecture for a crisis management system contains many machines that areconnected with different types of networks. Fig. 7 gives an overview of the kinds of ma-chines and communication networks that could be used in an instance of the CCCMS.

Terminal

Workstation

GovernmentSystem

Desktop PC

Macintosh

Laptop

PoliceSystem

VPN GatewayFile Server

Relational DatabaseSingle Server

or Server Cluster

Long-term StorageLogging Host

Phone

CellularPhone

AuthenticationServer

GSM Antenna

PDAGPS

HospitalSystem

Fire DepartmentSystem

SurveillanceSystem

Fig. 7. CCCMS: Physical Architecture

The backend of the system is composed of a server or a server cluster that im-plements most of the business functionality. Local CMS employees, such as the coor-dinators and the system administrators, use terminals or desktop machines to accessthe backend through a private network. External services and mobile CMS employeeswith laptops are connected to the backend by means of virtual private networks on topof public networks. Cell phones, GPS (Global Positioning System) devices and PDAs(Personal Desktop Assistants) are reached using a GSM (Global System for MobileCommunications) antenna.

In the network layer, several protocols can be used to transport the communications:GSM for voice, GSM for SMS (Short Message Service), UDP/TCP/IP for voice, and

18

TCP/IP for data exchange. In the application layer, several protocols can be used totransport the communications: proprietary protocols or standardized protocols (HTTP,SMTP, POP3, IMAP, XMPP, etc...)

7 Car Crash Crisis Management System: Selected Design Models

During design, a blue print of a solution that satisfies the requirements defined bythe analysis models is devised. In object-oriented design, the conceptual state has tobe mapped to objects, and then the developer has to decide how the conceptual statechanges specified in every system operation are to be implemented by interacting ob-jects at run-time.

The concepts identified during analysis, in our case e.g. Crisis, Mission, CMSEm-ployee, are initial candidates for becoming design objects that hold the application state.However, some concepts may be implemented using several objects, or, alternatively,some concepts may be implemented as attributes. The granularity of objects affectsseveral aspects of the system under development. Too fine-grained decomposition leadsto systems with thousands of objects. Such systems might be hard to understand andmaintain due to their high coupling, and generate huge communication overhead. Onthe other hand, a coarse decomposition leads to bulky architectures, and objects withunclear responsibilities, which can also be hard to understand and maintain. Good de-signers try to maximize object coherence, while minimizing object coupling.

The idea of this section is to present some design models of a possible object-oriented design of the CCCMS backend. Currently, the only functionality that is de-signed is the CreateMission functionality that is triggered by the SuperObserver whenordering missions to deal with the crash.

7.1 Creating Missions

Summary of Functionality The CreateMission functionality allows the SuperOb-server to inform the CCCMS about a mission that needs to be accomplished in order todeal with the crash. The system has to store the relevant mission information, determinethe candidate CMSEmployees that could accomplish the mission, establish contact withat least one of them and propose the mission to him. The design of CreateMission alsoimplements some secondary functionality. For instance, it takes care of gathering statis-tics on how many potential candidate employees the system was able to choose fromwhen assigning the mission. Also, it makes sure that employees have properly loggedinto the system (and hence authenticated) before sending them mission related infor-mation.

Interaction Design It is assumed that somehow the user interface on the PDA allowsthe SuperObserver to select the appropriate mission kind, select the emergency levelof the mission and enter detailed mission information before sending the request tothe CCCMS backend. The sequencing of message exchanges between objects that aretriggered by this request are shown in a sequence diagram in Fig. 8.

19

currentEmpl := next()

emplLocation := getLocation()

: Map

size := getSize()

foundEmployees := clone()

available := isAvailable()

      missionLocation := getLocation()

exp := getRequiredExpertise()

foundEmployees := find(exp)    foundColl := get(exp)

: ResourceManager

m: Mission

myEmployees:EmplHashTable

foundEmployees: EmplColl

initiateAssignment(m)

foundColl:EmplColl

loop [currentEmpl within foundEmployees]

currentEmpl:CMSEmployee

opt [available]

time := travelTime(emplLocation, missionLocation)

opt [time < maxStartDelay]

      maxStartDelay := getMaxStartDelay()

create()

candidates:EmplPriorityList

create()

insert(currentEmpl, score)

                score := adequacyScore(currentEmpl, time)

: StatisticsnumberOfCandidates(size)

empl := removeFirst()

empl: CMSEmployeecontactAbout(m)

alt [not loggedIn]

req: LoginRequestSMS

create(emplSMSNumber)

: SMSSendersend(req)

[else] : PDASendersendMissionProposal(myPDAConnection, m)

                setStatus(contacting, m)

                setStatus(proposing, m)

setCandidates(candidates)

: CrisisManager

createMission (su: SuperObserver,   kind: MissionKind,   level: EmergencyLevel,   details: MissionDetails)

create(currentCrisis,    level, details)

currentCrisis: Crisis

addMission(m)

su: SuperObserver

currentCrisis := getCrisis()

Fig. 8. CCCMS: CreateMission Design Sequence Diagram

The initial request is directed to the CrisisManager. After instantiating a new mis-sion object and linking it to the crisis, the crisis manager hands the responsibility ofassigning the mission to a CMSEmployee to the ResourceManager. The resource man-ager has access to a hash table of employees indexed by expertise, and hence is able to

20

obtain a collection of employees that are qualified to execute the mission. The resourcemanager then proceeds by looping though this list, and inserting any available employee(i.e. an employee that currently is not affected to other missions or otherwise unavail-able) that is close enough to the mission location (i.e. can get to the mission locationin a reasonable amount of time) into a priority queue. In the queue, the employees aresorted with respect to their ”adequacy” for performing the mission. Once this list is es-tablished, the size of the list is remembered for statistical purpose. Finally, the resourcemanager proceeds by contacting the first employee on the list. If that employee is notcurrently logged in, then he is requested to do so by sending him an SMS.

The interaction design ends here, because the system now has to wait for an an-swer from the employee (which can either be a login request, or a mission acceptancenotification).

Structural Design The chosen design solution presented in the sequence diagram hasmany implications on the design. It assumes, for instance, the existence of many classeswith particular fields and method definitions. Also, some permanent associations are as-sumed to exist. For example, a super observer must be associated with a crisis. This isobvious from the first message in the sequence diagram in Fig. 8. Another example isthe employee hash table that can find employees based on a particular expertise. TheCreateMission design assumes that this hash table already exists. This means that thefunctionality that deals with the creation of employees must also take care of build-ing this hash table, establishing permanent references between expertise and groups ofemployees.

The classes, attributes and methods, and the dependencies and associations betweenclasses created, used and assumed by the CreateMission design are shown in Fig. 9.

8 Acknowledgments

The authors would like to thank Christian Fischer, Damien Garot, Laurent Vuillermoz,Jacques Klein and Alfredo Capozucca for sharing requirements documents and mod-els of crisis management systems with us. Their contributions led to the creation ofthe first draft of this document. Our thanks also extend to Mehmet Aksit, Wisam AlAbed, Joao Araujo, Florencia Balbastro, Franck Fleurey, Jean-Marc Jezequel, GunterMussbacher, Awais Rachid, Pablo Sanchez and Jon Whittle, the participants of the first1-week aspect-oriented modeling workshop held at the Bellairs Research Institute ofMcGill University from April 5th to April 12th 2009. Their valuable input and sugges-tions significantly enhanced the quality of the requirements and use cases descriptions.

References

1. Optimal Security: Requirements document: Version 0.8. (March 2009)2. Wikicars.org: http://wikicars.org/en/Car accidents

21

numberOfCandidates(int) 

<<system-wide>>

Statistics1

employees1

RequestLoginSMS

destNumberSMS

boolean isAvailable()Location getLocation()setStatus(EmplStatus,Mission)contactAbout(Mission)

available: booleanloc: Locationstatus: EmplStatus

CMSEmployee

create(Crisis,EmergencyLevel,MissionDetails)Location getLocation()float adequacyScore(CMSEmployee,Time)Time getMaxStartDelay()Expertise getRequiredExpertise()

level: EmergencyLeveldetails: MissionDetailsloc: Location

MissionrelatedMission0..1

createMission(SuperObserver, MissionKind, EmergencyLevel,MissionDetails)

 

<<system-wide>>

CrisisManager 1

EmplColl find(Expertise)EmplColl get(Expertise)

 EmplHashTable

ExpertiseEmplColl clone()CMSEmployee next()

 EmplColl

0..*insert(CMSEmployee, float)

int getSize()CMSEmployee removeFirst()

 EmplPriorityList

0..*

<<instantiate>>

candidates0..1

initiateAssignment(Mission) 

<<system-wide>>

ResourceManager 1

Time travelTime   (Location, Location)

 

<<system-wide>>

Map

addMission(Mission) 

Crisis

0..*

1

SuperObserverobservedCrisis0..1 0..*

send(SMS) SMSSender 1

sendMissionProposal   (PDA,Mission)

 PDASender 1

Fig. 9. CCCMS: Partial Design Class Diagram based on CreateMission Design

3. Optimal Security: Product line document: Version 0.7. (March 2009)4. Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object-Oriented Software Engineer-

ing: A Use Case Driven Approach. Addison–Wesley (1992)5. Cockburn, A.: Writing Effective Use Cases. Addison–Wesley (2000)6. Mustafiz, S., Kienzle, J.: DREP: A Requirements Engineering Process for Dependable Re-

active Systems. In Romanovsky, A., Jones, C., Knudsen, J.L., Tripathi, A., eds.: Methods,Models and Tools for Fault Tolerance. Number 5454 in Lecture Notes in Computer Science,Springer Verlag (2009) 220 – 250

22