Purpose: settings, miljøet det nye system skal indgå i

gasownerΔιαχείριση Δεδομένων

31 Ιαν 2013 (πριν από 4 χρόνια και 6 μήνες)

209 εμφανίσεις


1


my.ITU


The Next Iteration

Object Oriented Analysis and Design




2






Contents





Introduction

................................
................................
................................
................................
.......................

4

The Task

................................
................................
................................
................................
........................

4

Purpose

................................
................................
................................
................................
..........................

4

System Definition

................................
................................
................................
................................
..........

5

Context

................................
................................
................................
................................
..........................

6

Problem Domain

................................
................................
................................
................................
............

7

Application Domain

................................
................................
................................
................................
......

8

The Problem Domain

................................
................................
................................
................................
........

9

Clusters and Classes

................................
................................
................................
................................
......

9

Class Diagram

................................
................................
................................
................................
.............

12

Behavioral Patterns

................................
................................
................................
................................
......

12

Events

................................
................................
................................
................................
..........................

16

Application Domain

................................
................................
................................
................................
.........

17

Actors and Use
-
Cases

................................
................................
................................
................................
..

17

Function
s

................................
................................
................................
................................
.....................

21

User Interface

................................
................................
................................
................................
..............

22

Design Document

................................
................................
................................
................................
............

29

Task

................................
................................
................................
................................
.............................

29

Technical Platform

................................
................................
................................
................................
......

30

Architecture

................................
................................
................................
................................
.................

31

Model Component

................................
................................
................................
................................
.......

32

Recommendations

................................
................................
................................
................................
.......

36







3


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 captions to all figures.



NOTE: Use Cases could be extended to include Objects and Functions!




4


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
.

but suggestions for improvements to the syste
m will be presented

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 i
n 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 i
ntroduce 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 suc
h

the system should be perceived as
the
next iteration of a system alread
y 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 we
ll as providing a host of links to various
relevant websites on the intra
-

and
I
nternet (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 referre
d 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 ab
out 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 f
eature 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 o
n which information is
deemed relevant or irrelevant.
The already existing v
aluable 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, we expect a
high level of IT experience from the users of our system as well as an environment where net access
is pervasive.


5


The target system wil
l 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 w
ill 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 commun
ication 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 accessibl
e 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 whic
h 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 th
e system.


Conditions

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 a
ssume that users are already familiar with such interfaces.


6



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 ce
ntralized 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.

Context

Rich Picture



7


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 m
anage 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, tea
chers 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 informatio
n.

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. 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 pertaini
ng 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
bookma
rks, 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 a
re enrolled in one or more courses (receive information from the courses they are
associated with).



Teachers teaching on
e

or more courses can change
and
add information for the
ir active
courses in
the Course Base
.

As mentioned, changes to course plans occu
r 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).


8


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 iter
ations 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 cour
se 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.



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, liter
ature 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 mess
ages 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 sy
stem 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 plan
s 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 li
sts, 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
ma
triculation.


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 manage
ment.


9




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 in
formation based on the course associations of students



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.




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.















Figure 1
: The essential tasks
in the system’s application domain

The Problem Domain





Clusters and Classes



As illustrated in the figures below there are
three

main clusters of
classes relevant for the system:






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

C
alendar
.



These clusters and various classes are described in the
following section.


User
-
Cluster

At ITU, people can have different roles:
Student
,
T
eacher

or
Administrative S
taff
. However,
people also share attributes which are relevant to ITU and to the target system. These are properties
such as name, date of birth/c
pr
-
number, address and other contact information. Hence, the
User

class is a generalization of the three subclasses
Student
,
Teacher

and
Administration
.

Users (Role
pattern)

Courses


Calendar


10


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 fol
lowing 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 ha
ve the following additional attributes:


Study
Line, Grades, Student
ID
,

Staff
ID,

and

Rights
.


Student and Teachers are assigned to one or more courses and semesters while the administrative

users have no specific affiliation.

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/tea
chers 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 a
ctivated..

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
.



11


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.

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 timesl
ot 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
ti
me 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




12


Class Diagram

