S oftware E ngineering & N etwork S ystems Lab A Requirements Pattern-Driven Approach to Modeling and Analyzing Embedded Systems Betty H.C. Cheng Software.

S oftwareE ngineering &N etworkS ystems Lab

A Requirements Pattern-Driven A Requirements Pattern-Driven Approach to Modeling and Analyzing Approach to Modeling and Analyzing

Embedded SystemsEmbedded Systems

Betty H.C. Cheng

Software Engineering and Network Systems Lab

Michigan State University

This work is supported in part by:

Grants from NSF 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 Force’s Rome Laboratories, Siemens Corporate Research, Eaton Corporation, Motorola, and in cooperation with Siemens Automotive and Detroit Diesel Corporation.

S oftwareE ngineering &N etworkS ystems LabSoftware Engineering and Network Software Engineering and Network

Systems LaboratorySystems Laboratory

Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners


SENS PersonnelSENS Personnel• Betty H.C. Cheng: software engineering, patterns, OO, formal methods, embedded systems.

• Laura K. Dillon: specification and validation of concurrent systems

• Kurt Stirewalt: interactive systems, program reasoning, SE.

• Jonathan Shapiro: Network protocols, security, peer-to-peer systems

• Philip McKinley: distributed computing, networking, OS, adaptive middleware

• Sandeep Kulkarni: fault tolerance in distributed systems

• Approximately 30 grad research assistants• Occasional visiting scholars and postdocs

Bridge the Gap Between Informal and Formal Methods

Object-Oriented “Blueprints”

Informal specifications,• graphical models,• easy for humans to formulate, •may be inconsistent and incomplete.

Fo

rmalizatio

n T

echn

iqu

es an

d P

attern

s

Formal Representations

Objective:• formal specifications• executable code• that can be verified for correctness and completeness

Benefits:•Automated Analysis

•Consistency, completeness•Rapid Prototyping•Behavior Simulation

• Design Transformations•Test Case generation

6


OutlineOutline

Introduction

UML Formalization

Modeling and Analysis Process

Conclusions

Future Work

Requirements Patterns

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

7


IntroductionIntroduction

• Many embedded systems require high assurance (e.g. automotive, medical)

• Requirements modeling and analysis – One of the most difficult tasks in software development– Focus on behavioral specification of system activities– Describes a system’s modes of operation and events that

cause mode changes

• Challenges for embedded system development:– Software does not execute in isolation:

• Environment (including User)• Hardware

– Current technology involves ad hoc techniques from natural language specifications to code

• ES community interested in using OO and UML

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

8


Problem StatementProblem Statement

• Desirable properties of requirements analysis documents:– Easy to interpret– Structural description of system– Behavioral description of system – Descriptions should be concise and correct– Requirements analyzable for critical properties

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

9


General ApproachGeneral Approach

• Objective:– Easy to use notation and technique for capturing

requirements– Notation must be amenable to rigorous analysis

• Proposed Solution:– Provide process and requirements patterns for

constructing UML diagrams– Formalizing UML enables automated analysis of

UML diagrams– Visualize analysis errors in terms of original UML

diagrams

• Project Collaborators:– Dr. Kurt Stirewalt– Dr. L. Campbell, Dr. W. McUmber, Dr. E. Wang– R. Bourdeau, G. Coombs, M. Deng, H. Goldsby, S.

Konrad

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

10


OutlineOutline

Introduction

UML Formalization


Conclusions

Future Work


Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

11


UML FormalizationUML Formalization

• Automate translation of diagrams into a formal language– OMT Formalization

• [TSE95, ICSE97, J. SEKE00, TSE02, IWSSD00, DSN00]

– UML Formalization [HASE99, ICSE01]

• General framework for mapping diagrams to multiple formal languages

• Embedded systems domain• Currently targets Promela

– Hydra• Mapping from UML to the target language (such as

Promela, VHDL)• Enables execution through simulation and analysis

through model checking

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

12


UML MetamodelUML Metamodel

• Metamodel defines UML syntax using class diagram notation.

• Semantics not defined by metamodel

• Note: Any language or diagram syntax can be defined with a metamodel

Program

SimpleStatement

CompoundStatement

Block0..*

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

13


Unified Class/Dynamic Unified Class/Dynamic MetamodelMetamodel

ModelModel

ClassClass RelationshipsRelationships

InstanceVariables

InstanceVariables AggregationAggregation GeneralizationGeneralization

AssociationAssociation

