of 25 /25
Patterson Superstore Chapter 5 Structural Modeling Twittie Senivongse (Ed.) [Revised by Nakornthip]

Patterson Superstore

  • Author
    others

  • View
    20

  • Download
    0

Embed Size (px)

Text of Patterson Superstore

Patterson Superstore Chapter 5 Structural Modeling
Twittie Senivongse (Ed.) [Revised by Nakornthip]
Functional Requirements Revisited 1. 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 appointment scheduling 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
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
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: 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 Model If 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