Embedded Software Engineering Part 3: Analysis of Functional Requirements

Transcription

1 Embedded Software Engineering Part 3: Analysis of Functional Requirements Prof. Dr.-Ing. Stefan Kowalewski Chair Informatik XI, Embedded Software Laboratory RWTH Aachen University Summer term 2005 Reminder: V model requirements analysis acceptance test specification integration test architecture design system integration modul/algorithm design modul test implementation 1

2 How to do requirements analysis Reminder: Online Includes first Requirements Elicitation ad-hoc analysis - Collect the requirements from customers, marketing, system engineers etc. Requirements Analysis - Analyse whether the requirements are actually what the customers, marketing, system engineers etc. want. Offline Results will be presented to the customer after analysis Several iterations possible Two analysis paths technically oriented functional reqs (first version) requirements elicitation business oriented non-functional requirements (first version) requirements analysis analysis of functional reqs analysis of qualities functional specification driving qualities architecture design 2

3 Design viewed as an optimization problem requirements analysis analysis of functional reqs analysis of qualities functional spec = optimization constraints driving qualities = optimization criteria design = optimization Find best or good enough solution (measured by qualities) among all admissible solutions (given by functional spec.) Analysis of Functional Requirements Manifest your understanding of the elicitated requirements (make them clear to you). Structure and present them in different form to the customer (e.g., build models or derive test cases), such that the customer can then compare your understanding with his/her original intentions. Do not begin designing the system! Why? - Customer will discuss design issues with you. - Design solution will become part of specification document and reduce degree of design freedom. How? - Regard system as black box (in this phase). 3

4 Analysis of Functional Requirements First step: Define System Boundaries Interfaces between system and environment What must be designed, what is given? Needed for agreement on content of the project One possible model: Context diagram Context diagram Elements: System (Function) Partner in the environment (Interface) Flow/Exchange of - Data - Information - Energy - Mass - 4

5 Context diagram: Example ACC Driver What if sensor would be part of system? Radar sensor activate indicate operation, selected speed, current speed, current distance object distance, object velocity ACC select speed, activate, de-activate acceleration/ decelaration Engine controller brake force ESP system car speed, lateral acceleration, yaw rate Analysis of Functional Requirements Second Step: Understand Black Box behavior Capture functional requirements as they manifest themselves at the interface between system and environment. One possible tool: Use Cases Use case = A coherent piece of functionality of the system that is visible (in black-box form) from outside the system. Elements outside the system which are involved in the use case are called actors. In embedded systems, actors are mostly sensors and actuators (but also users). OOA Definition of use case (see OOSK, Prof. Lichter): A sequence of interactions between an actor/actors and a system triggered by a specific actor which produces a result for an actor. (applicable to continuous control functions?) 5

6 Use cases: Example ACC Use cases: Activation De-activation Keeping speed constant Keeping distance to front object constant Use case relations/ use case diagrams In OOA, use cases can have relations: - includes - extends - generalizes (with inheritance of interaction relations) This offers possibility to reuse use cases. Aim: Structure functionality. Use case diagrams: System boundary Usecase1 Actor 1 relation Actor 2 Usecase2 } Your opinion? Use case diagram for ACC example? 6

7 Textual description of use cases Several templates in literature. From lecture OOSK by Prof. Lichter: - Name - Aim - (Level) - Pre-condition - Post-condition - Post-condition in case of failures - Actors - Trigger - Standard sequence (steps, actions/events) - Alternatives/exceptions Textual description of use cases: Example ACC activation Name: Activating ACC Aim: ACC must be operational Pre-condition: ACC is not activated; car is running; radar sensor is available; ESP, engine ECU are running; CAN is available; cruise speed is selected; current speed is in [30 ; 180 km/h] Post-condition: ACC operation is indicated to driver Post-condition in case of failures: failure to activate ACC is indicated to driver Actors: driver, radar sensor, ESP Trigger: driver operates ACC activation interface 7

8 Textual description of use cases: Example ACC activation /2 Standard sequence (steps, actions/events): 1 Driver operates ACC activation interface 2 ACC activates radar sensor 3 radar sensor acknowledges availability 4 ACC checks that current speed is in [30 ; 180 km/h] 5 ACC indicates operability Alternatives/exceptions: 3a1 no response from radar sensor 3a2 ACC indicates failure 4a1 current speed is not in [30 ; 180 km/h] 4a2 ACC de-activates radar 4a3 ACC indicates failure Your try Use cases: Activation De-activation Keeping speed constant Keeping distance to front object constant 8

