In addition to Precondition, Some UML book also mention about Postcondition. It make me a little bit confusion about how to use Postcondition. Can you give me some example about PostCondition

Thank in advance.

Your suggestion of the trigger is:
* Existing customer calls to request an appointment.
* Actor identifies that a customer is due for their next appointment.
I wonder whether we should include those events in the use-case specification. To develop our software, all we need to know is that sometimes the actor will use our Scheduling use-case. That’s enough. We needn’t worry and should not worry about the real-life situation that lead the actor to intiate the use-case. The reason is simple, we cannot/ hardly imagine all of the real-life situations. Maybe, the customer call officer (by phone)/ email or visit face-to-face the officer. Maybe, the technician request a visit (on behalf of the customer…).
Sometimes, some types of trigger are important (eg. a stimulous from sensor, a package from network, receive a message/email….). However, real-life situation trigger like your use-case seems to be not necessary. How about your idea?

I read some UML book. When talking about extension of use-case, the authors usually mention about 2 types of relationship between use-case: include and extend. Use-case extension is good for re-use (save some time for documenting the use-case specification). However, I wonder why should we make a difference between include & extend relationship? It is so meticulous and why don’t we focus on it in design phase in some diagram like activity diagram or sequence diagram?

Hope to hear from you all

Hai Ly-Hoang

I’ve been writing usecases for a number of years… I have no strong preference for using either extensions or alternative flows *from a writing point of view*. In my experience, using extensions (Rather than alternative flows) makes the usecases easier to read for people not familiar with the UC technique. That, for me, is sufficient reason to use extensions.

Just my five cents

P.S. I really like the book by Cockburn. It is one of the most complete discussions on the topic of usecases so perhaps my comment is slightly biased..

You make really good points about extensions versus alternates. I’ve always used alternates in the past, but Cockburn suggests extensions. I think you’ve convinced me that alternates are better. What do other folks think about alternates versus extensions?

As to preconditions for subordinate use cases – I think the power of subordinate use cases comes from encapsulation and reuse. With that approach in mind, a subordinate use case is just another use case that happens to be reused. And therefore should have preconditions – allowing it to be reused from within multiple other use cases.

Comment 1: the first precondition is superfluous, as it is already stated that the actor of this Use Case is the office worker, whose work it is to schedule exterminator visits to customers.
This precondition can be modeled more elegant by specifying the actor in the Use case in stead of saying “Actor”. I normally put the Actor names in Italics in my Use Cases.

Comment 2: use alternative flows in stead of extensions.
Almost every Use Case has alternative flows, so don’t introduce another mechanism (extensions) when alternative flows can handle the situation.

Schedule Exterminator Visit To Customer

1. The Office worker verifies customer is an existing customer.
2. The Office worker retrieves customer records.
3. The Office worker requests available times for a technician visit.
4. System presents available times for a technician visit.
5. The Office worker and customer select an acceptable time from the list of available times.
6. The Office worker adds visit time and location to technician’s schedule.
7. System confirms that appointment has been scheduled.
8. The Office worker confirms the appointment with the customer.

Alternative flows

A1.1 New customer
When the Actor determines that the customer is NOT an existing customer,
the Actor adds a new customer record including the customers location.
Continue at step 2.

Comment 3: “Actor adds visit time and location to technician’s schedule” is not a Use Case, as it does not represent a complete User’s goal, it is only a step in it.

“Add visit time and location” could be a subflow of this use case. Use subflows to prevent the main flow from becoming too complex. Subflows, in my opinion, should NEVER have preconditions.
The reader of the Use Case should be able to first understand the mainflow, and after that delve deeper into the subflows.
In order to be able to understand the mainflow, the reader should know about the preconditions for the subflow while reading the mainflow.

So insteat of:
Flow:

4. Step …
5. Step … (see subflow S)
6. Step …

Subflow S
Precondition: some condition you might think of DOES hold

Step
Step
Step

I prefer:

4. Step …
5. The verifies that some condition you might think of DOES hold
6. Step …

Alternative flows
A5.1 If some condition you might think of DOES NOT hold
Continue at step …

Again: use the construct “Alternative flows” which we use already.

Hope to hear from you all.

I’m updating this article so as to not distract other readers (and keeping these comments as history). Thanks for catching it.

The point I was making (in both articles that reference CRUD) is that there are elements of software development that many (but not all) people take to be “understood.”  It raises interesting debates about how to document and approach them when writing requirements.

By analogy – if you set up a database, of course you need to be able to retrieve a record.  If you have a secure website, of course the user has to be logged in.

There are cases in both domains where you absolutely must specify this stuff.

• Database – you are not using auto-increment functions to generate unique ids; you have concurrency;  you need to apply a locking strategy to prevent multiple people from creating multiple records with the same “unique” id.
• User ACL – you support role-based authorization/variation for viewing of data, access to pages, and validation of fields on entry.  And you expose an API (perhaps as an SOA service provider).

But there are also cases where the effort to document “understood” levels of detail provides little return.