[IEEE 2006 International Conference on Computational Inteligence for Modelling Control and Automation and International Conference on Intelligent Agents Web Technologies and International

REQUIREMENTS DEFINITION OF SAFE SOFTWARE USING THE BEHAVIORAL PATTERNS ANALYSIS (PBA) Approach:

The Railroad Crossing System

Dr. Assem El-Ansary, CEO Emergent Technologies USA, Inc.

[email protected]

Abstract This paper is concerned with a new event-oriented approach named the Behavioral Pattern Analysis Approach (BPA). In BPA, events are considered the primary objects of the world model. BPA is a more effective alternative to use cases in modeling and understanding the functional requirements. The Event defined in BPA is a real-life conceptual entity that is unrelated to any implementation. The BPA Behavioral Patterns are temporally ordered according to the sequence of the real world events. 1. Introduction. Experience began is showing some problems with Use Cases such as [GRAHAM 96] lack of Use Case formal specification, lack of atomicity, and absence of the notion of triggering events and business goals in determining the use cases. A major problem in the use case approach is its tendency to focus on the solution rather than the problem. Use cases is what the machine does. They are parts of the solution, not parts of the problem [JACKSON 95]. The concluding statement of the “Question Time! About Use Cases” Panel of the OOPSLA’98 Conference by Ian Graham was “There is a need for another approach with a sound theoretical basis and a precise definition.” This need is what this research paper is about. In addition to the problems with the use cases [OOPSLA 98][JACKSON 95] several problems were identified during this dissertation research: � The types of interactions are: interactions among users,

interactions between users and the system, and interactions among the different components of the system. Yet, use cases describe only the users’ interaction with the system. This is just one type of interaction.

� Because use cases are used to identify the objects, if use cases do not describe all of the interactions, the resulting object (class) model may be incomplete.

� As a result of this class model incompleteness there will then be an incomplete description of the interactions, and so the sequence diagram may be incomplete.

� Using natural language in use cases description, with the absence of any semantic structure such as alternation or repetition, increases the risks of ambiguity, incompleteness, and inconsistency.

� The use case approach is using the state diagrams to complement the system behavior modeling. However a missing object or interaction is unlikely to be captured and explicitly represented in these diagrams.

In conclusion, if the analyst misinterpreted or neglected some structural or behavioral aspects, the resulting conceptual model will not be a good representation of the real world. The resulting software solution system built from the model may not demonstrate the correct behavior or may ungracefully terminate. The end result might be the loss of opportunities in using business systems, serious damages in embedded systems, or the loss of lives in using a safety-critical system.

This paper is concerned with developing BPA, which is a more effective alternative to use cases in modeling and understanding the functional requirements [ELANSARY 02]. BPA is an event-oriented approach in which events are considered the primary objects of the world model. While the term Event is used in UML, and in almost all of the other modeling approaches, to mean an occurrence of stimulus that can trigger a state transition, the Event defined in BPA is a real-life conceptual entity that is unrelated to any implementation. In the BPA approach, the BPA Behavioral Pattern, which is the template that one uses to model and describe an event, takes the place of the Use Case in the UML Use Case View. The BPA Behavioral Patterns are temporally ordered according to the sequence of the real world events. 2. Research Thesis The specific thesis is that the proposed Behavioral Pattern Analysis (BPA) Approach is more effective than the Use Case Analysis (UCA) Approach at modeling the functional requirements of Interactive Safety-Critical Real-time Systems. The following subsection presents a summary of the research approach. 3. The BPA Requirements Development Procedure The following is an outline of the BPA functional requirements development procedure: � Identify the Mission and the Scoped Problem � Identify the events at different levels of abstraction –

draw the Event Hierarchy Diagram � Identify the relationships between events – draw the

Event Thread Diagram ♦ Group the events by Location / Loci of Control and

Effect � Refine and transform the main (high level) events into

their corresponding BPA Behavioral Pattern � Identify the Temporal and Enable/Causal Constraint

relationships between events – draw the Constraints Event Thread Diagram

� Identify the Critical Events and possible ways of their failure – draw the Critical Event Analysis Diagram

� Identify missing requirements that are necessary to satisfy the critical constraints

� Using the identified missing requirements, refine the diagrams as necessary

� Using the BPA Behavioral Patterns, identify the candidate classes – draw the Class Diagram

� Depict the relationships between Events and World State if a State Model is required in the design phase – draw the Event/State History Chart.

Figure 1 illustrates the BPA functional requirements development procedure. In the following subsections, the BPA diagrams will be explained and the Crossing Railroad case study will be used to illustrate them.

International Conference on Computational Intelligence for ModellingControl and Automation,and International Conference onIntelligent Agents,Web Technologies and Internet Commerce (CIMCA-IAWTIC'06)0-7695-2731-0/06 $20.00 © 2006

E ven t

H ierarch y

D ia gram

E ven t

T h rea d

D ia gra m

C ritica l E ven t

A n a lysis

D iagram

B PA

B eha viora l

P a ttern

C lass

D ia gram

E ven t /

S ta te H istory

C h art

T em p ora l/C a usa l

C o n stra in ts

E ven t T hread

D ia gram

M issin g

R eq ’ts?

N o

R efin e d ia gram s

Y es

M ission

O p e ra ting

R e q uirem en ts

O rig ina ting

R e q uire m ents

Figure 1 Requirements Development Procedure

4.4. Introducing Time The key intuitions motivating the introduction of time are: � Events take time. Yet, in most of the popular Object-

Oriented Approaches such as OMT and UML, time is neglected in the event definition.

� Multiple events may occur at the same time, and could be unrelated, cooperating, or interfering with each other.

Events may have temporal constraints. BPA uses the time intervals’ relations that are described in the Interval Algebra framework [ALLEN 83] to model the temporal relationships between events. In this Interval Algebra framework, seven basic relations can hold between time intervals. Figure 2 illustrates these basic relations for arbitrary events x and y.

REL SYM MEANING

x before y

b

x meets y

m

x overlaps

y

o

x starts y s

x during y

d

x finishes

y

f

x equals y

eq

Figure 2 Time Interval Algebra – Temporal Relations 4.5. Introducing Enable / Cause Relationships

The introduction of the Enable1 / Cause relationships between events will enable the analyst to do cause effect analysis and reason about any possible failure of the system.

b Before

m Meets

o Overlapsd During

s Starts

f Finishes

eq Equals

i Inverse

Temporal

Relations

Figure 3 Time Interval Algebra - Temporal Relations Notation

Train EnteringCritical Region

LoweringGate

Detecting TrainIn Critical Region

ProtectingAgainst Power

Failure

HoldingGate Down

Detecting EmptyCritical Regions

Train LeavingRailroadCrossing

Gate ControllerRaising Gate

ActivatingTrack Sensor

CheckingTracks Sensor

{b}

{d,f}

{d}

{b}

{b,m,s}

{s,b}

{b}

{b,m}{b,m}

{b,m}

Figure 4 Temporal Constraint Diagram – Railroad

Crossing 4.6. Failure Issues The following is a list of possible failure reasons: � A relevant event which the system can’t handle � Event rate exceeding the system’s capacity � Non-capturing of all information triggered by event � Failure across man-machine interface � Failure of Software, Hardware, or Human. The ability to provide requirements specification for safe behavior is very limited using the current approaches. Neither a safety analysis (anterior analysis) nor accident analysis (posterior analysis) can be achieved efficiently without event analysis. As shown below, the BPA approach provides the Critical Event Analysis (defined below) as an efficient solution to this problem. 4. Illustrating BPA using the Railroad Crossing Case Study I. Mission Safe Railroad Systems II. Scope Railroad Crossing III. Critical Constraints � Safety Property Prevent vehicles and pedestrians from crossing as trains pass through the critical region

1 ‘Enable’ is defined in the American Heritage

Dictionary as: “..To supply with the means, knowledge,

or opportunity; make able: a hole in the fence that

enabled us to watch; techniques that enable surgeons to

open and repair the heart.”

x

x

y

x

y

x

y

x

y

x

y

x

y

y


� Utility Property Enable crossing of vehicles and pedestrians if no trains are detected in the critical region IV. Problem Decomposition Scoped Problem Railroad Crossing Main Events � Stop Crossing ♦ Train Approaching R ♦ Lowering Gate ♦ Train Passing Through R � Enable Crossing ♦ Train Leaving Railroad Crossing ♦ Raising Gate ♦ Indicating Empty Critical Region V. High Level Event Hierarchy

RailroadCrossing

Stop CrossingEnable

Crossing

Safety Utility

Figure 5 Event Hierarchy - Railroad Crossing

VI. Detailed Level Event Hierarchy – Stop

Crossing

Event: 'Stop Crossing'

Description: Stop pedestrian and cars crossing as trains approach the railroad crossing area

Lowering Gate


TrainApproaching R

Stop Crossing

Holding GateDown


Train PassingThrough R

Activating TrackSensor

Figure 6 Event Hierarchy Stop Crossing - Originating Requirements: Detailed Level Event Hierarchy – Enable Crossing

Event: 'Enable Crossing'

Description: Allow crossing of pedestrians and cars after trains leave the railroad crossing area. This main event represents the Utility Property of the railroad crossing.

EnableCrossing

Train LeavingRailroad Crossing

Raising Gate

Detecting Empty

Critical Regions


Figure 7 Event Hierarchy - Enable Crossing

VII. Event Thread Diagram – Stop Crossing


Lowering Gate

Holding GateDown



P Sub-region

Critical Region-R

I Sub-region

Gate G

Track Sensor T

TrackSensor T

Figure 8 Event Thread Diagram - Stop Crossing - Originating Requirements VII. Event Thread Diagram – Enable Crossing

Train LeavingRailroad Crossing




Track Sensor T

Gate G

I Sub-region

Figure 9 Event Thread Diagram - Enable Crossing BPA BEHAVIORAL PATTERN

Event (WHAT?) Train Entering Critical Region

Actions

1. 4.

2. 5.

3. 6. Roles (WHO?)

Agent a: Train

� Initial State: Outside R Final State: Enter R Affected p: Critical Region R � Initial State: Empty Final State: Occupied

Modality (HOW?)

Instrument i:

Manner m:

Circumstances

Condition c1: Empty Track c2:

Effect f1: Busy Track f2:

Date/Time (WHEN?)

t: After Detecting Empty Track

Place (WHERE?)

Location

l: Critical Region R Path

Motion Direction

m: Reduced Speed d: Left OR Right

Rationale (WHY?)

Goal g: Safe Train Approaching

Mental State bdi:

Caused-By e’:

End;

Figure 10 Train Entering Critical Region


BPA BEHAVIORAL PATTERN

Event (WHAT?) Gate Controller Raising Gate

Actions

1. 4.

2. 5.

3. 6.

Roles (WHO?)

Agent a: Gate Controller

� Initial State: Hold Down Final State: Move Up Affected p: Gate � Initial State: Down Final State: Up

Modality (HOW?)

Instrument

i:

Manner

m:

Circumstances

Condition c1: Gate Down c2: Track Sensor Off

Effect

f1: Gate Up f2:

Date/Time (WHEN?) l: After Train Leaving Railroad Crossing

Place (WHERE?) Location

l: Railroad Crossing Path: Motion Direction

m: Gate Moving d: Up

Rationale (WHY?)

Goal g: Enable Crossing

Mental State bdi:

Caused-By e’:

End;

Figure 11 Gate Controller Raising Gate

IX. Temporal Constraint Diagram


LoweringGate



Failure

HoldingGate Down






{b}

{d,f}

{d}

{b}

{b,m,s}

{s,b}

{b}

{b,m}{b,m}

{b,m}

Figure 12 Temporal Constraint Diagram - Railroad

Crossing

X. Critical Event Analysis Diagram

GateAccident

Train CollisionTrain

Accident

Accident

OR

Figure 13 Critical Event Analysis Diagram -

Railroad Crossing Safety

Train

Accident

AND

Train Leaving

RTrain Enter R

OR

Train In R

AND

Gate Controller

Down Hold Error

Sensor

Activation Error

Gate Up

Power Failure Gate Controller

Activation Error

OR

Gate Up

Possible Failure Source

Undesired Event

Figure 14 Critical Event Analysis Diagram – Train

Accident

TrainApproaching R

DetectingOccupied Track

NOT

AND

Train CollisionGate

Accident

LoweringGate

Vehicles andPassangers

Crossing

AND

Safety Light is required to warnnext train's driver Crossing Alarm Required

Figure 15 Critical Event Analysis Diagram - Derived

Safety Requirements

XI. Missing Requirements

During the BPA analysis in the Critical Event Analysis

stage, the following possible problems were discovered:

Train Collision If a train is already in the critical region, and another train is approaching the railroad crossing on the same track, a train collision will occur unless the coming train is stopped before entering the critical region. Therefore, we need to warn that coming train’s driver that there is another train, on the same track, in the


critical region so s/he can stop the train. To solve this problem, a Safety light was introduced before the critical region. 1. Gate Accident If gate closes as pedestrians or vehicles are crossing, an accident would occur. Therefore, we need some warning mechanism for pedestrians and drivers to stop crossing before the gate controller lowers the gate. To solve this problem, a crossing alarm was introduced at the railroad crossing. The Originated Requirements were revised and the following Derived Requirements document was generated. Derived Requirements Document

2

P

PI

I

R

R

A

A

S

S

Figure 16 Railroad Crossing – Derived Requirements

2 The Originating Requirements of this case

study addressed safety in an ambiguous way.

Consider a set of two trains, running in opposite directions, traveling through regions R on two tracks. Each whole region R is split into two sub-regions, P and I. The system to be developed operates a gate at the railroad crossing sub-region, which will be identified as I. P lies outside the entrance to I. A train first enters P (within R but outside I), then travels through the crossing (I), and finally exits a critical region R. Track sensors detect when a train enters P. A gate controller uses sensor data to control the gate (G). When no train is present in P, the gate G at the crossing remains in the up position, allowing the passage of vehicles and pedestrians. However, once a train enters P, an alarm (A) at the crossing sounds before the gate G closes in the down position

3. The gate closes when the train

enters P. The gate remains closed in the down position until the train exits I. When no train is detected in I, the gate opens to the up position. As an added safety precaution, a safety light (S) will be placed at the entrances of P. If one train is anywhere in R, the safety light L will display red, warning a second train that it may not enter P at that time. As soon as the first train exits R, S will display a green light, notifying the second train that it is safe to enter P

4.

XI. Refinement Stage Detailed Level Event Hierarchy (Refined) – Stop Crossing

Event: 'Stop Crossing'

Description: Stop pedestrian and cars crossing as trains approach the railroad crossing area

Lowering Gate


TrainApproaching R

StartingCrossing Alarm

Stop Crossing

Holding GateDown


DetectingEmpty Track

Train PassingThrough R

Turning SafetyLight Red


Figure 17 Event Hierarchy - Stop Crossing (refined) Detailed Level Event Hierarchy (Refined) – Enable Crossing

3 The alarm was added after performing a

safety analysis of the system in the BPA approach. 4 The safety light S was added after doing a

safety analysis of the system in the BPA approach.


Event: 'Enable Crossing'

Description: Allow crossing of pedestrians and cars after trains leave the railroad crossing area. This main event represents the Utility Property of the railroad crossing.

EnableCrossing

Train LeavingRailroad Crossing Raising Gate

StoppingCrossing Alarm



Turning SafetyLight Green

Indicating EmptyCritical Region

Figure 18 Event Hierarchy - Enable Crossing (R) VI. Event Thread Diagram (Refined) – Stop

Crossing



Lowering Gate

Holding GateDown



Turning SafetyLight Red Activating Track

Sensor

Stop Crossing

Safety Light S P Sub-region

Critical Region-R

I Sub-region

Crossing Alarm A

Gate G

Track Sensor T

TrackSensor T

Figure 19 Event Thread - Stop Crossing (refined)

Event: 'Detecting Empty Track'

Description: If a train is anywhere in the critical region R, on the same track, a safety light (S) that is positioned before the critical region R (before P) will display a red light to warn the driver that another train is on the same track within the critical region. As soon as the other train exits the crossing (sub-region I), the driver signals light will change to green.

Stopping Train

Checking SafetyLight S


Detecting Empty Track

Light Status

Green

Light Status

Red

Figure 20 Event Thread - Detecting Empty Track

(derived)

VII. Event Thread Diagram (Refined) – Enable Crossing

Train LeavingRailroad Crossing Gate Controller

Raising Gate





Enable Crossing

Track Sensor T

Gate G

Crossing Alarm A

Safety Light S

I Sub-region

Figure 21 Event Thread - Enable Crossing (refined) Event (WHAT?) Starting Crossing Alarm

Actions

1. 4.

2. 5.

3. 6.

Roles (WHO?)

Agent a: Alarm Control

� Initial State: Idle � Final State: Activated Affected p: Crossing Alarm � Initial State: Off � Final State: On

Modality (HOW?)

Instrument i: Track Sensor

Manner m: Critical

Circumstances

Condition c1: Track Sensor ON c2: Gate Up

Effect

f1: Stop Crossing f2:

Date/Time (WHEN?) l: After Train Entering Critical Region

Place (WHERE?) Location

l: Crossing Area I

Path: Motion Direction

m: d:

Rationale (WHY?)

Goal g: Safe Train Approaching

Mental State bdi:

Caused-By e’: Train Entering Critical Region

End;

Figure 22 Starting Crossing Alarm (derived)


XI. Temporal Constraint Diagram (Refined) – Enable Crossing




LoweringGate



Failure

HoldingGate Down

Detecting Empty

Critical Regions




Turning SafetyLight Red




{b,m,d}{b}

{d,f}

{d}

{b}

{b,m,s} {b,m}

{b,m}

{b,m}

{b,m,d}

{b}

{b}

{s,b}

{b}

{b,m}{b,m}

{b,m}

Figure 23 Temporal Constraint Diagram - Enable Crossing (refined) XII. Railroad Crossing CLD

Train

Gate Controller

Track Sensor Gate

Crossing Alarm

Critical Region

Safety Light

*

1Activates

1

1

Activates

2

1

Controls

21 Operates

2

1..*

Activates

1

1

Has

1..*

ChangeColor

*1Has

1

1

Has

1..*

Figure 24 Class Diagram - Safe Railroad Crossing 5. Why This Work Is Important 5.1 Real-time Systems In most of the popular object-oriented development approaches state diagrams are used to model the behavior. By using state diagrams, one is focusing on an individual object’s response to specific events rather than objects interaction. Hence, objects interaction must be reconstructed from the analysis of groups of diagrams. Such a task is at least complex and error-prone. By describing the requirements in terms of events, represented by the behavioral patterns, this perceived problem is reduced. 5.2 Multi-agent Systems

Modeling a multi-agent system using UML is an extremely difficult to an impossible task. There is a need for a multi-agent systems analysis and design method that is powerful enough to model interaction patterns involving autonomous agents as well as the knowledge structure that they need to manipulate]. 5.3 Safety-critical Systems In safety-critical systems, the requirements should correctly reflect the critical properties of the environment in which software is to work. In these systems, analysts should perform a ‘Safety Analysis’. Using BPA, one identifies and documents the critical events during the requirements definition stage. GOD says [KORAN][TORAH], “ … Whoever rescues a single life earns as much merit as though he had rescued the entire world.” If the use of the BPA Approach may save one life, the significance of this approach is immeasurable.

Bibliography

[ALLEN 83] Allen, J. F., Maintaining Knowledge about Temporal Intervals, Communications of ACM, 26, 1983, pp 832-843

[BOOCH 99] Booch, G.,Jacobson, I., and Rumbaugh, J., The Unified Modeling Language User Guide, Addison Wesley, Reading, Massachusetts, 1999.

[ELANSARY 02] El-Ansary, Assem I., Behavioral Pattern Analysis: Towards a New Representation of Systems Requirements Based on Actions and Events, in Proceedings of the 2002 ACM Symposium on Applied Computing, ACM, New York, NY, 2002.

[GRAHAM 95] Graham, Ian, Migrating to Object Technology, Addison-Wesley, Reading, Massachusetts, 1995.

[HEITMEYER 96] Heitmeyer, Constance and Mandrioli, Dino, Formal Methods for Real-Time Computing: An Overview, in Formal Methods for Real-Time Computing, John Wiley & Sons, Inc., NY, 1996.

[JACKSON 95] Jackson, Michael, Software Requirements & Specification, A Lexicon of Practice, Principles and Prejudices, ACM Press, Addison-Wesley, Reading, Massachusetts, 1995.

[JACOBSON 95] Jacobson, I., The Use Case Construct in Object-Oriented Software Engineering, in Carroll, J., Scenario-Based Design, John Wiley & Sons, Inc., NY, 1995.

[OOPSLA 98] Fowler, Martin and Cockburn, Question Time! About Use Cases, OOPSLA’98 Proceedings, ACM Press, New York, NY, 1998.


Documents

[IEEE 2006 International Conference on Computational Inteligence for Modelling Control and Automation and International Conference on Intelligent Agents Web Technologies and International