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 - Tom_Andries

Pages: 1 [2]
Uml Process / Re: Proposed Product Oriented Nature of This Forum
« on: December 24, 2002, 08:50:29 pm »

RUP was only mentioned under the modeling header as indication that "work product" can be much more then just diagrams, the typical UML domain.

As for the rest of your reply, I couldn't agree more. In my practice as both methodologist and quality controller, most of the problems originate back to scoping and requirements.

Apart from it's affordable price (yeah, I'm a poor almost lonely consultant), EA's extensions beyond UML were just what convinced me to buy the product.

Oh, by the way: I've started my career ... back in those Clipper days. It's not about getting old, it's about seeing new horizons ...

I'll come back to the structure proposal itself, after some study & questions about the forementioned EA extensions. Just hope it's worth the while (meaning: people will have the selfdiscipline to respect a structure, still applying common sense).

To be continued ...


Uml Process / Re: Proposed Product Oriented Nature of This Forum
« on: December 24, 2002, 05:45:59 am »
Modeling :
You have to agree on what those work products are: will you take a UML-view, an EA-view, a RUP-view, ... ?
I'd take the list of official UML-diagrams and add specific diagrams (EA possibilities, profiles) to it.

UML is a modeling language, not a process. The fine line between the two is not always obvious. As problems are often more process than notation related, one cannot exclude the process part.

Workflow and Phase are orthogonal views on process. Applying both to structure a forum might be overkill. I'd choose one axe to structure a forum (e.g. Workflow).


Uml Process / Re: Action Language usage
« on: December 24, 2002, 05:59:45 am »

I think it was Sally Schlaer, and if I'm not deadly wrong, she passed away not more then a year or so ago. Which, for the world of software engineering is as great a loss as it was to her family. There's just too few of those: there aren't enough that get through to management positions to really prove better processes provide better results.

It stems from the real-time work of Schler(?) and Mellor but I find it useful for business process stuff.


Uml Process / Re: USE CASE Cookbook
« on: December 24, 2002, 05:51:39 am »
At the risk of repeating an already quoted reference, I recommend:

Writing Effective Use Cases by Alistair Cockburn (Paperback)

Uml Process / Re: Thesis and UML
« on: December 24, 2002, 08:52:52 pm »

You're wellcome ! Happy holidays too, if you're thesis doesn't prevent it. Although, given the subject it shouldn't be a drag.

Enjoy !


Uml Process / Re: Thesis and UML
« on: December 24, 2002, 05:25:44 am »
If I can be of any help, I'd gladly do so. Feel free to use whatever communication means seems most fit to your purposes and constraints.


Uml Process / Re: A first contribution on the PUP/EUP
« on: December 24, 2002, 05:52:57 am »
If I'm not mistaken, Scott Ambler uses the name EUP for Enterprise Unified Process.

I did register right away, given the criticality of EA for my current assignment and the excellent features of it in general.

However, I do join the question made previously: why was this necessary?

Didn't this forum do a good job already, and couldn't it be extended if need be? Or should Sparx gradually stop effort in this forum and move to the one of the user group instead?
I know I would if I where them, there's no point in doubling effort.

It does indeed increase the burden of where finding what information.


Automation Interface, Add-Ins and Tools / Objects: RTF doc problem
« on: September 07, 2005, 06:09:48 am »
I use quite some objects to demonstrate object flow in activity diagrams. Obviously, I'm not naming those objects, but just assign a classifier (a class) and select a state defined on that class to show the effect of activities on the object.

Somehow, in RTF it is totally impossible to list to what class an object belongs. I can merge state and object name at best, so some distinction shows up in the report (the state, that is, as I leave objecnames blank).
I wanna avoid overkill like aDocument:Document, just because RTF base classes and classifier do not return anything usefull.

Has anyone an idea how to report the class of an object in RTF?



Automation Interface, Add-Ins and Tools / Re: New Add-In
« on: September 07, 2005, 05:57:57 am »
Maybe because it's a Spanish add-in ? :)

Automation Interface, Add-Ins and Tools / Re: RTF Documentation Problem
« on: September 07, 2005, 05:52:26 am »
I completely subscribe to the proposed solution of creating separate packages.
Apart form correct semantics (grouping), it has the distinct advantage of letting you assign a template totally adapted to the package contents and even 'auto-generate" that doc.

If you wanna put it all together: use Word. I find myself using Word for correct headers anayway, and it takes next to no time.

Ive started using project issues only for things that come my way outside a modelling effort. Copies of mails, ideas of people passing by, ...

I'll move them to one or more modelelement as the project progresses.

Another disturbing fact is the lack of consistency: issues at project level and issues at element level do not bare the same characteristics.
As a result, any report will have to be constrainend to the common minimum.

I would expect any logical project to threat - or at least note - all issues the same way.

What do you use the tag for? Can reports be filtered thereon?

I either have to note the element somewhere in the element-specific issue, either repeat all element names on the RTF (issue or not). Both are overkill.

In EA, we find issues at the project level, the model level, the element level and ... graphically represented via a "custom" kind of note.

It's getting a bit crowded, certainly because reporting is far from obvious.
Project issues and system model issues seem to be the same.
I admit they are easy to RTF report via Model->Issues section.

Issues related to a model element can be created via:
a- the maintenance tab
b- the custom graphical "Issue" in the project browser dragged as child-element under the concerned element

While the first one is more complete, the second one is quicker during user assisted modeling sessions.

Reporting problems for each:
a- In the RTF generator, you'll need to print EACH element name - regardless whether it has issues or not -!!!
For the RTF issues section does not show name and (stereo)type of the related element.
b- there's no way to filter only these "issue" elements out, I guess.

Is there any solutions to either a or b ?



By the way
(1) Using EA with Visual Sourcesafe. Works great!
(2) RTF report generation, while sometimes reacting awkward, is a major step forward. Now I can really recommend my clients to use EA, as they get the output they want.

Pages: 1 [2]