SysML Workbook – MagicDrawasattepress.com/Downloads/Tutorials/QA-Test-2015-N2-Intro-SysML... · 2. Add it directly from the Containment browser. Actually, there is a third method

SysML Workbook – MagicDraw

V1.0.1 – 17 July 2017 Copyright© 2015 i

Twitter: #QAT15SysML


David Hetherington


V1.0.1 – 17 July 2017 Copyright© 2015 ii


Table of Contents

Overview of the Space Chessboard System .............................................................. 1

What You Will Need .............................................................................................................. 1

Our Sample System – the Space Chessboard ........................................................................ 2

Step 1 – Creating Your First SysML Model ................................................................... 3

Hello World ............................................................................................................................ 3

Renaming the Model ............................................................................................................. 4

Adding Packages .................................................................................................................... 6

Step 2 – Requirements ................................................................................................ 14

Importing From a CSV File ................................................................................................. 15

Setting Up Your Project File ......................................................................................................... 15

Understanding CSV files ............................................................................................................... 15

Turning Off Element Auto-Numbering .............................................................................. 16

Importing From a CSV File ................................................................................................. 17

Organize the Requirements............................................................................................ 22

Making Copies of Requirements ................................................................................... 24

Creating a Requirements Diagram ............................................................................... 29

Saving a Copy of the Diagram for PowerPoint........................................................... 32

Clarifying a Single Requirement .................................................................................... 34

Clarifying Conflicting Requirements ............................................................................. 35

Adding Sub-Requirements ............................................................................................. 38

Step 3 – Modeling the Structure of the System ......................................................... 40

Setting Up Your Project File ........................................................................................................ 40

System Context ..................................................................................................................... 40

Modeling the Basic System - Composition ......................................................................... 46

Aggregation – Game Participants ........................................................................................ 51

Generalization – Types of Pieces and Spaces ...................................................................... 52


V1.0.1 – 17 July 2017 Copyright© 2015 iii


Step 4 – Elaborating and Allocating Requirements ................................................. 54


Chess Pieces and Board – A Closer Look ............................................................................ 56

Finish Up the Initial Clarification ........................................................................................ 56

Clean Up System Structure .................................................................................................. 58

Exporting the Clarified Requirements ................................................................................ 59

Iterative Design and Requirements Allocation ................................................................... 62

The Vodka Detector ..................................................................................................................... 62

Piece Retention ............................................................................................................................ 63

Step 5 – Use Cases ...................................................................................................... 66

About Use Cases .................................................................................................................. 66

Make a Use Case Diagram .................................................................................................. 67


Create a Use Case Diagram ......................................................................................................... 67

Allocate Requirements to Use Cases ................................................................................... 69

Step 6 – Interfaces and Sequence Diagrams ........................................................... 70

Interfaces .............................................................................................................................. 70


Add an Interface ................................................................................................................... 70

Allocating Requirements to the Interface ............................................................................ 72

Make a Sequence Diagram for the Interface ....................................................................... 73

Step 7 – Test Case ....................................................................................................... 76

Add Test Case to a Requirements Diagram ........................................................................ 76


Create a Hierarchical Test Plan for the Piece .............................................................................. 76

Adding a Child Activity Diagram ........................................................................................ 77


V1.0.1 – 17 July 2017 Copyright© 2015 1


Overview of the Space Chessboard System During the next three hours, we are going to do a quick flyover of SysML with a specific tool (MagicDraw in this case) as well as give a brief taste of the idea of a traceable methodology for going from initial requirements all the way to test cases.

Clearly, this short tutorial is NOT going to make you an expert in anything. The goals of this tutorial are simple:

1. Glimpse of Requirements Traceability – for a beginner who is unfamiliar with the topic, this tutorial will provide just enough of an example so that the beginner can imagine the benefits and effort involved.

2. Glimpse of SysML – this tutorial will give beginner a short introduction to Model-Based Systems Engineering (MBSE) and the SysML modeling language.

3. “Start Here” Example for the Tool – SysML is great stuff. Unfortunately, the tools are really complicated. Such tools are usually general-purpose UML tools that have been extended to support dozens of modeling languages. Even though they come with thousands of pages of user documentation, it can be really difficult for even a highly technical user to figure out how to get started and make the “Hello World” SysML model. This tutorial will provide this sort of step-by-step introduction to creating your first model with MagicDraw.

What You Will Need In addition to the tutorial materials, you will need a copy of MagicDraw

The key point here is that you need the SysML Plugin:

http://www.nomagic.com/products/magicdraw-addons/sysml-plugin.html

which in turn requires MagicDraw Standard, Professional, Architect or Enterprise Editions.

This tutorial was prepared with:

• MagicDraw Professional Java Edition 18.2

• MagicDraw SysML Plugin 18.2

Earlies versions of MagicDraw may be able to support the activities of the tutorial, but may not be able to open the version 18.2 compatible model files provided in the tutorial materials.

http://www.nomagic.com/products/magicdraw-addons/sysml-plugin.html


V1.0.1 – 17 July 2017 Copyright© 2015 2


Our Sample System – the Space Chessboard

Figure 1 - The Space Chessboard1

Our sample system is the “Space Chessboard” This system is planned for the next long-haul space mission planned to visit the planet Saturn. Since the astronauts will be onboard the spaceship for several years, our space agency has decided that it is important to provide them with some entertainment that will help keep them mentally sharp.

As we dig into the requirements and design of this system, we will find that there are a number of interesting requirements for the system. First of all, we don’t want the pieces to float randomly around the cabin. As such there is a requirement that the chessboard somehow mechanically retain the pieces when the players are not moving them. There is also a design goal that the players be able to play the game while in their bulky spacewalk suits. Finally, the mission psychologist is very interested in monitoring the players as they play to assess stress levels and mental health.

1 Image Source: https://commons.wikimedia.org/wiki/File:Chess_board_with_chess_set_in_opening_position_2012_PD_05.jpg

https://commons.wikimedia.org/wiki/File:Chess_board_with_chess_set_in_opening_position_2012_PD_05.jpg


V1.0.1 – 17 July 2017 Copyright© 2015 3


Step 1 – Creating Your First SysML Model

Hello World Start MagicDraw. I usually simply dismiss the start page:

Pull down “File” and click “New Project”

1. Select “SysML Project”


V1.0.1 – 17 July 2017 Copyright© 2015 4


2. Name the project

3. Select the project directory, if necessary using the three dots button to navigate to the right location.

4. Click “OK”

Your new (empty) model will appear in the Containment Tree browser:

Renaming the Model One of the nice things about SysML is that everything can be named to be easy to understand for your stakeholders. The term “Data” is very generic. Let’s re-name it.

Double click on the word “Data” which as it happens is the root of the SysML model tree.


V1.0.1 – 17 July 2017 Copyright© 2015 5


The model properties dialog box will appear. Click next to “Data” in the “Name” field.


V1.0.1 – 17 July 2017 Copyright© 2015 6


Replace “Data” with “Requirements and Test Cases Model” and click “Close”

