Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Pool of actors and associations, structuring suggestions
Pool of actors and associations, structuring suggestions [message #1700267] Wed, 01 July 2015 11:25 Go to next message
Tomas Sandkvist is currently offline Tomas SandkvistFriend
Messages: 149
Registered: October 2013
Senior Member
This is probably less Papyrus than UML/SysML, but lets go:

I use a base model (BaseCS) that models a skeleton control system. In this model I have a large number of use cases and standardized actors (to avoid confusion).

Now, when designing a delivery control system (CustomerCS), I often need to specialize certain functions, thus also arises the need for creating customer specific use cases. These use cases should then "reuse" the same actors, because these are "standardized" within the context (i.e. industry).

And now comes the problem. When drawing an association from the actor to the use case, the association will be stored in BaseCS because of the directionality (which is not shown of course, but it is still there), which requires BaseCS to be writable. This also means that BaseCS will be cluttered with associations that actually belongs to one of the CustomerCS projects, which is not so good from a structural standpoint.

I could draw the associations from the use case to the actor, but this is perhaps not UML-correct?

I could break out the actors to a separate model, this will be somewhat cumbersome due to Papyrus lack of refactoring support, but doable as long has I still have only a handful of CustomerCS projects to refactor (I have to force an update of the diagram file of all projects, while having all projects open, explained in another post on this forum).

Any suggestions for the simplest solution?

Regards,
Tomas Sandkvist
Re: Pool of actors and associations, structuring suggestions [message #1700269 is a reply to message #1700267] Wed, 01 July 2015 11:32 Go to previous messageGo to next message
Raphael Faudou is currently offline Raphael FaudouFriend
Messages: 105
Registered: July 2009
Senior Member
Hi Thomas,

You mentioned the simplest action: create associations from specialized UC to general actors. Your associations will be stored with your UC.

Concerning good practices, separating actors into a dedicated package is one of them. why is it so difficult to move actors in a new package of BaseCS model?

Best
raphaël
Re: Pool of actors and associations, structuring suggestions [message #1700273 is a reply to message #1700269] Wed, 01 July 2015 11:48 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 952
Registered: February 2011
Senior Member
Hi Tomas,

The container of the Association is an implementation choice made in Papyrus. I don't think that it's mandatory in UML.

You could create the Association from the Actor to the Use Case (Or vice-versa), then move the association to any Package. The only important thing is that the Association's End typed with the Actor needs to be "Owned by Association" (OtherwIse the Actor will own the Association's End)

Associations in UML have no "source" or "target". They simply have some "ends", and ends can be owned either by the association or the classifier, and can be navigable (or not). The owner of the Association is not especially relevant.

Regards,
Camille


Camille Letavernier
Re: Pool of actors and associations, structuring suggestions [message #1700283 is a reply to message #1700267] Wed, 01 July 2015 12:58 Go to previous messageGo to next message
Peter Cigehn is currently offline Peter CigehnFriend
Messages: 49
Registered: September 2014
Member
Hi Tomas,

Oh, how I have been there with exactly the same problem as you describe! Although this was with other modeling tools, i.e. RoseRT and RSARTE. Both these tools have the principle that the association is packaged in the same location as the element you start drawing the association from, i.e. if you draw the association from the actor to the use case, the association is stored together with the actor, and vice versa.

The pragmatic solution we had to choose in both RoseRT and RSARTE was simply to tell our users to always draw the association from the use case to the actor. This is sometimes very counter-intuitive, but that was the way we had to solve it.

I checked a bit with Papyrus and from what I can see, using the the latest Mars build (or actually I am using the latest Neon build, but I guess not much has happened on master since the Mars release), and from what I can see the association is always stored in the same location as the diagram where you draw the association. The direction you draw the association does not seem to matter. I myself could not really repeat the behavior you describe. Not sure what differs. Are you still using the Luna release where it might behave differently?

Anyway, personally I would suggest that you do as you proposed yourself, i.e. draw the association from the use case to the actor to get the association to be stored where you want it, i.e. together with the use case, as you normally want it to be with large models where you want to re-use actors in the way you describe. As long as you set the desired navigability at each end, it does not really matter in which direction you originally drew it on the diagram.

Hope this helps!

/Peter Cigéhn
Re: Pool of actors and associations, structuring suggestions [message #1700291 is a reply to message #1700267] Wed, 01 July 2015 13:33 Go to previous message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Tomas,

As actors are classifiers, they support generalization. You could
require users in their CustomerCS to create actors that specialize the
common actors defined in the BaseCS, according to each actor's role.
Then the ownership of all of the associations naturally defaults into
packages in the CustomerCS. (note that neither Actor nor UseCase has
the capacity to own association ends, so all associations between them
are de facto undirected in either direction)

Possibly, you could define in a plug-in a edit-helper advice for the
configuration of the CreateRelationshipRequest for associations that,
when an association end is in the BaseCS model, sets the new
association's container to be in the CustomerCS model regardless. This
eliminates the need for error-prone habits in the user.

HTH,

Christian


On 2015-07-01 11:25:36 +0000, Tomas Sandkvist said:

> This is probably less Papyrus than UML/SysML, but lets go:
>
> I use a base model (BaseCS) that models a skeleton control system. In
> this model I have a large number of use cases and standardized actors
> (to avoid confusion).
> Now, when designing a delivery control system (CustomerCS), I often
> need to specialize certain functions, thus also arises the need for
> creating customer specific use cases. These use cases should then
> "reuse" the same actors, because these are "standardized" within the
> context (i.e. industry).
>
> And now comes the problem. When drawing an association from the actor
> to the use case, the association will be stored in BaseCS because of
> the directionality (which is not shown of course, but it is still
> there), which requires BaseCS to be writable. This also means that
> BaseCS will be cluttered with associations that actually belongs to one
> of the CustomerCS projects, which is not so good from a structural
> standpoint.
>
> I could draw the associations from the use case to the actor, but this
> is perhaps not UML-correct?
>
> I could break out the actors to a separate model, this will be somewhat
> cumbersome due to Papyrus lack of refactoring support, but doable as
> long has I still have only a handful of CustomerCS projects to refactor
> (I have to force an update of the diagram file of all projects, while
> having all projects open, explained in another post on this forum).
>
> Any suggestions for the simplest solution?
>
> Regards,
> Tomas Sandkvist
Previous Topic:FlowPort Icons missing
Next Topic:Solver for Papyrus
Goto Forum:
  


Current Time: Fri Mar 29 09:10:40 GMT 2024

Powered by FUDForum. Page generated in 0.02478 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top