In this section, we start our practical project: setting up an online store.

A use case diagram shows you which services your system offers externally and who uses them. You will learn what a use case is, how it functions as a contract between the actor and the system, and how to name it correctly.

Course content:

• Use and structure of a use case diagram

• Definition of use cases

• Differentiating between primary and secondary actors

• Correct naming of use cases

Put yourself in the shoes of the actors and talk to stakeholders to understand their goals and needs. Use observations, interviews and surveys to identify the important use cases. Remember that this process is iterative and requires flexibility.

Course content:

• Taking on the perspective of the actors

• Involving stakeholders

• Methods for identifying use cases

• Iterative process of adaptation

We add the basic elements of a use case diagram: the system boundary, use cases, actors, and associations as lines connecting actors to use cases.

Learning content:

• Define the system boundary

• Creating and naming use cases

• Identify and visualize actors

• Create associations between actors and use cases

In this chapter, we answer key questions about structuring use case diagrams: How do you effectively combine similar use cases? When and how are use cases automatically linked? And under what conditions can additional actions occur in a use case? We'll walk you through how to use generalizations, includes, and extends to make your diagrams clear and concise.

Course content:

• Clarity about the use of generalizations in use case diagrams

• Understanding when include relationships are useful and how they are represented

• Knowing when to use extend relationships

• Use relationship types to optimize the diagram structure

In this chapter, we will answer an often-overlooked but important question: What is the difference between scenarios and use cases? We will discuss why use cases and scenarios are not synonyms and how they are related. You will learn how scenarios describe the possible sequences of events within a use case as concrete execution paths.

Course content:

• Definition and differentiation of use cases and scenarios

• Understanding of the structure and significance of main success and alternative scenarios

• Insight into why scenarios are not shown in the use case diagram

• The importance of scenarios for a complete and realistic system model

Today we will clarify why a use case diagram alone is not enough and how you can capture all the important information with a detailed use case specification. We will discuss which elements should not be missing from a specification: From the name and scope, to actors, stakeholders, pre- and post-conditions, to triggers and scenarios. You will learn how to create a complete and comprehensible specification that clearly and precisely documents the process and requirements. This lays the foundation for successful system development.

Course content:

• Structure of a complete use case specification

• Important content: name, scope, actors, stakeholders, pre- and post-conditions, triggers and scenarios

• Difference between diagram and textual specification

In this lesson, we discuss a common stumbling block: How granular should a use case actually be? You will learn why it is important not to set the scope too broadly and how to recognize whether your use case is too large. We will look at how you can break down complex use cases such as “placing an order” into more specific, precise use cases to create clarity and organization. A use case is optimal when it describes exactly one main scenario – everything else are exceptions or errors.

Course content:

• Recognizing overly extensive use cases

• Splitting complex use cases into more specific, clearly defined units

• Determining the optimal granularity of a use case

• Practical tips for creating effective use case models

In this lesson, we clarify when in the life cycle of a project the use case diagrams should be created – and why it makes sense to start early. You will learn how use case diagrams help to view the system from the user's perspective and reduce misunderstandings between stakeholders during the requirements phase. We will also look at how these diagrams can be used later to distribute use cases across subsystems and components. A valuable tool that will accompany you throughout the entire project.

Course content:

• The importance of use case diagrams in the early project phase

• How they contribute to the definition and communication of requirements

• Reusing the diagrams in the architecture design

You can also download the job description

In this lesson, you will learn about the basic structure of a requirements diagram in SysML. We start with the frame (req) and its central elements: the requirements. You will learn how the frame defines the context of the diagram and which minimum attributes each requirement must have - including name, description and ID. We also clarify what exactly a requirement is and what significance it has for the system. The next chapter then deals with the different types of requirements that SysML recognizes.

Learning content:

• Structure and meaning of the frame (req) in the requirements diagram

• The three minimum attributes of a requirement: Name, description, ID

• Definition of requirements in SysML

• Importance of a consistent requirements model in a team

In this lesson, we clarify the difference between functional and non-functional requirements (NFRs). You will learn how functional requirements relate to the **what** of a system and NFRs to the **how** of a system. I'll also show you how SysML helps to specify NFRs using stereotypes such as 'performanceRequirement', 'interfaceRequirement', and 'designConstraint', although it does not provide a strict distinction. For functional requirements, we use the stereotype 'functionalRequirement' to make your diagrams clear and consistent.