Adding Packages Now we have a ready-to-go, empty model. Now we can add some packages to it. In doing so, we will demonstrate a few different ways of doing things in the tool.

First let’s add an empty diagram.


V1.0.1 – 17 July 2017 Copyright© 2015 7


Right click on the model, select “Create Diagram”, select “SysML Diagrams”, and select “SysML Package Diagram”

Name the untitled diagram “Model Packages”


V1.0.1 – 17 July 2017 Copyright© 2015 8


You will now have a properly titled package diagram in the right-hand diagram pane. Notice that the name “Model Packages” shows in three places:

1. The package diagram is a top-level element of the model as shown in the left-hand containment tree browser.

2. The name is shown on the tab for the diagram. As we open more diagrams, these tabs will be very helpful.

3. The name is included in the SysML frame for the diagram. MagicDraw is one of the few tools that properly draws the diagram frame per the SysML specification.

The first thing we will do is drag the top-level model itself (which is also a package) to the diagram. Simply grab the element: “Requirements and Test Cases Model” and drag it onto the diagram.

Why can we do this? In SysML, everything is contained within a package and in fact the top-level model is itself a package, so it makes perfect sense to add it to a package diagram.


V1.0.1 – 17 July 2017 Copyright© 2015 9


Next we will add a package from the tool pallete.

Grab the Package element in the tool pallete and drag it onto the diagram as shown.

Click inside the new package …. And ignore the unhelpful popup box. Name the package “Requirements”


V1.0.1 – 17 July 2017 Copyright© 2015 10


Once we are done, we will see that the “Requirements” package is visible in two places:

1. In the Containment browser

2. As an element in the diagram

Now we are going to learn something about SysML modeling tools: there are always two ways to add something to the model:

1. Drag something onto a diagram

2. Add it directly from the Containment browser.

Actually, there is a third method and that is to import from a file, but we will get to that a little later on. Next we will practice adding something from the Containment browser. We will add another package called “Structure” to the model.


V1.0.1 – 17 July 2017 Copyright© 2015 11


Right-click on the model, click “Create Element”, and select “Package”

Click in the empty box and name the package “Structure”

A key point is that the new “Structure” package does NOT automatically show up in the diagram. This is a key point of Model-Based Systems Engineering (MBSE):

1. The Model (as shown in the Containment browser) is the “Truth” and contains everything

2. Individual diagrams show only those parts of the model that we think are helpful for one specific stakeholder to understand the model.


V1.0.1 – 17 July 2017 Copyright© 2015 12


Got it. However, we have now decided that our stakeholder for the “Model Packages” diagram does indeed need to see all of the top-level packages in the model when she looks at the “Model Packages” diagram. Go ahead and drag the “Structure” package from the Containment browser into the diagram.

Add three more packages to the model in the same way:

• Use Cases

• Behavior

• Test Cases

Notice that you may have to drag the elements around in the diagram to make them look neat. Just like PowerPoint, the tool has a number of features to align and distribute things.

Now, let’s save a copy of our project.


V1.0.1 – 17 July 2017 Copyright© 2015 13


Now, if you successfully completed Step 1, save the project as shown. This will be the basis for the next step in the tutorial. If you didn’t complete it, no need to worry, there is a copy of “Space Chessboard – Step 1.mdzip” in the tutorial materials. In this case, you can save your work as “Step 1 – Not Quite Done Yet.mdzip” or something.

Note: If we actually had a source code control system setup, we would not do all of this file renaming. *.mdzip files can be managed quite nicely with most source code control systems


V1.0.1 – 17 July 2017 Copyright© 2015 14


Step 2 – Requirements Great! We have our packages setup and we are ready to start tackling the requirements!

The various stakeholders have been giving input to the systems engineering team. Take a look at the file “Space Chessboard Requirements.xlsx”

Read through the requirements carefully and get a feel for the concerns of the different stakeholders.

All done?

Did you notice anything?

For example, did you notice that: The Requirements Are a Complete MESS!!! (?)

If you have recently graduated from university and are shocked to find that the requirements are a complete mess: Welcome to the real world of systems engineering!


V1.0.1 – 17 July 2017 Copyright© 2015 15


Importing From a CSV File OK. The requirements are vague, confusing, contradictory – in short, business as usual for a systems engineering project.

Before we get started, however, I need to comment that getting things in and out of Microsoft Excel is the bane of every SysML tool. On some level, the problem is unsolvable. Spreadsheets are complicated and have random formats. SysML models are also complicated and have a structure that does not really resemble a spreadsheet. The problem is made worse by the fact that SysML is not really a native entity but rather a profile on top of UML, which tends to make the situation even more complicated. Finally, no tool vendor wants to write a dedicated import/export function just for SysML requirements. Instead, they usually write a fully generalized interface for any sort of UML entity to and from any format of spreadsheet…

…and these things are COMPLICATED!!….fasten your seatbelt…

Setting Up Your Project File First, however, let’s make sure you have a clean copy of the results of the Step 1 exercise above.

If you did not fully complete Step 1, copy the file “Space Chessboard - Step 1.mdzip” from the tutorial materials to your project directory and rename it “Space Chessboard.mdzip”

Understanding CSV files MagicDraw CSV import does not work with standard Excel files, but rather with so-called CSV (comma separated value) files. Above we looked at the file “Space Chessboard Requirements.xlsx” from the tutorial materials. You will notice that there is another file “Space Chessboard Requirements.csv” If you double-click on this file, Microsoft Excel will open it. It will look like the XLSX file except that it will have forgotten all the formatting. The reason there is no formatting is that this is actually a much simpler text format. You can open the CSV file with Notepad or any text editor. It will look like this:

All the information is simple text. Each row is on a separate line. Columns are separated by commas.

CSV files are very handy and flexible because they are so simple. However, they do have some vulnerabilities. For example, if your text has commas inside the text, the CSV files will get messy. You can see an example of


V1.0.1 – 17 July 2017 Copyright© 2015 16


this problem on the last line of the file above. Even worse are embedded carriage return characters…which can get into your data if you copy–and-paste a block of formatted text into a cell in your Excel spreadsheet.

The easiest way to work with CSV files is usually to keep a master copy of your information in an XLSX file and have Excel export it to CSV just before you need to use it.

Turning Off Element Auto-Numbering As a general purpose tool, MagicDraw has one feature that we need to turn off if we want to do any sort of normal project requirements work and that is element auto-numbering.

Select “Options” and click on “Project”

1. Select “General project options”

2. Scroll down to “Use Element Auto-numbering”

3. Unselect this option

4. Click “OK”


V1.0.1 – 17 July 2017 Copyright© 2015 17


Importing From a CSV File

Pull down “File”, select “Import From” and “Import CSV”


V1.0.1 – 17 July 2017 Copyright© 2015 18


1. Click on choose file.

2. Navigate to and select the file “Space Chessboard Requirements.csv”

3. Under “Target Package” select “Requirements” The imported requirements will land here.

4. Under “Target Element Type” select “Class” – Huh?!! Not “Requirement”?! Yes. The problem is that SysML is actually a profile on top of UML. The real element type is the UML Class. “Requirement” is a stereotype of “Class”.

