Student Info Systems
Title of This Report
Abstract:
Abstract is required. It is a summary of your project. Your final project report is expected to be 10 pages, including the references and title. The font is Times New Roman, the font size is 12. You may use multiple line space of 1.15 or 1.25. Do not use single space or double space.
## we use the same format as the midterm template.
## you do not need to delete any content in midterm report. Everything for the final report will be growing on top of the midterm report. What you need to do is: just add more content to the midterm report.
## what are the NEW content in the final report?
· You can still update, improve, revise the midterm report.
· Require three new design models to the final report: Use Case diagram, sequence diagram, and activity diagram.
· The implementation of the SIS is required. It will be shown in the template how to demonstrate the implementation.
· Validation is optional. To encourage you to do this section, extra points will be given to the final report grade.
· Of course, at this moment, the conclusion is required. It should not be “Expected Results”.
I. Introduction
Why do you want to do this work – goal and objectives. Background is to show the related work in this area. What are existing works in this area, what are current results? How do the current works solve the problem? Please put enough citation for current existing works in this area.
II. Problem Statement (Rationale)
What are the current existing research issues? What are the problems you will solve in this project? Give a detail description why this problem is important, i.e., what if the problem is not solved, why this work is significant.
III. Related Work (Background)
What are the current works that has been done? Please use correct reference form.
IV. Project Management and Timeline
List all tasks of your project that you have implemented, the person that conducted and finished this task, time that started and finished this task. A sample chart is shown in the following.
|
Task# |
Task Description |
Personnel |
Time |
Memo |
|
1 |
System configuration; literature review; … |
Keoka Jackson |
Sep 7 to Sep 30 |
|
|
2 |
|
|
|
|
|
3 |
|
|
|
|
|
… … |
|
|
|
|
|
10 |
|
|
|
|
V. Design Model of System
In this section, you need to present the model of the system. You need to use any standard models for software and/or system design. Preferred model: UML model, Zed, Petri Nets, First Order Logic, etc. (if you have no idea about any other design methodologies).
If use the UML model, the system design model must include static diagram – Class diagram and dynamic diagram – use case diagram and/or state diagram and/or sequence diagram and/or activity diagram. This is required for all projects.
Your system design model must follow the correct notation. In the final report, you must have a COMPLETE design model, all errors in midterm report must be fixed and included.
Our system design model will include the class diagram and state diagram, which are shown in Figure 2. & 10. In final report, we will include the sequence diagram and activity diagrams.
4.1. Class Diagram (Midterm )
a. Description of each class
Per the introduction in Section I. our SIS system will need 7 classes to realize the overall behaviors. In detail, our SIS will need to record students’ information, academic record, and continuous regiration information. In order to maintain the correct information and academic record, the SIS will need seven classes in the design: class Student, Professor, Admin, Person, Course, …….
Each class is defined in Sect 4.2. Figure 2 -9.
To show the dynamic behavior of each execution objects of each class in the system, the state diagram is provided in section 4.4.
b. Definition of each class
In this section we will show the UML dentition of each class. The figure shown in this template is not a completed version. You will need to fill up with other classes’ definitions.
( Person Student Professor Admin <<attributes>> - Name: String - email: String - telephone: String - address: String - personID: String <<operations>> + setName(String newN): void + getName(): String + setEmail(String em): void + getEmail(): String <<constructor>> + Person(String n, String e) <<attributes>> - Grade: double - Courses: String[] - letterGrade: char <<behaviors>> + addCourse(String[] crs): void + dropCourse(String[] crs): Boolean <<constructor>> + Student(String n, String[] c) )
c. Class diagram
Describe the relationships among these seven classes, and formulate the class diagram.
( Person Student Professor Admin Course Grading Registration 1 1 0..* 1 StudentInformationSystem JFrame JPanel JButton NumberFormat 1 JTextField JTextArea )
4.2. State Diagram (Midterm )
We define ten key states which are: OpenAccount, Registering, AddingCourse, RemovingCourse, CheckStatus, Grading, …. Each state is defined in Figure 9 – 19 using UML state diagram notation. The overall state diagram is shown in Figure 20.
( OpenAccount entry/inputPInfo do/activateAcc exit/returnMsg otherActions/ Figure 11. Open Account State )
4.3. Use Case Diagram (Final Report)
Define all necessary use cases of Student Information System. Developed a Use case diagram with correct UML notation. Develop a use case description chart.
4.4. Sequence Diagram (Final Report)
Need to make sure the objects are consistent with the classes in Section 4.1.
If one sequence diagram does not complete, you may consider multiple sequence diagrams.
4.5. Activity Diagram (Final Report)
Focus some specific scenarios, for instance, login process that involves in the credential validation, registration is another complex process, you may use activity diagram to analyze.
VI. Tool Description
If you use any tools, platform, or new programming languages, plug-ins, please give a description what you use. You need to have introduction of the tool, syntax, semantics (if possible), examples, and why you need to use it. In the final report, you must have a COMPLETE description of the tools, engines, platforms that are used in your project.
VII. System Implementation and Results (Final Report)
This is required for final report. All functions that you have implemented, new APIs (if you have), user defined classes, design patterns that you used, can be implementations. Make sure attach snapshots for your results. For each functions, show the key methods how this function is implemented, attach the code.
The class Student provides the basic information of student account, and the APIs for student objects communicating with other objects. Here is the implementation of class Student:
class Student extends Person {
…. …. ….
}
Give a short description of class Professor here. Here is the implementation of class Professor:
class Professor extends Person {
…. …. ….
}
Give a short description of class Course here. Here is the implementation of class Course:
class Course {
…. …. ….
}
For the graphic user interface design, you may need to describe the interface. Here is the snapshot of courses available for a student:
Give a short description of class Grading here. Here is the implementation of class Grading:
class Grading {
…. …. ….
}
Give a short description of class Registration here. Here is the implementation of class Registration:
class Registration {
…. …. ….
}
Here is the snapshot of student registration
Finally, StudentInformationSystem class will initialize the user interface, instantiate the objects. here is the class StudentInformationSystem:
class StudentInformationSystem {
…. …. ….
Public static void main(String[] a) {
}
}
You need to pay attention to followings:
· The implementation has to be consistent with design model;
· The implementation has to be consistent with the tasks defined in your document.
· Identify the existing problems of your implementation, since nothing is perfect
VIII. Validation Methodology (Extra Points)
Any system needs to be validated before release. The validation methodology can be software testing or formal verification. There are various types of testing technologies available now. A list of testing tool can be found in this link: http://wrestt.cis.fiu.edu/cen/. A good reference book should be Roger S Pressman, “Software Engineering: A Practitioner's Approach,” 7th edition, McGraw-Hill Science, ISBN-13: 978-007337597-7. There are two unit testing techniques are recommended for this work: white box testing and black box testing. You are required to use one methodology, e.g., basis path testing.
· For Java applications, apps, you may use JUnit.
· For C or C-like program, you may use basis path testing. Testing is one of the biggest portion in the final report, please make sure you do it properly.
Example:
If you don’t use Junit, or don’t use software testing methods, then you can still validate your program properly and systematically.
Suppose we have a constraint that each student can register up to 5 courses for each semester. To validate this statement, run a program, register a student (TestS) with 4 courses, 5 courses, and 6 courses to observe the results. First two cases, the program should run correctly, but for the 6-course case, the program should report a message to user about this situation. How to report? That depends on your program.
You need to understand what are the system constraints. A full time student cannot register less than three courses each semester.
If grade is D or lower, then this class is not a passing class.
IX. Conclusion (Discussion and Future Works)
Conclusion includes the significance of this work and possible future extension that can be applied to this work.
References:
Following requirement is the requirement from template of IEEE standard conferences and journals. It should be good for you to follow, you may find IEEE standard format online.
The template will number citations consecutively within brackets [1]. The sentence punctuation follows the bracket [2]. Refer simply to the reference number, as in [3]—do not use “Ref. [3]” or “reference [3]” except at the beginning of a sentence: “Reference [3] was the first . . .”
Number footnotes separately in superscripts. Place the actual footnote at the bottom of the column in which it was cited. Do not put footnotes in the reference list. Use letters for table footnotes.
Unless there are six authors or more give all authors' names; do not use “et al.”. Papers that have not been published, even if they have been submitted for publication, should be cited as “unpublished” [4]. Papers that have been accepted for publication should be cited as “in press” [5]. Capitalize only the first word in a paper title, except for proper nouns and element symbols. For papers published in translation journals, please give the English citation first, followed by the original foreign-language citation [6].
G. Eason, B. Noble, and I. N. Sneddon, “On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,” Phil. Trans. Roy. Soc. London, vol. A247, pp. 529–551, April 1955. (references)
J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68–73.
I. S. Jacobs and C. P. Bean, “Fine particles, thin films and exchange anisotropy,” in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271–350.
K. Elissa, “Title of paper if known,” unpublished.
R. Nicole, “Title of paper with only first word capitalized,” J. Name Stand. Abbrev., in press.
Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy studies on magneto-optical media and plastic substrate interface,” IEEE Transl. J. Magn. Japan, vol. 2, pp. 740–741, August 1987 [Digests 9th Annual Conf. Magnetics Japan, p. 301, 1982].