Messages

1

Suggestions and Requests / Diagram Refactorings (Extract)

« on: March 23, 2007, 08:30:20 am »

Hi!
Nowdays is very common to have refactoring functionality in the IDE, a refactoring I find particularly useful is "extract method", (http://www.refactoring.com/catalog/extractMethod.html)

I would love to have similar functionality in Activity Diagrams or State Diagrams, so that I could select a subset of the elements of the diagram, and click on "extract diagram", the EA would replace the elements of a the actitiy diagram with a composite element and automatically create a composite element with an internal activity diagram with all the elements that were previously in the main diagram.

Mmmm... it could also be used in Sequence & Communication diagrams!!! (And we could also have an "inline diagram" that could do the opposite thing... )

Other refactorings that would be nice to have could be:
-Extract Superclass (for Class Diagram)
-Extract Interface (for Class Diagram)
- Pull Up Field (for Class Diagram)
- Pull Up Method (for Class Diagram)
- Extract Class (for Class Diagram)

In fact it would be great if EA could have "diagram equivalents" for all the refactorings in http://www.refactoring.com/catalog/index.html, that would eliminate a lot of "grunt work"...

What do you think?  

2

Suggestions and Requests / Real Undo (Transactions / Recycle Bin)

« on: March 23, 2007, 08:47:37 am »

Hi!
I believe that EA's current undo capabilities are very limited, why?
well right now, If by accident I delete anything in the project view... I have lost it forever, and that has happened more often to me, (and my friends) than one may thing (In fact, I failed to introduce EA to a friend precisely because the first time he tried to use it, he spent several hours trying to make lots of related activity diagrams... then he made a mistake.. and deleted hours of work... (after that he refused to use EA ever again)
I believe there are different ways to prevent this:

1) The EA files are basically, databases (I can open them with MS Access) so, wouldn't it be nice if after opening an EA file everything could be inside a transaction? (And the transaction would only commit if the "Save" button is clicked (that way I can make lots of mistakes on project view, and easily revert to the last saved version).
2) Provide a "Recycle Bin" when anything is deleted, instead of really disappearing it could go to a "recycle bin" from where it can be manually retrieved... of course changes in the project structure could make such a retrieval inconsistent... for that case, EA should allow to restore deleted elements "exactly as they were before deleting" or "as detached copies" that can be placed in an independent context.
3) Provide full undo capabilities for every action that can be done in EA the same way MS-Word does it, by providing almost unlimited undo levels (I guess this is the hard way of doing it)

What do you think? Are there any plans to address this issues?

3

Suggestions and Requests / Name Syncronization

« on: March 23, 2007, 08:01:34 am »

Hi!
I would like to have the hability to sync the names of 2 differnt entities, so that if I change the name of one of them, the other changes too... some kind of customizable "rename refactoring" on which can say "all this elements share the name X" and if I change the name of one of them, the name of all of them changes:
It would be really useful to keep Use Case Diagrams / Activity Diagrams in sync (I have realized that a lot of times, theres a one to one same name realtionship between Use Cases and Activity Nodes)
What do you think?

4

General Board / Hierarchy & Matrix Views fail for classifier

« on: March 23, 2007, 07:47:40 am »

Hi!
If I relate a Partition, (or any other object) with a class by "setting its classifier", AFAIK:
-I can not see that relationship in the Hierarchy View  
-I can not  see that relationship in the Matrix View
-I can not show that relationship in the UML or RTF documentation

Why is that?

5

Uml Process / Re: Activity Diagrams kill Use Case Diagram

« on: March 28, 2007, 05:24:54 am »