5. Under “Target Stereotype” select “Requirement” – This is where we close the loop. “Requirement” is a stereotype of “Class”.

6. Click “Next”


V1.0.1 – 17 July 2017 Copyright© 2015 19


Make sure “Use First Row as Header” is selected. Notice that MagicDraw has already previewed the file and figured out what columns are available. We actually only need three of the four columns. Next we need to map them to the relevant three elements in the massive list of possible elements at the left.

1. Select the column of ID numbers under “ID” in the “CSV Data” area.

2. Scroll down and select “Id” in the “Properties” Window.

3. Click “Add”.


V1.0.1 – 17 July 2017 Copyright© 2015 20


1. Select the column of requirement titles under “Title” in the “CSV Data” area.

2. Scroll down and select “name” in the “Properties” Window.

3. Click “Add”.

1. Select the column of requirement descriptions under “Requirement” in the “CSV Data” area.

2. Scroll down and select “Text” in the “Properties” Window.

3. Click “Add”.


V1.0.1 – 17 July 2017 Copyright© 2015 21


The mapping is ready. Notice that the columns of the CSV file are now mapped to the UML/SysML properties for the items to be imported. Click “Finish”

The status of the import operation is shown in the Notification Window. Also, the “Requirements” package turns blue to let you know that you have unsaved changes to the model in that package. Expanding the “Requirements” package shows that all the requirements have been properly loaded.


V1.0.1 – 17 July 2017 Copyright© 2015 22


Organize the Requirements Clearly some of the requirements are going to need to be clarified, extended, and/or rewritten. On the other hand, we don’t want to lose track of the “raw” original requirements as stated by the stakeholders. Let’s separate the requirements into “original” and “clarified” by creating some subpackages.

Right-click on “Requirements”, select “Create Element” and select “Package”

Name the package. Create an additional subpackage (also in “Requirements”) called “Clarified Requirements”.


V1.0.1 – 17 July 2017 Copyright© 2015 23


Select all of the requirements and drag them into the “Original Requirements” subpackage. Nice and neat.


V1.0.1 – 17 July 2017 Copyright© 2015 24


Making Copies of Requirements Taking a look at the original requirements, we can see that the “Vodka Detection” requirement is pretty straightforward. Let’s make a copy of it in “Clarified Requirements”

Select “Vodka Detection” in the Original Requirements folder. Right-click and select “Copy”


V1.0.1 – 17 July 2017 Copyright© 2015 25


Now, right-click on “Clarified Requirements”, select Paste”


V1.0.1 – 17 July 2017 Copyright© 2015 26


Voila! Our new requirement is there. However, we will want to clean up two problems with the new requirement:

1. ID – we really do NOT want to who two different requirement elements in the system with the same id. We will need to invent a numbering scheme. Numbering schemes seem like a stupid and trivial problem, but in large organizations they are difficult and critical at the same time! You need to think carefully about your numbering scheme goals (!) Our scheme will work like this:

a. Requirements that are merely copied (like this one) will prepend the number with “CPY-“

b. Requirements that are significantly clarified will prepend the number with “CLR-“

c. Requirements that merge two or more previous will get a new scheme “MRG-00n” where “n” is the number of the merged requirement.

2. Text – our stakeholders have a typical organizational “Tower of Babel” problem. Each team is calling the system something else. We will correct all requirements to call the system “Space Chessboard”

Double-Click on the new copy of “Vodka Detection”


V1.0.1 – 17 July 2017 Copyright© 2015 27


A panel of requirement properties will appear. If you click near “SAF-003” MagicDraw will display a three-dot button. You MIGHT be tempted to believe that this action would allow you to edit the value of the ID. You would be mistaken. Doing this will only lead you around in circles helplessly clicking on panel after panel, none of which let you edit the value.

The correct approach requires you to understand that SysML is not a native standard, but rather a layer on top of UML. What seems to be a “requirement” is actually a UML “Class” with some extra “Tags” for things that are not normally part of a UML Class.

The right way to edit the SysML requirement is to look in the “Tags” section of the properties.

Make sure “Properties” is set to “All” and click on “Tags”


V1.0.1 – 17 July 2017 Copyright© 2015 28


Scroll down to and select “Id”. Add “CPY-” to the ID. Click “Close”

Fix the requirement text to read “Space Chessboard” and click “Close”


V1.0.1 – 17 July 2017 Copyright© 2015 29


Creating a Requirements Diagram OK, we now have a requirement in two versions: an original, and a slightly-corrected (but not substantively changed) version. How are we going to explain that to the Safety department? Those guys can get pretty upset if they think you are ignoring their requirements input! (?)

Model-Based Systems Engineering (MBSE) to the rescue! We can make a diagram, that is coupled to the model just for the Safety department!

Where should we put the diagram? It really doesn’t matter, but I am a “Neat Freak” so I like to make another package just for this purpose. Right-Click on the “Requirements” package and add another subpackage called “Clarification Diagrams”. (See above for the procedure).

Right-click on the new subpackage and select “Create Diagram”, “Requirements Diagrams”, “Requirement Diagram”

Name the diagram “Safety Requirement Clarifications”


V1.0.1 – 17 July 2017 Copyright© 2015 30


The diagram is now there. Notice that we can see the name of the diagram in three places:

1. The Containment Tree

2. The tab in the diagrams pane

3. The SysML diagram frame as per the SysML standard.

Drag the clarified “Vodka Detection” requirement from the “Clarified Requirements” subpackage to the diagram.

Drag the original “Vodka Detection” requirement from the “Original Requirements” subpackage to the diagram.


V1.0.1 – 17 July 2017 Copyright© 2015 31


You now should have something that looks like this

Now we will want to add a SysML relationship between these two requirements for traceability purposes.

Click on the “Copy” tool in the Tool Palette. Drag a relationship from the clarified requirement to the original requirement as shown.

Congratulations! You know have a traceable requirement!


V1.0.1 – 17 July 2017 Copyright© 2015 32


Saving a Copy of the Diagram for PowerPoint Wait! The meeting with the Safety department is in 10 minutes and they are hopping mad because they heard a rumor that you have been ignoring their requirements! Quick, we need to make something for PowerPoint.

Pull down “File” and select “Save as Image…”

1. Select “Active Diagram”

2. Name the image file

3. I recommend PNG (lossless compression) rather than JPEG which is good for human face photos but bad for things like line art with sharp edges. MagicDraw also supports SVG (Scalable Vector Graphics) which is wonderful if you are working with something like InkScape, but not so useful for Microsoft Office.


V1.0.1 – 17 July 2017 Copyright© 2015 33


4. Click “Options”

5. Here you can move the sliders around to get your desired tradeoff between image sharpness and file

size. The defaults for this diagram yielded a very compact 17KB file that was too fuzzy for my taste. These values yielded a 128KB file which was much sharper:

Once you have the files exported to your liking, you can use the standard Office “Insert Picture” functions to add them to your document.


V1.0.1 – 17 July 2017 Copyright© 2015 34


