Patterson SuperstoreChapter 5 Structural Modeling

Twittie Senivongse (Ed.) [Revised by Nakornthip]

Functional Requirements Revisited1. Schedule appointment

1.1 The system shall be able to receive a client’s request to be seen by the clinic.1.2 The system shall display the defined service offerings list.1.3 Determine service

1.3.1 The system shall allow the client to either choose a defined service offering from the list or request that a service need survey be completed.1.3.2 When the client has completed the service need survey, the system shall determine whether the service needed falls within the scope of the clinic’s capabilities.

1.4 Determine referral for the client’s conditions beyond the scope of the clinic’s services

1.4.1 The system shall list referral information.1.4.2 The system shall compare and evaluate referral need against referral list.1.4.3 The system shall display appropriate referrals.

1.5 Make appointment for the client’s conditions within the scope of the clinic’s services

1.5.1 The system shall display the current real-time availability for appointmentscheduling with wait time listed.1.5.2 The system shall allow the client to choose appointment time for the current day or make an appointment in advance.1.5.3 The system shall update the calendar to reflect scheduled appointment.1.5.4 The system shall send a confirmation to the client.

date, time

Detail Use Case Description for Schedule Appointment Revisited

Detail Use Case Description for Make Appointment Revisited

Detail Use Case Description for Make Referral Revisited

Overview Use Case Description for Communicate Real Time Revisited

Overview Use Case Description for Assess via Tele-Health Revisited

Object Identification (1/2)

• Using textual analysis on use case descriptions (and functional requirements), Ruby and the team identified a set of candidate classes:• client, existing health clinic system, appointment,

referral, clinic services, service need, survey, administrative staff, wait time, time/data, appointment preference, appointment confirmation, match, referral need

• The goal in this first iteration was to be as thorough as possible.

Sarah, Business analyst Kelly, System analystRuby, Project manager

Object Identification (2/2)• Also using brainstorming and common object list,

Ruby asked the team• Were there any attributes, operations, and/or

relationships for these potential candidate classes?• Were any of these potential classes only actors, in which

case, no class would be necessary in the structural model?

• The team decided on these candidate classes:• client, appointment, service referral, clinic service,

service need, survey, service listing, referral listing, appointment list

• The team then created CRC cards.

Sarah, Business analyst Kelly, System analystRuby, Project manager

CRC Card: Client

CRC Card: Survey

Survey of client’s condition to determine service need

CRC Card: Survey Question

CRC Card: Service Need

Service need is used to determine if the client’s condition falls within scope of the clinic service (and appointment can be made), or referral is to be made from a referral list.

CRC Card: Clinic Service

CRC Card: Appointment

CRC Card: Calendar

CRC Card: Referral List

CRC Card: Referral

Review CRC Cards (for structural model validation)• The team decided that they should role-play the

CRC cards using the use case descriptions to validate the current structural model.• CRC cards were handed out to members of the team.• The team executed different use cases, one at a time, to

see if the current structural model could support each use case or whether the use case caused the “system” to crash.• Anytime the “system” crashed, there was something

missing: a class, an attribute, a relationship, or an operation. • They would then add the missing information to the

structural model and try executing the use case again.

Sarah, Business analyst Kelly, System analystRuby, Project manager

Remove because the team accidentally combined the actor and class aspects of the client, e.g. the Client actor requests an appointment, not the Client class.

Name and Address needed to be expanded.

Identify Need responsibility was very complex. As it dealt with 3 use cases –Schedule Appointment, Make Appointment, Make Referrral – it was decomposed into 3 responsibilities.

Create Class Diagram from CRC Cards

Review Structural ModelIf the service need resulted in an appointment being created, it should insert the appointment to the calendar of appointments too.

This association needed to be recorded in both CRC card and class diagram.

Revise More CRC Card: Calendar

Revised Class Diagram