UML Weekend Crash Course™ - To Parent Directory

290
Sunday Afternoon
Create
User Account
User
Upload
Appointments
and Contacts
Query
Contacts
Query
Contacts From
Wired Device
Query
Contacts From
Wireless Device
Log In
Query
Appointments
Query
Appointments From
Wireless Device
Query
Appointments From
Wired Devices
Figure 28-1 UML Use Case diagram, Friendly Reminder system
The requirements-gathering team then develops the details behind each of these Use
Cases by developing Use Case narratives and possibly Activity diagrams. They also find all
the Use Case scenarios for each Use Case to provide the basis for the test plan.
Cross-Ref
The steps for developing Use Case narratives and finding Use Case scenarios
for a test plan are outlined in Sessions 7 and 8.
Analysis
In the requirements-gathering phase, you considered what the system must do to meet the
needs of the client. In the analysis phase, you expand your understanding of the business
problem and create a Class diagram that represents the business problem. Because the
analysis phase is more about the business problem than the technical solution to that
problem, this phase, like the previous one, will be essentially the same for Web and
non-Web applications.
In this case study, one of the areas you need to analyze is how appointments are represented
in the system. Through an analysis of the existing system and the business problem,
the analysts create a conceptual Class diagram of The Friendly Reminder appointments and
contacts. This diagram is shown in Figure 28-2. A User makes zero to many Appointments
and tracks zero to many Contacts. Each Appointment has a date, time, description, priority,
notes, and Contacts related to that Appointment. A Contact is anybody about whom the