Clarifying a Single Requirement What if a requirement needs some clarification? The “ERG-004 Piece Movement” requirement is a candidate. What does “easy” mean?! After some discussion with the stakeholders, it is decided that the meaning of easy should be: “Does not require more than 1/20th of a Newton of force to move”.

1. Using the procedure above, copy-and-paste the “ERG-004 Piece Movement” requirement from the “Original Requirements” to the “Clarified Requirements” folder. By the way, notice that the Ergonomics department actually labelled two requirements as “Piece Movement” One of them should really be “Piece Mass”. We should really clean that up by creating a copy as described above. However, for the moment just be sure you copy the right requirement by inspecting the requirement properties in the “Original Requirements” package before you copy it.

2. Edit the properties of the requirement in the “Clarified Requirements” package:

a. Add the “CLR-“ prefix to the ID

b. Change the text of the requirement to “Pieces shall require less than 1/20th of a Newton of force to move.”

3. In the “Clarification Diagrams” package, add a new requirements diagram called: “Ergonomic Requirement Clarifications”

4. Drag original and clarified requirements to the diagram and fixup the format as before.

5. Add a SysML “refine” relationship between them.

While we are at it, let’s deal with that poorly-named second copy of “Piece Movement”. Do the same thing, but rename the clarified requirement “Piece Mass”. In my opinion, renaming the requirement crosses the border between “copy” and “refine” so again use the “refine” relationship. You can add these both to the same diagram.

When you are done, you should have something that looks like this:

Notice the blue highlighted items in the Containment tree. These are new or changed items. The original requirements are also blue (even though they were not changed) because they have new relationships.


V1.0.1 – 17 July 2017 Copyright© 2015 35


Clarifying Conflicting Requirements If we look back at the requirements, we can see that ERG-001 and PSY-003 are in direct conflict. The Ergonomics department thinks that the astronauts should be in control of how much time is allocated for each move on the chess clock – after all, what could be less ergonomic than a parameter like that which the user can’t control?! On the other hand, the Mission Psychology department firmly believes that they should be able to control the time – what if the astronauts are slowly losing their marbles? The psychologists definitely feel like they should be able to adjust the move time allocation in order to assess astronaut cognition and stress levels.

After a long debate and some level of management escalation, it is decided that both should be able to control the time-per-move parameter, but that the mission psychologist should have precedence in the event of a conflict.

1. In the “Clarification Diagrams” package, create a new requirements diagram called: “Chess Clock Time-per-Move”

2. Drag both conflicting requirements to the left side of the diagram and fix up the format.

3. From the Tool Palette, drag a requirement onto the diagram.


V1.0.1 – 17 July 2017 Copyright© 2015 36


4. Double-click the new requirement on the diagram to open its specification.

5. Click on the “<>” at the top of the properties tree. Name the requirement: “Move Time Control”.

Click “Close”.


V1.0.1 – 17 July 2017 Copyright© 2015 37


6. Double-click on the requirement in the diagram again.

7. Set the ID to “MRG-001” and set text to “Mission psychologist and astronaut shall both be able to

control the time-per-move with the mission psychologist having precedence.” Click “Close”

8. Drag SysML “derive” relationships from the new requirement to both of the original requirements. The result should look like this:


V1.0.1 – 17 July 2017 Copyright© 2015 38


9. Oh…and yes…there is one remaining “Neat Freak” thing to clean up. Since we did not tell it otherwise, the tool created the new requirement in the “Clarification Diagrams” package. Drag the requirement to the “Clarified Requirements” package where it belongs.

Adding Sub-Requirements What about requirements that need to contain more detail? We will want to add subrequirements.

Requirement MEC-001 needs some work. First, our mechanical engineers don’t play chess and they have the wrong number of spaces. They also forgot to mention that some spaces are black and some are white.

1. Using the procedure above, copy-and-paste the “MEC-001 Spaces” requirement from the “Original Requirements” to the “Clarified Requirements” folder.

2. Edit the properties of the requirement in the “Clarified Requirements” package:

a. Add the “CLR-“ prefix to the ID

b. Change the text of the requirement to “The space chessboard shall have 64 spaces.”

3. In the “Clarification Diagrams” package, add a new requirements diagram called: “Chessboard Layout”

4. Drag original and clarified requirements to the diagram and fixup the format as before.

5. Add a SysML “refine” relationship between them.

6. Drag a requirement to the diagram from the Tool Palette.

a. Name it “White Spaces”

b. Give it the ID “CLR-MEC-001.a”

c. Give it the text “The Space Chessboard shall have 32 white spaces.”

7. Add a similar requirement for black spaces with the ID “CLR-MEC-001.b”

8. In the Containment Tree, drag the two new requirements from the “Clarification Diagrams” package to the “Clarified Requirements” package.


V1.0.1 – 17 July 2017 Copyright© 2015 39


So far, we have something that looks like this. The requirements are there, but they are not coordinated…

Drag a containment relationship from the black and white requirements to the “CLR-MEC-001” requirement.

Notice that the “black” and “white” requirements are now nested under the “spaces” requirement in the Containment Tree.

That ends Step 2. Before continuing, save a copy of the project as “Space Chessboard - Step 2.mdzip”


V1.0.1 – 17 July 2017 Copyright© 2015 40


Step 3 – Modeling the Structure of the System In Step 2, we were able to setup some requirements for our system. Next we will start modeling the structure of the system itself.

Setting Up Your Project File Were you able to complete Step 2 above?


System Context First we will draw an understanding of the context of the system. Who are the stakeholders? What does it connect to?

Right-click on the “Structure” package and add a SysML Block Definition Diagram.

Name the diagram “System Context”.


V1.0.1 – 17 July 2017 Copyright© 2015 41


Right-click on the “Structure” package and add a “Block”

1. Name the element “Space Chessboard System”

2. Drag the new element from the Containment Tree to the center of the diagram.

Next let’s add a boundary around the system. At this point we need to explain that the boundary is not actually part of the SysML specification. However, most system engineers want to add boundaries around elements in this sort of diagram, so most tools (including MagicDraw) provide a feature to do so.

1. In the “Common” section of the Tool Palette, find “Horizontal Separator”.

2. Pull down to expand and select “Rectangular Shape”

3. Drag to add the boundary around the “Space Chessboard System”.


V1.0.1 – 17 July 2017 Copyright© 2015 42


As we can see, a boundary has been added to the diagram. However, nothing in particular has been added to the model in the Containment Tree because the boundary is not actually an official SysML element.

Next, add another element to the “Structure” package.

1. Right-click on “Structure” and add an “Actor”

2. Name the actor: “Astronaut”

3. Drag the astronaut from the Containment Tree to the upper left part of the diagram.


V1.0.1 – 17 July 2017 Copyright© 2015 43


Next we want to add an “Association” to the diagram. Depending on what state MagicDraw is in, this may be hidden underneath “Directed Association”. If so, pull down and select “Association” as shown.

Drag a reference association from the Astronaut to the Space Chessboard System.

The reference association is the most basic relationship in SysML. It has a flexible and light meaning, but it also serves as the anchor for modeling interfaces later.


