UML Weekend Crash Course™ - To Parent Directory

320
Appendix A
11. We need to know how to start the Use Case. Do we simply say “start” as in selecting
a menu option, or do we trigger an event Does the Use Case start because of
time or because of a state within the system Sometimes the starting mechanism
can tell us whether a Use Case should actually be more than one Use Case.
12. Both define conditions that must be true in order for the Use Case to work properly.
But the Use Case takes on the responsibility for testing the condition defined
in the preconditions, where it does not test the conditions defined in the assumptions.
The Use Case literally assumes that another Use Case has satisfied the
assumption prior to the execution of this Use Case.
13. The dialog is the conversation between the actor/Use Case and the system in the
execution of the Use Case. It describes how they communicate with one another in
order to complete the goal established for the Use Case.
14. They are defined separately mostly for visibility, to make certain that the dialog
has addressed all the possible outcomes. We also define them separately because
some termination options are difficult to describe in textual form (for example,
concurrency options like canceling in the middle of an operation).
15. Typically, you only include what the user would be able to see during his interaction
with the system. So you wouldn’t normally see things like saving items to the
database, closing connections, and so on. But there are always exceptions.
16. A Use Case is a single goal that the system is expected to accomplish. A scenario is
one possible way that the Use Case might execute when it attempts to accomplish
the goal.
17. Scenarios help you define all the functional requirements for the execution of the
Use Case. By doing so, they also provide the basis for a test plan to ensure that the
Use Case can and does work exactly as expected.
18. The Use Case narrative and the Activity diagram illustrating the Use Case narrative
can both be used.
19. Avoid redundancy. Isolate the unique segments of the logic into separate paths
rather than repeat the same series of steps in multiple scenarios. Then to describe
a complete scenario, simply combine and/or repeat the execution of individual
test segments.
20. Use the scenarios as a guide to develop test cases. Taken together, the set of scenarios
for all Use Cases in the system form the basis for your acceptance-level testing.
21. The Class diagram establishes the rules that govern the creation and use of objects.
The Object diagram represents the facts about actual objects. Consequently, the
Object diagram is a valuable tool for testing the accuracy and correctness of the
Class diagram.
22. A constraint is a rule or set of rules that dictate the values that may be assigned
to the attribute.
23. Constraints on an operation typically specify the logic or rules for the proper
execution of the operation.
24. The name compartment includes the name of the class, optionally a stereotype,
and optionally a set of properties (or constraints).
25. No. The UML allows you to show or hide as much or as little of the class notation
as you need for the current problem you are working on, though typically you
would always show at least the name compartment.