1

Case Study: Modeling a Crisis Management Systemsusing the AMoDE-RT approach and DERAF

Marco A. Wehrmeister Informatics DepartmentFederal University of Technology – Parana (UTFPR), Curitiba, Brazil

Email: wehrmeister@utfpr.edu.br

Abstract

This manuscript describes a UML model for the Crisis Management System (bCMS) that has been created usingthe Aspect-oriented Model-Driven Engineering for Real-Time systems (AMoDE-RT) design approach. Such a modelfollows AMoDE-RT modeling guidelines, and includes the handling of non-functional requirements specification usingaspect-oriented concepts, such as the Distributed Embedded Real-time Aspects Framework (DERAF), the AspectsCrosscutting Overview Diagram (ACOD), and the Join Point Designation Diagram (JPDD). bCMS static structure isdepicted using the class diagram, whereas its overall behavior is shown using the UML state machine diagram. Theindividual runtime scenarios are specified using sequence diagrams. This case study demonstrates how AMoDE-RTmight be used outside the context of the embedded systems domain, since the bCMS covers an information systemand more resourceful computing systems.

I. INTRODUCTION

This paper concentrates on describing the modeling phase of the Aspect-oriented Model-Driven Engi-neering for Real-Time systems (AMoDE-RT) design approach for embedded real-time system. Specifically,this contribution aims the Third International Comparing Requirements Modeling Approaches (CMA@RE2013) workshop1, whose goal is to analyze various modeling approaches in the context of a focused casestudy, in order to discuss under which conditions each approach is more applicable. For that, a CrisisManagement System (bCMS) [4] has been used as the case study. bCMS has been modeled with theUnified Modeling Language (UML) and AMoDE-RT modeling guidelines, including the non-functionalrequirements specification using aspect-oriented concepts, such as Distributed Embedded Real-time AspectsFramework (DERAF), Aspects Crosscutting Overview Diagram (ACOD), and Join Point Designation Di-agram (JPDD). A common comparison criteria2 has been used to evaluate all created bCMS models, andhence, the analysis of these approaches features is going to be performed during the CMA@RE workshop.

As mentioned, bCMS has been modeled with UML. Therefore, the bCMS functional requirements havebeen specified using regular UML diagrams. The bCMS (static) structure is depicted using the class diagram,whereas its overall behavior is shown using the UML state machine diagram. The individual runtimescenarios are specified using sequence diagrams. DERAF aspects have been used to specify the handling ofthe non-functional requirements as described in the bCMS requirements document3. Three non-functionalrequirements have been explicitly mentioned: integrity, availability, and performance. Additionally, onemight perceive the time constraints on some bCMS activities. From these non-functional requirements,only performance and time are addressed by the current version of DERAF. Thus, new aspects have beencreated (following AMoDE-RT guidelines) to specify the complete set of bCMS requirements.

In this sense, it is important to highlight that AMoDE-RT (and hence, DERAF) has been proposed toaddress the problems in the design of embedded and real-time systems whose services could be distributedover distinct processing nodes. As the bCMS case study presents elements that are not usually found in thecontext of the embedded systems domain, e.g. a database, user interface, and more resourceful computingsystems, this is the first case study that uses the AMoDE-RT approach outside the embedded systems

1http://cserg0.site.uottawa.ca/cma2013re/index.htm2http://cserg0.site.uottawa.ca/cma2013re/ComparisonCriteria.pdf3http://cserg0.site.uottawa.ca/cma2013re/CaseStudy.pdf

2

Libraries

Mapping Rules (XML)

Sw/Hw Platforms

DERAF Aspects Implementation

(10)

RT-UML Specification

+ DERAF (5)

RT-UML Model Transformation (6)

DERCS Model

(7)

GenERTiCA

Code Generation

+ Aspects Weaving (9)

Generated Source Code (12)

Code Compilation

and Synthesis (11)

Distributed Embedded

Real-Time System

Modeling (4)

Requirements (2)

Requirements Analysis (1)

Simulation of Model Execution

and Testing

(8)

Aspects Framework (DERAF)

(3)

Fig. 1. Overview of the AMoDE-RT design approach

context. Particularly, the results achieved until the moment are encouraging as they provide indications onthe generality of AMoDE-RT and its aspect-oriented techniques.

The remainder of this paper is organized as follows. Section II provides an overview of AMoDE-RTdesign process, whereas Section III presents the classification of AMoDE-RT. Section IV briefly introducesthe AMoDE-RT modeling approach for functional and non-functional requirements, and the remainder ofthe text shows some diagrams of the bCMS case study.

II. OVERVIEW OF AMODE-RTAspect-oriented Model-Driven Engineering for Real-Time systems (AMoDE-RT) [7], [12] is a MDE

approach that combines UML [2] and AOSD concepts already in the earlier design stages. Specifically, inthe requirements engineering and system modeling activities, aspects are used to handle the non-functionalrequirements, whereas regular UML diagrams specify the functional requirements. As usual in MDEapproaches, system models are the main artifacts created by the engineers; the system implementationis generated from the created models by transformation and code generation tools. Thus, AMoDE-RTincreases the abstraction level carried out during design, as engineers deal directly with models instead ofthe source code. Figure 1 shows AMoDE-RT design flow.

AMoDE-RT starts with requirements engineering. The engineers use the RT-FRIDA [3] approach toidentify and collect the embedded real-time system’s requirements and constraints. RT-FRIDA providestools, such as templates, checklists, mapping tables, and requirements conflict resolution tables, in orderto help the engineers to identify and specify functional and non-functional requirements. For a detaileddiscussion on RT-FRIDA, interested readers should refer to [3].

Once the requirements are gathered and specified, the modeling phase takes place. The engineers usesuch an information to create the main specification (i.e. the UML model) of the embedded real-timesystems. As mentioned, the functional requirements are described using regular UML diagrams annotatedwith stereotypes of the MARTE4 profile [1]. Class diagram is the main diagram5 to specify the systemstructure, whereas the sequence, activities6 and state diagrams are used to specify the system behavior. Themodeling activity is an iterative process, and hence, the created diagrams are successively refined up toachieve the desired level of detail, providing sufficient information for system realization. The main idea is to

4UML profile for Modeling and Analysis of Real-time and Embedded systems5other structural diagrams (e.g. composite structure and deployment diagrams) are also supported in AMoDE-RT to specify the system

structure, but they have not been used in the bCMS case study6In the bCMS case study, the activities diagram has not been used

3

enable the engineers to work with model describing concepts that are closer to the target application domain(e.g. sensors, steering devices, robot arms, etc.), since higher abstraction levels are easier to understandand allows focusing on applications foundations. Thus, due to the abstract nature of these elements, it ispossible to create repositories of application domain elements (composed of many different UML elementsand/or diagrams) to be reused in other projects. On the other hand, the non-functional requirements arespecified using a high-level aspects framework called Distributed Embedded Real-time Aspects Framework(DERAF) [3], [12]. DERAF is intended to be used in two moments: (i) the system specification and (ii) inthe implementation, more specifically, in the code generation/aspects weaving step (see Section IV-B).

It is worth mentioning that as much as high-level specifications help in addressing complexity issues,they can also lead to ambiguous or erroneous interpretations of the same specification. For instance,UML allows the same feature to be specified with using different diagrams and/or elements, producingan ambiguous model. Moreover, high-level specifications cannot be executed in computational devices (e.g.microprocessors), due to their incomplete semantics and/or lack of sufficient details. Thus, these ambiguitiesmust be removed in order to enable the automation of design tasks using computational tools, such as CASEtools. To cope with such issues, AMoDE-RT proposes (i) a set of modeling guidelines to create UML models,and (ii) model transformations to decrease the UML ambiguity without loosing the platform-independentfeature of the created models. The set of modeling guidelines define a subset of UML diagrams to be used,as well as rules defining how to specify application elements using these diagrams. On the other hand,transformation rules have been created to transform UML models into the Distributed Embedded Real-timeCompact Specification (DERCS) [9], which provides a Platform Independent Model (PIM) suitable to themanipulation of such an high-level information. DERCS provides elements to support both the object-and aspect-oriented paradigms. Moreover, the UML meta model does not support AOSD; and the DERCSmeta-model is less ambiguous than the UML one, since the same information on the system behavior canbe represented with fewer elements [9]. UML-to-DERCS transformation is performed automatically via atransformation engine used by GenERTiCA [8] and AT4U [10] tools. A detailed discussion on DERCASand the UML-to-DERCS transformation is presented in [9].

Additionally, an important issue in MDE approaches is how to deal with specification errors and mistakes.Since the system implementation is automatically generated from the created models, an undetected errorin any model could be easily propagated to the latter design phases, increasing its detection/repair cost.AMoDE-RT address this issue by applying an iterative system specification activity (fig. 1, steps 3 – 7). Thecreated UML model can be checked as soon as possible, even though the model is still not complete. Thebehavior specified in the (partial) UML model can be simulated [11] using the AT4U tool [10], and thus,it is possible to check whether the specification respects the expected functional requirements. Specifically,the AT4U main idea is to use a set of test cases to exercise the system behavior while it is being specified.In other words, AT4U tries to find specification errors through the direct execution of system behaviors byusing the test cases, which are executed on both individual elements (i.e. unit test) and groups of dependentelements (i.e. component test). The software tool executes automatically the test cases set, and hence, therepetition of the testing process (at every round of changes on the UML model) allows regression tests. Ifany inconsistency is detected, the engineers notice such an issue and the UML model can be fixed, andthus, the problem is not propagated to the next stages of the design.

