Eliciting integration scenarios Proposal for Meeting 20130503.

Slides:



Advertisements
Similar presentations
1 Aspects of IEEE P1471 Viewpoints in Unified Modeling Language (UML) Manzur Ashraf, BRAC University Humayra Binte Ali, Dhaka University Md.Mahfuz Ashraf,
Advertisements

IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
CS3773 Software Engineering Lecture 03 UML Use Cases.
Use-case Modeling.
Systems Analysis and Design in a Changing World, Fourth Edition
Lecture 12: Chapter 22 Topics: UML (Contd.) –Relationship Structural Behavioral –Diagram Structural Behavioral.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
1 © Wolfgang Pelz UML2 UML Part Two. 2 © Wolfgang Pelz UML2 Chapters Four & Twelve Interaction Diagrams.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
CSCI928 Software Engineering Requirements & Specifications Modeling System Interactions Tri A. Kurniawan, M.Eng. Ph.D Candidate
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Sharif University of Technology1 Design and Use-case Realization Software Engineering Laboratory Fall 2006.
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Chapter 7: The Object-Oriented Approach to Requirements
Software Engineering 2003 Jyrki Nummenmaa 1 USE CASES In this lecture: Use cases - What are use cases? - Why to use use cases? - How to write.
System Sequence Diagrams
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Chapter 5 – System Modeling
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa USE CASES In this lecture: Use cases - What are use.
Class, Sequence and UML Model.  Has actors and use cases.
Project Analysis Course ( ) Final Project Report Overview Prepared by: Sijali Petro Korojelo (Course Assistant)
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
SE-280 Dr. Mark L. Hornick Design Review Issues. SE-280 Dr. Mark L. Hornick 2 Many expensive defects are a result of design problems Software applications.
Chapter 8 Architecture Analysis. 8 – Architecture Analysis 8.1 Analysis Techniques 8.2 Quantitative Analysis  Performance Views  Performance.
OSLC Embedded Systems User Group Charter. OSLC ES User Group Charter - Required name of User Group -Embedded Systems purpose and scope of User Group (e.g.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Object-Oriented Analysis and Design Fall 2009.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 5 Models and UML Notation for The Object-Oriented Approach.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
UML-1 3. Capturing Requirements and Use Case Model.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
UML-1 8. Capturing Requirements and Use Case Model.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
Interaction Diagrams Interaction Diagrams allow the designer to show how groups of objects collaborate in some behavior. –Interaction Diagrams will show.
OSLC PLM Workgroup visit URL for terms of usage1 OSLC PLM Workgroup PLM Scenarios Systems Engineering scenario “Systems Engineer Reacts to Changed Requirements”
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
System sequence diagrams
Eliciting Integration Scenarios As discussed during Meeting
Use Cases CS 6961 – Lecture 4 Nathan Dykman. Neumont UniversityCS Lecture 102 Administration Homework 1 is due –Still reviewing the proposal, but.
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
CIM LAB MEETING Presentation on UML Rakesh Mopidevi Kwangyeol Ryu.
Why have an Ontology for DoT? The difficult questions.
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
Chapter 5 System Modeling (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Prof. Hany H. Ammar, CSEE, WVU, and
UML - Development Process 1 Software Development Process Using UML.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Appendix Object-Oriented Analysis and Design: Use Cases and Sequence Diagrams Modern Systems Analysis and Design Fifth Edition Jeffrey A. Hoffer Joey F.
Use Cases Defining user requirements in chunks. Introduction Presentation on Use Cases, includes: Presentation on Use Cases, includes: What is a use case.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Object Oriented Analysis & Design By Rashid Mahmood.
OSLC ES User Group Telco – 10 April Agenda Attendees: Andreas Korff (Atego), Hedely, Frederic, Rainer, Jad Quick recall from last telco Decide on.
Basics of RSA Rational Software Architect. What is RSA? Comprehensive Modeling and Development environment that leverages the Unified Modeling Language.
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
Chapter 4 – System Modeling Lecture 1 1Chapter 5 System modeling.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Chapter 5 – System Modeling
Chapter 5 – System Modeling
System sequence diagrams
Unified Modeling Language
Analysis models and design models
Uml diagrams In ooad.
Presentation transcript:

Eliciting integration scenarios Proposal for Meeting

Terminology To be placed on the “Terminology” wiki page 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 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)

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 compiler Code Generator Simulation Tool Requ. Engineer

A typical ES Development “Setup” Brake-by-wire - USE_BBW.pdfhttp:// 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