Print Friendly, PDF & Email

SysML Tutorial

SysML tutorial will give you an overview about the model-based system with SysML, including but not limited to definitions, requirements, and tools. This article is ideal for those individuals who are just starting to learn about this subject, or want to freshen up their knowledge.

Introduction to SysML

SysML gives support to the specification, evaluation, design, verification, and validation of a wide range of complex systems. Such systems might consist of hardware, software, information, processes, personnel, and facilities.

SysML tutorial

SysML was first initiated as a tactical decision by the International Council on Systems Engineering’s (INCOSE) Model Driven Systems Design workgroup in January 2001 to modify the Unified Modeling Language (UML) for the use in systems engineering. Such led to a collaboration among INCOSE and the Object Management Group (OMG), maintaining the UML specification, to mutually grant the OMG Systems Engineering Domain Special Interest Group (SE DSIG) in July 2001. The SE DSIG, with the support of INCOSE and the ISO AP 233 workgroup, created the specifications for the modeling language, later were published by the OMG as part of the UML for Systems Engineering Request for Proposal (UML for SE RFP; OMG document ad/2003-03- 41) in March 2003.

Today, it is a routine exercise for systems engineers to apply a variety of modeling languages, tools, and techniques on large systems projects. In a reaction similar to how UML combined the modeling languages used in the software industry, SysML’s goal is to combine the various modeling languages presently applied in systems engineering.

SysML is planned to deliver simple yet strong framework to model a variety of systems engineering problems. It is specifically efficient in identifying requirements, structure, behavior, allocations, and limitations of system properties to support engineering analysis. The language intends to give support to several processes and techniques such as structured, object-oriented, and others, but each method may enforce extra limitations on how a framework or diagram type may be applied. This type of language offers most, but not all, of the specifications of the UML for Systems Engineering.

Language Architecture

SysML reprocesses a subcategory of UML 2 and gives extra extensions required to discourse requirements in the UML for Systems Engineering. This requirement records the language architecture in regards to the elements of UML 2 that are reused and the extensions to UML 2.

Design Principals

  • Requirements-driven
  • UML reuse
  • UML extensions
  • Partitioning
  • Layering
  • Interoperability

SysML Modeling Elements

  • Allocations
  • Rationales
  • Diagram Frames
  • Model Views and Viewpoints
  • Problems

Extension Mechanisms

This requirement applies the following instruments to describe the SysML extensions:

  • UML stereotypes
  • UML diagram extensions
  • Model libraries

SysML stereotypes describe new modeling frameworks by spreading existing UML 2 structures with new assets and restraints.

SysML diagram extensions explain new diagram footnotes that complement diagram notations reused from UML 2.

SysML model libraries define unique model components that are accessible for reuse.

The SysML user model is developed by instantiating its metamodel and using the stereotypes stated in the SysML profile, and optionally referencing or subsetting the model components in the SysML model library.

Compliance

Compliance with SysML involves the subset of UML necessary for SysML is executed, and that the SysML extensions to this subset are executed as well. To completely conform to SysML, a device must establish both the concrete syntax (notation) and abstract syntax (metamodel) for the required UML subset and the SysML extensions. The following sections explain the description of compliance for SysML.

  1. Compliance with UML Subset (UML4SysML)

The subset of UML needed for SysML is quantified in regards to a subset of metaclasses introduced from the UML 2 metamodel. It is arranged in terms of 3 levels of modeling competencies:

  • Level 1 (L1); offers the base of UML concepts from the UML kernel and supplements language units for use cases, interactions, structures, actions, and activities.
  • Level 2 (L2); extends the language units already delivered in Level 1and adds language units for state machine modeling and profiles.
  • Level 3 (L3); signifies the whole UML subset for SysML by improving the language units already provided in Level 2 and supplementing language units for modeling generalization sets, association classes, and information flows and for model packaging.
  1. Compliance with SysML Extensions

In addition to UML, more units of compliance for SysML are the sub-packages of the SysML profile, except for Deprecated Elements, which is not a compliance unit.

SysML package include:

  • Activities (with or without probability)
  • Allocations
  • Blocks
  • Constrain blocks
  • Model elements
  • Ports and flows (with or without item flow)
  • Requirement
  1. Meaning of Compliance
  • Abstract syntax compliance
  • Concrete syntax compliance

Compliance for a given level can be expressed as:

  • abstract syntax compliance
  • concrete syntax compliance
  • abstract syntax with concrete syntax compliance

SysML Model Elements

The ModelElements package of SysML describes general-purpose frameworks that may be demonstrated on several forms of SysML diagram. Such consist of package, model, various types of dependencies, restraints, and comments.

Diagram Elements

Diagram elements mostly include comments, constraints, problem, rationale, and dependencies. Dependencies are compromised of the dependency subtypes Conform, Realization, and Refine, shown on all SysML diagram types, in addition to the diagram elements that are specific to each diagram type.

Blocks

Blocks are modular units of system description. Each block describes a collection of specifications to explain a system or other component of interest. These may include both structural and behavioral features, such as properties and operations, to represent the state of the system and behavior that the system may exhibit.

Blocks give a general-purpose ability to model systems as trees of modular elements. The certain types of elements, the types of connections between them, and the way these components join to explain the whole system can all be chosen based on the goals of a specific system model. SysML blocks can be applied across all the stages of system requirement and design, and can be used in various types of systems. These contain modeling either the rational or physical breakdown of a system, and the requirement of software, hardware, or human components. Parts in these systems may communicate with many different tools, such as software functions, distinct state transitions, flows of inputs and outputs, or continuous interactions.

Block Diagram Elements

  • Block definition diagram
  • Internal Block Diagram

Block Definition Diagram- UML Extension

  • Block and ValueType Definitions
  • Default «block» stereotype on unlabeled box
  • Labeled compartments
  • Constraints compartment
  • Namespace compartment
  • Structure compartment
  • Unit and QuantityKind definitions
  • Default multiplicities
  • Property-specific type

Internal Block Diagram- UML Extension

  • Property types
  • Block reference in diagram frame
  • Compartments on internal properties
  • Compartments on a diagram frame
  • Property path name
  • Nested connector end
  • Property-specific type
  • Initial values compartment
  • Default multiplicities

How Can You Learn More?

TONEX offers several hands-on trainings, listed below:

SysML Training Crash Course

Advanced SysML Training | Creating SysML Models

SysML Training | Systems Modeling Language Training

SysML Tutorial

Request More Information

Please enter contact information followed by your questions, comments and/or request(s):
  • Please complete the following form and a Tonex Training Specialist will contact you as soon as is possible.

    * Indicates required fields

  • This field is for validation purposes and should be left unchanged.