When the specification phase is finished, the created UML model is used to generate source code for theselected target platform. The tool called GenERTiCA (Generation of Embedded Real-Time Code based onAspects) [8] generates the source code from the DERCS model, which has been created from the UMLmodel. It performs two tasks: (i) it generates code for a given target platform; and (ii) it weaves the aspectsadaptations into the generated code. For that, GenERTiCA executes several scripts with mapping rules,which create code fragments, in order to perform model-to-text transformations from DERCS elementsto constructions in the target platform. These fragments are combined to form the source code files. Thecode generation algorithm is as follows: GenERTiCA accesses each element of the DERCS model, lookingfor the script that defines the mapping from this element into suitable constructs in the target platform. Inaddition, if the accessed element is affected by any DERAF aspect, the code related to the aspect adaptations

4

is woven into the generated code. Such adaptations code is also specified within scripts which representthe DERAF aspects implementation.

After the source code is generated, third party tools are used to compile and synthesize the application,and system implementation is almost ready to be executed or tested using the target platform. It is importantto mention that this text only covers the modeling phase of AMoDE-RT, and hence, details on all othersubjects presented in this Section are provided in other publications, e.g. [7], [3], [8], [9], [12], [11], and[10].

III. CLASSIFICATION OF AMODE-RT APPROACH

As indicated in the call for contributions, AMoDE-RT is classified as follows:

A. Classification of the approach as either aspect-oriented, feature-oriented, object-oriented, subject-oriented,or any other paradigm

AMoDE-RT is an aspect-oriented Model-Driven Engineering approach that uses UML models as themain artifacts of design. Functional requirements are specified using regular UML diagrams, whereas non-functional requirements are described with DERAF, and ACOD and JPDD, which are lightweight extensionsof UML diagrams. Therefore AMoDE-RT approach can be classified as both object- and aspect-oriented.

B. Statement classifying the approach in terms of its software development phasesAMoDE-RT has been proposed to cover the earlier design stages, such as requirements engineering, up

to the implementation phase using code generation and aspect weaving tools. Requirements engineeringand specification processes are iterative and incremental. Therefore, AMoDE-RT can be classified as anapproach that covers early requirements specification and analysis, high-level and architectural design, andlow-level design, including early validation/verification of specifications. However, even though the modelingis iterative and incremental, considering the purpose of this paper and the presented model, AMoDE-RTmodeling process may be classified as “high-level and architectural design”.

C. Description of what has been modeledThis paper presents the modeling of bCMS as single system. Software product lines and variations are not

considered in this study. However, as mentioned, the specification process is iterative, and hence, variationscould be incorporated in refined versions of the bCMS.

IV. OVERVIEW OF AMODE-RT MODELING APPROACH

After the requirements identification, the requirements document is used as input for the AMoDE-RT modeling process. UML and the MARTE profile were chosen to specify the high-level model ofembedded real-time systems, because they are standards, wide accepted, and supported by a recognizedorganization such as OMG. Thus, information exchange between designer teams (hardware and software)can be improved, avoiding misunderstandings on the system specification.

A. Specifying Functional RequirementsAccording to [6], information captured in UML models is often redundant and overlaps. Consequently, it

is not necessary to use all of these diagrams to model a distributed embedded real-time system. Dependingon the used design method and project goals, only some of them are useful. Moreover, some diagrams aremore suitable (or clear) than others to specify system characteristics in a given target application domain.For instance, although activity, state and sequence diagrams are behavioral diagrams, sequence diagramsshow the behavior related to objects exchanging messages in a better way than activity or state diagramsallow, in spite of all of them could express such actions.

5

<<Non−Functional>>

Embedded

<<Aspect>>

HwAreaMonitoring

<<Aspect>>

EnergyMonitoring

<<Aspect>>

HwAreaControl

<<Aspect>>

EnergyControl

<<Aspect>>

MemoryUsageControl

<<Aspect>>

MemoryUsageMonitoring

<<Non−Functional>>

Timing

<<Aspect>>

TimeBoundedActivity <<Aspect>>

SchedulingSupport

<<Aspect>>

TimingAttributes<<Aspect>>

PeriodicTiming

<<Non−Functional>>

Communication

<<Aspect>>

MessageCompression

<<Aspect>>

MessageIntegrity

<<Aspect>>

MessageAck

<<Non−Functional>>

TaskAllocation

<<Aspect>>

NodeStatusRetrieval

<<Aspect>>

TaskMigration

<<Non−Functional>>

Precision

<<Aspect>>

ToleratedDelay

<<Aspect>>

DataFreshness

<<Aspect>>

ClockDrift

<<Aspect>>

Jitter

<<Non−Functional>>

Synchronization

<<Aspect>>

ConcurrentAccessControl

<<Aspect>>

MessageSynchronization

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>>

<<use>> <<use>>

<<use>>

<<use>><<use>>

<<use>>

Fig. 2. Overview of Distributed Embedded Real-time Aspects Framework

In this sense, AMoDE-RT modeling approach restricts UML usage to eight diagrams: (i) use case diagram;(ii) class diagram; (iii) sequence diagram; (iv) composite structure diagram; (v) deployment diagram; (vi)activity diagram; (vii) state diagram. However, only (i), (ii) and (iii) are mandatory, the other diagrams areoptional. As mentioned, to allow information contained in these diagrams to be correctly extracted, andtransformed into a DERCS model, a set of modeling guidelines for each diagram has been created, andmust be followed.

Considering functional requirements handling, the structure (e.g. classes, attributes, methods signaturesand objects) can be specified using standard UML diagrams, such as class, components, and/or deploymentdiagrams, enriched with timing requirements specification provided by the MARTE profile. The distributionof objects over different processing units is shown using a deployment diagram. The behavior is specifiedusing activities, state, and/or sequence diagrams. Both activities and state diagrams should be linked withsequence diagrams, which show details about the actions executed within each activity/state. Sequencediagram shows the interaction among objects through messages exchange. In addition, AMoDE-RT proposesthe use of a set o reserved words, which represent actions such as value assignments or mathematicaloperations, to describe actions within sequence diagrams. Therefore, sequence diagrams can also representactions execution, avoiding the use of action languages, which are not graphical and usually closer toprogramming languages.

B. Aspects Framework for Modeling and ImplementationDistributed Embedded Real-time Aspects Framework (DERAF) (see Figure 2) provides a set of aspect

to deal with a subset of the non-functional requirements commonly found in the domain of embeddedreal-time systems [3]. DERAF has been created to be a flexible framework, enabling its extension tocover non-functional requirements which are not supported. Moreover, DERAF is intended to be usedin both the high-level specification (i.e. the UML model) and the implementation of the embedded real-time system. Therefore, DERAF provides high-level aspects which affect the modeled system by addingspecific behavior and structure. Such adaptations are platform-independent, and therefore, the engineers

6

choose DERAF aspects to specify the non-functional requirements handling based on the aspects’ high-level semantics. Consequently, these semantics must be followed to implement the selected aspects using theservices provided by the target platform. Some examples of DERAF aspects are: PeriodicTiming providesall behavior to deal with periodic activation of tasks; ConcurrentAccessControl provides all features tocontrol the access of shared resources; and EnergyMonitoring adds elements to monitor energy consumption,warning if a specified threshold is reached.

To specify aspects in the UML model, the engineers create an Aspects Crosscutting Overview Diagram(ACOD) [7]. This diagram is a specialization of the class diagram; it depicts the selected DERAF aspectsand the classes affected by these aspects. A new profile has been created to represent AOSD concepts.Aspects are represented as classes annotated with the <<aspect>> stereotype, along with the informationon their adaptations, join points, and pointcuts. In addition, Join Point Designation Diagrams (JPDD) [5]are used to specify the selection of which elements are affected by aspects’ adaptations. As JPDDs is aplatform-independent specification of join points, they can be reused in different projects as discussed in[12].

As mentioned, DERAF is also used for system implementation. Specifically, during the code generationprocess, GenERTiCA uses the information on DERAF aspects that have been described in the UMLmodel. Aspects adaptations are implemented as code generation scripts, which contain target platform’sconstructions that implement aspects’ semantics. For instance, an adaptation script could append newcommands at the end of a generated code fragment. This extra code deals with some non-functionalrequirement(s) addressed by the DERAF aspect. Moreover, as demonstrated in the developed case studies,it is possible to use AOSD concepts with non-AOSD target languages, such as Java or C++.

V. BCMS CASE STUDY

This section discusses how the bCMS case study has been modeled using the modeling approach ofAMoDE-RT. The model follows the bCMS requirements document and specifies a single systems withoutconsidering any variation proposed in such a document, i.e. the model does not represent a SoftwareProduct Line (SPL), and hence, it focuses on the core requirements of the bCMS requirements document.The bCMS model specifies all of the main scenarios (7 scenarios) and their alternative/exception scenarios(9 alternatives), as described in the requirements document.

Additionally, the presented model focuses on the Car Crash Crisis Management System (CCCMS) of thebCMS. Each party of the bCMS, namely the Police and the Fire Stations, uses the same system, i.e. theCCCMS, to manage its local information. Some pieces of local information are shared among the parties,i.e. the police station CCCMS sends such an information periodically to the fire station CCCMS, and viceversa. As indicated in the bCMS requirements document, the internal communication between the policeand firemen staff is out-of-the-scope of this specification. Moreover, since modeling user interfaces are notsupported by the AMoDE-RT approach, none have been specified in the created UML model. However, itis important to mention that AMoDE-RT has been proposed to support embedded systems design whichusually does not present such a feature.

This section separates the discussion of the bCMS functional requirements (section 4 of the requirementsdocument) from the non-functional ones (section 5 of the requirements document).

A. Functional RequirementsFirstly, figure 3 shows the structure of bCMS in terms of classes and their relationships. As one can

see, the proposed solution comprises 15 classes and 6 enumerations. The main classes are: CarCrashCri-sisManagementSystem, Coordinator, Crisis, Vehicle, and RoutePlan.

