Phase II: Project Design
1. Design
1.1 Use case diagram
A use case diagram provided as follow. The actor for this system is
developer who will initiate the events involved in each task. A developer
calls the Jbuilder to make a new DB application . After the application
created he can choose which bean he want to use(Connection Bean,
DBTable Bean, DrawChart Bean and Copy File bean). For each particular
bean, developer should set correct value for each properties.
1.2 Class diagram
For the Database Connection Bean, we are going to develop a java bean
component to connect to database, as shown below. The user enters or
selects a JDBC driver, a database URL , a username, and a password, and
clicks the Connect button to connect to the database. Once connected, an
instance of the Connection interface can obtained from the getConnection
Bean.
In the database connection bean, after user input the JDBC driver, database
URL, username and password ,
connectionPanel will pass all these information to the ConnectionClass
which will verify the information and return a connection object back to
connectionPanel. Then, connectionPanel will send the connection object to
the bean upon user’s requirment.
DatabaseTable bean is a useful utility that displays all the rows of a database
table in a Jtable , allow user to navigate and modify it’s content.
This bean consists two classes: CreateTable and NewRecordDialog. Once
the database is connected, the table contents are displayed in an instance of
CreatTable. The CreateTable class is a JavaBean component that can be
used to browse a table and modify a table.
An instance of NewRecordDialog is displayed to let user enter a new record
when user click the Insert button in CreateTable.
The DrawChart bean will provide a statistic view of data information
currently in the databasetable. By using this bean, user can draw a pie chart,
a bar chart, or both of them. DrawChart class is a JavaBean component with
GUIs in it.
Once received the connection object passed by connectionPanel class, it will
select the useful information or data and pass them to PieChart class and
BarChart class by using an instance of ChartModel. After get the data,
PieChart and BarChart will automatically draw charts on the GUIs.
For the copy bean, we can get data from a text file and copy the data to a
table. Before add the data to database user can have a look at the content of
the text file, then go ahead to save it to databse.
The following is the class model for the whole DB JavaBean project, which
almost includes all the major classes in the project. The diagram gives an
overview of the whole system by showing its classes and the relationships
among them. It models a developer develop a database project by using
beans. The central class is Frame1, which likes a controller for the whole
project. Associated with it are connection bean, database table bean,
drawchart bean, and copyfile bean. The Frame1 will decide which bean will
be used and by how. By using connectionPanel bean, user can set properties
to each bean.
1.3 Sequence diagram
Sequence diagram describes how different classes collaborate in the DB JavaBean
project. It is an interaction diagram that details how operations are carried out -what messages are sent and when. As shown as follow, the whole diagram organized
according to time. The time progresses as you go down the page. The objects
involved in the operation are listed from left to right according to when they take
part in the message sequence.
2. Formal specification and prototyping
English version of pre and post condition.
For the database connection bean:
Operation1 :select JBDC driver and Database URL
Pre: none JDBC driver and Database URL were selected
Pos: User specify what kind of database he/she want to connect to and select
driver and URL from the list of the combo box.
Operation2: Give the correct Username and Password for database access
Pre: None username and password were given at the beginning.
Pos: User fill in his/her username and password, the system will verify the if
the information is correct. If not, show the error message on
status bar.
Operation3: Use database table bean
Pre: The connectToTable property of connectionPanel is set to false by
default. Which means database bean will not be used.
Pos: Set the connectToTable property value to be true.
Operation4: Use drawChart bean
Pre: The DrawChart property of connectionPanel is set to false by default.
Which means drawChart bean will not be used.
Pos: Set the DrawChart property value to be true.
Operation5: Use copyFile bean
Pre: The CopyFile property of connectionPanel is set to false by default.
Which means CopyFile bean will not be used.
Pos: Set the CopyFile property value to be true.
Operation6: check if get the correct information from database.
Pre: There will be nothing in the table at the beginning.
Pos: After connected to the database, the records shown in the table should
be exactly the same as what in the database. [
Operation7: insert a new record
Pre: database don’t have that record.
Pos: database have all the record including the one just added.
Operation8: delete a new record
Pre: the record we want to be deleted was already in the database
Pos: this particular record is removed from database
Operation9: update a record
Pre: the record with the information user want to modify was in the
database.
Pos: the record with information modified by user is in the database.
Operation10: use drawChart bean(nameToshow, a property value, let
program know will column will be shown as names in charts)
Pre: the nameToShow value of drawBean was 0 as default
Pos: set a value to nameToShow.
Operation11:use CopyFile bean
Pre: there are no input file at the beginning.
Pos: user specifies a file to be load.
3. Software quality assurance plan
Software quality assurance plan
Purpose
The purpose of Software Quality Assurance (SQA) Plan is to serve as a
guideline to [ ensure the quality of the project. It [ provides a way to manage
software quality for "Data Base Java Beans Application" project.
This plan will identify the SQA responsibilities of the project developer;
define reviews and audits and how they will be conducted and list the
activities, processes; and identify the SQA work products.

References
Software Management fifth edition Donald J.Reifer
IEEE Standard for Software Test Documentation, IEEE Std 829-1983
IEEE Standard for Software Quality Assurance Plans, ANSI/IEEE Std 7301989
IEEE Guide for Software Quality Assurance Planning, DRAFT, P730.2/D4

Management
Organization:
Organization structure:
Committee: Drs. Bill Hankley, Daniel Andresen and Mitchell Neilsen
Major professor: Dr. Bill Hankley
Developer:
Feng Chen
Responsibilities:
The developer will be responsible for project specification, design and
implementation under the supervision of the major professor and report to all
the committee members in the form of three presentations with one at end of
each phase.
The major professor suggests the topic of the project and general
requirements, supervises and audits the whole development process of the
project.
The committee will oversee and review the work performed by the
developer, provide feedback and advice, and audit the whole developement
process during the three presentations of the project.
Tasks:
In phase I, the developer must finish a) project overview b) cost estimate c)
project plan.
In Phase II, the developer must finish a) object model and sequence diagram
b) SQA plan c) test plan d) formal technical review e) formal specification.
In Phase III, the developer must finish a) source code b) testing c) evaluation
d) references, user manual
(including installation instructions and user manual)
Documentations
The following documents will be provided at the end of each phase:
Phase 1: Software Requirement




