SysML v2 Views

Overview

A view shows part of the model as a diagram. In a SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 project, each view is a view usage in the model, so it also appears in the text. Every change you make in a view is written into the text at once, as one undo step.

Views open from the same Diagrams list as diagrams in LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. projects, with the same tabs, toolbar, Add panel, inspector and exports. Holarch supports the standard view kinds of the OMGObject Management Group The standards body that maintains UML, SysML, UAF and XMI. SysML v2 specification:

Four more kinds are presets of the General View: Requirement View, Use Case View, Parametric View and Package View. Each is a General View with a filter that names its kind.

Holarch's own analysis diagrams (Spider, Hierarchy, Tree, IDEF0Integration Definition for Function Modeling A function-modeling method: each box is a function, with inputs, controls, outputs and mechanisms on fixed sides., ICOMInputs, Controls, Outputs, Mechanisms The four kinds of arrows on an IDEF0 box, each entering or leaving on its own side. and FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths.) and the Functional Analysis page also work on the model. They are Holarch diagrams, not SysML views: they are not part of the text.

Concepts

A view is part of the model

A view is a view usage typed by a standard view definition. It exposes the elements it shows:

view structure : StandardViewDefinitions::GeneralView {
  expose Vehicles::**;
}

• expose Vehicles::**; shows the package Vehicles and everything it owns. Holarch writes this form for packages and definitions.
• expose Vehicles::Powertrain; shows one element. Holarch writes this form for usages.
• expose VehicleRequirements::**[@SysML::RequirementUsage]; shows only the requirement usages of the package.

Because the view is a model element, it has an owner, a qualified name and a place in the Browser. You can also write or change a view in the Editor; the Diagrams list follows.

Layout is Holarch data

Positions, sizes, folded compartments, colors and zoom are stored with the project, next to the model. They are not SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. text. Layout is kept by element identity, so renaming or editing an element in the text keeps its place in every view.

Presets: a General View with a filter

SysML v2 has fewer diagram kinds than SysML 1.x. A requirement, use case, parametric or package diagram is a General View whose filter names its kind:

view requirementTree : GeneralView {
  filter @SysML::RequirementDefinition or @SysML::RequirementUsage or @SysML::SatisfyRequirementUsage;
  expose VehicleRequirements::**;
}

Other SysML v2 tools read these as standard General Views. Holarch draws them like the matching LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. diagram. Edit the filter in the text to change the kind.

Views and analysis diagrams

How to use it

When and why

Use views to look at the model from the angle a question needs:

• Structure: a General View for definitions and their specializations; an Interconnection View for how the parts of one assembly connect.
• Behavior: an Action Flow View for the order of steps and who performs them; a State Transition View for operating modes; a Sequence View for the messages of one scenario.
• Requirements: a Requirement View for the requirement tree with what satisfies and verifies each requirement; a Use Case View for the actors and goals; a Parametric View to check values against constraints.
• Review: a Grid for tables and matrices; a Package View for how the model is organized.

Write the model in text where that is faster, and switch to a view to see and adjust it. Both edit the same model.

Create a view

1. Open the Diagrams tool at the bottom of the rail.
2. Click + New Diagram.
3. Choose the view kind, for example General View.
4. Under Shows, choose the package or element the view shows. The list has packages first, then definitions, then part, action and state usages, by qualified name.
5. Optionally, type a View name. Without one, Holarch picks a free name.
6. Click Create. The view opens. The text gains a view usage next to the element it shows, for example view structure : StandardViewDefinitions::GeneralView { expose Vehicles::**; }.

The view is owned by the package it shows, or by the package that owns the element it shows.

Open a view

Use any of these:

• Click its card in the Diagrams list. Cards show a picture of the view.
• Open one of the rail's view lists, such as Behavior → Action Flows, and click the view.
• Select an element and choose Open in ▾ in the inspector. The menu lists every view that shows the element, with its kind.
• Click the view's tab under the top bar. Open views stay as tabs, as LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. diagrams do.
• In an open view, click ▲ Parent to open the view of the same kind that shows the owner of what this view shows.

Edit the model in a view

Each view has its own gestures; the common ones are:

1. Drag an item from the Add panel on the left onto the canvas, or focus it and press Enter. A new element is created in the model and shown in the view.
2. Drag from a shape's green dot or handle to another shape to add a relationship. Where more than one relationship fits, a menu lets you choose.
3. Drag a shape into another shape to move the element there (change its owner).
4. Double-click a name, or press F2, to rename.
5. Select shapes and press Delete to delete them from the model. Deleted elements go to the project's Trash, with their members.

Every change is checked first. A change that would make the text invalid is refused with a message, and the model stays as it was. Each accepted change is one undo step.

Worked example: the Hybrid Car demo

Create the demo first: Manage Projects → Project Files ▾ → New Demo Project → Hybrid Car (SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2). It has a view of each kind.

1. Open Diagrams and click vehicleStructure (a General View). You see the part definitions of Vehicles: Component above FuelTank, Engine, Battery and the other components that specialize it, and Car with its parts.
2. Open powertrainConnections (an Interconnection View of Vehicles::Powertrain). You see tank, engine, motor, battery, transmission and controller with their ports, the interfaces fuel, engineShaft, motorShaft and hvBus, and the binding of output to transmission.output.
3. Open driveCycleFlow (an Action Flow View of DriveCycle). You see the steps from the fork split to park, the decision shift and swim lanes for the parts that perform the steps.
4. Choose ▶ Simulate ▾ → Discrete Event. The Simulator runs DriveCycle with the durations written in the model, such as attribute duration : DurationValue = 75 [s]; on drive.
5. Open carSpecTree (a Requirement View of carSpec) and click ▲ Parent. requirementTree opens: the view of the package that owns carSpec.
6. Open sedanParametrics and click Solve All. The dialog shows sedanMassCheck as Pass: the sedan's curbMass of 1580 kg is within maxCurbMass of 1650 kg.
7. Open componentLayout (a Geometry View of sedanLayout) and drag the differential a little to the right. The text of sedanLayout now has a new value for the x of differential.

The demo also has powertrainStateView (State Transition), startUpSequenceView (Sequence), requirementsGrid (Grid), driverUseCases (Use Case) and packageStructure (Package).

Tips and good practice

• Keep views small. Expose one assembly, one action or one requirement tree. A General View above 12 boxes folds its compartments to their headings.
• Name views. A view name such as powertrainConnections reads well in the Diagrams list, the tabs and Open in ▾.
• Put views next to what they show. Holarch does this when it creates a view; keep it when you write views in the text.
• Use presets for reviews. A Requirement View with Arrange ▾ → Tidy Layout shows each requirement with what satisfies and verifies it.
• Use the Grid for many elements at once. It edits Kind, Type, Multiplicity and Value in the cell.

Common mistakes

• Expecting Delete Diagram to delete the elements. It deletes only the view usage and its layout. The elements it shows stay.
• Looking for an analysis diagram in the text. Spider, Hierarchy, Tree, IDEF0Integration Definition for Function Modeling A function-modeling method: each box is a function, with inputs, controls, outputs and mechanisms on fixed sides., ICOMInputs, Controls, Outputs, Mechanisms The four kinds of arrows on an IDEF0 box, each entering or leaving on its own side. and FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths. diagrams are Holarch data, not view usages.
• Deleting a shape to tidy a view. Delete removes the element from the model. To hide a lifeline in a Sequence View, use Remove instead.
• Writing an invalid guard. A guard that is not a valid expression is refused. Write it as an expression, for example speed > 30.

How it connects to other features

• Text and Browser: each view is an element you can open with Show in Text; every view edit changes the text (The Text Editor and Browser).
• Simulator: ▶ Simulate ▾ on an Action Flow View runs the flow (Evaluation, Units and Analysis).
• Requirements and verification: satisfy and verify lines in views are the same relationships the RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. and the Traceability Matrix show (Requirements and Verification).
• Documents and presentations: Insert → Diagram Picture… lists the views; figures show the current view.
• Frameworks: DoDAFDepartment of Defense Architecture Framework The US DoD framework for describing architectures as a set of viewpoints and products, such as OV-1 and SV-1. and UAFUnified Architecture Framework An OMG architecture framework that organizes views in a grid of viewpoints and aspects. It covers DoDAF and NATO needs. diagram products are views of the model (Holarch Features in SysML v2 Projects).

The view editor

Views use the diagram editor of LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. projects (Diagrams). This section lists what differs in SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 projects.

Tabs

Every view and analysis diagram opens as a tab under the top bar. The tabs stay open per project. A tab closes when its view is deleted.