V1.0.1 – 17 July 2017 Copyright© 2015 44


If you would rather have a straight line from the “Astronaut” to the “Space Chessboard System”:

1. Click on the select icon in the top left corner of the Tool Palette.

2. Right-click on the line.

3. Select “Remove Break Points”

Look back at the requirements. Are there any other human stakeholders? Certainly, we can see a mission psychologist. Let’s add the mission psychologist to the model and to the diagram. Hint: copy-paste-rename the Astronaut in the Containment Tree and you will save a lot of steps.

How about external systems? Reading the requirements, we can see at least three of these:

1. Mission Psychology System

2. Mission Security System


V1.0.1 – 17 July 2017 Copyright© 2015 45


3. Training System

Let’s add blocks for these and put them on the right side of the diagram.

Add associations between these external systems and the Space Chessboard System.

As you start adding the associations, you will notice that MagicDraw wants to add role labels to each end of the association. These labels don’t hurt anything, but they do clutter up the diagram. You can simply click on the labels and delete them.

Our System Context diagram is complete for the moment. Why is this diagram important? Experienced systems engineers will always make a diagram like this for two reasons:

1. It identifies things that are NOT part of the system we are trying to design. This point may sound trivial, but in a more complicated system, not having a clear “fence” around your system can lead to big arguments with the stakeholders about what is and what is not in the scope of the project.

2. It identifies interfaces that will need definition.


V1.0.1 – 17 July 2017 Copyright© 2015 46


Modeling the Basic System - Composition Now we are ready to take a closer look at the Space Chessboard System itself. In our first pass of modeling, we discover that the Space Chessboard System consists of:

1. A board

2. A Chess Clock

3. 32 pieces

Let’s model the structure of this.

1. Add another diagram to “Structure” called “Chessboard System Structure”

2. Drag the block “Space Chessboard System” to the diagram.

3. Wow. That block is looking pretty complicated. Furthermore, it is going to get worse as we add all

sorts of relationships. Let’s turn off the compartments.

a. Select “Options” and “Project”


V1.0.1 – 17 July 2017 Copyright© 2015 47


b. Scroll down and suppress all of the compartments.

4. At any rate, back to our diagram..

5. Add blocks to “Structure” for “Board”, “Chess Clock”, and “Piece” and drag them to the diagram.

.

Looks good. Except, why did we use the singular “Piece” when we know that we have 32 “Pieces”? The reason, is we are going to model that relationship explicitly.


V1.0.1 – 17 July 2017 Copyright© 2015 48


What we need next is the “Composition” relationship, which may be hidden beneath “Directed Composition”.

Select the Composition relationship. Drag from the “Space Chessboard System” to “Board”. Delete the labels. Remove the line breakpoints.

(Note that the direction of dragging things is important in all SysML tools and not necessarily consistent from tool to tool)

Next we will handle the problem of letting the model know that we have 32 pieces.


V1.0.1 – 17 July 2017 Copyright© 2015 49


1. Make sure the “select” tool is enabled in the upper-left corner of the Tool Palette.

2. Double-click on the black diamond relationship between “Space Chessboard” and “Piece”


V1.0.1 – 17 July 2017 Copyright© 2015 50


Now we can set the “multiplicity” for each end of the relationship. Notice that the panel shows us one section for each end of the relationship. Set the multiplicity for the “Space Chessboard System” to 1. Set the multiplicity for the “Piece” to 32. Now we have modeled the idea that 32 pieces go with 1 chessboard.

Set all multiplicities to 1 for the other two relationships.


V1.0.1 – 17 July 2017 Copyright© 2015 51


Composition has a meaning along the lines of “consists of” or “is made of”. Here we can see both in the diagram and in the Containment Tree that the Space Chessboard System consists of one board, one chess clock, and 32 pieces. This is a strong association. If you instruct your employee to “Discard the Space Chessboard System” you will expect that employee to discard the board, the chess clock, and all 32 pieces.

Aggregation – Game Participants What about the players? They certainly have a role in the system, but discarding the system would not cause the players to cease to exist. This sort of role is “aggregation”.

1. Add an Actor to the “Structure” package called “Player”

2. Drag that Actor to the upper left side of the diagram.

3. Select the “aggregation” relationship from the Tool Palette.

4. Drag an aggregation relationship from the Player to the Space Chessboard System.

5. Set the multiplicity for the Space Chessboard System end to 1 again.

6. Set the multiplicity for the Player end to “0..2” meaning “between 0 and 2 Players”

7. Note that you may need to drag the numbers around to get them in the right place.


V1.0.1 – 17 July 2017 Copyright© 2015 52


“Aggregation” indicates a sort of reference relationship. When your employee discards the “Space Chessboard System” he does not discard any of the players.

Generalization – Types of Pieces and Spaces What about pieces? Don’t we want to add more detail? Yes. Generalization will allow us to create more specific types of pieces.

1. Add another Block Definition Diagram to the “Structure” package and name it “Types of Pieces”

2. Drag the “Piece” block onto the diagram.

3. Create blocks for “Pawn”, “Rook”, “Knight”, “Bishop”, “Queen” and “King” and drag them onto the diagram as well.

4. Find the “Generalization” relationship in the Tool Palette. (It may be underneath “Directed Generalization”)

5. Drag a generalization relationship from the Pawn block to the Piece block. (Notice the direction of dragging is opposite from Composition)

6. Repeat for all the other types of pieces.


V1.0.1 – 17 July 2017 Copyright© 2015 53


This relationship is the “is a kind of” relationship. That is: “Knight is a kind of Piece”

(Note that in UML Land, they speak a different sort of language which can be a bit obtuse for normal humans. UMLians will generally say something like: “Piece generalizes Knight”)

Make a similar diagram called “Types of Spaces” to show black and white spaces as the specific cases of the more general space.

This ends Step 3. Before continuing, save a copy of the project as “Space Chessboard - Step 3.mdzip”


V1.0.1 – 17 July 2017 Copyright© 2015 54


Step 4 – Elaborating and Allocating Requirements One thing missing from most SysML textbooks is a strategy for elaborating and allocating requirements for different levels of the system. Requirements engineering textbooks, on the other hand, recommend something like this: “Keep refining and elaborating until you have requirements that require exactly one thing that can be satisfied by exactly one unique component” These are called “Leaf Requirements”.

Putting those two ideas together, you might imagine something like this:

This is sort of acceptable, but we can see two things from this diagram:

1. Parallel Activity – elaboration of the requirements is going to have to proceed in parallel/coordination with elaboration of the system design. This is definitely going to be a “throw it over the wall” waterfall-style activity.

2. Accountability – Using this sort of approach, you don’t make any formal connection between the requirements and the system until you get to the bottom -> The very end of the process!

3. Overview – What about that “Sandwich Eating Subsystem”? There is no way to get an overview of the requirements that its modules are responsible for.

Well, item (1) is simply a fact. As for (2) and (3) we can solve these problems by using the Hetherington method, which looks like this:


V1.0.1 – 17 July 2017 Copyright© 2015 55