Learning content:

• Difference between functional and non-functional requirements (NFRs)

• Use of SysML stereotypes for the specification of NFRs

• Best practices for labeling requirements

In this chapter, you will learn how to use containment relationships to present complex requirements in SysML in a structured and clear way. Using the example of a secure payment process in an online store, I'll show you how to break down high-level requirements into more detailed, subordinate requirements and logically connect them in the requirements diagram. You'll learn how these relationships are visualized through a clear hierarchy and the containment symbol, and what advantages they offer for structuring and impact analysis.

Course content:

• Definition and representation of containment relationships in SysML

• Application to functional and non-functional requirements

• Advantages of containment relationships for structure and impact analysis

• Best practices: clear hierarchy, unambiguous assignment, consistent granularity

In this lesson, we will examine the derive relationship in SysML and how it differs from the containment relationship. While containment represents a hierarchical decomposition, the derive relationship shows a logical dependency between requirements that does not represent a direct subset.

Learning content:

• Difference between containment and derive relationships

• Representation and application of the DeriveReqt relationship in SysML

• Traceability and logical dependencies through derive relationships

• Best Practices: When to use containment vs. derive relationships

This lesson is about the Refine relationship in SysML, which substantiates requirements using model elements such as use cases or activity diagrams. You will learn how this relationship is used to describe and specify requirements in more detail.

Course content:

• Definition and representation of the Refine relationship in SysML

• Refinement of requirements by use cases or activity diagrams

• Example application: Refining the product search in an online store

In this lesson, I will show you how to use the Satisfy relationship in SysML to link requirements to the elements that fulfill them. This relationship links requirements to blocks, use cases or activity diagrams that provide the corresponding solution or functionality.

Learning content:

• Definition and representation of the Satisfy relationship in SysML

• Linking requirements to blocks, use cases and activity diagrams

• Advantages of the Satisfy relationship for ensuring responsibilities

This lesson is about the Verify relationship in SysML, which links requirements to the test cases that check their fulfillment. You will learn how test cases in the requirements diagram help to ensure that a requirement has been implemented correctly.

Learning content:

• Definition and representation of the verify relationship in SysML

• Linking requirements with test cases for verification

• Importance of traceability through the verify relationship

In this lesson, you will learn about the trace relationship in the SysML requirements diagram. We'll look at when and why you should use this particular relationship - and why you might want to use it sparingly. You will get an overview of how the trace relationship works, what advantages and disadvantages it has and when other, more specific relationships are more suitable.

Learning content: 

• Definition of the trace relationship and its role in requirements diagrams

• Representation and notation of the trace relationship in SysML

• Differences to other requirements relationships such as Containment, Refine and Satisfy

• Advantages and disadvantages of the trace relationship

• Recommendations for the sensible use of the trace relationship in the modeling process

In this lesson, we explore three types of notation in SysML—direct, compartment, and callout notation—that help represent relationships between elements. Each notation style offers unique advantages for organizing and clarifying complex diagrams.

Learning Outcomes:

• Understanding direct notation for intuitive, visually clear relationships using arrows and stereotypes

• Using compartment notation to consolidate relationships within elements for compact visualization

• Applying callout notation to list multiple relationships of the same type within a comment

• Choosing the appropriate notation to improve diagram readability based on relationship complexity

In this lesson, we discuss rationales, a SysML feature for documenting justifications and contextual information in a model. Rationales are captured as a special type of comment, allowing you to attach additional insights to any element or relationship.

Learning Outcomes:

• Understanding rationales as note-based comments for documenting design decisions

• Using rationales to explain requirement origins, decisions, or constraints

• Enhancing model clarity and transparency for complex systems or future development

• Balancing the use of rationales to keep models informative without clutter

In this lecture, you'll explore decision and merge nodes, which are key for modeling alternative flows in a process. Decision nodes allow you to split a process based on conditions, while merge nodes bring those paths back together into a single flow.

I’ll guide you through using these nodes to manage decision logic and ensure your process flows smoothly.

Learning Outcomes:

