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

Pages: 1 ... 8 9 [10] 11
General Board / Re: ERWin -> EA ??
« on: July 16, 2002, 06:59:19 pm »
I have just been through a remodeling effort which involved tedious manual import from ERWin, so I strongly second Moreno's request. An import facility from Microsoft Repository should be considered (which, by the way, would permit imports from Visio as well).

Uml Process / Re: Activity Diagrams kill Use Case Diagram
« on: March 28, 2007, 04:59:08 pm »
fperedo: Now it turns out that you were talking about business process modeling! So I have no further comments.  

Anyway, I hope everyone enjoyed the discussion.



Uml Process / Re: Activity Diagrams kill Use Case Diagram
« on: March 27, 2007, 05:10:29 pm »
Hi all!

Let’s suppose you are at the stage of your project when you have not yet committed to architecture, but you have to create a model with the crucial functional requirements (the “what”, as some contribs. to this thread have pointed out). You would need, for example, to model some behavior to log into the system, and behavior for every one of the main menu items (lets say: Planning, Progress Reporting, Results, Follow-Up, tons of administrative stuff, so on). At this stage, you don’t know if you are going to develop through programming, buying packages, borrowing from legacy, prototyping, or whatever.
Inspired by something you just read in the EA Forum, you hop into your model-1947 flow chart vehicle, or its (not-so-different but more sophisto) activity diagram model. After about a month or so, you come out proudly with a humongous quantity of diamond-decision-studded diagrams. But (chucks!) after all that work, it is decided that Windows XP natural log-in is sufficient, and makes life easier for the users. Something similar happens to your beautiful model of the menu: some bum comes out with the news that the customer already has all the licensing to use Share Point, so the menu will not have to be programmed. And then... (“No! Not my flow model of Gantt-chart behavior! Please!”), but change is relentless, and it goes on, and on, and on.
Suppose, instead, that you have chosen to model this behavior with use cases: an Enter the System (or Log-in) use case, a Planning use case, and so on... What would be lost after deciding on architecture? Nothing, or close to nothing: use cases derive very well to whatever technical solution is given.
When you get to design, things get better still: your use case model has permitted you to identify reusable behavior that shortens the tons of administrative data entry interfaces to just a few use cases: you solve one, and you solve a whole family. You have a list of items you need to be able to display, update or delete? You do one use case called “Display list”, and either do a text description, a sequence diagram or even a GUI prototype, and re-use it every time you need it. It represents the same sequence of events, and you can parameterize your prototype until it solves a whole family of problems.
Sequence diagrams and sequence fragment reuse is solved at the use case level, through inheritance, use, extend, and so forth. Keep in mind also, that interaction diagrams work very well to model Services Oriented
Of course: there will be situations where you need an algorithmic, step by step, modeling, and activity diagrams are the best solution for them. UML is a huge tool box now, so you have lots of choices.
BTW, Jim: I’m sure you did some fine structured modeling. The point I was trying to make was not against what worked well with structured SW engineering models, but with what failed and created paralysis (and the same, or worse, happened with many OO efforts).



Uml Process / Re: Activity Diagrams kill Use Case Diagram
« on: March 26, 2007, 08:37:29 pm »

1. Petri-nets were invented in 1962 (around 15 years after flow charts), and no-matter how much mathematical formality they have, they still use Goldstine and Von Newmann's arc and node fundamentals.

2. Yes, I know the formalistic explanation given for activity diagrams in the UML 2.0 specification: but let's not miss the point. The question that started this thread was: Why use use-case diagrams, if you have activity diagrams? We must give a simple, straight-forward answer, and not make things more complicated.

3. Remember why the so called "structured methodologies" repelled people?: Because with all that rigoristic jargon, system analysis and design were not getting anywhere. It was, however, just absolutely de rigueur to pretend to have all these ultraprecise mathematical concepts underlying a modest model. Productiviy went down, and projects just went down the drain because of analysis-paralysis.  



Uml Process / Re: Activity Diagrams kill Use Case Diagram
« on: March 26, 2007, 03:54:07 pm »

