Version 2
1. Introduction
1.1 Purpose of the System
Academic advising is mandatory for undergraduate students in the College of
Engineering. Each semester, prior to registration for the following semester,
undergraduates meet with their assigned faculty advisors to review their progress in the
curriculum and determine the courses to be taken in the following semester. The purpose
of this system is to provide a more automated, electronic, on-line system for
administering and conducting advising activities in the College of Engineering. The
system should also allow for gathering of statistics, such as projected class sizes,
prospective graduates, etc. from advising information.
1.2 Design Goals
 Provide an on-line infrastructure for administering academic advising, college wide,
including promulgation of rosters, assignment of advisors, and collecting of statistics.
 Provide a framework for students to find their faculty advisor, sign up fo appointments,
and complete the PoC forms.
 Provide a framework for faculty, advisors and administrators to access and review
advising information.
 Provide an infrastructure for generating reports, including academic holds, class
standing, and course size projections
1.3 Definitions, acronyms and abbreviations
 CEE: Civil and Environmental Engineering.
 CoE: College of Engineering.
 DAA: Director of Academic Affairs; the administrator in charge of SAS.
 DO: Department Office; refers to the staff in a department office who are involved in
academic advising, including the Department Secretary and/or department
Undergraduate Advisor.
 EE: Electrical Engineering.
 FA: Faculty Advisor.
 ME: Mechanical Engineering.
 PoC: Program of Courses; the form filled out during an advising session and agree to
by the faculty advisor and student. The student retains a copy and a copy is returned to
the student's record in SAS.
 SAS: Student Academic Services; the office in the College of Engineering Dean's
Office responsible for maintaining student academic records and administering advising
in the college. The term refers to all staff in that office, including the DAA.

ST: Student; enrolled in the College of Engineering in either department ME, CEE, or
EE.
 UGA: Undergraduate Advisor; each department has a UGA, who is responsible for
identifying new students, graduating students, and students no longer on the list and
assigning advisors to students.
1.4 References
1.5 Overview
2. Current Software Architecture
Currently there is no software in place to automate the administration of academic advising.
Instead, the administration of academic advising is done manually using a variety of paper forms,
including department rosters, advisor assignment lists, curriculum check sheets, and program of
courses advising forms. These lists and forms shuffle between different offices (e.g. Student
Academic Services and Department Offices), and individuals (e.g. department office staff,
undergraduate advisors, faculty advisors and students). Furthermore, little use is made of the
information collected during advising. After advising, Program of Courses forms are filed in
each student's record and have limited availability to students, advisors and administrators.
3. Proposed Software Architecture
3.1 Overview
3.2 Subsystem Decomposisition
 USER: Consists of accounts for all actors in the entire system. Each actor group has
their own set of attributes.
 COMMUNICATIONS: Handles all communication between actors in the KUKA
system. Interface objects include email and postings (welcome page postings).
 FORMS: Gathers and manages data through interaction with the User. Provides
format for generating and editing email announcements or notification emails,
completing PoC forms, and creating lists and course reports.
 LIST: Provides utilities for reading and modifying various types of lists and keeps
track of list statistics.
 CALENDER: Provides a viewable calendar of important dates related to advising
and sends notification of those dates to relevant users; facilitates the scheduling of
appointments between faculty advisors and students for advising.
 DISPLAY: Provide display tools for items needing display, including the welcome
page, lists, the PoC form, records, reports, and notifications.
 MANAGER: Manages KUKA system information and activities.
3.3 Hardware/Software Mapping
3.4 Persistent Data Management
Data requiring persistency includes the following:
 User attributes (username, password, permissions, ID number, name, E-mail address)
 List of students with student information (major/dept, track, semester, advisor, status)
 List of faculty advisor with faculty information (department, track, semester, advising
load, status, advisee list)
 PoC
 Course reports
 Statistics