• Using decision nodes to branch processes

• Defining conditions (guards) for alternative paths

• Applying merge nodes to unify process flows

• Structuring control flow with complete and disjoint conditions

In this lesson, we explore Block Definition Diagrams (BDDs), a fundamental tool in SysML for visualizing the structure of a system. BDDs serve as blueprints, helping you define the components of your system and how they connect, providing a clear overview for all involved.

Learning Outcomes:

• Understanding BDDs as blueprints that illustrate system components and relationships

• Recognizing the purpose of blocks, actors, and relationships in system modeling

• Learning why BDDs are essential for maintaining clarity in complex, multidisciplinary systems

In this lesson, we explore blocks, the foundational elements of Block Definition Diagrams (BDDs) in SysML. Blocks serve as versatile templates for representing any system component, from physical objects to software elements, defining the structure and functionality of a system.

Learning Outcomes:

• Understanding blocks as foundational elements in SysML BDD for defining system entities

• Recognizing blocks as blueprints that specify types, not instances

• Identifying block notation, with the <<block>> stereotype and compartments for properties

In this section, we will take a deeper look at the structural properties of a block, specifically the part properties. You will learn how these properties map the internal components of a block and how they help to understand the structure of a system. With a clear example, I will explain how to display part properties in a block definition diagram.

Learning content:

• Definition and meaning of part properties

• Difference between structural and behavioral properties

• Example: Part properties in a user management block

• Display of part properties in the block definition diagram (BDD)

This lesson is about the structural properties in SysML, especially the reference properties. You will learn how to represent them correctly in Block Definition Diagrams (BDD) and what they mean. I also clarify the difference to Part Properties, as there is often confusion between the two, especially at the beginning.

Learning content:

• What are reference properties and how are they notated?

• Comparison of reference properties and part properties

• Practical examples to illustrate the difference

In this lesson, you will learn what value properties are in SysML and how they store data in a block. You will learn how to use these properties to model important system information.

Learning content

• Definition of value properties in SysML

• Differences between primitive data types (string, Boolean, integer, real)

• Use of value properties for data storage and processing

• Visualization of value properties in the values compartment of a block

In this lesson, you will learn how constraints in SysML are used to define rules and mathematical conditions in your block definition diagrams. You will learn how constraint blocks work and the advantages of using constraints for complex models.

Learning Content

• Definition of constraints in SysML and their meaning

• Use of the constraint compartment in blocks

• Introduction to constraint blocks and their application

• Differences between simple and reusable constraints

In this lesson, you will learn how ports in SysML define the interfaces of your blocks and enable communication between them. You will learn about the different port types, how they work, and when to use each port type.

Learning content:

• Definition of ports in SysML and their role in the interaction between blocks

• Difference between non-stereotyped ports, full ports and proxy ports

• Use of ports to control data flows and functions

In this lesson, you will learn how to use operations to model the behavior of your blocks in SysML. You will learn how to use parameter lists, return values and the notation of operations to define the functionalities of a block.

Learning content:

• Definition of operations in SysML and their significance for system behavior

• Notation of parameter lists, return values and multiplicity in operations

• Tips for comprehensible naming of operations

• The difference between synchronous and asynchronous communication

In this chapter, we will look at how to use receptions and signals to model asynchronous communication in a SysML block model. You will learn how blocks react to signals without waiting for a response – perfect for systems that need to react efficiently to external events. A practical example from an online shop illustrates how receptions are used to process payment transactions asynchronously.

Learning content:

• Definition and use of receptions in SysML

• Modeling asynchronous communication with signals

• Notation and parameters of receptions

This chapter is all about generalization, i.e. the inheritance of properties between blocks. You will learn how blocks inherit common properties through generalization and how to create clear structures in your model.

Learning content:

• Definition and use of generalization in SysML BDDs

• Inheritance of properties between blocks

• Representation of the generalization notation

• Avoiding redundancy through generalization

Today, we'll explore dependencies in Block Definition Diagrams (BDDs). I’ll show you how dependencies indicate that one block (client) relies on another (supplier) to complete its tasks. You’ll learn how changes to the supplier can affect the client and why BDDs keep these dependencies loose and straightforward.

Learning Objectives

• What are dependencies in BDDs?

