Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: gpc on November 01, 2007, 03:31:51 am

Title: avoiding duplication
Post by: gpc on November 01, 2007, 03:31:51 am
I have a project running under version control and to seperate the work, I have three packages. One is common and holds the classes and the other two contain a number of diagrams that two separate engineers will be working on.
The problem I can see is that each engineer will create an instance of the class for use in the diagrams, but later when the diagrams are put together, we will have two instances of each of the classes.
Not a big problem, but messy.
Any ideas how this can be avoided?
(the instances can't be placed in the common package as both engineers will need access at the same time)
Title: Re: avoiding duplication
Post by: «Midnight» on November 01, 2007, 05:37:38 am
First, please indulge me on the issue of "avoiding duplication" in this forum. Thanks for indicating in the other section that the duplicate of this post is a cross posting. However, most of us - at least most of us who regularly answer questions - read all the forum sections. Thus, please remove the other copy of this thread as soon as possible, in the hope that it doesn't live on.

Now, to your original issue.

Actually, while your problem is real, it can likely be avoided by some advance design. Get your engineers together - if you work in a distributed environment consider the EA function of providing a forum within each model - and think through the requirements for the work they will do. If you cannot identify (most if not all) the duplicate 'things' they will likely encounter, you probably haven't yet stated your problem clearly. This is a red flag that you should not yet drill down to the next level.

[Note: I've used "class" from here on; the logic applies to other elements, and to features.]

If you must move on without understanding the requirement, consider a paradigm where your engineers 'propose' new classes, and these are subject to review. Such classes will be placed in a shared package, with a temporary name. The class should be documented in sufficient detail to identify the reason why it was needed, as well as the function it must perform; these are different, if your engineers cannot distinguish them they should consider alternative designs. This temporary documentation does not have to meet corporate standards (that comes later), it needs only clarify why the class is being proposed.

The review can be done by a dedicated resource, some kind of quality circle, or whatever. It should not be done by a steering committee (at any level); this is a different function all together.

These 'proposed' classes will be subject to replacement, so until decisions are made the 'creators' must manage their use in such a way as to allow this to be done.

In some cases the review will show that the class is unique, and the class can be renamed to a meet your corporate standards. The documentation of the class will also be upgraded at this time. The original team need only take note of the new class name, EA should do pretty much all the rest. Later in the project other teams may adopt this class; if they need to extend the design that can be accomplished through normal methods and channels.

Sometimes the review will show a duplication, or expose where one is like to occur. Now the class definitions can be merged - one proposed class could be the 'winner' or all could be replaced with a new class, as befits the situation - to produce a clearly defined, named, and documented class.  The decision, as well as the identity of the new class, will then be communicated to all the proposing teams. All 'owners' of the proposed classes must make appropriate adjustments to their designs at that time.

Resource budgets should be adjusted when classes are proposed, to allow for the overhead of review, and the overhead of rework.

This last point is important! Resources are required to do this, and there is a real effect on project cost, timeline, and quality. You will likely want to include this in the presentation you are making to your management, client, or whoever (or whatever) spurred you on when you were not yet ready to move to the next level of work.

HTH, David
Title: Re: avoiding duplication
Post by: gpc on November 01, 2007, 01:31:07 pm
Hi David,
Thanks for the reply. Given your experience with the forum, I've accepted your comment that people read all forums and so have removed the cross-post.

Now. The "duplication" that I speak of is an element in the design - we will end up with say 100 diagrams, 50 of which reference one element and 50 reference another element with exactly the same name, both elements will be instances of a common class. In the posting to the automation forum, I added the comment that it didn't seem a trivial matter to replace one element in a diagram with another.
This is the problem.
The design, the work split and everything else is fine. My concern is using EA in such a way that we don't end up with duplicated instances or one engineer accidentally removing the others work.
Title: Re: avoiding duplication
Post by: peter.zrnko on November 01, 2007, 04:39:06 pm
I don't understand why it is a problem to have multiple instances of a class. I'm talking about objects (instance of a class is an object).
I think it's quite common to have multiple instances (objects) of a class even in the same diagram.

Maybe you have talked about two classes with the same name (two instances of a metaclass Class). If this is the case, I understand your problem.
In this case I suggest to work together on one package (packages) and use EA Security feature.
[size=10](Project can still be version controlled, if you need it. It's possible to use a shared drive for the Working copy of CVS repository.)[/size]
Title: Re: avoiding duplication
Post by: gpc on November 01, 2007, 04:53:39 pm
Hi Peter,
I think I can circumvent this problem with your answer to my other post. I know two instances (objects) aren't a problem, but I just don't want the project to get cluttered up with them. I would prefer to use a simple link to the class to avoid having them altogether, but this was also problematic (and not strictly correct uml).
If you have a dozen sequence diagrams, say, referencing the same class. Is it usual practice to use a simple link to that class, create an instance of the class and have all diagrams use that, or create a dozen instances of that class and have each diagram reference it's own instance?
All seem valid and maybe it's me being a neat freak, but having 6 reference one instance and 6 reference another just doesn't sit well :)
Title: Re: avoiding duplication
Post by: peter.zrnko on November 02, 2007, 02:50:57 am
Sorry, I don't know, what's usual for sequence diagrams since I've created only e few of them. Maybe somebody else can be of help for you.
Title: Re: avoiding duplication
Post by: JamesM on July 23, 2020, 06:58:10 pm
What you really need is to use a tool that will stop duplicates from ever being created.
Title: Re: avoiding duplication
Post by: Richard Freggi on July 23, 2020, 07:04:10 pm
Shouldn't it be possible to create a script that removes the option to drag an element from project browser to diagram as instance, forcing everything to be a link?
Title: Re: avoiding duplication
Post by: qwerty on July 23, 2020, 09:20:27 pm
I think that a proper training is what is missing here. An add-in can croak on instance creation. But then, what are you going to do when you really need an instance??

Title: Re: avoiding duplication
Post by: Modesto Vega on July 24, 2020, 06:12:05 pm
My 1st thought when I read this is that if you have engineers/architects working on the same elements, then you may be suffering from one or more of the following, non-mutually exclusive, problems:

Ultimately, I would never want engineers/architects stepping into each others toes.