my.ITU – The Next Iteration
Object Oriented Analysis and Design
1
Contents
Introduction ...................................................................................................................................................... 4
The Task ...................................................................................................................................................... 4
Purpose ........................................................................................................................................................ 4
System Definition ........................................................................................................................................ 5
FACTOR................................................................................................................................................... 5
Context ......................................................................................................................................................... 7
Rich Picture.............................................................................................................................................. 7
Problem Domain ......................................................................................................................................... 7
Application Domain ..................................................................................................................................... 9
The Problem Domain ................................................................................................................................... 11
Clusters and Classes ............................................................................................................................... 11
User-Cluster ........................................................................................................................................... 11
Course-Cluster ...................................................................................................................................... 12
Calendar-Cluster ................................................................................................................................... 12
Class Diagram ........................................................................................................................................... 14
Behavioral Patterns ..................................................................................................................................... 15
Events ......................................................................................................................................................... 19
Application Domain ....................................................................................................................................... 20
Actors and Use-Cases ............................................................................................................................. 20
Actor Descriptions ................................................................................................................................. 20
Use-Case Specifications...................................................................................................................... 21
Functions .................................................................................................................................................... 24
User Interface ............................................................................................................................................ 26
Dialogue Style ....................................................................................................................................... 26
Overview .................................................................................................................................................. 27
Interface Examples .................................................................................................................................. 32
Design Document ............................................................................................................................................ 34
Task ............................................................................................................................................................ 34
Purpose .................................................................................................................................................... 34
Corrections to Analysis ............................................................................................................................ 34
Quality Goals ........................................................................................... Error! Bookmark not defined.30
Technical Platform ....................................................................................... Error! Bookmark not defined.30
Equipment ............................................................................................... Error! Bookmark not defined.30
System Software ...................................................................................... Error! Bookmark not defined.30
System Interfaces .................................................................................... Error! Bookmark not defined.30
2
Design Language ...................................................................................... Error! Bookmark not defined.30
Architecture ................................................................................................................................................. 35
Components ............................................................................................................................................ 35
Process Architecture................................................................................................................................ 36
Standards ................................................................................................................................................. 36
Components ............................................................................................ Error! Bookmark not defined.32
Model Component................................................................................................................................... 36
Structure .................................................................................................................................................. 37
Function Component ............................................................................... Error! Bookmark not defined.33
System Interface Component .................................................................. Error! Bookmark not defined.33
User Interface Component ...................................................................................................................... 39
Additional components? ......................................................................... Error! Bookmark not defined.33
Recommendations....................................................................................................................................... 40
Systems Usefulness ................................................................................................................................. 40
Plan for Use ............................................................................................................................................. 40
Implementation Plan ............................................................................................................................... 40
General Notes /Reminders
Sørg for at teksten kommer i korrekt rækkefølge.
Beskriv og afgræns systemet mere klart ift nuværende system.
Sørg for at dække alle punkter i skabelonen i chapter 16
Gå igennem classes afsnittet igen og opdater ift. ovrige afsnit. (delvist)
Add operations to the class diagrams.
3
Introduction
The Task
The main purpose of this paper is to provide an analysis of the current my.ITU system and
outline a proposed design for the next iteration of the system. All data from the current
architecture will be retained. Some part of the architecture will be remodeled. Useful
features are to be carried over from the current system and re-implemented in the second
iteration. Some features can be re-implemented without changes and will not be
considered in this paper. New features will be added, the most prominent of these being a
calendar function that is used to present personalized information based on the individual
users.
Purpose
The target system in the present design and analysis paper is does not introduce a new
and unique system but rather aims at improving existing systems by adding new
functionalities and presenting existing functionalities in a new and ingenious way. As such
the system should be perceived as the next iteration of a system already in operation,
namely the web portal my.ITU used by staff and students at the IT University (ITU).
Currently, the responsibilities of my.ITU cover areas such as registration for courses and
exams, webmail, announcing happenings at and around ITU as well as providing a host of
links to various relevant websites on the intra- and Internet (for example the course base,
room plans, various electronic libraries, student jobs and the Friday Bar).
The aim of the next iteration of my.ITU (in this paper referred to simply as 'the target
system' to avoid confusion with the current my.ITU) is to improve on my.ITU.
my.ITU is not 'intelligent' as there is no way for the individual user to filter or control what
kind of information is displayed where. Information about courses is displayed outside
my.ITU on course webpages maintained by teachers and teaching assistants. Moreover,
my.ITU does not make it possible to have a unified view of information relating to different
courses and/or other events.
The primary new feature of the target system will be the delivery of personalized
information regarding courses and other study activities, which will be displayed in a
calendar on the login page of my.ITU. A student's association with courses will be used as
a criterion on which information is deemed relevant or irrelevant. The already existing
valuable features of my.ITU ,as mentioned above, will be preserved in the target system.
The design for the target system will effectively re-model the architecture of my.ITU using
the existing data. Focus will be on integrating the calendar function and on the
administrative part, through which teaching faculty and administrative personnel can
manage courses.
The University’s students and staff are the main users within the target system and should
be involved in the development. Due to ITU being a very technology-oriented institution,
4
we expect a high level of IT experience from the users of our system as well as an
environment where net access is pervasive.
The target system will be a communication and administrative tool and it aims at being
flexible and extensibleto allow addition of new features and functionality; i.e. more
communication channels or similar.
System Definition
A computerized system that is optimized for the individual student at ITU by intelligently
collecting and pushing information from staff to students.
The system is based on the existing system at ITU, but aims at fine-tuning the current
system by sorting and targeting information to the students. The main purpose is to
deliver information about courses (lecture/room plans, changes in these, exam dates and
other deadlines) to users of our system through the already existing webportal my.ITU.
Information about changes to course plans and literature will be presented to users in a
message pane. To give users a better overview of their week, the information will also be
represented in a calendar showing the current week and any courses that are active for
the current user.
The system will be a communication tool facilitating both the communication from staff to
students as well as retrieving necessary information for students. It will run in a web
environment and therefore the platform will be any PC with access to the internet and the
necessary tools to interpret modern web programming languages. Moreover, it will be
required that our system has the ability to interface with the current staff/student and
course databases at ITU. It should comply with current web-standards and hence be easily
accessible to people familiar with navigating the web.
FACTOR
Functionality, Application Domain, Conditions, Technology, Objects, Responsibility
Functionality:
The system gathers information from the individual course sites and presents it to the
students and teachers in a single centralized interface e.g. in a message pane and a
calendar.
The new and updated information is displayed inside the message pane which is added
through existing channels. The systems main task is to correlate information with the
correct users based on their profiles (rights, courses, etc.)
Application Domain
Students, Teachers and administrative staff can retrieve information using the system.
Conditions
5
The system builds on existing information; the radical difference is in the aggregation and
treatment of this information.
Familiarity with existing dynamic web-interfaces will be required to operate the system.
We find it fair to assume that users are already familiar with such interfaces.
Technology
Computers with an internet connection. User with a login to my.ITU. The target users are
people who work and/or study at ITU.
The system also builds on existing technology for dynamic web-interfaces.
Objects
Users (teachers, students, administration), Courses, Calendars.
Responsibility
The system is used to manage user profiles and furthermore used to provide information
from courses based on these profiles back to the user in a centralized interface (e.g. as
mentioned before in a message pane).
The system is also used to create new courses and to manage the students and teachers
that are associated with a given course.
6
Context
Rich Picture
Problem Domain
A typical, full-time student at ITU follows 2-3 courses per semester, which is roughly
equivalent to 4 lectures per week. In connection with courses, the student is often engaged
in exercise labs and projects centered around the courses. In order to best manage time,
the student needs an easily accessible overview of the week, which provides information
about when and where lectures and labs are held, required reading, project clusters,
mandatory hand-ins etc.
my.ITU is regularly used by both students, teachers and staff as it provides easy access to
webmail, course administration, study guidelines and other handy information.
However, my.ITU does not aggregate course information and hence there is no centralized
point of access to course related information. Course sites are wikis, and information can
be changed without the course students being notified. To communicate changes to
existing plans, teachers often use the course website or, in urgent cases, mailing lists.
7
However, both courses of action may be insufficient since users have to navigate multiple
information sources on a daily basis to be updated on all changes.
With the current architecture the users are required to go to each individual course
website to access the relevant information pertaining to the course, and in addition to this
have to access the general information from ITU at the my.ITU website. This approach is
not only time consuming but also means that when a user is not at his own PC, and hence
does not have access to his own bookmarks, he has to find information by surfing to
www.itu.dk, follow the link to my.ITU, log on, follow the link to the course base, scroll to
find the relevant course, follow the link to the course description and from there navigate to
the course site.
As mentioned, my.ITU is not only used by students, but also by teachers and
administrative staff for email and course management.
Users can be divided in three groups corresponding to their role at ITU:
Students who are enrolled in one or more courses (receive information from the courses
they are associated with).
Teachers teaching one or more courses can change and add information for their active
courses in the Course Base. As mentioned, changes to course plans occur outside the
target system and hence do not depend on user profiles – thus TAs can change course
plans without having a teacher profile.
ITU administration users who manage the creation and termination of users and courses
as well as the matriculation of students (will be managing cancellations and can add
information for all courses).
Students can request courses through my.ITU. During the first implementation, the actual
matriculation is done by administrative staff aided by the target system. Later iterations of the
system could support automation of the enrollment process.
New courses are created each semester. A course ends when the semester is finished but the
course and information about users etc. is stored. When the last student has passed the course or
has dropped out the course is set to inactive, until then the course is active and the teachers and
remaining students are still associated with the course. Once students are enrolled in a course,
they will receive information regarding that course in their calendar and message-pane. Hence,
each course needs to keep track of the associated users.
The calendar keeps track of the current week and displays any and all course activities at the
appropriate day and time.
8
Application Domain
The target system should help the users navigate the existing information, which is
currently published in numerous locations, by harvesting information from course sites and
presenting it in a single centralized location.
By integrating course information into the existing architecture the users will have far
easier access to the necessary information. One page will keep the users updated on
general activities and will give a personalized overview of classes, project clusters,
deadlines for hand-ins, literature lists as well as cancellations, rescheduled classes,
altered deadlines, changes to the literature for the upcoming classes, etc. The information
will be presented in a calendar interface on the my.ITU website
General information types such as messages and examination dates will be presented in
a separate pane for course information.
The target system will be used by students, teachers and administrative staff at ITU. The
users are hence members of the student body at ITU or hired by ITU.
The system will be handling information from the various active courses and present it in a
calendar-style interface giving access to all relevant course information. Course plans will
be displayed in the calendar at the appropriate day and time. Changes to plans and other
messages will be displayed in a message-pane and reflected in the calendar (possibly in
red or another bright color).
The communication part of the system will manage: course plans, changes to course
plans, examination dates, literature lists, course news and general messages. Changes to
course plans happening outside the target system (i.e. on course websites) will be parsed
through a proxy class. The administrative part of the system will manage: available and
active courses and course matriculation.
my.ITU already maintains responsibility for the administrative tasks just mentioned, we
have, however, chosen to re-model this in the target system to ensure stable
communication between the newly implemented calendar and the course management.
The target system determines what information to display and what options to make
available to the user based on a user profile.
Figure 1.1 summarizes the system’s application-domain tasks.
Manage courses and students and teachers associated with the courses
o Keep track of when and where courses and lab/exercise sessions are
being held
o Keep track of reading plans for the individual lectures
Register changes to any of the above, including students joining or leaving
courses
Collect information based on the course associations of students 9
Present information about in a calendar overview in the students’ my.ITU login
page and general information in a message pane used for course information.
Figure 1.1: The essential tasks in the system’s application domain
10
The Problem Domain
Clusters and Classes
As illustrated in the figures below there are three main clusters of classes relevant for the system:
Users (Role Courses
pattern) Calendar
Users, Courses, and Calendar. The Users have different roles and hence different
possibilities in terms of navigating the system. Associated to each user is one or more
Courses and a Calendar.
These clusters and various classes are described in the following section.
User-Cluster
At ITU, people can have different roles: Student, Teacher or Administrative Staff.
However, people also share attributes which are relevant to ITU and to the target system.
These are properties such as name, date of birth/cpr-number, address and other contact
information. Hence, the User class is a generalization of the three subclasses Student,
Teacher and Administration.
In terms of the target system, a user is only interesting and relevant in relation to one of
these three roles. A user can have only one of these roles. Therefore, the user class is
used as superclass for all the various user roles and has been modeled following the Role
pattern.
The user class contains the following general attributes:
CPR, FirstName Surname, Address, Email, PhoneNumber.
The specialized roles Student, Teacher and Administrative Users contain information
about the attended courses and have the following additional attributes:
StudyLine, Grades, StudentID, StaffID, and Rights.
Student and Teachers are assigned to one or more courses and semesters while the
administrative users have no specific affiliation.
11
The User class is linked to a proxy class which handles communication with the database
system at ITU. Through the proxy class, it is possible to import users. This is in order to
avoid repeat-tasks of creating users whose attributes already exist in the current database.
This proxy class may only be relevant while the target system is being phased in.
Students and teachers are connected to courses through the classes StudentCourse and
TeacherCourse. These classes are designed to break down many-to-many relations
between students/teachers and courses into two steps. This makes it possible to precisely
associate a user with a course. The relational classes contain the attributes:
ParticipantList (StudentCourse) and TeacherList (TeacherCourse).
Course-Cluster
All available courses are instances of the class Course. The Course class is linked to the
classes CoursePlan, CourseMessage, and Curriculum. Each of these classes are updated
with information from the course sites when the function Update Information is activated..
The semester object with all associations is destroyed at the end of each semester and a
new is created (with different properties) before the beginning of a new semester.
The course class contains information for the individual courses. Each course has a
number of students and one or more teachers assigned to it. Information about the
courses is gathered and stored in courseinfo and can be retrieved if necessary.
The course class contains the following general attributes:
Students, Teacher, Schedule, Dates.
The courseInfo class contains information about the data entries that are present in the
course sites. This class is used to access the correct information from the course sites and
make it available to users linked to a specific course.
The courseInfo class contains the following general attributes:
Course URL, Literature, Examination Dates, CourseChanges, Messages.
Calendar-Cluster
A calendar is composed of a Semester, which is composed of Course and DateTime.
DateTime can have the role Class, Other or Free.
The Calendar class is composed of DateTime. It is related to one or more users and each
user have a single calendar object. The Calendar class is used to gather the courses and
associate them to a specific time and date.
12
The calendar class contains the following general attributes:
Date/Month/Year, Events, Notes
A semester consists of a number of courses. Each course has a number of students and
one or more teachers assigned to it. Information about the courses is gathered from an
external database using a proxy class. The information from the course sites are imported
from the external course sites to a class in the system.
The semester class contains the following general attributes:
Year, Courses
DateTime is in this system considered a super class for Class, Other and Free. Other can
be used to extend the calendar to manage additional information other than courses, but
will not be specified further in the first implementation of the system. A given timeslot in the
Calendar can be occupied by a course, by another activity or it can be free. If a timeslot is
not occupied by Class or Other it defaults to Free.
The Datetime contains information about the date and time. Each course is assigned to a
specific time and date. It has the attributes:
Date, Time,
The Other class is included to allow for various non-course entries e.g. to allow users to
add their own custom entries in the calendar and has the following attributes:
Notes
13
Class Diagram
1
1..* Calendar
Users Course 1..* Calendar
-Date/Month/Year
-Events
1 Course -Notes
User
-Course Title
-Cpr
-ECTS
ProxyUser -Firstname
-Description 1
-Surname 1
-CoursePlan 1 1..*
-Address
-URL
-Email
-PhoneNr Semester
1 -Courses
0..* 1 -Year
1
Curriculum 1
-Title 1 1..*
-Author
Student -Pages DateTime
Administrat StudentCourse 0..*
Teacher -ISBN -Date
ion -StudentID 0..* 1
-ParticipantList -Time
-StaffID -StaffID -Marks
-Rights -Rights -Rights
-StudyLine CourseChange
-ClassRoomNr
-Reason
1 0..*
TeacherCourse 0..* Lecture Free Other
CourseMessage -Location -Notes
-TeacherList
-Title 1..*
0..*
-Subject
0..*
14
Behavioral Patterns
Statechart diagram is essential for describing the general behaviour of all objects in a specific class
in the target system which contains different states and transitions between them.
An overview and a description of the statecharts below:
Student/ Teacher class
Admin class
Student/Teacher Relation class
Course class
Calendar class
The behavioral pattern for the student/Teacher class describes all possible event traces for this
class.
Teacher /Student class
/ importUser,
/ ,courseJoined / loggedIn
/ courseRequested
/ userCreated / userActivated / semesterStarted
createNewProfile userActive
offline online
/ ,courseLeft
/ courseLeft,
/ userEdited / loggedOut
/ semesterEnded
/ userTerminated
The Student and Teacher class share the same statechart since they are very similar to each other.
The only difference is that a teacher cannot request a course while students would be able to do so.
A user is created which basically means that a student is enrolled at ITU. The next step is to create a
new profile for the newly enrolled student. The new profile creation process leaves two choices
15
either the data can be entered for the new student (userEdited) or the user can be imported from an
external database.
The student has now been created in the target system with all the necessary information i.e. name,
address, studyline, courses etc. and is ready to start a semester at ITU and thereby is an active user
in the target system.
The student/ teacher are to be considered created in the target system when in the state userActive.
The Student/teacher can either choose to join or leave courses. Then the semesterStarted event
occurs and the student/teacher can now start a semester. This leads the student/teacher can go from
offline to online and is in the target system considered logged in where the student can either choose
to log out or continue to stay logged in and decide whether or not to see the requested courses or
leave a course.
The offline and online states eventually leads to the event semesterEnded because when a semester
ends the semesterEnded event occurs and the student/teacher are back in the userActive state and
waiting for the new semester to start.
The behavioral pattern for the admin class describes all possible event traces for this particular
class.
Admin class
userActive
/ importUser, / loggedIn
/ userCreated / userActivated
createNewProfile offline online
/ loggedOut
/ userEdited
/ userTerminated
A user is created which basically means that an administrative staff member has been employed at
ITU. The next step is to create a new profile for the newly employed member of the administrative
staff. The new profile creation process leaves two choices either the data can be entered for the new
employee (userEdited) or the admin user can be imported from an external database.
The admin staff employee has now been created in the target system with all the necessary
information i.e. name, address and phone nr. etc. and is ready to start there employment at ITU and
thereby is an active user in the target system.
16
The admin staff employee is to be considered created in the target system when in the state
userActive.
The transition userActivated occurs which leads the admin staff employee to the offline or online
state and is in the target system considered logged in. The admin staff employee can either choose to
log out or continue to stay logged in.
The behavioral pattern for the course class describes all possible event traces for this particular
class.
Course class
/ courseCreated / semesterStarted / semesterEnded
courseAvailable courseActive
A course is created leads either the user student and/or teacher to the state courseAvailable. When
a course is available a student or teacher can sign onto to the desired courses. Then a
semesterStarted transition occurs which indicates that a given semester is started and the desired
courses are active. The student or teacher can now proceed from the state courseActive to the
semesterEnded which means that a semester has ended therefore the courses in the semester also
comes to an end.
The behavioral pattern for the student/teacher relation class describes all possible event traces for
this particular class.
Student /Teacher Relation
Class
/ semesterStarted / semesterEnded
userActive
The student/ teacher relation class is rather simple.
A semester is started for a student or a teacher then the user is active in the userActive state and
continues to semester ended when a given semester ends.
17
The behavioral pattern for the calendar class describes all possible event traces for this particular
class.
The calendar class is initiated when a user is created and is active in the target system.
Calendar class
/ Course Left / messagePosted
/ coursePlanChanged
/ Course Joined
/ userActivated / userTerminated
courseAvailable
/ semesterEnded / semesterStartedcurriculumUpdated
/
The statechart starts with a user (student or teacher) is activated and continues to the
courseAvailable state. Multiple transitions are available from this state.
The student/ teacher can start a semester followed by the user can join or leave one or more
courses.
Furthermore the student/teacher can post a message, the course plan can be changed, curriculum
can be updated all the updated information will be viewable and available in a message pane and or
the calendar.
This leads to semesterEnded where the next step is the user is terminated and the user is brought
back to the beginning (userActivated).
18
Events
User
Curric Cour Coursem Stud Teac Ad Seme Cou Stud Teac Calen Oth Date/
ulum se esage ent her min ster rse ent her dar er Time
Cha Cour Cour
nge se se
User X X X X
Created
Import X X X X
User
User X X X
Edited
User X X X X X
Terminated
Logged In X X X
Logged X X X
Out
Course X X X X X X X
Joined
Course X X X X X X X
Left
Semester X X X X X X
Started
Semester X X X X X X
Ended
X X X
CoursePla
n Changed
Message X X X
Posted
Curriculum X X
Updated
courseReq X
uested
userActivat X X X X
ed
19
Application Domain
Actors and Use-Cases
Actors Student Teacher Admin
Use Cases
Create User X
Edit User X
Delete User X
Import User X
Create Course X X
Edit Course Description X X
Delete Course X
View Calendar X X (X?)
Figure 2: Actor table
Actor Descriptions
User: Student
Goal: A person who is a student at ITU and owns a login/password for my.ITU. The
student needs my.ITU to keep track of weekly schedule and join courses.
Characteristic: The system's users include many students. These will be of varying
experience and sophistication.
User: Teacher
Goal: A person who teaches at ITU and owns a login/password for my.ITU. The teacher
needs my.ITU to keep track of weekly schedule and edit course descriptions for courses
she teaches.
Characteristic: The system's users will include a good deal of teachers. These might
generally be more interested in using my.ITU for maintaining their course(s) in the Course
Base and as a tool to communicate changes to course plans to students.
20
User: Administration
Goal: A person who works in the administration at ITU and owns a login/password for
my.ITU. Administration uses my.ITU to create profiles for new students and staff (teacher
and administration) – either through manual creation or importation – and delete profiles of
old ones. Moreover, administration creates and deletes courses in the Course Base.
Characteristic: Administration is the smallest segment of the system's users. These use
my.ITU for purely administrative purposes.
Use-Case Specifications
An overview of the actors and use-cases described below.
Actors:
Student
Teachers
Administration Staff
Use Cases:
Create User
Edit User
Delete User
Import User
Create Course
Delete Course
Edit course description
View Calendar
User Management Use Cases
NOTE: Use Cases could be extended to include Objects and Functions!
Create User
Use-case: Create user is initiated by the administration staff after a
successful login where the admin staff can create a user in the target
system if necessary.
21
Create user is in close collaboration with other functions like for
example edit, delete and import user.
Table 1: Use Case specification for “Create User”
Edit User
The edit user function is intended for the administration staff to edit a
specific existing user in the target system. if necessary rather than re-
entering all the data. For example if a user chooses to switch
studyline at the university the administration staff can easily edit the
user’s profile and have the update information available.
In short this function makes it easier for the staff to maintain the users
that already are registered in the previous system.
Table 2: Use Case specification for “Edit User”
Delete User
The delete user function is also only available for the administration
staff. For example if a user decides to drop out, the function permits
the administration staff to delete the user from the target system.
Table 3: Use Case specification for “Delete User”
Import User
The import user function is also initiated by the administration staff
and allows the staff to import a user. Basically this function allows the
administration staff to import all the necessary data on a given user
from the existing system (external database).
Table 4: Use Case specification for “Delete User”
The administration staff has all the necessary functions available to create, edit, delete and
import a user into the target system.
Course Management Use Cases
Create Course
Use-case: The administration staff manages the creation of courses.
The subtask for this function is to assign teachers and students,
22
manage cancellations and adding information to the newly created
course.
Tabel 5: Use Case specification for “Create Course”
Edit Course
Edit Course Description: The administration staff can edit the
course description so it is always updated and matches the current
course criteria.
Table 5: Use Case specification for “Edit Course”
Delete Course
Delete Course: The administration staff can delete a course if
necessary and re assign the student and teachers. Courses are
based on certain criterion
Table 6: Use Case specification for “Delete Course”
View Calendar
This function is initiated by the user Student when logging into my.ITU
and upon successful login, the calendar is shown on the main site.
Then the user profile is checked for associations to the student’s
current courses, and the relevant course site databases are queried
to return any new or edited items. The result is interpreted by the
target system and used to fill the calendar and message pane with
content.
The calendar is updated and showing all the necessary information
relevant for the student at the main site.
Table 7: Use Case specification for “View Calendar”
23
Functions
The following list outlines the main functions that the system will support.
The decisive factor for defining the complexity of the functions is the number of involved
objects.
User Management Complex Update
(Student, Teacher,
Administrative)
Import Existing Medium Update
User
Create New Medium Update
User Medium Update
Edit User Simple Update
Delete User
Course Management Complex Update
Create New Medium Update
Course
Edit Course Medium Update
Delete Course Simple Update
System Update Complex Signal
Make Calendar / Medium Compute
(calendar viewed?)
Join Course Simple Update
Leave Course Simple Update
Request Course Simple Update
Figure XX: Main functions in the system.
Update is used for all functions asking for existing information without any additional
processing of the data whereas Compute is used for all functions that require additional
processing of the data. Computes will not result in changes in the models state (Updates
will…)
The system currently has three complex functions. The User and Course management
have been represented in a hierarchical list to specify these further.
The System Update function is a pure system activity that performs a series of requests in
an external system and imports data to the target system depending on the outcome. The
following bit of pseudo code illustrates the main activities performed by this function.
24
___
Query course sites;
Select entries with timeStamp > lastCheckedTimestamp;
If updates found Import Data;
Result Objects of course information fulfilling criteria;
___
Other than these three functions the system functionalities are fairly self explanatory and
simple.
25
User Interface
Based on the main results from the problem domain analysis, functional requirements and in
particular the use cases the following design for the interface has been selected. Even though care
has been taken to include the users in the various subacvtivities that have led to this interface it
should if possible undergo additional user testing to ensure the usability of the system.
The system interface will resemble the existing myITU site in many aspects but will be adding
additional windows to support new functionalities. Also, some windows will be extended to include
additional information but with no changes to functionality.
Following the current standard for ITU, the application interface will be available in both English
and Danish versions.
Since the systems main purpose for the administrative users is to help manage courses and users on
a daily basis the main focus in this respect is to support efficiency and reliability. However, the
main goal for the students will be to gain easy access to relevant information and as such the
usability will be a key requirement for the interface.
Dialogue Style
While the part of the system that displays the Calendar is integrated in the existing myITU
webinterface, and as such best can be described as menu-selection, the course and user
management part of the system will be based on form fill-in. This approach is chosen
since the main users, who will be adding to the system (Teachers and Administrators) will
be using the system frequently for all course and user management procedures.
Using form fill-in is very well suited for frequent users and efficiently supports the task of
adding data. On the downside this approach takes up a lot of screen estate, - however,
since the screens based on this approach will only be available in certain parts of the
system and only to the relevant users this is not considered critical. The main reason for
choosing form fill-in over menu selection for the course and user management is to avoid
slowing down the workflow. Also, we anticipate that the frequent users of these
functionalities would quickly familiarize themselves with the various options and would not
need the aided menu navigation.
In addition to the form based dialog style we considered adding a command based
interface for the administrators but decided that the nature of the task made it more
intuitive to use the forms. However, should user tests prove that this is a desired
functionality it could be implemented to facilitate quicker data entry for the power users of
the system.
In the first implementation it has been decided that direct manipulation will not be
implemented. As described it may after a second iteration be decided that users should be
allowed to add information to the Calendar using the Other class. If this is implemented
using direct manipulation would be very well suited to allow users to click part of the
calendar to add a new event. This may of course be difficult to implement (and thus
26
expensive) but it is also very likely to be a functionality that would be very intuitive and
usable and could be a unique selling point that would ensure user acceptance
Windows Functionalities
Main Create New User
User Management Import User
Course Management Delete User
Calendar Edit User
Create New Course
Edit Course
Delete Course
Figure 1 Complete list of user interface elements.
Figure 2 outlines the interface elements that are relevant for the system. The amount of elements is
defined by the fact that the system is a web based solution mainly aimed at presenting information
in a browser. As such the interface elements are very closely tied to the functions that have been
identified for the system.
Overview
The outlined architecture in figure 1 provides an overview of the architecture in the system interface
windows. The main purpose of the navigation hierarchy is to illustrate how the individual windows
and functionalities are connected.
27
Interface description
An overview and descriptions of the my.ITU interface designs below:
my.ITU – Main site interface design (student/teacher)
my.ITU – Calendar View interface design
my.ITU – Admin main site interface design
my.ITU – Course Management interface design
my.ITU - Main site interface design (student/teacher)
Upon successful login to my.ITU the user (student or teacher) is presented to the main my.ITU site.
The main site contains four clusters: my.ITU, Other ITU links, Calendar – new messages and
Personnel Roster. All containing different types of information relevant to the user.
The user can use tabs to navigate around
the my.ITU site. The orange tab is where
the user currently is.
Below the tabs panel the ITU events are
placed where the more general
information and happening are posted.
Different links which are
relevant to the user.
Contains other links that might be
relevant for the user, particularly
the student user.
The user can skip to
following weeks or
previous weeks
Allows the user to easily and
efficiently find a student,
employee or alumnae.
A calendar which keeps track of the user’s
(student’s) courses and
Above the calendar, new messages are placed.
These messages are first and foremost intended The button Calendar View will take the user to a
for the urgent and eminent messages such as bigger, more detailed view of the calendar.
project deadlines, exam dates etc. Same as clicking the My Calendar tab above.
28
my.ITU – Admin main site interface design
Upon successful login to my.ITU the admin user is presented to the main my.ITU site intended for
admin staff only.
The main site for the admin staff is almost identical to the my.ITU site for the student/teachers
users.
The “My study activities” tab has
been removed because the admin staff
has no relation to this function.
The links Course management and
User management has been added.
These two links are vital for the admin
staff. Clicking these will take the user
to User and Course Management
respectively.
If there are no new messages,
the message pane is minimized.
29
my.ITU – Calendar View interface design
The user can navigate from the main site to the calendar site using the “my calendar” tab from the
tabs panel placed on the main site.
The ITU Events panel on
top of the is still showing.
The message pane
The calendar weeks are
showing (in this case week
51) where the user has the
option to navigate to any
desired week.
The calendar shows a 7 day
overview with the left side
containing time slots the user
can fill out if necessary
30
my.ITU - Course Management interface design
The course management site is intended for the admin staff where they can manage the different
courses by creating, editing or deleting if required.
The admin staff can navigate from the main site to the course management site using the “course
management” link.
The admin staff has a couple of options; the first
option being, to enter the intended course name
in the search field and finding the given course,
or the second option being to use the drop down
menu beside the search field and narrowing the
search by “course name”, ”Day of week” or
“Study line”. The third option is to manually
find the course from the list.
On the right side of the
screen the description of the
chosen course is shown.
At the bottom of the site there
are three buttons: “New
Course”, “Edit Course” and
“Delete Course”.
31
Figure 2 Navigation Diagram
As illustrated in the overview the User, Course and Calendar class are used as windows in the
system. User and Course can be perceived as generalizations for the underlying windows that all
contain subsets of information related to the main task.
The calendar class contains provides an aggregated view of the individual timeslots containing the
lectures for the current semester similar to the way the classes are connected in our data model.
The detailed design of the windows is described further in the following section where examples of
the application interfaces are described.
Interface Examples
In addition to the main window in the system there will be the main windows in our system are
based on the following classes:
User
Calendar
Course
32
We have made sure that the interfaces design builds on the existing structure in the old my.ITU
version. Also, the interfaces contain short and concise text that helps the users navigate the various
functionalities in each window.
Technical Platform:
The system will be based on navigation in application windows in a web browser.
Information is gathered from and stored in sql DB’s.
33
Design Document
Task
Purpose
Corrections to Analysis
Quality Goals
Below the figure XX shows the priority of design criteria. As mentioned in the interface section, the
main priorities for the system to support the anticipated user needs is to ensure usability, efficiency
and reliability. The design of the interface is focused on ensuring these requirements but is also
supported by the availability of functions that correspond to the actual user needs.
Since the system will be handling personal information for all users the security of the system is
also considered to be important as is the correctness and reliability of the system.
Criterion Very Important Less important Irrelevant Easily Fulfilled
important
Usable X
Secure X
Efficient X
Correct X
Reliable X
Maintainable X
Testable X
Flexible X
Comprehensible X
Reusable X
Portable X
Interoperable X
Figure XX: Priority of design criteria
Comprehensibility has been marked as easily fulfilled since the target system is based on an already
existing system and user, therefore, should have a good understanding of the system. Portability is,
at the current stage, considered to be irrelevant. All the other characteristics have been prioritized as
less important.
Technical Platform
Equipment
The following represents the standard requirements for implementation of the target system.
The system was designed for and developed on PCs, therefore the PCs must be powerful enough to
run the latest version of the most widely used operating system.
34
System Software
CHRISTIAN SKRIV NOGET!!!::: System software is any computer software which manages and
controls computer hardware so that application software can perform a task. Operating systems,
such as Microsoft Windows, Mac OS X or Linux, are prominent examples of system software.
System Interfaces
Beside the recommended PCs, the system requires a printer. It is also recommended that the
operating system handles the interface to the printer.
Design Language
The design document is base on the UML notation.
Architecture
Component Architecture
As illustrated in figure XX the architecture for the system is based on a centralized pattern. This
model has been chosen since the system will be web based using a single server to actually contain
the core application and allowing one or more clients to access the application remotely.
This approach allows users to access the system from basically any pc with a standard web browser
which is critical for the systems users.
35
Client:
>
User Interface
>
System Interface
Server:
> >
User Interface System Interface
>
System Interface
>
Database
Figure XX: Centralized client server architecture used in the system.
Process Architecture
As mentioned the system core will be situated on a single server so sharing of resources on the same
processor will be limited and will be managed by the server system so should not result in conflicts.
Since the system allows multiple users to access the system simultaneously there may be situations
where components on the server will be shared. Again control of these concurrent activities will be
handled by the server.
Standards
The system is as mentioned web based and will be displayable in various browsers. As such it is
based on is and supports the most recent WC3 standards.
Model Component
36
The model and function components are treated as one in the design since all functions are handled
as operations for the classes in the model component.
Structure
As illustrated in figure XX we made a few changes to the class diagram from the analysis
document.
Based on a revision of the events the event courseRequested was promoted to a class. This private
event was used to add courses to an attribute in the student class through iteration. For the events
“Semester Started” and “Semester Ended” it was necessary to add the attributes StartDate and
EndDate to the Semester class in the class diagram.
Based on a revision of the functions we added a class for the function System Update. This class is
used to manage the check of the information from the external course sites. The class contains the
attributes Time and Time Stamp, both used to control when the next update should occur.
To simply the system and make it easier to manage we decided that the system could be
restructured by combining the three classes Curriculum, CourseChange and CourseMessage in a
single class called CourseChange. This class serves as a form for generalization for the previous
classes and contains the following three attributes: ChangeType, Content and DateOfExpiration.
Implementing this class with generic attributes provides a better overview of the design and makes
it easier to implement the system.
1
1..* Course Calendar Calendar
Users
1 -Date/Month/Year
UpdateControl -Events
User -Time +createNew()
Course
-TimeStamp 0..* 1..* +assignRole()
-Cpr -Course Title
ProxyUser -Firstname +performUpdate()
-ECTS 1..*
1
-Surname +signalCourses()
1 -Description
-Address -CoursePlan
-Email Semester
1 -CourseState
-Phone# -URL -Year
1
+createNew() +createNew() 1 -StartDate
+AssignRole() +edit() -EndDate
+createNewChange() +createNew()
+setState() 1 +start()
+end()
1..*
1
0..*
Student DateTime
Administration Teacher -StudentID CourseChange -Date
1 0..*StudentCourse 0..*
-StaffID -Marks -ChangeType -Time
-StaffID
-Rights -Rights -ParticipantList -Content +createNew()
-Rights
-StudyLine +printList() -DateOfExpiration
+createNew() +createNew()
+createNew() +createNew()
+requestCourse() +specifyType()
1
1 0..* Lecture Free Other
TeacherCourse
-ParticipantList -Location -Notes
0..* +printList() 1..*
0..*
CourseRequest
-courseRequestList
Figure XX: Updated class diagram. CourseChange has been created as a generalization of three
existing classes to simplify the diagram. Based on a revision of the events, the UpdateControl class
was added.
37
Classes
Below is our specification of classes that contain essential attributes and/or non-trivial operations.
User
Purpose: Register users of the target system.
Attributes: Cpr, firstname, surname, address, email phonenr.
Operations: Create new, assign role (create administration, create teacher, create student)
Course
Purpose: Register available courses in the target system
Attributes. Course Title, ECTS, description, courseplan, URL
Operations: Create new course, create new courseChange
Calendar
Purpose: Keeps track of date, month and year. Associate objects from Lecture, Free and Other to a
dateTime.
Attributes:
Operations: create new dateTime, specify dateTime role, change dateTime role.
UpdateControl
Purpose: To update the system at regular intervals.
Attributes: Time, timestamp
Operations: perform update, signal courses
38
Operation: Perform Update
Category: X Active _ Compute
_ Passive _ Read
X Signal
_ Update
Purpose: To check all course sites for updates. If updates are found, a
signal is sent to the relevant course object(s). Check is executed
every 15 minutes.
Input Data: Course URL.
Condition: There must be at least one active course object in the model. 15
minutes must have passed on the system clock since last check.
Effect: Calendar and course is updated with new change-objects.
Algorithm: All course objects in the state active are traversed and the URL
attribute is read. An external database is queried to return entries
created in between 'now' and the last timestamp. If any entries
are returned a signal is sent. Content of returned queries is
passed to the 'create new' operation in courseChange/Message.
All courseChange/Message objects are traversed, outdated ones
are destroyed. The timestamp attribute is updated.
Placement: UpdateControl.
Involved objects: Course, calendar, courseChange.
User Interface Component
> Print
> User Interface
> Print > Print
Main Edit User User.List
Window
39
User Course
Managem Managem Course.Li
ent ent st
Recommendations
Systems Usefulness
Plan for Use
Implementation Plan
40