Applying Use Cases for the Requirements Validation of Component-Based Real-Time Software

Transcription

1 In Proceedings of 2 nd IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 99), 2-5 May 1999, Saint-Malo, France Applying Use Cases for the Requirements Validation of Component-Based Real-Time Software Wolfgang Fleisch Institute for Industrial Automation and Software Engineering University of Stuttgart fleisch@ias.uni-stuttgart.de Abstract Component-based software development is a promising way to improve quality, time to market and handle the increasing complexity of software for real-time systems. In this paper the basic properties of an event-triggered component model for real-time software are introduced. For the early exposure of design errors a process for the simulation based validation of component-based software applying use cases is presented. A template for structuring use cases helps gathering the course-oriented requirements which describe the required behaviour of the composed software. Requirements sequence diagrams are extracted from the use cases and compared with the simulated behaviour of the component-based software. A case study of a power window control from the automotive body electronics domain demonstrates practical experience with applying use cases for the requirements validation. 1. Introduction In the IAS (Institute for Industrial Automation and Software Engineering) research project Component-Based Software Development and Evaluation concepts, techniques and tools are developed to manage the increasing software complexity of distributed real-time systems, to improve software quality and to reduce time to market. In our point of view component-based software development means that new application software will be composed from a set of predefined, scalable and configurable software components, which have been explicitly developed for multiple usage. In the following, the word component always denotes a software component. The components have to meet the special requirements of embedded target processors, for example runtime efficiency and minimum demands for memory. In addition, the requirements for local and distributed communication between software components have to be met. The idea of applying a component model and a component-based software architecture promises many advantages as for example easier and faster construction, adaptation, modification and distribution of software applications for complex real-time systems. Assumed that we are using a component-based system architecture, the following aspects should be remarked: the software components which have been explicitly developed for multiple usage are supposed to have a validated or even a verified behaviour at their interfaces, which gives them a better quality. But when composing a new application software with such components it can not be concluded for the composed system that it has the same level of correctness compared to the single components. For that reason, especially the interactions between the software components have to be reviewed for the validation of the system behaviour. 2. Component-Based Software Development 2.1 Component Properties A software component (Figure 1) shows black-box behaviour at its interface. The internal state and the attributes of the component are strongly encapsulated. The encapsulated internal part of a component is exclusively communicating with its interface. The interface of a component provides inputs and outputs which can be connected with other components. Comp. Interface Component Body Input (0-n) Output (0-n) Figure 1: Component properties

2 2.2 Modelling Component-Based Application Software The modelling of a component-based real-time software application works fundamentally in two steps. In a first step, a planned application is refined hierarchically top down with architecture components (Figure 2). At the beginning, the architecture components are empty components and just outline the structure of an application to be designed. In the second step the developer fills up the empty architecture components with components from a component library to define the individual behaviour of an application. This means that the developer works of prime importance on the architecture level instead of coding on low level the complete software line by line. Considering the efficiency requirements of embedded real-time systems the component-based model structure is intended as a high level description for code generation and validation activities. Architecture Component X (System) Component 4 description as well as the component behaviour and interface description. Further information about current architecture description languages can be found in Bass et. al. [5]. 2.3 Component-Based Software versus Object- Oriented Software The reasons for applying a component model for real-time software are the advantages of the underlying interface connection architecture. In an object-oriented software architecture the connections (message sending commands) are buried in the objects as illustrated in (Figure 3). This has a number of disadvantages. For example that the encapsulated objects and the architecture are not clearly separate entities. Although the interface methods of objects can be defined before the implementation, the connections are only defined when the objects are built. So, the architecture has likely evolved as the system was built and was not predefined as a plan or outline of the system. Simple changes by replacing only one object for example may cause changes of the architecture. Supposed object 2 shall be exchanged, all method calls from other objects to the provided methods of object 2 have to be changed inside the encapsulated code of these objects. This is not a sufficient support for comfortable changes or extensions. Methods Architecture Component Y Interface 1 Object 1 Interface 2 Object 2 Component 1 Component 2 Component 3 Figure 2: Hierarchical component-based application structure For modelling component-based applications and library components, Architecture Description Languages (ADL) offer some essential properties for composition and configuration of component-based software although they have originally not been developed for. The ADL-based tools RAPIDE [1], [2] from Stanford University and ObjecTime Developer/ROOM [3], [4] from ObjecTime are currently used at the IAS for modelling and simulation. A textual or graphical ADLcovers the structure model Figure 3: Example for an object-oriented architecture In a component-based interface connection architecture the software structure is independent from the encapsulated internal behaviour of the components (Figure 4). The decoupling of the encapsulated internal component body from the architecture is achieved using an interface similar to hardware circuits with a defined set of inputs and outputs. The encapsulated component body is exclusively communicating with its interface. This strict separation of architecture and components enables flexible usage of standard components ( components off the shelf ) [5] plugged together via their interfaces. It supports easy modification and adaptation of the component-based software. Another advantage of an interface connection architecture is that when applying validated components, current validation activities only have to concentrate on analysing the architecture description.