Flat files will be used for the storage of these persistent data. A single file, one for each semester,
containing student information of all students will be maintained. The likewise will be done for
faculty information for all faculty. A directory will be created for each student to keep record of
PoC forms. A PoC file will be maintained for the student for every semester that the student is
active. Method for maintenance for course reports and statistics is still to be determined.
3.5 Access Control and Security
The authentication mechanism for the KUKA system will be a username and password
combination. Associated with each type of user (DAA/ SAS, UGA/DO, FA, and ST) are
permissions to perform certain actions. These permissions are allocated at login, based on the
user type, and the permissions are checked at the time the user selects a function to perform. The
capabilities possessed by each type of user are listed in the table below.
DAA/SAS
- View and edit
information of all
students and
faculty advisors in
the CoE
- view and edit PoCs
of all students
UGA/DO
- View and edit
information of all
students and
faculty advisors in
the respective
department and
- view and edit
student PoCs of
students in the
department
FA
- view and edit own
information
- update and submit
PoC forms of
advisees
- post availability
schedule for
advising
ST
- view and edit own
information
- view and edit own
PoC form
- request a change of
advisor
- sign up for advising
appointment
- change advising
appointment
3.6 Global Software Control
3.7 Boundary Conditions
4. Subsystem Services
4.1 Overview
4.2 User Subsystem
The user subsystem consists of accounts for all actors in the entire system. Each actor type
has their own set of attributes.
User Type
Actors
Attributes
General
DAA, SAS, UGA, DO
ID number
Name
Username
Password
E-mail Address
Status
Student
ST
Major/Dept
Track
Year
Advisor
PoC
Faculty
FA
Advising load
Advisee list
Major/Dept
Track
Functions
 Functions to set/read attributes – user gains access to functions to generate lists based on
permissions
 Functions to generate lists based on different attributes
 Sort user lists
Interactions
 passed to different subsystems always by reference
Notes
 May need to use an access control list to govern permissions
4.3 Communications Subsystem
The purpose of the communications subsystem is to provide a means of communication
between different actors of the KUKA system.
Interface Objects
 Email interface to the existing email system (wiliki)
 Posting (welcome page posting)
Objects
 Message
 Change of Advisor Request (via email)
 Report Discrepancy / Update Info (major/track) – (via email)
 Post Announcement (via posting and email)
 Appointment Availability Schedule (via posting)
 FA to ST communication (emergency changes—need to change appointment time)
 Subject
 Recipients
 Users – SAS, DAA, DO, UGA, FA, ST (ME, CEE, EE)
 Advisee list of particular FA (via posting and/or email)—(for Appointment
Availability Schedule)
 Hold list people (via posting and/or email)
The communications system would handle communications between actors in the KUKA
system. As seen above, the interface object would be email and postings (welcome page
postings). The different objects of the communication would be the message, recipients, and
possibly the subject.
As seen above, there are a variety of different interfaces with other systems. For example,
posting of the appointment availability schedule of a specific FA would have to interface
with the List system to retrieve the Advisee list. Also, message sent to students whom a hold
has been put on their accounts depends on the Hold List, from the List system.
4.4 Forms Subsystem
The FORMS subsystem gathers and manages data through interaction with the User.
The subsystem could be used to generate email announcements or notification emails, the
PoC, and reports. The subsystem could also be used to modify list data, for example, the
advising list or list of faculty.
Some services of the subsystem are:
AddData()
AppendData()
GetData()
ClearData()
ModifyData()
CheckData()
SaveData()
SearchData()
ViewData()
ClearForm()
SubmitForm()
SignForm()
DisplayForm()
SearchForm()
PrintForm()
EmailForm()
AcknowledgeSend()
4.5 List Subsystem
The subsystem is mostly used for the set of utilities to read and alter the list. There can be
various types of lists each for a specific purpose to fulfill the system requirements. There
will also be functionality to control access to list by certain users. Also, our team is looking
to implement an interface that keeps track of statistics about lists, i.e. logs of the number of
users on the system.
Functionality
- Various list commands
o Insert into the list
o Remove from the list
o Get an entry from the list
o Put and entry in place of another entry in the list
o Clear the list
o Get the size of the list
o Check the status of the list (empty/full)
- Search function
o For reports and specific lists
- Sort function
Elements
- Every list should contain some data storage for the needed information.
Interfacing with other Subsystems
Users subsystem
- The users class will store the information of users in a list
o Each user will have a list of previous PoC’s saved.
Forms
- The forms will be stored in lists.
o They will be adding to and altering lists.
- The forms will also access list data for reports and other tasks
o They will be getting specific data by searching or sorting
Manager
- The manager controls everything, including the list.
4.6 Calendar Subsystem
The purpose of the calendar subsystem is to provide a viewable calendar of important dates
related to advising and send notification of those dates to relevant users and to facilitate the
scheduling of appointments between faculty advisors and students for advising.
Functionality
 send notification/reminder of important dates related to advising to relevant users
 provide a viewable calendar of important dates related to advising to all users
 allow faculty advisors to post their schedule of availability for advising online
 allow students to view their faculty advisor’s schedule and sign up for a time slot
 allow faculty advisor to view schedule of appointments
 allow students to change appointment time and notify faculty advisor of change