Project Overview
Project plan
Cost Analysis
System Requirements Specification (SRS)
Phase 2: Software Design
 Software Quality Assurance (SQA) Plan
 System diagrams: Use case model, Object Model, sequence diagram,
database snowflake schemas
 Formal Specifications (in OCL)
 Test Plan
 Formal Technical Review (checklist)
Phase 3: Software Implementation
 Source Code, testing code.
 Web tutorials (general concepts) and user manual .
 Installation guidance: Detailed installation instructions fro
Jbuilder.
 Testing and Reliable Evaluation (including testing code)
 Project Evaluation
Standard, Practices, Conventions, and Metrics
Standards
Document Standards – MSE portfolio
Coding Standards - Java 1.3 or later
Coding Documents - Java Documentation
Test Standards - IEEE Standard for Software Test Documentation
Metrics
Line of code(LOC) is used to measure the size of the software
Programmer-month is used as another measure of the software

Review and Audits
There will be three formal presentations prepared by the developer and
evaluated by the committee at the end of each phase.

Test, Tools, Techniques, and Methodologies
Test:
As per Test Plan
Tools and techniques:
Jbuilder: development IDE
Together6.0 : UML model design
Oracle :
Database Server
Problem Reporting and Corrective Action
N/A
Training
N/A
Risk Management
N/A
4 Test plan
Identifier
"chen001-testplan-v001"
Introduction
This test plan will provide test cases for testing “The database java Beans
Applications”
project. The purpose of the plan is to ensure that proposed functionality of
the project can be implemented properly as specification defined.
Test Items
Unit testing: test major functionalities of each bean
Integration testing: test if each bean work well when put all of them together.
Test cases
DatabaseURL:
Incorrect input: wrong database url selected—should not let user connect to database
Correct input :select the correct url for database —should let user connect to
database
DatabaseDriver:
Incorrect input: wrong database driver selected—should not let user connect to
database
Correct input :select the correct url for database —should let user connect to
database
Logon:
Incorrect input: empty/wrong user name and/or empty/wrong password—
should not let user logon
Correct input: right user name and password—should let user logon
Update the data information:
Incorrect input: empty required field(s)—should not update or tell user to
fill in the required field(s)
Correct input: fill in all required field(s)—should update accordingly
Delete unwanted product from table:
Incorrect input: empty selection of item—should tell user to select certain
item then press delete button
Correct input: select item(s)—should delete selected item(s) from purchase
line items
Use database table bean:
Incorrect input: do not set the connecttoTable property of ConnectionPanle
on the Properties tab of the Inspector or do not add
connectionpanel1.setTable(createTable1) to the controller class— database
table bean should not work correctly.
Correct input :set connecttoTable property to be true and add line
“connectionpanel1.setTable(createTable1)” to the source—database table
bean will work.
Use draw chart bean:
Incorrect input: do not set the drawChart property of ConnectionPanle on
the Properties tab of the Inspector or do not add
connectionpanel1.setChart(newChart1) to the controller class— draw chart
bean should not work correctly.
Correct input :set drawChart property to be true and add line
“connectionpanel1.setChart(newChart1)” to the source—draw chart bean
will work.
Use Copy File bean:
Incorrect input: do not set the copyFile property of ConnectionPanle on the
Properties tab of the Inspector or do not add
connectionpanel1.setCopy(newcopyfile1); to the controller class— copy file
bean should not work correctly.
Correct input :set copyFile property to be true and add line
“connectionpanel1.setCopy(newcopyfile1);” to the source—Copy File bean
will work.
To use the Copy File bean:
Incorrect input: wrong input file format—could not read the file correctly
Correct input : change the format of input follow the instruction—could
read information from file.
To use the Draw Chart bean:
Incorrect input: do not set nameTo and numbers property — charts will not
show up
Correct input: set the correct value to these two properties charts will show
up
Pass/fail criteria
Testing is finished when all tests have been successfully completed.
Suspension criteria
If any defects are found during testing, the code shall be fixed, then testing
will be resumed. The defects will be tested
all over again.
Deliverables
Test plan
Test cases
Resolution of defects
Test input and test output data
Responsibilities
The developer is responsible for all the testing activities to be carried out.
Approvals
Approved by Committee members.
5 Develop a formal checklist and a formal report
10.1 Introduction
A formal technical inspection or formal technical review (FTR) is a quality
assurance activity for software. It aims to
find and eliminate software defects. Formal inspections may be applied to
any product or partial product of the
software development process, including requirements, design, and code.
Formal inspections are embedded in the
process of developing products and are done in the early stages of each
product's development.
10.2 Software requirement specification (SRS) checklist[4]
Completeness
Does this project include all user requirements (as defined in the concept
phase)?
Is a user manual submitted at the end of this project?
Does code match the design?
Does the design reasonable?
Consistency
Is there any internal inconsistency between the software requirements?
Does this application work on all version of Jbuilder?
Is this project compatible with different hardware?
Is the database application platform-independent?
Correctness
Is there justification for the design/implementation constraints?
Feasibility
Will the design(models), operation( coding), and maintenance(manuals) of
software be feasible?
Modifiability
Are different components organized to allow for modifications?
Is each unique bean easy to be reused?
Traceability
Does this database application completely cover the requirements defined
by client?
Understandability
Is the language ambiguous?
Is the user manual understandable?
Maintainability
Does the documentation follow MSE portfolio?
Is the documentation clear and unambiguous?
Verifiability/Testability
Are the requirements verifiable (i.e., can the software package be checked to
see whether requirements have been
fulfilled)?
Clarity
Are names indicative of their meaning?
 Is each concept defined only once, with one clear meaning?
Is each statement written as clearly as possible?
Functionality
Does the design implement the specifications and requirements?
Reliability
Are abnormal conditions considered?
Are the defect conditions/codes/messages specified completely and
meaningfully?