A Requirements PatternsDriven Approach to Specify Systems and Check Properties

1
A Requirements Patterns-Driven Approach to
Specify Systems and Check Properties

• Betty H.C. Cheng
• Laura A. Campbell
• Min Deng
• Sascha Konrad

This work is supported in part by grants from NSF
(EIA-0000433, CDA-9617310, CCR-9901017), ONR
(N00014-01-1-0744) Automotive applications from
Siemens Automotive
2
Overview

• Introduction
• Background
• MINERVA
• Hydra
• SPIN
• Requirements Patterns
• Modeling and Analysis Process
• Conclusion
• Future Work

3
Introduction

• Requirements modeling and analysis
• One of the most difficult tasks in software
  development
• Behavioral specification of the system activities
• Describes a systems modes of operation and
  events that cause mode changes
• Challenges
• Software does not execute in isolation
• Environment (incl. User)
• Hardware
• Current technology involves ad hoc techniques
  from natural language specifications to code
• Interest in using OO and UML

4
Logical Architecture of Embedded Systems Broy

• Modeled as part of the Requirements Engineering
  process
• An embedded system typically consists of
• Capture behavior of components and their
  interaction
• Collectively they provide requirements of system

5
Overview

• Introduction
• Background
• MINERVA
• Hydra
• SPIN
• Requirements Patterns
• Modeling and Analysis Process
• Conclusion
• Future Work

6
Background

• MINERVA
• Based on Honeywells DoME (Domain Modeling
  Environment)
• Graphical construction of UML diagrams adhering
  to a defined metamodel
• Generates intermediate language for diagrams
  (HIL)
• Visualization of consistency-checking results,
  simulation traces, and paths of execution
• Hydra
• Mapping from UML (via HIL) to the target language
  (such as Promela, VHDL)
• Checks for semantic errors in the HIL file
• Transforms LTL-claims into the format expected by
  the model checker used

7
Background

• SPIN
• Developed by Bell Labs starting 1980
• On-the-fly model checker
• Formal specification language Promela
• LTL Model Checking System
• Features
• Offers simulation
• Exhaustive verification
• Proof approximation
• Designed to handle large system sizes efficiently

8
Background

• Pattern Overview
• Analysis Patterns Recurring reusable analysis
  models
• Design Patterns Solution skeletons for software
  design, often object oriented
• Organizational Patterns Structure of
  organizations/ projects
• Process Patterns Software process design
• Security Patterns Skeletons to provide system
  security
• Requirements Patterns (our focus)
• Many more existing, Patterns can be found in
  almost any domain

9
Pattern Essentials

• A pattern has 4 essential elements
• Pattern name
• Problem
• Solution
• Consequences

10
Requirements Patterns Template

• Pattern Name and Classification
• Intent
• Also Known As
• Motivation
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns

• Design Patterns
• Template Gamma
• Idea
• Use similar approach
• More concrete than analysis patterns
• More abstract than design patterns

11
Requirements Patterns Template

• Pattern Name and Classification
• Intent
• Motivation (incl. use cases)
• Constraints
• Applicability
• Structure (class diagram)
• Behavior (sequence, state)
• Participants
• Collaborations
• Consequences
• Design Patterns
• Also Known As
• Related Patterns

• Pattern Name and Classification
• Intent
• Also Known As
• Motivation
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns

12
Overview

• Introduction
• Background
• MINERVA
• Hydra
• SPIN
• Requirements Patterns
• Modeling and Analysis Process
• Conclusion
• Future Work

13
Modeling and Analysis Approach
14
Requirements Patterns Roadmap
15
Diesel Filter System

• Self cleaning particulate filter
• Goal Reduce amount of particulate combustion
  aerosols (soot) emitted by diesel engines
• System consists of several filter tubes that
  filter particulates
• Trapped particulates build up, letting the
  pressure in the filter canister rise
• Filters can be heated up by applying an electric
  current to wires embedded in the grid, burning
  off trapped particulates
• http//www.dieselnet.com/papers/9812mayer.html