The distributed Crisis Management System (see figure 4) is comprised of one CarCrashCrisisManage-mentSystem for the police station and other one for the fire station. Each CarCrashCrisisManagementSystemexecutes on a different computing system which is physically separated and located at both the police stationand the fire station.

7

There is one local coordinator which is represented by the abstract class Coordinator and its concretechild classes PoliceStationCoordinator and FireStationCoordinator. The crisis information managed by theCarCrashCrisisManagementSystem can only be accessed by the local coordinator. However, in a coordi-nated crisis management, such an information is exchanged between police and fire station coordinatorsthrough the OtherCoordinator object. In other words, in the context of the policy station’s CarCrashCri-sisManagementSystem, the OtherCoordinator object represents the fire station coordinator. Likewise, in thecontext of the fire station’s CarCrashCrisisManagementSystem, such an object represent the police stationcoordinator. The OtherCoordinator objects is a sort of local proxy for the respective remote object. Thisproxy encapsulates all the behavior to communicated with its remote counterpart, allowing the engineersto abstract these details in the model. In addition, this solution enables the reuse of scenarios, since onescenario that shows the Coordinator and OtherCoordinator objects might be applied in both Police andFire stations.

Moreover, each CarCrashCrisisManagementSystem manages many Vehicles (i.e. PoliceVehicle for thepolice station, and FireTruck for the fire stations) in order to deal properly with the crisis. As stated in therequirements document, the internal communication among the station coordinator and the staff is outsidethe scope of the model. Hence, it is assumed that the PoliceVehicle and FireTruck always provide theupdated information.

In a coordinated crisis management, the police station’s CarCrashCrisisManagementSystem creates vari-ous RoutePlan objects which comprise of many routes (one per vehicle, RoutePerVehicle). In this situation,a common RoutePlan must be accepted by both police station and fire station coordinators.

As one can see, some stereotypes of the UML profile for MARTE have been used to annotate severalclasses. <<SchedulableResource>> stereotype indicates that the class represents an active object7.<<MutualExclusionResource>> stereotype indicates that the class represents an passive object whichare accessed concurrently by one or more active objects. However, such a concurrent access is exclusive,i.e. only one active object can access the passive objects at a given instant.

In summary, the proposed bCMS is composed of a set of active and passive objects. The active objectsmay be perceived as a set of concurrent threads.

7an object that executes its behavior concurrently with other active objects, e.g. a thread within a program

8

ClassDiagrampackage FR [ ]

+waitForCrisis()+initiateCrisisManagement()+startCrisisManagement()+startCoordinatedPlanning()+replan( crisisLocalAssessment : CrisisClassification )+executePlan()+abortPlan()+closeCrisis()+areGoalsAccomplished() : boolean+registerTimeoutLog()+setOtherCoordenatorInfo( info : Coordinator )-createRoutePlans( coordinated : boolean=true )-removeRoute( index : Integer )+getCrisisInfo() : Crisis+setOtherCrisisInfo( info : Crisis )+getVehiclesList() : Vehicle [0..*]+setOtherVehiclesList( list : Vehicle [0..*] )+reportVehicleLocationChange( vehicle : Vehicle )-assignVehicleGoals( vehicle : Vehicle ) : Goal [0..*]-replaceVehicle( vehicle : Vehicle ) : Vehicle-estimateETA( vehicle : Vehicle )+getRoutePlan() : RoutePlan+setOtherRoutePlan( route : RoutePlan )

-CommunicationEstablished : boolean = false-FirstVehicleArrived : boolean = false

<<SchedulableResource>>

CarCrashCrisisManagementSystem

-ID : Integer-Name : String-Phone : Integer-CommunicationEstablished : boolean = false-CoordinatedPlanningTimeout : boolean = false

+initiateCommunication()+exchangeCoordenatorInfo( infoToSend : Coordinator ) : Coordinator+exchangeCrisisInfo( infoToSend : Crisis ) : Crisis+exchangeVehiclesInfo( listToSend : Vehicle [0..*] ) : Vehicle [0..*]+exchangeRouteInfo( route : RoutePlan ) : boolean+setOtherCoordinatorInfo( info : Coordinator )+seekAgreement( route : RoutePlan ) : boolean+finishCoordinatedPlanning( coordinatedRoute : boolean )+requestTimeoutReason() : String+reportVehicleDispath( vehicle : Vehicle )+reportVehicleArrival( vehicle : Vehicle )+reportVehicleReturn( vehicle : Vehicle )+reportVehicleGoalsAccomplishment( vehicle : Vehicle )+reportVehicleReplacement( oldVehicle : Vehicle, newVehicle : Vehicle )+reportNewETA( vehicle : Vehicle )+exchangeCrisisManagementInfo()+assessCrisisManagement()+reportAllGoalsAccomplishment()+canCloseCrisis() : boolean

<<SchedulableResource>>

Coordinator

-FireTrucksCount : Integer-PoliceVehiclesCount : Integer-Coordinated : boolean = false

+createRouteFor( vehicle : Vehicle, destination : GPSPosition )+setFireTrucksCount( ftCount : Integer )+setPoliceVehiclesCount( pvCount : Integer )+isPartOf( vehicle : Vehicle ) : boolean+setCoordinated()+unsetCoordinated()+selectVehiclesToReturn() : Vehicle [0..*]

<<MutualExclusionResource>>

RoutePlan

+finishCoordinatedPlanning( coordinatedRoute : boolean )

PoliceStationCoordinator

-ID : Integer-ETA : DateTime

+changeLocationStatus( newState : LocationStatus )+monitorVehicle()+getLocationStatus() : LocationStatus+getInLocoAssessment() : CrisisClassification+recall()+dispatchTo( location : GPSPosition )+hasArrived( location : GPSPosition ) : boolean+addGoal( goal : Goal )+checkGoalsAccomplishment() : boolean+isDelayed() : boolean+getDelayReason() : DelayReasons+canContinueMission() : boolean

<<MutualExclusionResource>><<SchedulableResource>>

Vehicle

-Description : String-Accomplished : boolean = false

+setAccomplished()+unsetAccomplished()

Goal

-ID : Integer-OccurredAt : DateTime-ClosedAt : DateTime-Description : String

+getLocation() : GPSPosition+activate()+close()+isActive() : boolean

<<MutualExclusionResource>>

Crisis

ENROUTE_TO_LOCATION

ENROUTE_RETURNAT_LOCATION

STATION

<<enumeration>>

LocationStatus

+waitForCrisis()

<<SchedulableResource>>

CrisisManagementSystem

GOALS_ACCOMPLISHED

WAITING_NEXT_CRISISPLAN_FAILED

PREPARING

EXECUTINGASSESSING

PLANNING

<<enumeration>>

CrisisManagementPhase

FireStationCoordinator

TRAFFIC_PROBLEMSBLOCKED_ROUTE

BREAK_DOWNUNSPECIFIEDNO_DELAY

OTHER

<<enumeration>>

DelayReasons

MORE_SEVEREAS_EXPECTED

LESS_SEVERE

<<enumeration>>

CrisisClassification

-Instant : DateTime-Reason : String

TimeoutLogEnty

-Latitude : double-Longitude : double

GPSPosition

PoliceVehicle

RoutePerVehicle

CLOSEDACTIVE

<<enumeration>>

CrisisStatus

TURN_RIGHTTURN_LEFTFORWARD

<<enumeration>>

PathAction

FireTruck

Path

1

-Goals

1..*

-Location

1

1

-Coordenator

1

1

-Status

11

-CurrentLocation

1

1

-OtherVehicles

0..*

1

-LocalVehicles

0..*

-localCCCMS

1

-OtherCrisisInfo

11 -CrisisInfo

11

-OtherRoutePlan1

1

-RoutePlans

0..*

1

-FiremenCCCMS 1

-CMS

1

-PolicyVehiclesRoutes

0

1

-PoliceCCCMS

1 -CMS 1

-FireTrucksRoutes

0..*

1

-EndingPoint

1

1

-Goals 0..*

1

-DelayReason

11

-Paths 1..*

1

-CurrentRoutePlan1

1

-StartingPoint1

1

-Status

11

-TimeoutLogEntries

0..*1

-IntendedLocation

11

-Crisis 1

1

-LocalCoordinator 1

-localCCCMS

1

-Vehicle

1

1

-Status

11

-Crisis

1

1

-OtherCoordinator

1

1

-ActionAtEndPoint 1

1

Fig. 3. Crisis Management System class diagram

9

SystemDeploymentpackage FR [ ]

Fire Station

The OtherCoordinator attribute (from Coordinator class) is the local representation of the Police Station Coordinator object.Messages exchanged between local and other coordinators are remote messages, since each object resides in distinct computing node

Police Station

The OtherCoordinator attribute (from Coordinator class) is the local representation of the Fire Station Coordinator object.Messages exchanged between local and other coordinators are remote messages, since each object resides in distinct computing node

<<SchedulableResource>>

PoliceCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

FiremanCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

bCMS : CrisisManagementSystem

<<SchedulableResource>>

OtherCoordinator : Coordinator

<<SchedulableResource>>

LocalCoordinator : PoliceStationCoordinator

<<SchedulableResource>>

LocalCoordinator : FireStationCoordinator

<<SchedulableResource>>

OtherCoordinator : Coordinator

<<use>>

<<use>>

<<use>>

<<use>>

<<use>> <<use>>

<<use>><<use>>

Fig. 4. Crisis Management System distributed architecture

10

CCMS-Lifecycle CCMS-Lifecyclestate machine [ ]

Planning Crisis Management

Assessing Goals Accomplishment

Waiting for Crisis Event

Preparing for Planning

Goals Accomplished

Executing the Agreed Plan

Negotiation TimeoutPlan Failed