▲ Parent

▲ Parent opens the nearest other view of the same kind that shows an owner of what this view shows. It appears only when such a view exists.

In the demo, carSpecTree shows the requirement carSpec. Its ▲ Parent opens requirementTree, which shows the package VehicleRequirements that owns carSpec.

Problems button

The problems button in the top bar (the warning icon with a number) works as in LML projects. It counts suspect links, overdue TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date./TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed. items, failing tests, TPMTechnical Performance Measure A key technical parameter, such as mass or power, tracked over time against its target and threshold. breaches, high risks and model check findings. Click it to list them; click an entry to open its page. In SysML v2 projects the list has only pages that SysML v2 projects offer. Open Home is at the end of the list.

Add panel

The Add panel on the left lists the items the view can create. Each view's items are listed in its section below.

• Drag an item onto the canvas, or into a shape to create it there.
• Or focus the item and press Enter to add it to the selected shape.
• Each addition is one undo step and is written into the text.

In the analysis diagrams and the Geometry View, the Add panel also finds existing elements. Type in Add or find…:

• Create "name" as … creates a new element with that name.
• Below, the matching model elements are listed with their kind. Each row shows its owner path under it, such as Vehicles::Car::body, so same-named elements can be told apart.
• Type part of the path to narrow the list, for example Car::body.

Inspector

Select a shape or a line to show it in the SysML v2 inspector: kind, name, short name, type, multiplicity, value, documentation, owner and relationships. Open in ▾ lists Text, Browser, every view that shows the element, the Simulator for an action with a flow, and the analysis diagrams of the element. See The Text Editor and Browser for the inspector.

Duplicate, export and delete

• Duplicate: from the card menu. The Duplicate dialog asks for the Name of the copy. The copy is a new view usage with the same exposes and the same layout.
• Export…: the Export dialog with Diagram (PNG), Diagram (SVG), Diagram (HTML), Diagram (Word) and Diagram (Print), as for LML diagrams (Export and print). A Grid view uses the exports of the Database table and the Traceability Matrix instead.
• Delete Diagram: deletes the view usage and its layout after a confirmation. The elements it shows stay. Restore it from the Trash, or undo.

General View

A General View draws the exposed definitions and usages as boxes with compartments, and packages as containers.

What it shows

• Boxes: each definition or usage, with compartments for its attributes, ports, parts, actions and other members. A requirement shows its text.
• Lines: specialization, typing, composition, reference, «satisfy» and «verify».
• Layout: in ranks. Wholes sit above their parts, and general definitions above their specializations. A definition that many others specialize goes below them. Lines from one box share a trunk.
• Compartments: above 12 boxes they fold to their headings. Turn on Compartments in the toolbar to show them all, or click a heading to fold or show one. Boxes you have not moved are laid out again when their size changes.

Add panel

Package, Part Definition, Part, Port Definition, Port, Attribute Definition, Attribute, Item Definition, Interface Definition, Action Definition, Action, Requirement Definition, Requirement, Verification Case and Enumeration Definition. Drop onto a package to create the element in it.

Relate two elements

Drag from a box's green dot to another box. The Relate as menu lists the relationships that fit:

Toolbar, menus and gestures

• Delete: deletes the selected elements from the model; they go to the Trash.
• Format tools and alignment, as in LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. diagrams.
• Frame: shows the SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. frame with its heading.
• Compartments: shows or folds every compartment.
• Arrange ▾: Collapse All Compartments, Expand All Compartments, plus the host's Tidy Layout and Restore Defaults.
• Right-click a box: Rename (F2), Show in Text, Expand Compartments or Collapse Compartments, Delete….
• Right-click a line: Remove Relationship.
• Relationship ▾: select a line, then choose what it is between the same two boxes. A composition or reference line becomes Composition, Reference or Specialization; a specialization line becomes a Composition or Reference feature typed by the general; a satisfy or verify line becomes Satisfy or Verify. The change is one undo step in the text. A kind that is not valid, or that would add an error, is refused with the reason, for example "Attribute features cannot be composite: they are always references."
• Drag a box into a package to move the element there.

Interconnection View

An Interconnection View shows the inside of one part definition or usage. It uses the engine of the LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. Internal Block Diagram.

What it shows

