Association problem!

[marcelo.bs]

Maybe this is not the right place to ask this...i also tried to search it..but the pages always expires!
The problem that everybody knows...but me.
The context is not this..im just talking about a generic thing
Look:

USE CASE DIAGRAM 1
ACTOR------UC_A<--------UCS_B-------->UCS_C
                  EXTEND       INCLUDE
USE CASE DIAGRAM 2
ACTOR------UC_B<--------UCS_A-------->UCS_C
                EXTEND       INCLUDE


But..when i close..the EA automatically AUTOCONNECT all UC  

Like UC_A<-->UC_B  and UC_A<-UC_C->UC_B

Im full of it!

Is there another way(without the hide thing) to make EA to NOT AUTO-ASSOCIATE use cases?

Im really really really thx for your time, and sorry for me being so..noob.
And sorry for the english.

[«Midnight»]

Marcelo,

First, please try to provide a more descriptive subject title for your post; others might be more tempted to open it.

Try right-clicking on one of the connectors. From the context menu choose Visibility. Choose the appropriate "Hide" option for your requirements.

You can do this for the entire diagram from the main menu. Choose Diagram | Visible Relations, or use the control-shift-I shortcut.

David

[marcelo.bs]

Hey david..you`re great  
but..the hide thing is something cool right? Maybe.
If you acess the use cases properties you will see the submenu named link. Acess this and the surprise!
The link is still there..but is hide on the diagram you marked! We`re currently working with TONS of diagrams..like 1k. And create new use cases to prevent this will make a hotel for big thinless pigs
This could damage future diagrams? Maybe.
The x question is..there a way to EA NOT make this..cause the project is garganteous and just using the hide connector tool would cause more headache(just to know WHERE the extends and includes exist on wich diagrams cause depends on wich context...who to hide and blabla)  
than i already have.
Thx anyway...the shortcut was something really cool dude!
Thx lot..and another tip to STOP THE AUTO HELL LINK?

[thomaskilian]

Marcello,
I don't get it with your AUTO-CONNECT

What EXACTLY are you doing there? Can you describe please step by step?

[«Midnight»]

Marcello,

You can hide connectors on all other diagrams, but this won't affect diagrams you create in future.

As to how to find connectors, look at the Relationship Matrix and Hierarchy window in the EA help. [For the hierarchy window you need to look up Dockable Windows in the index.]

David

Thomas: I think he's referring to what happens when elements are dropped onto new diagrams, and any connections are added by EA.

[marcelo.bs]

Thomas..make this

Open your EA, choose some package, add, add diagrams, use case diagram.
Right, now create an actor named testUser.
Then create 3 use cases, named A, B and C.
Associate the use case A with the actor. Use extend B to A. Last, use includes B to C.
Ok...now repeat the process...choose some package, add, add diagrams, use case diagram. Then Pick the testUser and the 3 use cases used last time.
Now..do this:
Associate the use case B with the actor. Use Extend A to B, and for last, use Includes C with A.
Close All. And then reload.

You will see what happen  

The context isnt this(obviously)..but we dont want to create new use cases just to make link.

Thx for the help david and thomas.
You guys are great

[thomaskilian]

Now I see what you mean. But the problem is not EA. It's probably the way you worked with some other UML tool

Let me explain what happens. Once you created Actor and UCs in the first step you have an association between Actor and UC A and two between UC B and A/C (extend/include). So far so good.

Now you take the SAME Actor and associate it with UC B. Now you have
Actor -> A
Actor -> B
A <-ext- B
B -inc-> C
The UC B in the first diagram is the SAME as in the 2nd one! And to me it does not make sense to connect the Actor also to the UC B (which might be because of your example). But what EA does is completely correct. When you add the Actor->B association it will make this relation appear in all diagrams. Simply because diagrams are always created dynamically. So what you are after is likely something like an option "when I create a new association in this very diagram then hide it in all other diagrams". You might opt for that but I guess such an option will add more confusion than clarity. Give it a try and put your request in the Suggestions board.

