Eliciting integration PowerPoint Presentation

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

Define a set of typical

ES Development

“

Setup”s

For each such setup, define a set of relevant development use cases that highlight some tool interoperability needs.

For each use case, define a set of tool interoperability scenarios

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 top 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 Top 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.wiringdiagrams21.com/2009/07/31/2005-infiniti-qx56-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 dynamicsDefines control algorithmUMLSoftware design & codingTool relationshipsSimulink<->Requ: a trace is defined between control properties in Simulink and corresponding requirements in Requ. Management tool.

Requirements Management

Matlab/Simulink

UML

C compiler

Code Generator

Simulation

T

ool

Requ

. Engineer

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