RE: [SysML Forum] SatisfiedBy-relation

[edi...@sysmlforum.com]

> Instead, my idea is to use a dependency relation

> <<SatisfiedBy>> from the project specific requirements to the

> Blocks in the framework. Would this notation be SysML compliant?

> I have only seen the SatisfiedBy stereotype inside a Callout box.

 

Your inverse dependency workaround to address a tool-specific issue would be SysML *compatible*, but not *compliant* with the specification. So you should document your SysML model accordingly to explain the rationale for your workaround.

 

BTW, your inverse dependency should be named starting with a lowercase letter (i.e., <<satisfiedBy>>, rather than <<SatisfiedBy>>).

 

/Cris

 

__________________________________________________

Cris Kobryn

Editor, SysML Forum

edi...@SysMLforum.com

-------- Original Message --------
Subject: [SysML Forum] SatisfiedBy-relation
From: Hans Natvig <hans....@consoden.se>
Date: Wed, May 21, 2008 10:42 pm
To: SysML Forum <SysML...@googlegroups.com>


We are working with multiple models in parallel, using Enterprise
Architect. Some which are general (framework) and used as building
blocks in more project specific models. The framework model is used by
importing it to the project specific model as a root model (from XMI).
The model is made read-only to the staff working on a specific
project. When an updated version of the framework is released it is
imported again into the project specific model. Relationships that
originate from elements outside the framework root model are retained
during update, also if the relationships have framework elements as
target elements. However, in EA, relationships pointing in the
direction from the framework cannot be retained when framework model
is imported again with a new version.

One typical relationship that we would like to model is the SysML
<<Satisfy>> relationship. We want to use this relationship from Blocks
in the framework to requirements in the project to model that the
specific project requirements are fulfilled by using blocks from the
framework. But again, relationships pointing in the direction from the
framework cannot be retained when framework model is imported again
with a new version.

Instead, my idea is to use a dependency relation <<SatisfiedBy>> from
the project specific requirements to the Blocks in the framework.
Would this notation be SysML compliant? I have only seen the
SatisfiedBy stereotype inside a Callout box.

/Hans

[Hans Natvig]

Thank you Cris for your answer.

Is my problem really a tool specific issue? In my view every tool
should suffer from the same problem.

The <<satisfy>>-relationship is created in the project specific model
as a dependency from a block inside the framework package (which is an
imported package from a separate model) to a requirement in the
project specific model. The block inside the framework package owns
this relationship in EA, as well as in other tools I imagine. Hence,
when the framework package is updated with a new version later on, via
a framework model XMI-file, it is expected that the relationship is
discarded.

My conclusion is that SysML lacks a way to express that a requirement
is satisfied by a block without using a callout box. Unfortunately EA
does not support the user a lot with callout-boxes. New relationships
cannot be established via callouts nor are they available to support
writing callouts. However, the underlying relationship is always
pointing from the source Block to the target Requirement. So, even if
EA would incorporate better support for relationships in Callout-
boxes, this won’t help.

Our main goal is to find a way to document that all requirements are
accounted for, using parts from an imported framework as well as
additional elements developed within the project specific model. Is
there another way?

[edi...@sysmlforum.com]

> Is my problem really a tool specific issue? In my view every

> tool should suffer from the same problem.

 

I accept your point that many, perhaps most or all, SysML/UML modeling tools suffer from similar implementation problems. If that is the case, your problem should be addressed by the SysML revision process which is supposed to address tool implementation as well as usage issues.

 

Re usage vs. implementation issues: Most language design problems benefit from separating usage from implementation issues in order to determine a pragmatic solution with the best design tradeoffs. The usage issue here involves the definition of inverse relationships (e.g., <<satisfy>> and <<satisfiedBy>>) which need to be defined consistently as well as correctly if the language is to be easy to learn and apply. If anyone is interested in having me expound upon this I will be glad to do so.

> My conclusion is that SysML lacks a way to express that a requirement
> is satisfied by a block without using a callout box.

> Unfortunately EA does not support the user a lot with callout-boxes. 

 

