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.

<> AcceptRequests from CertifiedCustomers The systemshallaccept information requests from certified customers.

<> - partitioning of a complex requirement without adding meaning • <> - more detailed requirement arrived at via analysis • <> - assertion that a model element satisfies the requirement • <> - reference to a test case or verification aspect

<> CheckCertification Response

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.

<> Notify Customer of Disapproval

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

<> Media of Requests: Hardcopy Forms

<>

<>

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.

<> CheckCertification Response

<> Media of Requests:Verbal Telephonic

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

<> AcceptRequests from CertifiedCustomers The systemshallaccept information requests from certified customers.

elaboratedby

<>

<> Media of Requests: TelephonicElectronic File

ValidateCertifiedCustomers

<>

The systemshallvalidate the customer's certification to order imagery products.

<> Notify Customer of Disapproval

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.

<>

<> Media of Requests:Web Services

<>

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 <> • Parent-child relationship between use cases • Child use case at the end of the arrow • Extension <> • Expansion of use case under specific conditions (extension point) • Extension use case at the tail of the arrow • Classification (unfilled arrowhead) • Generalization / specialization relationship between use cases • Specialized use case at the tail of the arrow

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

<> in inventory

Deliver Image

<> GeospatialLibrary System

extension points

Assess Performance

in inventory not in inventory

Customers

<> not in inventory

Collect and Deliver New Product

<> Collectors

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