Author Topic: Nesting classes (and generalization)  (Read 8458 times)

HarryPlotter

  • EA Novice
  • *
  • Posts: 18
  • Karma: +0/-0
    • View Profile
Re: Nesting classes (and generalization)
« Reply #15 on: May 04, 2016, 12:32:23 pm »
Sometimes the automatic nesting is a good thing.
For example when using BPMN diagrams, or modelling user interfaces.

The option Tools|Options|Objects|Support for Composite Objects controls the automagical nesting behavior.

Geert

Hello Geert.

Can I trouble you for a thought (or an edict)? We have an ongoing task to rationalise/harmonise multiple discrete BPMN models that have been imported to a single repository. We had across-the-board 'nesting' rules:
  • collapsed subprocesses are nested within the process package
  • private processes are nested within the collaboration package.

That all went really well until we started unpacking one particular model, and discovered some of the existing 'private processes' involve complex collaborations. The result is (for example) a process within a collaboration within a process within a collaboration. EA allows this, but we're unsure if we should.

Is it legal? Recommended?

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 8483
  • Karma: +207/-26
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Nesting classes (and generalization)
« Reply #16 on: May 04, 2016, 04:39:58 pm »
Hi Harry,

At this one client we extensively use BPMN, and we discovered through a lot of painly experience, trial and a lot of error that the best way for us was to never ever use processes or activities "as link" on a BPMN diagram, and to never ever nest actual processes or activities in other processes.
The way this works for us is that we have a library of Business Processes and Business Process Activities.
Each of those elements has their own BPMN diagram detailing the process.
Whenever we need to use an existing Activity or Business Process we use the tagged value calledActivityRef to reference the BP or BPA we are actually calling.
This firstly solves the problem of having to call the same process twice on a single diagram, and we have a clear view on the structure of the model and where to find all Processes and Activities.

To make things easier for ourselves I wrote some clever scripts that transform a BP(A) dragged on the diagram as Link to a local "instance" that calls the original BP(A) in its calledActivityRef. We also make sure to synchronize the composite diagram so we can easily click through to the detailed process diagram.

With an ever increasing model with about 20 BA's constantly modeling BPMN diagrams this approach is working very good for us now.

The synchronize script is open source and can be found on github: https://github.com/GeertBellekens/Enterprise-Architect-VBScript-Library/blob/master/Projects/Project%20A/Diagram%20Group/Synchronize.vbs

Geert

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6453
  • Karma: +55/-6
    • View Profile
Re: Nesting classes (and generalization)
« Reply #17 on: May 05, 2016, 08:52:51 am »
At this one client we extensively use BPMN, and we discovered through a lot of painly experience, trial and a lot of error that the best way for us was to never ever use processes or activities "as link" on a BPMN diagram, and to never ever nest actual processes or activities in other processes.
The way this works for us is that we have a library of Business Processes and Business Process Activities.
Each of those elements has their own BPMN diagram detailing the process.
Whenever we need to use an existing Activity or Business Process we use the tagged value calledActivityRef to reference the BP or BPA we are actually calling.
This firstly solves the problem of having to call the same process twice on a single diagram, and we have a clear view on the structure of the model and where to find all Processes and Activities.
This is an excellent suggestion, fitting with both EA usage and the BPMN metamodel. I have espoused this way of working several times on the forum.

With the ability to view tagged value references in the traceability window, and EA automatically displaying the called activity name, there seems very few reasons to want to do anything else.
« Last Edit: May 05, 2016, 08:55:05 am by Simon M »
Simon

support@sparxsystems.com

HarryPlotter

  • EA Novice
  • *
  • Posts: 18
  • Karma: +0/-0
    • View Profile
Re: Nesting classes (and generalization)
« Reply #18 on: May 05, 2016, 10:26:52 am »
Hello Geert and Simon.

Thanks for that. We consistently use callActivities in both Collaboration and Business Process diagrams for the same reason.

But it sounds like we need to re-think how we have set out packages in the project browser - 'grouping' processes by collaboration seem to be the poor practise and everything compounds from there.

Reckon we can solve that with an hour of 'drag and drop'. Everything callable is wrapped in a process or collaboration, so the identity/namespaces will all resolve.