Callout boxes are a SysML hack proposed by persons who are clueless about how UML dependencies work. Since they are gratuitous and inconsistent with basic UML language design principles it is not surprising that your SysML tool has chosen not to implement them.

 

> So, even if EA would incorporate better support for relationships in Callout-boxes, this won't help.

 

So back to your original problem ...

> Our main goal is to find a way to document that all requirements are accounted for,

> using parts from an imported framework as well as additional elements developed

> within the project specific model. Is there another way?

 

In some modeling tools you may be able to overwrite the previous version of the imported Platform Independent Model (PIM) framework with the new version without breaking all the links. (I am assuming here that your framework is relatively stable with clearly defined reusable elements/interfaces; if this is not the case you really shouldn't be treating it as a framework!) However, even if we assume that there is a fundamental implementation problem here, you should be able to mitigate your problem by localizing and documenting the model elements in your imported PIM framework that satisfy your requirements. If you import these into your PSM in a measured way (e.g., selective import) you should be able to significantly reduce your problem and make it more manageable.

 

/Cris

 

__________________________________________________

Cris Kobryn

Editor, SysML Forum

edi...@SysMLforum.com

-------- Original Message --------
Subject: [SysML Forum] Re: SatisfiedBy-relation
From: Hans Natvig <hans....@consoden.se>

[BERNARD, Yves]

Hello,

Interesting subject !

The point is that all these relationships are derived from "Dependency" what is, from my point of view, not semantically correct if you refer to the UML definition of Dependency :

"[...] A dependency implies the semantics of the client is not complete without the supplier." (UML Superstructure Specification, v2.1.1, p62).

If what you're talking about is actually a "framework", items from this framework should not depend from elements of your application. There should be no more dependency in the opposite direction, as far as the model of your application is independent from the implementation.

Then, I think that we have a better modeling of what an allocation actually is in the MARTE profile, Allocation domain view(cf. ptc/07-08-04, fig. 12.1, p137). Note that, according to this definition, defining an allocation does not create any dependency between items from the application side and from the platform side. Unfortunately, the UML representation they have finally chosen extends the Abstraction metaclass (a Dependency subclass) what doesn't, from my point of view, comply with their "domain" definition.

I think we need a new model element, more consistent with the previous domain definition.

Cheers,

Yves

-----Message d'origine-----
De : SysML...@googlegroups.com [mailto:SysML...@googlegroups.com]De
la part de Hans Natvig
Envoyé : jeudi 22 mai 2008 07:42
À : SysML Forum
Objet : [SysML Forum] SatisfiedBy-relation

We are working with multiple models in parallel, using Enterprise
Architect. Some which are general (framework) and used as building
blocks in more project specific models. The framework model is used by
importing it to the project specific model as a root model (from XMI).
The model is made read-only to the staff working on a specific
project. When an updated version of the framework is released it is
imported again into the project specific model. Relationships that
originate from elements outside the framework root model are retained
during update, also if the relationships have framework elements as
target elements. However, in EA, relationships pointing in the
direction from the framework cannot be retained when framework model
is imported again with a new version.

One typical relationship that we would like to model is the SysML
<<Satisfy>> relationship. We want to use this relationship from Blocks
in the framework to requirements in the project to model that the
specific project requirements are fulfilled by using blocks from the
framework. But again, relationships pointing in the direction from the
framework cannot be retained when framework model is imported again
with a new version.

Instead, my idea is to use a dependency relation <<SatisfiedBy>> from
the project specific requirements to the Blocks in the framework.
Would this notation be SysML compliant? I have only seen the
SatisfiedBy stereotype inside a Callout box.

/Hans

This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

[Pete Kirkham]

In terms of the tool rather than the model, in the last couple of
weeks I've been using EA's automation interface to provide reverse
engineering and code generation for domain specific language (EADS
GEMS, used for satellite system monitoring). If you were to perform
the import of your model via that mechanism rather than XMI, then you
could make EA preserve the relationships in both directions. The
obvious disadvantage is that you have to get someone write a plugin
which duplicates most of the XMI import functionality already in the
tool, and the import may take longer as adding or updating elements
one-by-one via the automation interface appears to take longer than
deleting everything and bulk loading via XMI.

Pete