Beginners Guide to Model-Based Systems Engineering
12/18/2018
A Beginner’s Guide to Model-Based Systems Engineering
David Long President, Vitech Corporation Past President, INCOSE (2014 & 2015) dlong@vitechcorp.com
Copyright © 2018 by Vitech. All rights reserved.
1
Transforming to Model-Based Systems Engineering: A Roadmap for Today
• Understanding the changing environment for systems engineering • Decoding model-based systems engineering (MBSE) • Realizing the benefits of MBSE • Seeing MBSE in practice: An illustrated walkthrough
• Capturing the requirements • Defining the system logic • Implementing the system logic • Testing 1,2,3 • Addressing myths and misconceptions • Deploying MBSE successfully (time permitting) • Engineering in the age of complexity
Please raise questions and offer perspectives as they occur
2
1
12/18/2018
Connecting People, Disciplines, Insights, and Ideas
Image credit: US Department of Transportation
Systems engineering focuses on ensuring the pieces work together to achieve the objectives of the whole. Systems Engineering Body of Knowledge (SEBoK)
3
4
2
12/18/2018
Understanding the Original Environment for Systems Engineering
5
Executing Classical Engineering in a Complicated World
R
L
A
A
A
A
A
C
C
C
R1
L1
B
B
E
E
E
R1.1
L1.1
C
C
G
G
G
R1.2
?
L1.2
D
E
E
?
H
H
H
R2
L2
F
G
G
L3
H
H
I
I
I’
R2.1
L3.1
I
I
J
J
J
R2.2
?
K
L
L
L
L3.2
J
J
R2.3
M
M
M
L3.3
L
L
R3
N
N
N’
L4
M
M
R4
O
O
O
F4.1
N
N
R4.1
P
P
P
F4.2
O
O
R4.2
Q
F5
P?
P
R5
R EQUIRED
L OGICAL
A S D ESIGNED
A S O RDERED
A S B UILT
A S D ELIVERED
A S S ERVICED
R ETIRE
U TILIZATION & S UPPORT
C ONCEPT
D EVELOPMENT
P RODUCTION
Adapted from Aras Corporation, 2018.
6
3
12/18/2018
Seeing Today’s Environment for (MB)SE
7
Image credit: Alisa Farr for Letter27. farrimages.com
Image credit: www.baaa-acro.com
Image credit: 7Wonders
Image credit: MotorTrend
8
4
12/18/2018
The Mismatch between Modern Conditions and Classic Approaches
We tend to assume that technological advances will enable us to do what we have always done, only better. However these same technologies imbue our operating environment with escalating non-linearity, complexity, and unpredictability . Attempts to control complex systems by using the kind of mechanical reductionist thinking … breaking everything down into component parts, or optimizing individual elements … tend to be pointless at best or destructive at worst .
9
Systems Challenges in Today’s Complex World
Exceeding the capabilities of traditional siloed approaches • System scale
• Mission complexity • Technical complexity • Project team complexity • Dynamic complexity
SE Vision 2025. Copyright © 2014 by INCOSE. All rights reserved.
Image credit: Alisa Farr for Letter27. farrimages.com
10
5
12/18/2018
A Response from Systems Engineering: Connecting on the Why and What with Clarity
“Functioning in an interdependent environment requires that every team possess a holistic understanding of the interaction between all the moving parts.”
“People can only be empowered if they have enough context to make good decisions.”
Quotes from Team of Teams , 2015
11
Decoding Model-Based Systems Engineering Understanding what MBSE is and what it is not
12
6
12/18/2018
Executing Classical Systems Engineering
13
Towards MBSE: A Practice in Transition
Future
Traditional
•
Specifications
ATC
Pilot
Airplane
•
Interface requirements
Request to proceed
Authorize
Initiate power-up
•
System design
Power-up
ReportStatus
Direct taxiway
•
Analysis & Trade-off
InitiateTaxi
Executed cmds
•
Test plans
Moving from document-centric to model-centric
Reprinted from INCOSE Model-Based Systems Engineering Workshop, February 2010
14
7
12/18/2018
“Defining” Models and MBSE
Model: a graphical, mathematical (symbolic), physical, or verbal representation or simplified version of a concept, phenomenon, relationship, structure, system, or an aspect of the real world. www.businessdictionary.com Model: a physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process. DoD5000.59-M 1998 Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. INCOSE SE Vision 2020, September, 2007 Digital Engineering: an integrated digital approach that uses authoritative sources of systems' data and models as a continuum across disciplines to support lifecycle activities from concept through disposal. ODASD-SE, 2017
15
Recognizing What MBSE Is Not: “Demythify” the Transition
16
8
12/18/2018
Understanding the Transition: Clarify “Model” in MBSE
17
Understanding the Transition: Clarify “Model” in MBSE
18
9
12/18/2018
Understanding the Transition: Clarify “Model” in MBSE
BASIS OF
ALLOCATED TO
REQ
ARCH
BEH
BASED ON
PERFORMS
19
Establishing Three Essential Components of MBSE
1. A declared metamodel • Structure and semantics • Textual and graphical
• Explicit, context-free language for communication • Problem, solution, and management dimensions 2. A process or methodology 3. Defined mappings / projections • “Fit for purpose” views • Documentation and design artifacts • Other work products
20
10
12/18/2018
Component 1. A Defined Metamodel: One Integrated Architecture Model
Behavior Domain
Source Requirements Domain
Originating requirements trace to behavior
Data
verified by
Behavior is allocated to physical components
V&V Domain
Architecture Domain
Data
Data
verified by
verified by
Originating requirements trace to physical components
21
Component 1. A Defined Metamodel: The Information Needed to Engineer a System
…more than diagrams
…more than a data dictionary
…more than capture
…more than specification
…more than the
system of interest
22
11
12/18/2018
Component 2. A Process for MBSE: An Integrated, Convergent Approach
Dgn V&V
BEH
REQ
ARCH
Level Of Detail
Source Documents
Docs
LEVEL 1
Dgn V&V
BEH
REQ
ARCH
Docs
Docs
LEVEL 2
Dgn V&V
BEH
REQ
ARCH
Docs
Docs
LEVEL n
23
Component 3. Defined Mappings and Projections: Artifacts as By-products of Good Systems Engineering
24
12
12/18/2018
A Consistent View of Views
25
pbd Geospatial Library
C.2 Collectors
C.1 Customers
C.3 Customer Certification Authority
Link
Status Link
Request Link
Return Link
Geospatial Library
Command Link
Collector Product
GL Internal Link
Certification Request Link
Certification Response Link
SYS.1.2 Workstation
SYS.1.1 Command Center
Geospatial Library
26
13
12/18/2018
27
sd t.2 Image not in Inventory
Customer
GeospatialLibrary
Collectors
par
t.2 Request Image
t.2 Accept Request
t.2 Information Request
t.2 CheckProduct in Inventory
t.2 TaskCollectors
t.2 Collect Data
t.2 Collector Tasking
t.2 Accept and Format Product
t.2 Process and Provide Collector Data
t.2 Collector Data
t.2 Put Product in Inventory
t.2 Get Product fromInventory
t.2 Accept Image
t.2 Provide Product to Customer
t.2 Collection Product
Date:
University Edition - For Academic Use Only
October 12, 2014
28
14
12/18/2018
act Thread 2 - Product Not In Inventory
t.2.1
t.2.2
t.2.3
[Customers]
t2.Make Information Request
t2.Receive Estimated Schedule
t2.Accept Products
t2. Collection Products
t2. Information Request
t2.Estimated Delivery Schedule
t2.Priority of Request
t.2.7
t2.Notify Customer of Estimated Delivery
<
t.2.4
t.2.5
t.2.6
t.2.9
t.2.10
[System]
t2.Provide Product To Customer
t2.Accept & Format Request
t2.Prioritize Request
t2.Determine Collector Mix
t2.Add Product To Inventory
<
t.2.8
t2.Task Collectors
<
t2. Collector Tasking
t2. Collector Data
t2.Collector Mix
t.2.11
t.2.12
[Collectors]
t2.Process and Provide Collected Data
t2.Collect Data
<
t2. Unprocessed Data
29
30
15
12/18/2018
spider Monitor and Assess Performance
Measure Customer Service Time
refined by
Performance Self Assessment
Assess Performance
basis of
basis of
refined by
Measure Order Fulfillment
results in
Workstation
allocated to
basis of
Evaluate Products vs. Request
Criteria for Self Assessment
basis of
generates
basis of
Report Deficiencies And Recommendations
basis of
Monitor Self Performance
Assess Self Performance
basis of
refined by
refined by
Monitor and Assess Performance
31
A Consistent View of Views
32
16
12/18/2018
Increasing Understanding through “Fit for Purpose” Representations
Reprinted from Department of Defense Architecture Framework (DoDAF) 2.0, May 2009
A strong semantic foundation underpinning shared understanding and rapid analysis
33
Applying an Integrated Toolbox of Representations: Aligning Views to the Need
• Who is your audience? • What do they want/need to see? • What do you want/need to tell them?
34
17
12/18/2018
So what about the Systems Engineering Vee?
35
A Modern Approach to the Systems Challenge: What MBSE is All About • Making system descriptive and analytical models explicit, coherent, and consistent • Evolution from low-fidelity representations in documents to higher-fidelity, richer representations • Improved granularity of knowledge capture for management, analysis, and learning • One architectural model connecting multiple analytical models • Leveraging models for communication and analysis • Developing an “authoritative source of truth” for system design and specification
• Ensuring consistent design and specification (when done well) • Providing an explicit system model to engineering teams
An evolution – not revolution – in thinking and approach… An evolution that offers transformative results
36
18
12/18/2018
Realizing the Benefits of MBSE
37
Aligning through an “Authoritative Source of Truth” • Align around a shared understanding • Move as a team with speed, confidence, agility • Engage stakeholders and subject matter experts • Collaborate with context in fit-for-purpose ways • Engineer and analyze • Work from what you know to what you don’t • Connect analyses and detail design with clarity • Capture the journey alongside the outcome • Adapt to changing requirements and technologies • Enable defensibility and trust
38
19
12/18/2018
Connecting Architecture and Analysis
“One model to coordinate them all”
39
Aligning and Responding with Reference Architectures
Image credit Don McCullough
40
20
12/18/2018
Leveraging Product Line Engineering
41
Incorporating Feedback and Learning: From Built-to-Last to Built-to-Evolve
42
21
12/18/2018
Moving from Custom-Built to Composability: SoSE, IoT, Interactions, and Capabilities
43
Looking beyond Marketing Hype: The State of Adoption
• Defense community
• NASA & space community
• Automotive sector
• Medical device sector
• “Silicon Valley” (Apple, Google, SpaceX, …)
44
22
12/18/2018
Fitting the Practice to Business Needs: Begin with Your End in Mind
45
MBSE in Practice: An Illustrated Walkthrough From requirements to V&V
46
23
12/18/2018
SE Activities Timeline – Top Down
0. Define Need & System Concept
Activity bars represent movement of “center of gravity” of systems engineering team. Concurrent engineering is assumed.
1. Capture & Analyze Orig. Requirements 2. Define System Boundary
3. Capture Originating
Architecture Constraints
4. Derive System Threads
5. Derive Integrated System Behavior
6. Derive Component Hierarchy
7. Allocate Behavior to Components
SCHEDULE
8. Define Internal Interfaces
9. Select Design
10. Perform Effectiveness & Feasibility Analyses
11. Define Resources, Error Detection, & Recovery Behavior
12. Develop Validation Requirements/Validation Plans
13. Generate Documentation and Specifications
47
SE Activities Timeline – Reverse Engineering
8. Update System Boundary
then modify top-down.
Find the top,
7. Derive As-Built
6a. Modify System Threads 7a.Modify Reqts & Arch. Constraints
System Requirements
6. Derive As-Built System Threads
5. Aggregate to As-Built System Behavior
5a. Modify & Decompose System Behavior
4. Derive As-Built Behavior of Components
4a. Allocate Behavior to Components 3a. Refine Component Hierarchy
3. Capture Component Hierarchy 2. Capture Interfaces
2a. Define Interfaces
SCHEDULE
1. Define System Boundary
9. Select Design
10. Perform Effectiveness & Feasibility Analyses
11. Capture Error Detection, Resource, & Recovery Behavior
12. Develop Test Plans
13. Generate Documentation and Specifications
48
24
12/18/2018
A Roadmap for Our Example
• Capturing the requirements • Defining the system logic • Implementing the system logic • Testing 1,2,3
49
WWI Image Management System
IMAGE COLLECTORS
CUSTOMER (HQ)
INTERFACE
INTERFACE
IMAGE PROCESSING SYSTEM
50
25
12/18/2018
A Modern Reimplementation: Geospatial Library
COLLECTOR
CUSTOMER
SYSTEM
51
Our Requirements for the Geospatial Library
52
26
12/18/2018
Tackling the First Layer
Dgn V&V
BEH
REQ
ARCH
Level Of Detail
Source Documents
Docs
LEVEL 1
Dgn V&V
BEH
REQ
ARCH
Docs
Docs
LEVEL 2
Dgn V&V
BEH
REQ
ARCH
Docs
Docs
LEVEL n
53
Capturing the Requirements The requirements domain
54
27
12/18/2018
Where Do You Find Requirements?
• System Concept Paper • Executive Order • Concept of Operations • Statement of Work • Vendor Package/Contract • Preliminary Specification
• Change Request Trade Study Report • Standards (MIL-STD or Commercial) • Meeting Minutes
• Business Plan • Market Analysis
55
Desired Characteristics of Requirement Statements
• Necessary – remove it if the statement is not needed • Implementation independent – state what is required, not how the requirement is met • Unambiguous – generates a common understanding • Complete – can be understood in isolation
• Singular – addresses one thought • Feasible – is inherently possible • Verifiable – can confirm the requirement is satisfied • Correct – properly expresses the stakeholder expectation • Conforming – conforms in look and feel to organizational standards
Additional information available in INCOSE Guide for Writing Requirements
56
28
12/18/2018
Desired Characteristics of Requirement Sets
• Complete – represents the full definition of the stakeholder expectations • Consistent – reconciled and individual statements do not conflict with one another • Feasible – can be satisfied by a solution that is obtainable within life cycle constraints • Bounded – establish the system scope and do not address subjects outside that scope • Structured – organized such that sub-sets of requirement statements can be identified
Additional information available in INCOSE Guide for Writing Requirements
57
Our Requirements for the Geospatial Library
58
29
12/18/2018
Beginning Requirements Analysis with Requirements Capture
• Decompose originating requirements to single testable statements • Capture test requirements as validation requirements • Extract/decompose requirements – do not edit • Take care to not change the meaning of the requirements • Provide traceability from the source document to the parent originating requirements • Provide traceability from each parent requirement to its children
59
The Thinking Dimension to Requirements Capture, Part I: Concerns
• Problems which require a resolution
• Unclear or incomplete requirements • Contradictory requirements • Requirement for unlikely system performance • Over- or under-specified requirements
• Traced to the source • Mapped to the solution • Critical aspect of your design history
60
30
12/18/2018
The Thinking Dimension to Requirements Capture, Part II: Risks
• Problem which requires a mitigation plan • Uncertainly of achieving a product or program milestone • Reasons • Budget or schedule • Complex technology • New designs or concepts • Criticality • Resolution captured by mitigation plan • Tracked until reduced or resolved
61
Visualizing Requirements Traditional and SysML representations
62
31
12/18/2018
Requirements in Context
Color Code
elicits
Requirement
Use Case
Requirement Element
Functional Element
elaboratedby
refinedby
basedon / specifiedby
verifiedby
specifiedby
includes/ extends/ kindof
Physical Element
Interface Element
Verification Requirement
verifiedby
Verification Element
Other Element
fulfilledby
involves/ describes
executedby
Verification Event
Resource
employs
includes
Test Configuration
Test Activity
captures/ consumes/ produces
formedby
Test Procedure
decomposedby
Component
Function
performs
incorporates
exhibits
exitsby
built from / kindof
exposes
decomposedby
joined to
State
enters
exitedby
inputs/ outputs/ triggeredby
Exit
Interface
Port
decomposedby
includes
comprisedof
Event
Transition
responsible for
connectsto
triggeredby
Link
Item
transfers
includes
decomposedby
constrains/ usesparameter from
generates
results in
causes
assignedto
Organization
Constraint Definition
Concern
Risk
63
Hierarchy Diagrams
• Classic representation of relationships between several layers of objects • Most frequently used to represent composition or traceability • Nodes represent objects • Numbers and names standard • Object type often shown if diagram includes multiple types • Lines represent relationships • Implied flow based upon culture • Minimal symbology • Upper-left block - additional detail hidden • Upper-right block – entity repeated • “Generic visual query” • Represent any relationship set
64
32
12/18/2018
hierSpecificRequirements
R.2
Mapping Requirements Hierarchies
Specific Requirements
refinedby
refinedby
R.2.1
R.2.2
AcceptRequests fromCertified Customers
Retain Inventory andProvide Products
elicits
Requirement
Use Case
elaboratedby
refinedby
basedon / specifiedby
verifiedby
R.2.1.1
R.2.2.1
specifiedby
includes/ extends/ kindof
refinedby
refinedby
AcceptRequests
Retain Inventory
Verification Requirement
verifiedby
fulfilledby
involves/ describes
R.2.1.3
R.2.2.2
executedby
Verification Event
refinedby
refinedby
ValidateCertified Customers
Provide Products
Resource
employs
includes
Test Configuration
Test Activity
captures/ consumes/ produces
formedby
Test Procedure
decomposedby
Component
Function
performs
incorporates
exhibits
exitsby
built from / kindof
exposes
decomposedby
joined to
State
enters
exitedby
Level of Detail: Low Audience: General
inputs/ outputs/ triggeredby
Exit
Interface
Port
decomposedby
includes
comprisedof
Content: Names and relationships Use: Multi-level decomposition of requirements; traceability
Event
Transition
responsible for
connectsto
triggeredby
Link
Item
transfers
includes
decomposedby
constrains/ usesparameter from
generates
results in
causes
assignedto
Organization
Constraint Definition
Concern
Risk
65
Requirements Diagrams
• Expand classic hierarchy diagram to represent key aspects of requirements • Graphical format often complemented with tabular representation • Usage largely limited to providing context for a few requirements
66
33
12/18/2018
Key Semantics of Requirements Diagrams
reqAcceptRequests fromCertifiedCustomers
• Nodes represent objects
<
AcceptMedia of Requests
The systemshallaccept requests via any of the followingmedia: 1) Hardcopy Forms; 2)Verbal; 3)Phone-verbal; 4) Phone-electronic file; 5) Web-based electronic file.
<
• Type, name, and description standard
<
AcceptRequests
• Lines represent relationships •
The systemshallaccept information requests.
< AcceptRequests < Verify:The systemshall accept intelligence data collection requests fromthe certifiedusers. < < < For validated customer certification, the system shall format the customer's request into a common form for subsequent systemuse. Rejected requests shallbe returned to the customer and rejectionmetrics prepared. < < ValidateCertifiedCustomers The systemshallvalidate the customer's certification to order imagery products. < The systemshallprepare the customer's certification disapprovalnotification. The certificationdisapproval notification shall include the customer's order identifier, the customer's identifier and the reason for the certificationdisapproval. < Additional information available in Chapter 13 of A Practical Guide to SysML 67 reqAcceptRequests fromCertifiedCustomers < < < The systemshallaccept requests via hardcopy forms. Mapping Requirements Diagrams AcceptMedia of Requests < AcceptRequests The systemshallaccept requests via any of the followingmedia: 1) Hardcopy Forms; 2)Verbal; 3)Phone-verbal; 4) Phone-electronic file; 5) Web-based electronic file. < The systemshallaccept information requests. < Media of Requests:Verbal < The systemshallaccept verbal requests. < < For validated customer certification, the system shall format the customer's request into a common form for subsequent systemuse. Rejected requests shallbe returned to the customer and rejectionmetrics prepared. < < The systemshallaccept requests via telephone. elicits Requirement Use Case < elaboratedby < < ValidateCertifiedCustomers < The systemshallvalidate the customer's certification to order imagery products. < The systemshallaccept requests via telephonic electronic file. refinedby basedon / specifiedby verifiedby specifiedby includes/ extends/ kindof The systemshallprepare the customer's certification disapprovalnotification. The certificationdisapproval notification shall include the customer's order identifier, the customer's identifier and the reason for the certificationdisapproval. < < < Verification Requirement The systemshallaccept requests via via aWeb service. verifiedby fulfilledby involves/ describes executedby Verification Event Resource employs includes Test Configuration Test Activity captures/ consumes/ produces formedby Test Procedure decomposedby Component Function performs Level of Detail: Medium Audience: System/software engineers Content: Names, relationships, and descriptions Use: Limited (toy representation); context for limited set of requirements incorporates exhibits exitsby built from / kindof exposes decomposedby joined to State enters exitedby inputs/ outputs/ triggeredby Exit Interface Port decomposedby includes comprisedof Event Transition responsible for connectsto triggeredby Link Item transfers includes decomposedby constrains/ usesparameter from generates results in causes assignedto Organization Constraint Definition Concern Risk 68 34 12/18/2018 Additional Requirement Views Level of Detail: High Audience: General Content: Requirement properties and relationships Use: Requirement lists; traceability matrices; verification matrices Tables Level of Detail: High Audience: General (including contract officers) Content: System or subsystem requirements Use: Textual representation of requirements – generally compliant with a specific document format – used for milestone reviews and transmission across contractual boundaries Specifications 69 Bridging to and from Requirements: Use Case Diagrams • Describe the functionality of a system from the user perspective • Elicit requirements from stakeholders • Bridge to (elaborated by) system threads / behavior • Represents use cases, actors, and blocks • Complemented with • Preconditions • Postconditions • Primary flow • Exception flows 70 35 12/18/2018 Key Semantics of Use Case Diagrams: Use Case Relationships • Drawn as ovals within the frame • Inclusion < 71 Key Semantics of Use Case Diagrams: Other Relationships • Actors and blocks • Components involved in use case • Shown in outer ring • Stick figure implies human • Block implies non-human • Subject • System / component described by diagram • Shown as label at top of use case frame Additional information available in Chapter 12 of A Practical Guide to SysML 72 36 12/18/2018 Mapping Use Case Diagrams elicits Requirement Use Case elaboratedby refinedby basedon / specifiedby verifiedby specifiedby includes/ extends/ kindof Verification Requirement verifiedby fulfilledby involves/ describes executedby Verification Event Resource employs includes Test Configuration Test Activity captures/ consumes/ produces formedby Test Procedure decomposedby Component Function performs Level of Detail: Low Audience: General Content: Use cases and corresponding actors (components) Use: High-level tool to elicit requirements; bridge from requirements to system threads incorporates exhibits exitsby built from / kindof exposes decomposedby joined to State enters exitedby inputs/ outputs/ triggeredby Exit Interface Port decomposedby includes comprisedof Event Transition responsible for connectsto triggeredby Link Item transfers includes decomposedby constrains/ usesparameter from generates results in causes assignedto Organization Constraint Definition Concern Risk 73 Defining the System Logic The behavior domain 74 37 12/18/2018 System Behavior • Shows what a system does or appears to do without regard to how (implementation) it does it • Is represented graphically by a view integrating the control (functions and constructs) view with the interface (inputs and outputs) view Behavior is essential for providing the complete systems engineering perspective for any system or process 75 Why Behavioral Analysis? Why not Stop with Function Identification? • Classical functional analysis results in function lists / trees • Necessary, not sufficient • Incomplete sequencing of functions • Incomplete definition of items and functional interfaces • Missing performance allocation (or lacking in defensibility) hierGeospatialLibrary Context Function - Level2 C Geospatial Library Context Function - Level2 1.1 1.5 1.7 2.2 2.4 2.6 2.8 Report DeficienciesAnd Recommendations Generate Performance Report NotifyUserOf Estimated Schedule Accept And FormatCollector Products Accept And FormatRequest Get Product From Inventory PrioritizeRequest 1.4 1.6 2.1 2.3 2.5 2.7 1.3 Evaluate Products vs. Request Notify Customer ofDisapproval CheckProduct Inventory Determine CollectorMix Put Product In Inventory Provide Product ToCustomer TaskCollectors Behavioral analysis more difficult, more time consuming, but more complete. Perform the required analysis now, or wait until integration & test to find the problems. 76 38 12/18/2018 A Complete Set of Executable Constructs (Structured Representations) 1 2 2 DomainSet Exit X 1 FunctionA FunctionB FunctionB 1 IT IT FunctionA OR FunctionA SEQUENCE 3 Exit Y ITERATE FunctionC 1 MULTIPLE-EXIT 1 FunctionA FunctionA AND AND 2 OR OR 2 FunctionB FunctionB CONCURRENCY 2 DomainSet With coordination SELECT Function B Status Loop Condition Control 1 Exit X 1 RP RP Function A LP OR LP FunctionA Exit Y LE REPLICATE LOOP 77 A Complete Set of Executable Constructs (SysML Representations) [Exit X] FunctionA FunctionB FunctionA FunctionB FunctionA [Exit Y] FunctionB FunctionC SEQUENCE MULTIPLE-EXIT SELECT [DomainSet] [LoopCondition] [Exit X] FunctionA FunctionA [Exit Y] ITERATE LE REPLICATE LOOP DomainSet [With coordination] FunctionA FunctionB < Status FunctionB Control FunctionA RP RP CONCURRENCY 78 39 12/18/2018 Items – The Second Dimension of Behavior • Cross the system boundary • Passive things that are inputs and outputs of our system • Can be • Data • Signals • Physical objects System External System input to/ triggers performs performs Item outputs Top-Level Top-Level Function Function Item outputs input to/ triggers 79 Reflecting the Two Dimensions: Functions & Items • Function • A process that transforms inputs into outputs • An action taken by the system or one of its elements • Represented by a verb or verb-noun pair • Data stores • Item that does not provide a control role • Defined by an input to relationship • Shown with a single arrowhead (EFFBD) or with “optional” annotation (activity diagram) • Triggers • Item that provides a control role • Defined by a triggers relationship • Shown with a double arrowhead (EFFBD) or without annotation (activity diagram) • Function enablement • Enabled upon completion of the function prior to it in the sequencing • Function execution • Requires enablement and triggering, if a trigger is defined 80 40 12/18/2018 Building a Bridge to Behavior: Leveraging Use Cases • Describe the functionality of a system from the user perspective • Represent the highest level of functional abstraction for a system • Elicit requirements or bridge to (elaborated by) system threads • Represent the interactions between the system and external “actors” • Emphasizes functionality rather than control or timing • Implicit is the discovery of functional requirements • Should reflect • Pre-conditions • Post-conditions • Primary flow • Exception flows 81 Identifying Geospatial Library Use Cases 82 41 12/18/2018 Capturing Geospatial Library Use Cases uc Operate GeospatialLibrary GeospatialLibrary System Retrieve Existing Product < Deliver Image < extension points Assess Performance in inventory not in inventory Customers < Collect and Deliver New Product < 83 Bridging from Use Cases to Behavior: The Role of Threads • Define distinct classes of threads based on use cases, system I/O, and/or conditions • Start with one thread per use case, class of system input, and/or conditions • Preserve each thread (for thread testing, concept of operations, etc.) 1a. Derive threads t.1.3 t.1.4 t.1.5 t.1.6 t1.Accept& FormatRequest t1.CheckProduct Inventory t1.Get Product FromInventory t1.Provide Product ToUser 1b. Partition threads t.2.1 t.2.2 t.2.3 t.2.4 external t2.Make Information Request t2.Process and ProvideCollected Data t2.Accept Products t2.CollectData AND AND t.2.5 t.2.6 t.2.7 t.2.8 t.2.9 t.2.10 2. Integrate threads to define integrated system behavior system t2.Accept& FormatRequest t2.CheckProduct Inventory t2.Prioritize Request t2.Determine CollectorMix t2.Provide Product ToUser t2.TaskCollectors 10 Provide Product ToUser In Inventory 1 2 9 AcceptAnd FormatRequest CheckProduct Inventory OR Get Product FromInventory AND AND 5 12 NotifyUserOf Estimated Schedule Deficiencies Report DeficienciesAnd Recommendations 3 4 7 8 11 Not in Inventory AcceptAnd FormatCollector Products Evaluate Products vs. Request Determine CollectorMix AND AND Put Product In Inventory OR PrioritizeRequest 6 OK TaskCollectors 84 42 12/18/2018 Thread One: Image in Inventory CUSTOMER SYSTEM CUSTOMER Check Product Inventory Request Image Get Product From Inventory Provide Product To Customer Accept Request 85 Thread One: Image in Inventory effbd t.1 Image in Inventory t.1.1 t.1.2 t.1 Request Image Customer t.1 Accept Image Customer Customer t.1 Information Request t.1 Collection Product Ref. Ref. AND AND t.1.3 t.1.4 t.1.5 t.1.6 sd t.1 Image in Inventory t.1 Accept Request t.1 Check Product Inventory t.1 Get Product fromInventory t.1 Provide Product to Customer System Customer GeospatialLibrary GeospatialLibrary GeospatialLibrary GeospatialLibrary GeospatialLibrary par t.1Request Image t.1AcceptRequest t.1 InformationRequest t.1CheckProduct Inventory Date: University Edition - For Academic Use Only October 12, 2014 t.1Get Product fromInventory t.1Accept Image t.1Provide Product toCustomer t.1CollectionProduct Date: University Edition - ForAcademicUseOnly October 12, 2014 86 43 12/18/2018 Thread Two: Image Not in Inventory Task Collectors Accept & Format Product Put Product In Inventory CUSTOMER SYSTEM CUSTOMER ? Check Product Inventory Request Image Get Product From Inventory Provide Product To Customer Accept Request 87 Thread Two: Image not in Inventory effbd t.2 Image not in Inventory t.2 Request Image Customer t.2 Accept Image Customer Customer t.2 Information Request t.2 Collection Product t.2 Accept Request t.2 Check Product in Inve... t.2 Task Collectors t.2 Accept and Format Product t.2 Put Product in Inventory t.2 Get Product fromInventory t.2 Provide Product to Customer System Ref. Ref. AND AND GeospatialLibrary GeospatialLibrary GeospatialLibrary GeospatialLibrary GeospatialLibrary GeospatialLibrary GeospatialLibrary t.2 Collector Tasking t.2 Collector Data t.2 Process and Provide Collector Data Collectors t.2 Collect Data Collectors Collectors Date: University Edition - For Academic Use Only October 12, 2014 88 44 12/18/2018 Thread Two: Image Not in Inventory sd t.2 Image not in Inventory Customer GeospatialLibrary Collectors par t.2Request Image t.2AcceptRequest t.2 InformationRequest t.2CheckProduct in Inventory t.2TaskCollectors t.2CollectData t.2CollectorTasking t.2Accept and Format Product t.2Process andProvideCollectorData t.2CollectorData t.2Put Product in Inventory t.2Get Product fromInventory t.2Accept Image t.2Provide Product toCustomer t.2CollectionProduct Date: University Edition - ForAcademicUseOnly October 12, 2014 89 Integrating the Threads CUSTOMER In Inventory SYSTEM THREAD 1 Not In Inventory THREAD 2 COLLECTOR 90 45 12/18/2018 Specifying the Integrated System Behavior Customer System Collectors 91 Make Information Request Accept & Format Request Get Product from Inventory Provide Product to Customer Visualizing Behavior Traditional and SysML representations Accept Product 92 46 12/18/2018 Behavior (Logical Architecture) in Context Color Code elicits Requirement Use Case Requirement Element Functional Element elaboratedby refinedby basedon / specifiedby verifiedby specifiedby includes/ extends/ kindof Physical Element Interface Element Verification Requirement verifiedby Verification Element Other Element fulfilledby involves/ describes executedby Verification Event Resource employs includes Test Configuration Test Activity captures/ consumes/ produces formedby Test Procedure decomposedby Component Function performs incorporates exhibits exitsby built from / kindof exposes decomposedby joined to State enters exitedby inputs/ outputs/ triggeredby Exit Interface Port decomposedby includes comprisedof Event Transition responsible for connectsto triggeredby Link Item transfers includes decomposedby constrains/ usesparameter from generates results in causes assignedto Organization Constraint Definition Concern Risk 93 An Integrated Picture of Behavioral Views Concepts Composition Control / Structure Triggering Data Flow Allocation What about • audience? • level of detail? 94 47 12/18/2018 A Minor Detour: State Transition Diagrams • Describe the logical transition of the system through multiple states • Orthogonal to behavior • Alternative approach to analysis / representation • If both are used, states are elaborated / realized by behavior • Represents states, transitions that connect them, and events that trigger transitions • Traditional systems approach included in SysML specification 95 Key Semantics of State Transition Diagrams • States • Shown as rounded rectangles • Indicate state name plus • entry – functions invoked when state entered • exit – functions invoked when state left • do – functions executed while in the state • Transitions • Lines connecting states • Reflect valid transition paths 96 48 12/18/2018 Key Semantics of State Transition Diagrams, cont. • Triggering events for transitions • Guard conditions (in brackets) • Type • Call – EventName (condition) • Signal – EventName (condition) • Change – when condition • Absolute Time – at condition • Relative Time – after condition • Service function for transition • Related behavior shown after triggering event information Additional information available in Chapter 11 of A Practical Guide to SysML 97 stmGeospatialLibrary Mapping State Transition Diagrams TurnOff idle shuttingdown ShutdownConfirmed /ShutDownCameras after 60 s / Display "Timed Out"Status Startup elicits Shutdown [in (loggedon)] / Confirm Shutdown Request Requirement Use Case elaboratedby initializing refinedby basedon / specifiedby verifiedby [init ok] specifiedby includes/ extends/ kindof operating SystemOK [not initOK] Verification Requirement entry/Display "Operating"Status do/OperateGeospation Library exit/Display Status verifiedby fulfilledby involves/ describes Maintenance [in (loggedon)] / Confirm Maintenance Request executedby diagnosing Verification Event SystemOK Resource employs includes maintenance Test Configuration Test Activity captures/ consumes/ produces MaintenanceCompleted formedby Test Procedure decomposedby Component Function performs Level of Detail: Medium Audience: System and software engineers Content: System states and the corresponding transitions Use: Insight into the system by taking an orthogonal look at behavior incorporates exhibits exitsby built from / kindof exposes decomposedby joined to State enters exitedby inputs/ outputs/ triggeredby Exit Interface Port decomposedby includes comprisedof Event Transition responsible for connectsto triggeredby Link Item transfers includes decomposedby constrains/ usesparameter from generates results in causes assignedto Organization Constraint Definition Concern Risk 98 49 12/18/2018 Returning to Behavior: Sequence Diagrams • Emphasize interaction between collaborating parts of a system • Particularly powerful when used in understanding logical threads • Often become overloaded when representing complex logic • Includes lightweight representation of behavioral constructs • Traditional systems approach included in SysML specification • Well understood (and often requested) by software engineers 99 Key Semantics of Sequence Diagrams • Blocks and lifelines • Interacting blocks (components) reflected at the top of the diagram • Lifeline shown as dashed line extending below block • Events • Execution instances of functions involved in the interaction • Represented as nodes on the lifeline to which the function is allocated • Often unlabeled (emphasis on interaction between blocks) 100 50
Made with FlippingBook - professional solution for displaying marketing and sales documents online