Guillaume Finance

Abstract:

UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling language for systems: SysML or Systems Modeling Language.

This article is intended to provide a non-exhaustive presentation of SysML including some background about Systems Engineering and SysML, and a review of each SysML diagram and modelling techniques.

The article "SysML Modelling Language explained" is available from the following PDF document (size: 747 KB).

You may wonder why an incomplete or incorrect diagram would be useful. Shouldn't it make sense to aim at producing a good representation right from the start by modelling what needs to be built and achieved? This article deals with a simple approach: incomplete diagrams provide a visual representation of the system to be built, that once shown to stakeholders, product owners, dev teams, and project managers, will trigger feedback and discussions to move towards a shared vision.

This article deals with a recurring question in use case modelling: given a use case that’s automatically triggered by the system clock or timer, what actor should be used? In this context, it is common use to define as the primary actor the system’s clock or timer, since this actor triggers the use case. This article compares three alternatives.

Using Enterprise Architect in a Team Environment often involves a version control repository like SVN (Subversion). This article describes a way to compare the current version of a package in your model, which is controlled under an XMI file in SVN, with an older version of this package. This is achieved through the use of the EA Baseline feature.

This article is intended to illustrate the advantages based on my current experience of using the Diagram Filters, functionality added in EA version 9. Two case studies/examples illustrate the purpose of Diagram Filters: 1- filter dependency connectors between provided and required interfaces on a UML Component diagram, 2- show differences between the specifications and two implementations through the use of UML State Chart diagram.

Sparx Systems will shortly release Enterprise Architect version 10. An overview of the main features is available from the following link: http://www.sparxsystems.com/products/ea/10/index.html.

This article is intended to provide a preview of the improvements and new features that are expected in Enterprise Architect v10 following a test carried on its beta 2 (note: as a beta version, the features shown in this article may be modified when the final version is released).

The OMG has published this month the official specifications of the expected new version 1.3 of SysML, two years after releasing SysML 1.2.

SysML 1.3 affects the definition of ports by introducing Full Ports and Proxy Ports, both allowing to combine operations to call, and items to flow in and out the block. SysML 1.3 updates also include nested ports, nested flows, association blocks, and port compatibility.

Further details are available from my post in April : SysML 1.3 beta preview.

The next version of SysML, the modelling language based on UML for Systems Engineering projects, should be released in June as version 1.3 beta is currently listed on the OMG.org website.

Even though SysML 1.3 beta specifications aren’t released yet, it’s already covered in the Second Edition of “A Practical Guide to SysML” book by S.Friedenthal, A.Moore, and R.Steiner (ISBN : 0123852064).

SysML 1.3 main changes apply to ports, distinct interaction points on Blocks. In the current version (SysML 1.2), there are two types of ports: standard ports to describe service oriented peer-to-peer interaction through provided/required interfaces, and flow ports to describe items that can flow in and out the block. 

Flow ports and Port specifications are deprecated in version 1.3, but the concepts remain: SysML 1.3 replaces them with two new types, Full Ports and Proxy Ports, both allowing to combine operations to call, and items to flow in and out the block.

●     Full ports

●     A full port represents a part that has been placed onto the main block’s boundary so it can be accessed from external blocks; hence this part is no longer shown inside the main block but as a full port

●     A full port is typed by a block to define its properties i.e. operations to call and/or items that can flow in and out the block. A full port therefore combines both SysML 1.2 flow ports and standard ports, and no longer requires the ball and socket interface notation

●     Full ports can be conjugated like SysML 1.2 flow ports to reverse the direction of items ; it has the same effect on operations i.e. it will change provided features (supported by the owning block) to required features (operations that must be supported by other blocks)

●     Proxy ports:

●     A proxy port acts as a surrogate or placeholder to route all requests to the real port that provides these features (operations, items) ; this port may belong to the main block or an internal part

●     A proxy port does not implement any feature, nor is it a block internal part

●     Proxy ports are typed by Block Interfaces to specify the available features (items and/or operations)

●     Nested ports and nested flows have been introduced in SysML 1.3 to specify an additional level of ports within a port. As shown in the following diagram, the port p1 has two nested ports to associate external blocks directly with the AC in and Audio out.

To define nested ports, the block’s port is type by a block that owns ports

●     Association blocks have also been introduced in SysML 1.3 to specify port compatibility in order to ensure that connecting ports from different blocks doesn’t violate any constraint

○     This is modelled by creating an association block between two interface blocks, and then choosing this association block as the type for a connector between the 2 proxy ports:

Conclusion

SysML 1.3 has revised the concept of Ports to provide a more complete approach and definition compared with version 1.2. For instance it prevents from duplicating ports when a Block both needs to provide or require operations and have items to flow in/out.

This approach could have a significant impact on how you organize and model your system since interfaces are no longer exposed by ports. Instead, it will the block used as the type for the full port, that will realize or use interfaces, or itself own operations.

Once SysML 1.3 is available, it will be interesting to see how SparxSystems will implement it in Enterprise Architect so these new features are easy to use (e.g. with the IBD, to move an internal part of the block to a full port). A feature to easily convert a project from SysML 1.2 to 1.3 whilst keeping a good control over the changes would be useful.