Andrius Armonas


Dr. Andrius Armonas is the MagicDraw Product Manager and MagicDraw Analyst Team Manager with more than ten years of experience in software development. As a Product Manager, he is responsible for setting directions for the product, its roadmap and vision, and selecting features for each new version of MagicDraw. His responsibilities also include understanding the market and the competitive environment. As the Analyst Team Manager, Andrius is responsible for the MagicDraw R&D team, ensuring requirements quality and completeness, requirements gathering and specification processes.

Dec 222016

We would like to share several videos about the very first integration of Cameo Collaborator with Teamwork Cloud.

•    All data is stored and retrieved from Teamwork Cloud
•    The web application runs on our brand new Web App Platform
•    The web application is smart phone and tablet-friendly

Demo on a desktop:

Demo on an iPhone 7:

Apr 032015

Publis from TS - CopyIn the traditional systems engineering, or so-called document-based systems engineering, work products are created separately and consistency between these products is maintained manually by the designer(s) of the system. One of the biggest model-based systems engineering ROI is the ability to automatically generate consistent work products out of a systems model. This session demonstrates various approaches to work product generation from models. A special emphasis is put on publishing information stored in the models on the web to various stakeholders, some of which have never been exposed to MBSE, models, or modeling tools.

The session demonstrates:

  • TechnologiessupportedbyCameoSystemsModeler for work product generation
    • VTL template-based reporting
    • SysML Views&Viewpoints approach to document generation
    • Generation of work products by exporting them directly from the model
  • Publishing models on the web
  • Reviewing published models on the web and tracking review progress
  • Integrating published models with Wikis
  • Customizing the appearance and information fidelity of published models

The comparison of the documentation generation approaches is provided in this session

Technology Target user group Templates supported Commenting supported Customization can be done by Customization technology
VTL templates for documents (Word, Excel, etc.) Non-modelers and modelers Yes Yes, basic support Customer VTL scripting
Web reports Modelers Yes No Customer VTL scripting
Web Portals Non-modelers and modelers Yes Yes, basic support No Magic Java coding
Document Modeling plugin / SysML V&V Non-modelers and modelers Partially No Customer Modeling
Cameo Collaborator / SysML V&V Non-modelers and modelers Yes Yes, advanced support Customer Modeling


Slides used during presentation:

Download (PDF, Unknown)

Webinar recording:



Q&A session answers:

GDE Error: Error retrieving file - if necessary turn off error checking (404:Not Found)

The session is hosted by Dr. Andrius Armonas, MagicDraw Product Manager at No Magic

Learn more at:


Dec 192014

Intro to Cameo Collaborator

Cameo Collaborator is a new product MagicDraw core team has been working on since April, 2014. It helps team members to review their work by connecting model authors, reviewers, and stakeholders on the web.


I am excited to share the information that we have just released the second Alpha version of Cameo Collaborator. You can download it for free from here:

Please try this new product (it will take just 30-45 minutes to setup the environment) and be part of creating Cameo Collaborator. Tell us what you think at!

Cameo Collaborator has unique capabilities which I will briefly present in this post.

What’s new in Alpha 2

Here are new things since the first Alpha:

  • Polished look and feel
  • Redesigned and improved graphical commenting workflow
  • Ability to update models in Cameo Collaborator by retaining previously entered comments
  • Published portal name is now set by the user before publishing

Graphical comments

One of the most innovative capabilities the product has, is the ability to graphically comment published diagrams. The primary use case for graphical commenting is the ability to add missing links between elements (e.g. stating that a connector is missing between two parts), or specifying that some elements need to be introduced in a diagram, e.g. a new subtask between two other subtasks in a BPMN diagram. Here is how graphical comments look:


Graphical commenting helps:

  • modelers to comment models much more efficiently compared to writing just textual comments. It is much faster to draw missing elements or links between elements than to describe what is missing in text
  • non-modelers (people who have never been exposed to models or trained in MagicDraw) contribute to models much more easily just by drawing free-form shapes. They may not precisely understand the semantics of the language (e.g. a BPMN diagram) or they may not know which elements to use, but they are capable to draw missing parts in the diagrams by using various shapes (rectangles, arrows, etc.) which the model authors can convert to model elements