BehaviorBehavior

State VertexState Vertex

TransitionTransition

Rest of dynamic model

Class related

Dynamic related

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

14


Example Metamodel MappingExample Metamodel Mapping

h:

h:

h:

h:

h:

AA BB

CC

R

hasComp(A,C)

Source

B’B’ A’A’

C’C’

D’D’

hasPart(A’,C’)

R’

Target

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

15


MetMetaamodel mappingmodel mapping

UMLdiagram

UMLdiagram

Describes instance

Formal descriptionof system

Formal descriptionof system

Describes instance

UMLmetamodel

UMLmetamodel

Formal languagemetamodel

Formal languagemetamodelHomomorphism

Mapping Rules

Producesmapping

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

16


Introduction to Mapping RulesIntroduction to Mapping Rules

• VHDL used for embedded systems– VHDL contains time notations

– Many commercial tools available

– Comprehensive simulation capability

• SPIN used in industry– Spin provides model simulation and

checking

• Concurrency is a feature of both

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

17


Summary of MappingsSummary of Mappings

VHDL

Ent/Arch

Port signature

procedure

Ent/Arch

Write to signal

Promela

proctype

channels

Labeled blockof statements

proctype

Channelassignment

Class

Relationship

State

CompositeState

Event

Structure

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

18


Tool SupportTool Support

MINERVA HydraAnalysis

Tool*HIL

Analysis results

Diagramreports

Analysis reports

Spec*UML

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

19


Architecture of MinervaArchitecture of Minerva

UML

Diagram in DoME format

Diagram reports

Analysis reports

Visualizationcommands

HIL

Analysis results (raw)

Analysis results (processed)

UML diagrameditors Plug-ins

Text processingscripts

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

20


MINERVAMINERVA

– MINERVA• Based on Honeywell’s DoME (Domain

Modeling Environment)• Graphical construction of syntactically

correct UML diagrams adhering to a defined metamodel

– [RE-01]

• Visualization of consistency-checking results, simulation traces, and paths of execution

• Enables roundtrip engineering of UML diagrams

– [REJ-02, RHAS-02, Spin-03]

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

21


Hydra Translation ToolHydra Translation Tool

HydraparserHydraparser

Implements mapping rules

for specific language

Uses library and parser to implement rules

Modular performal language

Language Specific Class

Library

HIL

FormalSpecifications

Minerva

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

22


OutlineOutline

Introduction

UML Formalization


Conclusions

Future Work


Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

23


PatternsPatterns• Patterns Overview:

– Analysis Patterns: Recurring & reusable analysis models [Fowler]

– Design Patterns: Solution skeletons for (OO) software design [Gamma et al]

– Organizational Patterns: Structure of organizations/ projects

– Process Patterns: Software process design– Security Patterns: Skeletons to provide

system security [Fernandez, Yoder, RHAS03]

– Requirements Patterns: conceptual model, system constraints [RE02,RHAS02,SPIN03]

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

24


A pattern has 4 essential elements:

• Pattern name• Problem• Solution• Consequences

NAMENAME

PROBLEMPROBLEM

SOLUTIONSOLUTION CONSE-CONSE-QUENCESQUENCES

Pattern EssentialsPattern EssentialsOverview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

25