• Representing dependencies

• Loose coupling: pros and cons

In BDDs, actors represent external entities that interact with your system but are not part of it. They can be users, other systems, or even organizations. I’ll show you how actors are placed outside the system boundary and how they interact with blocks

Learning Objectives:

• What are actors in BDDs?

• How actors interact with blocks

• Using actors to represent external users and systems

• Deciding when to include actors in your BDD

Now that we've explored use case, requirements, and block definition diagrams, it's time to dive into how our system behaves. Activity diagrams help us visualize how components work together, focusing on the flow of control and data. Think of them as scripts that show the sequence of actions, decisions, and data exchanges within your system.

In this chapter, we will delve into the world of actions. They form the core of an activity diagram by depicting processes and processing steps within a system. I will show you how to define actions in a meaningful way to maintain clarity and how to display them in the diagram.

Learning content:

• What are actions in an activity diagram?

• How do you define atomic actions?

• Granularity of actions: not too coarse, not too fine

• Representation and naming of actions in the diagram

To make the activity diagram meaningful, we need to look at control flows and tokens. I'll explain what control tokens are, how they move around the diagram and how you can use control flows to specify the sequence of actions.

Learning content:

• What is a control token and how does it work?

• How control tokens control the flow in a diagram

• Using control flows to display the sequence

• Connecting actions using edges

In this lesson, we dive into how information flows between actions. You'll learn the difference between control flow and object flow, and explore the role of pins and object nodes. Step by step, I'll show you how data is transferred using object tokens and how to model this flow. By the end, you'll understand how pins act as interfaces and why they often don't need explicit labeling.

Learning Outcomes

• Difference between control flow and object flow

• Role of pins and object nodes

• Modeling data flow

• Using object tokens to transfer data

• Notation of pins and object flows

In this lesson, we’ll explore how actions in SysML start and end. You’ll learn about the initial node, which marks the starting point of an activity with a control token, and how object flows can also trigger activities. We’ll also cover how to end an activity using the activity final node, which stops the entire process. By the end, you'll understand the key concepts for beginning and concluding actions within an activity diagram.

Learning Outcomes

• Understanding the initial node and its role in starting activities

• How object tokens can trigger actions via object flows

• Using the activity final node to end activities

In this lecture, you'll learn how to introduce parallelism in your processes using fork and join nodes. Fork nodes allow multiple actions to run simultaneously, while join nodes synchronize them by waiting for all tasks to complete before continuing. I'll also introduce the flow final node, which terminates specific paths without ending the entire process.

Learning Outcomes:

• Using fork nodes to create parallel process paths

• Synchronizing actions with join nodes

• Differentiating between merge and join nodes

• Applying flow final nodes to stop individual paths

In this lecture, you’ll explore activity partitions, also known as swimlanes, which help organize your activity diagrams by showing who or what is responsible for each action. These partitions make it easy to maintain clarity in complex systems by grouping tasks under departments, components, or other structures.

Learning Outcomes:

• Organizing actions with activity partitions (swimlanes)

• Assigning responsibilities to departments, components, or individuals

• Structuring complex systems for better clarity

• Visualizing multi-level responsibilities in diagrams

In this lecture, you'll learn about call behavior actions, which allow you to call another behavior when an action is triggered. This helps break down complex processes into smaller, reusable components, keeping your model clear and flexible. You'll also see how data flows between actions through object nodes and parameters.

Learning Outcomes:

• Understanding the role of call behavior actions in process modeling

• Using call behavior actions to reuse and modularize behaviors

• Managing data flow between actions with object nodes and parameters

• Enhancing process clarity and reducing redundancy in diagrams

In this lecture, you'll explore send signal actions, which allow your system to send signals without waiting for a response. This action is useful for asynchronous processes, where tasks can continue without immediate feedback. Send signal actions ensure that necessary data is transmitted, but the process moves on as soon as the signal is sent.

Learning Outcomes:

• Understanding the role of send signal actions in process modeling

• Sending signals asynchronously in a "fire and forget" manner

• Managing data flow for send signal actions

• Differentiating between send signal actions and other synchronous actions

In this lecture, you'll learn about the accept event action, which listens for specific events or signals. Once the event occurs, the action responds and passes control to the next step. This makes it perfect for asynchronous processes, where actions trigger only when certain signals are received.

