MBSE SysML 读书笔记

diagram kind

Model element type

Model element name

Diagram name

elements of definition

element structural relationships

When you perform MBSE activity

conjunction with other SysML diagrams to provide a complementary view

element type

namespace

Block

RelationShip between Blocks

actor

Value Type

Constraint Blocks

displays usages of blocks

convey additional information

IBDs and BDDs provide complementary views of a block.

A BDD letsyou first define a block and its properties. Then you can use an IBD to display a valid configuration of that block—a specific set of connections among the block’s properties.

The only allowable model element type for an IBD is block.

Inside the frame, you can display that block’s part properties and reference properties and the connectors that join them.

IBD has the same meaning as a part property in the parts compartment of a block on a BDD

A reference property on an IBD has the same meaning as a reference property in the references compartment of a block on a BDD

ChildTopic

ChildTopic

ChildTopic

ChildTopic

concisely conveys a set of use cases

suited to serve as a system context diagram

A use case diagram is an analysis tool and is generally created early in the system life cycle.

during the development of the system concept of operations (ConOps)

elicitation and specification stage

during the architectural design stage

The use case gathers those different scenarios together.

A use case is a service—a behavior—that your system will per-form. The use case name, therefore, is always a verb phrase
(such as Send command).

Not every behavior your system performs is a use case. Rather,use cases are the subset of system behaviors that external actors can directly invoke or participate in.

An actor can be a person or an external system that interfaces with your system.

The actors that invoke a use case are called primary actors. The actors that participate in the use case are called secondary actors. A primary actor can also be a secondary actor.

Each use case should represent a primary actor’s goal. Write the use case name—the verb phrase—from the perspective of the actor and not your system.

The use case name does not convey a lot of information. You will create a use case specification for each use case to narrate how your system and its actors collaborate to achieve the use case goal.

Use Cases

System Boundary

actors

Associating Actors with Use Cases

Base Use Cases

Included Use Cases

Extending Use Cases

An activity diagram is a kind of behavior diagram

One of its key advantages is its read­ ability; activity diagrams can express complex control logic better than
sequence diagrams and state machine diagrams.

it often is the first kind of behavior diagram you turn to when you need to
communicate with stakeholders and capture the expected behaviors of the system and its actors.

to communi­cate with other members of your team and capture the expected behav­iors of the system’s internal parts

The only allowable model element type for an activity diagram is activity

Tokek Flow

Actions: The Basics

ob­ject flows

control flows

initial nodes

activity final nodes/flow final nodes

decision nodes

merge nodes

fork nodes

join nodes

Activity Partitions: Allocating Behaviors to Structures

presents a dynamic view of the system

sequences of behaviors and event occurrences over time

the order in which behaviors are performed,

 which structure performs each behavior, 

which structure invokes each behavior

specify the intended interactions between the systemof interest and the actors in its environment

These diagrams are useful early in the architectural design stage to specify the interactions between subsystems.

the end of architectural design to specify the interactions between components in preparation for the handoff to the teams producing detailed designs of components.

sequence diagrams as graphical test case specifications

you can potentially create a sequence diagram at any point in the system life cycle.

The only allowable model element type for a sequence diagram is interaction.

Leftline

Message

Destruction Occurrences

Execution Specifications

Constraints

Combined Fragments

Interaction Uses

A state machine diagram is a kind of behavior diagram

it presents a dynamic view of a system.

how a structure within a system changes state in response to event occurrences over time

to describe the behavior of a block at any level in the system hierarchy (such as the
system of interest itself, a subsystem, or a single component)

States

Final States

Transitions

Regions

model equations and inequalities as constraint blocks

create para­metric diagrams during any stage of the system life cycle.

A package diagram is the kind of diagram you create when you need
to display the organization of the system model.

Package diagrams can display packages nested within pack-
ages to convey the containment hierarchy of the model.

convey information about the structure of the model itself.

crosshair notation

nesting notation

qualified name string notation

model

model library

profile

view

This diagram is particularly valuable when your target audience
needs to see the traceability from the requirements to the elements in
your system model that are dependent on them.

Establishing requirements traceability

to display those relation-
ships at any point during this work.

Requirements

Requirements Relationships

Containment Relationships

Trace Relationships

Derive Requirement Relationships

refine Relationships

Satisfy Relationships

Verify Relationships

Direct Notation

Compartment Notation

Callout Notation

Matrices

Tables

create a «satisfy» dependency from a block to a require-
ment