16
Modeling Approach

• In order to enable the system for model checking
  the following components are used
• _SYSTEMCLASS_ process
• Instantiates classes
• Picks non-deterministically system and
  environment conditions
• Initiates system execution
• Environment process
• Contains values for system and environment
  conditions chosen according to equivalent classes
  derived from the requirements
• Remaining processes
• Contain the components of the system

17
Requirements Constraints

• Equivalence classes derived from the
  requirements
• determine the modes the system is operating in

18
Environmental Parameters

• Additional equivalent classes are needed to
  model
• different interactions with the physical
  environment

19
Diesel Filter System
20
Analysis-EnabledDiesel Filter System
21
Requirement 1

• Watchdog Pattern
• General Claim
• (Violation -gt ltgt Start recovery action)
• Instantiated Claim
• ((Watchdog.Violation 1)
• -gt ltgt (ComputingComponent.PowerStatus 0))
• If the watchdog detects a violation, then the
  system should turn off
• Analysis
• A violation was detected using model checking
• State diagram animation revealed a missing
  transition as the cause

22
Requirement 1
ShutdownES/
23
Requirement 2

• Watchdog Pattern
• General Claim
• (Violation -gt ltgt Indicator activated)
• Instantiated Claim
• ((Watchdog.Violation 1)
• -gt ltgt (DriverDisplay.DriverDisplayValue 1))
• If the watchdog detects a violation, then the
  driver display should be actiavted
• Analysis
• A violation was detected by the model checker

24
Requirement 2

• Subsequent Analysis
• Watchdog Pattern
• (Watchdog.Violation 1
• -gt ltgt (sent(FaultHandler.StoreError(200))))
• FaultHandler Pattern
• (sent(FaultHandler.StoreError(200))
• -gt ltgt (sent(UserIterface.ActivateWarningLevel(1)))
  
• User Interface Pattern
• (sent(UserIterface.ActiavateWarningLevel(1))
• -gt ltgt (DriverDisplay.DriverDisplayValue
  1))
• Last claim uncovered the reason of the violation.

25
Requirement 2
26
Requirement 2

• Transition Trace
• Object UserInterface transitions from state
  Initial" to state Idle" on event modelstart
• Object UserInterface transitions from state
  Idle to state Check on event
  ActivateWarningLevel(WarningLevel)
• Object UserInterface transitions from state
  Check to state Idle on condition
  WarningLevel1

27
Overview

• Introduction
• Background
• MINERVA
• Hydra
• SPIN
• Requirements Patterns
• Modeling and Analysis Process
• Conclusion
• Future Work

28
Conclusions

• Requirements patterns
• Give guidance for structure of UML diagrams
• Constraints section in patterns
• Give guidance for properties to check
• Formalization work and tool suite
• Enable rigorous checking of requirements using
  simulation and model checking techniques
• Visualization tools
• Help locate errors in original diagrams
• Facilitate model refinement

29
Overview

• Introduction
• Background
• MINERVA
• Hydra
• SPIN
• Requirements Patterns
• Modeling and Analysis Process
• Conclusion
• Future Work

30
Future Work

• Current and furture work will
• Extend our tools and patterns to support timing
  aspects
• Make the environment component dynamic
• Extend our pattern repository
• Examine how to abstract model specifications

31
Future Work

• Is this example safe?
• !(Train.in1
• Gate.down0)
• Maximum Execution Time
• Miniumum/Maximun Time in a
• State

32
Acknowledgements

• Software Engineering and Networking Systems
  Faculty/Students
• This work has been supported in part by
• NSF grants EIA-0000433, EIA-0130724, CDA-9700732,
  CCR-9901017, Department of the Navy, Office of
  Naval Research under Grant No. N00014-01-1-0744,
  and DARPA grant No. F30602-96-1-0298, managed by
  Air Forces Rome Laboratories
• Eaton Corporation, a Motorola doctoral
  fellowship, and in cooperation with Siemens
  Automotive and Detroit Diesel Corporation

33
Questions/Discussion
34
References
35
References
36
References