Textual comments

Cameo Collaborator supports textual commenting in addition to graphical commenting. Here is how a textual comment can be entered for the “condenser” element:


The title of each pane indicates the number of entered comments for the element:

comment number

View all comments from all reviewers in a single pane:

all comments pane

Clicking on each individual comment thread navigates to the commented content.

Every element in the diagram has a callout indicating the number of comments for this element:


Customizable review workflows

The product supports review workflows. Review workflows shows at a glance the status of review tasks. Email notifications are also sent to those involved in the review.

To use review workflows, all you need to do is create a review task, assign reviewers and published models to it:


It is easy to check the status of reviews in a BPMN diagram (BPMN models can be used to introduce your own review workflows):



Also, the status of a review is shown in the workflow details:


Publishing models online

It is easy to publish just a fraction of your model online. Let’s imagine you want to publish several diagrams from your model for review. For this we will create a smart package and drag and drop the diagrams we want to publish for review into that smart package:


Then we will launch Cameo Collaborator Publisher plugin (it is a free plugin) from the Tools menu to publish the selected smart package:


After clicking the Publish button, the model will be published to Cameo Collaborator.

What is coming next?

  • Fully customizable GUI of the published models (element trees, information associated to each element in each tree, colors, etc.)
  • Visual cues as to who created each graphical comment
  • Additional drawing markups (lines, arrows, rectangles, etc.)
  • Automatic publishing of models from MagicDraw Teamwork Server
  • Predefined review workflows
Jun 232014

Some of our products have as many as 50 to 70 different diagrams, making it difficult to find the one diagram you want to create. The new Create Diagram dialog introduced in MagicDraw 18.0 helps you create any new diagram in 2 to 3 seconds. Here is how (UPDM is used in the example):


The essence here is that all you need to do is to enter the first letters of the diagram (e.g. ov1 for the “OV-1 Free Form Operational Concept Graphic”) and click Create to create a new diagram.

In future releases of MagicDraw, we are considering extending this dialog to be able to create elements and make these new dialogs available from the browser shortcut menu. Tell us what you think of this idea!

Jan 122014

This feature was sitting in our backlog for a while and we finally decided to implement it!

Let’s say you have the following domain diagram and decide that you want to insert new classes between Loan and Customer:

Before pusher

To do that easily, click on the Pusher icon in the top of the diagram palate:


Choose the place where you want to make more place – a black bar appears. By dragging it you will see the new placement area of moved shapes:


After releasing the mouse, you will have more space available:

Pusher after2

We also implemented 2 shortcuts for pusher and magnet which makes their use simpler: Ctrl+Shift+Z invokes pusher, Ctrl+Shift+X invokes magnet. I use these shortcuts several times during my day.

Jan 122014

Yes, it was not so good, maybe even stressful. But give it another look – there is an improved label layout in diagrams now. Let’s see what we did.

Diagram automatically sorted with the OLD MagicDraw v17.0.4 (do Layout -> Quick Diagram Layout):  The same diagram automatically laid-out using MagicDraw 17.0.4 SP1:
 layout old  layout good
Jan 122014

Searching for elements by property value is simplified.

Let’s say you want to find abstract classes in your model. For this, open the Find dialog (Edit -> Find) and specify that you will be looking for classes in the Type field:


Now click on the Options button and press the “…” button in the “Properties” area to specify that you will be searching for classes by property values:

Find all

Select the value to search for. In this case, “Is Abstract” should be set to true.

Select property

Press OK:

Find is abstract

Click Find and you are done:

Search results

Jan 122014

It is not only possible to reconnect relationships from one element to another in diagrams, but diagrams are also updated when you make changes via specification windows.
Here is an example which properties values to change for association between classes in order to reconnect it from one element to another:

Type properties

Jan 122014

Ever wanted to use your own images instead of out-of-the box UML/SysML/whatever shapes MagicDraw provides? You can do it this way:

  1. Open the element specification dialog.
  2. Select the image you want to see instead of the shape symbol:


Here’s what we have as the result:


BTW, as I mentioned in my earlier post, you can show property values in the note(s) attached.

Jan 122014