[marcelo.bs]

Yah..you know what i mean.
The problem is my context.
Imagine a big shop system. The user can add, search and delete products. Imagine also, that the products have acessories(like a mouse..that can have a promotional scroll). So our system also have a submenu that we can add, search and delete acessories. We can acess acessories by the main adding of products(think about hyperlink)
So we have The User associatin with the use case Search Product. And the use case add product is extens of search!
Finally, the use case search acessories is extend of the use case add product. Ok finished.
Now..we want to improve our surfing on the ea, and we would like to create a SPECIFIC use case with own scenaries and details of the acessories(also to help the programmers).
So here we go...pick the user(that is the same), and create a own diagram for acessories. Create uc search acessories and add acessories. But wait..at the menu of adding acessories we have to choose the product that is linked with it. So..here we go to the...WHAT THE HELL O__O
the search product...
So the UC search product will link the actor(cause is the same actor...then EA autoAssociate), the context is wrong and the search acessories will extend the search product...BUT ITS WRONG! In this case is the SEARCH PRODUCT THAt EXTENDS THE ACESSORIES  

We all hate this...IS THERE A HELL WAY TO KILL THIS PROCESS?

David and thomas thx a lot for your time.

[thomaskilian]

Maybe you should think about the way you are creating the UC. From my perspective it does not make sense to use include/extend in your scenario. Both are independent UC. The search goal is to bring product knowledge to the customer. The add is to actually enable selling of products. I strongly recommend to search the forum for extend/include and read the recommended books (I like Bittner et al.). To cite the latter: Do not think of UC Analysis but SYNTHESIS! It needs a while to get the point....

[marcelo.bs]

Yah..from this point of view you're completely right.
The point is the synthesis.
My boss said something like that. All i was doing was followin my own point of view, but i think we should REALLY evict the use of include/exclude cause with our context we are getting really melting-brain

[«Midnight»]

I hear you Marcelo,

There are some who suggest doing away with some or all of the connections between use cases. This usually boils down to either avoiding or reacting to some variation of your current frustration.

But your boss is correct; use cases are synthesis, not design. [After all, you've got the rest of UML to do this.] One weakness of UML is that it is difficult to 'attach' use case models to the rest of a system. UML 2.x has helped a lot in that area, and tools like EA have taken us much further.

It keeps boiling down to that same distinction though: synthesis versus design. Keep that in mind.

For example, do you - or your intended user community; put yourself in their position - think adding a product is a natural extension of searching through products? [I did not find what I was searching for, so I think I need to add one.] Or is searching for a product part of the process of adding one? [I think this product is nifty, and we should be selling it. I should make sure its not already in our catalog.] Try modeling both scenarios.

What you will notice is that the 'extends' relationship can go either way, depending on how you look at things. What you should pick up is what Thomas has been saying. The two use cases are separate and distinct; neither is part of the other.

There's another thing going on here as well. Use cases can describe a system at many levels of abstraction. You seem to be having a problem when you link general and detailed cases. You might want to rethink this a bit. It is perfectly valid to have a 'blue-sky' level, which does not drill down to lower levels. The purpose here is to frame the system (or part thereof). When you write lower level cases - which you do only until the design issues become exposed, then move on to other parts of the model - you should be paying attention to the overall scope of the lower level cases (if they exceed the boundaries of the higher level you have an alignment problem) and the level of abstraction (which should be fairly consistent across the use cases at each level).

HTH, David

[NB: I am trying really hard to be methodology agnostic here. That's why I am not suggesting or recommending any particular approach. That is for you and your organization to decide. There are several ways to go on this; there are evangelists who will quite correctly explain why each methodology is better than all the others. What you really need to concentrate on is what works in your environment.]

[BTW: Search the forum for many good suggestions, as well as some lessons learned.]

[marcelo.bs]

You`re becoming more like my father talkin like that.
Im REALLY grats to you.

Thx for all  

[«Midnight»]

But did any of it help?

[marcelo.bs]

Sure =)

Gonna abort everything and start over again "_"