S oftware E ngineering N etwork S

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 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. N 00014 -01 -1 -0744, and DARPA grant No. F 30602 -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.

Software Engineering and Network Systems Laboratory S oftware E ngineering & N etwork S ystems Lab Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners

SENS Personnel S oftware E ngineering & N etwork S ystems Lab • Betty H. C. Cheng: software engineering, patterns, OO, formal methods, embedded systems. • Laura K. Dillon: specification and validation of concurrent systems • Sandeep Kulkarni: fault tolerance in distributed systems • Philip Mc. Kinley: distributed computing, networking, OS, adaptive middleware • Jonathan Shapiro: Network protocols, security, peer-to-peer systems • Kurt Stirewalt: interactive systems, program reasoning, SE. • Approximately 30 grad research assistants • Occasional visiting scholars and postdocs

Bridge the Gap Between Informal and Formal Methods Informal specifications, • graphical models, • easy for humans to formulate, • may be inconsistent and incomplete. Formalization Techniques and Patterns Object-Oriented “Blueprints” 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 5

Outline Overview: Introduction UML Formalization Introduction Req. Patterns Process Conclusions UML Formalization Future Work Requirements Patterns Modeling and Analysis Process Conclusions S oftware E ngineering & N etwork S ystems Lab Future Work 6

Introduction Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work • 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 S oftware E ngineering & N etwork S ystems Lab 7

Problem Statement Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab • 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 8

General Approach Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work • 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: S oftware E ngineering & N etwork S ystems Lab – Dr. Kurt Stirewalt – Dr. L. Campbell, Dr. W. Mc. Umber, Dr. E. Wang – R. Bourdeau, G. Coombs, M. Deng, H. Goldsby, S. Konrad 9

Outline Overview: Introduction UML Formalization Introduction Req. Patterns Process Conclusions UML Formalization Future Work Requirements Patterns Modeling and Analysis Process Conclusions S oftware E ngineering & N etwork S ystems Lab Future Work 10

UML Formalization Overview: Introduction UML Formalization Req. Patterns Process Conclusions • Automate translation of diagrams into a formal language – OMT Formalization • [TSE 95, ICSE 97, J. SEKE 00, TSE 02, IWSSD 00, DSN 00] Future Work – UML Formalization [HASE 99, ICSE 01] • General framework for mapping diagrams to multiple formal languages • Embedded systems domain • Currently targets Promela – Hydra S oftware E ngineering & N etwork S ystems Lab • Mapping from UML to the target language (such as Promela, VHDL) • Enables execution through simulation and analysis through model checking 11

UML Metamodel Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work • 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 0. . * S oftware E ngineering & N etwork S ystems Lab Compound Statement Block Simple Statement 12

Unified Class/Dynamic Metamodel Overview: Introduction UML Formalization Req. Patterns Model Class related Dynamic related Process Conclusions Behavior Class Relationships Future Work State Vertex Instance Variables Aggregation Generalization Transition Association Rest of dynamic model S oftware E ngineering & N etwork S ystems Lab 13

Example Metamodel Mapping Overview: Introduction UML Formalization Target Source h: Req. Patterns Process h: Conclusions Future Work A R B h: B’ has. Comp(A, C) R’ A’ D’ h: C has. Part(A’, C’) h: C’ S oftware E ngineering & N etwork S ystems Lab 14

Metamodel mapping Overview: Introduction UML Formalization Req. Patterns Process Conclusions UML metamodel Homomorphism Formal language metamodel Future Work Describes instance UML diagram S oftware E ngineering & N etwork S ystems Lab Produces mapping Mapping Rules Describes instance Formal description of system 15

Introduction to Mapping Rules Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work • 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 S oftware E ngineering & N etwork S ystems Lab 16

Summary of Mappings Overview: Introduction UML Formalization Req. Patterns VHDL Structure Promela Process Conclusions Ent/Arch Future Work Port signature procedure Ent/Arch Write to signal S oftware E ngineering & N etwork S ystems Lab Class Relationship State Composite State Event proctype channels Labeled block of statements proctype Channel assignment 17