9 Textual description of use cases: Example Keeping distance to front object constant Name: Keeping distance to front object constant Aim: keeping distance constant without driver interaction Pre-condition: ACC is active Post-condition: current distance is displayed, distance is as specified, in speed control if necessary Post-condition in case of failures: indication of failure, deactivate ACC Actors: engine CU, ESP, driver, sensor Trigger: detection of a front object Textual description of use cases: Example Keeping distance to front object constant /2 Standard sequence (steps, actions/events): 1 Get distance and object speed 2 Get own speed, lateral acceleration, yaw rate 3 Compare current with desired distance 4 Adjust speed accordingly 5 Display distance 6 Go back to 1 as long as object is in front Alternatives/exceptions: Your turn! 9

10 Sequence of actions/events in use cases can be represented graphically by Sequence diagrams/mscs Basic idea: Represent interaction between system and actors by a temporally ordered exchange of messages Fundamental elements: - System, actors: vertical lines - Message exchange: horizontal arrows Actor Message System Temporal order (qualitative) Sequences are only possible, not a complete behavioral specification! Origin: Graphical representation of use cases: Sequence diagrams/mscs /2 - OSI Time Sequence Diagrams (standardized 1991!) - ITU-T SG 10: Message Sequence Charts, ITU-T SG 10: Algebraic semantics of MSCs, 1996 UML adopted MSCs, renamed them to sequence diagrams and changed/added some elements/representations - Examples: Lifelines for objects stimulus and response Actor System Actor System stimulus response 10

11 MSC Example: production plant (from Kowalewski, at-automatisierungstechnik, 9/2001) Produktion C-Teile Produktion D-Teile Lager C-Teile C C C Roboter D D Lager D-Teile Greifplatz C-Teile C D Greifplatz D-Teile Diskriminator D C C C D D A A B A B B Förderband Ortsschalter MSC Example /2: basic MSC (from Grabowski et al, at- Automatisierungstechnik, 12/2001) MSC ProduktionAC Roboterplatz FabrikFürC Produktionszelle FabrikFürD Initialzustand NeuesTeil (A) T ProdZeit Produktion eines neuen C-Teils A-Teil erkennen und C-Teil greifen Gegriffen Produkt montieren und ausliefern Produkt (AC) NächstesTeil Vorhanden (C) Initialzustand 11

12 MSC Example /3: inline expressions (from Grabowski et al, at- Automatisierungstechnik, 12/2001) MSC AlternativeProdukte Roboterplatz FabrikFürC Produktionszelle Initialisierungsphase FabrikFürD alt NeuesTeil (A) Gegriffen NächstesTeil Vorhanden (C) Produkt (AC) NeuesTeil (B) Gegriffen NächstesTeil Vorhanden (C) Gegriffen Produkt (BDC) Vorhanden (D) MSC Example /4: High level MSCs (from Grabowski et al, at- Automatisierungstechnik, 12/2001) MSC Produktionszyklus Initialisierungsphase Initialzustand ProduktionAC ProduktionBDC 12

13 Example for sequence diagram: Use case ACC activation Name: Activating ACC Aim: ACC must be operational Pre-condition: ACC is not activated; car is running; radar sensor is available; ESP, engine ECU are running; CAN is available; cruise speed is selected; current speed is in [30 ; 180 km/h] Post-condition: ACC operation is indicated to driver Post-condition in case of failures: failure to activate ACC is indicated to driver Actors: driver, radar sensor, ESP Trigger: driver operates ACC activation interface Example for sequence diagram: Use case ACC activation (2) Standard sequence (steps, actions/events): 1 Driver operates ACC activation interface 2 ACC activates radar sensor 3 radar sensor acknowledges availability 4 ACC checks that current speed is in [30 ; 180 km/h] 5 ACC indicates operability Alternatives/exceptions: 3a1 no response from radar sensor 3a2 ACC indicates failure 4a1 current speed is not in [30 ; 180 km/h] 4a2 ACC de-activates radar 4a3 ACC indicates failure 13

14 MSC for use case ACC activation driver sensor ACC ESP alt driver wants to activate ACC activate acknowledgement get speed speed in [30,180] km/h indicate operability driver wants to activate ACC activate not available indicate failure driver wants to activate ACC activate acknowledgement indicate failure get speed speed not in [30,180] Outlook Next part: Analysis of qualitative (non-functional) requirements 14