Get documents about "OOAD_whole_AllElementsPresent
Document Sample
my.ITU – The Next Iteration
Object Oriented Analysis and Design
1
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
Functions ..................................................................................................................................................... 21
User Interface .............................................................................................................................................. 22
Design Document ............................................................................................................................................ 29
Task ............................................................................................................................................................. 29
Technical Platform ...................................................................................................................................... 30
Architecture ................................................................................................................................................. 31
Model Component ....................................................................................................................................... 32
Recommendations ....................................................................................................................................... 36
2
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!
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. but suggestions for improvements to the system 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 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, we expect a
high level of IT experience from the users of our system as well as an environment where net access
is pervasive.
4
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
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.
5
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.
Context
Rich Picture
6
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. 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).
7
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.
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.
8
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
Present information about in a calendar overview in the students’ my.ITU login
Figure 1: The essential tasks in the system’s application domain
page and general information in a message pane used for course information.
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.
9
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.
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.
10
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 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
11
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..*
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
12
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
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.
13
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.
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
14
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.
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
/
15
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 -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).
Events
User
Curricul Cour Courseme Stud Teac Adm Semes Cour Stud Teac Calen Oth Date/Ti
um se sage ent her in ter se ent her dar er me
Chan Cour Cour
ge se se
User X X X X
Created
Import User X X X X
User Edited X X X
User X X X X X
Terminated
Logged In X X X
Logged Out X X X
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
CoursePlan X X X
Changed
Message X X X
Posted
Curriculum X X
Updated
courseRequ X
ested
userActivat X X X X
ed
16
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.
User: Administration
Goal: A person who works in the administration at ITU and owns a login/password for my.ITU.
17
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
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 user.
18
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, manage
cancellations and adding information to the newly created course.
19
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”
20
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 User Medium Update
Edit User Medium Update
Delete User Simple Update
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.
___
Query course sites;
21
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 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.
22
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 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 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.
23
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.
24
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.
25
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.
26
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
27
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”.
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.
28
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 user 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 analysis 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.
Design 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 been 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
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.
29
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 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 using 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
30
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.
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 users to access the system from basically any pc with a standard web browser
which is critical for the systems users.
Client:
<<component>>
User Interface
<<component>>
System Interface
Server:
<<component>> <<component>>
User Interface System Interface
<<component>>
System Interface
<<component>>
Database
Figure XX: Centralized client server architecture used in the system.
31
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 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.
32
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.
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 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
33
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 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.
34
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
<<component>> Windows <<component>> Print
Main Edit User
User.List
Window
User Course
Managem Managem Course.Li
ent ent st
New User New
Course
Import Edit
User Course
Calendar
View
35
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.
Implementation Plan
The actual implementation 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.
36
