Why Don't We Add `Attributes` To Use Case Diagrams?

Question

I'm a undergraduate, and studying 'Software Design And Analysis' for my current semester. As part of the course, I was handed over a case study from which I had to make out the visual form of the resulting Use Case Diagram, with the necessary Use Cases and `Actors.

The case study is about Purchasing Flight Ticket System. A part of the case study read as follows,

Consider your neighboring travel agent from whom you can purchase flight tickets. To book a ticket you need to provide details about your journey i.e. on which date and at what time you would like to travel. You also need to provide your address ...

Now, according to what I knew at that time, I was associating Uses Cases with Functional Requirements - the behavioral aspect of the application. So when I read, "on which date and at what time you would like to travel", I was thinking in my head, "as a user, I would like to have the option to specify the date, time, address". When the evaluating and class discussion came to, I was told that when specifying use cases, I do not ever have to specify the needed attributes and such.

I was confused because,

1. The user expects the application to behave like this. Wouldn't it be nice to explicitly mention in the Use Case Diagram that this should happen, that is, it should take the date, time, address as input
2. I actually made my original assumption by making 'Get Date', 'Get Time', 'Get Address'as Use Cases, and including them in 'Get Details'.

Is this always true? Do we ever need to specify the attributes and such that will be used ( in an abstract or informal way )?

Thanks for your time!

P.S. Not asking for help with homework. The task was ungraded and is about 1-2 weeks old. If this violates the rules, please feel free to remove.

Answer 1

When talking about Use Case Diagrams, I like to make sure to mention one or two quotes from Martin Fowler's UML Distilled:

The best way to think of a use case diagram is that it's a graphical table of contents for the use case set.

and

Instead, concentrate on the textual description of a use case; that's where the real value of the technique lies.

Going to your specific example, the first step is to figure out what the use case is. A use case is a list of interactions between a role (or actor) and the system under design. In the example, I would not consider "get date" or even "get details" to be a use case. The use case would be "book ticket". A fully detailed use case would include information about who the actor is (the travel agent using the software system), their goal (reserve a ticket for a client or customer), other stakeholders (the agent's customer, the airline), preconditions (authentication and authorization, perhaps), steps (a sequence of inputs and outputs to achieve the goal, including dates, times, addresses) and perhaps extensions or alternate flows (alternate sequences of inputs and outputs which could be positive or negative).

The way that I think about it is that the use case exists at a level that provides value. A travel agent wouldn't use your system to enter an address - that doesn't add value for the travel agent or their client. The value comes from being able to book a ticket. Once your system provides at least one slice of flow through the use case, the travel agent can realize some value. As more flows (if there are any alternate flows) are added, more value is realized.

The Use Case Diagram, however, doesn't allow you to capture this level of detail. Like Fowler says, it's a graphical table of contents.