A Practical Guide to SysML

The Systems Modeling Language

Sanford Friedenthal, Alan Moore, Rick Steiner

• Publisher: Morgan Kaufmann
• Year: 2009
• ISBN:
  9780123838575
• Topic: Computer Science
• Subtopic: Programming Languages
• Index: Computer Science

A Practical Guide to SysML: The Systems Modeling Language is a comprehensive guide to SysML for systems and software engineers. It provides an advanced and practical resource for modeling systems with SysML. The source describes the modeling language and offers information about employing SysML in transitioning an organization or project to model-based systems engineering. The book also presents various examples to help readers understand the OMG Systems Modeling Professional (OCSMP) Certification Program. The text is organized into four parts. The first part provides an overview of systems engineering. It explains the model-based approach by comparing it with the document-based approach and providing the modeling principles. The overview of SYsML is also discussed. The second part of the book covers a comprehensive description of the language. It discusses the main concepts of model organization, parametrics, blocks, use cases, interactions, requirements, allocations, and profiles. The third part presents examples that illustrate how SysML supports different model-based procedures. The last part discusses how to transition and deploy SysML into an organization or project. It explains the integration of SysML into a systems development environment. Furthermore, it describes the category of data that are exchanged between a SysML tool and other types of tools, and the types of exchange mechanisms that can be used. It also covers the criteria that must be considered when selecting a SysML. Software and systems engineers, programmers, IT practitioners, experts, and non-experts will find this book useful.*The authoritative guide for understanding and applying SysML
*Authored by the foremost experts on the language
*Language description, examples, and quick reference guide included

PART I

Introduction

Chapter 1 Systems Engineering Overview

The Object Management Group’s OMG SysML™ [1] is a general-purpose graphical modeling language for representing systems that may include combinations of hardware, software, data, people, facilities, and natural objects. SysML supports the practice of model-based systems engineering (MBSE) that is used to develop system solutions in response to complex and often technologically challenging problems.

This chapter introduces the systems engineering approach independent of modeling concepts to set the context for how SysML is used. It describes the motivation for systems engineering, introduces the systems engineering process, and then describes a simplified automobile design example to highlight how complexity is addressed by the process. This chapter also summarizes the role of standards, such as SysML, to help codify the practice of systems engineering.

The next two chapters in Part I introduce model-based systems engineering and provide an overview of SysML. The language overview includes a simplified SysML model of the automobile design example introduced in this chapter.

1.1. Motivation for Systems Engineering

Whether it is an advanced military aircraft, a hybrid vehicle, a cell phone, or a distributed information system, today’s systems are expected to perform at levels undreamed of a generation ago. Competitive pressures demand that the systems leverage technological advances to provide continuously increasing capability at reduced costs and within shorter delivery cycles. The increased capability drives requirements for increased functionality, interoperability, performance, reliability, and smaller size.

The interconnectivity among systems also places increased demands on systems. Systems can no longer be treated as stand-alone, but behave as part of a larger whole that includes other systems as well as humans. Systems are expected to support many different uses as part of an interconnected system of systems (SoS). These uses drive evolving requirements that may not have been anticipated when the system was originally developed. An analogy can be made by looking at how the interconnectivity provided by email impacts the requirements on our day-to-day activities. Clearly, email can result in unanticipated requirements that affect who we communicate with, how often, and how we respond. The same is true for interconnected systems.

The practices to develop systems must support these increasing demands. Systems engineering is an approach that has been dominant in the aerospace and defense industry to provide system solutions to technologically challenging and mission-critical problems. The solutions often include hardware, software, data, people, and facilities. Systems engineering practices have continued to evolve to address the added complexity of the interconnected SoS challenges, which are no longer limited to aerospace and defense systems. As a result, the systems engineering approach has been gaining broader recognition and acceptance across other industries such as automotive, telecommunications, and medical equipment, to name a few.

1.2. The Systems Engineering Process

Systems engineering is a multidisciplinary approach to develop balanced system solutions in response to diverse stakeholder needs. Systems engineering includes the application of both management and technical processes to achieve this balance and mitigate risks that can impact the success of the project. The management process is applied to ensure that development cost, schedule, and technical performance objectives are met. Typical management activities include planning the technical effort, monitoring technical performance, managing risk, and controlling the system technical baseline. The technical processes are applied to specify, design, and verify the system to be built. The practice of systems engineering is not static, but continues to evolve to deal with increasing demands.

A simplified view of the systems engineering technical processes is shown in Figure 1.1. The System Specification and Design process is used to specify the system requirements and allocate the component requirements to meet stakeholder needs. The components are then designed, implemented, and tested to ensure that they conform with their requirements. The System Integration and Test process includes activities to integrate the components into the system and verify that the system requirements are satisfied. These processes are applied iteratively throughout the development of the system, with ongoing feedback between the different processes. In more complex applications, there are multiple levels of system decomposition beginning at an enterprise or SoS level. In those cases, variants of this process are applied recursively to each intermediate level of the design down to the level at which the components are purchased or built.