3 Interface 1 Component 1 Connections Interface 2 Component 2 Figure 4: Example for a component-based interface connection architecture Component-based software is a specialisation of objectoriented software. The component model which is currently developed at the IAS is based on object-oriented basic concepts like hierarchy, encapsulation and composition. The inner part of the components may even be modelled object-oriented as long as they show the required black-box behaviour at their interfaces. 2.4 Component Model for Real-Time Software Overview An event-triggered component model for distributed realtime software is currently specified at the IAS. Beside of that a time-triggered component model for distributed realtime software is under construction [6]. In the following, a brief overview about the basic properties of the eventtriggered component model is given. The component model defines the following different sub-models: structure model communication model execution model Structure Model The structure model of a component-based application software consists of architecture components and components as presented in Figure 2. Architecture components and components are wired with connections. The elements of the structure model can be described by using an architecture description language. To support hierarchy, a set of connected components can be compound to an architecture component, which behaves the same at its interface as a basic component does Communication Model Communication between components is intended to be asynchronous and message based. Depending on the content of messages, either event messages or state messages are used. When using event-messages, queues are necessary for all inputs. Messages do not contain information about their sender and receiver. This information is included in the connections of the structure model Execution Model The activation of components at run-time is eventtriggered and can be defined nearly independent from the structure of an application. A Component is activated by receiving an input message at its interface. The runtime execution can be managed in different ways like 1. task or thread management of a real-time operating system 2. simple control loop activating the components in a predefined order (for example FIFO event queue) 3. activation by connected timer components. 3. Requirements Engineering 3.1 Motivation Distributed real-time systems are usually concurrent, have to be reliable and have to meet timing constraints. A strongly increasing application area for real-time systems are embedded systems, which received their name because they are embedded in a technical process. The application example of an automotive power window control presented in chapter 5 also belongs to the domain of embedded systems. A measure for the current complexity of automotive control systems is that in a today s car there are working up to 75 microcontrollers, interconnected via communication busses as for example CAN (Controller Area Network) [7]. The number of control units has strongly increased over the last years and it is expected that especially software will have an enormous rise in complexity over the next decade [8], [9]. The software has to match customer wishes and requirements in any cases. This means that increasing software complexity results in an increasing number of requirements. Software quality and correctness of a new automotive system can not be validated as it is done with standard PC software. A driver will not accept to test his new car in daily traffic. Violating or forgetting just one requirement may cause serious consequences. For example ignoring the stop message from an anti-pinch protection sensor in just one case of the control software of a power window is a question of vital importance. 3.2 Definitions Requirements engineering is a sub-discipline of system engineering. Its goal is to help customer and contractor to describe their wishes to produce a new system and to support the developer to understand and structure these wishes and to ensure that the product meets the imposed requirements. The biggest part of the requirements is specified during the analysis phase and has to be validated