Tool Support Overview: Introduction UML Formalization Req. Patterns Analysis results Process Conclusions Future Work UML MINERVA Diagram reports S oftware E ngineering & N etwork S ystems Lab HIL Hydra Spec* Analysis Tool* Analysis reports 18

Architecture of Minerva Overview: Introduction Diagram reports UML Formalization Req. Patterns Diagram in Do. ME format Process Conclusions Future Work UML diagram editors Plug-ins Visualization commands Analysis results (processed) Text processing scripts S oftware E ngineering & N etwork S ystems Lab HIL Analysis reports Analysis results (raw) 19

MINERVA Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work – MINERVA • Based on Honeywell’s Do. ME (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 S oftware E ngineering & N etwork S ystems Lab – [REJ-02, RHAS-02, Spin-03] 20

Hydra Translation Tool Overview: Introduction UML Formalization Uses library and parser to implement rules Req. Patterns Process Modular per formal language Conclusions HIL Future Work Minerva Hydra parser Language Specific Class Library Formal Specifications S oftware E ngineering & N etwork S ystems Lab Implements mapping rules for specific language 21

Outline Overview: Introduction UML Formalization Introduction Req. Patterns Process Conclusions UML Formalization Future Work Requirements Patterns Modeling and Analysis Process Conclusions S oftware E ngineering & N etwork S ystems Lab Future Work 22

Patterns Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab • 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, RHAS 03] – Requirements Patterns: conceptual model, system constraints [RE 02, RHAS 02, SPIN 03] 23

Pattern Essentials Overview: Introduction UML Formalization A pattern has 4 essential elements: Req. Patterns Process Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab • • Pattern name Problem Solution Consequences PROBLEM NAME SOLUTION CONSEQUENCES 24

Logical Architecture of Embedded Systems [Broy] Overview: Introduction UML Formalization Req. Patterns Process • Modeled as part of the requirements engineering process • An embedded system typically consists of: Conclusions Future Work User UI CD A S PD Environment • Capture behavior of components and their interaction S oftware E ngineering & N etwork S ystems Lab – Collectively they provide requirements of system 25

Requirements Patterns Template Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab Design Pattern Template • Pattern Name and Classification • Intent • Also Known As • Motivation • Applicability • Structure • Participants • Collaborations • Consequences • Implementation • Sample Code • Known Uses • Related Patterns Requirements Pattern 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 26

Behavioral Patterns Overview: UML Formalization 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: Introduction • 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 Req. Patterns Process Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab 27

Structural Patterns Overview: Introduction UML Formalization Req. Patterns • 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: Process Actuator. Sensor: • describes how to specify an object model for a user interface that is extensible and reusable. Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab 28

Actuator-Sensor Pattern Overview: Introduction UML Formalization Req. Patterns Process Conclusions Future Work • Motivation: – ES have various kinds of sensors/actuators – Can distinguish two main categories of sensors: • Passive. Sensors (pull: controller requests information) • Active. Sensors (push: sends information to controller) S oftware E ngineering & N etwork S ystems Lab 30

Actuator-Sensor Pattern: Structure Passive. Sensor Computing. Component Actuator Passive. Integer. Sensor Passive. Real. Sensor Passive. Boolean. Sensor Passive. Complex. Sensor Active. Sensor 31

Actuator-Sensor Pattern: Behavior (sequence diagram) Fault. Handler Temperature Sensor Computing Component Radiator Valve Sensor Input Device Temperature Sensor Actuator. Output Device Temperature Sensor 32

Actuator-Sensor Pattern • Consequences: – Common Interface – Class attributes are accessed through messages – Pattern describes when to use active and passive sensors S oftware E ngineering & N etwork S ystems Lab 33

Actuator-Sensor Pattern • Constraints: – Specification patterns [Dwyer 98] for properties of interest. Response pattern: – When the value of an active sensor changes, the computing component should receive the updated value. – [](Active. Sensor. ``Value change’’ -> <>(``Send updated value to Computing Component’’)) S oftware E ngineering & N etwork S ystems Lab Response pattern: – When an active sensor times out, a fault message should be sent to the fault handler. – [](Active. Sensor. ``Timeout’’-> <>(``Report timeout to fault handler’’)) 34

