Eliciting integration scenarios Proposal for Meeting 20130503 Terminology

Eliciting integration scenarios Proposal for Meeting 20130503

Terminology To be placed on the “Terminology” wiki page http: //open-services. net/wiki/embedded-systems/Terminology/ • ES development setup • Use Cases • Scenarios • Priority Topic - An aspect of embedded system development that the ES User Group has identified as of high priority.

The ES User Group Top 4 Topics • Model-based development - Rainer: Make more specific. MBD testing? Implementation? Etc. • Product line engineering - Atego: reuse - Rainer: avoid this topic for the time being, since it overlaps with ALM/PLM workgroup. But we should certainly do later • Systems of systems - Rainer: avoid this topic for the time being, since it overlaps with ALM/PLM workgroup. But we should certainly do later • Mission critical systems Do we need to define more topics for this User Group?

Approach 1. Define a set of typical ES Development “Setup”s 2. For each such setup, define a set of relevant development use cases that highlight some tool interoperability needs. 3. For each use case, define a set of tool interoperability scenarios 4. Identify and generalised scenarios into common patterns To start with define 1 -2 ES setup

1. Define a set of typical ES Development “Setup”s • 1 ES Development “Setup” consists of 2 parts: - Part 1 - An embedded system product description • • That fits to one or more of our topics Described as: – – – A simple textual description and/or A list of functional requirements and/or A set of models - Part 2 - A tool chain supporting the ES product development • Consists of – – – A set of tools • The specific role a tool plays in the tool chain (such as the activities the tool cover) needs to be cleared defined; since a tool can play many different roles. • Example, a UML tool can be used as an analysis or design tool in different setups. A set of development roles/users (development stakeholders) • Example: requirements engineering, designer, architect, … A set of relationships and dependencies between tools • Example: data/artefact/model flows between tools • An ES Setup ought to cover a small section of the ES development (instead of a big setup for the complete process) • An ES Setup should focus on the Topics of the ES User Group.

Part 1 - An embedded system product description • Example: Vehicle cruise control system - (Models below for illustration purposes only) http: //www. antony-anderson. com/cruise/3 -oper. htm http: //www. freepatentsonline. com/6769504. html http: //www. wiringdiagrams 21. com/2009/07/31/2005 -infiniti-qx 56 -auto-cruise-control-wiring-and-system-circuit-diagram/

Part 2 - A tool chain supporting the ES product development (Model below for illustration purposes only) • Tool Roles: - Simulink: • Models system dynamics • Defines control algorithm - UML • Software design & coding • Tool relationships - Simulink<->Requ: a trace is defined between control properties in Simulink and corresponding requirements in Requ. Management tool. Matlab/ Simulink Requirements Management Requ. Engineer C compiler Code Generator UML Simulation Tool

A typical ES Development “Setup” • Brake-by-wire - http: //www. timmo-2 -use. org/deliverables/TIMMO-2 USE_BBW. pdf • Can be used to extract both a product description, and tool chain. • Found on web from a simple searching. - Need/can to check Volvo contacts for further details.

2. Define Use Cases • 2. For each such setup, define a set of relevant development use cases that highlight some tool interoperability needs. • Use 1 UML Use Case diagram - Include development roles/users – as actors - Include a high-level textual description of each use case.

3. Define Scenarios • 3. For each use case, define a set of tool interoperability scenarios. • Each scenario describes a particular user/tool interaction that includes some kind of tool interoperability need

3. Define Scenarios • How to describe a scenario? - Use UML sequence diagrams for each scenario - Scenarios are grouped under corresponding Use Case - Objects consist of either tools or users/developers - Focus is on messages (interactions) between tools (hence integration needs) • Messages (interactions) between users can exist for clarification purposes • Messages (interactions) between users and tools can exist for clarification purposes - Define preconditions & postconditions for the scenario • … • Given such a setup, it should be relatively easy to extract “integration specifications“?

4. Identify Patterns • 4. Identify and generalised scenarios into common patterns • Scenario patterns are submitted to OSLC Workgroups for further consideration