BMI Management System
Software Design Document Phase 1
Beta version Date Author Comments
1.0 01/03/18 P. Gangavalli Initial draft
1.1 03/03/18 P.Gangavalli Minor changes to Package
diagram and class
diagram. Stable release
1.2 18/03/18 P.Gangavalli Mo
id rating >34.99
Client : Hills Public School
Vendor : You studying COIT12200 at CQU Term1 2018
Due Date: Week5 Friday April 6th XXXXXXXXXX45pm
Please email XXXXXXXXXX with any co
ections / requests for
clarification.
mailto: XXXXXXXXXX
COIT12200, 2018 Term One - Page 1 of 16
TABLE OF CONTENTS
1. INTRODUCTION 2
1.1 Purpose 2
1.2 Scope 2
1.3 Overview 2
2. SYSTEM OVERVIEW 2
3. SYSTEM ARCHITECTURE 3
3.1 Architectural Design 3
3.2 Use Case Diagram 4
3.3 Class Diagram 5
3.4 Sequence Diagrams 6
4. DATA DESIGN 10
5. INTERFACE DESIGN 12
6. REQUIREMENTS MATRIX 14
7. TEST PLAN 15
XXXXXXXXXXSUBMISSION 15
XXXXXXXXXXMARKING GUIDE 16
10. ACKNOWLEDGMENTS 16
COIT12200, 2018 Term One - Page 2 of 16
1. INTRODUCTION
1.1 Purpose
Hills public school is a leading primary and secondary education provider for children in
Australia. With the increase in child obesity nationwide, the principal wanted to keep track of
their student’s wellbeing. Body Mass Index (BMI) is a ratio of weight to height and identifies
over and underweight students easily. The school approached CQU software development
under graduate students and you are asked to voluntarily help them out.
1.2 Scope
The system is to be developed in two phases. The functionality is limited to the given
functional requirements but the system must have graphical user interface (GUI) and must be
developed using Java technologies( NetBeans, Swing , Java DB).Due to time constraint the
system in Phase 1 cannot handle
owse feature to cycle through the students. This will be
implemented in Phase 2.
1.3 Overview
BMI is calculated using a simple formula with metrics for weight in kilograms and height in
meters. (1 meter =100 centimetres). The cu
ent available ratings are as below
BMI= weight / (height x height)
Bulimic Lean Under Normal Over Obese Mo
id
XXXXXXXXXX== XXXXXXXXXX== XXXXXXXXXX== XXXXXXXXXX== XXXXXXXXXX==34.99 >34.99
2. SYSTEM OVERVIEW
The initial user functional requirements are:
1. Start the application and connect to the database. If a connection cannot be established, the
application must exit with a message.
2. Display all students’ records.
3. Display the record for a specified student.
COIT12200, 2018 Term One - Page 3 of 16
4. Display all records where the BMI is within the specified range.
5. Display the total records number and details of students at risk (Bulimic and Mo
id).
6. Update height and weight fields with any changes and automatically assign BMI and ratings for
specified student and these should be reflected in the database.
7. Add new Student and this insertion to be reflected in the database.
8. Clear all text fields.
9. Close the database connection and Exit the application.
3. SYSTEM ARCHITECTURE
3.1 Architectural Design
The system is Object Oriented and developed in Java adhering to the class diagram provided.
Phase 1: Single tier with two layered design with the below package diagram
COIT12200, 2018 Term One - Page 4 of 16
3.2 Use Case Diagram
COIT12200, 2018 Term One - Page 5 of 16
3.3 Class Diagram
COIT12200, 2018 Term One - Page 6 of 16
3.4 Sequence Diagrams
The sequence diagrams for the realisation of requirements 1-9 are shown below. Note that in these
cases, we have chosen to show JDBC interaction with the database. In requirement 1, note that
“start GUI” is not a method. It refers to the process employed by the NetBeans GUI Builder to
start up a GUI on the Swing thread.
Above Sequence diagram for Requirement 1 (Start)
COIT12200, 2018 Term One - Page 7 of 16
Above Sequence diagram for Requirement 2 (All students)
Above Sequence diagram for Requirement 3 (Single student)
COIT12200, 2018 Term One - Page 8 of 16
Above Sequence diagram for Requirement 4 (Bmi within range)
Above Sequence diagram for Requirement 5 (At risk Students)
COIT12200, 2018 Term One - Page 9 of 16
Above Sequence diagram for Requirement 6 (Update)
Above Sequence diagram for Requirement 7 (Add new)
COIT12200, 2018 Term One - Page 10 of 16
XXXXXXXXXXAbove Sequence diagram for Requirement 9 (Close)
4. DATA DESIGN
The SQL script that will be used to test the application is given below.
DROP TABLE STATS;
CREATE TABLE STATS
(
STUDENTID VARCHAR (8) NOT NULL,
HEIGHT FLOAT NOT NULL,
WEIGHT FLOAT NOT NULL,
COIT12200, 2018 Term One - Page 11 of 16
RATING VARCHAR(10),
PRIMARY KEY (STUDENTID)
);
INSERT INTO STATS(STUDENTID,HEIGHT,WEIGHT,RATING)
VALUES
('S01',170.3,83.2,'?'),
('S02',165.1,50.1,'?'),
('S03',154.8,45.7,'?'),
('S04',193.6,95.3,'?'),
('S05',183.2,40.5,'?'),
('S06',145.0,49.0,'?'),
('S07',160.9,33.1,'?'),
('S08',175.4,100.8,'?'),
('S09',161.0,110.0,'?'),
('S10',177.5,51.6,'?');
Note BMI is not stored in the table. It is a computed value and no storage required.
As there is only one table, an ERD is not provided.
Data access will be via JDBC using prepared statements, as shown in the Sequence Diagrams. Java
DB must be used as the database.
Note that if you choose to use SQL’s COUNT() method for fetched record count, the result set
eturned when the query is executed consists of a single row with a single column that contains an
int. To retrieve this value, use code similar to the following:
execute query here
resultSet and n have been declared elsewhere
esultSet.next();
n = resultSet.getInt( 1 );
.
COIT12200, 2018 Term One - Page 12 of 16
5. INTERFACE DESIGN
Developers are free to use the NetBeans GUI Builder or alternatively, they can hand code the
complete GUI. You can be creative and only an indicative GUI is shown. Developers are free to
use this design as is or to do things differently, for example using menus for data entry. Note that
ecause of the simplicity only one initial screen is provided but explained the actions to be ca
ied
out. When outputting lists of results, formatting the data as tables with appropriate headings is
equired – eg) use Result.toString() to display the details of each result.
1. All Students:
Output of fetched records to be only shown in the text area. Any previous content to be cleared.
Should have proper header and footer showing total records fetched.
2. Specific Student:
The student id to be searched is entered in the text field and other fields should be populated if
ecord found. Only the status of the operation (success/fail) to be shown in text Area.
3. Bmi in Range:
The range fields should be validated (numeric and first field smaller than second field in value)
and the results to be shown in text area. Any previous content to be cleared. Should have proper
header and footer showing total records fetched.
4. At Risk Students:
Only the students who fall on the boundary rating to be shown (Bulimic and Mo
id). Any previous
content to be cleared. Should have proper header and footer showing total records fetched
5. Update:
This operation should calculate BMI and Rating for the cu
ent student and changes to be reflected
in the database and the operation status (success/fail) to be shown in text Area. Cu
ently there is
no feature to cycle through the list. We search for specific student and only update that student
details. The height, weight can also be updated. Note Student# updating is avoided here because
it is a primary key.
6. Add New:
This operation can only be performed after first clicking on clear button to clearing the text fields.
The height, weight and Student# need to be entered. Note Student# to be unique because it is a
primary key. Any changes to be reflected in the database and the operation status (success/fail) to
e shown in text Area. All inputs to be received with existing swing controls and no extra controls
or dialog boxes required.
COIT12200, 2018 Term One - Page 13 of 16
Bmi and Rating text fields are never editable to the user and shown in grey colour. The text Area
should not be editable and well formatted with header and footer showing total records fetched
and scroll panes when required.
Indicative GUI
COIT12200, 2018 Term One - Page 14 of 16
Functionality Swing Components
Output JTextArea
Input JLabel, JTextField
Operations JButton
6. REQUIREMENTS MATRIX
Requirement Button
Inputs Required
1 n/a n/a
2 All Students None
3 Specified Student Student #
4 BMI in Range Range of values
5 At risk students None
6 Update Fields Student #,Height, Weight
7 Add New Student #, Height, Weight
8 Clear None
9 Exit None
Mapping of requirements to actions
COIT12200, 2018 Term One - Page 15 of 16
7. TEST PLAN
The following tests will be performed prior to acceptance:
Requirement Test
Comment
1 Start Operation performs
co
ectly. Handles no
database/inco
ect database
Application is to exit with
message.
2 All Students Operation
performs co
ectly
3 Specific Student Operation
performs co
ectly
4 Bmi in Range Operation
performs co
ectly given co
ect
preconditions
Validation checks required.
First field smaller than second
field in value and should be
numeric and positive
5 At Risk Students Operation
performs co
ectly given co
ect
preconditions
6 Update Operation performs
co
ectly