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

Pages: 1 ... 17 18 [19] 20
Uml Process / Re: Activity vs. Use Case
« on: January 13, 2004, 09:22:36 am »

If a business process has no perceived value to the user of a system, then it's not worth modeling a use case.  That said, you may still want to model such a process with activity diagram(s) if you want to keep a complete model of the business for whatever reasons.

If a system will not support certain business processes, then some of the models for those processes may provide some context (what's in the system, what's not).

Uml Process / Re: Activity vs. Use Case
« on: January 13, 2004, 07:46:33 am »

It depends.  Sometimes it's worth modeling a process as a use case, sometimes not.

If a process provides a result that by itself is of value to a user of a system, then that process is worth modeling as a use case (and activity diagrams).

If a process provides a result that by itself is of no value to a user of a system, then it may not be worth modeling as a use case (but may still be worth modeling activity diagrams).

Before talking about a system and it's use cases, you may want to document and model business processes with activity diagrams and stereotyped activities.  From these business processes, you may find that only a subset are going to be supported by a some new system.

Uml Process / Re: Activity vs. Use Case
« on: January 12, 2004, 12:21:54 pm »

Take the banking system example again.

As far as a client of a bank is concerned, there are a series of steps involved in the use case  "Open an Account". These steps are essentially the user guide for "Open and Account".  [Steps to the use case "Open an Account"] is equivalent to [process of opening an account].

From the business perspective, there may be a whole bunch of steps that the banking system performs that are unknown to the client.  All these steps make up the business process of setting up a new account for a client.  If there is an internal system, a bank employee may be interested in the use case "Setup New Account", described by a series of steps.  Those steps describe the business process of setting up a new account.

The following may be more useful than my gibberish above:  "... the business process was written as a use case and documented with an activity diagram."  (p. 85, "Use Cases for Business Processes", Applying Use Cases, Second Edition by Schneider and Winters.)

Uml Process / Re: Activity vs. Use Case
« on: January 12, 2004, 05:26:17 am »
G'day g'day,

Use Cases are features provided by a system (software system, business system, etc.).

For example, your banking system (forget about computer systems ... think of the old days) provides you with some of the following features:
- open an account
- apply for a loan
- make a deposit
- make a withdrawal
- transfer funds

"Opening an account" involves a certain number of steps.  These steps can be modelled with an activity diagram.

Use cases do not appear in any order.  They are features of a system which you should be able to use individually and independently.  In the banking example, there is no flow from one use case to the other, but you can have pre-conditions: "you must have an account before you can make a loan".  But there is no flow or order between use cases.

I don't think a business process is an aggregation of use cases.  The aggregation of use cases is a system.

Uml Process / Re: Non Functional Requirement / Use Case
« on: January 14, 2004, 11:55:05 am »
G'day again,

I'd stick with the recommendation on using the realization link.

I guess the only question for your situation is whether it is better to link your use cases to the non-functional requirement, or link other types of elements to the non-functional requirement.

Uml Process / Re: Non Functional Requirement / Use Case
« on: January 14, 2004, 09:44:02 am »

I link all requirements, irregardless of the type, to elements via realization links.

What kind of requirement are you looking at?

Uml Process / Re: Test-driven Analysis & Design
« on: December 30, 2003, 04:45:50 am »
G'day g'day,

Thanks Jason.  Excellent piece of work.  Much appreciated.

Uml Process / Use of Components & Nodes, and Instances of
« on: November 05, 2003, 10:25:06 am »
G'day g'day,

Not sure when/where to use components and nodes, and instances of both.

Say I have a source component that compiles into an exe component that is meant to be deployed to a type of node.  When  created, these three things are initially classifiers.

Do I use these classifiers in all diagrams, or do I create and use instances?  When do I use instances vs classifiers and in what kind of diagrams?

If there are relationships between the classifiers, do I recreate these relationships between instances of these classifiers?

Thanks in advance.

Uml Process / Re: Proposed Product Oriented Nature of This Forum
« on: December 18, 2002, 06:00:05 am »
Would it be worth having separate threads for work products (artifacts), workflows and phases?  (Yes, I've got "The Unified Software Development Process" book in front of me...)

Something like:
Artifact - Use case diagram; Artifact - Use case narrative; etc.
Workflow - Requirements Capture; Workflow - Analysis; etc.
Phase - Inception; Phase - Elaboration; etc.

Is that a wee bit of overkill?  If so, then I think I'm with Phil's proposal.

I think an FAQ would be needed asap (would be nice if forum was cleaned-up as things get moved to an FAQ).

Uml Process / Re: The best way to write use cases?
« on: January 24, 2003, 04:46:57 am »

Symbols for use cases?  My knee-jerk vote would be for the ones Alistair C.o.c.k.b.u.r.n. used in "Writing Effective Use Cases".

Uml Process / Re: The best way to write use cases?
« on: January 22, 2003, 04:51:32 am »
G'day Mikkel,

I think this is one of those questions that leads to an "It depends..." answer.

Personally, I prefer the divide and conquer approach to anything.  Divide things up into as small a bite size as possible without getting to the point of losing value.

I've found that users and/or user representatives don't do too well with diagrams.  So very simple context diagrams for them, and a bigger focus on use cases (the text form) that merge includes/extends if it makes things easier.  I don't think most users like to have to bounce back and forth between documents to figure out the full picture.

For the technical crew who are used to diagrams, then break things down to the max.  That said, I think it's best to limit diagrams to between 7 and 12 objects to keep them clean and simple.  Better to have many diagrams focusing on different aspects/subjects/contexts/etc ... going from overall big picture diagrams to very detailed and specific diagrams.

Really, it all depends...

Uml Process / Re: Thesis and UML
« on: December 13, 2002, 04:25:02 am »
G'day Fred,

Would you consider setting up a project/thesis web site instead of e-mailing?

Uml Process / Re: A first contribution on the PUP/EUP
« on: December 10, 2002, 06:20:53 am »
G'day folks,

I know this is awfull early in the game to mention this, but I figure better now than never.

It would sure be nice to have, with the PUP, a PUP/EA tutorial of the same quality/caliber as Steve's EA tutorial at World-eIT.  May be too big of an effort, though.

Uml Process / Re: A first contribution on the PUP/EUP
« on: December 10, 2002, 05:08:46 am »

Great idea.  Don't know how much I can contribute, nor how much time I can give, but I'm in.

Pages: 1 ... 17 18 [19] 20