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 |
Tomas Sandkvist 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 #1700283 is a reply to message #1700267] |
Wed, 01 July 2015 12:58 |
Peter Cigehn 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 |
|
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
|
|
|
Goto Forum:
Current Time: Mon Sep 23 13:06:11 GMT 2024
Powered by FUDForum. Page generated in 0.03431 seconds
|