4 and traced through the following development phases design, implementation and system integration. In the requirements engineering process the essential functional and non-functional requirements for a system to be produced, are discussed, specified, analysed, validated and documented. Boehm [10] distinguishes between two techniques for reviewing requirements specifications, verification and validation. He explains the difference between both activities as follows: Verification: Am I building the product right? Validation: Am I building the right product? The IEEE-Standard [11] defines validation as follows: Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. This is achieved by inspecting the following criteria completeness consistency feasibility and testability within an actual requirements specification and tracing the requirements through the whole development process. Validation can be made with different manual and computer aided techniques. In [10] good overviews about verification and validation techniques are presented. 3.3 Requirements Engineering for Component- Based Software When composing a component-based application software with predefined components from a component library, it is a logical conclusion that the overall number of errors will be less due to reusing validated components with a better quality. But when composing and configuring components for a new application, design errors will still occur for example by disregarding or forgetting some requirements. In addition to other validation techniques like reviews and consistency checks (static structure and data types), we have chosen simulation to detect design errors in the dynamic behaviour in the early design phase. Simulation has been chosen because in many cases of software development for an embedded real-time system, the distributed target system is not available for rapid prototyping at the beginning. Therefore it is helpful to simulate the designed software structure and its dynamic behaviour by using a simulation model as for example in [12]. Another reason for selecting simulation for the requirements validation is the increasing importance of automatic target code generation from modelling and simulation tools. It is assumed that a planned tool for componentbased software development will also provide target code generation in the future. When using generated code from a component-based model the currently used validation technique conformance testing will not work anymore. Conformance testing means that the dynamic behaviour of the simulation model is recorded and compared to the dynamic behaviour of the executed code during black-box testing on the target system. But when the simulation model and the executable code are both extracted from the same component-based model, they are based on the same set of data. However, most nowadays simulation tools lack support for efficient structured requirements specification and validation mechanisms. Deviations of the simulated behaviour from single requirements have to be checked intuitively by the developer by hand. For that reason, a new requirements validation process applying use cases and simulation is presented in the next chapter. 4. Applying Use Cases for the Validation of Component-Based Software 4.1 Describing Requirements with Structured Use Cases Use cases as defined by Jacobsen [13] are not concretely defined, and leave a lot to interpretation by the user. According to Jacobson, A use case is a specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of events initiated by an actor and the system...the collected use cases specify all the existing ways of using the system [13]. This description of use cases has been popularised in nearly all object-oriented methodologies to date. Use cases lead to a scenario-driven analysis model. The actors used in this analysis model are not generally corresponding with the components in the later componentbased design model. It depends on the behaviour of each actor if a corresponding component can be found in the component library or if more than one library component have to be selected and connected to design the required behaviour of an actor in the later component-based design process. Use cases describe courses of events between an actor and the system. One course of events is called scenario. An actor plays a role concerning to a selected function. An actor can be a human being, a machine or a computer system. At this time it has to be noticed that use cases for themselves are not object-oriented but course-oriented. They describe dynamic behaviour in a system-oriented view. Because of their course-oriented and system-oriented view, they are a very good fit for the requirements specifi-

