1. 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. 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.

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

3. S oftware E ngineering & N etwork S ystems Lab 3 MSU SENS Laboratory The Software Engineering and Network Systems Laboratory supports research in: – software engineering – distributed computing – network protocols and real-time systems – fault tolerance and security – formal methods, code generation – compilation/analysis of concurrent systems Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners

4. S oftware E ngineering & N etwork S ystems Lab SENS 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

5. 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. Formalization Techniques and Patterns 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 oftware E ngineering & N etwork S ystems Lab 6Outline Introduction UML Formalization Modeling and Analysis Process Conclusions Future Work Requirements Patterns Overview: Introduction UML Formalization Process Conclusions Future Work Req. Patterns

7. S oftware E ngineering & N etwork S ystems Lab 7Introduction 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 oftware E ngineering & N etwork S ystems Lab 8 Problem 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 oftware E ngineering & N etwork S ystems Lab 9 General 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 oftware E ngineering & N etwork S ystems Lab 10Outline Introduction UML Formalization Modeling and Analysis Process Conclusions Future Work Requirements Patterns Overview: Introduction UML Formalization Process Conclusions Future Work Req. Patterns

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

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

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

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

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

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

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

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

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

23. S oftware E ngineering & N etwork S ystems Lab 23Patterns 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 oftware E ngineering & N etwork S ystems Lab 24 A pattern has 4 essential elements: Pattern name Problem Solution Consequences NAME PROBLEM SOLUTION CONSE-QUENCES Pattern Essentials Overview: Introduction UML Formalization Process Conclusions Future Work Req. Patterns

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

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

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

29. S oftware E ngineering & N etwork S ystems Lab 29 Patterns Overview Overview: Introduction UML Formalization Process Conclusions Future Work Req. Patterns

30. S oftware E ngineering & N etwork S ystems Lab 30 Actuator-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

31. Actuator-Sensor Pattern: Structure PassiveSensor ComputingComponent Actuator ActiveSensor PassiveBooleanSensor PassiveIntegerSensor PassiveRealSensor PassiveComplexSensor

32. Actuator-Sensor Pattern: Behavior (sequence diagram) FaultHandler Temperature Sensor Computing Component Radiator Valve Sensor Input Device Temperature Sensor ActuatorOutput Device Temperature Sensor

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

34. S oftware E ngineering & N etwork S ystems Lab 34 Actuator-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 oftware E ngineering & N etwork S ystems Lab 35Outline Introduction UML Formalization Modeling and Analysis Process Conclusions Future Work Requirements Patterns Overview: Introduction UML Formalization Process Conclusions Future Work Req. Patterns

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

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

38. S oftware E ngineering & N etwork S ystems Lab 38 Modeling 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 oftware E ngineering & N etwork S ystems Lab 39 Analysis-Enabled Diesel Filter System Pressure Detector: UserInterface: 1 Current Mirror1: Pressure Sensor: controls Environment: _SYSTEM CLASS_: Fault Handler: Current Mirror2: EngineControl Unit: Heater Regulator1: Heater Regulator2: Driver Display: monitors controls affects controls reports 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 reads 11 Computing Component: Overview: Introduction UML Formalization Process Conclusions Future Work Description Requirement 1 Requirement 2 Req. Patterns

40. S oftware E ngineering & N etwork S ystems Lab 40 Environmental Parameters 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 oftware E ngineering & N etwork S ystems Lab 41 Environmental Parameters 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 oftware E ngineering & N etwork S ystems Lab 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 1 Overview: Introduction UML Formalization Process Conclusions Future Work Description Requirement 1 Requirement 2 Req. Patterns

43. S oftware E ngineering & N etwork S ystems Lab 43 Diesel Filter System Overview: Introduction UML Formalization Process Conclusions Future Work Description Requirement 1 Requirement 2 Req. Patterns

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

45. S oftware E ngineering & N etwork S ystems Lab 45 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 oftware E ngineering & N etwork S ystems Lab 46 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 oftware E ngineering & N etwork S ystems Lab 47 Requirement 2 (3) Pressure Detector: 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 oftware E ngineering & N etwork S ystems Lab 48 Requirement 2 (4) Idle [WarningLevel=1]/ ^DriverDisplay.SetDriverDis playValue(0) Check ActivateWarningLevel (WarningLevel)[]/ [WarningLevel=1]/ ^DriverDisplay.SetDriverDisplayValue(1) Transition Trace: 1. 1.Object “UserInterface” transitions from state “Initial" to state “Idle" on event “modelstart” 2. 2.Object “UserInterface” transitions from state “Idle” to state “Check” on event “ActivateWarningLevel (WarningLevel)” 3. 3.Object “UserInterface” transitions from state “Check” to state “Idle” on condition “WarningLevel=1” [] / ^_SYSTEMCLASS_.ready Visualization of analysis results Overview: Introduction UML Formalization Process Conclusions Future Work Description Requirement 1 Requirement 2 Req. Patterns

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

50. S oftware E ngineering & N etwork S ystems Lab 50Conclusions 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 oftware E ngineering & N etwork S ystems Lab 51Outline Introduction UML Formalization Modeling and Analysis Process Conclusions Future Work Requirements Patterns Overview: Introduction UML Formalization Process Conclusions Future Work Req. Patterns

52. S oftware E ngineering & N etwork S ystems Lab 52 Future 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 oftware E ngineering & N etwork S ystems Lab 53Acknowledgements 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 oftware E ngineering & N etwork S ystems Lab 54References [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 oftware E ngineering & N etwork S ystems Lab 55 Relevant Publications [TSE95] [IWSSD-10] [DSN00] [IJSEKE00] [ICSE01][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 oftware E ngineering & N etwork S ystems Lab 56 Relevant 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 10 th 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][SPIN03][RHAS03]

57. S oftware E ngineering & N etwork S ystems Lab 57 Relevant 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 oftware E ngineering & N etwork S ystems Lab 58Questions/Discussion Overview: Introduction Background Process Conclusions Future Work