Book a Demo

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - i

Pages: [1]
1
General Board / SysML AbstractRequirement relationships
« on: July 05, 2022, 06:26:33 pm »
Dear KP,

I hope you found my explanations about the trace relationship useful.  :)

After reading your latest reply:
I was about to provide further information to your latest request:
Quote from: KP
Now use the same argument for /refinedBy /satisfiedBy and /verifiedBy
when I realised someone had already locked that topic, hence here it comes a new one to fulfil your request. Apologies for that, it would be simpler to continue the discussion in the original one, but it wasn't me who locked it.

Please find below a requirement diagram I created to support my explanation to your request:

Please note that A is now the supplier, while in the previous post it was the client. Having now more clients it seemed right to start with A as supplier and then the rest as clients. I hope this doesn't create additional confusion.

The key here is that A, as a requirement, is the supplier of all those relationships drafted in the diagram.

Think of A as the main piece of information here, driving the rest (clients). Meaning that any change in A could potentially impact the rest of the elements in the diagram, but not the other way around.

Then, you would read those relationships as follows:
  • B traces to A, and A is traced from B.
  • C satisfies A, and A is satisfied by C.
  • D refines A, and A is refined by C.
  • E verifies A, and A is verified by E.
With this key idea, you may go now to the SysML spec definitions:
Please read them again, and let me know if you have any further questions.

Honestly, they all seem fine to me but, as any other human, I might be getting something wrong, in which case I would really appreciate your input.

In any case, please bear in mind that I'm here just trying to help, not a guru, not a writer of the spec, just a SysML user as any other.  :)

Sincerely yours,
i

2
Dear KP,

From my point of view the SysML 1.6 spec is correct, though the wording they chose might be a bit too convoluted sometimes.
This is how I read and undestand the parts you quote.

Let's go with the 1st one:
Quote
/tracedTo : NamedElement [0..*]
Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.
Here we have a trace relationship (kind of a dependency really) that involves a requirement (this requirement) which is a supplier of trace relationships (arrowhead end of the trace relationship in its graphical representation), meaning that there are other requirements whose definition depend on this requirement. Those dependant requirements are the clients, which occupy the "from" end of those trace relationships, that is why the relationships are "derived from" them. Hence, all those clients are "traced to" this supplier.

Now the 2nd one:
Quote
getTracedTo () : NamedElement [0..*]
bodyCondition:
Trace.allInstances()->select(base_Abstraction.client=self).base_Abstraction.supplier
OK, here it becomes a bit trickier, because honestly, from the name of the method "getTracedTo" you could really understand it in either of the following ways:
  • get elements that trace to the one given as input (clients for a given supplier)
  • get elements traced to by the one given as input (suppliers for a given client)
If it was up to me, the natural definition for this method would be the 1st one but, if you go to its "body", it is clearly the 2nd one:
  • Trace.allInstances() --- "from all trace relationships..."
  • ->select(base_Abstraction.client=self) --- "...get those that have as client this requirement (self)..."
  • .base_Abstraction.supplier --- "...and for those, get their supplier."
Furthermore, this definition keeps consistency with the getTracedFrom method described with more detail in the spec and quoted previously by me in a comment in this thread. Here you have it again:
Quote
getTracedFrom (in ref : NamedElement) : AbstractRequirement [0..*]
The query getTracedFrom() gives all the requirements that are clients ("from" end of the concrete syntax) of a
«Trace» relationship whose supplier is the element in parameter. This is a static query.
bodyCondition:
AbstractRequirement.allInstances()->select(tracedTo->includes(ref))

Wrapping up, I believe the definition of the trace relationship in the SysML spec is consistent but, as I said, probably put in a too convoluted way.

I hope this helps.

Best Regards,
i.

3
Dear KP,

The getTracedFrom operation definition from the SysML 1.6 spec section 16.3.2.8 might also contribute to clarifying this topic:

Quote
getTracedFrom (in ref : NamedElement) : AbstractRequirement [0..*]
The query getTracedFrom() gives all the requirements that are clients ("from" end of the concrete syntax) of a
«Trace» relationship whose supplier is the element in parameter
. This is a static query.
bodyCondition:
AbstractRequirement.allInstances()->select(tracedTo->includes(ref))

getTracedFrom(Supplier) returns all the Clients of the trace relationship for a given Supplier.

In the case we're discussing here:
Quote
a trace from A to B
in which I hope we've already agreed that A is the client and B the supplier, the query:
Code: [Select]
getTracedFrom(B)will return A as a result, which means that B is traced from A, and not the other way around.

I sincerely hope this helps.
i



4
No, I'm right. See SysML 1.6 (formal-19-11-01) section 16.3.2.1

AbstractRequirement has a derived attribute:

Quote
/tracedTo : NamedElement [0..*]
Derived from all elements that are the client of a «trace» relationship for which this requirement is a supplier.

Well... you aren't.

In "A traces to B", the client is A and the supplier is B. Do we agree on that?
(B is the supplier because a modification in B might impact A...)

