Messages

1

General Board / Re: How do you model a debounce of a signal?

« on: June 01, 2024, 02:18:09 am »

Do you want to A) keep a signal to a ceratin value for 500ms or B) you want to check if for 500ms a signal kept all the time a certain value?


If A)
Then you simple set the value and then use a timer event to delay furher execution

if B)

Your described approach would not be correct, because it would simply check that after 500ms have passed and the signal value is ON. So if from ms 2 to ms 499 the value of the signal was OFF, and at ms 500 the signal became ON, then you would still continue with the next steps.

Debouncing is usually a state based behavior so, a state machine would be better. But if you want to model with an Activity Diagram, then you need variables to represent the expiration of the timer.  The timer tracking variable is se to true if the timer expires and you have a decision loop which continously checks if Signal is ON and the timer has expired.

2

General Board / Re: CallBehaviorAction versus CallOperationAction in Practical SysML Book

« on: June 01, 2024, 01:46:28 am »

Hi

Do you have a diagram image related to the text?

The author talks about a "Hybrid-Approach", and he calls it hybrid, because he uses a CallBehaviorAction to call An Activity (this is normal) but he also links the CallBehaviorAction to an Operation (normally CallBehaviorActions have nothing to do with operations) by means of an Allocation relationship (He does not link the Operation with the Activity directly).

Apparently he states, that the Action's behavior is described by the Activity (because he calls the activity by the CallBehaviorAction) and he states the the Action's behavior is realized by the Operation (because he allocates the CallBehaviorAction "not the Activity" to the Operation).

In the text it is however not clear what he means by inherited and redefined. So it is hard to tell what the real use case of this approach is, but it maybe can look something ike this:


1) Two Blocks represent different versions of something and there is a diagram that describes the behavior of each block

AcitvityA
   --AllocatedTo--> BlockA
ActivityB
   --AllocatedTo--> BlockB
BlockA
   --doSomething (operation)
BlockB
   --Generalization  -->BlockA
   --doSomething (inherited)

ActivityDiagramX
   -doSomething:ActivityA (CallBehaviorAction) the Action has the same name as the operation to visually make it look like its the operation but it actually calls ActivityA
           --allocatedTo-->doSomething(from BlockA)

ActivityDiagramY
   -doSomething:ActivityB (CallBehaviorAction) the Action has the same name as the operation to visually make it look like its the operation but it actually calls ActivityB
           --allocatedTo-->doSomething(from BlockB)


So in the above example, two different diagrams which "appear" to call the same operation (they dont actually do it) have a different behavior for the "same called operation".


In EA you cant link Operations, so it is not possible to do something similar.

I however couldnt think of a single use case, which would be supported by the modelling tools EA, Rhapsody, Cameo or PTC Modeller where this approach would be benefitial.




In EA you cant link Operations, so it is not possible to do something similar. I however dont think this approach has any benefits

3

General Board / Re: Linking Part Properties with Composite Aggregations

« on: June 01, 2024, 12:03:04 am »

Yes, but this is the relationship between the part and its classifier. What I want is to relate a part created via script , with a composite aggregation that was also created via scipt.

So an example:

If I have three Blocks Sys, SubSysA, SubSysB and draw composite aggregation relationships between them in EA, EA will automatically create parts under the Sys Block and EA will automatically relate a name change in the Composite Aggregation "Source Role" to the Name of the corresponding created Part

As soon as one draws the composite agreggations we get the Sys Block with two unnamed parts:
Sys
:SubSysA
:SubSysB

If one updates the source roles of the composite aggregations to ssA and ssB then EA automatically updates the names of the parts and one gets:

Sys
ssA:SubSysA
ssB:SubSysB

So the above example is the default behavior when modelling within the tool and now I wish to make this work via script.


What I do in my script is the following:

First I create the parts via Script and thus get:

Sys
ssA:SubSysA
ssA:SubSysB

Then I create the composite aggregations from Sys to SubSysA and from Sys to SubSysB.

Now the issue is that thevia script created composite aggregations are not related to the previously created parts, how can I tell EA, that those composite aggregations correspond to specific parts?

4

General Board / Linking Part Properties with Composite Aggregations

« on: May 17, 2024, 05:38:34 am »

Hi Everbody,

When one create a Composite Aggregation on  a Diagram this automatically creates a Parts and it links the Role Name of the COmposite Aggregation with the name of the Part, such that if the Role Name is changed the part name is also changed.

I wish to have the above behavior but through a Script.

Currenlty  I am creating parts first in the browser automatically via a VBA Script, but since parts created in the browser do not automatically create Composite Aggregations I proceed to create the composite aggregations per Script as well.

But the created parts and aggregation are not related to each other, so the the above mentioned role name changes in the aggregation reflect automatically in the part.

Does anybody now how one can tell EA, that a certain composite aggregation corresponds to a certain Part.

Thanks

Bo