• The frame is the border of the exposed part. Its own ports sit on the frame.
• Parts: the part's own parts, then those of its definitions, nested to the chosen Depth. Parts are placed in columns along their connections (Holarch tries a few arrangements, such as a power or data hub on the left with the parts it serves on the right, and keeps the one whose lines cross least), each level with what it connects to, and sized to their names and ports. A part linked only to the frame joins an end column. Frame ports bound to a part in a middle column sit on the top or bottom of the frame.
• Ports sit on the side of a part that faces what they connect to. Their labels (name : type) sit inside the part, beside the port, below the part's name; the frame's ports are labelled inside the frame, above their line. A part nested deeper shows only the port name; point at a port to see its type.
• Lines: connections (labelled with name and type), interfaces (thicker), bindings (dashed, with =) and item flows («flow» and the item, filled arrowhead). Lines run around the parts they do not belong to, each in its own lane, and a connection's name sits on a free stretch of its line. The gaps between columns widen with the number of lines that pass through them.

Add panel and gestures

• Add panel: Part (on the diagram or into a part), Port (onto a part) and Item. Holarch asks for a name.
• Connect: drag from a port's handle to another port. The drop zones are Interface : <interface def> (when an interface definition fits both ports), Connection, Binding and Flow. Flow asks for the item: choose it and click Add Flow.
• Nest: drag a part into another part to move the usage there.
• Delete: asks to confirm, then deletes the element and its members. Deleting an inherited part deletes it from its definition, so it disappears from every usage of it.

Toolbar

• Depth − n + and All: how many levels of nested parts to show (3 by default).
• View ▾: Item Flows and Inherited Parts and Ports, each shown or hidden.
• Interface Register: the connections and interfaces on the view with their status, owner, items and capacity check, as on the LML Internal Block Diagram.
• Relationship ▾: select a line and make it a Connection, Interface, Flow or Binding with the same ends. Its type (a connection or interface definition) and a flow's item are removed. An interface needs ports at both ends, and a binding has no members; other kinds that would add an error are refused with the reason.
• Delete, Frame and Arrange ▾, as in LML diagrams. Arrange ▾ → Tidy Layout returns every part and port to the automatic layout; Restore Defaults also resets the depth and the View ▾ settings.

Action Flow View

An Action Flow View shows how an action runs: its steps, the order between them, the items that flow between their parameters, and which part performs each step. It exposes an action definition or usage.

What it shows

• The frame is the exposed action. Its parameters are pins on the frame border.
• Actions are rounded boxes with their parameters as pins: in on the left, out on the right. The parameters of their definitions are included.
• Control nodes: start (filled circle), done (ringed circle), fork and join bars, decision and merge diamonds, accept and send actions, and loops (while).
• Successions are arrows. A guard shows in brackets; an unguarded succession after a decision is [else].
• Flows are green arrows between pins, labelled with their item.
• Swim lanes come from perform (and allocate): a part that performs actions of the flow gets a lane with those actions.

Add and connect

1. Use + Action ▾, or drag from the Add panel: Action, Accept Action, Send Action, Loop (while), Fork, Join, Decision or Merge.
2. Drag from the green dot of a node to another node to add a succession ("first this, then that").
3. Drag from one pin to another to add a flow.
4. Select an action and choose + Parameter ▾ → Input (in) or Output (out). With nothing selected, the parameter goes to the exposed action.

Guards, loops and lanes

• Select a succession to set its guard; double-click it to type one.
• Select a loop to edit its condition.
• Drag an action into a lane to make that part perform it. Drag it out of every lane to remove the perform.
• + Lane, or Swim Lane in the Add panel, adds an empty lane for a part.

Toolbar

• + Action ▾, + Parameter ▾, + Lane.
• Delete: removes the selection with the successions, flows and performs that name it.
• Rename (F2).
• Format tools.
• Layout: lays the flow out again (one undo step).
• ▶ Simulate ▾: Discrete Event or Monte Carlo opens the exposed action in the Simulator (Evaluation, Units and Analysis).
• Generate Parts View: creates a view of the parts that perform (or are allocated) the actions of the flow and opens it. When one part contains them all, it is an Interconnection View of the innermost such part; otherwise a General View of the parts. The view is named after the action, such as driveCyclePerformers, and one undo step removes it.

Positions are kept when you edit the text.

State Transition View

