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

Pages: [1]
1
Suggestions and Requests / use case scenario
« on: July 21, 2003, 04:19:24 am »
In most cases I know my use case well and I type in the steps of the scenario in sequence just hitting the 'save' button in between steps. Why is it that after that I have to manually correct the ordering of these usecase-steps? It seems that when I enter a new step it does not automatically appear under the selected (or last) one. I find it a bit of a hassle...

2
Uml Process / Re: Dependency between UseCases
« on: August 12, 2003, 05:04:01 am »
Hi Fintan,

Your suggestion seems very sensible. I'll work it out that way.

Thnx!

Huddie


3
Uml Process / Re: Dependency between UseCases
« on: August 08, 2003, 07:07:51 am »
Hi Fintan,

"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. "

Therefore an Activity Diagram does not seem appropriate to me.

I think that what's happening is this: a condition of usecase A (and therefore usecase A itself) is dependent on some artifact/outcome of usecase B. As I started this project I simply modelled a dependency from usecase A to B. That does not feel right to me because A is not dependent on B, it's dependent on a product of B.

I could define a custom stereotype for dependency to show this.

Or am I thinking data versus process too much?

Regards, Huddie

4
Uml Process / Re: Dependency between UseCases
« on: August 08, 2003, 12:03:06 am »
Javier,

You take a point of view I had not considered yet, I quite agree with your solution and it makes me understand the problem better.

I see now that what I'm actually trying to model is that the precondition of 'Check in with reservation' is met by 'Make reservation'.

Regards, Huddie

5
Uml Process / Dependency between UseCases
« on: August 07, 2003, 01:44:43 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?

a) I could show that the outcome of UC 'Make reservation' is an object 'Reservation' and that  Reservation is the input for UC 'Check in'.

b) Or I could draw a dependency link between Make reservation and Check in and give it a stereotype?

c) Ofcourse I could also make a higher level UseCase with the steps Make Reservation and Check In.

NB: It's perfectly clear that Check in has a pre-condition that a reservation has been made. This specifies the order in time of these Use Cases but this is not shown in the diagram...

What is best practice in your opinion?

Regards, Huddie

6
Uml Process / Re: Showing dependencies between packages
« on: August 07, 2003, 02:37:59 am »
Hi,

I show dependencies between the packages by creating a seperate diagram in the higherlevel package (the package containing the packages...)

Then I drag the packages from the browserview onto the diagram and model the dependencies using stereotypes like realise or implements.

When classes contained in these packages have a relation you won't see it on this diagram, but if you'd drag classes onto the diagram that have a relation it will automatically appear.

If you want to keep track of dependencies I'd advice you to study the matrix view (Project/Relationship Matrix in the menu)

As to your evaluation; we just switched from System Architect to Enterpris Architect and are very happy with the functionality, the support and the prise of the product. It has increased productivity enormously!

Regards, Huddie

7
Uml Process / Re: Proposed Product Oriented Nature of This Forum
« on: July 25, 2003, 04:09:04 am »
Hi Everyone,

I must say I like Phill's idea. Splitting threads by diagram (UseCase, Collaboration etc.) seems the best solution to me as there can be little doubt as to what's to be found where this way.

As Tom states so well, UML is a  language not a process, and I think this is very important discussion. I only recently joined the EA family and I was struck by the fact that the most interesting discussions here are often not so much about the UML as about "How should  we use this?"

I think that if you wanna know what a certain diagram is about there's plenty of material out there. But I find it very interesting to read how other people put their's to work. And specially in relation to EA. So in my opinion the process could proof to be of much more interest then the UML ( in this forum, at least! )

Take my case: this is my first project with EA and I want to generate Functional Specifications Document for the system I am designing. I want this document to show the user/client what he's gonna get at the end of the run. How do we do this?

So I can imagine that next to the threads for each kind of diagram (wich are EA independant) we also have threads for:
- Generating code
- Generating documentation / help
- Generation testscenario's

What do you guys think about this?

Regards,

Huddie


8
Uml Process / Organising Packages
« on: July 25, 2003, 05:51:10 am »
Hi Everybody,

I'd like some input on the following issue:

The EA project Browser is split up in Dynamic View, Deployment View, UseCase View, etc. A Package is always created inside these Views. Because my UseCases are in the UseCase View and my Classes are in the Logical View they can't be in the same package.

Some how this does not feel right. I want to split up the system I'm developing into functional subdivisions creating packages. I want to give these packages functional constraints and responsibillities/requirements, so that I know what i'm gonna do and where i'm gonna do it.  

Now I'm working on UseCases one moment and working on Classes the next and I find myself describing the same thing in different places.

What's wrong? Can anybody put me straight?

Regards,

Huddie

Pages: [1]