at (every 5 minutes)

[(areGoalsAccomplished() == false) and (canCloseCrisis() == false)]

startCoordinatedPlanning() [(isCommunicationEstablished() == true)

and (isCrisisExchange() == true)]

registerTimeoutLog()

initiateCrisisManagement()

replan( crisisLocalAssessment : CrisisClassification )

at (negotiation timeout)

startCrisisManagement()

abortPlan() [(areGoalsAccomplished() == false) and (canCloseCrisis() == true)]

[areGoalsAccomplished() == true]

closeCrisis()

Fig. 5. Overall behavior for the Car Crash Crisis Management System

On the other hand, the behavior of the CCCMS/bCMS has been specified using one state diagram anda number of sequence diagrams. Notice that, in AMoDE-RT modeling approach, the behavior may bespecified using activities, state, and/or sequence diagrams. Both activities and state diagrams should belinked with sequence diagrams, which show details about the actions executed within each activity/state.Sequence diagram shows the interaction among objects through messages exchanges. In addition, AMoDE-RT proposes the use of a set o reserved words, which represent actions such as value assignments ormathematical operations, to describe actions within sequence diagrams. Therefore, sequence diagrams canalso represent actions execution, avoiding the use of action languages, which are not graphical and usuallycloser to programming languages.

Figure 5 shows a state machine diagram which depicts the CCCMS/bCMS overall behavior, i.e. itsruntime lifecycle. In other word, rather than associating such a behavior with an specific class/object ofthe CCCMS, this diagram shows the system behavior in terms of states and the events that trigger thetransitions. CCCMS has four mains phases: (i) “Waiting for Crisis Event”, (ii) “Planning” (which has beenseparated in the states “Preparation for Planning”, “Planning Crisis Management”, “Negotiation Timeout”);(iii) “Executing the Agreed Plan”; and (iv) “Assessing Goals Accomplishment” (concerns have been splitbetween “Goals Accomplished” and “Plan Failed” states). The communication and information exchangedbetween coordinators is performed within the phases (ii), (iii), and (iv).

Furthermore, as mentioned, each state of the state diagrams is liked with one (or more) sequencediagram. The system whole behavior (i.e. the behavior of its individual classes/objects) is obtained fromthe combination of all behavioral diagrams, which depict distinct scenarios. The system behavior is detailedin the following sequence diagrams. They are depicted following the order of scenarios presented in thebCMS requirements document.

11

Establish Communication Establish Communicationinteraction [ ]

<<SchedulableResource>>

localCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

LocalCoordinator : Coordinator

<<SchedulableResource>>

OtherCoordinator : Coordinator

[CommunicationEstablished == false]

opt

initiateCommunication()2:

crisisInfo7:

exchangeCoordenatorInfo(infoToSend=self)3:

exchangeCrisisInfo(infoToSend="crisisInfo"):""8:

setOtherCoordinatorInfo(info=otherCoordInfo)5:

getCrisisInfo()6:

setOtherCrisisInfo(info=otherCrisisInfo)10:

otherCoordInfo4:

otherCrisisInfo9:

initiateCrisisManagement()1:

Fig. 6. Scenario 1: PSC and FSC establish communication and identification of coordinators

Figure 6 depicts the scenario 1 “PSC and FSC establish communication and identification of coordinators”and the initial exchange of information between PSC and FSC (scenario 2). It is important to note that,since this scenario is similar to both PSC and FSC, there is no explicit mention about police or fire stationcoordinators; this scenario describes the action of the local and other coordinators. This scenario is describedas follows:

1) messages 1-2: localCCCMS informs the LocalCoordinator that a coordinated crisis management hasinitiated, and hence, it must make contact with the other station’s coordinator.

2) messages 3-5: if the information about the coordinators has not yet been exchanged, the localCoordi-nator sends its information and receive the OtherCoordinator information. The received informationis stored by the LocalCoordinator.

3) messages 6-10: the LocalCoordinator gets the local Crisis information and sends it to the Other-Coordinator, which, in return, sends its local Crisis information. The received information is storedby the LocalCoordinator.

12

Figure 7 depicts the scenario 2 “PSC and FSC exchange crisis details”. In addition, this sequence diagramsalso depicts the handling of the availability non-functional requirement (section 5.2 of the bCMS require-ments document). As one can see, the first message is annotated with the MARTE profile’s <<TimedEvent>>stereotype, indicating that this operation is triggered periodically at every 5 minutes. This follows the firstpart of the availability non-functional requirement (first paragraph of section 5.2 of the bCMS requirementsdocument). This scenario is described as follows:

1) messages 2-3: localCoordinator request the updated Crisis information to localCCCMS.2) messages 4: a counter has been created to control the frequency within which the crisis management

information is exchanged between coordinator. This solution fulfill the second part of the availabilitynon-functional requirement.

3) messages 5-16: the information about the local coordinator (of both stations), the crisis details, androute plan is exchanged between coordinators.

Figure 8 depicts the scenario 3 “PSC and FSC develop a coordinated route plan in a timely fashion fornumber of vehicles to be deployed to specific locations with respective ETAs”, including the three sub-itemsand the alternative scenarios 3.a, 3.3.a1, and 3.3.a2.

As one can see, the first message is annotated with the MARTE profile’s <<RTFeature>> stereotype,indicating that this operation (i.e. the coordinated planning, messages 1-26) has a deadline (e.g. in thisspecification, 5 minutes) to be complete. If the time constraint is not respected a timeout occurs the bothcoordinators shall inform and store the reasons about why such an agreement could not be achieved withinthe deadline (messages 27-30). Such a feature covers the alternative scenario 3.a as described in the bCMSrequirements document.

This scenario is described as follows:1) messages 2-11: firstly, localCoordinator and OtherCoordinator exchange the information on the

vehicles under their management.2) messages 12: a list of possible route plans is created by the CarCrashManagementSystem of the

police station. In order to see details on such an activity, see figure 9.3) messages 13-19: for each created RoutePlan, the LocalCoordinator (i.e. the PSC) gets a RoutePlan

and sends it to the OtherCoordinator (FSC). If the FSC does not agree with the sent RoutePlan, itis removed from the list of route plans and a new RoutePlan is selected. This process repeats untilan agreement between PSC and FSC is obtained, or whether there is no route plan remaining forseeking an agreement.

4) messages 20-25: the plan is set as either uncoordinated (i.e. there is no agreement) or coordinated(there is an agreement). This information is exchanged between coordinators (messages 24 and 25).

5) messages 26: the localCCCMS starts the execution of the plan.6) messages 27-30: in parallel, if a timeout occurred, the coordinators are requested to inform the

reasons for not achieving an agreement within the deadline.

13

Periodic Information Exchange Periodic Information Exchangeinteraction [ ]

<<SchedulableResource>>

localCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

OtherCoordinator : Coordinator

<<SchedulableResource>>

LocalCoordinator : Coordinator

[(crisisInfo.isActive() == true)or (periodsCount == 6)]

opt

if there is no crisis, the information is exchanges every 30 minutes (5 min. plus 6)

crisisInfo3:

currentRoutePlan6:

otherCoordInfo8:

otherCrisisInfo11:

otherRoutePlan14:

getCrisisInfo()2:

getRoutePlan()5:

exchangeCoordenatorInfo(infoToSend=self)7:

exchangeCrisisInfo(infoToSend=crisisInfo)10:

exchangeRouteInfo(route=currentRoutePlan)13:

setOtherCoordinatorInfo(info=otherCoordInfo)9:

setOtherCrisisInfo(info=otherCrisisInfo)12:

setOtherRoutePlan(route=otherRoutePlan)15:

ASSIGN( periodsCount, periodsCount + 1 )4:

ASSIGN( periodsCount, 0 )16:

exchangeCrisisManagementInfo()1:

<<TimedEvent>>

{every = "5 minutes" }

Fig. 7. Scenario 2: PSC and FSC exchange crisis details (periodic information exchange)

14

Coordinated Planning Coordinated Planninginteraction [ ]

<<SchedulableResource>>

PoliceCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

LocalCoordinator : PoliceStationCoordinator

<<SchedulableResource>>

OtherCoordinator : FireStationCoordinator

<<MutualExclusionResource>>

CurrentRoutePlan : RoutePlan

TimeoutLogEntries : TimeoutLogEnty

[ ]

if the agreement for the coordinated route plan is not achieved, the FireStationCoordinator is warned through the finishCoordinatedPlanning() message whose argument is false

[ ]

par

[infoToSent == NULL]

[else]

alt

[i=0; (i < RoutePlansCount) && (agreement == false)]

[agreement == false]

opt

loop

[agreement == false]

[else]

alt

It is assumed that the predefined timeout for plan negotiaion is 5 minutes

createRoutePlans(coordinated="true")12:

exchangeVehiclesInfo(listToSend=)2:

localVehicles4:

localVehicles10:

ASSIGN(agreement, false)13:

ASSIGN( CurrentRoutePlan, RoutePlans[i] )14:

seekAgreement(route=CurrentRoutePlan)15:

finishCoordinatedPlanning(coordinatedRoute=agreement)24:

createRoutePlans(coordinated="false")20:

removeRoute(index= i)19:

startCrisisManagement()26:

requestTimeoutReason()28:

("CrisisInfo", "LocalCoordinator", "reason", "currentDateTime")30:

ASSIGN( CurrentRoutePlan, RoutePlans[0] )21:

setCoordinated()23:

unsetCoordinated()22:

getVehiclesList()3:

exchangeVehiclesInfo(listToSend=localVehicles)5:

setOtherVehiclesList(list=otherVehicles)7:

setOtherVehiclesList(list=infoToSend)8:

RETURN(localVehicles)11:

getVehiclesList()9:

exchangeRouteInfo(route=route)16:

agreement18:

finishCoordinatedPlanning(coordinatedRoute=agreement)25:

reason29:

otherVehicles6:

agreement17:

startCoordinatedPlanning()1:

<<RTFeature>>

{relDeadline = "5 min"}

timeout27:

<<Alarm>>

Fig. 8. Scenario 3: PSC and FSC develop a coordinated route plan in a timely fashion

15

Create Route per Vehicle Create Route per Vehicleinteraction [ ]

<<SchedulableResource>>

PoliceCCCMS : CarCrashCrisisManagementSystem

<<MutualExclusionResource>>

CrisisInfo : Crisis

<<MutualExclusionResource>>

RoutePlans : RoutePlan[until there is a different uncovered route to crisis location]

[coordinated == true]

opt

loop

[i = 0;i < LocalVehiclesCount]

loop

[i=0; i < OtherVechilesCount]

loop

4:

setFireTrucksCount(ftCount=OtherVehiclesCount)5:

setPoliceVehiclesCount(pvCount=LocalVechilesCount)6:

createRouteFor(vehicle=OtherVehicles[i], destination="crisisLocation")7:

createRouteFor(vehicle=LocalVehicles[i], destination="crisisLocation")8:

getLocation()2:

crisisLocation3:

createRoutePlans(coordinated="")1:

Fig. 9. Scenario 3-B: CCCMS creates one route per vehicle for both police vehicles and fire trucks

16

Start Crisis Management Start Crisis Managementinteraction [ ]

<<SchedulableResource>>

: CarCrashCrisisManagementSystem

<<MutualExclusionResource>>

CurrentRoutePlan : RoutePlan

<<MutualExclusionResource>>

CrisisInfo : Crisis

<<MutualExclusionResource>><<SchedulableResource>>

LocalVehicles[i] : Vehicle

[i = 0;i < LocalVehiclesCount]

[dispatch == true]

opt

loop

ASSIGN( FirstVehicleArrived, false )5:

activate()4:

isPartOf(vehicle=LocalVehicle[i])6:

dispatchTo(location=crisisLocation)9:

getLocation()2:

assignVehicleGoals(vehicle=LocalVehicle[i]):""8:

dispatch7:

crisisLocation3:

changeLocationStatus(newState=ENROUTE_TO_LOCATION)10:

startCrisisManagement()1:

Fig. 10. Scenario 4: PSC and FSC communicate to each other its vehicles dispatch

Figure 10 depicts the scenario 4 “PSC and FSC communicate to each other that their respective vehicleshave been dispatched according to plan (per vehicle)”. This scenario is complemented by sequence diagramdepicted in figure 12 (in fact the communication between coordinators is depicted in that figure) and isdescribed as follows:

1) messages 2-4: the CarCrashCrisisManagementSystem requests the Crisis location, and then indicatesthat this crisis management has started (message 4, Crisis.activate()).

2) messages 6-10: for each vehicle under management: (a) checking if the vehicle is part of the crisismanagement plan; (b) if the vehicle is part of the plan, assign the vehicles goals (i.e. its mission);(c) dispatch the vehicle, informing the other coordinator (PSC or FSC) such an event.

17

Figure 11 depicts the scenario 5 “PSC and FSC communicate to each other their arrival (per vehicle) attargeted locations” and scenario 6 “PSC and FSC communicate to each other completion (per vehicle) oftheir respective objectives”. In addition, the alternative scenarios 5.a and 5.b are specified on this sequencediagram. These scenarios are described as follows:

1) messages 2-7: for each vehicle, check if it is part of the plan, and hence, check if it has arrived at thecrisis location. It is important to highlight that, as mentioned, the exchange of such an informationis depicted in figure 12.

2) messages 8-11: the CarCrashCrisisManagementSystem checks if the vehicle has accomplished itsindividual goals. If this is the case, the LocalCoordinator report such an accomplishment to theOtherCoordinator.

3) messages 12-15: in the case that the vehicle has not arrived within ETA, some action must be takento minimize such a problem. When the reason for the vehicle delay is related to traffic problems orblocked route, the route plan must be recreated and agreed (see the “ref” combined fragment). Thisrepresents the alternative scenario 5.b.

4) messages 16-23: when the delay reason is related to vehicle break down, the LocalCoordinator candecide either repair the vehicle and then continue waiting until it arrives at the crisis location withina new ETA, or the broken vehicle can be replaced by other. Both situation must be reported to theOtherCoordinator. This represents the alternative scenario 5.a.

18

Execute Plan Execute Planinteraction [ ]

<<SchedulableResource>>

: CarCrashCrisisManagementSystem

<<SchedulableResource>>

OtherCoordinator : Coordinator

<<SchedulableResource>>

LocalCoordinator : Coordinator

<<MutualExclusionResource>>

CurrentRoutePlan : RoutePlan

<<MutualExclusionResource>>

CrisisInfo : Crisis

<<MutualExclusionResource>><<SchedulableResource>>

LocalVehicles[i] : Vehicle

[i = 0;i < LocalVehiclesCount]

[vehicleLinkedToPlan == true]

[vehicleArrived == true]

[goalsAccomplished == true]

opt

[else]

[(reason == TRAFFIC_PROBLEMS)or (reason == BLOCKED_ROUTE)]

Coordinated Planning

ref

[reason == BREAK_DOWN]

[canContinue == true]

[else]

alt

alt

alt

opt

loopisPartOf(vehicle=LocalVehicle[i])4:

hasArrived(location=crisisLocation)6:

getLocation()2:

checkGoalsAccomplishment()8:

reportVehicleGoalsAccomplishment(vehicle=LocalVehicles[i])10:

isDelayed()12:

getDelayReason()14:

replaceVehicle(vehicle=LocalVehicle[i]):""21:

reportVehicleReplacement(oldVehicle=LocalVehicle[i], newVehicle=newVehicle)22:

canContinueMission()16:

estimateETA(vehicle=LocalVehicles[i])18:

reportNewETA(vehicle=LocalVehicle[i])19:

reportVehicleGoalsAccomplishment(vehicle=vehicle)11:

reportVehicleReplacement(oldVehicle=oldVehicle, newVehicle=newVehicle)23:

reportNewETA(vehicle=vehicle)20:

vehicleLinkedToPlan5:

crisisLocation3:

vehicleArrived7:

goalsAccomplished9:

delayed13:

reason15:

canContinue17:

<<TimedEvent>>

executePlan()1:

{every = "30 seconds" }

Fig. 11. Scenarios 5 and 6: PSC and FSC communicate to each other about: (a) the vehicles arrival; (b) goals accomplishment for eachvehicle.

19

Changes in Vechile Location Status Changes in Vechile Location Statusinteraction [ ]

<<SchedulableResource>>

localCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

OtherCoordinator : Coordinator

<<SchedulableResource>>

LocalCoordinator : Coordinator

<<MutualExclusionResource>><<SchedulableResource>>

: Vehicle

[vehicle.getLocationStatus() == ENROUTE_TO_LOCATION]

[vehicle.getLocationStatus() == AT_LOCATION]

[FirstVehicleArrived == false]

[crisisAssessment != AS_EXPECTED]

opt

opt

[vehicle.getLocationStatus() == ENROUTE_RETURN]

alt

reportVehicleDispath(vehicle=vehicle)4:

reportVehicleArrival(vehicle=vehicle)6:

reportVehicleReturn(vehicle=vehicle)12:

getInLocoAssessment()9:

replan(crisisLocalAssessment=crisisAssessment)11:

ASSIGN( FirstVehicleArrived, true )8:

reportVehicleDispath(vehicle=vehicle)5:

reportVehicleArrival(vehicle=vehicle)7:

reportVehicleReturn(vehicle=vehicle)13:

reportVehicleLocationChange(vehicle=self)3:

MODIFY_STATE( newState )2:

crisisAssessment10:

changeLocationStatus(newState=)1:

Fig. 12. Scenarios 4 and 5: the communication between PSC and FSC regarding changes in the vehicles location status

20

Vehicles Monitoring Vehicles Monitoringinteraction [ ]

<<MutualExclusionResource>><<SchedulableResource>>

: Vehicle

This dagram have been created to specify explicitly that each vehicle is monitored periodically, and thus, to specify a non-functional requirement related to such a time constraint.The internal details on how this shall be performed is out of the scope for this case study.Therefore, these details have been ommitted.

monitorVehicle()1:

<<TimedEvent>>

{every = "30 seconds" }

Fig. 13. Scenarios 4, 5 and 6: individual vehicle monitoring

Figure 13 depicts the periodic activation of the vehicle monitoring activity. Each vehicle is an active objectand its monitorVehicle() operation is executed every 30 seconds. Although not specified as a requirementin the bCMS requirements document, such an activity has been specified, since we understand that theVehicle object itself is responsible for keeping its information updated and also for reporting any changeon its internal state to the CarCrashManagementSystem and/or LocalCoordinator. As mentioned, since thisrequirement has not been specified, the internal details have been omitted.

21

Replan Crisis Management Replan Crisis Managementinteraction [ ]

<<SchedulableResource>>

: CarCrashCrisisManagementSystem

<<MutualExclusionResource>>

CurrentRoutePlan : RoutePlan

<<MutualExclusionResource>><<SchedulableResource>>

vehiclesList[i] : Vehicle

[crisisAssessment == MORE_SEVERE]

Coordinated Planning

ref

[crisisAssessment == LESS_SEVERE]

[i = 0;i < vehiclesCount]

loop

alt

selectVehiclesToReturn()2:

recall()4:

vehiclesList3:

changeLocationStatus(newState=ENROUTE_RETURN)5:

replan(crisisLocalAssessment=)1:

Fig. 14. Scenarios 5c and 5d: crisis management replanning

