Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - pneutam

Pages: [1]
1
Suggestions and Requests / Communication Diagram Improvements
« on: August 08, 2007, 03:33:15 pm »
A couple of small requests regarding communication diagrams. I nearly asked for multi-level numbering full-stop before I found it via the "Sequence Communication Numbers" dialog ;D

1. Add Promote/Demote Message Number to Context Menu
Currently message numbers can be promoted/demoted (e.g. 1.1. to 1.1.1) via the "Sequence Communication Numbers" dialog. It would be handy to have it available via the context menu of a message for ease of use and greater visibility.

2. Support Rotation of Message Arrow and Label
It would be handy to rotate the arrows and text of the messages to make the diagrams cleaner.

Thanks for the great product guys!

2
Suggestions and Requests / Re: Alias and Name Display
« on: October 21, 2004, 05:27:14 pm »
A voting mechanism might be useful.

Thomas, I think its okay to say that a feature isn't useful for you (just like a vote), but I think it's too hasty to conclude that it isn't useful to anyone else in 47 minutes!

Sure too many features can be implemented, but they still should be recorded if deemed appropriate (taking into account sheer numbers). A single, elegant feature may satisfy many small requests, though they seem unrelated.

For example, flexibility may be desired for class display, for communication, not style. The larger number of options could be handled by the interface, eg a hierarchical options dialog.

Well, that's my 2¢ 8)

3
Suggestions and Requests / Re: Alias and Name Display
« on: October 20, 2004, 05:22:29 pm »
If I didn't make it clear, I was suggesting an option to display this format (just like there is one now to either show the alias if available or just the name).

Mike, my interest in this feature is because we use aliases for tables within our code (not within the DBMS). A generalisation of my request is the display of project-relevant properties on class diagrams to aid communication, as the existing feature using the alias if defined, does. I'm not really fussed which one is in brackets, or indeed the format in general - I just bracketted the name under the assumption that you may often use the alias, but still may need to know the name.

Thomas, the WIBNIF acronym implies a low priority. I encourage our customers to give such suggestions as it helps us to see how our products are being used and how they can be improved. IMO, your response discourages such discussion and defeats the purpose of this forum. I would suggest you either clarify the objective of the request (as Mike has done) or, if you understand it but don't agree, state so simply, if at all. After all, if you don't like an option, you don't have to use it  ;)

Cheers

4
Suggestions and Requests / Alias and Name Display
« on: October 20, 2004, 01:08:40 am »
WIBNIF a class' alias and name could be displayed in class diagrams, rather than just the alias if defined. For example, {Alias}({Name})  could be used if an alias is defined, otherwise {Name}.

I am particularly interested in this for data modelling (as the alias and the name are useful to know at a glance).

5
General Board / PutDiagramImageToFile Formats
« on: May 29, 2003, 11:26:10 pm »
Below is the syntax for the PutDiagramImageToFile f'n:

PutDiagramImageToFile(
  VARIANT DiagramGUID,
  VARIANT Filename,
  long Type):BOOL

What are the valid formats and their corresponding Type values?

6
General Board / Re: Learning Automation
« on: August 07, 2003, 05:59:49 pm »
It's probably a darn site quicker to access the database directly also. I am generating Word documentation using EA automation, but it's a bit sluggish (as is most automation - not an EA fault). This is exacerbated by .Net interop (using C#).

I found that using the project interfaces xml functions and the Xmi export a lot quicker for reading EA info  than the normal autmation interface.

Ahh the need for speed 8)

Ben

7
General Board / Re: .Net Automation
« on: March 24, 2003, 03:07:43 pm »
Thanks for the info Steve,

I have gone ahead with using late binding in C#, building wrappers for the underlying EA objects. It's a little more verbose in C# than in VB.Net, but still works.

I might put up a sample when I'm done ;)

8
General Board / .Net Automation
« on: March 23, 2003, 10:03:49 pm »
Hi,

I've been trying to automate EA from C# and have struck a few problems.

I was hoping to use early binding from C#, but there is no EA type library in the VS.Net COM references dialog :(

Trying a lower-level method, running Tlbimp.exe on EA.exe (thought the type library might be embedded here), also fails with the error 'The input file ... is not a valid type library'.

So, is there a way to early bind to EA from C#?

If there is a .tlb file associated with the EA.exe that could be registered, I would love to get hold of it.

Cheers,
pneutam

9
Uml Process / Re: Looking for more indepth UML example
« on: August 07, 2003, 05:45:27 pm »
Hi Joyce,

There is an EA add-in called Zircom mentor that could help, although I haven't looked at it. There are also whitepapers on the sparx systems web site.

I found the following books invaluble for an introduction of UML and using it in the development process:

UML Distilled, Martin Fowler, ISBN 0-201-65783-X
- Describes UML in a 'use what you need' style.

Applying UML And Patterns, Craig Larman, ISBN 0-13-092569-1
- Also introduces the unified process in a 'use what you need' style.

Cheers,
Ben

10
Uml Process / Re: EA question
« on: July 29, 2003, 05:26:45 pm »
Hi Alex,

When you reverse engineer files in EA, it brings in the classes declared in those files, and sets the reference to parent classes, but does not create anything for them.

A quick way of manually specifying inheritance in EA is by creating an "Inherit" relationship between two classes on a diagram.

Cheers,
Ben

11
Uml Process / Re: Dependency stereotypes
« on: July 27, 2003, 06:07:14 pm »
Thanks for your response Javier,

What I was doing (and perhaps should have been more specific in the original post) was automatically generating design documents using EA and Automation, and wanted to specify a 'focus' class which would constitute the beginning of the document and a bunch of 'auxiliary' classes that would be included in the same document. I could have easily used my own stereotype, or tagged values etc., but wanted to see if there was commonly used method of describing the concept.

Somewhere in my reading I found the terminology of a 'focus' class and 'auxiliary' classes, the latter only existing to service the former. So, I decided to use an <<auxiliary>> stereotype, which can apply to either generealization, association or dependency relationship. The source of the relationships is implicitly a focus class, and the graph of auxiliary relationships are followed when generating the documentation.

Pros:
- Don't have to model package structure for this purpose. If I did it would result in one package (and therefore C# namespace) per focus class. I did start doing this but the design quickly became harder to understand.
- Communicates to others, at a glance, the reason for an auxiliary class' existence.

Cons:
- Uses up a stereotype. So far with my approach this is only a problem with <<realize>>, in which case I create another <<auxiliary>> dependency.
- Shows more stereotypes on diagrams. I put up with this because of the Pros.
- May become unmanageable for huge projects.

Other Notes:
- I am mostly following the specification perspective [UML Distilled], with some elements of an implementation perspective - this stereotype is one of those elements.
- As mentioned earlier, I am using associations for structural dependencies and dependencies for semantic dependencies.

Well, now I've thumped this out, perhaps this can help someone else approaching the same issue. :D

Cheers,
Pneutam

12
Uml Process / Dependency stereotypes
« on: June 16, 2003, 09:27:36 pm »
Say class A is heavily dependent on class B (A->B), and class C is lightly dependent on class B (C->B).

I wanted to indicate that the detailed design of class B should be done with A and thought that a stereotype on the (A->B) dependency would do the trick.

Does anyone have any suggestions as to the correctness of this approach and what stereotype to use?

Thanks for any suggestions,
Ben

Pages: [1]