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

Pages: 1 2 [3]
General Board / Import & Export XML
« on: December 19, 2002, 10:07:24 am »
I am getting very frustrated with the import / export facility in EA.  I export a small simple use case view package to an xml file and then I open a new file and try to import the same xml file.  EA gives me a message saying "Error  Code=0xc00ce014  Source = Line 76; char = 31   Error description = Element content is invalid according to the DTD/Schema.  Expecting #PCDATA,XMI.reference". >:(

This combined with the fact that it does not automatically convert collaboration diagrams to sequence diagrams, or keep the links between objects when placed on a new diagram makes this a completely useless product.

I thought that I had found the 'holy grail' - only to find that EA does not live up to its promises.

If anyone can provide a remedy for these problems I would be most grateful.



General Board / Re: convert EA to Rose? (was Visio)
« on: December 19, 2002, 04:43:16 am »

Could anyone tell me how to import and export xml / xmi files to/from Rose Modeller edition?  I can export the diagram from EA, but Rose will only allow me to import a *.ptl file? :'(

Many thanks,


Uml Process / Re: Use Case Arrows - what to use?
« on: October 02, 2003, 12:33:54 am »
Hi Ingrid / Laurent,

The correct way to show the connection between the Actor and the Use Case is to use the Association line.  The arrow should be pointing to the Use Case, i.e. from Actor to Use Case.

If you double click the association (or right click and choose Association Properties), the Association Properties dialog pops up.  In the 'Direction' combobox (originally "Unspecified") select "Source -> Destination".  This will put an arrow on the Association.

Ingrid :
<<extends>> and <<include>> are the only arrows that should be between Use Cases.  In your diagram you should not display any links where your generalisation links are.

Instead you should have association links (with arrows pointing to Use Cases) from the actors to each Use Case.  This is so we know who can trigger each use case.  The Use Case Model does NOT allow you to show the order that Use Cases are executed.  If you need to show this you will have to use Activity diagrams.

Hope this helps,


Uml Process / Re: Dependency between UseCases
« on: August 12, 2003, 03:45:09 am »
"An activity diagram is a special case of a state diagram in which all (or at least most) of the states are action or sub activity states and in which all (or at least most) of the transitions are triggered by completion of the actions or sub activities in the source states. "

I think this quote trivialises the Activity diagram too much.  An activity diagram can show a process(e.g. a use case), who inititates the process, and the order in which processes take place.  E.g.  Make booking -> Reserve room -> Check In.  This is the order that you are trying to show.

Remember the use case diagram does not show everything.  The use case diagram shows you the specific sets of requirements (functionality) and who initiates each piece of functionality.

As you indicate - do you need to think about data at all?  The dependency is that "check-in" relies on "make booking".  Even so, this should not be shown in a use case diagram.  You can diagram the dependency in an activity diagram as :  Make booking -> Check In.

When writing out the use case for Check In, I would include as a pre-requisite that the Make booking use case must have been executed.



Uml Process / Re: Dependency between UseCases
« on: August 08, 2003, 05:17:09 am »
Hi everybody,

I want to show how one UseCase is dependent on another in the overall process.

For example; a guest will normally make a reservation first and check in later. How do I show this on my diagram?

What is best practice in your opinion?

Regards, Huddie

Hi Huddie,

The one thing that Use Cases Diagrams do NOT do is show order.

Rather than messing up your use case diagram, I would use an Activity diagram to show the order.

I wanted to show a diagram of how this looks, but cannot get a picture without having a web site set up :'(



Uml Process / Re: Use Case Diagram question
« on: July 31, 2003, 05:51:03 am »
if the actor gets information back from the use case, then i will need arrows on each side?

If the use case displays information on a computer screen then I would not consider this as the actor physically receiving information back from the system, and would leave the arrow pointing from the actor to the use case.

If however the system sends an email to an actor this I would consider the actor receiving information back from the use case.

Rather than draw arrow heads on each side of the association line - the standard is that for bi-directional communication a line with NO arrow heads is used.  This is what your diagram suggests.

The use case diagramm is for our own use. The application being developed is for our own use.

Whatever works for you is fine, as long as whoever is reading the diagram can understand it.  If an application you are developing gets more complicated, all the additional <<include>> lines may end up confusing the diagram, making it harder to read.



Uml Process / Re: Use Case Diagram question
« on: July 31, 2003, 03:43:08 am »
If the newer version is still not correct, you can also edit the new model at

Hi Alex,

Here are some of the changes that I would make (does not necessarily mean that there is something wrong with what you have done)
(i) Put arrows on associations from the actors to the use cases.  This implies that the actor starts the use case, but there is no transfer from the use case back to the actor.

(ii)  Although it is correct UML to use <<include>> to link the use cases for "Save user data" and "Load user data".  I do not see that these Use Cases add anything to the diagram.  These use cases will end up as a single line the the Use Case text.  I would tend to leave them out if they do not add anything to the diagram.  If you need to emphasise which use cases save to and load from the database you could List these in a Note on the diagram instead.  If the purpose of the diagram is to practise UML and the correct use of <<include>> relationships, then it is correct to leave them in.  If the purpose is to show this diagram to a customer as the requirements of their system then it may be overkill.

(iii)  As a rule I tend to avoid using the name "User" as an actor if I can - and try to use a more specific name.  Again if this is an exercise, then it is OK.  For a customer's system use a name appropriate to what they do (Accountant, Secretary, etc.)

Hope this is useful,


Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: April 17, 2003, 02:51:43 am »
Just to add my 2.54 c (Euro cents that is),

Paul :  What I think people are saying is that your "top level use cases" should in fact be packages.  E.g. you will have an association between the Site Administrator actor and a package called 'Administer Site'.  Within this package are all the use cases that the Site Administrator is associated with.  Ditto for Content editor & 'Manage Content' package.

Where I would use relationships between use cases is in the case that TJerk mentions - overlapping functionality, although I would use it rather for overlapping requirements.  Where there is a requirement which is used in more than one use case, I would extract that requirement into its own use case and create an <<include>> relationship between them.



Uml Process / Re: The best way to write use cases?
« on: January 27, 2003, 02:37:15 am »
What about when the user interface design is part of the project?

How do you avoid making design decisions in the use cases, when scenarios often sound like "step 117: User clicks the GO button".

Hi Mikkel,

I would NEVER write a scenario like the above which has - as you point out - a UI design decision already made.   I would reword this as something a lot more specific (rather then general).  I.E. "Step 117: Bank Clerk chooses to run the account reversal transaction".  This step will most probably be coded as the user clicking a GO button, but the use case does not have to describe that.

Remember the point of the use case is to show that the system does something of use to the Actor.  Choosing to run a useful function of the system is a goal of the Actor - clicking a button labelled 'GO' is not IMHO.

Once the use cases have been written the UI design and the Analysis & Design (for code) can be run in parallel - both using the same use cases as their launching points.  In fact test cases can be started as well.  UI design will focus on screens and navigation between them.  Analysis & Design will focus on objects and classes and the relationships between classes.

In Summary :
I avoid the word 'user' in use case texts and always specify the actor name.

I never use "the <<actor name>> clicks OK button", instead I write "<<Actor name>> chooses <<particular function of system>>.

Use Cases should be design agnostic, UI agnostic and contain all data elements required.

Once a use case like this has been written and approved, 3 different teams can start building based on the use case.  
1 - Analysis & Design.
2 - UI Design
3 - Test cases
(Perhaps 4 - User documentation?)

Each of these 3 are likely to discover items which should have been included in the use cases, so running these in parallel will solidify the use case in the least amount of time.



Uml Process / Re: Use Case Alternatives
« on: February 20, 2003, 04:40:55 am »

1) Why go through all those text details for scenarios, when you are going to model them in sequence diagrams (or, if you wish, in activity diagrams or state machines)?