There are many ways that documentation can be entered and viewed in MagicDraw.
MagicDraw has a hover feature which shows editorial notes:

Editorial notes on diagram

To turn this feature on, choose the following from MagicDraw main toolbar:

Turning editorial notes on

Notes can be used to document elements too. The documentation is attached to the model and can be seen everywhere, in each diagram:

Note on diagram

It is also possible to edit documentation from other places as well:

Documentation edit from quick properties

Documentation edit from specification

Jan 122014

In MagicDraw, notes are used not just to show/enter documentation for the element, but also to display derived information, which is an extremely powerful feature (I’m not aware of another tool that supports this capability).

Let’s say you want to show inherited properties for a class. You can attach a note to an element, press the “…” handler and select any metaproperty (in MagicDraw you can easily define your own metaproperty with its own derivation rules without any programming):

select compatment edit

It is also possible to show metaproperties on the shape itself. Choose the following menu item for the element on which you want to display metaproperties:

Element properties

Compartment edit

Show metaproperty on shape

Jan 092014

SysML reading of the Three Little Pigs done with MagicDraw + SysML plugin. Simple, funny, but … serious. Let me in, Let me in, little pig or I’ll huff and I’ll puff and I’ll blow your house. Not by the hair of my chinny chin chir…. You see it is just as I told you. The way to get along in the world is to do things as well as you can.

Do you agree?

[slideshare id=5276195&doc=the-three-little-pigs-100924062354-phpapp02]


Dec 172013

This document proposes structuring and styling rules that help writing requirements using the SysML language as well as specific MagicDraw capabilities that support this process.

Prerequisites: basic MagicDraw knowledge; basic knowledge of the SysML language requirements part.

The biggest issue users have when they start writing requirements using the SysML language is that there is little information on how to properly layout the requirement diagrams, how to relate them to other UML or SysML diagrams, how to structure the requirements project into layers, what the granularity of the requirements should be, how evolution of the requirements should be handled, etc. In other words, there is quite a lot of information describing language concepts themselves, not so many practical experiences describing how to use that language in the real-world.

In this guide, we share No Magic, Inc. experience using the SysML language for developing MagicDraw product itself. We hope that this document can lead to a two-way sharing of experience and ideas – if you as a reader have suggestions or questions, you are very welcome for a discussion.

Requirement Layers

Every product (tool, plugin, or framework) should have a single MagicDraw requirements project which should hold requirements for the current state of the product. The recommended name for the requirements project is ” Requirements”, e.g. “Cameo Infrastructure Requirements” or “MagicDraw Requirements”.

The requirements within a project should be expressed in the “shall” form stating how the system should work instead of specifying what has to be changed from the current state.

Figure 1 Package structure of a requirements project.

A requirements project should have a single root package called Requirements which should contain all the requirements under it (directly or indirectly). It should be shared so that the development and QA could use the requirements for their needs.

The Requirements package should have three packages under it (see Figure 1):

  1. Logical Domain. This package should contain domain models expressed in UML class diagrams. More information on this is provided in the following chapters of this document.
  2. Business. This package should contain high-level (business) requirements. Requirements in this package should be independent of the requirements specified elsewhere in this project.
  3. Concrete. This package should contain requirements that implement or satisfy the business requirements. Requirements in this package should only depend on the requirements specified in the Business package via the «derive» relationships. For example if the business requirement is ‘The system shall track changes in projects’, then its counterpart in concrete requirements could be ‘The system shall support element-level versioning’.

Figure 2 summarizes what has been described so far. It shows the dependencies between the requirements in top-level requirement packages expressed as «derive» relationships.

Figure 2 Dependencies between requirements in top-level packages.

Contents of the Business Requirements Layer

The Business requirements package should have a single non-derived requirement root element (we will further refer to this element as to root requirement in this document). There can be other root requirements but they can only be derived directly or indirectly from the root requirement. In order to emphasize that there is only a single true root element, other root elements should be moved into packages which represent logical units of a system. Non-derived and derived root elements should be owned by the packages. Other requirements should be owned by requirements. In other words, the requirement should either be a root requirement, or belong to the root requirement directly or indirectly, or be derived from the requirements that belong to the root requirement directly or indirectly.

