CSE 360 Programming Object Identification and CRC diagrams Project

Only Do part B. “Object Identification and CRC diagrams”.

CSE360 – Introduction to Software Engineering
Team Project Phase 2
Requirements – Deliverables
Phase 2 consists of:
A) Use Cases and the Use Case Diagram (30)
B) Object Identification and CRC (20)
C) Initial Class Diagram and class descriptions (40)
D) Test Plan for Functional Testing (30)
Above items will be submitted as a single PDF
E) Initial Prototype Code (20) – Submitted separately.
———————————————————————————-Modeling tool required for Phase II: Astah. Astah tutorial is posted in the
“Tutorials and Course Tools” module in the canvas.
Note: Following diagrams need to be constructed using Astah. Hand drawn
diagrams will receive automatic 50% deduction of points.
• Use case diagram.
• Class diagram
CRC diagram doesn’t need to be constructed using Astah
A) Use Cases and Use Case Diagram from Requirements – Discussed
Module 3
•
•
A (high-level) Use Case Diagram with all actors and their use cases, using Astah.
Document all use cases using the following format discussed in lectures.
Use case Name
Actors
Description
Data
Stimulus
Response
Comments
Hint – Be sure that use-cases map to all functional requirements from your
Requirements
B) Object Identification and CRC diagrams – – Discussed in Module 3
• For each use-case scenario from above to, identify objects involved in the
scenario including the ones within the system/software.
C) Class Diagram and class descriptions – – Discussed in Module #4
•
•
Identify all of the objects in your system.
For each object, include:
o A paragraph description of the object/class and how it fits into the project
system.
o UML representation of the object/class with a name, attributes, and
operations. Example:
•
UML class diagram of your entire system including all classes (with their
attributes and operations) and their relationships using Astah. For example,
Be sure that all classes are related in some way. There should not be a class that is
not related to any other classes in the system.
D) Test Plan –Discussed in the Use case-based test plan module
1. Project Overview
Login page
Stakeholders’ Requirements: The following requirements for the login page
●
●
●
●
●
●
●
Pediatric Doctor’s Office name and logo
Selection of identity (Doctor, Nurse, patient )
login button
Forgot password button
Text field for user ID
Text field for password
create an account (patient only)
Functional Requirements:
When the user opens the application, they are prompted with a sign in page where they can enter
their ID and password. If the information entered is correct, they will be directed to the requisite
pages and will have utility that they can access in the application. If the user enters the incorrect
ID or password the login page will display an error message (that tells the user they’ve entered
an incorrect ID number or the ID does not exist). The “forgot ID will” redirect the user to a page
where they can recover their ID.
Nonfunctional Requirements:
This is all done with a series of buttons, text fields, txt files, arrays and functions. The primary
functions are going to be a read/write function (to read in data and write the user data) in addition
to a number generator for the ID. This will all be done in a JavaFX class.
Patient’s record intake page
Stakeholders’ Requirements: The following requirements for the Patient’s record intake page
●
●
●
●
●
●
●
●
Radio button nurse name selection
Search engine for Patient
Add new patient records button
Text field to enter patient’s name(patient’s contact information)
Four text fields to enter vitals (weight, height, body temperature, blood pressure)
Text field for health question( alleges, any health concerns)
insurance information
pharmacy information
Functional Requirements:
When the nurse travels to the patient’s record intake page the nurse must first identify
themselves by selecting their name. Due to potential issues there is now accountability. Next, the
nurse will have the ability to search for a patient or create a new patient record if it’s their first
visit. After they’ve found the patient or created a new patient they will enter all the patient
information into the text fields.
Nonfunctional Requirements: Identification function will be used to verify the nurse with the
current database of nurses. The same read and write functions from before will be used to create
a new entry for the database.
Patient history
Stakeholders’ Requirements: The following requirements for the Patient History
●
●
●
●
●
Title Patient history
Text with health issues details
Text with prescribed medications
History of immunization
Patient visits
Functional Requirements:
This is a page that stores all the information about the patient from all past appointments to any
recent appointments. It will display all health issues so that the care provider knows about any
potential risks their patient may have. The second thing, medical care providers will see is the
previously prescribed medications. Additionally, immunization history will also be displayed on
this page to make sure the patient is up to date
Nonfunctional Requirements:
Writing function will read from the txt file and will display all the patient information in a
formatted way.
Physical test page
Stakeholders’ Requirements: The following requirements for the Physical test
●
●
●
●
●
Textbox examination
Risk factor text box
Medication text box
Patient history button
Patient’s record button
Functional Requirements:
The doctor will navigate to the Patient’s record to look at the vitals (weight, height, body
temperature, blood pressure) and other health questions such as allergies, and health risks. The
doctor can also navigate to the patient’s history via the button. They will have access to
information such as health issues, prescriptions, and immunization records. After reviewing the
information the doctor will be well informed about the patient and can examine their patient.
After the examination, the doctor will enter a summary into the textbox. In the event of a
prescription the doctor will enter necessary (identification) information. When the doctor submits
the form, the prescription will be forwarded to the patient’s pharmacy.
Nonfunctional Requirements:
Read function goes and outputs all the data for the doctor. Then the doctor’s prescription will be
written to a prescription txt file for the pharmacy.
Patient Portal
Stakeholders’ Requirements: The following requirements for the patient portal
●
●
●
●
Identified by (first and last name, date of birth, ID)
Contact information(view, edit) button
Summary of each patient’s last visit
send messages portal to doctor/nurse
After the patient logs in or creates an account they will be taken to the patient portal. Where they
have the option to access all of their information (User ID is prominently displayed). The user
will have the option to edit any of the information entered by the nurse to ensure validity.. The
patient can also see summaries of past visits. Below the summary of each patient’s visit is a
button that will take the patient message portal, where they can communicate with the
doctor/nurse/technicians.
2. User’s Guide/Walkthrough
Login Page:
The first scene is the login page. The user is prompted with a field to enter their patient
ID. If the ID is correct, the user will be redirected to their home screen. However, if the
ID is incorrect, or is not found, the user will be shown a message stating “Incorrect, or
non-existent ID”. If the user forgot their ID, they can press on the “Forgot ID?” label,
which will redirect them to a page where they can recover their ID. If they don’t have an
ID, they can press on the “Sign Up” label; This will redirect them to the Sign up page.
Sign up page
In the sign up page, there are five fields where the user can enter the necessary
information to create a new patient profile, with a unique ID to sign in in the future. If all
of the information entered is correct, the user will be signed in, and redirected to the
home screen. If one or more of the fields have incorrect entries, a warning message will
be displayed, where the problematic field is specified. If the user already has an account,
and remembers their ID, they can press the “Sign in” label to return to the sign in page.
Home screen:
In the home screen, the user is presented with their ID under the university logo. Multiple
options are presented in the form of labels which can be pressed to be redirected in order
to use their corresponding functions. The schedule label redirects the user to the
scheduling page.
Scheduling:
Users can schedule their appointments in the scheduling page. They are presented with a
calendar where they can select the desired date. We plan to add a field to enter time, as
well as a text area to show availability of their desired space. Pressing submit will store
the information in the system and return the user to the home screen, with a message
prompting success. If the scheduling space entered is not available, or the information is
incorrect, a warning message will be displayed.
Patient Directory:
The patient directory can only be accessed by technicians and doctors. It has two
functional labels on the superior corners that allow the user to either group multiple
patients into clusters, or add a new one. Under that, there’s a field where specific users
can be searched by name or patient ID. The rest of the screen is used to display existing
patients in a list.
Test Results:
The results page is accessible both by the doctor and the patient. The patient can only
view this content. The doctor uses this page to assess the risk level of the patient.
Technician portal:
The technician portal allows the technician to enter the test results of a specific patient.
When all information is complete, the user can press the submit button. If the information
entered is correct, it’s saved and displayed in the results page. If the information is
incorrect, a warning message pointing to the field containing the error will be displayed.