Figure 14 depicts the alternative scenario 5.c “when the crisis is more severe than expected” and alternativescenario 5.d “when the crisis is less severe than expected”. Both scenarios demand the crisis managementreplanning.

Finally, figure 15 depicts the scenario 7 “PSC and FSC agree to close the crisis”. As one can see, thecrisis management results are assessed every 5 minutes (message 1 is annotated with the MARTE profile’s<<TimedEvent>> stereotype. This scenario is described as follows:

1) messages 2-3: the LocalCoordinator checks whether the crisis management goals have been com-pletely achieved.

2) messages 4-7: if all goals have been achieved, such an accomplishment is reported to the Other-Coordinator. Thereafter, a negotiation start in order to check if the crisis can be closed. If bothcoordinators agree, the crisis management can be finished.

3) messages 9-10: on the other hand, if the goals are not yer achieved, the LocalCoordinator checks if

22

Assess Crisis Accomplishment Assess Crisis Accomplishmentinteraction [ ]

<<SchedulableResource>>

localCCCMS : CarCrashCrisisManagementSystem

<<SchedulableResource>>

OtherCoordinator : Coordinator

<<SchedulableResource>>

: Coordinator

[goalsAccomplished == true]

[closeCrisis == true]

opt

[else]

[closeCrisis == true]

opt

alt

goalsAccomplished3:

closeCrisis6:

closeCrisis9:

areGoalsAccomplished()2:

reportAllGoalsAccomplishment()4:

canCloseCrisis()5:

closeCrisis()7:

canCloseCrisis()8:

abortPlan()10:

assessCrisisManagement()1:

<<TimedEvent>>

{every = "5 minutes" }

Fig. 15. Scenarios 7: PSC and FSC agree to close the crisis

the crisis should be closed by requesting such an information to the OtherCoordinator. If both coor-dinator agree to finish the crisis management, the LocalCoordinator aborts the current managementplan and closes the crisis management.

23

B. Non-Functional RequirementsThis section discusses how the non-functional requirements described in section 5 of the bCMS require-

ments document, namely integrity, availability, performance, are handled using AMoDE-RT approach.It is important to highlight that, according to the requirement documents, the bCMS presents time-relatedconstraints, leading to time requirements that are not explicitly mentioned in the non-functional requirementssection. In addition, due to the system’s parallel activities and the concurrent access of share data, there isalso the need to control the access of such data, leading to an additional non-functional requirement thatshall be handled.

Figure 16 shows the Aspects Crosscutting Overview Diagram (ACOD). This case study reused 8 aspectsfrom the Distributed Embedded Real-time Aspects Framework (DERAF). This diagram shows aspects asclasses annotated with the <<Aspect>> and “regular” classes. It is worth discussing the associationsbetween aspects and classes, i.e. those decorated with the <<Crosscut>> stereotype. If an aspect structuraladaptation inserts new attributes in classes, the affected classes must be included in ACOD specification. Foreach affected class, an unilateral one-to-one association decorated with the <<Crosscut>> stereotype mustbe created from the aspect to the affected class. Values for the new attributes are specified as tagged valuesin the crosscut association as depicted in figure 16. For instance, TimingAttributes inserts two attributes (i.e.Deadline and WCET) into the active object classe (e.g. CarCrashCrisisManagementSystem). This crosscutassociation specifies that Deadline must be initialized with 30 seconds and WCET with 10 seconds. However,it is important to highlight that crosscut associations are not “concrete” associations between aspects andclasses in terms of UML association semantics. Instead, they are interpreted as informative relationshipsthat do not produce any meta-model element in the associated elements.

The integrity non-functional requirement is related with the integrity of the communication and also thetransmitted data. It has been handled by the following DERAF aspects: (i) MessageSynchronization, (ii)MessageAck, and (iii) MessageIntegrity. The aspects (i) and (ii) deal with the delivery of messages, sinceboth comprehend mechanisms to check the delivery of each message exchanged between two objects. Onthe other hand, the aspect (iii) deals with the integrity of the data transmitted/received by means of includingadditional data, in order to allow the data checking once a message is received. A more detailed descriptionof these aspects is as follows:

1) MessageSynchronization aspect (Synchronization Package) deals with holding behaviors executionuntil the arrival of an acknowledgment message (or a reply message) indicating that the (remote)object has received the message sent. It provides a waiting mechanism that could be implementedas either (i) a busy wait, i.e. a loop that waits until the acknowledgment message arrives; or (ii)using the system scheduler, which preempts the execution of the current active object, marking itas blocked, and thus, opening room for other active objects execution. Later, when the expectedacknowledgment message arrives, the blocked active object is marked as ready to execute, and itsexecution is resumed following the scheduler’s decision.

2) MessageAck aspect (Communication Package) provides an acknowledgment mechanism to notifyreception of a message to its sender. In this sense, this aspect affects both sides of a messageexchange: sender and destination objects. On one side, the sender object sends a messages andwaits for an acknowledgment of message reception. On the other side, the receiver objects needsto send an acknowledgment message after each received message. MessageAck is related withMessageSynchronization aspect.

3) MessageIntegrity aspect (Communication Package) is responsible for handling messages integrityby providing checking information within a message. Similarly to MessageAck, this aspect alsoaffects both message’s sender and receiver objects. Sender objects must generate integrity checkinginformation, appending it in the message to be sent, while receiver objects must generate checkinginformation from the received message, comparing it with the information that came with the receivedmessage. The acknowledgment mechanism must be notified whether the checking information matchor not.

24

pa

ck

ag

e

AC

OD

NF

R[

]

<<

Poin

tcut>

>+

pcS

hare

dO

bjC

lass(

JP

DD

_E

xclu

siv

eO

bje

ctC

lass, C

oncurr

encyC

ontr

olM

echanis

m, A

DD

_N

EW

_F

EA

TU

RE

)<

<P

oin

tcut>

>+

pcB

efo

reO

pera

tionC

all(

JP

DD

_E

xclu

siv

eO

pera

tionC

all,

AcquireA

ccess, B

EF

OR

E )

<<

Poin

tcut>

>+

pcA

fterO

pera

tionC

all(

JP

DD

_E

xclu

siv

eO

pera

tionC

all,

Rele

aseA

ccess, A

FT

ER

)<

<S

tructu

ralA

dapta

tion>

>+

Concurr

encyC

ontr

olM

echanis

m()

<<

Behavio

ralA

dapta

tion>

>+

AcquireA

ccess()

<<

Behavio

ralA

dapta

tion>

>+

Rele

aseA

ccess()

<<

Aspect>

>

Co

nc

urr

en

tAc

ce

ss

Co

ntr

ol

<<

Poin

tcut>

>+

pcA

ctC

lass(

JP

DD

_A

ctiveO

bje

ctC

lass, P

eriod, A

DD

_N

EW

_F

EA

TU

RE

)<

<P

oin

tcut>

>+

pcA

ctO

bjC

onstr

ucto

r( J

PD

D_A

ctiveO

bje

ctC

onstr

ucto

r, M

odifyC

onstr

ucto

r, M

OD

IFY

_S

TR

UC

TU

RE

)<

<P

oin

tcut>

>+

pcA

ctO

bjInit(

JP

DD

_A

ctiveO

bje

ctC

onstr

uction, S

etP

eriod, A

FT

ER

)<

<P

oin

tcut>

>+

pcA

ctO

bjInit2(

JP

DD

_A

ctiveO

bje

ctC

onstr

uction_A

ction, A

daptO

bje

ctC

onstr

uction, M

OD

IFY

_S

TR

UC

TU

RE

)<

<P

oin

tcut>

>+

pcLoop(

JP

DD

_P

eriodic

Behavio

r, L

oopM

echanis

m, A

RO

UN

D )

<<

Poin

tcut>

>+

pcF

reqC

trl( J

PD

D_P

eriodic

Behavio

r, F

requencyC

ontr

ol, A

FT

ER

)<

<S

tructu

ralA

dapta

tion>

>+

Period()

<<

Str

uctu

ralA

dapta

tion>

>+

ModifyC

onstr

ucto

r()

<<

Behavio

ralA

dapta

tion>

>+

SetP

eriod()

<<

Behavio

ralA

dapta

tion>

>+

LoopM

echanis

m()

<<

Behavio

ralA

dapta

tion>

>+

Fre

quencyC

ontr

ol()

<<

Behavio

ralA

dapta

tion>

>+

AdaptO

bje

ctC

onstr

uction()

<<

Aspect>

>

Pe

rio

dic

Tim

ing

<<

Poin

tcut>

>+

pcA

ctC

lass(

JP

DD

_A

ctiveO

bje

ctC

lass, D

eadlin

e+

Priority

+W

CE

T, A

DD

_N

EW

_F

EA

TU

RE

)<

<P

oin

tcut>

>+

pcA

ctC

lass2(

JP

DD

_A

ctiveO

bje

ctC

lass, M

odityC

lassS

tructu

re, M

OD

IFY

_S

TR

UC

TU

RE

)<

<P

oin

tcut>

>+

pcA

ctO

bjInit(

JP

DD

_A

ctiveO

bje

ctC

onstr

uction, S

etT

imin

gA

ttribute

s, A

FT

ER

)<

<P

oin

tcut>

>+

pcA

ctO

bjInit2(

JP

DD

_A

ctiveO

bje

ctC

onstr

uction_A

ction, A

daptO

bje

ctC

onstr

uction, M

OD

IFY

_S

TR

UC

TU

RE

)<

<P

oin

tcut>

>+

pcA

ctO

bjC

ontr

ucto

r( J

PD

D_A

ctiveO

bje

ctC

onstr

ucto

r, M

odifyC

onstr

ucto

r, M

OD

IFY

_S

TR

UC

TU

RE

)<

<S

tructu

ralA

dapta

tion>