“Allocate” is a more flexible relationship than “Satisfy”. In this manner, the requirements team can work in parallel with the system design team, gradually refining both the requirements and design while maintaining continuous synchronization between the two streams.

That is, the deeper you go into the system design, the fewer “allocate” and the more “satisfy” relationships you will encounter.




V1.0.1 – 17 July 2017 Copyright© 2015 56


Chess Pieces and Board – A Closer Look Let’s take a closer look at the chess pieces and the chess board.

A quick inspection of the original requirements reveals several that are definitely going to affect the design of the board and the pieces. We have already clarified a few of these. Let’s finish up the initial clarification.

Finish Up the Initial Clarification Let’s see, we already clarified ERG-002 and ERG-004. Let’s take care of ERG-003. A simple copy should be sufficient.

1. Copy-and-Paste ERG-003 from “Original Requirements” to “Clarified Requirements”

2. Change the ID of the new requirement to “CPY-ERG-003”

3. Open the diagram: “Ergonomic Requirement Clarifications”

4. Add both the original and the copy to this diagram.

5. Add a SysML “Copy” relationship from the clarified to the original requirement.

Department ID Title RequirementErgonomic Engineering ERG-002 Piece Movement All chess pieces shall have a mass of less than 50 grams.Ergonomic Engineering ERG-003 Piece Size Pieces shall be large enough to be grasped by astronauts in full spacewalk

gear.Ergonomic Engineering ERG-004 Piece Movement Pieces shall be easy to move.Mechanical Engineering MEC-001 Spaces The space chessboard shall have 100 spaces.Mechanical Engineering MEC-002 Coffee Spills The space chessboard shall be impervious to coffee spills.Safety SAF-001 Piece Retention The astronaut idle time consumption system shall mechanically retain

pieces at all times to prevent them from drifting around the cabin Training TRN-002 Next Move Lighting In training mode, when the astronaut touches a piece, the training system

shall light up all possible movement paths for that piece.


V1.0.1 – 17 July 2017 Copyright© 2015 57


Let’s see, MEC-001 was already clarified. Let’s make copies of MEC-002 and SAF-001 and add them to the diagram “Safety Requirement Clarifications”

Create a new requirements diagram called “Training Clarifications” and make a copy TRN-002.

Great! Now we have a complete set of clarified requirements…at least for the next task…and we can turn our attention to the system structure.


V1.0.1 – 17 July 2017 Copyright© 2015 58


Clean Up System Structure If we now look at the “Structure” package in the Containment Tree, we can see that it is getting a little messy. Let’s clean it up a little.

1. Create a subpackage called “Top-Level Structure Diagrams”

2. Move the diagrams “System Context” and “Chessboard System Structure” into this subpackage.

3. Create a subpackage called “Actors” and move the three actors into that subpackage.

4. Create a subpackage called “Board” and move the diagram “Types of Spaces” as well as the blocks “Board”, “Space”, “Black Space”, and “White Space” into that subpackage.

5. Create a subpackage called “External Systems” and move the three external systems into that subpackage.

6. Create a subpackage called “Clock” and move the block “Chess Clock” into that subpackage

7. Create a subpackage called “Pieces” and move the diagram “Types of Pieces” as well as all the pieces block into that.

8. The cleaned up “Structure” package should look like this:

9. Collapse and expand each subpackage. Does everything seem to be in the right place? If not, move

items around as needed.


V1.0.1 – 17 July 2017 Copyright© 2015 59


Exporting the Clarified Requirements At this point, it would be handy to have a fresh copy of the clarified requirements.

One of the weaknesses of MagicDraw is the lack of a generic export to spreadsheet capability. Fortunately, in the narrow case of requirements, there is an easy workaround: create a requirements table and export that to Excel.

Right-click on the “Clarified Requirements” folder, select “Create Diagram”, “Requirement Diagram”, and “Requirement Table”

Name the table.


V1.0.1 – 17 July 2017 Copyright© 2015 60


Select all the clarified requirements and drag them to the table.

Click “Export”, name the file, click “Save”


V1.0.1 – 17 July 2017 Copyright© 2015 61


We can now open that file in Excel by clicking on it.

(I formatted the columns a little bit to make it prettier)


V1.0.1 – 17 July 2017 Copyright© 2015 62


Iterative Design and Requirements Allocation

The Vodka Detector Let’s start with the “Vodka Detection” requirement. Clearly the chessboard will need a Vodka Detector.

1. In the package “Board” create a new Block Definition Diagram called “Vodka Detector”

2. Create a new block called “Vodka Detector”

3. Drag “Board” and “Vodka Detector” to the diagram.

4. Add the composition relationship between the detector and the board as shown.

5. From “Clarified Requirements” drag “CPY-SAF-003” to the diagram as shown.

6. Allocate the requirement to “Board”

7. Add “Satisfy” requirement between the detector and the requirement.

Now, a few remarks:

1. We are Cheating – Requirements professionals will immediately notice that CPY-SAF-003 is not really a “Leaf” requirement. Correct. Actually, we need to model a lot more about the Vodka Detector and break this into more detailed requirements.

2. MBSE – The nice thing about Model-Based Systems Engineering is that it is easy to keep refining. If this is all we understand at the moment, it may be OK to go with this “Cheating” use of satisfy and come back later and continue to fill in the details. Or not. The difference depends on the size and formality of your organization/project. On a very large project, you would NOT want to add the “satisfy” relationships until everyone on the team was comfortable that the requirements were down to “Leaf” level. The reason for the difference is that on large projects (usually with some additional programming support) management can create “dashboard” progress indicators from the model showing how many requirements have been defined, how many allocated, how many “satisfied” and so on.

3. What About the Space Chessboard System? – Didn’t we forget to allocate the requirement at the top? That depends on your organization’s policy and requirements management strategy. On one level, every requirement will end up allocated to the system. That may or may not add much value. It depends on the “dashboard” strategy mentioned in (2) above.


V1.0.1 – 17 July 2017 Copyright© 2015 63


Piece Retention Let’s do one more with a bit more complexity to it. Let’s handle the piece retention problem. That is, the spaceship may be rotating or accelerating. You don’t want the chess pieces to float all over the place in the cabin. On the other hand, you want the astronauts to be able to move them around easily. Clearly, this problem is going to require capabilities in both the chessboard and in the pieces.

1. Create a new Block Definition Diagram called “Piece Retention”. Since this will span both “Board” and “Pieces”, let’s put it in the package “Top-Level Structure Diagrams”

2. Drag “Space”, and “Piece” to the diagram.

3. Let’s also drag CLR-ERG-004, CLR-ERG-002, and CPY-SAF-001 to the diagram.

4. Great… Our design team looks at this picture and proposes that each space will have an embedded electromagnet that can hold a steel retention ring built into the base of each piece.

5. Let’s add those items to the diagram.

Oh dear. This diagram is going to get really complicated! MBSE to the rescue! Just make several simpler diagrams. Let’s handle the Board::Space side first.

1. Create another Block Definition Diagram in the package “Board” that has the name “Retention Magnet Capabilities”