Interface
Components
Users
Calendar
Services
User
SAS
DAA
DO
UGA
- create calendar (input important
dates on calendar, edit)
- request/change request for email
notification of important dates
FA
ALL
- view calendar of important dates
ST
Appointment Scheduler
Services
- submit schedule
- edit schedule
- view schedule
- print schedule
- send mail
- view FA’s availability schedule
- sign up for appointment
- change appointment
- send mail
Cooperation w/ Other Subsystems
 User Accounts – accesses calendar subsystem for services
 Communications – communication with other subsystems; email notifications
 List – access list of faculty advisors and respective advisees


Forms – calendar layout; schedule layout
Display – view calendar; view schedule
Notes
 Can build upon existing system for time and dates
 Access control – students wishing to sign up for an appointment with faculty who is not
the student’s faculty advisor must request permission from the faculty advisor; faculty
advisor can grant permission through some method of overriding permissions
4.7 Display Subsystem
Provide display tools for items needing display, including the welcome page, lists, the PoC
form, records, reports, and notifications.
Support two groups and has two interfaces:
Group 1: DAA, SAS, DO, UGA
Group 2: FA/FAS, ST
Interface 1: operation interface (support operations)
Interface 2: communication interface (announcement or email)
1. Log in interface (users group 1, users group 2)
User group 1 can view, edit and print all the forms and lists
Course list
Student list (status, advisor, check sheet, POC, track information)
Advisor List
User group 2 can view and print his or her own forms and lists
Course list
Forms (check sheet, POC, track information)
Advisor List
ST-FA appointment schedule
2. General interface
Any operations that need confirmed (or generate failure report)
Select items to display (expend or close it)
Print hard copy
Announcement bulletin board: edit post or email to group or persons
4.8 Manager Subsystem
The main purpose to the management system is to manage the information and activities that
is going on in the KUKA systems. Basically, this is the “middle man” in the system that uses
the other subsystem to minimize or simplify the work of the users(namely, the students and
the faculties).
Functionality

Notifications
o This allows the user to post announcements/notification anytime. The
following are the functions included:
o [FORM(announcement), getdate()]
 Once the notification/announcement are written, user enters the date
when it will be announced.
o [ search(LIST))]
 This function enters a search function to determine the recipient of the
notifications
o [send(FORM(), getdate(), search(LIST())] KUKA will then send the notification/announcement on the date
specified to the determined recipients.

Change/Update student information (student no., track, and other information
that requires dean, assistant dean and/or EE/CE/ME office approval.)
o [notify(FORM(request change info), search(D, DA)] Once the student had the request form submitted (by providing his UH
ID no. for confirmation and security reasons), KUKA will send
notification to the authorized person/s for approval.
o [notify(FORM(request failed), return address())] If notification failed, the authorized person did not approve the request,
or 3 days had already past, KUKA sends notification to the student
that the request: failed to reached the authorized person, request has
not approved or authorized person did not respond, with the
explanation, if there is any, from that person.
o [FORM(confirm(accept, approved)), FORM(explanation)] –
 If it reached the authorized person, that person/s will have an option to
approve and reject the request. It will also prompt him to provide
explanation, which he may or may not provide.
o [Notify(FORM(announcement)), edit(return address())) Once approved, KUKA will change the information in the list as
requested and send a notification to the student that the request was
approved.

Report Discrepancy
o [notify(FORM(report discrepancy), search(D, DA, office))
 Once form submitted, send notification to the authorized person.
o [notify(FORM(failure to reach authority), return address())]
 If 3 days had past and no action was taken, or failed to reach authority,
KUKA sends notification to the student that the report have failed to
reached the authority
o [notify(FORM(discrepancy cleared), return address()), edit(return address())]
 After authorized personel had checked and confirmed the discrepancy,
student was notified and the information questioned was checked and
modified.
Dependencies
This subsystem is really dependent on the FORM(), USER() and LIST() subsystems. The
usefulness of this subsystem also depends on the functionalities that are going to be
implemented. The above lists are the ones likely to be implemented. Note that the functions
in CAPS are that subsystems that will be used. Other functions that are needed are needed,
from above are






Search()
Notify()
Confirm
Return address() – address of the user who submitted the request, report.
Getdate()
Date expired()
…
Updated by: Everret Kawano and Aileen Ng