>+

Deadlin

e()

<<

Str

uctu

ralA

dapta

tion>

>+

Priority

()<

<S

tructu

ralA

dapta

tion>

>+

WC

ET

()<

<S

tructu

ralA

dapta

tion>

>+

ModifyC

onstr

ucto

r()

<<

Str

uctu

ralA

dapta

tion>

>+

ModityC

lassS

tructu

re()

<<

Behavio

ralA

dapta

tion>

>+

SetT

imin

gA

ttribute

s()

<<

Behavio

ralA

dapta

tion>

>+

AdaptO

bje

ctC

onstr

uction()

<<

Aspect>

>

Tim

ing

Att

rib

ute

s

<<

Poin

tcut>

>+

pcS

ubS

yste

mC

lass(

JP

DD

_S

ubS

yste

mC

lass, A

cknow

ledgm

entM

echanis

m, A

DD

_N

EW

_F

EA

TU

RE

)<

<P

oin

tcut>

>+

pcR

em

ote

MsgB

ehavio

r( J

PD

D_R

em

ote

MessageB

ehavio

r, S

endA

cknow

ledgm

ent, A

FT

ER

)<

<S

tructu

ralA

dapta

tion>

>+

Acknow

ledgm

entM

echanis

m()

<<

Behavio

ralA

dapta

tion>

>+

SendA

cknow

ledgm

ent)

()<<

Aspect>

>

Me

ss

ag

eA

ck

<<

Poin

tcut>

>+

pcS

ubS

yste

mC

lass(

JP

DD

_S

ubS

yste

mC

lass, S

chedule

r, A

DD

_N

EW

_F

EA

TU

RE

)<

<P

oin

tcut>

>+

pcS

ubS

yste

mC

onstr

uction(

JP

DD

_S

ubS

yste

mC

onstr

uction_2, S

etu

pC

oncurr

entA

ctivitie

s, A

FT

ER

)<

<S

tructu

ralA

dapta

tion>

>+

Schedule

r()

<<

Behavio

ralA

dapta

tion>

>+

Setu

pC

oncurr

entA

ctivitie

s()

<<

Aspect>

>

Sc

he

du

lin

gS

up

po

rt

<<

Poin

tcut>

>+

pcM

sgIn

tegrity

Info

( JP

DD

_S

endM

sgT

oR

em

ote

Obje

ct, G

enera

teIn

tegrity

Info

, B

EF

OR

E )

<<

Poin

tcut>

>+

pcC

heckM

sgIn

tegirty

( JP

DD

_R

em

ote

MessageB

ehavio

r, S

endA

cknow

ledgm

ent, B

EF

OR

E )

<<

Behavio

ralA

dapta

tion>

>+

Genera

teIn

tegrity

Info

()<

<B

ehavio

ralA

dapta

tion>

>+

Verify

Inte

grity

Info

()

<<

Aspect>

>

Me

ss

ag

eIn

teg

rity

<<

Poin

tcut>

>+

pcS

ubS

yste

mC

lass(

JP

DD

_S

ubS

yste

mC

lass, W

aitin

gM

echanis

m, A

DD

_N

EW

_F

EA

TU

RE

)<

<P

oin

tcut>

>+

pcR

em

ote

MsgS

endin

g(

JP

DD

_S

endM

sgT

oR

em

ote

Obje

ct, W

aitF

orA

cknow

ledge, A

FT

ER

)<

<S

tructu

ralA

dapta

tion>

>+

Waitin

gM

echanis

m()

<<

Behavio

ralA

dapta

tion>

>+

WaitF

orA

cknow

ledge()

<<

Aspect>

>

Me

ss

ag

eS

yn

ch

ron

iza

tio

n

<<

Poin

tcut>

>+

pcS

tart

Counting(

JP

DD

_T

imeC

onstr

ain

edA

ction, S

tart

Tim

e, B

EF

OR

E )

<<

Poin

tcut>

>+

pcF

inis

hC

ounting(

JP

DD

_T

imeC

onstr

ain

edA

ction, V

erify

Tole

rate

dD

ela

y, A

FT

ER

)<

<B

ehavio

ralA

dapta

tion>

>+

Sta

rtT

ime()

<<

Behavio

ralA

dapta

tion>

>+

Verify

Tole

rate

dD

ela

y()

<<

Aspect>

>

To

lera

ted

De

lay

<<

Schedula

ble

Resourc

e>

>

CarC

rash

Cri

sis

Man

ag

em

en

tSyste

m

<<

Mutu

alE

xclu

sio

nR

esourc

e>

><

<S

chedula

ble

Resourc

e>

>

Veh

icle

<<

Schedula

ble

Resourc

e>

>

Cri

sis

Man

ag

em

en

tSyste

m

<<

Schedula

ble

Resourc

e>

>

Co

ord

inato

r

<<

Cro

sscut>

>

{Tole

rate

dD

ela

y =

"5

min

ute

s"}

<<

Cro

sscut>

>

{Deadlin

e =

"5

min

ute

s",

WC

ET

= "

60

seconds"

}

<<

Cro

sscut>

>

{Deadlin

e =

"30

seconds"

,

WC

ET

= "

10

seconds"

}

<<

Cro

sscut>

>

{Deadlin

e =

"30

seconds"

,

WC

ET

= "

15

seconds"

}

<<

Cro

sscut>

>

{Deadlin

e =

"30

seconds"

,

WC

ET

= "

10

seconds"

}

<<

Cro

sscut>

>{P

eriod =

"30

seconds"

}<

<C

rosscut>

>{P

eriod =

"30

seconds"

}

<<

Cro

sscut>

>{P

eriod =

"5

min

ute

s"}

<<

Cro

sscut>

>

{Period =

"30

seconds"

}

Fig.

16.

AC

OD

:A

spec

tsC

ross

cutti

ngO

verv

iew

Dia

gram

25

The availability non-functional requirement has been specified in the sequence diagram presented at figure7. Such a diagram depicts the information exchanges between police and fire CCCMS/bCMS. However, asthis information is exchanged periodically, timing requirements have been included. This requirements hasbeen handled by the following DERAF aspects from Timing Package:

1) TimingAttributes aspect is responsible to deal with active objects’ characteristics such as deadline,priority, WCET, and the absolute time instants on which their behavior must start and finish theexecution. Attributes representing the mentioned characteristics are inserted in the affected activeobject classes, as well as methods and behavior to initialize and handle these attributes. As mentioned,the handling of these timing issues is delegated to the target platform that must provide support tothis aspect semantics.

2) PeriodicTiming aspect provides means to trigger periodically the execution of an active objectbehavior. Thus, besides adding an attribute indicating the execution frequency in the affected activeobject class, this aspect must also enclose the affected behavior with a repetition mechanism, whoseexecution is controlled according the information stored in the mentioned new attribute. In otherwords, this aspect is used to deal with the handling of periodic active objects (or threads).

3) SchedulingSupport aspect inserts a scheduler object in the affected computing nodes. This object isresponsible to control active objects execution, indicating instants at which they must start performingtheir behavior.

The performance non-functional requirement is related to time constraints on bCMS activities. It hasbeen handled by the following DERAF aspects: (i) TimingAttributes and (i) ToleratedDelay (PerformancePackage). Each action/activity affect by these aspects will include mechanism to measure and analysis thebCMS performance.

1) TimingAttributes (Timing Package) aspect was already discussed.2) ToleratedDelay (Performance Package) aspect controls the maximum tolerated delay for an activity

to complete its execution. Thus, the time between the start and the execution of the observed activitymust be measured and its duration calculated. If the observed duration is greater than the maximumallowed delay, this aspect provides means to handle this exception.

Finally, as mentioned, the concurrent access to share data must also be handled. For that, the Con-currentAccessControl aspect (Synchronization Package) provides means to control the concurrent accessto objects, which share their information with other objects. The following accesses to object’s differentelements can be controlled: (i) the object itself; (ii)their attributes; and/or (iii) their methods. Therefore,depending on the controlled element, one or more arbiters (i.e. concurrency controller instances) are created.Every time an (active or passive) object needs to access controlled shared elements, it must request the accessto them (i.e. request a lock) that are granted or not by the arbiter. Depending on the arbiter implementation(e.g. mutex, semaphore, monitors), and also to the number of objects that are accessing the shared resourceat a giving moment, the access request are authorized or not. Similarly, after the use of the shared resource,the object which had the access permission must notify the arbiter, indicating that it can release the exclusiveaccess for the shared resource, and hence, it does not need using it anymore.

Although the aspects specification is an important part of non-functional handling specification, equallyimportant is the specification of which model elements are affected by aspects adaptations. Therefore, joinpoints selection are specified using a subset of Join Point Designation Diagrams (JPDD) [5].

JPDD can capture model elements based on three different models: (i) control flow; (ii)data flow; and(iii) state. The first model allows the elements selection based on the execution control flow depicted insequence or activity diagrams, e.g. a JPDD selects actions performed in the behavior of a given method “a”,which is called inside the behavior of a method “b”. The second model allows the elements selection basedon data passed from one method to other one, e.g. a JPDD selects a method behavior that has received

26

JPDD_ActiveObjectClasspackage NFR [ ]

<<SchedulableResource>><<JoinPoint>>

*

Fig. 17. JPDD 1: Selecting all classes that represent the active objects

JPDD_ActiveObjectConstruction_Action JPDD_ActiveObjectConstruction_Actioninteraction [ ]

<<SchedulableResource>>

* : *

* : *

<<JoinPoint>>

1:

Fig. 18. JPDD 2: Selecting the creation/instantiation action of all active objects

a string starting with “s” character as parameter. The last model allows elements selection base on theirexplicit state described in a state diagram, e.g. a JPDD selects all objects that are in “state A”.