The arrow in the graphical representation of the relationship of course points from the client to the supplier.



Then Sparx EA calls the client "Source" and the supplier "Target" and "Destination", which is really unfortunate because anyone could erroneously identify "source" and "supplier" as synonyms, when in this case I'm afraid they are not.



I hope it's clearer now.

Best Regards,
i

5
Yeah, EA gets it wrong. A trace relationship from A to B means that B is "traced to" A and A is "traced from" B.

"A trace relationship from A to B" means literally that:
  • A traces to B
  • B is traced from A
which is just the opposite to what you captured in your comment quoted above.




can't get the image thingy to work (newbie alert)

You may try uploading the image to imgur (or similar) instead, and copy the image url like this
Code: [Select]
[img]https://i.imgur.com/2PCdxUg.gif[/img]
which results in:

6
General Board / Re: state machine guard transition
« on: May 12, 2022, 02:42:06 pm »
Hi qwerty, thanks for your comment :)

Shouldn't the "do" be an "entry" instead?
It would work as well, same as if you used the "exit" operation instead. As long as only one of these routines runs at a time it doesn't make any difference at which point (operation) the assignment is done.

Isn't there History state for exactly that purpose?
Not as far as I know, but I'm no expert either. If there's a built in history state record it would be cleaner to use it. It would be great if someone with more insight in this matter could clarify if this is possible or not.

Regards,
i.

7
General Board / Re: state machine guard transition
« on: May 11, 2022, 11:12:20 pm »
What if in addition to [Runtime] and [Mode] you captured in [LastRoutine] the last routine as a state and you included that as a condition in both cases?

Otherwise you could also achieve this with a bit of Javascript setting a variable when you enter in any of those routines and then use that variable in the guard as well.
Code: [Select]
this.last_routine = "A";
This is what I've done here:


Transitions are triggered here by signals, namely: goToA, goToB, continue and end, just for simplicity sake.
In the case of the transition from Evaluate back to either Routine A or Routine B, the guard
Code: [Select]
this.last_routine == "A";allows the state machine to go back to Routine A when that condition is True at the same time the "continue" signal is triggered, and similarly in the other case.

I hope this helps :)

8
+1
I'm also interested in this topic.
Similarly, it would be great to set a diagram to a default view of Specification or List with a given set of columns.

9
General Board / Re: Manual simulation issue
« on: May 11, 2022, 09:32:07 pm »
Hi,

The activity might get stuck in the join element because it doesn't generate the output token until all the input tokens arrive to it.

In the following example, since the guard to get out from Action 3 is false, Action 4 won't be executed and the join element will get stuck there even if it correctly received the token from Action 2.



If you set the guard to true, or if you remove it, both tokens will reach the join and the final node will be reached.

I hope this makes sense, otherwise please let me know.
i

10
General Board / Re: Dynamic SysML Simulation with Python
« on: May 11, 2022, 08:53:06 pm »
Hi SJ,

I honestly have no clue either, but you might want to use the pywin32 library as they claim to do for developing EA add-ins?
One question, could you please describe a minimum working example that would satisfy your needs?
It sounds like a super cool capability, thanks for bringing it up, I'll follow this thread with interest.
Good luck :)
i

11
Dear Geert,

I've tried again the Compact option and this time it worked alright. I don't understand why it didn't work before.

Many, many thanks for this tip.

Best Regards,
i.

12
Dear Geert,

Many thanks for your quick reply. I've tried both of your suggested solutions (Compact & Transfer) and unfortunately in both cases the EAPX file (database) size remains unchanged.

I guess I'll stick to using external artifacts only from now on, because the internal artifact option is clearly unsustainable, which is a pity because in some instances it would be really handy to have the actual file available within the model.

Best Regards,
i.

13
I'm using Sparx EA 15.2.1554 (Build: 1554) in Windows 10.

I've noticed that when I delete files stored in the model as internal artifacts, the size of the model doesn't decrease.

Steps to reproduce this issue:
  • Create a new project.
  • Create a package in the main node of the project.
  • Create a package diagram in the package.
  • Save the project.
  • Check the size of the EA Repository (.eapx) file.
  • Drag and drop a file into the package diagram. Tip: choose a file that weights considerably more than the curreny EA Repository file, for instance 10MB, it'll be simpler to spot the issue later.
  • From the 3 possible options, select "Artifact (Internal)".
  • Check that the file appears both in the diagram and in the project tree under the package.
  • Save the project.
  • Check the size of the EA Repository (.eapx) file. It should have increased in at least the size of the chosen imported file.
  • Right click in the file within the project tree.
  • Delete the file.
  • Save the project.
  • Check the size of the EA Repository (.eapx) file. It should have decreased in at least the size of the deleted file, but it doesn't, at least for me.

I might be missing some final step such as purging, cleaning-up... but I don't find any way to do so.

I've tried closing and opening the file again, closing and opening the Sparx EA again...

Apologies if this is just lack of knowledge from my side, and many thanks for your support in any case.

i

Pages: [1]