Users
-
Date
/
Month
/
Year
-
Events
-
Notes
Calendar
-
Courses
-
Year
Semester
-
Date
-
Time
DateTime
1
1
..*
-
Cpr
-
Firstname
-
Surname
-
Address
-
Email
-
PhoneNr
User
0
..*
1
-
StaffID
-
Rights
Administrat
ion
ProxyUser
-
TeacherList
TeacherCourse
-
ParticipantList
StudentCourse
0
..*
1
-
Notes
Other
0
..*
1
Course
1
1
..*
Calendar
1
..*
1
1
1
..*
0
..*
1
1
1
..*
Free
-
Title
-
Author
-
Pages
-
ISBN
Curriculum
-
ClassRoomNr
-
Reason
CourseChange
-
Title
-
Subject
CourseMessage
0
..*
1
0
..*
1
0
..*
1
-
Course Title
-
ECTS
-
Description
-
CoursePlan
-
URL
Course
-
Location
Lecture
-
StudentID
-
Marks
-
Rights
-
StudyLine
Student
-
StaffID
-
Rights
Teacher



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 cl
ass



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

13


class.




The Student and Teacher class
share the same statechart since they
are

very similar to each other
.
T
he only d
ifference is that a teacher can
not request a course

while st
udents 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
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 ca
n 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

state
s eventually leads to the event
semesterEnded

because w
hen 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.








offline
online
/
userCreated
/
userTerminated
createNewProfile
/
semesterStarted
/
loggedIn
/
loggedOut
/
userEdited
userActive
/
,
courseLeft
/
,
courseJoined
Teacher
/
Student class
/
importUser
,
/
courseRequested
/
courseLeft
,
/
semesterEnded
/
userActivated

14


The behavioral pattern for the
admin class

describes all possible event traces for this particular
class.


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 administra
tive
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 syste
m 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.


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.



/
userCreated
/
userTerminated
Admin class
offline
online
/
loggedIn
/
loggedOut
createNewProfile
/
userEdited
/
importUser
,
/
userActivated
userActive
courseAvailable
courseActive
/
semesterStarted
/
courseCreated
Course class
/
semesterEnded

15



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 fro
m 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 par
ticular class.





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.



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.






userActive
/
semesterEnded
/
semesterStarted
Student
/
Teacher Relation
Class
/
userActivated
Calendar class
/
userTerminated
/
Course Joined
/
Course Left
/
semesterStarted
/
semesterEnded
/
coursePlanChanged
/
messagePosted
/
curriculumUpdated
courseAvailable

16


The statechart starts with a

user (student or teac
her) 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
-
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 broug
ht
back to the beginning (
userActivated
).


Event
s



User




Curricul
um

Cour
se
Chan
ge

Courseme
sage

Stud
ent

Teac
her


Adm
in

Semes
ter

Cour
se

Stud
ent

Cour
se

Teac
her

Cour
se

Calen
dar

Oth
er

Date/Ti
me

User
Created




X

X

X






X


Import User




X

X

X






X


User Edited




X

X

X








User

Terminated




X

X

X





X

X


Logged In









X

X


X


Logged Out









X

X


X


Course
Joined




X

X


X

X

X

X

X



Course

Left




X

X


X

X

X

X

X



Semester
Started




X

X


X

X



X


X

Semester
Ended




X

X


X

X



X


X

CoursePlan
Changed


X






X



X



Message
Posted



X


X






X



Curriculum
Updated

X










X



courseRequ
ested




X










userActivat
ed




X

X

X





X




17


Application Domain

Actors and Use
-
Cases


Actors





Use Cases

Student

Teacher

Admin

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 t
eachers. 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.


User: Administration

Goal:
A person who works in the administration at
ITU and owns a login/password for my.ITU.

18


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 crea
tes 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 b
elow.


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



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.

Create user is in close collaboration with other functions like for example
edit, delete and import u
ser
.



19


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 eas
ier 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, manage
cancellations and adding information to the newly created course.



20


Tabel 5: Use Case specification for “Create Cou
rse”


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
牥汥癡湴nc潵牳o 獩se 摡瑡扡獥猠a牥 煵e物r搠瑯 牥瑵牮rany ne眠潲 e摩de搠
楴e浳⸠
周q 牥獵汴 楳i楮ie牰牥瑥搠by 瑨t 瑡tge琠sy獴敭sa湤n畳u搠瑯t晩汬f瑨攠ca汥湤lr a湤n
浥獳m来⁰ ne⁷楴栠捯湴 湴n

周q ca汥湤lr 楳i異摡瑥t a湤n獨潷楮g a汬 瑨e 湥ce獳慲y 楮景i浡瑩潮m牥汥la湴
景f⁴桥⁳瑵摥湴⁡琠瑨攠浡i渠獩瑥t


