How to correctly model internal application flows or interactions?

[BenAvdicevic]

Hi,

Our users frequently put internal components of an application as a Participant object in a Scenario or Structure diagram.   

This example shows an Scenario of Flows of Application System.  Database was simply added as Participant object in the diagram and placed "inside" the application Ben-Application-1.   

In second example, I am showing Scenario of Application Environment Flows diagram

Here, I have added IT Service Ben-IT-Service-1 as a Participant IT Service and placed it "inside" the Composition application.

Is there anything wrong with modeling this way?

Alternatively, we could insist that our users create a new diagram for the object they want to show internal components, and then use the option called "display  diagram describing the object" - as seen below:

To me, it seems the correct way to "model" the architecture is to crate new diagram and use the "display the diagram describing the object"

But I'm not clear what is the impact if our users do NOT use that option (because it is too cumbersome)

[PBessodes · Accepted solution]

Hello,
We usually do not cross boundaries of an agent. Instead, we promote the black box/white box.
Why ? Because it is the only way to keep the consistency and the control of agent descriptions. Crossing boundary (for flows or any other dependency link) means you are ignoring agent's architecture, which can lead to inconsistencies between structure and dependency.