5 cation for component-based software, where the required interactions between the composed components have to be analysed and validated. For capturing the requirements of component-based software we have developed [14] a more formalised use case template (Figure 5) which is based on Cockburn s [16] formalised definition of use cases. In his point of view, use cases capture not only the scenarios between the user and the system but also scenarios specifying interactions between actors modelled inside the system. In this context, Mattingly and Rao [15] introduced a similar extended view of use cases and denoted the scenarios between actors inside the system as collaboration cases. Since the form of use cases and collaboration cases does not differ and for simplicity, we denote it uniformly as use case. USE CASE <No> < Use Case Name> 1 Goal 2 Precondition 3 Postcondition 4 Actors 5 Main scenario Step Action 6 Event Scenario 2 Step Action 7 Event Variations 10 Exceptions 11 Notes 12 Figure 5: Use case template Each use case describes how the goal of a selected actor is accomplished or fails. The simple use case template in Figure 5 provides a structured form for writing use cases which are not only helpful for gathering design requirements but also support later validation of a componentbased software. Keeping the use cases form simple has been the ultimate challenge and will keep user acceptance high. The structured use case is defined as follows: 1 Use case name: Provides a short meaningful name. 2 Represents the goal of the use case. 3 Preconditions indicate circumstances that must be true prior to the invocation of any scenario of the use case. Alternatives of preconditions are possible. They are ordered by numbering with letters (a,b,c...). 4 The postcondition validate that the main scenario and all alternative scenarios successfully achieved the stated goal of the use case. 5 An actor plays a role (e.g. user, machine, computer system or software component), which influences the system or is influenced by the system during a scenario. 6 Each use case has only one main scenario. The main scenario is a sequence of steps that the role or actor is likely to take in order to accomplish the goal of the use case. The main scenario is intuitively the easiest way to reach the goal. 7 Alternative scenarios are optional. Each use case has zero to many alternative scenarios. The alternative scenario is a different sequence of steps that the role of actor can take that also accomplishes the goal of the use case. Usually they are triggered by another event or have different preconditions. 8 The event which triggers the sequence of steps in the scenario. 9 Single step in a scenario. 10 Variations are scenarios which differ just insignificantly in one step from another scenario or just the role or actor is varied. 11 The exception scenario is a sequence of steps the role or actor takes when the task is interrupted. The postcondition that validates the goal of the use case is not necessarily true after the exception scenario has been taken. 12 Notes for comments. The template has been realised as a MS-Word97-Table because nowadays UML (Unified Modelling Language) [17] modelling tools do not enable structuring use cases in a user-friendly manner. 4.2 The Validation Process The component-based software development and validation process is shown in Figure 6. The development process starts with gathering requirements. The courseoriented part of the requirements is described in structured use cases presented in the previous chapter. After that the developer is building up the component-based model derived from the requirements and by selecting suitable components from the component library. The componentbased model contains all structure and behaviour descriptions which are necessary for the simulation model and the code composition for the target system.

6 Component Library Idea Analysis Requirements Specification Component- Based Design Component- Based Model Code Composition Source Code (Target System) Formalised Requirements from Use Cases Validation Simulation Model Figure 6: Component-based software development and validation process Requirements Specification Component-Based Model Stimuli Simulation Model Use Case Main Scenario Scenario 2 Requirements Sequence Diagr. A1 A2 A3 Mapping A -> C E -> M Comparison Sequence Diagr. C1 C2 C3 Trace Sequence Diagr. C1 C2 C3 Improvements required Validation O.K. Compliance Checking simulated Differences Possible Composition Errors Figure 7: The simulation based validation process The validation (Figure 7) itself is based on compliance checking between the formalised required behaviour derived from the use cases and the simulated behaviour of the simulation model. The simulation model, which is described with an ADL, is a subset of the componentbased model and contains all information about the submodel views structure, communication and execution of the modelled application. The formalisation of the required behaviour starts with the structured use cases. Each scenario of the collected use