The root requirement should be named the same as the framework/tool/plugin is named (without version), e.g. Cameo Infrastructure.

There should be a single diagram directly under the Business package or owned by the root requirement. It should be the starting point for reading framework/tool/plugin requirements (e.g. its name could be High-Level Requirements). This diagram should have a symbol representing the root requirement and (possibly) its directly owned requirements.

The sample structure of the Business package is shown in Figure 3. There is a root requirement under this package and a single diagram graphically representing it. There is also a bunch of packages which contain requirements derived directly or indirectly from the root requirement.

Figure 3 Structure of the Business package.

Contents of the Concrete Requirements Layer

As stated earlier, requirements in the Concrete package should have requirements that “implement” or satisfy requirements in the Business layer. Requirements in this package should be derived from the requirements in the Business package. Generally, the same rules from the Business package apply here except that there is no root requirement. All the requirements here are derived and should be owned by packages which on their own should be owned by other packages or the Concrete package. As for the contents of the packages under the Concrete package, they should contain both functional and GUI requirements.

Sample structure for the Concrete package is shown in Figure 4.

Figure 4 Structure of the Concrete package.

Domain Models

Domain models should be owned by the Logical Domain package (see Figure 5). Each package should be structured on its own. Package structure should be created in accordance to the logical parts of a modeled system.

Figure 5 The Logical Domain Package.

Domain models are be modeled using class diagrams. Sometimes state machine, activity or sequence diagrams are also used in addition to class diagrams. Class diagrams should be owned by the packages residing in the Logical Domain package. Sometimes it is needed to describe the overall domain model of a particular feature in several aspects. In such a case each aspect shall be modeled in a separate class diagram. The diagrams describing separate aspects should still be owned by the same package that holds classes describing the feature.

Requirement Diagram Ownership

Requirement diagrams should be owned by the requirements they represent. In some cases requirement diagrams can be placed next to the represented requirements. This approach is less recommended as the diagram in this case is not kept together with the requirement and all refactoring-related actions should be performed twice on both the requirement and the diagram (e.g. moving a requirement to new location will require moving the diagram to another location too). This may lead to situations where diagrams are scattered over the model in different places than the represented requirements. This would make reading the requirements model quite a hard task.

In Figure 6, the root requirement is named Cameo Infrastructure. There is a diagram High-Level Requirements that represents this requirement and is owned by the Business package. There is also a diagram called Scalability Requirements, which is owned by the Scalability requirement and it graphically represents the Scalability, Storage, and Distribution requirements and their subrequirements.

Figure 6 Ownership of Requirement Diagrams.

Element Layout in Requirement Diagrams

Figure 7 Requirement diagram areas.

There should be mainly two areas in each requirement diagram (see Figure 7 for an example):

  • Navigation area. There should be an area in the diagram for putting links to/from related diagrams (e.g. there is a yellow rectangle shape at the top left corner in the diagram shown in Figure 7 holding hyperlinks to domain models and related requirement diagrams). If the requirement diagram refines a requirement from another requirement diagram, the Navigation area should have a hyperlink to that diagram.
  • Requirements modeling area. There should be a single root node and a certain level of its owned requirements in a single requirement diagram. One nesting level is recommended. However, if the number of requirements in each nesting level is small (e.g. 1-4 requirements), there can be more nesting levels in a single diagrams. Requirements that have more than 5 owned requirements should be refined in separate diagrams. Having more than one root node would possibly mean that the navigation area would contain backlinks to different contexts which could possibly confuse the reader if he/she wanted to navigate to objects from a single context. Requirements from other contexts, e.g. derivation targets, should be of a different color (for example the color could be yellow as shown in Figure 7). This is required to distinguish the requirements in the current context from the requirements in other contexts.

