eliciting integration scenarios proposal for meeting 20130503
TRANSCRIPT
Eliciting integration scenariosProposal for Meeting 20130503
Terminology
To be placed on the “Terminology” wiki pagehttp://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”s2. 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 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.htmhttp://www.freepatentsonline.com/6769504.htmlhttp://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 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.
Requirements Management
Matlab/Simulink
UML
C compilerCode Generator
Simulation Tool
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