Learning Outcomes:

• Understanding the function of accept event actions in process modeling

• Handling asynchronous events with accept event actions

• Passing control after receiving a signal in the process flow

In this chapter, you'll learn about the Wait Timer Action, which pauses a process for a specific time before continuing. Represented by an hourglass symbol, this action can be set for absolute or relative time, making it useful for time-based processes where a delay is required.

Learning Outcomes:

• Understanding the function of Wait Timer Actions in process flow

• Modeling time delays with absolute or relative durations

• Differentiating between Wait Timer and Accept Event Actions

• Using time-based control to manage process flow efficiently

In this lesson, we explore how to use nested parts to present the internal structure of your system. Nested parts allow you to organize components within other components, giving a clear view of how different elements are interconnected, especially in complex systems.

Learning Outcomes:

• Understanding how to model nested parts to show internal system structures

• Using connectors to represent communication between nested components

• Applying dot notation for compact representation of nested parts

• Balancing clarity and complexity in diagrams with multiple nested levels

In this lesson, we explore why and when to use sequence diagrams. Sequence diagrams provide a clear view of the dynamic behavior of a system by showing how different components interact with each other over time. They are particularly valuable for understanding communication between system parts, such as users, servers, or modules, especially in message-driven systems like REST APIs.

Learning Outcomes:

• Understanding the purpose of sequence diagrams in modeling dynamic behavior

• Visualizing interactions between system components in chronological order

In this lesson, you'll learn the basic components of a sequence diagram: lifelines, messages, and the timeline. These elements help you represent participants in an interaction, how they communicate, and the order in which events occur, providing a clear view of system behavior.

Learning Outcomes:

• Understanding lifelines as representations of participants in a system

• Distinguishing between synchronous and asynchronous messages

• Visualizing the timeline of interactions in a sequence diagram

• Applying these elements to model communication and event flow

In this lesson, we’ll dive into control structures in sequence diagrams, focusing on alternatives (`alt`) and options (`opt`). These elements allow you to model flexible behavior by showing different paths based on specific conditions.

Learning Outcomes:

• Understanding combined fragments and their role in control logic

• Using the `alt` operator to model alternative sequences with guard conditions

• Applying the `opt` operator for optional actions that are conditionally executed

• Enhancing sequence diagrams with dynamic paths based on system behavior

In this lesson, you'll learn how to model repeatable processes using loops in sequence diagrams. Loops represent actions that are repeated multiple times, and you can specify the number of iterations or set conditions to control the loop's behavior.

Learning Outcomes:

• Using the loop operator to model repeatable processes

• Defining minimum and maximum iterations in a loop

• Adding conditions (guards) to control when a loop ends

In this lesson, you'll learn how to model parallel processes using the `par` operator in sequence diagrams. With the `par` operator, you can run multiple processes simultaneously, making your system more efficient by allowing independent actions to occur in parallel.

Learning Outcomes:

• Using the `par` operator to model parallel processes

• Structuring parallel sequences with dashed lines in the par frame

• Representing independent actions in parallel

• Understanding the efficiency benefits of parallel processing in sequence diagrams

In this lesson, you'll learn about execution specifications, which clearly define when an action begins and ends for a participant in a sequence diagram. These are particularly useful in complex diagrams, as they provide a clear visual of how long an instance is actively executing a task.

Learning Outcomes:

• Using execution specifications to mark the duration of actions on a lifeline

• Understanding the start and end points of an action with the vertical rectangle

• Visualizing active periods of participants, such as web servers or databases

• Clarifying action timelines in complex sequences

In this lesson, we explore three key types of constraints in sequence diagrams: time constraints, duration constraints, and state invariants. These constraints help define precise temporal or logical conditions that must be met for the process to be valid.

Learning Outcomes:

• Understanding time constraints and how they ensure events occur within a specific time frame

• Using duration constraints to specify a valid time range between two events

• Applying state invariants to check conditions that must be true for an instance before continuing a process

• Enhancing control over the flow and conditions in your system

In this lesson, we explore destruction occurrences, which represent when an instance in a sequence diagram is destroyed or reaches the end of its lifespan. Destruction occurrences are marked by an "X" at the bottom of the lifeline, indicating that no further messages will be sent or received by the instance.