The figures from 17 to 29 depict the specified JPDDs. A short description on which elements are selectedby each JPDD has been provided in the figures caption. It is important to highlight that, from these 13JPDDs, 10 JPDDs have been reused from other case studies (see [12]) without any modification. Thenew JPDDs created in this case study are: JPDD ExclusiveOperationCall, JPDD RemoteMessageBehavior,JPDD TimeBoundActivity. These JPDDs have been included into the JPDD library in order to be reusedin further cases studies.

The JPDD presented in figure 17 selects all classes (“*”) that represent active object, i.e. those classesdecorated with <<SchedulableResource>>. For instance, this join point selects the following classes:CarCrashCrisisManagementSystem, Coordinator and its child classes, CrisisManagementSystem, Vehicleand its child classes.

The JPDD presented in figure 18 selects all actions that represents the instantiation of any class rep-resenting active objects (i.e. those annotated with <<SchedulableResource>>). For instance, amongother creation objects actions, the action represented by message 4 shown in figure 9 are selected by thiscriteria and included in the join point list of elements.

On the other hand, the JPDDs presented in figure 19 and 20, select, respectively, the behavior and thedefinition of the constructor associated with the actions discussed in the previous paragraph.

27

JPDD_ActiveObjectConstruction JPDD_ActiveObjectConstructioninteraction [ ]

<<SchedulableResource>>

* : *

* : *

<<JoinPoint>>

1:

{Behavior}

Fig. 19. JPDD 3: Selecting the behavior associated with the constructor operation of all active objects

JPDD_ActiveObjectConstructor JPDD_ActiveObjectConstructorinteraction [ ]

<<SchedulableResource>>

* : *

* : *

<<JoinPoint>>

1:

{MessageDefinition}

Fig. 20. JPDD 4: Selecting the definition of the constructor operation of all active objects

28

JPDD_ExclusiveObjectClasspackage NFR [ ]

<<JoinPoint>><<MutualExclusionResource>>

*

Fig. 21. JPDD 5: Selecting all classes of objects that are accessed concurrently, but the access is exclusive for one active object at a giveninstant

JPDD_ExclusiveOperationCall JPDD_ExclusiveOperationCallinteraction [ ]

<<MutualExclusionResource>>

* : *

* : *

<<JoinPoint>>

*(..) : *1:

Fig. 22. JPDD 6: Selecting all messages sent to mutual exclusive passive objects

The JPDD presented in figure 21 selects all classes (“*”) that represent passive objects whose datamust be protected from the concurrent access of distinct active objects, i.e. those classes decorated with<<MutualExclusionResource>>. For instance, this join point selects the following classes: Crisis,RoutePlan, Vehicle and its child classes.

On the other hand, figure 22 describes the selection of all actions that represents an operation call to anypassive object whose content is protected from concurrent access.

29

JPDD_PeriodicBehavior JPDD_PeriodicBehaviorinteraction [ ]

<<SchedulableResource>>

* : *

*

<<JoinPoint>><<TimedEvent>>

*(..):*1:

{Behavior,

every = "*" }

Fig. 23. JPDD 7: Selecting the behavior of all operations that are triggered periodically

The JPDD presented in figure 23 describes the selection of the behavior triggered by the any messages(i.e. the behavior of an operation) that are annotated with the <<TimedEvent>> stereotype, whose taggedvalue every is set. In addition to this criteria, the operation must be owned by classes decorated with the<<SchedulableResource>> stereotype.

Figure 24 and 25 depict JPDDs that describe the selection of elements related to remote message sending.Figure 24 indicates that the behavior of a remote message sending should be selected, whereas figure 25represents the selection of the actions to send message to objects residing on a distinct node.

Furthermore, figure 26 shows a JPDD that selects all classes whose name ends with “System”. Likewise,figure 27 indicates that the selected elements are the constructors of all classs whose name ends with“System”. In addition, figure 28 depicts a JPDD that select the behavior of the constructors of all classeswhose name ends with “System”.

Finally, figure 29 shows the selection criteria that gathers all messages (of any class) that are decoratedwith the RTFeature whose tagged value relDeadline is set.

30

JPDD_RemoteMessageBehavior JPDD_RemoteMessageBehaviorinteraction [ ]

remote.* : *local.* : *

<<JoinPoint>>

*(..):*1:

{Behavior}

Fig. 24. JPDD 8: Selecting the behavior of all operations owned by remote objects

JPDD_SendMsgToRemoteObject JPDD_SendMsgToRemoteObjectinteraction [ ]

remote.* : *local.* : *

<<JoinPoint>>

*(..):*1:

Fig. 25. JPDD 9: Selecting the actions of sending a message to any remote object

31

JPDD_SubSystemClasspackage NFR [ ]

<<JoinPoint>>

*System

Fig. 26. JPDD 10: Selecting the classes of objects that represent (sub)systems

JPDD_SubSystemConstruction_2package NFR [ ]

<<JoinPoint>>+*System(..):*(){Behavior}

*System

Fig. 27. JPDD 11: Selecting the definition of the constructor operation of all objects representing (sub)systems

JPDD_SubSystemConstruction JPDD_SubSystemConstructioninteraction [ ]

** : *System

* : *

<<JoinPoint>>

1:

{Behavior}

Fig. 28. JPDD 12: Selecting the creation/instantiation actions of all (sub)system objects

32

JPDD_TimeConstrainedAction JPDD_TimeConstrainedActioninteraction [ ]

* : * * : *

<<JoinPoint>><<RTFeature>>

*(..) : *1:

{relDeadline = "*" }

Fig. 29. JPDD 13: Selecting the all actions that must be fully executed within a given deadline

33

VI. DISCUSSION

This paper has discussed how to use the AMoDE-RT modeling approach to specify the functional andnon-functional requirements of the bCMS case study. The presented model does not represent a SoftwareProduct Line (SPL), and hence, it focuses on the core requirements of the bCMS requirements document.Therefore, the bCMS model specifies all of the main scenarios (7 scenarios) and their alternative/exceptionscenarios (9 alternatives), as described in the requirements document. In addition, the three non-functionalrequirements have been addressed by using DERAF aspects.

Since AMoDE-RT has been proposed to deal with embedded systems design, this is the first attempt touse it outside is intended domain. The bCMS case study indicates the use of IT system elements such asPCs, user interfaces, databases, etc. Although the AMoDE-RT modeling approach does not support suchfeatures, it can be stated that it succeed in specifying the key concerns of this case study.

However, it is important to highlight that the presented model represents the fulfillment of the gapbetween the requirement engineering and the analysis/design phases. Thus, even though the model providesa platform independent view of the system structure and behavior, it also provides enough details to allowthe code generation. Finally, as mentioned, for a discussion on the whole model, please refer to report thatis available in the ReMoDD.

REFERENCES

[1] “UML profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE),” 2013, http://www.omg.org/spec/MARTE/1.0.[2] “Unified Modeling Language (uml), version 2.4.1,” 2013, http://www.omg.org/spec/UML/2.4.1/.[3] E. P. Freitas et al., “DERAF: A high-level aspects framework for distributed embedded real-time systems design,” in Early Aspects:

Current Challenges and Future Directions. Springer, 2007, pp. 55–74, DOI: 10.1007/978-3-540-76811-1 4.[4] J. Kienzle, N. Guelfi, and S. Mustafiz, “Transactions on aspect-oriented software development vii,” S. Katz and M. Mezini, Eds. Berlin,

Heidelberg: Springer-Verlag, 2010, ch. Crisis management systems: a case study for aspect-oriented modeling, pp. 1–22.[5] D. Stein et al., “Expressing different conceptual models of join point selections in aspect-oriented design,” in 5th Intl. Conf. on Aspect-

Oriented Software Development. New York: ACM, 2006, pp. 15–26.[6] Y. Vanderperren, W. Mueller, and W. Dehaene, “Uml for electronic systems design: a comprehensive overview,” Design Automation for

Embedded Systems, vol. 12, no. 4, pp. 261–292, 2008.[7] M. A. Wehrmeister et al., “An aspect-oriented approach for dealing with non-functional requirements in a model-driven development

of distributed embedded real-time systems,” in 10th Intl. Symp.on Object Oriented Real-Time Distributed Computing. IEEE ComputerSociety, 2007, pp. 428–432.

[8] M. A. Wehrmeister et al., “GenERTiCA: A tool for code generation and aspects weaving,” in 11th IEEE Intl. Symp. on Object OrientedReal-Time Computing. IEEE Computer Society, 2008, pp. 44–54. [Online]. Available: http://dx.doi.org/10.1109/ISORC.2008.67

[9] M. A. Wehrmeister et al., “An infrastructure for UML-based code generation tools,” in Analysis, Architectures and Modelling of EmbeddedSystems. Boston: Springer, 2009, vol. 310/2009, pp. 32–43. [Online]. Available: http://www.springerlink.com/content/e526553445v3335u

[10] M. A. Wehrmeister et al., “Early verification of embedded systems: Testing automation for uml models,” in Brazilian Symposium onComputing System Engineering. Porto Alegre: Brazilian Computer Society, 2012, DOI: 10.1109/SBESC.2012.31.

[11] M. A. Wehrmeister, J. G. Packer, and L. M. Ceron, “Support for early verification of embedded real-time systems through UML modelssimulation,” SIGOPS Operating Systems Review, vol. 46, no. 1, pp. 73–81, Jan. 2012, DOI: 10.1145/2146382.2146396.

[12] M. A. Wehrmeister, C. E. Pereira, and F. Rammig, “Aspect-oriented model-driven engineering for embedded systems applied to automationsystems,” IEEE Trans. on Industrial Informatics., 2013, To appear in special issue on Software Engineering in Factory and EnergyAutomation. DOI: 10.1109/TII.2013.2240308.