Outline Overview: Introduction UML Formalization Introduction Req. Patterns Process Conclusions UML Formalization Future Work Requirements Patterns Modeling and Analysis Process Conclusions S oftware E ngineering & N etwork S ystems Lab Future Work 35

Modeling and Analysis Approach Overview: Introduction 2 UML Formalization Req. Patterns Process Description 1 Requirement 1 3 1 Requirement 2 Conclusions Future Work 4 6 7 5 6 7 7 S oftware E ngineering & N etwork S ystems Lab 36

Diesel Filter System Overview: Introduction UML Formalization Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab • 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 filter exhaust pipe exhaust - soot 37

Modeling Approach Overview: Introduction UML Formalization Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work • 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 S oftware E ngineering & N etwork S ystems Lab • Contain the components of the system 38

Analysis-Enabled Diesel Filter System Overview: Introduction UML Formalization Environment: Req. Patterns controls 1 Process 1 reports Description Requirement 1 Requirement 2 Conclusions Future Work controls Pressure Detector: 1 1 monitors 1 Pressure Sensor: 1 controls Computing Component: controls 1 1 1 Heater Regulator 1: 1 reads S oftware E ngineering & N etwork S ystems Lab 1 Current Mirror 1: 1 controls 1 User. Interface: 1 Heater Regulator 2: affects 1 Driver Display: 1 Engine. Control Unit: 1 affects 1 1 Fault Handler: 1 1 _SYSTEM CLASS_: 1 Current Mirror 2: 39

Environmental Parameters Overview: Introduction UML Formalization Equivalence classes derived from the requirements determine the modes in which the system operates: Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab 40

Environmental Parameters Overview: Introduction UML Formalization Additional equivalent classes are needed to model different interactions with the physical environment Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab 41

Requirement 1 Overview: Introduction UML Formalization Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work 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 []((Pressure. Detector. Violation == 1) -> <> (Computing. Component. Power. Status == 0)) • Analysis Results: S oftware E ngineering & N etwork S ystems Lab – A violation was detected using model checking – State diagram animation revealed a missing transition as the cause 42

Requirement 1 (2) Overview: Visualization of analysis results Introduction UML Formalization Shutdown. ES[]/ Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab 44

Requirement 2 (1) Overview: Introduction UML Formalization Req. Patterns Process Detector-Corrector Pattern: • General Claim: – If there is a violation, activate indicator. Description Requirement 1 Requirement 2 Conclusions Future Work [](“Violation” -> <> “Indicator activated”) • Instantiated Claim: – If the watchdog detects a violation, then the driver display should be activated []((Pressure. Detector. Violation == 1) -> <> (Driver. Display. Value == 1)) • Analysis Results: S oftware E ngineering & N etwork S ystems Lab – A violation was detected by the model checker 45