A State Transition View shows a state definition or usage with its states and transitions. It uses the engine and shapes of the LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. State Machine Diagram.

What it shows

• States are rounded boxes with an entry / do / exit compartment.
• Composite and parallel states enclose their substates. A parallel state's substates are its regions, drawn with dashed borders.
• Initial state: the dot. It comes from entry; then off;.
• Final state: the bullseye, for a transition to done.
• Transitions are open arrows labelled trigger [guard] / effect. Shorthand transitions such as accept StopRequest then off; start at the state they follow.

Add panel and gestures

• Add panel: Initial State (onto the state the machine starts in), Final State (onto the state it ends after), State, Parallel State, Region (onto a parallel state), Entry Action, Do Action and Exit Action (onto a state).
• Drag a state into another state to move it. The shorthand transitions that follow it move with it.
• Drag from a state's handle to another state to add a transition.
• Select a transition to edit it in the side panel: Name, Trigger, Guard and Effect, plus Show in Text and Delete. An initial transition has only Guard.

Toolbar

Depth − n + and All (3 levels by default), Delete, Frame and Arrange ▾.

Sequence View

A Sequence View shows the messages of one scenario in order. It exposes an occurrence, part or action definition or usage. It uses the drawing and gestures of the LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. Sequence Diagram.

What it shows

• Lifelines: the parts and ports of the exposed element.
• Messages: its message and flow usages between them, as horizontal arrows.
• Order: the first m1 then m2; successions between messages, then the order of the members.

Add and edit

1. Drag Lifeline (part) or Lifeline (port) from the Add panel to add a new part or port of the subject as a lifeline. Or click + Lifeline.
2. Drag one of the subject's parts from the Add panel to show its lifeline (✓ marks shown ones).
3. Drag from one lifeline to another to add a message. Or drop Message between two lifelines: the left one sends it to the right one. The text gains message m1 from a to b; and the succession that puts it in place.
4. Drag a message up or down to reorder it. Drag a lifeline head sideways to reorder the lifelines.
5. Select a message to edit Name, Payload, From and To in the side panel, with Inspect, Show in Text and Delete.

Toolbar and Arrange

• + Lifeline.
• Remove: hides the selected lifeline from this view. The part stays in the model; drop it from the Add panel to show it again.
• Delete: deletes the selection from the model.
• Arrange ▾ → Reset Lifeline Order and Show All Lifelines.

Lifeline order and hidden lifelines are Holarch data.

Grid view

A Grid view is the Database table or the Traceability Matrix of the exposed elements. Switch with Table and Matrix. The setting is kept with the view.

• Scope: the view's exposes. A metaclass filter such as expose VehicleRequirements::**[@SysML::RequirementUsage]; becomes the class filter.
• Table: the Database's filters, column chooser, inline editing, inspector, right-click menu and exports. Kind shows the element's kind as the class badge (Holarch items show their class); Owner is the qualified name of the owning element, which tells same-named usages apart. The Type, Multiplicity and Value columns edit in the cell: double-click or press Enter.
• Views pane: saved views and built-in views: Recently changed, Most connected, Requirements without a verification case, Unsatisfied requirements, Parts without ports, Untyped usages, Unresolved names, Unnamed elements, Suspect links, Open TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date./TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed., Model check findings and Unresolved comments. Unnamed elements lists elements without a name, such as an action in a succession, by kind and owner; other lists leave them out. Unnamed redefinitions (is:redefinition) lists a variant's unnamed parts, ports and items that redefine inherited ones (part :>> battery;); the other lists leave them out too, except the issue views (suspect links, TBD/TBR, findings, comments). Their Owner ends in :>> battery. Attribute redefinitions stay in the lists because they carry the variant's values.
• Matrix: the Traceability Matrix tools (Requirements and Verification).

Requirement, Use Case, Parametric and Package Views

These four presets are General Views drawn like the matching LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. diagram, with the same Add panel and connect handles. Arrange ▾ → Tidy Layout lays a preset out again:

• requirement trees with each satisfying, verifying or derived element under its requirement;
• use cases in two staggered columns in their subject, with actors on the side of most of their use cases;
• each constraint's bound values below it.

Requirement View