Learning Outcomes:

• Understanding how destruction occurrences model the end of an instance’s lifecycle

• Using destructions to show resource management, such as releasing memory or closing connections

• Differentiating between destruction triggered by a message and self-termination

• Visualizing when an instance is no longer needed in the system

In this lesson, we introduce the Internal Block Diagram (IBD) and explain how it complements the Block Definition Diagram (BDD). While the BDD defines the overall structure and relationships between blocks, the IBD focuses on the internal organization and connections of those blocks.

Learning Outcomes:

• Understanding the purpose and structure of an Internal Block Diagram (IBD)

• Differentiating between the high-level overview of a BDD and the detailed view of an IBD

• Exploring how part properties from the BDD are connected and interact in the IBD

• Knowing when to create an IBD, particularly during system integration and detailed design stages

In this lesson, we explore the key components of an Internal Block Diagram (IBD): part properties and reference properties. These elements help you model the internal structure of a block and its interactions with other blocks, giving you a clear view of how a system is organized and connected.

Learning Outcomes:

• Understanding part properties as internal components of a block

• Using reference properties to represent connections to external systems

• Differentiating between part and reference properties in IBDs

• Applying the correct notation for part and reference properties with names, types, and multiplicities

In this lesson, we dive into connectors, which are essential for showing how parts of a system interact in an Internal Block Diagram (IBD). Connectors represent the communication between part properties and reference properties, helping you understand the flow of information both within the system and with external systems.

Learning Outcomes:

• Understanding connectors as links between part and reference properties

• Visualizing internal communication between system components

• Modeling external connections using connectors and ports

• Naming and typing connectors to clarify the nature of interactions in your system

In this lesson, we explore item flows, a key concept in SysML that allows you to model the specific data or objects flowing between parts of your system. While connectors show that elements are linked, item flows provide detail about what exactly moves through those connections, enhancing the clarity of your model.

Learning Outcomes:

• Understanding the role of item flows in defining data or object transfer between parts

• Differentiating between simple connections and item flows

• Using ports to model item flows between system components

• Enhancing system transparency by specifying what flows between parts

In this lesson, we introduce state machines in SysML, which allow you to model how a system reacts to events and transitions between states over time. State machines help you visualize the dynamic behavior of a system, making complex processes easier to understand.

Learning Outcomes:

• Understanding the concept of states and transitions in state machines

• Recognizing the importance of state machines for representing system behavior

• Getting a high-level overview of state machine components and their role in system modeling

In this lesson, we delve deeper into the different types of states in a state machine: the initial state, final state, and simple states. These states define the system's behavior as it progresses through various stages, with specific actions triggered at entry, during, and exit of each state.

Learning Outcomes:

• Understanding the initial state as the automatic starting point in a state machine

• Recognizing the final state as the termination of a process with no further transitions

• Defining simple states as the current status of a system, waiting for events to trigger transitions

• Exploring Entry, Do, and Exit Behaviors within simple states to model actions during state transitions

In this lesson, we focus on transitions, which describe how a system moves from one state to the next. Transitions are triggered by events, and sometimes additional conditions (called guards) must be met for the change to occur.

Learning Outcomes:

• Understanding transitions as the mechanism for changing states in a system

• Identifying triggers as the events that cause a transition to occur

• Visualizing transitions in diagrams and understanding their role in system behavior modeling

In this lesson, we explore events, the key triggers that cause a system to transition from one state to another. Events determine when state changes occur, and we look at four main types: signal events, call events, time events, and change events.

Learning Outcomes:

• Understanding how events trigger state transitions in a system

• Identifying signal events as messages between systems

• Recognizing call events as function or method calls that trigger transitions

• Exploring time events based on time intervals or specific times

• Using change events to trigger transitions when certain conditions are met

In this lesson, we explore guard conditions, which are additional criteria that must be met for a transition between states to occur. While events trigger state changes, guard conditions act like gates that control whether or not a transition takes place.

Learning Outcomes:

• Understanding guard conditions as requirements for state transitions

• Modeling guards in state diagrams using square brackets next to the event trigger

• Combining events with guard conditions to ensure all criteria are met before changing states