7 cases has to be transformed by the developer into a requirements sequence diagram, describing the ordered interactions between the analysed actors (Ax). The sequence diagrams are according to the UML standard [17]. Requirements Sequence Diagram (A1) (A2) (A3) E1; t_max=30ms E3 E5 E3 E2; t_max=30ms E4 E4 E6 t_int= [0,49;0,51]s Figure 8: Requirements sequence diagram In addition to the causal ordering of event communication between the actors also real-time constraints can be specified in a sequence diagram. Timing requirements can be defined with a minimum time, a maximum time or with a time interval. Figure 8 contains the two different kinds of timing requirements: timed event delay A timed event means that the actions connected to the event consume time. In Figure 8 the t_max specifies the maximum time for sending the event E1 from actor A1 until it influences the receiving actor A2 by receiving event E1. This is necessary because the actor-oriented view in the use case driven analysis model is different to the component view in the component-based simulation model. In the component-based simulation model, which is a subset of the component-based model, not every component is corresponding exactly to one actor. It is possible that a sent event is passed through many components in the modelled component structure until it affects the component corresponding to the receiving actor. A delay is a timing requirement between the occurrence of two events which can also be seen in Figure 8. The time interval indicates that event E5 has to occur after the occurrence of event E1 with a delay time in the specified interval range. In a further step, the requirements sequence diagrams have to be mapped to the name space of the component-based simulation model to supply an automated compliance check between requirements sequences and the recorded event trace sequences from the simulation. After that the required behaviour is described in a set of comparison sequence diagrams which use corresponding component identifiers. Actors are mapped to components and events are mapped to messages of the connections between components. An interesting fact is that the stimuli for the simulation can be extracted from the initial events (messages) of the comparison sequence diagrams. In that way, all required courses from the use cases are simulated in the simulation model. Each component in the original component-based model owns a behaviour description for simulation and code generation purposes. The simulation model consists of the connected components and their behaviour description. When using an ADL for modelling the structure and behaviour of an application it is even possible to simulate model parts which are incompletely specified. The simulation on an architecture level records event traces of the message traffic between the component s interfaces, but not the events inside a component, for example between the component body and its interface. Usually event traces are just recorded in temporal order. The Rapide [2] simulation tools additionally enable causal ordering of the events, which helps filtering out causal dependencies from interleaved event sequences. The interleaved event sequences result for example from recording concurrent activities on different processor nodes in a distributed realtime system. The filtered sequences can also be depicted in trace sequence diagrams as shown in Figure 7. Differences between the required and recorded sequences detect possible composition or configuration errors, but have to be checked further by the developer. First experiences with applying the structured use cases for simulation based validation seems to be very promising for the exposure of design errors. The sequence diagrams can also be used later on during integration test as a basis for test-suite construction. 5. Example 5.1 Passenger Power Window The following example presents first experiences with applying use cases for the validation of component-based software. The example is taken from the automotive body electronics domain as shown in Figure 9 concerning the power window control function of the front passenger window. The example seems to be quite simple but functional details as comfort opening with connection to the central locking system, anti-pinch protection and conflict situations exhibit unexpected complexity. An example for a conflict situation are different wishes of driver and passenger when both press their button for the passenger power window in opposite directions.

8 Microcontroller Driver Door Microcontroller Dashboard CAN-Bus Microcontroller Passenger Door Figure 9: Body electronics system including the power window control Figure 10 presents a snapshot from the simulation model of the component-based software. The simulation model has been developed with ObjecTime Developer [3] which provides basic properties for component-based modelling and simulation. The presented architecture component front passenger power_window contains the components power_window_control, motor, window_switch, hallsensor and the connections between the components. 5.2 Requirements Specification with Use Cases Requirements are gathered with the use case templates introduced in chapter 4.1. The following use case (Figure 11) shows an excerpt from the use case Automatic Closing of Passenger Power Window with ignition on. For a better understanding, all actors in the use case have been marked with an identifier (Ai) enclosed in the following brackets. Remarkable is also the extends -relationship of step 1.2 which refines the use case with another use case Executing anti-pinch protection with ignition on. Figure 10: Snapshot from the component-based simulation model power_window USE CASE FH.5 Automatic Closing of Passenger Power Window with ignition on Goal Passenger or driver wants to close the passenger power window by pressing the passenger side switch when ignition is on Precondition Ignition on Postcondition Passenger power window is stopped Actors Driver (A0), Passenger (A1), passenger side switches (A2, A3) for the passenger power window (A4) Main Scenario Step Action Event Passenger (A1) presses for a short while the passenger side switch (A3) in position close 1.1 Passenger power window (A4) is closing 1.2 Executing anti-pinch protection with ignition on (-> Use Case FH.8) 1.3 Passenger (A1) presses the passenger side switch (A3) for the Passenger power window (A4) again 1.4 Passenger power window (A4) stops Scenario 2 Step Action Event Passenger (A1) presses for a short while the passenger side switch (A3) in position close 2.1 Passenger power window (A4) is closing 2.2 Executing anti-pinch protection with ignition on (-> Use Case FH.8) 2.3 Passenger power window (A4) is in end position 2.4 Passenger power window (A4) stops Scenario 3 Step Action Event Driver (A0) presses for a short while the passenger side switch (A2) in position close 3.1 Passenger power window (A4) is closing 3.2 Executing anti-pinch protection with ignition on (-> Use Case FH.8) Variations - none - Exceptions - none - Notes Passenger side switch (A2) at the driver door has priority to passenger side switch (A3) at the passenger door Figure 11: Use case Automatic Closing of Passenger Power Window with ignition on