Table 7: Use Case specificatio
n for “View Calendar”








21


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
(Student, Teacher,
Administrative)



Import Existing
User



Create New User



Edit User



Delete User

Complex





Medium




Medium



Medium



Simple

Update





Update




Update



Update



Update

Course Management



Create New
Course



Edit Course



Delete Course

Complex



Medium




Medium



Simple

Update



Update




Update



Update

System Update

Complex

Signal

Make Calendar /
(calendar viewed?)

Medium

Compute




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…)


T
he 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.


___


Query course sites;


22



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.


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 f
unctionalities. 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
-
select
ion
, 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 downs
ide 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 f
ill
-
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 a
ided m
e
nu 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.



23


In the first implementation it has been decided that direct manipulation will not be implemented. As
described it may
after a secon
d 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 m
ay of course
be difficult to implement (and thus 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
U
ser


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 cl
osely tied to the functions that have been
identified for the system.


Overview


The outlined architecture in figure
XX


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.



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.



24



Figure
XX

Navigation Diagram


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



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.




25


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.





Different links
which

are
relevant
to

the user.

Contains other links that might be
relevant for the user, particularly
the student user.



A
llows 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
for the urgent and eminent messages such as
project deadlines, exam dates etc.


The button Calendar View will take the user to a
bigger, more detailed view

of the calendar
.
Same as clicking the My Calendar tab above.

The user can skip to
following
weeks or
previous weeks

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.



26


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 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
respectiv
ely.

The
“My study activities”

tab has
been removed because the admin staff
has no relation to this function.


If there are no new messages,
the message pane is minimized.


27




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.


















T
he
ITU Events

panel on
top of the
is still showing.



The message pane

The calendar shows a 7 day
overview with the left side
containing
time slots the user
can fill out if necessary

The calendar weeks are
showing (in this case
week
51
) where the user has the
option to navigate to any
desired week.


28



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.











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.


T
he 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

be
side 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”
.



29


Recommendations

Systems usefulness and Feasibility

The reasoning for the proposed functionality provided by the target system, is based on user
requirements for improvements to the existing system. This has the advantage that lacking user
acceptance is considered low risk. Also, since the general framework

for a large part of the systems
components is present in the existing system, implementation of the new system should require very
few adjustments to the current technological architecture.

Strategy

Even though the need for the system is based on actual u
ser needs and wishes, the further work on
the project should be formalized by creating a project group to review the results of the analysis and
to manage and validate the further work on the system design.


Development Economy

Following the current analy
sis a design period including user involvement should be commenced.
Testing and data gathering from all user groups can be completed within two months followed by
one month to complete the actual design document in collaboration with the project group.

D
e
sign Document

Task

Purpose

The target system has two main tasks: To present relevant information to users based on their
profiles, and


To support management of existing and new Courses and Users. As such the system
needs to support both the workflow
management for content creation and the correct presentation of
the information. These main purposes have been considered throughout the design document.

Corrections to Analysis

The findings from the analysis document have been revisited and revised where
necessary to better
suit the design and implementation needs. The overall purpose of the class diagram remains the
same but additional classes have been added to ensure support for all events and functions. Also, the
architecture of the class diagram has b
een simplified to facilitate a more efficient implementation
.

The mentioned changes are described in detail in the following sections.


Quality Goals


Below the figure XX shows the priority of design criteria. As mentioned in the interface section, the
mai
n 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 correspo
nd 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
correct
ness
and

reliab
ility of the system.



30




Criterion

Very
important

Important

Less
important

Irrelevant

Easily Fulfilled

Usable

X





Secure


X




Efficient

X





Correct


X




Reliable

X





Maintainable



X



Testable



X



Flexible



X



Comprehensible





X

Reusable


X




Portable




X


Interoperable



X



Figur
e

XX
:
Priority of design criteria


C
omprehensibility

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
. P
ortability

is,
at the current stage, con
sidered to be
irrelevant
.
All the other characteristics have been prioritized as
less important
.


Technical Platform

Equipment

The system will be developed on PC and targeted for web use. The system core will run on the
server side. The system must be
able to withstand heavy traffic and therefore the server should be
tailored to handling many clients at once. Alternatively, we could opt for a model

distributing the traffic on several servers.

As the users at ITU in general use a host of different
operating systems and browser systems, the
system will be tested in many different browser environments; including Internet Explorer, Mozilla

Firefox, Safari, Opera and Konqueror.


System Software

We have chosen to follow the existing my.ITU solution. The
system will be written in Standard
ML, a functional programming language. In order to write dynamic web applications around SML,
we will use the latest release of the SMLserver application which is plugin for the Apache

server.

We are also considering usi
ng
SML.NET
. This would make interoperability with applications
written for Microsoft's .NET and other languages compatible with the Common Language Runtime,
such as C# and Vidual Basic.

We assume the availability

of a Relational Database Management System such as MySql, Oracle or
Postgresql.


System Interfaces

Beside the recommended PCs, the system requires a a network connection. However, we leave the
responsibility for handling the TCP/IP protocol to the server
and the client OS respectively.


31



Design Language

The design document is based 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 u
sers

to access the system from
basically any pc with a standard web browser
which is critical for the systems users.



Figure
XX:
Centralized client server architecture used in the system.





Client
:

<<component>>

User Interface


<<component>>

System Interface



<<component>>

System Interface



Server
:

<<component>>

System Interface



<<component>>

Database



<<component>>

User Interface



32


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


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 comp
onent.


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 oc
cur.



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 sys
tem.



33


Users
1
1
..*
0
..*
1
ProxyUser
0
..*
1
-
Notes
Other
0
..*
1
Course
1
1
..*
Calendar
1
..*
1
1
1
..*
0
..*
1
1
1
..*
Free
0
..*
1
-
Location
Lecture
1
0
..*
+
createNew
()
+
assignRole
()
-
Date
/
Month
/
Year
-
Events
Calendar
+
createNew
()
+
AssignRole
()
-
Cpr
-
Firstname
-
Surname
-
Address
-
Email
-
Phone
#
User
+
createNew
()
-
StaffID
-
Rights
Administration
+
createNew
()
-
StaffID
-
Rights
Teacher
+
createNew
()
+
requestCourse
()
-
StudentID
-
Marks
-
Rights
-
StudyLine
Student
+
performUpdate
()
+
signalCourses
()
-
Time
-
TimeStamp
UpdateControl
+
printList
()
-
ParticipantList
StudentCourse
+
printList
()
-
ParticipantList
TeacherCourse
+
createNew
()
+
specifyType
()
-
ChangeType
-
Content
-
DateOfExpiration
CourseChange
+
createNew
()
+
edit
()
+
createNewChange
()
+
setState
()
-
Course Title
-
ECTS
-
Description
-
CoursePlan
-
CourseState
-
URL
Course
+
createNew
()
+
start
()
+
end
()
-
Year
-
StartDate
-
EndDate
Semester
+
createNew
()
-
Date
-
Time
DateTime
-
courseRequestList
CourseRequest
1
0
..*
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.



Classes

The following section describes the 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 rol
e (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



34


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







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 l
ast 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:

Co
urse, calendar, courseChange.



35


User Interface Component


The screens and print elements are gathered in the interface component as illustrated in
figure
XX
.
The
primary
responsibility of the
main window is the
to present information

while the additional
windows are used for user and course management. The print options are used in relation to the
course
and user management and provide

a means for creating a physical print of the various lists
that are available.






<<component>> User Interface


User.List

Course.Li
st

<<component>> Print


Main
Window

User
Managem
ent

New User

Edit User

Course
Managem
ent

New
Course

<<component>>

Windows

Import
User

Edit
Course

Calendar
View


36



Recommendations


Systems Usefulness

The outlined system design aims at meeting the outlined quality goals by providing relevant
functionalities according to work tasks. While, the personalized and targeted display of
information
should ensure that users will
perceive the displayed information to be usable additional user testing
should be performed following the first implementation of the system.


Plan for Use

Since the system is based on existing technology the
system should be presented as an update to the
current system. The main change in functionalities will be concern the Administrative staff and to
some extent the teachers and training sessions should be provided for these users.

The system will be part of
the ITU information architecture and technical management and
maintenance should be placed under the IT department. Responsibility for content and data
maintenance will be placed under the head of administration.

Impl
e
mentation Plan

The actual implementati
on is closely tied to the existing solution and should be undertaken in
collaboration with the manager of the current system.
After Following the implementation the
system should undergo a series of user tests and based on the results of these be
modified
to best
suit the user needs.