CAS Example

1
CAS Example

• Wei-Tek Tsai

2
Introduction

• This slides will demonstrate how to apply E2E
  Scenario Tools to the application Car Alarm
  System (CAS).
• E2E Scenario Tool analyzes CAS requirements,
  decomposes natural language requirements into
  ACDATEs (Actors, Conditions, Data, Actions,
  Timing, and Events) and models CAS system into
  semi-formal format --- Scenarios.
• Once CAS ACDATE/Scenario model is constructed,
  various UML diagrams such as flowchart diagram
  and sequence diagram can be generated from the
  scenario specification automatically.
• In order to learn basic operations of E2E
  Scenario Tools, please refer to Scenario Tool
  User Manual.

3
Abstract

• Original Requirements
• E2E Scenario Specification Process
• A Scenario Specification Example
• Scenario-Based Analysis

4
Original Requirements
5
Original Requirements (Cont.)
6
Original Requirements (Cont.)
7
Overall Process
8
E2E Scenario Specification Process

• Step1 Separate System and Environment
• Step2 System Decomposition
• Step3 ACDATE Decomposition
• Step4 Construct System Scenarios (SS) with
  ACDATE Information
• Step5 Create Templates

9
Step1 Separate System and Environment

• The first step is to separate environment from
  system based on the system requirement documents.
  This steps helps to decide what needs to be
  modeled and simulated. Environment doesnt need
  to be modeled, but it will drive E2E simulation.
  The system and environment of CAS are listed in
  the following table

10
Step2 System Decomposition

• A system (even a simple system like CAS) is
  usually hierarchical. Therefore the system
  decomposition process should also be
  hierarchical, from the highest level down to the
  lowest level. For example, the decomposition of a
  hierarchical CAS can be divided into two
  sub-steps, based on the CAS system and
  environment architecture done in Step1.

11
Step3 ACDATE Decomposition

• In this step we need to decompose system
  requirements into ACDATEs (Actor, Condition,
  Data, Action, Timing and Event) to describe
  systems in tail.
• There exist different kinds of ACDATEs according
  to their different definitions. In the following
  section, well analyze CAS requirements and
  enumerate examples for each kind of ACDATE.

12
Actor

• Actor Example In the requirement SR2, both
  alarm and remote controller are actors,
  because remote controller performs the action
  turn off, and alarm is the receiver of this
  action.

13
Condition

• Condition Example In the requirement SR3, both
  the status of driver door and passenger door,
  trunk, hood are closed and alarm is armed and
  time elapsed from the status specified above is
  0.5 seconds are conditions, because they are two
  decision point for the actor drivers door and
  passengers door to trigger the action get
  locked.

14
Data

• Data Example Lets look at the requirement SR3
  again. Weve identified two conditions the
  status of driver door and passenger door, trunk,
  hood are closed and alarm is armed and time
  elapsed from the status specified above is 0.5
  seconds. The first condition involves four
  entities driver door status, passenger door
  status, trunk status and hood status, while
  the second condition involves one entity alarm
  status.

15
Action

• Action Example Requirement SR 10 includes two
  actions unlocks the drivers door and unlocks
  the front passengers door.

16
Timing

• Timing Example Requirement SR 3 specifies the
  timing constraint 0.5 seconds.

17
Event

• Event Example Requirement SR 4 is triggered by
  the event the trunk is opened with the key.

18
Step4 Construct System Scenarios (SS) with
ACDATE Information

• Though all the CAS requirements are listed in the
  Original System Requirements Section, only few
  analyses can be done with those natural language
  requirements due to the limitation and difficulty
  in parsing natural languages.
• Therefore we need to transform system
  requirements into a semi-formal format ----
  Scenarios, based on which the system can be
  modeled, simulated, analyzed and tested. In E2E
  Scenario Tool, all the scenarios are logic
  combinations of ACDATEs.

19
Scenario Example

• CAS_RC_concurrently_disarm_unlock_handler_SCNR
• (Trigger Event --- eTurnOffAlarmAndUnlockByRC)
•  
• using ACTORAlarm
• using ACTORDriverDoor
•  
• if (true)
• then
• do ACTIONAlarm.TurnOffAlarm
• do ACTIONDriverDoor.UnlockDriverDoor
• else

20
Actor Usage Example
21
Condition Usage Example
22
Data Usage Example
23
Action Usage Example
24
Event Usage Example
25
Step5 Create Templates

• Scenarios may share similar logical structure,
  which can be reused in scenario construction.
• In E2E Scenario Tools, those logical structures
  are called templates.
• The advantages of templates are not only in
  scenario construction reusability, but also in
  requirement change management.
• Suppose changes in requirement will cause logical
  structure changes of 1000 scenarios. Without
  templates, all those changes have to manually
  done one scenario by one scenario. But if all
  those 1000 scenarios are derived from a template,
  what we need to do is just to change that
  template itself, and the logical structures of
  all those linked 1000 scenarios will change
  accordingly. 10001, template method will save
  99.9 efforts in change management.

26
Scenario Specification Example

• In this section, well illustrate scenario
  specification process with a detailed scenario
  example, which is based on CAS Requirement 10

• ACDATEs can be decomposed from the above
  requirement (marked with different colors)
• When the drivers door and passengers door are
  locked, pressing unlock for the first time on
  remote controller unlocks the drivers door the
  second time unlocks the front passengers door.

27
Decomposed ACDATEs

• Actors 1. Drivers door
• 2. Passengers door
• 3. Remote controller
• Conditions 1. Drivers door is locked
• 2. Passengers door is locked
• 3. Drivers door is closed but unlocked (This
  condition is an implicit condition, which is the
  result of the action unlocks the drivers door)
•  
• Data 1. Drivers door status (Locked / Closed
  but unlocked / Open)
• 2. Passengers door status (Locked / Closed but
  unlocked / Open)
•  
• Actions 1. Unlock the drivers door
• 2. Unlock the passengers door
•  
• Events 1. Pressing unlock for the first time
  on remote controller
• 2. Pressing unlock for the second time on
  remote controller

28
Constructed Template
29
Generated Scenario
30
Scenario Dependency Analysis
31
Thin Thread Generation
32
CAS ACDATE, Scenario and Thin Thread Statistical
Data
33
Automated Flowchart Diagram Generation
34
Automated Sequence Diagram Generation
35
Report Generation
36
Entity Report