Modeling With SysML - Jhuapl.edu
Modeling with SysMLInstructors:Sanford Friedenthalsanford.friedenthal@lmco.comJoseph Wolfromjoe.wolfrom@jhuapl.eduTutorial presented at INCOSE 2010 Symposium, Chicago, IL, July 2010.
OMG SysML Specification Specification status Adopted by OMG in May ’06 Available Specification v1.0 in Sept ’07 Available Specification v1.1 in Nov ‘08 Available Specification for v1.2 in March ‘10 Revision Task Force for v1.3 in process Multiple vendor implementations available This tutorial is based on: OMG SysML available specification (formal/2007-09-01) andOMG/INCOSE tutorial by Friedenthal, Moore, and Steiner“A Practical Guide to SysML” by Friedenthal, Moore, and SteinerTutorial Material from JHU/APL Course developed by Joe Wolfrom This OMG tutorial, specifications, papers, and vendor info can befound on the OMG SysML Website at http://www.omgsysml.org/2Copyright 2006-2009 by Object Management Group.
Agenda 3IntroductionSysML Diagram OverviewIntroduction to a Modeling ToolLanguage Concepts and ConstructsClass ExerciseProcess SummaryTools OverviewWrap-up 2010 by JHU/APL. All Rights Reserved.
Objectives & Intended AudienceAt the end of this tutorial, you should have an awareness of: Motivation of model-based systems engineering approach SysML diagrams and basic language concepts How SysML is used as part of an MBSE processThis course is not intended to make you a systems modeler!You must use the language.Intended Audience: Practicing Systems Engineers interested in system modeling Software Engineers who want to better understand how tointegrate software and system models Familiarity with UML is not required, but it helps4Copyright 2006-2009 by Object Management Group.
INTRODUCTION5 2010 by JHU/APL. All Rights Reserved.
SE Practices for Describing SystemsPastFuture SpecificationsATC Interface requirementsPilotAirplaneRequest to proceedAuthorize System designInitiate power-upPower-upReport Status Analysis & Trade-offDirect taxiwayInitiate TaxiExecuted cmds Test plansMoving from Document centric to Model centric6Copyright 2006-2009 by Object Management Group.
Model-based Systems Engineering (MBSE) Formalizes the practice ofsystems developmentthrough use of models Broad in scope Integrates with multiplemodeling domains acrosslife cycle from system ofsystems to component Results inquality/productivityimprovements & lower risk Rigor and precision Communications amongsystem/projectstakeholders Management of complexity7Vertical IntegrationLife Cycle Support Copyright Lockheed Martin Corporation All Rights Reserved
System Development StatusTechnical dataDefine SystemReqt's &DesignSystemModelingActivities8System archAllocated ingActivitiesIntegrated ProductDevelopment (IPD) isessential to improvecommunicationsTest proceduresIntegrate& onentsA Recursive V processthat can be applied tomultiple levels of thesystem hierarchyCopyright 2006-2009 by Object Management Group.System
System Modeling Activities – OOSEMIntegrating MBSE into the SE ProcessAnalyzeNeeds Causal analysis Mission use cases/scenarios Enterprise modelMajor SE Development ActivitiesDefine System use cases/scenariosSystem Elaborated contextRequirementsOptimize &EvaluateAlternativesDefineLogicalArchitecture Parametric Diag Trade study Reqt’sManageRequirements Diagram& tablesSupportValidation &Verification Test cases Test procedures Logical decomposition Logical scenarios Logical subsystemsSynthesizeAllocatedArchitectureCommon Subactivities9Copyright 2006-2009 by Object Management Group. Node diagram HW, SW, Data arch System deployment
4 Pillars of SysMLpkg [Model] Example Model [Model Organization]SystemModelRequirementsreq [Package] RequirementsBehavioract [Activity] metricsbdd [Package] Structure«block»:Actorpar [Block] Parametrics::Analysis Jproperty 1Systemvaluesproperty atisfy»:A2«block»«block»Comp 1Comp 2valuesproperty 1.1act [Activity] Behavior::A1:Comp1ibd [Block] System:Comp2:Comp 1:A1.1:A1.210valuesproperty 1.2 2010 Elsevier, Inc.: A Practical Guide to SysML:Comp 2property 1.1property 1.2
SysML Diagram TypesSysML includes nine diagrams as shown in this diagram: 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 3.111 2010 by JHU/APL. All Rights Reserved.
4 Pillars of SysML – ABS Example1. Structure2. Behaviorsd ABS ActivationSequence [Sequence Diagram]stm TireTraction [State nmodBrkFrc(traction 3. Requirements 4. ParametricsCopyright 2006-2009 by Object Management Group.
SYSML DIAGRAM OVERVIEW13 2010 by JHU/APL. All Rights Reserved.
SysML Diagram Frames Each SysML Diagram must have a diagram frame Each SysML diagram frame represents a model element Diagram context is indicated in the header: Diagram kind (act, bdd, ibd, sd, etc.)Model element type (package, block, activity, etc.)Model element nameUser defined diagram name or view name A separate diagram description block is used to indicate if thediagram is complete, or has elements elidedFIGURE 4.8 2008 Elsevier, Inc.: A Practical Guide to SysML14Copyright 2006-2009 by Object Management Group.
SysML Diagrams 15Package diagramRequirement diagramUse Case diagramBlock Definition diagramInternal Block diagramActivity diagramSequence diagramState Machine diagramParametric diagram 2010 by JHU/APL. All Rights Reserved.
Package Diagram Represents the organization of a model in terms of packages thatcontain model elementsFIGURE 3.19 2008 Elsevier, Inc.: A Practical Guide to SysML16 2010 by JHU/APL. All Rights Reserved.
Requirement Diagram Represents text-based requirements and their relationship with otherrequirements, design elements, and test cases to supportrequirements traceabilityFIGURE 3.2 2008 Elsevier, Inc.: A Practical Guide to SysML17 2010 by JHU/APL. All Rights Reserved.
Block Definition Diagram Represents structural elements called blocks, and their compositionand classificationFIGURE 3.3 2008 Elsevier, Inc.: A Practical Guide to SysML18 2010 by JHU/APL. All Rights Reserved.
Internal Block Diagram Represents interconnection and interfaces between the parts of ablockFIGURE 3.919 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Use Case Diagram Represents functionality in terms of how a system or other entity isused by external entities (i.e., actors) to accomplish a set of goalsFIGURE 3.4 2008 Elsevier, Inc.: A Practical Guide to SysML20 2010 by JHU/APL. All Rights Reserved.
Drive VehicleSequence Diagram Represents behavior interms of a sequence ofmessages exchangedbetween partsFIGURE 3.5 2008 Elsevier, Inc.: A Practical Guide to SysML21 2010 by JHU/APL. All Rights Reserved.
Start VehicleSequence DiagramFIGURE 3.622 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Activity Diagram Represents behavior in terms of the ordering of actions based on theavailability of inputs, outputs, and control, and how the actionstransform the inputs to outputsFIGURE 3.7 2008 Elsevier, Inc.: A Practical Guide to SysML23 2010 by JHU/APL. All Rights Reserved.
Vehicle System HierarchyBlock Definition DiagramFIGURE 3.1024 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Power SubsystemInternal Block DiagramFIGURE 3.1225 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Provide PowerActivity Diagram 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 3.1126 2010 by JHU/APL. All Rights Reserved.
State Machine Diagram Represents behavior of an entity in terms of its transitions betweenstates triggered by eventsFIGURE 3.827 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Parametric Diagram Represents constraints on property values, such as F m*a, used tosupport engineering analysisFIGURE 3.1428 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Requirements TraceabilityFIGURE 3.1829 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
INTRODUCTION TO AMODELING TOOL30 2010 by JHU/APL. All Rights Reserved.
Typical Work Area ComponentsDrawing AreaProjectBrowserToolboxFigure Tabs31 2010 by JHU/APL. All Rights Reserved.
LANGUAGE CONCEPTS ANDCONSTRUCTS32 2010 by JHU/APL. All Rights Reserved.
Agenda Language Concepts and Constructs Organizing the Model with Packages Capturing Text-Based Requirements in the Model Modeling High Level Functionality with Use Cases Modeling Structure With Blocks Modeling Blocks and Their Relationships on a BDD Modeling Part Interconnection on an IBD Modeling Behavior Flow-based Behavior with Activities Message-based Behavior with Interactions Event-based Behavior with State Machines Modeling Constraints with Parametrics Modeling Cross Cutting Relationships with Allocations33 2010 by JHU/APL. All Rights Reserved.
ORGANIZING THE MODELWITH PACKAGES34 2010 by JHU/APL. All Rights Reserved.
Packages Packages are used to organize the model Groups model elements into a name space Often represented in tool browser Supports model configuration management (check-in/out) Model can be organized in multiple ways By System hierarchy (e.g., enterprise, system, component) By diagram kind (e.g., requirements, use cases, behavior) Use viewpoints to augment model organization Package Diagrams provide a graphical depiction of the modelorganization and/or package content35Copyright 2006-2009 by Object Management Group.
Package Diagram for Automobile ModelFIGURE 3.19 2008 Elsevier, Inc.: A Practical Guide to SysML36 2010 by JHU/APL. All Rights Reserved.
Package Diagram Containment Relationship Depicts Package Hierarchy Three techniques (displayed below) Packages contained within ‘frame’ of parent package Packages contained within a package Crosshair pointing to the parent package 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 5.137 2010 by JHU/APL. All Rights Reserved.
Package Organization for Parking GarageGate38 2010 by JHU/APL. All Rights Reserved.
Summary Packages are used for Model Organization Package Diagrams are used to depict how the model is organized Packages can contain: Other packages Model elements Models may be organized using a variety of methods39 2010 by JHU/APL. All Rights Reserved.
CAPTURING TEXT-BASEDREQUIREMENTS IN THE MODEL40 2010 by JHU/APL. All Rights Reserved.
Requirements The «requirement» stereotype represents a text based requirement Includes id and text properties Can add user defined properties such as verification method Can add user defined requirements categories(e.g., functional, interface, performance) Requirements hierarchy describes requirements contained in aspecification Requirements relationships include Containment, DeriveReqt,Satisfy, Verify, Refine, Trace, Copy SysML provides a graphical depiction of these relationships SysML also provides a means to capture rationale for a specificrequirement or relationship41Copyright 2006-2009 by Object Management Group.
Automobile Specification RequirementsDiagramFIGURE 3.242 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Requirements TraceabilityFIGURE 3.1843 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Representing Relationships Three ways to depict requirement relationships in SysML: Direct Compartment Callout44 2010 by JHU/APL. All Rights Reserved.
Direct Notation Used when the requirement and the related model element appear onthe same diagram Establishes dependency of model element to requirement in model Read figure below as: “The camera satisfies the Sensor Decisionrequirement”. 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 12.345 2010 by JHU/APL. All Rights Reserved.
Compartment Notation Used when the requirement and model element do not appear on thesame diagram. Used for model elements such as blocks or requirements thatsupport compartments. 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 12.446 2010 by JHU/APL. All Rights Reserved.
Callout Notation Used when the requirement and model element do not appear onthe same diagram Uses ‘Note’ box, rather than model element Can be used when the model element or tool does not supportcompartments 2008 Elsevier, Inc.: A Practical Guide to SysML 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 12.547 2010 by JHU/APL. All Rights Reserved.
Depicting Rationale Used to explain or justify a requirement or a requirement relationshipFIGURE 12.1448 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Tabular Format Requirements and their relationships can be represented in atabular format 2008 Elsevier, Inc.: A Practical Guide to SysML 2008 Elsevier, Inc.: A Practical Guide to SysML49
Parking Garage Requirements Model50 2010 by JHU/APL. All Rights Reserved.
Summary Requirement modeling graphically depicts: Hierarchy between requirements Traceability between requirements and the rest of the modelelements There are three types of notation used to depict requirementrelationships: Direct, Compartment, and Callout There are seven types of requirement relationships in SysML: Containment Satisfy Verify Derive Refine Trace Copy51 2010 by JHU/APL. All Rights Reserved.
MODELING HIGH LEVELFUNCTIONALITY WITH USE CASES52 2010 by JHU/APL. All Rights Reserved.
Use Cases Provide means for describing basic functionality in terms ofusages/goals of the system by actors Use is methodology dependent Often accompanied by use case descriptions Common functionality can be factored out via «include» and«extend» relationships Elaborated via other behavioral representations to describe detailedscenarios No change to UML53Copyright 2006-2009 by Object Management Group.
Operate Vehicle Use Case DiagramFIGURE 3.4 2008 Elsevier, Inc.: A Practical Guide to SysML54 2010 by JHU/APL. All Rights Reserved.
Use Case Diagram Components Use Case diagrams are comprised of the following: Subject Actors Use Cases RelationshipsFIGURE 11.155 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Subject Provides the functionality in support of the use casesRepresents a system being developedAlso called the ‘system under consideration’Represented by a rectangle on the use case diagramFIGURE 11.156 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Actors Used to represent something that uses the system Not ‘part’ of the system Depicted outside of the system ‘box’ Actors interface with the system Can be a person or another system Usually depicted by a stick figure and/or block with actor label Name the Actors based on the role they perform as a user of thesystem (e.g. Operator, Customer, etc)FIGURE 11.157 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Use Cases Represent the goals that a system will support Depicted by an oval with the Use Case name inside Name should consist of a verb and a noun that describe thefunctionality of the system (e.g. Record Grades, MonitorEnvironment)FIGURE 11.158 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Relationships on a Use Case Diagram Relationships between Actors and Use Cases Relationships between Use Cases Include Extend ClassificationFIGURE 11.459 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Relationships Between Use Cases Include - depictsshared (or reused) functionality Extend – depictsoptionalfunctionality,performed when aparticularcondition is met Classification –indicates that thespecialized UseCase inheritsfunctionality fromthe general UseCase60FIGURE 11.4 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Use Case Model for Parking Garage Gate61 2010 by JHU/APL. All Rights Reserved.
Summary Use Cases capture the functionality a system must provide toachieve user goals Use Case diagrams are made up of: Subject Actors Use Cases Relationships Use Case can be elaborated through: Activity diagrams Sequence diagrams State machine diagrams62 2010 by JHU/APL. All Rights Reserved.
MODELING STRUCTUREWITH BLOCKS63 2010 by JHU/APL. All Rights Reserved.
MODELING BLOCKS AND THEIRRELATIONSHIPS ON A BDD64 2010 by JHU/APL. All Rights Reserved.
Blocks are Basic Structural Elements Provides a unifying concept for describing the structure of anentity m«activity»ModulateBrakingForcevaluesDutyCycle: Percentage Multiple standard compartments can describe the blockcharacteristics 65Properties (parts, references, values, ports)OperationsConstraintsAllocations from/to other model elements (e.g. activities)Requirements the block satisfiesUser defined compartmentsCopyright 2006-2009 by Object Management Group.
Top Level Block Definition DiagramFIGURE 3.366 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Vehicle System Hierarchy 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 3.1067 2010 by JHU/APL. All Rights Reserved.
Purpose of Block Definition Diagrams Depicting Relationships between Blocks Composite Association Generalization Depicting Structural Features of Blocks Part Properties Value Properties Ports Flow Ports Standard Ports Depicting Behavioral Characteristics of Blocks Operations68 2010 by JHU/APL. All Rights Reserved.
Composite Association Composite Associations depict parts that make up the Whole Black diamond on the Whole end Role names can appear on the part endFIGURE 6.569 2008 Elsevier, Inc.: A Practical Guide to SysML 2010 by JHU/APL. All Rights Reserved.
Generalization Block Definition Diagrams can beused to depict generalization andspecialization relationships Facilitates reuse The specialized block (subclass)reuses (inherits) the features of ageneralized block (superclass),and adds its own features Depicts an ‘is-a’ relationship Depicted with a closed arrowheadpointing toward the generalizedblockSuperclassSubclassSubclass 2008 Elsevier, Inc.: A Practical Guide to SysMLFIGURE 6.3570 2010 by JHU/APL. All Rights Reserved.
Value Properties Used to model quantifiable block characteristics or attributes Based on a Value Type, which describe the values for quantities Listed in compartments using the following syntax: value property name: value type name Value Properties: can have default values can also define a probability distribution for their valuesProbability DistributionDefault Value 2008 Elsevier, Inc.: A Practical Guide to SysML71FIGURE 6.22 2010 by JHU/APL. All Rights Reserved.
Ports Specifies interaction points on blocks Kinds of Ports Flow Port Specifies what can flow in or out of a block Standard Port Specifies a set of required or provided operations72
Flow Ports Flow Ports – used to describe an interaction point for items flowingin or out of a block Two types: Atomic Ports Non-atomic Ports Depicted as a box on the block borderFIGURE 6.25FIGURE 6.26 2008 E
Modeling with SysML Instructors: Sanford Friedenthal sanford.friedenthal@lmco.com Joseph Wolfrom joe.wolfrom@jhuapl.edu Tutorial pr
Systems Modeling Language (SysML) - Systems Modeling Language (SysML)7 September, 2020 Modeling Systems in Enterprise Architect Using SysML in Enterprise Architect, the process of developing a model to design or investigate a system is quick and easy, but at the same time versatile and flexible with a full implementation of the SysML specification.
the results of a case study consisting of the modeling of a UMTS transceiver using SysML. 3 Case Study: Modeling a UMTS Transceiver Using SysML To evaluate the benefits and the limitations of SysML in modeling RF and microwave front-ends, which represent an important interface between embedded systems and the
SysML Modelling Language explained Page 4 SysML defines the following diagrams: Structure diagrams o The Block Definition Diagram (BDD), replacing the UML2 class diagram o The Internal Block Diagram (IBD), replacing the UML2 composite structure diagram o The Parametric Diagram, a SysML extension to analyse critical system parameters
VR-SysML: SysML Model Visualization and Immersion in Virtual Reality Roy Oberhauser[0000-0002-7606-8226] Computer Science Dept. Aalen University Aalen, Germany e-mail: roy.oberhauser@hs-aalen.de Abstract - As systems grow in complexity, the interdisciplinary nature of systems engineering makes the visualization and
JHU Applied Physics Laboratory Colloquia November 15, 2019 www.jhuapl.edu/colloquium/archive. colloquium@jhuapl.edu . 2019 – 2020 . Stephen Moore (Author and .
Eclipse Tools Day 2019 Sébastien Revol 2 SysML is a System Modeling Language Papyrus is an Eclipse/EMF-based SysML editor CEA provides tools on top of EMF SysML models Papyrus is a central platform to edit models Different purposes : Model analysis Design automation (code generation, model transformation ) Model simulation Result analysis
Modeling these components requires a general purpose modeling language that can fit embedded systems such as systems modeling language (SysML) [7] and [16]. Authors of that work propose a TCP/IP model requirement, design and analysis using SysML. The Unified Modeling Language (UML) [27] is an object oriented modeling language, which cannot fit
Reading Comprehension GRADE 10. Student Name School Name. District Name. ELEMENTELEMENTARY & SECONDARYTARAARRY & SECONDAR&RY. Massachusetts Department of. This is a practice test. Your responses to practice test questions must be recorded on your Practice Test Answer Document. Mark only one answer for each multiple-choice question. If you are not sure of the answer, choose the answer you think .