Activity diagrams are direct descendants of the flow charts created in 1947 by Von Newmann and Goldstine for the ENIAC programmers. These charts are a great way of introducing you to algorithmic thinking, and oftentimes work well as communication vehicles for simple flows. (They are not so good when the flow gets somehow involved and convoluted.)

The reason many people like them is that they seem to "naturally" model a flow. However, if you try to model with them anything beyond a few simple flows they are (in the words of Fred Brooks in The Mythical Man-Month) "an obsolete newsance". The current world-wide consensus in systems modeling is that Brooks is 100% right on that one.

Use cases (as ugly and strange as they seem at first) are seven-league boots that enable you to model a whole modern, object-oriented, system's behaviour in a matter of minutes (of course, if you ommit detailing them).

You cannot model many OO features, or user interface behaviour, with flow charts or activiy diagrams. For example, it is quite hard to model a modern menu with an activiy diagram, but with use cases you can do it in a jiffy.

Use cases permit you to naturally distribute work in a project, estimate project size, specify pre- and post-conditions, re-use, inherit, specify scenarios with text or with sequence diagreams, and (besides many other features) help a great deal with your tests.

Of course, if they don't make sense to you, don't try to force them into your project, and use whatever you find most useful and adequate.

There's a lot of dogma going around UML these days, so be careful not to do things just because some important sounding manual says it ought-to be so.

Hope this helps,


Uml Process / Re: Testdriven development - example ?
« on: May 14, 2007, 04:21:20 pm »
Hi Bernd,

What I am about to describe is not precisely extremeProgramming, but it is the most natural way (that I see, at least) of aproximating it in EA:

Create a use case for every story you would create in extremeProg. (Since your model is extremeProg and not the Unified Process, don't worry about how to relate your use cases with <<extend>> or other relationships.) You can create packages and/or diagram to group your stories, in order to set priorities.

Write your stories in the Scenario tab of your use cases. In order to keep a single place of change, from that point on use the use cases (either in the model, or in a printout) instead of cards.

Display the diagram with the use case/stories you want, then View -> Testing (or Alt+3), and clic on the use case/story you want to design the test for. Right-click on one of the Test lines of the Test Cases dialog, then use the option to copy the scenario to the Unit (or Integration, System, etc.) test. Use the description tab to further describe the test (if needed), and the Input tab to specifiy your battery of inputs.

Of course, a class model would greatly help you to identify the fields you would use for your inputs, but you can model your classes (or not model them) as you prefer. IMHO, what is important is that the use cases, not the classes, are the containers of the stories, and the ones you are going to play out in your testing.

Hope it helps,


Uml Process / Re: What's the closest thing to DFDs in UML/EA?
« on: April 16, 2006, 07:45:26 pm »
Hi lipmanc:

I think that what you are looking for is activity diagrams. Be aware that they do have their differences with DFDs; for example, you should use instances of classes (a.k.a. "objects") instead of data stores, and your should use object flow connectors instead of the simple data flow arrows. However, you will find that element variety and syntax are much richer.

The reason why UML did not include DFDs is a long, long story. But, to put it very briefly (and to basically confirm what Kevin is saying): UML is object-oriented, so you need an OO "set of mind", which is very different from the structred modeling frame. However, don't let this intimidate you and, while you become accustomed to the OO world, simply "map" ERDs into class diagrams, and DFDs into activity diagrams.

Hope this helps,



1. Through interviews and JAD sessions, you can interactively create a business process model, a conceptual (domain) class model, a use case model, and whatever else you need for analysis (requirements, org charts, etc.). You can now generate a good-looking, professional,  business and/or systems analysis documentation. This is great, but you can also…
2. From the conceptual model and use cases (and requirements, in general), you can derive a database model. This will be your most natural departing point for forward engineering your model: you can now generate your CREATE TABLE…, PKs, FKs, constraints… from a model that is visible to the whole development team (and that is also neatly documented for your stakeholders). This is even better that having just a good analysis and requirement documentation, and it is also fairly straight-forward, but you can also…
3. Build a class model for your windows, web pages, and so forth. You can now create operations that logically interface with your database (just copy the attributes from your tables and/or conceptual model...)  Forward engineering will initially generate skeleton code for these classes, and (as you get more and more proficient) your will generate readily-executable/compilable code. For .NET, you can manually write whatever is necessary, and reverse-engineer it into your classes.
4. If you are bold (or reckless enough), you can customize the code generating templates for your own needs. There is a learning curve, of course; so you have to balance between immediate and long-term gains.



Hi lipmanc,

This is a very short answer, but I hope to address your main concern. In EA, you can forward engineer classes and interfaces. If you are planning to use it for the long run, I would definetely recommend to understand how the code generating templates work: search for info on these templates in EA Help, and then bravely experiment with the templates themselves (Settings -> Code generation templates). Don't worry if you make a mistake, because you can always revert to the default tamplate.



Uml Process / Re: Can we represent details of operation in UML?
« on: March 12, 2006, 06:52:42 pm »
Hi Folks,

Here's a contribution on this discussion:

Business rules are OK for models with a higher level of abstraction; that is to say, for business models, logical models (or, if you prefer, the "domain" or "conceptual" models), use case models, and so forth. The UML does have a way of including these in your diagrams (and nicely implemented by EA), with notes attached to the element with a note link. You can either type the business rule directly in the note, type it in the Notes section of your element, or (if you are modeling a class or an interface) include an operation, and type it in the operation's notes section. IMHO, the latter should be the prefered way, and you can display your business rule in the note with "Link this note to an element feature" (right click on the note link, choose the aforementioned option, choose "Operation" as feature type, and then choose the operation that has the note). You can use these notes for your algorithms, business rules, or whatever (just adhere to the KISS principle: Keep It Simple...).

An example of this would be an operation to insert a new instance into a class; say (in the case of a procedure for an RDBMs), sp_ins_entity. You can either model these operations as class operations, or as operations of an interface. These operations work very nicely in sequence diagrams; for instance, a user interface class that has the responsibility of entity maintenance calls sp_ins_entity through a sequence message. And, if your model has enough detail, you can specify the operation's parameters in the "Parameters" section of the operation. Now you can try the "Operations" button in the Message Properties of your sequence message.

OCL is included in the UML standard, so you can use it in high-ceremony projects that require strict adherence to standards (or the like). It does take time to learn it, though, because it has more than its share of hard-to-learn specifications, so it is not suited for projects with very tight schedules. As an alternative to OCL strictures, you can try an "OCL-light" approach, with simply sticking to the algebraic part of the language, which is quite intuitive and easy to learn.

Once you go into your physical (or, if you prefer, your implementation) model, you can copy your analysis classes (the ones in your logical or conceptual model) into your implementation classes, interfaces or tables, in the implementation diagrams of your model. If you have created your operations as stated above, they will be copied into the implementation classes and interfaces. You can then refine and elaborate on them until they contain fully-functional code, which should be placed in the "Behaviour" section of the operation. This section is not displayable through "Link this note to an element feature", but who on Earth would like the whole functional code displayed in a diagram?

The "Notes" sections of the operation will contain a short  description of the operation's responsibility, and an example on how to use it or invoke it ("Usage...").
The parameters section of the operation has the parameters, and so forth...

Now, you can display the "Notes" section of your operation in a diagram note with "Link this note to an element feature"; or (better still), generate your code with Ctrl + G (or "Generate DDL", as appropriate), and either see it in EA with Ctrl + E, or with the "View" button. In other words, the Operation's notes, behaviour, params (and other) sections are the NATURAL places for your code, either in their sketchy or in their fully functional versions. In OO and UML parlance, these are now a "Methods", and not just "Operations", but for modelling purposes it is allright to continue to refer to them as Operations.

I would like to point out that the UML does provide ways of spcifying Operations and Methods. Jim Rumbaugh's et al., The UML Reference Manual (1999) gives the full notation on on page 372. However, it is much easier and better to use EA's features than to blindly follow the specification.

I hope this works for you as well as it has worked for me.


Uml Process / Re: Dimensional modelling in UML with EA
« on: June 15, 2004, 02:20:08 pm »
Hi all,

The atomic level datawarehouse is a regular, vanilla-flavored third normal form database (albeit a consolidated, historical, and correcly grained one).

Mutidimensional data marts are modeled as stars, which are "quasi" third normal form data models (they would be third normal form if the dimensions did not contain so much redundant data).

Both atomic level DW and data marts can be modeled as you would any regular RBMS (relational) table diagram, and EA works great for generating the create tables and the indexes.

For futher reference on this topic see Ralph Kimball's book The Datawarehouse Toolkit.



Uml Process / Re: object identification
« on: June 08, 2004, 04:18:00 pm »

We've had some modest discussion on this topic in this forum:;action=display;num=1041954502;start=8#8

Not a full article on object identification, but I hope it helps.


Uml Process / Re: The best way to write use cases?
« on: January 22, 2003, 04:53:03 pm »
Hi all,

Just want to contribute another two --well, really four-- bits:

1. Ilja's point on reusability goes to the heart of the matter when dealing with <<include>>, because the most iportant reason to do an <<include>> is to have a sequence of events that can be reused by several use cases. Example: "update budget" or "update GL" use cases can be quite useful to <<include>> in order to represent interfaces to accounting (and they can even be reused among different projects and applications).

2. <<extend>> is a different matter, because it is used for conditional or exceptional event sequences (user choices, error messages, system not available, and so forth...). These are sometimes reusable (the user chooses a certain menu item), or not (an error message in a particular window or screen).

3. Your use case diagrams are getting too convoluted, and are not adequate for discussions with users? I suggest doing process diagrams (which are extensions of activity diagrams), as the best way to explain to users what you are trying to depict. Yes, use case analysis is very much object oriented, and oftentimes it is not as user-friendly as we wish it was.

4. You have a ton of scenarios, and they horribly complicate a diagram or a use case? I suggest creating a special diagram where the scenarios are represented as individual use cases, linked with a generalization relationship towards the most general use case (the basic path, that is). This basic path is practically the only one you will use in your other use case diagrams. This is a very strict logical approach: the basic path should contain only the most general sequence of events.

If you find that something works for your project and saves a lot of time, please send my above comments to the "formal, but not that useful" dept.

Jaime Gonzalez

Uml Process / Re: Action Language usage
« on: December 15, 2002, 08:23:12 pm »
On Dec. 11 you described the following scenario:

"There will be several truck-loads from that paddock of peas and each weigh-bridge transaction is called an 'intake'. For the purposes of my scope, an intake is boring. it is created (and may be deleted if it was in error).

"If I am using an action language for detailed specification (and hopefully generation), do people think the best place to document the first intake generating the paddock's harvesting-in-progress signal would be..."

Even if I'm not familiar with what an action language is (and did not find a description of it by searching the OMG's web page), here's my two cents worth on your question:

The most important thing to model is the event of the truck arriving at the weight-bridge. This is the confirmation of the fact that the peas have begun the state transition of "harvesting in progress".

When the last truck has arrived (is there a way to signal this?), "harvesting in progress" ends, which happens while the next state (¿selection? ¿prepacking?) is process.

The challenge here is to handle embedded states: while harvesting is in progress, instances of the the pea class (pea_truckload, or something similar) are already undergoing other state transitions.

The way I would model it is as a sequence diagram with states (see Rumbaugh et al.: The Unified Modeling Language Reference Manual, p. 426, in "13. Encyclopedia of Terms", under "sequence diagram". See also my posting for this in the EA forum, two or three months ago).

Trucks keep arriving at the weight bridge, modeled as a message with *iteration, that causes the instance to undergo a state transition, and the while loop ends the last truck arrives.

   Place an embeded messsage in between trucks arriving at the bridge, and the return signal. This embeded message touches off next state transition, and model it also as an *iteration

The return of the "trucks arriving" message closes the iteration loop

Of course, this is just a suggestion, and there are many other ways of modeling this: state machines and collaboration diagrams are two clear possiblities; but (correct me if I'm wrong) I don't think that the action language actually plays such an important part in the modeling of these transitions.

Hope this helps,

Jaime Gonzalez

Uml Process / Re: Action Language usage
« on: December 12, 2002, 07:06:56 am »
Hi Chris,

Yes: yours is certainly the type of question that belongs in this forum. But let me ask you (and excuse my ignorance): What is an "action language"? Is is something like the Object Constraint Language (OCL) thas was used in UML's metamodel?


Pages: 1 ... 8 9 [10] 11