Hi! (this gets even more interesting)
1) jaimeglz, I somehow fail to see why it is worse to come after a month or so with activity diagrams... than coming with use case diagrams... (I think here the problem is that you took a lot of time to model, and didn't worry a lot about feedback). Of course you can describe a big system with a few simple high level use cases..., but... why an activity digram can't be high level too? After all, this diagrams http://www.sparxsystems.com.au/EAUserGuide/index.html?businessmodelling.htm are some kind of activity diagrams.. aren't they? and IMHO they are high level, flow diagrams, and more expressive than Use Cases.. or not?

2) sargasso... sorry... I am not sure if I understood your example... but I am guessing is about high level (kind of house), and low level (wiring, plumbing) description of the solution... two questions... why an activity diagram cant be high level (as in http://www.sparxsystems.com.au/EAUserGuide/index.html?businessmodelling.htm )and... two, after you put lots of bricks together, it will start looking (or not) like a house, and AFAIK there are specific rules in architecture on how to put every piece so that the end result is an structure with a good foundation... ¿where are the rules to build the foundation for my use case diagrams? (the sequence diagrams that describes a use case doesn't have a way to represent the "extends" or "inherits" relationship of that use cases with another use case... or does it?

I agree use case diagrams are nice for communication, to give an overview about how the system is going to be built.. but, as you start filling the gaps, you realize that there a just no rules to link you bricks with your blueprint... I mean, you activity/sequence/communication diagrams with your use case diagrams...  and they seem to be written in 2 completely different and unconnected languages...

A little off topic note: some days I really miss yourdon data flow diagrams... .. they somewhat remind me of iconix robustness diagrams...  

6

Uml Process / Re: Activity Diagrams kill Use Case Diagram

« on: March 27, 2007, 08:25:48 am »

Hi!
Thanks of all the answers (this discussion is getting interesting)
First I would like to clarify somethings about my initial post... i do like (and think is good an important) to have use cases describing the behavior of a system.
The thing I don't like is the use cases "diagram".
A funny thing about use case diagrams is... that they don't describe how a use case works... instead of that they describe "the list of use cases you have". So... use case diagrams are... for describing the internal behavior of a system... at "relationships between use cases level"

But... when someone says "I am going to describe one use case" he is not going to use a use case diagram (strange thing don't you think?), to describe the behavior inside that one use case he is going to use communication, or sequence, or activity diagrams, or plain text...

So.. we have 2 kinds of diagrams (domain specific languages?): use case diagrams for relationships between use cases, and "whatever you want" for  the "inner workings" of each use case.

But... as we all know, if there are relationships between use cases, is because some of them "extend" or "include" or "inherit" or "invoke" from other use cases...  and that happens because their "inner workings".
So, you may realize that 5 use cases include a "common abstract use case" because after you modeled those 5 use cases, you realized that a good part of their internal description was pretty much the same, and you decided to "extract to" the common functionality.

The fundamental question here is: "if 2 use cases are somehow related at the use case diagram level... how is that relationship represented inside each one of those 2 use cases" What is the official equivalent, in communication, activity or sequence diagrams for an "include" relationship? and for a "extends" relationship? and for inheritance? I believe there is none... so, our use case diagrams have no foundation (the internal descriptions inside use cases just don't justify the existence of the external relationships represented at the use case diagram level).

To put it more clearly... imagine that you have a activity or sequence diagram, that describes 1 use case... and that you could select a part of that diagrams, right click and select "extract to <<included>> use case", and have all the selected elements automatically extracted, moved inside a separated use case, have an <<include>> relationship create between the old use case and the recently extracted, and represent that <<include>> relationship inside the sequence or activity diagram... how?

(I know refactoring for UML might be too much to ask for, and I don't expect to see such functionality in the near future, but, before being able to do it automatically, UML should have at least enough expressivity to do it "by hand", don't you think? is there a way to do it? or a just should live thinking that use case diagrams should be done even if they have no foundation?)

I think activity diagrams kill use case diagrams, because there is a known and established way to "nest" activity diagrams using composite activities, and ways to call activities in one activity diagrams from another... it is always the same language (you just make it less and less abstract as you get closer to implementation details, but you are always "talking" in activity language, but, with use cases, things get disrupted because you can't call an use case "ball" form inside an activity diagram (or a sequence diagram, or an communication diagram)... or can you?)

7

Uml Process / Re: Activity Diagrams kill Use Case Diagram

« on: March 26, 2007, 08:57:32 am »

Hi!
Thanks for your answers.
I also believed that UC diagrams were more abstract, but... a high level activity diagram is "as abstract" as any UC diagram (and I really can't see any disadvantage of using it that way)

If use cases are like folders with a "what name" on which we store an activity diagram (explaining "how")... the problem is that the steps of the "how" aren't (can't be) always and the lowest level (binary code)... so the steps in the "how" are "whats", and each "what" will have and internal "how" described in other "whats":

List of What
How for each What
The How is a List of What of lower level of abstraction
How for each What...

So, if a particular "activity" (or use cases) is a what or a how.. it depends on the particular level of abstraction you are currently thinking... but the artificial separation between UC diagrams (what) and Activitiy diagrams (how) doesn't seem help a lot with this...

I think the problem of making it easier to solve complex problem using a "fractal" of hows & whats, was structured programming... and activity diagrams match structured programming a lot better than UC diagrams... and UC diagrams arent really that much object oriented (they are very procedural to me)... so... Am I really wrong to think that the whats and the hows are really just the same thing (depending on you level of abstaction)? (and that UC diagrams... are just an unnatural construct?)

8

Uml Process / Activity Diagrams kill Use Case Diagram

« on: March 23, 2007, 07:52:14 am »

Hi!
This is just a philosophical question but... I have just realized.. anything that can be represented in an Use Case diagram can be represented in an Activity Diagram (and Activity Diagrams have IMHO lots of advantages over Use Case Diagrams). Since every use case can be represented as a step in an activity diagram...
Why should I make Use Case Diagrams? (They seem redundant to me)
Note that I think that writing (or diagramming) "use cases" isa good idea, but why should I diagram them using a use case diagram, if an activity diagram is far more expressive...?

9

Uml Process / Re: Rubustness Analysis for Bussiness Modeling

« on: March 27, 2007, 08:49:17 am »

Hi!
Thanks for you answers, but I believe those resources are more for "describing the new software solution" or "describe the current software solution" and i would like to find out more about: "describing the current softwareless solution"... any other recommendations?

10

Uml Process / Rubustness Analysis for Bussiness Modeling

« on: March 23, 2007, 07:56:55 am »

Hi!
I want to use Rubustness Analysis for "non-software systems" (business modeling), the idea is to:

1) Describe the current (softwareless) situation (in UML)
2) Describe the problems of the current situation (in UML)
3) Describe the solution (new situation) (in UML)

For 3) I plan to use ICONIX,... and I would like to use ICONIX and robusness diagrams to describe the current situation (a paper / human (no computers) based system) and I can't find any examples of books on how to do that... any suggestions?