Requirement 2 (2) Overview: Introduction UML Formalization Req. Patterns Process Description Requirement 1 Requirement 2 Conclusions Future Work Subsequent Analysis: 1. Detector-Corrector Pattern: [] (Pressure. Detector. Violation == 1 -> <> send(Local. Fault. Handler. Report. Local. Fault(200))) … 2. Fault. Handler Pattern: [](send(Global. Fault. Handler. Report. Global. Fault(200) ) -> <> (send(User. Interface. Activate. Warning. Level(1))) 3. User Interface Pattern: [](send(User. Interface. Activate. Warning. Level(1)) -> <> (Driver. Display. Value == 1)) S oftware E ngineering & N etwork S ystems Lab Claim 3 uncovered the reason for the violation. 46

Requirement 2 (3) Overview: Introduction MINERVA generated sequence diagram of the violation. UML Formalization Req. Patterns Process Pressure Detector: Computing. Component: Description () CCOK () Get. Pressure. Value() Requirement 2 Future Work User. Interface: Pressure. Sensor: Driver. Display: () Get. Pressure. Operation. State() Requirement 1 Conclusions Fault. Handler: () Set. WDPressure. Value(11, 000) () Shutdown. ES() () Store. Error(200) () Activate. Warning. Level(1) () Set. Driver. Display. Value(0) S oftware E ngineering & N etwork S ystems Lab 47

Requirement 2 (4) Overview: Visualization of analysis results Introduction UML Formalization Transition Trace: Req. Patterns Process Description 1. [] / ^_SYSTEMCLASS_. ready Object “User. Interface” transitions from state “Initial" to state “Idle" on event “modelstart” 2. Object “User. Interface” transitions from state “Idle” to state “Check” on event “Activate. Warning. Level (Warning. Level)” 3. Object “User. Interface” transitions from state “Check” to state “Idle” on condition “Warning. Level=1” Requirement 1 Requirement 2 Idle Activate. Warning. Level (Warning. Level)[]/ Check Conclusions Future Work [Warning. Level=1] / ^Driver. Display. Set. Driver. Dis play. Value(0) [Warning. Level=1]/ ^Driver. Display. Set. Driver. Display. Value(1) S oftware E ngineering & N etwork S ystems Lab 48

Outline Overview: Introduction UML Formalization Introduction Req. Patterns Process Conclusions UML Formalization Future Work Requirements Patterns Modeling and Analysis Process Conclusions S oftware E ngineering & N etwork S ystems Lab Future Work 49

Conclusions Overview: Introduction Background Process Conclusions Future Work • 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 S oftware E ngineering & N etwork S ystems Lab 50

Outline Overview: Introduction UML Formalization Introduction Req. Patterns Process Conclusions UML Formalization Future Work Requirements Patterns Modeling and Analysis Process Conclusions S oftware E ngineering & N etwork S ystems Lab Future Work 51

Future Work Overview: Introduction Background Process Conclusions Future Work • Current and future work: – Extend our tools and patterns to support discrete timing aspects [ASE-04] – Real-time specification patterns [RT-patterns 04] – Extend our pattern repository to address security [RHAS 03] – Examine how to abstract model specifications • Other projects: S oftware E ngineering & N etwork S ystems Lab – – – RAPIDware (ONR adaptive middleware project) Safeness and Correctness of adaptations Feature Interactions Use AOP to weave adaptability Code generation for adaptations. 52

Acknowledgements Overview: • Software Engineering and Networking Systems Faculty/Students • Introduction This work has been supported in part by Background Process Conclusions Future Work • • S oftware E ngineering & N etwork S ystems Lab NSF grants EIA-0000433, EIA-0130724, CDA 9700732, CCR-9901017, Department of the Navy, Office of Naval Research under Grant No. N 00014 -011 -0744, and DARPA grant No. F 30602 -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 53

References [Gebhard] Bernd Geghard, Martin Rappl, Requirements Management for Automotive Systems Development. SAE World Congress, 2000 [Broy] Manfred Broy, Requirements Engineering for Embedded Systems. Workshop on Formal Design of Safety Critical Embedded Systems, 1997 [Glinz] 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 [Dwyer] [Gamma] S oftware E ngineering & N etwork S ystems Lab 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 54

Relevant Publications [TSE 95] [IWSSD-10] [DSN 00] [IJSEKE 00] [ICSE 01] [RE 01] S oftware E ngineering & N etwork S ystems Lab ``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. Mc. Umber, 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. 55

Relevant Publications [RHAS 02] “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 [RE 02] “Requirements Patterns for Embedded Systems, ” Sascha Konrad and Betty H. C. Cheng, Proc. Of IEEE 10 th International Requirements Engineering Conference Essen, September 2002 [REJ 02] ``Automatically detecting and visualizing errors in UML diagrams, ‘‘ Laura A. Campbell, Betty H. C. Cheng, William E. Mc. Umber, and R. E. K. Stirewalt, Requirements Engineering Journal, 7(4): 264 -287, 2002. [TSE 02] “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. [SPIN 03] “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 ICSE 03. ) [RHAS 03] “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 RE 02. ) S oftware E ngineering & N etwork S ystems Lab 56

Relevant Publications [ASE 04] [Trace] [Patterns] S oftware E ngineering & N etwork S ystems Lab ``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. 57

Questions/Discussion Overview: Introduction Background Process Conclusions Future Work S oftware E ngineering & N etwork S ystems Lab 58