9 5.3 Extracting Requirements Sequence Diagrams from Use Case Scenarios Requirements Sequence Diagram Passenger Side switch Power Anti-Pinch- (A1) (A3) Window (A4) Protect.(UCFH.8) press close execute press stop Figure 12: Required behaviour in a sequence diagram extracted from the main scenario The next step in preparing the course-oriented requirements for the validation of component-based software is the extraction of the requirements sequence diagrams from the use case scenarios. This is done for all meaningful scenarios, variations and exceptions of each use case. The result is a large set of requirements sequence diagrams. Figure 12 shows the requirements sequence diagram extracted from the main scenario of the use case Automatic Closing of Passenger Power Window with ignition on. The interactions from the use case main scenario between the actors are described in sequential order. The extends -use case from step 1.2 becomes a substitute for an actor in the requirements sequence diagram, because it also interacts with the other actors. To reduce complexity the possible timing requirements are not shown in Figure 12. The time axis would be running top down and temporal constraints would be specified for the execution of single events or between the occurrence of two events (note: the event is just one point without history or future on the time axis but in practise events are associated with actions which consume time). 5.4 Mapping the Requirements Sequence Diagrams to the Comparison Sequence Diagrams Extensive work has to be dedicated to the mapping of the actor identifiers from the use case view to the component identifiers of the component-based simulation model. Actor names are mapped to corresponding component names and event names are mapped to connection-message names of the simulation model as it is shown in Figure 13. The result is the comparison sequence diagram. Finding the corresponding components and connection-messages is a remaining validation task which can not be automated. But after the mapping a computer aided compliance checking against the simulated event traces is feasible. Requirements Sequence Diagram Passenger Side switch Power Anti-Pinch- (A1) (A3) Window (A4) Protect.(UCFH.8) press close execute Mapping Comparison Sequence Diagram window power_window motor hallsensor _switch _control AutoUp Close GetValue press stop Actor -> Components: Passenger(A1) -> window_switch Side switch(a3)-> power_window_control Power Window(A4) -> motor Anti-Pinch-Protect.(UCFH.8) -> hallsensor AutoUp Stop Events -> Connection-Messages press -> AutoUp close -> Close execute -> GetValue stop -> Stop Figure 13: Mapping of the requirements sequence diagram to the comparison sequence diagram Figure 14: Recorded behaviour from the simulated event trace of the power window control