2)How much detail should go into interaction diagrams?
In theory, a solid model should go down to the CRUD level (create, read, update, delete data items). In practice, however, you would get yourself bogged down if you try that level of detail, and your project will become prohibitively expensive, or worse...

Hi Jaime,

In response to your 2 questions above, the following is the way that I view use cases and so how I utilise them :
1)  My use cases capture the *requirements* of my final system so -
(i)  {Customer sees the Use Cases}
I can show my customer the FULL requirements of the system (including all scenarios).  When they sign off on these requirements I know that they can not come back and say "Hey I never sanctioned that!".

The customer has confidence that the system will cover every eventuality.

CRUD operations usually appear as one of C,R,U,D as the Basic Flow and the others as Alternative Flows (alternate scenarios).  These Alternative Flows are usually uncomplicated to write as variations of the Basic Flow.  Therefore it does not take much effort to write them in text version.

If CRUD operations need to be split into separate use cases then the fact that they are so different means that the effort in writing a new use case will be worth it in the end.

(ii) {Test Cases derived from Use Cases}
All of my test cases are derived from the Use Cases (with maybe some information from the Supplementary Specification).  If I write out all scenarios - then I know that my test cases will give 100% coverage of the system.

Not writing out all scenarios means that my test writers have to "discover" the unwritten scenarios that the Modellers will develop.  This could lead to functionality which is not tested for, or new tests for functionality which is not included in the model / code.

(iii) {Modellers derive UML diagrams from Use Cases}
Experienced modellers will probably create CRUD UML diagrams automatically.  If you have an inexperienced modeller, having ALL requirements specified in the Use Case means that there is no possibility of them 'missing' the unspecified scenario.

(iv) {User Documentation derived from Use Cases}
Most often when a user most needs to read the documentation is when they are doing something which is outside how they 'normally' use the system, i.e. alternative scenarios.  If these alternative scenarios are not written in the Use Case, the tech writer will have to "discover" all of these to document them for the user.

Essentially you could rely on the "Head Knowledge" of experienced Test Writers, Modellers, Tech Writers for items (ii), (iii) and (iv) - but if one of these gets hit by a bus in the morning (all 3?) it could be difficult to retrieve this information.

If you are using EA to generate code then the more detail you have in your UML diagrams the more complete your generated code will be.

If you are not using your UML diagrams to generate code then only put as much information into the diagrams as is required to communicate the idea.



Uml Process / Re: What looks like an Industry trend?
« on: January 15, 2003, 08:53:49 am »
Hi Al,

We bought licences for a *few* Rose licences, and I was very dismayed at the introduction of so many products which seem to compete.  We develop in Java/J2EE, asp and VB.  Someone like myself could end up coding in all three.  Which of the new products should I choose - Rational XDE for Java?, Rational XDE for .Net? (We are considering moving asp coding to this platform).  Do I need 2 licences locked down to my PC even though I can only use one of them at once?

The way I see it is that a standalone tool that allows me to generate code in Java or VB is the ideal tool.  The programming IDE should be able to pick up changes made to a class file and load them up itself.

Just my opinion,


Pages: 1 2 [3]