s oftware e ngineering & n etwork s ystems lab a requirements pattern-driven approach to...
TRANSCRIPT
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
OutlineOutline
Introduction
UML Formalization
Modeling and Analysis Process
Conclusions
Future Work
Requirements Patterns
Overview:
Introduction
UML Formalization
Process
Conclusions
Future Work
Req. Patterns
7
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
OutlineOutline
Introduction
UML Formalization
Modeling and Analysis Process
Conclusions
Future Work
Requirements Patterns
Overview:
Introduction
UML Formalization
Process
Conclusions
Future Work
Req. Patterns
11
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
OutlineOutline
Introduction
UML Formalization
Modeling and Analysis Process
Conclusions
Future Work
Requirements Patterns
Overview:
Introduction
UML Formalization
Process
Conclusions
Future Work
Req. Patterns
23
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
Actuator-Sensor PatternActuator-Sensor Pattern
• Consequences:– Common Interface– Class attributes are accessed
through messages– Pattern describes when to use active
and passive sensors
34
S oftwareE ngineering &N etworkS ystems Lab
Actuator-Sensor PatternActuator-Sensor Pattern
• 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
S oftwareE ngineering &N etworkS ystems Lab
OutlineOutline
Introduction
UML Formalization
Modeling and Analysis Process
Conclusions
Future Work
Requirements Patterns
Overview:
Introduction
UML Formalization
Process
Conclusions
Future Work
Req. Patterns
36
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
[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
S oftwareE ngineering &N etworkS ystems Lab
Requirement 2 (1)Requirement 2 (1)
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
Requirement 2 (3)Requirement 2 (3)
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
S oftwareE ngineering &N etworkS ystems Lab
Requirement 2 (4)Requirement 2 (4)
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
S oftwareE ngineering &N etworkS ystems Lab
OutlineOutline
Introduction
UML Formalization
Modeling and Analysis Process
Conclusions
Future Work
Requirements Patterns
Overview:
Introduction
UML Formalization
Process
Conclusions
Future Work
Req. Patterns
50
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
OutlineOutline
Introduction
UML Formalization
Modeling and Analysis Process
Conclusions
Future Work
Requirements Patterns
Overview:
Introduction
UML Formalization
Process
Conclusions
Future Work
Req. Patterns
52
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
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
S oftwareE ngineering &N etworkS ystems Lab
Relevant PublicationsRelevant Publications
[TSE95][TSE95]
[IWSSD-10]
[DSN00]
[IJSEKE00]
[ICSE01]
[RE01][RE01]
``A 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
S oftwareE ngineering &N etworkS ystems Lab
Relevant PublicationsRelevant Publications
“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
``Automatically 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
S oftwareE ngineering &N etworkS ystems Lab
Relevant PublicationsRelevant Publications
``Automated 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.
``Object 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
S oftwareE ngineering &N etworkS ystems Lab
Questions/DiscussionQuestions/DiscussionOverview:
Introduction
Background
Process
Conclusions
Future Work