10 5.5 Simulation based Validation Validation is done by compliance checking between the comparison sequence diagram (Figure 13) and the simulated event trace (Figure 14). Figure 14 shows a recorded event trace sequence diagram which embodies a possible design error because of a differing behaviour. After the initialisation, the window_switch component sends an AutoUp message to the power_window_control component to assign the motor component to Close the window. When the window_switch component sends the AutoUp message again as specified in the use case, the power_window_control component sends the wrong message Open instead of the required Stop to the motor component. The logical conclusion is that the power_window_control component has either been configured wrong or the composition of the components has been made faulty. The component-based model has to be improved. 6. Conclusions and Further Steps Component-based software development promises overall improved quality, manageablity and reduced time to market. It can not be concluded from the quality of single software components to the overall software quality of a composed real-time software. Although errors are limited to composition and configuration errors and the overall number of errors will be less, validation techniques have to be applied for the exposure of design errors. When applying an interface connection architecture and applying validated software components in the context of the presented component model, current validation activities may only concentrate on analysing the architecture description. Simulation has been chosen for the validation of the dynamic behaviour of component-based real-time software in an early development phase. Up to now, the compliance checking between the required and the simulated behaviour is done by hand and its automation is a goal of further research. Extracting scenarios from the structured use cases is simple, but as mentioned before, for real-time systems use cases contain more scenarios than ordinary transformational software. For that reason, writing a big amount of structured use cases and extracting the requirements sequence diagrams out of it would be more comfortable with tool support. A timeconsuming part of the validation process is the mapping of the use case identifiers to the identifiers of the simulation model of the component-based software. This creative step will always need a developer for making the assignments, but it is conceivable to support even that with tool features. Compliance checking between the required comparison sequence diagrams and the recorded event trace sequence diagrams from the simulation seems to be a feasible task. Deviations of the simulated behaviour from single requirements are always indicators for possible composition errors and have finally to be checked by the developer by hand. 7. Literature [1] Luckham, D.C. et al.: Specification and Analysis of System Architecture Using Rapide, IEEE Transactions on Software Engineering, 21 (4), April 1995, S [2] Rapide Design Team: Guide to the Rapide 1.0 Language Reference Manuals, Program Analysis and Verification Group, Computer Systems Lab., Stanford University, version 1.0, July [3] ObjecTime Developer 5.1: User Guide 1.0, ObjecTime Limited, 340 March Road, Kanata, Ontario, August [4] Selic, B., Gullekson, G., Ward, P.T.: Real-Time Object- Oriented Modeling, Wiley, New York, [5] Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, Addison Wesley, Reading, Mass., [6] Göhner, Peter: Komponentenbasierte Entwicklung von Automatisierungssystemen, GMA-Kongreß 98, VDI- Berichte Nr. 1397, 1998, p [7] Controller Area Network CAN: An In-Vehicle Serial Communication Protocol, Handbook, SAE Press, [8] Daimler-Benz AG : Presse Information PRI_0428.DOC, Technologiepressekonferenz, Stuttgart, Sept [9] Kytölä, T., Mathony, H.-J., Münich, A.: Objektorientierte Software-Entwicklung für Karosserieelektronik- Anwendungen, VDI-Tagung 98 Electronic Systems For Vehicles, VDI-Berichte Nr. 1415, 1998, p [10] Boehm, B. W.: Verifying and Validating Software Requirements Specifications, IEEE Software Vol. 1, Nr. 1, Januar 1984, S [11] IEEE: ANSI/IEEE Std , IEEE Guide to Software Requirements Specifications, [12] Fleisch, W., Ringler, Th., Belschner, R.: Simulation of Application Software for a TTP Real-Time Subsystem, Proc. European Simulation MultiConference, Istanbul, Turkey, 1997, S [13] Jacobsen, Ivar et al.: Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, Reading, Mass., [14] Fleisch, Wolfgang: Validierung komponentenbasierter Software für eingebettete Echtzeitsysteme, GMA- Kongreß 98, VDI-Berichte Nr. 1397, 1998, p [15] Mattingly, LeRoy, Rao, Harsha: Writing Effective Use Cases and Introducing Collaboration Cases,The Journal of Object-Oriented Programming, Vol. 11(6), 1998, p [16] Cockburn, Alistair: Structuring Use Cases with Goals, The Journal of Object-Oriented Programming, Vol. 10 (5/6), Sept.-Dec [17] Unified Modeling Language - UML - Notation Guide version 1.1, Rational Software Corporation, Santa Clara, CA,