2. Drag “Space” and “Electromagnet” to the diagram.


V1.0.1 – 17 July 2017 Copyright© 2015 64


3. Drag CLR-ERG-002 and CPY-SAF-001 to the diagram.

4. Looks great…but where is the Composition relationship between the two blocks? Let’s show it.

Select both blocks (shift+click) and then right-click. Select “Related Elements” and “Display Paths”

The relationship will be displayed. Go ahead and delete the text labels that we don’t need.

5. Allocate CPY-SAF-001 to “Space” (The allocate relationship is in the “Common” section of the Tool Palette)

6. In the package “Clarified Requirements” add a new requirement.

7. Name the new requirement “Retention Magnet”

8. Give it the ID “CPY-SAF-001-a”

9. Add the text “Each space on the chessboard shall have a magnet for retaining pieces.”

10. Drag this requirement to the diagram and fix up the format.

11. Add a “Derive” relationship to CPY-SAF-001

12. Add a “Satisfy” relationship from the block “Magnet”

13. Add another requirement to “Clarified Requirements”

14. Give it the name “Magnet Strength”


V1.0.1 – 17 July 2017 Copyright© 2015 65


15. Give it the ID “MRG-002”

16. Give it the text “The magnet shall have sufficient strength to retain a piece of mass up to 50 grams”

17. Drag it to the diagram and fix up the format.

18. Add “Derive” relationships to “Piece Mass” and “Retention Magnet”

19. Add “Satisfy” relationship from “Magnet”

Very nice. However, it is easy to imagine that if we were building this thing in real life, there would be a lot more detail to add. What is the mass of the retention ring? What is the distance from the magnet to the ring? What is the power budget? How about the separate communications interface between the piece and the chessboard space? Clearly the chessboard piece will need to detect the astronaut’s hand…which might be inside of a spacewalk suit.

Notice also, that there is no “Right Answer” on how to do this sort of modeling. There are many possible opinions about requirement numbering. Perhaps the “Magnet Strength” requirement should be a subrequirement of “Retention Magnet”. The SysML standard and tools like MagicDraw merely support your organization’s efforts to make clear models. SysML and the tools do NOT make these decisions for you.



V1.0.1 – 17 July 2017 Copyright© 2015 66


Step 5 – Use Cases

About Use Cases Use cases are an important part of systems and software engineering. However, a lot of organizations get very frustrated with this activity. However, I can pass along two tips from other experts on how to make the use case activity more productive:

1. Flip the Order – Most organizations think of the use cases as the starting point. That is, their understanding of use cases is something like laying on the psychologist’s couch. Just start talking and requirements will magically pop out of the meandering. Needless to say, this sort of rambling narrative approach can get very frustrating very quickly. A better approach is to start with the known requirements and develop a story for each known requirement. The context of the single known requirement helps put some fences around the pasture and keep the cows from wandering away into the woods. Meanwhile, this type of focused use case can be very helpful for flushing out additional detail in elaborating the requirement. Insight from Lenny Deligatti http://delligattiassociates.com/about-us/

2. Who-What-Why – Focus the use case on these three questions. For example: “As the mission psychologist, I want to detect high stress levels in the astronauts so I can take action to provide support for any that are drifting into the danger zone.” Start with the role. Continue to what that role wants to do. Conclude with why that role wants to do it. Be careful to keep the discussion away from the “How”. Insight from David Hawks http://www.agilevelocity.com/team/david-hawks/

Before we dive in, we should also note that SysML does not provide specific modeling constructs for the content of use case. Rather, SysML provides modeling constructs to track the relationship of use cases to each other and to actors as well as to other elements of the system.

http://delligattiassociates.com/about-us/

http://www.agilevelocity.com/team/david-hawks/


V1.0.1 – 17 July 2017 Copyright© 2015 67


Make a Use Case Diagram



Create a Use Case Diagram

In the package “Use Cases” create a Use Case diagram called “Piece Movement”

From the package “Structure::Actors” drag “Player” onto the diagram.

The rest of the drawing aspect of the use case diagram is pretty simple. The problem of moving the chess piece is actually a little complicated. The player may place his hand on a piece and think for awhile. While the player is in this position, you want to reduce the retention force so it is easy for the player to move the piece. On the other hand, you don’t want to totally let go of the piece in a zero-gravity environment. That is, if the player lets go of the piece again, you want to pull it back tightly to the chessboard.

Overall, the use case and sub uses cases might look like this:

Drawing the diagram is pretty trivial with the Tool Palette elements shown.


V1.0.1 – 17 July 2017 Copyright© 2015 68


What about the text content of each use case? It might look like this:

Move a Piece As a player, I want to be able to freely and naturally select pieces, hold them in place while I think about moving the, tentatively move them, and finally commit the move by releasing the piece at a new location on the chessboard.

Think about starting a move

As a player, when I touch a piece, I want the chessboard to relax the grip on the piece somewhat so that I can fiddle with it, move it around slightly in its space and so on, so that I can stimulate my imagination.

Moving a piece As a player, when I start to move a piece from its previous position, I want it to be very easy to move so that the Newtonian counter-reaction does not move me around the cabin.

Thinking about completing a move

As a player, when I tentatively position a moved piece on a new space, I want the chessboard to gently grab the piece while I consider whether I want to commit the move.

Change Mind As a player, when I let go of a piece on its original space, I want the Space Chessboard to pull it neatly and firmly into the center of the space and then retain it firmly.

Commit Move As a player, when I let go of a piece on a new space, I want the Space Chessboard to pull it neatly and firmly into the center of the space and then retain it firmly. I also want the board to inform the Chess Clock that my move is complete.

So, what to do with this text? Good question. SysML does not really address this problem. However, MagicDraw allows you to load an extended profile for a use case that adds some additional fields.

It is also possible to model it as a SysML Note linked to each Use Case. It depends on the level of effort your organization wants to put into use cases. Writing Effective Use Cases by Alistair Cockburn is widely regarded as the go-to reference for doing really serious use case work. If your organization wants to invest at that level, then you will probably want to develop a formal use case template and dig deeper into extending MagicDraw to track links to these external files.


V1.0.1 – 17 July 2017 Copyright© 2015 69


Allocate Requirements to Use Cases As mentioned in the tips above, we can also proceed directly from requirements to use cases. Naturally, we would want to allocate requirements to use cases to track this sort of relationship. For this purpose, requirements can be added directly to Use Case diagrams.

Here I have created a simpler Use Case diagram called: “Requirement to Use Case Allocation Example” to demonstrate the point.



V1.0.1 – 17 July 2017 Copyright© 2015 70


Step 6 – Interfaces and Sequence Diagrams

Interfaces SysML has very rich constructs for modeling very complicated interfaces. In fact, interfaces are one of the key areas of interest for the SysML community and substantial changes were made between SysML 1.2 and SysML 1.3.

For the purposes of this tutorial, however, we are just going to do a very simple example using the least complicated approach possible just to give a impression of what sorts of modeling are possible.