• Requirements show their id (short name), text (doc) and subject. Nested requirements hang under their owner. Attributes ▾ chooses Id, Text, Subject and Attribute Names.
• Lines:
  • «satisfy»: satisfy carSpec by fleet.sedan;
  • «verify»: a verification case's objective verify carSpec.sedanMass;
  • «deriveReqt»: a connection typed by RequirementDerivation::Derivation, such as connection batteryMassDerivation : Derivation connect carSpec.sedanMass to batteryMassLimit; (also written #derivation connection)
  • «refine»: #refinement dependency commute to carSpec.sedanRange;
• Add panel: Requirement (onto a requirement: nested and numbered after it), Requirement Definition, Part (onto a requirement: the part satisfies it) and Verification Case (onto a requirement: the case verifies it).
• Connect: drag a handle from one shape to another and choose Containment (owned member), «deriveReqt» (derivation connection), «refine» (refinement dependency), «satisfy» (satisfy … by) or «verify» (verification objective).
• Relationship ▾: select a «satisfy», «verify», «deriveReqt» or «refine» line and choose another of these kinds. The old relationship is replaced by the new one between the same elements, as one undo step. Kinds that are not valid between them are refused with the reason: satisfy needs a feature that is not a requirement, verify a verification case, and a derivation two requirement usages.

Use Case View

• Use cases are ellipses inside the boundary of their subject (subject car : Car;). A use case usage takes its definition's subject.
• Actors: each actor definition is one stick figure, joined to the use cases it takes part in (actor driver : Driver;).
• Lines: «include» (include use case startCar : StartCar;) and generalization (a use case definition that specializes another). SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 has no extend relationship; a use case that specializes another plays that part.
• Add panel: Use Case (into a subject: it gets that subject), Actor (onto a use case: it takes part) and Subject (onto a use case).
• Connect: drag from an actor to a use case to add the actor, or between use cases for «include» or Generalization (specializes).
• Relationship ▾: select an «include» or generalization line and change it to the other kind. An «include» needs a use case definition as its target; a generalization relates two use case definitions.

Parametric View

• Constraints show their expression (their own or their definition's). Parameters are pins on the constraint's bottom edge, labelled with their values.
• Bindings: a parameter whose value names a feature, in mass = fleet.sedan.curbMass;, is bound to it. The value appears in its part, or on its own for a package-level value such as maxCurbMass.
• Status: values and Pass / Fail come from the model's evaluation with units. Needs input means a parameter has no value yet.
• Solve All: checks every constraint with units, computes a value an equation defines (q == s * s) and solves a single unknown. The Solve All Constraints dialog previews the values to write (Value, Parameter, Current, New, How: Computed or Solved for input) and each constraint's state. Click Apply n Changes to write them as one undo step.
• Solve: the same for the selected constraint (Solve Constraint).
• Only values that are numbers (or empty) are written; a value that is an expression stays.
• Add panel: Constraint, Parameter (onto a constraint), Part and Value.
• Bind: drag from a parameter to a value. The parameter's value becomes the value's name. Delete on a binding line removes the value from the parameter.

Package View

• Packages nest by ownership and show their members. Turn off Members in the toolbar to hide them.
• «import» lines show what each package imports.
• Drag a package or member into another package to move it.
• Drag a handle from one package to another for «import» (private import ::*) (private import Other::*;) or Containment (owned member).

Geometry View

A Geometry View draws a part's parts in 2D, at the place and size their attributes give. It exposes one part: view componentLayout : GeometryView { expose VehicleViews::sedanLayout; }.

What it shows

• A part is drawn as a rectangle when it has the attributes x, y, width and height. They are lengths in m, cm or mm; a plain number is metres.
• Redefining inherited attributes works too: attribute :>> x = 1 [m];.
• x and y are measured from the top left corner of the nearest placed part that owns the part (else the view's origin), with y downward.
• 1 m is 200 px at 100 % zoom. The bar under the drawing shows 1 m.
• Parts without the four values are listed under the drawing as Not placed (no x, y, width and height). Place adds them.

part redefines frontAxle {
  attribute x = 1.0 [m]; attribute y = 0 [m]; attribute width = 0.65 [m]; attribute height = 1.8 [m];
}

Edit

• Drag a part to change x and y. Drag a corner to resize it.
• Arrow keys move the selected part by 1 cm; with Shift, by 10 cm.
• The values are written in the units they already use, as one undo step.
• Add panel: drag Part onto the drawing for a new part with x, y, width and height where it is dropped (inside the part it is dropped onto). Or press Enter to add it to the selected part.
• Type in Add or find… to create a part with that name, to add a part typed by an existing part definition, or to place a part that has no values yet.

Analysis diagrams

Holarch's analysis diagrams work on the model of a SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 project, with the same engines and look as in LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. projects (Other Diagrams). They are kept with the project under their root element. They are not view usages and do not appear in the text. Their layout is yours to arrange; what they show always comes from the model.

Selecting a node or block shows the SysML v2 inspector. Deleting one deletes the element from the model; it goes to the project's Trash. The LML palette and Remove (from the diagram) for decomposition links are not shown. ▲ Parent opens the same diagram of the element's owner (a part's owning part, or its package). Double-click an element, or choose Open Entity View in its menu, to open its Entity View.

Open one

• Click + New Diagram in the Diagrams list, choose the diagram type and the element it starts from.
• Or select an element in a view, the Browser or a list and choose Open in ▾ → Spider Diagram. Hierarchy Diagram and Tree Diagram are listed where the element has members; FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths. and IDEF0Integration Definition for Function Modeling A function-modeling method: each box is a function, with inputs, controls, outputs and mechanisms on fixed sides. Diagram where it has steps.
• The Browser row menu has Show in Spider Diagram.
• Behavior → FFBD and Architecture → Hierarchy list those diagrams.
• The Diagrams list also offers a derived Hierarchy Diagram of every definition with members (part, action or requirement definitions owned by a package) until you open or delete it.

Spider Diagram

The element is in the centre with everything related to it, out to the Level.

• Relationships: owns, typed by, specializes, subsets, redefines, connected to, satisfied by, verified by, performs, allocated to, flows to and depends on. Relationships… chooses the kinds it follows.
• + on a node shows that node's neighbours.
• Add a relationship: drag from a node's dot to another node, or use + Add Related…. Only relationships the model can hold are offered: typed by, specializes, satisfy, verify, allocate, dependency, connection and ownership. The relationship is written into the text.
• Add panel: every kind. The new or existing element is related to the selected node (or the centre). Choose the relationship: owns, typed by, specializes, subsets, satisfied by, verified by, allocated to or depends on.

Hierarchy and Tree Diagrams

They show the decomposition: a part's parts, an action's actions, a requirement's requirements, and a package's packages, definitions and top-level usages.

• A usage with no members of its own shows its definition's. part powertrain : Powertrain shows the parts of Powertrain.
• + Add Child adds a usage.
• Drag a node onto another to move the element there.
• Add panel: the kinds of the decomposition (a part: Part; an action: Action; a package: Package, definitions and usages). A new element becomes a member of the node it is dropped on; an existing element moves there. On a Tree, drop it on a node.

IDEF0 and ICOM Diagrams

An action's steps are boxes A1, A2, …. In the + New Diagram list the ICOMInputs, Controls, Outputs, Mechanisms The four kinds of arrows on an IDEF0 box, each entering or leaving on its own side. diagram is ICOM (A0) Diagram.

• + Action adds a step.
• Generate ▾ → Generate Parts View…: previews the parts that perform the action and its steps, then creates an Interconnection View of the part that contains them all (else a General View of the parts) and opens it, as Generate Asset Diagram does in LML projects.
• Generate ▾ → Generate Requirements… (on the IDEF0 Diagram of a step): previews and creates a requirement per input, control, output and step, worded for the part that performs the step ("The Engine shall accept Fuel."). They are requirement usages in the package of the document <part> Requirements, under the sections Input Requirements, Output Requirements and Functions, satisfied by the step and traced to the part. Running it again updates them.
• Add panel: Action (Step) adds a step; an action definition from the search becomes a step typed by it. Parameter dropped on a step's top side is a Control (in attribute), on its left side an Input (in item), on its right side an Output (out item); an item or attribute definition from the search types it. Part (Mechanism) adds a part that performs the step; drop an existing part to have it perform the step.

FFBD

The action's steps in their order: successions as arrows, forks and joins as AND, decisions as OR (with their guards), and loops with LP. Edit it as in LML projects (The FFBD diagram): the Add panel, drop points, lines and Delete. Each change is written into the model and the text as one undo step.

• Add panel: Action, AND, OR and LP, the steps of the action and the action definitions. An action definition becomes a step typed by it; an action usage from elsewhere moves into the action.
• AND adds a fork and a join; OR adds a decision and a merge, with the probabilities split evenly; LP adds a while loop.
• A line back to an earlier step is a succession back to it: a loop.
• Delete takes a step out of the flow. It stays in the model without successions and is listed under Not in the flow in the Add panel. To delete the step itself, use Delete from Model… in the inspector; it goes to the project's Trash.
• Edit Flow… opens the Action Flow View that shows the action.

The FFBD is a Holarch diagram, not a SysML view: it is kept with the project and does not appear in the text.

Functional Analysis

The Functional Analysis page works on the model's actions (Functional Analysis).

1. Open Behavior → Functional Analysis.
2. Click Choose… and pick the top-level function: an action definition or usage. Its functions are its action usages, numbered by their short names.
3. On the Functions tab, edit IDs, names and the requirements each function satisfies (a satisfy in the model).
4. Tick Subsystem to see the parts that perform each function (perform or allocate).
5. Open Flow & FFBD to see the flow as an FFBD. The flow is the order of the steps in the model: successions, forks and joins (AND), decisions (OR) and loops. To change it, click Edit as Text… or Edit on the Action Flow View, edit the FFBD, or edit the model text. The structured flow editor of LML projects is not shown.

Tables, Coverage and the Word report work as in LML projects.

Edit the flow as text

Edit as Text… opens the flow dialog of LML projects with the same notation (Functional Analysis): steps joined with ->, AND( a | b ), OR( a | b ) and LOOP( … ), with a live FFBD preview. ✦ AI ▾ → Suggest Flow with AI… opens the same dialog with the suggested flow and the changes to the current one.

1. Click Edit as Text…. The text shows the current flow; steps are named by short name, else by name.
2. Edit the text. A name that is not a step yet becomes a new action usage of the top-level function ("Check health" becomes checkHealth). A step left out of the text leaves the flow: it stays in the model without successions and is listed under Not in the flow in the FFBD's Add panel.
3. Click Apply. Holarch writes the flow into the model as successions, fork and join nodes (AND), decision and merge nodes (OR) and a succession back to the loop's first step (LOOP; an empty loop is a while true). Unchanged parts keep their successions, guards and else branches; gates that hold the same steps keep their nodes, while and if actions.

The change is one undo step, and the model text shows the new successions. Apply refuses a text the model cannot hold, and nothing changes:

• A loop takes no options in a SysML v2 project, and EXIT has no SysML v2 form.
• A decision with guards takes one branch without a guard (its else). Add a further branch on the Action Flow View and give it a guard.
• When the flow read back from the model would differ from the text, make the change on the Action Flow View.

Other diagram types

+ New Diagram also offers the interface diagrams on the model: N²N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. Diagram (Actions), N² Diagram (Parts), Physical I/O Diagram and Interface Control Diagram. See Holarch Features in SysML v2 Projects.

Keyboard shortcuts

The other diagram shortcuts are listed in Diagrams.

Accessibility

Views work with the keyboard alone and with a screen reader, as LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. diagrams do.

• A view has one Tab stop. Shapes and connections are named from the model, such as "Part def: Component" or "Port: Fuel Out, inside Part: Tank".
• Arrow keys move between shapes, then connections, and select each one. Space selects; Shift+Space adds to the selection.
• Enter moves into the inspector; Esc there returns to the shape. Shift+Enter opens the item.
• ⌥ / Alt+arrow keys move the selected shape, one undo step per key press (Shift moves farther). C opens Connect… to relate the shape to another one. Delete deletes the selection.
• The Grid view is the Database table, with the same keyboard use.

Messages

Limits

• Sequence Views draw messages between lifelines only; combined fragments are not drawn.
• The Geometry View is 2D; 3D geometry is not drawn.
• Simulating state machines is not yet available; the Simulator runs action flows.
• Analysis diagrams are not exchanged with other SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 tools.

Related pages

• Getting Started with SysML v2 Projects
• The Text Editor and Browser
• Requirements and Verification in SysML v2 Projects
• Evaluation, Units and Analysis in SysML v2 Projects
• Holarch Features in SysML v2 Projects
• Diagrams
• Other Diagrams

SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams.® and OMGObject Management Group The standards body that maintains UML, SysML, UAF and XMI.® are registered trademarks of Object Management Group, Inc. in the United States and other countries.