• Using multiple guard conditions to specify complex criteria for transitions

In this lesson, we explore composite states, which allow you to organize multiple related states within a hierarchical structure. Composite states enable finer control over a system’s behavior by grouping substates within a larger state, improving clarity and reducing complexity.

Learning Outcomes:

• Understanding composite states as containers for related substates

• Organizing substates hierarchically within a composite state

• Transitioning between substates within a composite state

• Managing transitions that exit a composite state once all substates are complete

In this lesson, we explore pseudostates, which are special nodes used to define and control transitions in state machine diagrams. Pseudostates help direct the flow between states and allow more complex control logic than standard states.

Learning Outcomes:

• Understanding the role of the initial pseudostate as the starting point of a state machine

• Visualizing the initial pseudostate as a filled circle without incoming transitions

• Using junction pseudostates to split or merge transitions based on conditions

• Applying guard conditions and 'else' paths to outgoing transitions for greater flexibility in control logic

• Enhancing the structure and flow of state machines using pseudostates for complex decision-making

In this lesson, we explore how events, guards, and effects work together to control transitions in state machines. These three elements allow you to precisely determine when a transition occurs, under what conditions it is executed, and what actions are performed.

Learning Outcomes:

• Understanding how events trigger transitions between states

• Applying guards to define conditions that must be met for a transition to execute

• Defining effects as actions carried out during a transition

• Combining events, guards, and effects to create clear and controlled state transitions in your model

In this lesson, we introduce Parametric Diagrams in SysML, which provide a detailed view of the constraint blocks defined in Block Definition Diagrams (BDDs). While BDDs establish the structure and relationships between blocks, Parametric Diagrams help visualize the specific mathematical rules and conditions linking properties within a system.

In this lesson, we explore the connection between Block Definition Diagrams (BDDs) and Parametric Diagrams. BDDs define the blocks and constraint blocks that contain mathematical rules, while Parametric Diagrams apply these rules using binding connectors to link value properties to constraint parameters.

Learning Outcomes:

• Understanding how Parametric Diagrams extend BDDs by detailing constraint relationships

• Using binding connectors to link value properties with constraint block parameters

• Ensuring that linked values remain synchronized for accurate calculations

• Visualizing how mathematical rules are applied in a system through Parametric Diagrams

In this lesson, we dive into the core components of Parametric Diagrams: constraint properties, constraint parameters, and value properties. These elements are essential for modeling the mathematical rules and connections that define a system’s behavior.

Learning Outcomes:

• Understanding constraint properties as instances of constraint blocks within higher-level blocks

• Recognizing constraint parameters as variables used in constraint equations

• Defining value properties as the data inputs for constraints

• Visualizing how these elements work together to apply mathematical rules within a system through Parametric Diagrams

In this lesson, we introduce package diagrams, a specific type of structure diagram used to logically group and organize different entities in a system. Package diagrams help you divide complex systems into functional units, keeping your model organized and clear.

Learning Outcomes:

• Understanding packages as containers for organizing elements in a system

• Using packages to group related elements by function, subsystem, or layer

• Reducing system complexity and improving navigation by organizing elements into packages

• Knowing when to create or update a package diagram to reflect changes in your system’s structure

In this lesson, we explore the logical structure of package diagrams, focusing on how packages and sub-packages are organized, nested, and connected. This provides a clear overview of the relationships and dependencies between different functional units in a system.

Learning Outcomes:

• Understanding the purpose of the package diagram frame and its main packages

• Using nesting notation to show sub-packages within main packages

• Applying qualified name notation to represent hierarchical relationships between packages

• Recognizing crosshair notation to indicate connections between packages on the same level

• Visualizing dependency relationships to show how packages rely on each other

In this lesson, we cover four specialized packages in SysML that help organize and manage elements in a model: models, model libraries, profiles, and views. Each package type serves a distinct function to improve the organization, reusability, and clarity of the model.

Learning Outcomes:

• Identifying models as the root of a system’s hierarchy and structure

• Using model libraries to store reusable elements across projects

• Applying profiles to create custom stereotypes and extend element types

• Creating views to focus on specific stakeholder needs and perspectives

• Organizing elements with specialized packages to enhance model clarity