Add an Interface In Step 5, we looked briefly at the mechanical aspects of the interaction between each chess piece and the chessboard. Here we will look at the control aspect. Clearly the chess piece has to detect the player’s hand as it touches, grabs, moves, and releases the piece. These gestures have to be communicated to the chessboard so that it can control the electromagnet that secures the piece to the board. Obviously, there is an interface between a “Piece” and a “Space” on the chessboard. How is this interface implemented? We don’t know yet. The design team is off looking at options. Some members are lobbying for an optical link. Others think that near field communication (NFC) shows more promise. In any event, we don’t need to know precisely which sort of link will be selected in order to begin modeling what we want the link to do.

1. Add a new top-level package to the model called “Interfaces”

2. Right-click on this package and add a Block Definition Diagram called “Piece to Space Communication”

3. From the “Board” package, drag “Space” onto the diagram.

4. From the package “Pieces” drag “Piece” onto the diagram.

5. From the Tool Palette, select the “Association Block” link. This is a very important and useful element that was added in SysML 1.3. That is, this element is a relationship that has an attached “block”. This combination thing is very useful because unlike other relationships, this sort of link is a fully featured modeling element in its own right. That means, that we can allocate things to it, make it satisfy requirements, and so on – just what you want from an interface!


V1.0.1 – 17 July 2017 Copyright© 2015 71


6. Drag the link from “Space” to “Piece” in the diagram.

7. Double-click on the new block element to name it:

8. Name it “Piece Control Interface”.

9. MagicDraw places the SysML element for the interface under “Relations”


V1.0.1 – 17 July 2017 Copyright© 2015 72


Allocating Requirements to the Interface 1. In the package “Requirements” add a new subpackage called “Elaborated Requirements”

2. In “Elaborated Requirements” add a new Requirements Diagram called “Piece Control Interface Requirements”

3. From “Clarified Requirements” drag CLR-ERG-004 “Piece Movement” onto the diagram.

4. From the Tool Palette, drag a requirement to the diagram.

a. Set the name to “Hand Force Sensing”

b. Set the ID to CLR-ERG-004-a

c. Set the text to “Each piece shall sense hand force in excess of 0.02 Newton and report it to the chessboard”

d. Drag a “Derive” relationship from this new requirement to CLR-ERG-004

5. From the Tool Palette, drag a requirement to the diagram.

a. Set the name to “Hand Force Sense Data”

b. Set the ID to CLR-ERG-004-a.1

c. Set the text to “The Piece Control Interface shall have a command to support reporting of hand force in units of 0.001 Newtons”

d. Drag a “Derive” relationship from this new requirement to CLR-ERG-004

e. Drag “Piece” to the diagram and make a “Satisfy” relation between “Piece” and “CLR-ERG-004a”

f. Drag the interface to the diagram…

g. MagicDraw will populate the diagram with the elements on both ends of the interface.

h. Rearrange them a little to look pretty.


V1.0.1 – 17 July 2017 Copyright© 2015 73


i. Drag a “Satisfy” relationship from the interface to the lowest requirement.

Make a Sequence Diagram for the Interface In the Containment Tree, right-click on the interface and:

Select “Create Diagram”, “SysML Diagrams”, “SysML Sequence Diagram”.


V1.0.1 – 17 July 2017 Copyright© 2015 74


Click “OK” to include the ends of the interface.

MagicDraw includes the ends of the interface. Drag the “Player” actor onto the diagram and rearrange as shown:

You will notice that the tool draws the dashed lines and positions the elements vertically automatically. All you can really control is the horizontal spacing. These are referred to by systems engineers as “Swim Lanes”


V1.0.1 – 17 July 2017 Copyright© 2015 75


1. Add an interaction by clicking the “Send Message” icon and then dragging from one swim lane to

another as shown.

2. Click on the arrow that was added and name it “Push piece to move”.

3. Clicking underneath the arrowhead on the “Piece” swim lane, draw an interaction to the “Space” swim lane.

4. Name that one: “Hand force sensed”

5. Continue adding as shown:

Of course, this is a very simple Sequence Diagram. SysML supports a lot more complexity in Sequence Diagrams…



V1.0.1 – 17 July 2017 Copyright© 2015 76


Step 7 – Test Case So, we are finally at the goal – Test Cases!

The punchline here is that Test Cases in SysML are similar to Use Cases. There really isn’t all that much unique support for them. However, we can use all the other SysML constructs to do a decent job of modeling them.

Add Test Case to a Requirements Diagram



Create a Hierarchical Test Plan for the Piece There is no such thing as a “Test Case Diagram”. However, SysML considers test cases to be part of the requirements tool set, so working with a Requirements Diagram is easiest.

1. Right-click on the “Test Cases” package and add a Requirements Diagram called “Piece Test Strategy”

2. Drag a Test Case from the Tool Palette onto the diagram and name it “Piece Master Test Plan”. Note that MagicDraw calls this element “Test Case Activity” in the Tool Palette.

3. From the folder “Clarified Requirements” drag CPY-ERG-003 “Piece Size” to the diagram.

4. Drag another Test Case onto the diagram and name it “Space Walk Glove Movement Test”

5. Drag a “Verify” relationship from this test case to the requirement.

6. From the package “Structure::Pieces” drag “Pawn” onto the diagram.

7. Drag a “Satisfy” relationship from “Pawn” to the requirement.

8. Select the “Containment” relationship and drag it from the Glove Test to the Master Test Plan.

1. The “Space Walk Glove Movement Test” is contained within the “Piece Master Test Plan”

2. The “Space Walk Glove Movement Test” verifies the requirement CPY-ERG-003 “Piece Size”


V1.0.1 – 17 July 2017 Copyright© 2015 77


3. The block “Pawn” is responsible for satisfying the requirement.

Adding a Child Activity Diagram One possibly convenient feature for test case development is the ability to attach a child activity diagram to the test case.

Right-click on the “Space Walk Glove Movement” Test Case. Select “Create Diagram”, “SysML Diagrams”, “SysML Activity Diagram”

We don’t need “Verdict’ – which is actually something from SysML 1.4 that NoMagic seems to have slipped into the SysML 1.3 diagramming function.


V1.0.1 – 17 July 2017 Copyright© 2015 78


Accept the default name.

Delete the spurious “Verdict” from the diagram.

At this point, the SysML activity diagram Tool Palette will pop up.


V1.0.1 – 17 July 2017 Copyright© 2015 79


…and you can draw something like this pretty easily.

In its basic form, the SysML Activity Diagram is simply what used to be called a “Flow Chart”. Of course, it does have some fancier features which are beyond the scope of this tutorial.

In one final remark, if we right-click on “Grab and lift chess piece” we will see that it is possible to further nest another Activity diagram inside “Grab and life chess piece”

This sort of “Drill-Down” function provides a very nice facility for modeling very complicated test plans at different levels of complexity.

This concludes this tutorial. For your reference, the completed model is available in the file “Space Chessboard – Step 7.mdzip”.

Documents

SysML Workbook – MagicDrawasattepress.com/Downloads/Tutorials/QA-Test-2015-N2-Intro-SysML... · 2. Add it directly from the Containment browser. Actually, there is a third method