Requirements in the Requirement modeling area can be laid-out in three different ways:

  • Horizontally. In this layout, requirements of the same nesting level are laid-out horizontally. Nested requirements are positioned below the owning requirement by aligning the center of the whole row of requirements to the center of the owning requirement. This layout type is handy when requirement texts are not large (and they should not be large; if they are – they should be decomposed into several requirements). Requirements in this layout are read in the left-to-right, depth first order. Horizontal layout is the
    recommended layout. A sample of horizontal requirement layout is depicted in Figure 7.
  • Vertically. In this layout, requirements of the same nesting level are laid-out vertically. Nested requirements are positioned below the owning requirement by shifting the whole column of requirements to the right relatively to the owning requirement. This layout type is handy if there is a list of requirements whose texts take a considerable amount of space. A sample of vertical alignment is depicted in Figure 8.
  • Horizontally and vertically in a single diagram (mixed layout). Sometimes it is useful to mix horizontal and vertical layouts in a single diagram, e.g. for saving diagram space. Figure 9 shows a sample requirement diagram where requirements Reusable Dialogs, General Requirements for a Dialog Window, and Open Dialogs Only When Connected to Server are laid-out horizontally, where others are laid-out vertically to save space (this is much more readable and understandable than organizing the requirements horizontally in this particular case).

Note: This section only describes three layouts that are most common, however depending on the situation you can layout requirements differently, e.g. when you have only derived requirements in a single diagram you may want to use something different.

Figure 8 Vertical requirement layout.

Figure 9 Mixed requirement layout.

Requirement Hyperlinking

Requirements should have hyperlinks to the requirement diagrams in the following cases:

  • If the requirement is refined with another diagram, then it should have a hyperlink to the refining diagram;
  • If the requirement B is derived from the requirement A then both A and B should have hyperlinks to the diagrams in which they are described if these diagrams are different. The diagram where A is described should have a symbol representing B and the derivation path to B. The diagram where B is described should have a symbol representing A and the derivation path to A.

Using SysML Requirements Tables

Figure 10 Requirements table.

In some cases, requirements tables (see Figure 10) can be used instead of ordinary requirements diagram. This diagram is mostly useful in situations where there is a single requirement which has one nesting level of requirements under it. It is worth noting that the table is not capable of showing derivations and other relationships, thus the usage of this table is limited currently. In cases where relationships and related elements need to be displayed, the Generic Table can be used. This diagram is not specifically devoted for requirements, but requirements can be managed in it too.

Modeling GUI Requirements

It is recommended to use a single template for modeling all GUI requirements. An example of such a template is described in this subsection.

A diagram representing requirements for a single window should at least satisfy the following requirements:

  • It should have a single root requirement that groups requirements for the whole window;
  • Requirements directly owned by the root requirement should describe:
    • How the window is opened (by clicking on some button, automatically, etc.);
    • Title of the window;
    • Any informational messages or descriptive texts the window has, e.g. texts that describe what the window does;
    • Data management components. Usually requirements for data tables or data input/editing fields are placed under this requirement;
    • Data management buttons. Buttons that perform actions on entered or selected data are placed under this requirement.
  • In MagicDraw, it is strongly recommended to use the User Interface Modeling Diagram for sketching the GUI. If this diagram is used, a sketch of the dialog should be created in a separate diagram to which a hyperlink should be created from the root requirement. Alternatively the Diagram Overview shape could be used to display contents of the GUI in the requirements diagram (see Figure 11 for an example). If the User Interface Modeling Diagram cannot be used, there should be a sketch of the dialog placed in the same diagram and it should be attached to the root requirement.

A sample requirements diagram of the Open Server Project window is shown in Figure 11.

Figure 11 GUI requirements for a single window.

Requirement Decomposition

When writing requirements in SysML a question when to decompose a requirement into other requirements arises quite often. The rules here are as follows:

  • if some part of the requirement is going to be used somewhere else, e.g. some other requirement derives from it, or it is a subject to decomposition itself, then the requirement should be decomposed into smaller requirements
  • if the requirement has information from different (sub)topics, it should also be decomposed into subrequirements
  • if parts of the requirement are not used by any other requirement and the requirement holds information that naturally describes the same topic or thing, but the text of the requirement becomes too big (e.g. 8-10 sentences), it should still be decomposed into several requirements for better readability

«satisfy» relationship

The «satisfy» relationship describes how a design or implementation model satisfies one or more requirements. A system modeler specifies the system design elements that are intended to satisfy the requirement, e.g. architecture classes satisfying the requirements. This relationship should not be used between requirements.