Figure 1.1 Simplified systems engineering technical processes.

The System Specification and Design process includes the following activities to provide a balanced system solution that satisfies the diverse stakeholders’ needs:

• Elicit and analyze stakeholder needs to understand the problem to be solved, the goals the system is intended to support, and the effectiveness measures needed to evaluate how well the system supports the goals
• Specify system functionality, interfaces, physical and performance characteristics, and other quality characteristics required of the system to support the goals and effectiveness measures
• Synthesize alternative system solutions by partitioning the system design into components that can satisfy the system requirements
• Perform trade-off analysis to evaluate and select a preferred solution that satisfies system requirements and provides the optimum balance to achieve the overall effectiveness measures
• Maintain traceability from the system goals to the system and component requirements and verification results to ensure that requirements and stakeholder needs are addressed

1.3. Typical Application of the Systems Engineering Process

The System Specification and Design process can be illustrated by applying this process to an automobile design. A multidisciplinary systems engineering team is responsible for executing this process. The participants and roles of a typical systems engineering team are discussed in Section 1.4.

The team must first identify the stakeholders and analyze their needs. Stakeholders include the purchaser of the car and the users of the car. In this example, the user includes the driver and the passengers. Each of their needs must be addressed. Stakeholder needs further depend on the particular market segment, such as a family car versus a sports car versus a utility vehicle. For this example, we assume the automobile is targeted toward a typical mid-career individual who uses the car for his or her daily transportation needs.

In addition, a key tenet of systems engineering is to address the needs of other stakeholders who may be impacted throughout the system life cycle, so additional stakeholders include the manufacturers that produce the automobile and those who maintain the automobile. Each of their concerns must be addressed to ensure a balanced life-cycle solution. Less obvious stakeholders are governments that express their needs via laws and regulations. Clearly, each stakeholder’s concern is not of equal importance, and therefore stakeholder concerns must be properly weighted. Analysis is performed to understand the needs of each stakeholder and define relevant effectiveness measures with target values. Target values are used to bound the solution space, to evaluate the alternatives, and to discriminate the solution from competitor solutions. In this example, the effectiveness measures may relate to aesthetics, performance, fuel economy, safety, reliability, repair time, and production cost.

The system requirements are specified to address stakeholder needs and associated effectiveness measures. This begins with a definition of the system boundary so that clear interfaces can be established between the system and external systems and users as shown in Figure 1.2. In this example, the driver and passengers are external users who interact with the automobile. The gas pump and maintenance equipment are examples of external systems that the vehicle interacts with. In addition, the vehicle interacts with the physical environment such as the road. All of these external systems, users, and the physical environment must be specified to clearly demarcate the system boundary and its associated interfaces.

Figure 1.2 Defining the system boundary.

The functional requirements for the automobile are specified by analyzing what the system must do to support its overall goals. This vehicle must perform functions related to accelerating, braking, and steering, and many additional functions to address driver and passenger needs. The functional analysis identifies the inputs and outputs for each function. As shown in the example in Figure 1.3, the functional requirement to accelerate the automobile requires an acceleration input from the driver and produces outputs that correspond to the automobile forces and the speedometer reading for the driver. The functional requirements analysis also includes specifying the sequence and ordering of the functions.

Figure 1.3 Specifying the functional requirements.

Functional requirements must also be evaluated to determine the required level of performance. As indicated in Figure 1.4, the automobile is required to accelerate from 0 to 60 miles ...

Table of contents

• Cover
• Title Page
• Copyright
• Table of Contents
• Preface
• About the Authors
• Chapter 1: Systems Engineering Overview
• Chapter 2: Model-Based Systems Engineering
• Chapter 3: SysML Language Overview
• Chapter 4: SysML Language Architecture
• Chapter 5: Organizing the Model with Packages
• Chapter 6: Modeling Structure with Blocks
• Chapter 7: Modeling Constraints with Parametrics
• Chapter 8: Modeling Flow-Based Behavior with Activities
• Chapter 9: Modeling Message-Based Behavior with Interactions
• Chapter 10: Modeling Event-Based Behavior with State Machines
• Chapter 11: Modeling Functionality with Use Cases
• Chapter 12: Modeling Text-Based Requirements and Their Relationship to Design
• Chapter 13: Modeling Cross-Cutting Relationships with Allocations
• Chapter 14: Customizing SysML for Specific Domains
• Chapter 15: Water Distiller Example Using Functional Analysis
• Chapter 16: Residential Security System Example Using the Object-Oriented Systems Engineering Method
• Chapter 17: Integrating SysML into a Systems Development Environment
• Chapter 18: Deploying SysML into an Organization
• Appendix: SysML Reference Guide
• References
• Index