SysML specification for containment relationship

[Robert]

Dear all,

this about the interpretation of the the containment relationship and
its
implementation on the tool side.

We are using MagicDraw 14.0 and SysML 1.1sp2.

As soon as a containment relationship is created between two
requirements the
contained requirement is automatically relocated to the package
of the container. This prevents distribution of requirements in
different
packages, in particular if a contained requirement belongs to a
subsystem.
I would like to properly distribute them.

We have a requirement A which contains requirement B and C.
A is a requirement on very high level of the system which is
decomposed into
requirements B and C on a subsystem level.
To avoid to have all requirements together (because B and C belong to
the
subsystems) we want to put A, B and C in different packages but still
have
the containment relationship (as foreseen by the SysML spec.)
that's why I think it is different from a package containment. They
are not the
same.

What is your perception?

Cheers,

Robert

[Darren R C KELLY]

Hi Robert,

I am involved with applying Magicdraw UML's SysML plugin to real-world applications.

Your questions are very interesting ones that I've noticed arising
frequently from students in my attempts to date to teach SysML.

I will try to answer some of your questions as they apply to the
spec here and will answer tool-specific stuff outside this forum
be sending you a Magicdraw project file directly with examples.

Robert wrote:

Dear all,

this about the interpretation of the the containment relationship 
and its implementation on the tool side.
  

In advance, most of the issues you identify are not about interpretation
of containment nor how it is implemented in any tool. See below.

We are using MagicDraw 14.0 and SysML 1.1sp2.
  

The containment aspects are taken almost directly from UML2
as the UML4SysML intersection. There are other strategies
in SysML for achieving what you want in any SysML tool.

As soon as a containment relationship is created between two
requirements the contained requirement is automatically relocated 
to the package of the container. 

That is what containment means in UML4SysML.
It is meant to "steal" ownership (and thus physical "location" in the model).
Whether package containment or namespace containment
(like within a containing component) the ownership is taken.
That is likely the same in every tool.

This prevents distribution of requirements in different
packages, in particular if a contained requirement belongs to a
subsystem.
  

This is probably mixing terminology. If I may interpret your sentence,
what you want is the ability to supplement physical containment
(ownership) or requirements with logical grouping ("belonging")
and there are a number of ways of achieving that in SysML.

It also seems that you might be better considering how
a requirement might be satisfied by a subsystem,
rather than asserting (a priori) that is "belongs" to it.

[Aside: in SysML a <<Subsystem>> is a non-normative
extension of a Block, whereas in the UML2 standard
profile for Magicdraw <<subsystem>> has metaclass
Component. I will assume we are talking about SysML.]

And you can also use <<allocate>> to establish
further logical groupings parasitically without
affecting the ownership of a shared requirement
that is already physical packaged (perhaps as
a read-only module).

One strategy is to decouple the requirements hierarchy
entirely from the block/system/subsystem hierachy used
to <<satisfy>> the requirements.

I would like to properly distribute them.
  

Maybe the <<copy>> between Master and Slave is what you need.

See SysML spec 1.0 final  (07-09-01.pdf) (my underline and emphasis):

16   Requirements
16.1 Overview
..

A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML
namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its
containing child requirements. ..

There is a real need for requirement reuse across product families and projects. Typical scenarios are regulatory, statutory,
or contractual requirements that are applicable across products and/or projects and requirements that are reused across
product families (versions/variants). In these cases, one would like to be able to reference a requirement, or requirement
set in multiple contexts with updates to the original requirements propagated to the reused requirement(s).

The use of namespace containment to specify requirements hierarchies precludes reusing requirements in different
contexts since a given model element can only exist in one namespace. Since the concept of requirements reuse is very
important in many applications, SysML introduces the concept of a slave requirement. A slave requirement is a
requirement whose text property is a read-only copy of the text property of a master requirement. The text property of the
slave requirement is constrained to be the same as the text property of the related master requirement. The master/slave
relationship is indicated by the use of the copy relationship.

We have a requirement A which contains requirement B and C.
A is a requirement on very high level of the system which is
decomposed into requirements B and C on a subsystem level.
  

Again, this seems to be reempting the satisfaction of the requirements
by particular subsystems (or eventually blocks). If you think of the
entire requirements hierarchy as a type of logical view of the system
then those requirements might be satisfiable by entirely different
systems blocks. In other words, the <<satisfy>> network can be handled
a lot like "design by contract" against interfaces.

You might like to think of it this way:
The requirements are NOT on the blocks of the system.
The requirements are on the real-world system.
The blocks are merely a model of that real-world system.
You can change the block model entirely without changing the requirements.
Both the requirements and the blocks "look" at the real-world system.
The <<satisfy>> network makes a claim about the contract being met,
and the <<verify>> network tests whether that contract is being met.

If you do want to package requirements locally with subsystems that
can also be done, so then the above decoupling principle simply works
at the level of that subsystem.

It is so that the levels of a requirements hierarchy (progressive refinement)
may correspond well with the levels of the subsystems that satisfy them,
however that does not mean they have to be physically packaged together !

Also, in terms of workflow, there are other advantages to having requirements
and subsystems packaged separately (worked on by different people/roles).

To avoid to have all requirements together (because B and C belong to
the subsystems)

I would like to see the text of those requirements to see in what sense
they already "belong" to the subsystems (already). Could you please
email a concrete example to here for further discussion.

 we want to put A, B and C in different packages but still
have the containment relationship (as foreseen by the SysML spec.)
  

Then it is not a containment relationship. Containment owns. Basta.
You want to have your cake and eat it, too.

that's why I think it is different from a package containment. 
They are not the same.
  

What is your perception?
  

My perception (only, based on an example without concrete requirements text),
is that you need other SysML relationships and mechanisms to achieve what
you want, and the problem is not tool specific. You need to change your
syseng strategy to decouple requirements and satisfaction of them.
BTW this may also help managing verification of requirments, too.

Thanks for your questions,

Darren

-- 
Dr Darren R C Kelly, BSc, PhD
No Magic Inc.,
Expert Advisor,
Science, Engineering, and Education
Phone: +61 (2) 9386 0090
Mobile: +61 (2) 405 029 008
Post: PO Box 1816, Bondi Junction, NSW 1355, Australia

Magicdraw UML: Architecture made simple !