Is this the right way to model communation between 2 components in SYSML / Rational Rhapsody

[Kev tronik]

I try to model the communication between a sensor, that measures a distance and a SmartDevice, that measures time. The Smartphone runs a function 'Calculate velocity'. The data Transmission is via Bluetooth. I am using an internal block diagram (cause I often read that internal block diagrams are used to model the interaction of components with each other). At that Point I ve created:

Block1: Sensor

Block2: SmartDevice

Flowport1 on Sensor: flowport_Bluetooth

Flowport2 on SmartDevice: flowport_Bluetooth

between these two Bluetooth flowports I create a bidirectional flow called 'Bluetooth'

Then I use a Itemflow that I call Velocity. Unfortunately I can't see the direction, i fthe velocity-data goes out of the sensor or in the sensor. (Maybe I should use Flow Properties to model 'velocity' ? )

Now I feel like this is somehow not the way to go!

I Need a more structured way to work on this because the big Goal of my work is that I can model different architectural realizations for one function. For example: function 'Calculate velocity' can be realized by a sensor+smartdevice or sensor+smartphone+cloud.

How can I model a function like 'Calculate Velocity' in SysML + Rational Rhapsody?

Thanks for your Feedback!

[Michael Campbell]

You have to define the itemflow in the properties of the block. 

typically in out or inout depending on the direction or bidirection.  

[Eran Peleg (Metaphor)]

Hi Michael

The static view – Blocks with Ports, either SysML Flow-ports with direction or Standard-Port from UML ready to accept the Lollypop – means Interface or API of the receiving component (Block).

In order to see the ItemFlow direction combine Connector and Information-Flow (means the connector realized the information-flow).  Just add connector and look in its properties.  The following example is from EA, but Rhapsody does it too:

You may use "logical" components or physical components with Allocation between them.

BTW, Stereotyped elements simplify the visual identification of different role of each element.

 

The dynamic flow may be design using either, or both – Activity Diagram (AD) or Sequence Diagram (SD).

In the AD, each Partition represents (and reference) a Component (Block); in SD each Lifeline may represents the Component or its Interface (if you're using the UML Lollypop concept).

In AD you may use Object-Node as an instance of a message passed between the components; in SD you may use Method arguments with parameters of the message (or object) passed between the Lifelines (Interface or the Block itself).

AD:

SD

 

The same methodology can be implemented using most UML tools, especially in Rhapsody and EA.

 

Good luck

Eran

 

=============================

Eran Peleg, CEO, Metaphor Vision Ltd.

Metaphor ID: 513394734

Phone: +972545346060

eMail: epe...@metaphor.co.il

Skype: EranPelegMetaphor

=============================

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at https://groups.google.com/group/sysmlforum.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/44519c19-ab5c-4624-851e-f20be8fcf419%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[geoff]

Eran,

Your model appears to assert that the «block» Fire has a state "Detected".  How does that state influence the behavior of a realizing instance of the «block» Fire?  I assert that there is no such state of the «block» Fire.  What services does the «block» Fire Provide?  Heat, Light, Smoke, Gases (combustion by-products).  These are the objects which flow from Fire and potentially the phenomenology objects which a «block» Sensor might Require to provide its services of reporting the exchange of said object. I would further assert that it is reasonable to assume that the exchange between Fire and Sensor is asynchronous. The «block» Sensor may have a State "Fire Detected" which results in a behavior.  Perhaps I'm being pedantic, but I suggest this distinction is important.

Geoff

[Eran Peleg (Metaphor)]

Hi Geoff and others

See below …

Thanks

Eran

 

=============================

Eran Peleg, CEO, Metaphor Vision Ltd.

Metaphor ID: 513394734

Phone: +972545346060

eMail: epe...@metaphor.co.il

Skype: EranPelegMetaphor

=============================

 

From: sysml...@googlegroups.com [mailto:sysml...@googlegroups.com] On Behalf Of geoff

Sent: Thursday, June 14, 2018 4:51 PM
To: SysML Forum

Subject: Re: [SysML Forum] Re: Is this the right way to model communation between 2 components in SYSML / Rational Rhapsody

 

Eran,

 

Your model appears to assert that the «block» Fire has a state "Detected".  How does that state influence the behavior of a realizing instance of the «block» Fire?

[EP] a. if you're referring to the :Fire in :SensorCtl – it is a :Fire with state [Detected] within the Block SensorCtl (Partition represents Block = Component)

b. If there Is a Guard on the Flow (either Object or Control) the State guides the flow according to the Guard (as below)

  I assert that there is no such state of the «block» Fire.

[EP] Fire, in that example, is an Object not a Block;  However, it has a Statemachine with that state, otherwise it is impossible to provide the :Fire[Detected].

 

  What services does the «block» Fire Provide?

[EP] The dynamic view is not presented in my reply.  However, the Block (component) SensorCtl, Log,and Sensors, each has many services described as Use-Cases (UC) and Activity Diagrams for each (at lease Basic, Alternate, and Exception flows, as Activity Diagram(AD), for each UC).

  Heat, Light, Smoke, Gases (combustion by-products).  These are the objects which flow from Fire and potentially the phenomenology objects which a «block» Sensor might Require to provide its services of reporting the exchange of said object. I would further assert that it is reasonable to assume that the exchange between Fire and Sensor is asynchronous.

[EP] In AD it is sometime not so clear (or not so important) if a flow is synchronous or a-Sync.  So, if that matter is not clear, it is better to use Sequence Diagram (SD) instead or in addition to AD.

The «block» Sensor may have a State "Fire Detected" which results in a behavior.  Perhaps I'm being pedantic, but I suggest this distinction is important.

[EP] I agree with your observation.  Therefore, my methodology also suggests (or force) using Statemachine for both, each Component (represented by a Block) and Object (represented by a Class or Block with a specific Stereotype (ST)).

 

Geoff

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at https://groups.google.com/group/sysmlforum.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/983f4e3a-7c89-4c63-aeab-14056c8bc53c%40googlegroups.com.