Logical Architecture of Embedded Systems Logical Architecture of Embedded Systems [Broy][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

UI CDA PDS

User

Environment

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

26


Requirements Patterns TemplateRequirements Patterns Template

• Pattern Name and Classification

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

Design Pattern Design Pattern TemplateTemplate • 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

Requirements Pattern Requirements Pattern TemplateTemplate

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

27


Behavioral PatternsBehavioral Patterns

Communication Link:

• describes how to capture high-level information about communication capabilities offered by an embedded system, •such as sending periodic heart beat messages to other systems.

Computing Component:

• specifies various operational modes of an embedded system, •such as fail-safe modes that a system enters in response to occurring faults.

Detector-Corrector:

• detectors offer fault detection capabilities,• correctors offer fault correction capabilities, and •the interaction between both types of components is controlled by a local fault handler.

Fault Handler : • A global fault handler collects fault messages from the local fault handlers and • Acts as a central coordinator for system recovery and safety.

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

28


Actuator-Sensor:

• specifies basic types of sensors and actuators in an embedded system and • describes how relationships between these actuators and sensors and other components in the system can be captured.

Controller Decompose:

• describes how to decompose an embedded system into different components according to their responsibilities.

User Interface:

• describes how to specify an object model for a user interface that is extensible and reusable.

Structural PatternsStructural PatternsOverview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

30


Actuator-Sensor PatternActuator-Sensor Pattern

• Motivation:– ES have various kinds of

sensors/actuators– Can distinguish two main categories

of sensors:• PassiveSensors (pull: controller requests

information)• ActiveSensors (push: sends information

to controller)

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

Actuator-Sensor Pattern: StructureActuator-Sensor Pattern: Structure

PassiveSensor ComputingComponentActuator

ActiveSensor

PassiveBooleanSensorPassiveBooleanSensor

PassiveIntegerSensorPassiveIntegerSensor

PassiveRealSensorPassiveRealSensor

PassiveComplexSensorPassiveComplexSensor

Actuator-Sensor Pattern: Behavior Actuator-Sensor Pattern: Behavior (sequence diagram)(sequence diagram)

FaultHandlerTemperature

SensorComputingComponent

RadiatorValve

Sensor Input Device

TemperatureSensor

ActuatorOutputDevice

TemperatureSensor

33



• Consequences:– Common Interface– Class attributes are accessed

through messages– Pattern describes when to use active

and passive sensors

34



• Constraints:– Specification patterns [Dwyer98] for properties

of interest.

Response pattern:– When the value of an active sensor changes, the

computing component should receive the updated

value.– [](ActiveSensor.``Value change’’ -> <>(``Send updated value to Computing

Component’’))

Response pattern:– When an active sensor times out, a fault message

should be sent to the fault handler. – [](ActiveSensor.``Timeout’’-> <>(``Report timeout to fault handler’’))

35


OutlineOutline

Introduction

UML Formalization


Conclusions

Future Work


Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

36


RequirementsPatterns

ProseRequirements

LTLProperties

User

Minerva

ModelChecking

Simulation

Hydra

SPIN

commands

UML

HIL

Promela

Modeling and Analysis ApproachModeling and Analysis Approach

11

11

22

33 44

77

77

66

77

55

66

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

37


Diesel Filter SystemDiesel Filter System

• Self cleaning particulate filter in diesel trucks• 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

exhaust+ soot

filterexhaust

pipeexhaust- soot

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

38


Modeling ApproachModeling Approach

• In order to enable model checking of a system the following elements are modeled:– Environment class

• Contains system and environment condition values chosen from equivalence classes derived from the requirements

– _SYSTEMCLASS_ class • Instantiates classes• Non-deterministically picks system and environment

conditions• Initiates system execution

– Remaining classes• Contain the components of the system

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

39


Analysis-Enabled Diesel Filter SystemAnalysis-Enabled Diesel Filter System

PressureDetector:

UserInterface:

1

CurrentMirror1:

PressureSensor:

controlsEnvironment:

_SYSTEMCLASS_:

FaultHandler:

CurrentMirror2:

EngineControlUnit:

HeaterRegulator1:

HeaterRegulator2:

DriverDisplay:

monitors

controls

affects

affects

controls

controls controlsreports

11

1

1

1

1

1

1

1

1

1

11

1

1 1

1 1

1

1

1reads

1 1

ComputingComponent:

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

40


Environmental ParametersEnvironmental Parameters

0, Component not working

1, Component working

No cleaning needed[0;8,000],

Cleaning needed(8,000;10,000],

System shutdown(10,000; ),

[

Component OperationStatus

CurrentSystemPressure

TotalRPMValue

0;10,000) , Cleaning disabled

[10,000; ) , Cleaning enabled

[0;700) , Cleaning disabled

[700, ) , Cleaning enabledCurrentRPMValue

Equivalence classes derived from the requirements determine the modes in which the system operates:

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

41


Environmental ParametersEnvironmental Parameters

250

300

3,000

2

3

4

PressureSensorCleanupValue

HeaterCurrentConversionRatio

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

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

42


Detector-Corrector Pattern:• General Claim:

– If there is a violation, then start recovery action.

[](“Violation” -> <> “Start recovery action”)

• Instantiated Claim:– If the pressure detector detects a violation, then the

system should turn off

[]((PressureDetector.Violation == 1) -> <> (ComputingComponent.PowerStatus == 0))

• Analysis Results:– A violation was detected using model checking – State diagram animation revealed a missing transition

as the cause

Requirement 1Requirement 1Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

44


[CurrentPressureVal<=8000]/^PressureSensor.GetCurrent

PressureValue

PowerOff

entry/PowerStatus:=0

GetPressure2

Idle

ShutdownES[]/

Normal Behavior

ShutdownES[]/

(elided)

GetPressure1

ShutdownES[]/

[]/^PressureSensor.GetCurrentPressureValue

[CurrentPressureVal

>8000]/CCFail[]/

CCOK[]/

SetCurrentPressureVal(CurrentPressureVal)

[]/

...

...

[]/^_SYSTEMCLASS_

.ready(Initialization)

Requirement 1 (2)Requirement 1 (2)

ShutdownES[]/

Visualization of analysis resultsOverview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

45



Detector-Corrector Pattern:• General Claim:

– If there is a violation, activate indicator.

[](“Violation” -> <> “Indicator activated”)• Instantiated Claim:

– If the watchdog detects a violation, then the driver display should be activated

[]((PressureDetector.Violation == 1) -> <> (DriverDisplay.DriverDisplayValue == 1))

• Analysis Results:– A violation was detected by the model checker

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

46


Requirement 2 (2)Requirement 2 (2)Subsequent Analysis:1. Detector-Corrector Pattern:

[] (PressureDetector.Violation == 1 -><> send(LocalFaultHandler.ReportLocalFault(200)))

…2. FaultHandler Pattern:

[](send(GlobalFaultHandler.ReportGlobalFault(200)) -> <> (send(UserInterface.

ActivateWarningLevel(1)))

3. User Interface Pattern: [](send(UserInterface. ActivateWarningLevel(1)) -> <> (DriverDisplay. DriverDisplayValue == 1))

Claim 3 uncovered the reason for the violation.

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

47



PressureDetector:

ComputingComponent: FaultHandler: PressureSensor:

()

UserInterface: DriverDisplay:

()

()

()

()

()

()

()SetWDPressureValue(11,000)

StoreError(200)

ActivateWarningLevel(1)

SetDriverDisplayValue(0)

ShutdownES()

GetPressureValue()

CCOK

GetPressureOperationState()

MINERVA generated sequence diagram of the violation.

Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

48



Idle

[WarningLevel=1]/^DriverDisplay.SetDriverDis

playValue(0)

CheckActivateWarningLevel(WarningLevel)[]/

[WarningLevel=1]/^DriverDisplay.SetDriverDisplayValue(1)

Transition Trace:

1. Object “UserInterface” transitions from state “Initial" to state “Idle" on event “modelstart”

2. Object “UserInterface” transitions from state “Idle” to state “Check” on event “ActivateWarningLevel (WarningLevel)”

3. Object “UserInterface” transitions from state “Check” to state “Idle” on condition “WarningLevel=1”

[] / ^_SYSTEMCLASS_.ready

Visualization of analysis resultsOverview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Description

Requirement 1

Requirement 2

Req. Patterns

49


OutlineOutline

Introduction

UML Formalization


Conclusions

Future Work


Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

50


ConclusionsConclusions

• Requirements patterns: – Give guidance for developing 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

Overview:

Introduction

Background

Process

Conclusions

Future Work

51


OutlineOutline

Introduction

UML Formalization


Conclusions

Future Work


Overview:

Introduction

UML Formalization

Process

Conclusions

Future Work

Req. Patterns

52


Future WorkFuture Work

• Current and future work:– Extend our tools and patterns to support discrete timing

aspects [ASE-04]– Real-time specification patterns [RT-patterns04]– Extend our pattern repository to address security

[RHAS03]– Examine how to abstract model specifications

• Other projects:– RAPIDware (ONR adaptive middleware project)– Safeness and Correctness of adaptations– Feature Interactions– Use AOP to weave adaptability– Code generation for adaptations.

Overview:

Introduction

Background

Process

Conclusions

Future Work

53


AcknowledgementsAcknowledgements

• 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 Force’s Rome Laboratories

• Eaton Corporation, Siemens Corporate Research, a Motorola doctoral fellowship, and in cooperation with Siemens Automotive and Detroit Diesel Corporation

Overview:

Introduction

Background

Process

Conclusions

Future Work

54


ReferencesReferences[Gebhard]

[Broy]

[Glinz]

[Dwyer]

[Gamma]

Bernd Geghard, Martin Rappl, Requirements Management for Automotive Systems Development. SAE World Congress, 2000

Manfred Broy, Requirements Engineering for Embedded Systems. Workshop on Formal Design of Safety Critical Embedded Systems, 1997

Martin Glinz, Problems and Deficiencies of UML as a Requirements Specification Language. Proceedings of the Tenth International Workshop on Software Specification and Design, San Diego, 11-22, 2000

M. B. Dwyer, G. S. Avrunin, J. C. Corbett, Patterns in Property Specifications for Finite-State Verification. UM-CS-1998-035, 1998

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Abstraction and Reuse of Object-Oriented Design. Lecture Notes in Computer Science, vol. 707, p. 406 – 431, 1993

55


Relevant PublicationsRelevant Publications

[TSE95][TSE95]

[IWSSD-10]

[DSN00]

[IJSEKE00]

[ICSE01]

[RE01][RE01]

`À Formal Semantics of Object Models'' R.H. Bourdeau and B. Cheng, IEEE Trans. on Software Engineering, Vol. 21, No. 10, pp. 799--821, October 1995.“Object-Oriented Modeling and Automated Analysis of a Telemedicine Application,” L Campbell and B. Cheng, IEEE International Workshop on Software Specification and Design, November 2000. “Enabling Automated Analysis through the Formalization of Object-Oriented Modeling Diagrams,” L. Campbell, B. Cheng, and E. Wang, IEEE Dependable Systems and Networks, June 2000. “Formalizing the Functional Model within Object-oriented Design,” E. Wang and B. Cheng, International Journal on Software Engineering and Knowledge Engineering, Vol 10, No. 1, February 2000.

“A General Framework for Formalizing UML with Formal Language,”. William E. McUmber, Betty H.C. Cheng, Proceedings of IEEE International Conference on Software Engineering, Toronto, 2001

“Integrating Informal and Formal Approaches to Requirements Modeling and Analysis,” L. Campbell and B. Cheng, IEEE Requirements Engineering, Poster Workshop, August 2001.

56



“Adding Formal Specifications to Requirements Patterns,” Betty H.C. Cheng, Laura A. Campbell, and Sascha Konrad, International Workshop on Requirements for High Assurance Systems, Essen, September 2002

“Requirements Patterns for Embedded Systems,” Sascha Konrad and Betty H.C. Cheng, Proc. Of IEEE 10th International Requirements Engineering Conference, Essen, September 2002

`Àutomatically detecting and visualizing errors in UML diagrams,‘‘ Laura A. Campbell, Betty H. C. Cheng, William E. McUmber, and R. E. K. Stirewalt, Requirements Engineering Journal, 7(4):264-287, 2002.

“Formalizing and Integrating the Dynamic Model for Object-Oriented Modeling,” B. Cheng and E. Wang, IEEE Transactions on Software Engineering, Vol 28, No. 8, August, 2002.

“A Requirements Pattern-Driven Approach to Specify Systems and Check Properties” S. Konrad, L. Campbell, B. Cheng, M. Deng, SPIN 2003, May 2003. (Co-located with ICSE03.)

“Using Security Patterns to Model and Analyze Security Properties,” S. Konrad, B. Cheng, L. Campbell, R. Wassermann, IEEE Workshop on Requirements for High Assurance Systems, September 2002. (Co-located with RE02.)

[RHAS02]

[RE02]

[REJ02]

[TSE02][TSE02]

[SPIN03][SPIN03]

[RHAS03][RHAS03]

57



`Àutomated Analysis of Timing Information in UML Diagrams,'' Sascha Konrad, Laura Campbell, and Betty H.C. Cheng), Proc. of IEEE International Conference on Automated Software Engineering (to appear), September 2004, Linz Austria.

``Retrieval-By-Construction: A Traceability Technique to Support Verification and Validation of UML Formalizations,'' M. Deng, R.E.K. Stirewalt, and B. Cheng submitted to International Journal on Software Engineering and Knowledge Engineering, Special issue on Traceability, June 2004.

`Òbject Analysis Patterns for Embedded Systems,'' S. Konrad, L. Campbell, and B. Cheng, revision under review for IEEE Transactions on Software Engineering, August 2004.

[ASE04]

[Trace]

[Patterns]

58


Questions/DiscussionQuestions/DiscussionOverview:

Introduction

Background

Process

Conclusions

Future Work

S oftware E ngineering & N etwork S ystems Lab A Requirements Pattern-Driven Approach to Modeling and Analyzing Embedded Systems Betty H.C. Cheng Software.

Documents

distributed systems

interactive systems

systems modes of operation

software developmentfocus

peer systems philip

embedded system development

chengsoftware engineering

embedded systemsbetty