SOFTWARE DESIGN DOCUMENT v1.1
-
Upload
koray-eren -
Category
Documents
-
view
232 -
download
0
Transcript of SOFTWARE DESIGN DOCUMENT v1.1
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
1/52
1
SOFTWARE DESIGN DOCUMENT
for
CONFMAN
v1.1
PREPARED BY
CENGIZOVERBirand Koray EREN
Ahmet Anl PALA
Mustafa YAVUZ
Burak N
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
2/52
2
Table of Contents
PREFACE ........................................................................................................................................ 3
1. INTRODUCTION ........................................................................................................................ 4
1.1 Purpose ....................................................................................................................................... 4
1.2 Scope ...................................................................................................................................... 4
1.3 Overview ................................................................................................................................ 5
1.4 Reference Material ................................................................................................................. 5
1.5 Definitions & Acronyms ........................................................................................................ 5
2. SYSTEM OVERVEW ................................................................................................................ 6
2.1 Design Constraints ................................................................................................................. 7
2.1.1 Performance ..................................................................................................................... 7
2.1.2 Easeness to use ................................................................................................................ 7
2.1.3 Security ............................................................................................................................ 7
3. SYSTEM ARCHITECTURE ....................................................................................................... 9
3.1 Architectural Design ............................................................................................................... 9
3.1.1 Server-Side Design .......................................................................................................... 9
3.1.2 Client-Side Design ......................................................................................................... 12
3.1.3 Server-Client Integration ............................................................................................... 12
3.2 Decomposition Description .................................................................................................. 13
3.2.1 ER DIAGRAM .............................................................................................................. 13
3.2.2 Class Diagram ............................................................................................................... 19
3.2.3 Activity and State Diagrams .......................................................................................... 20
3.3 Design Rationale .................................................................................................................. 33
4. DATA DESIGN ......................................................................................................................... 34
4.1 Data Description ................................................................................................................... 34
4.1.1 User-oriented Classes .................................................................................................... 34
4.1.2 Conference-oriented Classes ......................................................................................... 37
4.2 Data Dictionary .................................................................................................................... 39
4.2.1 Classes ........................................................................................................................... 40
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
3/52
3
4.2.2 Association Classes ....................................................................................................... 41
5. ALGORITHMS .......................................................................................................................... 42
5.1 MD5 Hashing ....................................................................................................................... 42
5.2 Scheduling Algorithm .......................................................................................................... 43
6. HUMAN INTERFACE DESIGN .............................................................................................. 45
6.1 Overview of the User Interfaces ........................................................................................... 45
6.2 Screen Images ....................................................................... Error! Bookmark not defined.
6.2.1 Home Page..................................................................... Error! Bookmark not defined.
6.2.2 Author Panel .................................................................. Error! Bookmark not defined.
6.2.3 Reviewer Panel .............................................................. Error! Bookmark not defined.
6.2.4 Chair Panel .................................................................... Error! Bookmark not defined.
7. CONCLUSION .......................................................................................................................... 51
PREFACE
This document contains design specifications for CONFMAN (Conference Management
and Hosting System). This document has been prepared as an assignment of ComputerEngineering Design course, CENG491. This course aims to make students practice analysis,
requirement specification, design phases of a computer system, issues related to project
design and presentation and engineering ethics. Projects will be inspired from real life
hardware/software problems and students are expected to come up with a professional quality
design solution by applying computer and software engineering methods.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
4/52
4
CHANGE HISTORY
DATE DOCUMENT ID VERSION COMMENT WRITERS
02/12/2012 CENGIZOVER_COFMAN_SDD 1.0 Created CENGIZOVER
17/01/2013 CENGIZOVER_COFMAN_SDD 1.1 Section 3 has
been changed
CENGIZOVER
17/01/2013 CENGIZOVER_COFMAN_SDD 1.1 ALGORITHM
S section has
been added
CENGIZOVER
17/01/2013 CENGIZOVER_COFMAN_SDD 1.1 SCREEN
IMAGES part
has been
updated
CENGIZOVER
1. INTRODUCTION
1.1 Purpose
The purpose of this document is to describe detailed description of CONFMAN. This
document defines details of major software components, expected functionalities of this
system with diagrams.
1.2 Scope
This document gives a detailed description of CONFMAN and the business flow is
described by using related diagrams. CONFMAN will be a conference management system
that manages all administrative and organizational tasks of a conference, including multi-role
authentication, conference rooms presentation scheduling, periodical announcements,
reviewer evaluations, paper submissions, paper reviewer assignments and web page.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
5/52
5
There are some assumptions in the content of the document that will become certain
during the implementation stage.
The key software life cycle product that drives our software design is typically SRS. Our
team wrote the SRS version 1.0 of the CONFMAN that will drive the design and design
constraints to be considered and observed.
1.3 Overview
Section 2 mentions system overview of CONFMAN. Section 3 gives detailed description about the architecture of CONFMAN based on
diagrams.
Section 4 gives detailed description about the data used in CONFMAN. Section 5 describes the human interface design of CONFMAN.
1.4 Reference Material
[1] HTTPServlet Class -
http://docs.oracle.com/javaee/1.4/api/javax/servlet/http/HttpServlet.html
[2] JDBC Basics -http://docs.oracle.com/javase/tutorial/jdbc/basics/index.html
[3] Sencha ExtJS Documentation -http://docs.sencha.com/ext-js/4-1/
[4] SQL Injection - http://www.unixwiz.net/techtips/sql-injection.html
[5] Cross Site Scripting Wiki Page -http://en.wikipedia.org/wiki/Cross-site-scripting
[6] MD5 Wiki Page -http://en.wikipedia.org/wiki/MD5
1.5 Definitions & Acronyms
ACRONYM DEFINITION
CONFMAN Conference Management & Hosting System
IEEE The Institute of Electric & Electronic
Engineers
SRS Software Requirement Specification
METU Middle East Technical University
CENG Computer Engineering
SDD Software Design Document
UI User Interface
http://docs.oracle.com/javaee/1.4/api/javax/servlet/http/HttpServlet.htmlhttp://docs.oracle.com/javaee/1.4/api/javax/servlet/http/HttpServlet.htmlhttp://docs.oracle.com/javase/tutorial/jdbc/basics/index.htmlhttp://docs.oracle.com/javase/tutorial/jdbc/basics/index.htmlhttp://docs.oracle.com/javase/tutorial/jdbc/basics/index.htmlhttp://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://en.wikipedia.org/wiki/MD5http://en.wikipedia.org/wiki/MD5http://en.wikipedia.org/wiki/MD5http://en.wikipedia.org/wiki/MD5http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.sencha.com/ext-js/4-1/http://docs.oracle.com/javase/tutorial/jdbc/basics/index.htmlhttp://docs.oracle.com/javaee/1.4/api/javax/servlet/http/HttpServlet.html -
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
6/52
6
API Application Programming Interface
HTTP HyperText Transfer Protocol
GUI Graphical User Interface
HTML HyperText Markup Language
MVC Model View Controller
JS JavaScript
2. SYSTEM OVERVEW
Our system for CONFMAN will be developed based on MVC design pattern. MVC is an
architecture that separates the representation of information from the user's interaction within.
The central idea behind MVC is code reusability and separation of concerns. MVC can be
broken into three elements:
Model: The Model represents data and the rules that govern access to and updates ofthis data. In enterprise software, a model often serves as a software approximation of
a real-world process
View: The View renders the contents of a Model. It specifies exactly how the Modeldata should be represented. If the Model data changes, the View must update itsrepresentation as needed.
Controller: The Controller translates the user's interactions with the View intoactions that the Model will perform. In a stand - alone GUI client, user interactions
can be button clicks or menu selections. Depending on the context, a Controller may
also select a new View to present back to the user.
Figure 2.1 shows the schema of MVC.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
7/52
7
Figure 2.1 - MVC Schema
2.1 Design Constraints
2.1.1 Performance
* CONFMAN will perform all of the desired functionalities as quick as possible. It has
been estimated that the time to perform functionalities successfully is up to 5 seconds.
* CONFMAN will minimize the database usage to maximize the speed of data
manipulation & data flow. It is expected to have a huge performance boost (up to ten times)
by means of shifting the computation amount from database queries to java run-time
environment.
2.1.2 Easeness to use
* CONFMAN aims to minimize the effort of the user to perform functionality with user-friendly interfaces. In other words, the user will do multiple operations at a time.
2.1.3 Security
Since the privacy is critical in this system, the system should be guarded with strict
security precautions. The followings explain main security issues.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
8/52
8
1. The system should be invulnerable to the SQL injection attacks. In order to preventsystem from SQL injection[4] attacks, inputs should be sanitized well and prepared
statements should be used instead direct concatenation and execution of the SQL
Queries. For more detailed information visit the website [4] in reference section.
2. Cross-Site Scripting (XSS)[5] is another widely used type of attack from themalicious users, which uses scripting language to retrieve private information of the
user registered to the system. Since the client-side of the system will almost
completely be coded be a scripting language, this security concern should be taken
into consideration. For more detailed information visit the website [5] in reference
section.
3. In the system, feedback messages should not give any clue about the system. Anexample illustrates this briefly. For instance, if a malicious user types an invalid
username or password to the login form, System should inform user with message
Invalid username or password or equivalent one. Not inform with a message like
Password is wrong if he enters a valid username but invalid password. Because he
will be able to understand that the user is registered to the system but only the
password is wrong. In the same way, if the typed username is not registered to the
system, system should not give message like Username is not registered to the
system. The attackers should not be able to inference whether username is registered
to the system or not. Clearly, it should simply print the message Invalid username or
password which does not give any clue about the entries in the users table so reduce
the possibility to find usernames or password by brute force.
4. Size and type of any uploaded document should be checked. Malicious user may tryto upload very big sized file in order to damage server or may try to upload an
executable file with Trojan. The restriction on type is not only about the security, it is
also important for consistency in the system. If many types are allowed, reviewers
may not be able to see this papers due to lack of some technical reasons about the type
of the file. Hence, we enforce to users (authors) to upload only few widely used types
of file like pdf, doc.
5. Most of errors should be handled properly and a convenient informative messageshould be presented to the users in the case of error actions. If these are not handled
appropriately, malicious user may try to get information about the database by typing
mistake input to the forms deliberately. For example, there may be some failures on
database actions and if they are not handled, web browser may print some private
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
9/52
9
information about the databases tables which give clue about the system to the
malicious users. Hence, these possibilities should be predicted before coding phase
and dealt with.
3. SYSTEM ARCHITECTURE
3.1 Architectural Design
CONFMAN can be separated into two parts: Server-Side and Client-Side
3.1.1 Server-Side Design
3.1.1.1 Servlet
Servlet is Java-based server-side web technology to extend the capabilities of servers that
host applications hosted by web servers. Although they can communicate over any client-
server protocol, they usually use HTTP protocol. Servlets are used to add dynamic content to
the web server using the Java platform. Figure 3.1 shows the position of servlets in a web
application.
Figure 3.1 the role of servlet in web application
Servlets can perform the tasks below:
1. Read the data sent by the client side. (form)
2. Read implicit HTTP request data sent by the client (cookies)
3. Process data and generate the results (invoking a Web service, talking to the
database)
4. Send the explicit data to the clients in variety of formats(XML, GIF, Excel etc.)
5. Send the implicit HTTP response to the clients (setting cookies)
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
10/52
10
3.1.1.2 Tomcat
To deploy and run a servlet, a web container must be used. A web container is essentially the
component of a web server that interacts with the Servlet. Apache Tomcat is an open source
implementation of Servlet technology and can act as a standalone server to test servlets and canbe integrated with the Apache Web Server.Figure 3.2 shows Java interfaces used to handle requests
from and responses to client side.
Figure 3.2 Requests and Responses in a Web Application
The steps of the life cycle of a servlet can be modified by changing
javax.servlet.http.HttpServlet[1]. Below are the explanations of the methods that we are
going to use to implement servlets.
init - The servlet is initialized by this method.
service - The servlet calls this to process a clients request.
doGet - A GET request results from a normal request for a URL or from an HTML
form
that has no method specified and it should be handled by this method.
doPost - A POST request results from an HTML form that specifically lists POST
as the
METHOD and it should be handled by doPost() method.
destroy - The servlet is terminated by this method.
Figure 3.3 shows the activity diagram for the request-response relationship between client side and the
server side components.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
11/52
11
Figure 3.3 activity diagram for request-response relationship
3.1.1.3 JDBC
JDBC[2] is a Java-based access technology that defines how a client may access a database.
It provides methods to query and update data in a database by using statements. Below are
the components of JDBC.
DriverManager keeps track of all various JDBC implementations that we aredealing with.
Connection stores the information about the database and makes us to handle theStatement objects.
We interact with Statement class to get our queries executed and get theresult.
After a Statement is executed, the results are returned through the ResultSetand allow us to navigate through these results.
JDBC API is shown at Figure 3.4
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
12/52
12
Figure 3.4 JDBC API
3.1.2 Client-Side Design
ExtJS[3] is a JavaScript application framework to build interactive web applications. ExtJS
includes a set of GUI-based form controls for use within web applications such as text field,
date fields, toolbars, radio & checkbox controls. Sencha is a framework that makes the
management of the ExtJS easier. It follows an MVC architecture specified on its
requirements. In addition to these, there is a component called Store at which where data
templates, defined by the developer, reside in.
An Ext JS application UI is made up of Components ( A Container is a special type of
Component that can contain other Components. A typical Ext JS application is made up of
several layers of nested Components. Figure 3.5 shows the component structure of a web
application.
3.1.3 Server-Client Integration
Communication between server-side and client-side will be maintained through JSON files.
JSON is a lightweight data interchange format. It is easy for humans to read and write, and
also for machines to parse and generate. Although it uses JavaScript syntax to describe data
objects, it is language and platform independent. JSON is built on two fields:
A collection of name/value pairs. In various languages, this is realized as an object,record, structure, dictionary, hash table, keyed list, or associative array.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
13/52
13
An ordered list of values. In most languages, this is realized as an array, vector, list,or sequence.
To illustrate, for login operation, following steps occur:
1. After submitting, our system will create a JSON file, such as {user:confman,pass:123456} where user and pass are properties(e.g. Labels)
of the JSON file , confman and 123456 are values given to the username and
password fields respectively by the user.
2. This JSON file is parsed through servlet at the server side. Data is checked forwhether or not there is a matching username and password combination at the
system. Depending on the success of the login operation, server will create a
JSON file such that {success:true/false} where success is the label. If the
login is successful, success property is set to true or false otherwise.
3. The client will handle this JSON file and depending on the value of success, itnavigates the user to his specific page or returns notification indicating that the
login is not successful.
3.2 Decomposition Description
3.2.1 ER DIAGRAM
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
14/52
14
Figure 3.5ER diagram of CONFMAN
ConferencesThis table keeps information about the conferences currently being held.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
15/52
15
fieldName Description
conf_id The number uniquely given to the entry of
the conference
conf_name The name of the conference
conf_date The start date of the conference
SettingsThis table keeps information about the settings of the conference.
FieldName Description
set_id The number uniquely given to the entry of
the settings item.
set_name The name of the setting item
set_value The value to which the corresponding
setting item has been set
set_description Description of the setting item
RoomsThis table keeps information about room where presentations will be made in a conference.
FieldName Description
r_name The name of the room
r_id The number uniquely given to the entry of
the room instance
r_capacity The maximum number of people that can sit
in comfortably in the room
UsersThis table keeps information about the users in the conference (except authors).
FieldName Description
u_id The number uniquely given to the each user
instance
firstname A part of personal name that specifies and
differentiates between members of a group of
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
16/52
16
individuals, especially in a family
lastname A part of personal name which has been
passed, according to law or custom, from one or
both parents to their children
email Email address of the user
password The encryption of set of characters used for
authentication
address The collection of information, presented in a
mostly fixed format, used for describing the
location of a building, apartment, or other
structure or a plot of land, generally using
political boundaries and street names as
references, along with other identifiers such as
house and apartment numbers.
u_telephone The telephone number to reach to the user
u_type The type of the user(except authors)(Look at
SRS 1.0 Section 2.2)
SubconferencesThis table keeps information about the branches of a conference, if any.
FieldName Description
sub_id The name uniquely given to each
subconference instance
chair_id Referring to users table, the u_id of the
chair of the subconference
conf_id Referring to conferences table, the conf_id
of the conference of which the subconference
instance is a branch
ScheduleThis table keeps information about the timetables of the conference.
FieldName Description
sch_id The number uniquely given to each
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
17/52
17
scheduling item
sch_date The date when the scheduled item will
occur.
sch_speaker_id Referring to user table, the u_id of the
speaker that will make presentation at sch_date
sch_room_id Referring to rooms table, the r_id of the
room where the speaker with sch_speaker_id
will make presentation at sch_date
PapersThis table keeps information about the authors of the papers.
FieldName Description
p_id The number uniquely given to each paper
instance.
p_title The title of the paper
p_subconf_id Referring to sub conferences, the sub_id of
the conference for which that file has been
uploaded
p_author_id The id number of the author for the contact
to notify him about acceptance / rejection of the
paper
grade Average of the assigned reviewers' grades
on the paper
AuthorsThis table keeps information about the author(s) of the papers.
FieldName Description
a_position The order in which authors has been entered
to the system (i.e. '1' for the author entered
first,'2' for the second etc.)
a_paperid Referring to papers table, p_id of the paper
that corresponding author(s) has written.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
18/52
18
firstname First name of the author
lastname Last name of the author
email Email address of the author
ReviewsThis table keeps information about the reviews on the paper(s) made by reviewer(s).
FieldName Description
r_id The number uniquely given to each review
entry
comment The statements of the reviewer on the
paper(s) to which he has been assigned
grade The grade of the paper given by the
reviewer
r_paperid Referring to papers table, p_id of the paper
to which the reviewer has been assigned
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
19/52
19
3.2.2 Class Diagram
Figure 3.6Class Diagram of CONFMAN
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
20/52
20
3.2.3 Activity and State Diagrams
3.2.3.1 Login
To be able to use facilities of the system, user should login to the system. Loginprocess is pictured in figure 3.7.
User should first type the URL of the system to the browser and enter the website.Then, he will meet a login screen showed in Figure 5.2 including a simple form with
username and password sections.
User will type his username and password and click the Login button. If the one ofinformation he entered is not correct or does not exist in the database, a system error
message should appear in order to inform user.
This informative message should be convenient to system security specificationmentioned in 3.item in 2.3.3. It may be Invalid username or password.
If the user enters valid information, he enters the system and the system renew userspage with normal user panel.
Figure 3.7Login Procedure
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
21/52
21
3.2.3.2 Upload Paper
Only users who assigned as Author should be able to upload paper to correspondingconference.
To be able to upload paper they should be logged in the conference panel they want toupload their paper. They press the button labeled as Upload Paper.
After pressing button a file browser should appear. The author should be able tochoose multiple files at a time.
Chosen files will be filtered according to their size and type. This is due to securityand consistency of the system stated in 4.item in 2.3.3.
If the files could not pass the validation system, an informative message shouldappear on the user interface. It may be Improper file type and Size of the file
exceeds the limit. The name of the uploaded file should turn the bold font in red
color in order to indicate which file is erroneous.
If there is no problem with type and size of the file, a submission form then shouldappear. Form should contain mandatory information about the paper like title of the
paper and information about the authors of the paper.
At least, one authors information has to be filled in the form and the title of the paperhas to be stated. Otherwise system will warn the user with a message like Missing
information.
If all steps are passed successfully then by pressing a Submit button the file will beuploaded to the server.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
22/52
22
Figure 3.8Upload Paper procedure
3.2.3.3 Create Conference
Only Conference Supervisor should be able to create conference environment. Hereenvironment means an entry in conference table in database with its configuration
settings.
To create a conference, supervisor should be logged in to the system firstly. Loginsystem is specified in 3.2.3.1.
In his home page, CS will be able to see a button New Conference. By clicking thisbutton, CS will be sending a request in order to create a conference.
In response to this request, a submission form will be appearing in the home page ofCS. This form will be consists of sections related to settings of conference.
CS will fill this submission form and press the Submit button then the informationwill be checked for validation. If there are any missing or wrong typed information, it
should be highlighted with red color, bold font and a warning message should be
appear near the corresponding erroneous section.
After CS enters all information correctly submission will accomplish. Related tableentries and configuration settings will be inserted to the database and a success
message should be presented to the CS by the system. This message may be
Conference has been successfully created.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
23/52
23
Figure 3.9Creation of Conference
3.2.3.4 PC Designation
Only users who assigned as Chair should be able to form a Program Committee. In order to assign some reviewers to a Program Committee, Chair firstly should log in
to the system and conference. Login procedure will be as in 3.2.3.1. After Chair logins to the system, he chooses a conference, which he was assigned to,
from his conference list (Figure 5.1) in his home page. Conference panel appear.
In this panel, there should be a button labeled as Program Committee.By clickingthis button, Chair will be send request in order to add reviewers to PC.
A small popup appear in response to this request.In this popup, a list of reviewerstakes part.
If the person whom Chair wants to add in PC exists in the list, PC just selects him andclick button labeled Add Selected Person. Then system should inform the Chair
whether the operation is successful or not. This is important for security mentioned in
item 5 in 2.3.3.
If the person whom Chair wants to add in PC does not exist in the list, Chair shouldbe able to invite that person through email. There will be an input form on the popup,
which takes a valid email address. Then Chair clicks the button Invite and system
will send an invitation mail to the invited person automatically. After that procedure
will be operated same as in 3.2.3.10.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
24/52
24
Figure 3.10PC Formation
3.2.3.5 Chair Assignment
Only Conference Supervisor should be able to assign or invite a user as Chair. In order to assign Chair CS should first login to the system with the procedure
specified in 3.2.3.1 and should choose the conference, where he want to assign Chair,
from the conferences list on his home page.
In conference panel, there will be button only available to the CS labeled as AssignChair. CS clicks this button and sends request to the server.
In response to this request an invitation form appears on the CSs screen. After thatprocess is the same as in the invitation process specified in 3.2.3.10
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
25/52
25
Figure 3.11Chair Assignment
3.2.3.6 Reviewer Assignment
Chair should be able to assign or invite a user as Reviewer. In order to assign Reviewer, Chair should first login to the system with the procedure
explained in 3.2.3.1 and should choose the conference, where he want to assign
Reviewer, from the conferences list on his home page.
In conference panel, there will be labeled as Assign Reviewer. Chair clicks thisbutton and sends request to the server.
In response to this request an invitation form appears on the Chairs screen. After thatprocess is the same as in the invitation process explained in 3.2.3.10
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
26/52
26
Figure 3.12Reviewer Assignment
3.2.3.7 Author Invitation
Actor in an existing conference will be able to invite users as Author to thisconference.
After actor logins to the system, he chooses a conference, from his conference list(Figure 5.1) in his home page. Conference panel appears.
In this panel, there should be a button labeled as Invite Author.By clicking thisbutton, actor will be send request in order to invite author.
In response to this request an invitation form appears on the conference panel of theactor. After that process is the same as in the invitation process stated in 3.2.3.10
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
27/52
27
Figure 3.13Author Invitation
3.2.3.8 Recover Conference
Only Conference Supervisor will be able to recover a conference which is backed upbefore.
To recover a conference, supervisor should be logged in to the system firstly. Loginprocedure is explained in 3.2.3.1
There will be a button labeled as Recover Conference only available to CS. Byclicking this, request will be sent to the server and new options will appear on home
page of the CS related to recover.
One of them is a list of backed up conferences. CS selects one them and click therecover button labeled as Recover. A confirmation alert appears asking question
like Are you sure to recover this conference?
A validation system operates on the server side in order to control whether the datesof the conference is appropriate or not. Then system feedbacks to the CS by a warn
message if there is a problem or not with dates.
If there is a problem with the date, CS should select this conference again and beforerecover, he should adjust the dates of the conference by clicking button Settings.
After clicking this form appear consists of settings of the conference. CS fills this
form appropriately and saves the configurations by clicking Save button. Form is
similar to Conference Configuration procedure while creating a conference.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
28/52
28
If there is not a problem with the date, system checks the checksum (MD5) of theconference whether it is crashed or not.
If it is not crashed operation is successful and a success message is sent back to theCS. Otherwise, CS should again informed with failure message and CS should set thesettings of the conference again as in the procedure.
Figure 3.14Recover Conference
3.2.3.9 Backup Conference
Only Conference Supervisor will be able to back up a conference. To back up a conference, supervisor should be logged in to the system. Login system
is specified in 3.2.3.1.
There will be a button labeled as Backup only available to CS. By clicking this,request will be sent to the server.
In response to this request, a confirmation box pops up and ask a Yes No questionwhether CS is sure or not.
If CS clicks Yes, all configurations are backed up on the server and a copy of theconfigurations are also will be downloaded to the CSs personal computer. If clicks
No, confirmation box disappear and nothing happens.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
29/52
29
Figure 3.15Backup Conference
3.2.3.10 General Invitation Procedure
All types of actors will be able to invite anybody outside the system. Although, theinvitation types will be different, the invitation procedure is almost same for them.
Firstly, actor logins to the system. In home page or conference panel, there will bebutton labeled as Invite. Actorclicks in order to send request to this operation. A
submission form appears on screen.
In this form, there will be a list of actor types that registered user wants to assignsomebody. He chooses one of them and fills the input form which takes an email
address as input. Then clicks the submit button to send invitation to the email of
invited person.
If there is any mistake in the submission form, the system should warn the user with aclear informative message.
If the submission is successful, system sends the invitation mail with an activationlink and informs the user with a success message.
This activation link is special to the invited person that it should include somevariables related the type of invitation. After invited person clicks the activation link,
if he is already registered to the system, there will be a news on the notification area
(Figure 5.1) waiting for acceptation/rejection.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
30/52
30
If he accepts invitation, conference will be added to his conference list (Figure 5.1) onhis home page. Otherwise, nothing happens and a feedback will be sent to the user
who invites the user. The message appears on notification are of that person or he will
informed through email.
If invited person is not registered to the system, after clicking the activation link, aregistration procedure will be operated. After he registers to the system, the
conference which he invited to will be added his conference list (Figure 5.1) on his
home page automatically.
Figure 3.16General Invitation Procedure
3.2.3.11 Registration Procedure
Only invited people and the people who have mail with edu.tr extension will beable to register to the system.
They firstly type the URL of the system to the web browser and enter the mainpage the system. In login screen (Figure 5.2), there is a link labeled as Sign Up.
After clicking this registration form appears on the screen of the user.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
31/52
31
This form will include input sections for Name, Surname, Username and an emailaddress. The user will be expected to enter all information correctly. After fills the
form, clicks the submit button and if there is mistake in the form, user should be
warned with proper way explained in item 5 in 2.1.3
If there is not any wrong information with the inputs, registration process will besuccessful and a success message will be sent to the user.
Figure 3.17Registration Procedure
3.2.3.12 Paper Evaluation
Only reviewers whom assigned some papers in order to review are able to evaluatepapers.
To evaluate papers reviewers should be first logged into the system. After login reviewer choose one conference from conference list on main panel,
where he want to login and evaluate paper. He double clicks this conference and the
conference data will be loaded to the conference panel on the right side of main panel
(figure 6.4) .
After loading conference, if the user has multiple roles in this conference he choosesreviewer role from role type combobox (figure 6.4) in conference panel, after
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
32/52
32
choosing reviewer the relating data will automatically be loaded to the conference
panel.
For reviewers there will be an assigned papers panel devoted to reviewers, reviewerchoose one paper from there and double clicks it. An evaluation form appears (figure
6.8).
Reviewer fills the evaluation form and clicks the review button to completeevaluation process.
Figure 3.18Paper Evaluation
3.2.3.13 Notification Area
Notification area will be used for follow the news about invitation or other actionslike request for some role for some specific conference. This panel will be available to
all user types.
Since notification area will mainly be used for accepting/rejecting requests, it willhave a unique template for elements in this area. An element will be a box including
explanation about the request and two buttons labeled as accept and reject. There
may also be a hyperlink labeled as details which gives more information about the
request.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
33/52
33
If a request is sent to the user, the notification area will automatically be updated. User reads explanation or clicks details button to learn much more about it. Then clicks the accept or reject button. If he accepts request, then relating
operation will automatically be done and main panel will be updated according to thisoperation.
If he rejects nothing will be, however in both cases, the user who send the request willbe informed in same way, that is, the explanation will appear on his notification panel.
Figure 3.19Notification Procedure
3.3 Design Rationale
We gave up FLEX because of two drawbacks. If our system was developed withFLEX, one that wants to use our system, would install Adobe Flash to his browser.
Furthermore, we would lose mobile users because of dependency to Adobe Flash.
Although we have changed our tool, our architecture can still be maintainedsuccessfully due to the advantage that our new client-side tools are based on MVC.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
34/52
34
4. DATA DESIGN
Since CONFMAN is going to be an extensively comprehensive stand-alone web service,
it will keep and process huge amount of data. In order to satisfy the all requirements of the
project, a special care has to be taken in order to avoid unexpected behavior in the final
product when making data design choices. This section will explore how the objects of
classes to be defined in business-logic implementation (mostly in server-side) will deal with
organization and manipulation of the internal data and provided by the system users.
4.1 Data Description
Basically, classes that objects which will be populated with run-time data can be divided
into four kinds. First is responsible for dealing with user data, second is for taking care of
conference-related data, third and most crucial one is the ternary association classes of
objects where the interaction between conference objects and user objects take place. Last
and forth is for communication between users. Association classes will be discussed in the
subsections of the user-oriented and conference-oriented classes since they form a concise
and delicate relationship between these two.
4.1.1 User-oriented Classes
User classes are designed in such a way to deliver a multi-user environment and satisfy
the related requirements. Although users can conceive different kind of roles according to
their position in conference instances, outside the scope of any conference, users can have 3
different immutable(can't change during the lifetime of user account) Since this is a strict
requirement, classes are designed in such a way that it will not allow an illegitimate action.
For this purpose, an enumeration is introduced. According to this enumeration,
SYSTEM_ADMINISTRATOR will yield 0, CONF_SUPERVISOR will yield 1 and
STD_MEMBER will yield 2. Additionally, a base class called SystemUser is introduced. It
features each attribute that all users of the CONFMAN will have in common namely name,
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
35/52
35
surname, email and systemRole which is nothing but an enumerated integers by the
enumeration mentioned above. Furthermore, it has methods to send and receive messages and
notifications. SystemUser class which is a base class will serve as a generalization for the
following classes: ConferenceSupervisor, SystemAdmin and StandardMember.
4.1.1.1 StdMember
StandardMember class has myConferences attribute which is basically an integer array
which keeps the conf_id of the conferences which user has already signed in. any object of
StdMember or any class derived from it has a method to return the array mentioned above.
An important association class which is to form an association between StdMember and
Conference classes called ConferenceSpecificRole is introduced to satisfy multiple-role
assignment requirement for each conference individually. Thanks to this abstract base class,
classes derived from it can have role-specific attributes and methods according to the
conference-specific role of the corresponding run-time object. Derived classes namely
Outsider, Chair, PCmember, Author, Reviewer and Participant are explained below.
Outsider class is for the ones StandardMembers who are not yet signed in corresponing
conference (conference object which has the ternary relation with the aforementioned
StdMember object) It will feature isSigned boolean type attribute indicating if he is invited or
not (this is important in case of invisible conference instances) and requestForSignIn methods
to make a request to in the conference. When this request is approved, business logic
implementation will change the role attribute of the Outsider object to the unsigned integer
defined for author in the conferenceRoles enumeration. Moreover, it will cast the type of
Outsider class to Author class (any conferenceRoles class and its inheritors are defined as
virtual)
Chair class is for the StdMember instances who are assigned to a particular conference
object as chair. Apart from the attributes and the methods derived from
ConferenceSpecificRole class, objects of this class will store the conferencePengingSignIn
list which basically lists SignInRequest objects from the Outsider objects who requested to
sign in the particular conference instance which the abovementioned association object has
the ternary association with. Moreover, it has a method called confirmSignInRequest and
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
36/52
36
rejectSignInRequest which allow objects of this class to confirm or reject the SignInRequest
objects. It has two more methods called assignPCMember and assignReviewer to designate
standard members as PCmember or reviewer respectively for a particular conference
instance.
Additionally, this class has a ternary association with Paper class which is for storing the data
associated with the paper submitted by the Author objects. Name of the association class is
ConfirmPaperSession. It has isEvaluated attribute which is of Boolean type. When chair
wants to see if he has already evaluated the submitted paper or not, GUI element which is
bonded to this attribute will react according to the state of above mentioned attribute. Author
class also has confirm and reject methods to confirm or reject the papers submitted. These
two methods will be invoked by the 'accept' and 'reject' buttons located in the conferencepanel view of chair. Since chairs will be allowed to see the name of the association class has
also a method to see the name of the presenter of the paper. Note that Paper class has many-
to-many relationship with the Author class. Hence, there can be more than one owner of a
paper and vice versa. However chair of a conference can see only the presenter name.
As for, PCmember class, it will not implement any other attributes nor will have any
other attributes other than the ones inherited from its ancestor class. However, it will have a
ternary association with Paper class. One can think of this ternary relation just like the onewhich Paper and Chair classes mutually have.
Author class is introduced to allow its instantiations to accumulate the paper-related data -
for now only the gradeAverage of the paper- of the author along with what inherited
attributes store. It will also feature methods such as showGrade, calcMean and submitPaper
each of which implements the functionality that its class name suggests respectively.
Reviewer class doesnt feature any other attributes or methods than the ones derived from
StdMember class. However, it will have an association class with Paper class. This
association class called ReviewPaperSession has an attribute named isReviewed denoting if
the reviewer has already reviewed the paper object which is in the ternary relation with the
reviewer object. This class provides a method to allow Reviewer object to grade the Paper
object which is in association with itself. It also features a method called seePaper to let
reviewer see the Paper when he presses corresponding button in reviewer panel.
Objects of participant class dont have any other attributes or methods than the ones
derived from StdMember class.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
37/52
37
4.1.1.2 Conference Supervisor
Conference Supervisor is a derived class SystemUser class and responsible for
management of the every conference instance created. Conference instances can be created
solely by him. It will not feature any derived-class specific attribute but two methods called
updateDatabase and createConference. First of these methods simply allows
ConferenceSupervisor object to update the database by overwriting the whole run-time data
over the data stored in the database. It will be invoked by a 'update database' button lie the
user panel view of the supervisor of the conference. As for createConference method, it is to
create newConference and ConferenceManagement instances as the name of the class
suggests. Moreover, For the purpose of allowing the object(s) of this class to manage each
conference individually, this class has a ternary relation with Conference class named
ConferenceManagement. This association class will have various methods to change, back up
and recover settings (another class) of conference as well as carry out the scheduling task of
the conference. Script to schedule will be called from the inside this method. It also features
another method to invite StdMember objects to conference. By means of its assignChair
method, conferenceSupervisor can assign StdMembers to a conference as a chair.
4.1.2.3 SystemAdmin
Object(s) of systemAdmin class doesn't have any feature to take care of any conference or
user -related entity. Sole function of it is to update database.
4.1.2 Conference-oriented Classes
In this section, conference-oriented classes will be discussed in detailed way even though
this class is mentioned for many times in the early sections.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
38/52
38
4.1.2.1 Conference
This class will store the conference-specific data such as conf_id, conf_name, conf_date,
is_subConf, mother_id and conf_desc. Objects of this class can accumulate data of either a
single-track conference or any track of a mult-track conference along with the mother
conference. Thats why, it has a binary association with itself. From an object-oriented
perspective, some conference objects (mother track of multi-track conference) can have a
one-to-many relation with the subtracks of the conference. This class is designed such a way
that it allows its objects to import the settings defined for the mother of themif there any-. It
delivers this functionality by means of importSettingsFromMother method. This class has
two composition classes namely Settings and Schedule.
4.1.2.2 Settings
Objects of this class will store conference-specific settings laid out byConferenceSupervisor object. Settings class has isVisibleForOutsiders, scheduleSpecs (which
is of ScheduleType type) and paymentSpecs (which is of PaymentSpecs type) attributes. First
is of Boolean type and in case of it being true, the particular conference instance which
corresponding Settings object belongs to will be visible in the announcements list in the main
user panel of CONFMAN. Otherwise it will not be visible there and users can know about the
conference only when they are invited by StdMember objects that are signed in the
corresponding conference instance or any conferenceSupervisor. As for scheduleSpecs class,
it is to define the schedule characteristics such as presentationDuration, breakDruation,
numberOfSlots (for presentation sessions) presentationsStartAt (the hour when earliest
presentation starts) lunchBreakAt and lunchBreakDuration. PaymentSpecs is to specify
payment specifications such as payment deadline and signInWithoutPayment.
Setting class has a composition relationship with Rooms class which stores data about the
rooms where the presentations held during the conference. Associated data with the objects of
room class are name and capacity.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
39/52
39
4.1.2.3 Schedule
Object of these classes will be responsible to store timetable of the conference and
manipulate this stored information when needed. Stored data is basically a Timetable array
(Timetable class is comprised of two unsigned integers namely presenter_id and slot_number
respectively) and isScheduled attribute which is of Boolean type. Manipulation takes place
through a method called addPresentation method. This will be invoked whenever a
PCmember or Chair object of the ConferenceSpecificRole object of the corresponding
conference confirms a paper to be presented. One other manipulation of the objects of a
Schedule class is realized by ConferenceSupervisor object when it invokes the
scheduleConference method of Schedule class to reorganize the timetable array mentioned
above. And finally, it features showSchedule method to return timetable scheduled.
4.1.3 Communication-oriented Classes
For establishing the communication infrastructure of the CONFMAN, Message and
Notification classes are introduced. These two classes similar will be similar in
implementation. However, whether Notification objects will have some predefined strings
while Message objects will have String datatype as an attribute that can be retrieved from
classes of view components when user enters the message. Additionally, Message class
doesnt have from_id which denotes the user_id of sender member whereas Notification class
doesnt have that.
4.2 Data Dictionary
This section will list all the system entities both located in Server-side implementation
by providing tables for all classes and association classes with their associated attributes,
methods and method parameters.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
40/52
40
4.2.1 Classes
Classes Description Attributes MethodsSystemUser Users Signed Up
CONFMAN
name(string)
surname(string)
email(string)
systemRole(int)
norifications(Notification[])
inviteNewUser(uint user_id):void
seeNotifications():Notification
receiveNotification(Notification):void
sendMessage(Message):Boolean
receiveMessage(Message):void
SystemAdmin User(s) responsible
for providing
technical support to
CONFMAN
N/A updateDatabase():Boolean
ConferenceSupervisor User(s) responsible
for organization of
the conferences
N/A createConference(int conf_id, string
conf_name, Date conf_date, bool
is_subConf , int mother_id, string
conf_desc ):Boolean
StdMember User(s) who are
neither SystemAdmin
nor
ConferenceSupervisor
myConferences(uint[]) showMyConferences():uint[]
Conference Conference conf_id(int)
conf_name(string)
conf_date(Date)
is_subConf(bool)
mother_id(int)conf_desc(String)
importSettingsFromMother():Boolean
Settings Conference Settings isVisibleForOutsiders(bool)
scheduleSpecs(ScheduleTy
pe)
paymentSpecs(PaymentSpe
cs)
setScheduleSpecs():Boolean)
setVisibilirty(Boolean):void
Schedule Conference Schedule timetable(TimeSlot)
isScheduled(void)
addPresentation():Boolean
scheduleConference():Boolean
Room Rooms where
presentations duringthe conference will be
held
name(string)
capacity(uint)
N/A
TimeSlot Entry of Schedule presenter_id(uint)
slotNumber(uint)
N/A
ScheduleType Schedule
Characteristics
presentationDuration(uint)
breakDuration(uint)
numberOfSlots(uint)
presentationsStartAt(Date)
lunchBreakAt(Date)
lunchBreakDuration(uint)
N/A
PaymentSpecs Payment
Specifications
paymentDeadline(Date)
signInWithoutPayment(Bo
olean)
N/A
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
41/52
41
4.2.2 Association Classes
Associations Description Entities Involved Attributes Methods
ConferenceManagement Associate a
ConferenceSupe
rvisor with a
Conference
ConferenceSuperviso
r, Conference (one-
to-many)
N/A seeSettings():void
loadSettings(file
XML):Boolean
saveSettings():Boolean
inviteUserToConf():voi
d
assignChair(uint
user_id):void
ConferenceSpecificRole Associate aStdMember
with a
Conference
StdMember,Conference
(many-to-many)
role(uint) inviteUserToConf(uintuser_id)
payConferenceFee():voi
d
showSchedule():Timeta
ble
Chair Associate a
Chair with a
Conference
Chair, Conference
(many-to-many)
conferencePendingLi
stSignInList(SignInR
equest)
confirmSignRequest():v
oid
rejectSignInRequst():voi
d
assignPCMember():void
assignReviewer():void
Outsider Associate anOutsider with a
Conference
Outsider, Conference(many-to-many)
isInvited(Boolean) RequestForSign():void
PCmember Associate a
PCmember with
a Conference
PCmember,
Conference
(many-to-many)
N/A N/A
Reviewer Associate a
Reviewer with a
Conference
Reviewer,
Conference
(many-to-many)
N/A N/A
Participant Associate a
Participant with
a Conference
Participant,
Conference
(many-to-many)
N/A N/A
ConfirmPaperSession Associate a
Paper with a
Paper, Chair
(one-to-many)
isEvaluated(Boolean) confirm():void
reject():void
Notification Notification to be sent
and received by
SystemUser objects
notificationMessage(uint)
from_ID(uint)
N/A
Message Message to be sentand received by
SystemUser objects
messageText(string)from_ID(uint) N/A
SignInRequest Request for Signing
In sent by an Outsider
customMessage(string)
from_ID(uint)
N/A
Paper Paper to be submitted
by Author
grade(float)
owner_id(uint)
paper_id(uint)
N/A
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
42/52
42
Chair showPresenterID():void
ConfirmPaperSessionB
YPCmember
Associate a
Paper with a
PCmember
Paper, PCmember
(many-to-many)
isEvaluated(Boolean) confirm():void
reject():void
showPresenterID():void
ReviewPaperSession Associate a
Paper with aReviewer
Paper, Reviewer
(many-to-many)
isReviewed(Boolean) grade():void
seePaper():void
5. ALGORITHMS
5.1 MD5 Hashing
The passwords are digested and stored in the user database in an
encrypted form. No one, even the administrator, can open the database and know the
password by looking at the encrypted form of it. This makes it safer, because the encrypted
form of the password can be read only by the web server.
MD5 hash is used for sending encrypted user credentials across a network within HTTP.
An MD5 hash contains a user name, password and the name of the realm. The realm is the
domain that will authenticate or reject the users credential. MD5 consists of binary data,
typically no more than 160 bits and was assumed to have the following properties:
Hash length: Hash length is independent of the size of the message. Commonly 128 or
160 bits are used.
Non-discoverability: Every pair of nonidentical messages will translate into different
hash values.
Determinism: Each time a particular message is hashed using the same algorithm, the
exact same hash value will be produced.
Irreversibility: All hashing algorithms are one way. It is not possible to discover the
password and any part of the password given the hash value alone.
MD5 algorithm works as follows on b-bit message:
A single bit 1 is appended to the end of the message. Then add enough zero bits to the
length of the message to 64 bits fewer than nearest multiple of 512.
64 bits are filled up binary representation of the length of the original message.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
43/52
43
4 word buffers(32-bit register) A,B,C,D are initialized to following values: A: 01 23 45 67
B: 89 ab cd ef
C: fe dc ba 98
D: 76 54 32 10
Message is processed in 512-bit blocks. Four similar rounds happen each of which consist
of 16 similar operations based on nonlinear function F, modular addition and left rotation. F
can have 4 functions each of which must be used only at one round. Buffers are updated after
each round.
One iteration in MD5 operation is shown at Figure 5.1
Figure 5.1 - MD5 Operation
5.2 Scheduling Algorithm
In order to tackle Scheduling Problem (Computationally hard-to-solve by its nature)
CONFMAN has employed and adapted genetic algorithm to schedule the presentations of a
conference. When adapting genetic algorithm to our problem, some ideas discussed on paper
Solving Timetable Scheduling Problem by Using Genetic Algorithms, Branimir Sigl, Marin
Golub, Vedran Mornar, are borrowed.
Regarding genetic algorithm implementation, there are some important points to
mention namely; data representation, gene evaluation function depending on the definition of
optimality, genetic operators, termination condition.
Data representation is the most crucial part of implementing genetic algorithm since
this is how we reduce the theoretical problem size. In our case, we have three resources asfollows: days, hours, rooms. Besides, we have only one constraint: no resource should be
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
44/52
44
allocated by multiple presentations at the same time. To illustrate allocation of the resources
by presentations, figure below can be viewed. As for, representing the individuals (in our
case, concatenation of mathematical representation of presentation individual each of which
are with corresponding three-tuple coordinate in constraint cube (grid cube in the figure)
first, presentations should be represented. Each presentation can allocate only one three-tuple.
Each element of three-tuple denotes presentation day, presentation time-slot and presentation-
room. In this way, we can define individuals a vector of three-tuples. For example Let
*()| + be the domain for IND individuals (having a
domain in base two will allows to convert data representation to binary string which will be
useful for genetic operators)
As for evaluation function, a function is defined which takes an instance of set
and assess its fitness value. Positive fitness values imply individual doesnt have any
conflicting presentation whereas negative values indicates conflicts are present in the
presentation schedules (two or more three-tuples in vector are same). Furthermore,
positive values gets larger as the individual get closer to the optimality whereas smaller
negatives mean more conflicts. Optimality criteria is defined as earlier the presentations are,
better it is. However, this function is defined as flexible as possible so it is possible to
redefine the optimality criteria. This would possibly result in absolute value changes in
positive and negative values of individuals yielding same sign as in any legit evaluation
function for this reduced version of scheduling problem.
TimeSlots
Figure 5.23D representation
of a gene individual which
suggests a scheduling for aconference with resources of three
days, three rooms and three time-
slots. Each color denotes different
presentation to be held in the
conference. This gene is fit
enough to meet the no-confliction
constraint.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
45/52
45
Since, individuals are represented as concatenation of binary strings, genetic operators
such as cross-over operator, mutuator and selection operators. Basically, after having a
randomly initialized vector of IND individuals(discussed above) and converting this to the
binary string which is the data representation of the corresponding individual gene) this
operators can operate on them to get fitter individuals and eliminate weak ones. So, in this
way the algorithm starts from an infeasible timetables, and tries to get a feasible one.
Termination condition for the genetic algorithm is the when some individual is fit
enough for a good scheduling (yielding a positive value) or enough time is elapsed. When
latter is the case, this will cause an exception to be handled first by server-side and then
client-side notifying user that scheduling operation is failed. Judging by the performance of
the genetic algorithm implementation of CONFMAN so far, such a condition will rise onlywhen invalid parameters are provided by conference chair.
.
6. HUMAN INTERFACE DESIGN
6.1 Overview of the User Interfaces
Our aim is to minimize the attempt of the user for performing operations. Panels,
forms, etc. will open when the user . We do not need to redirect the user to a different page to
perform his tasks.
6.2 Screen Images
6.2.1 Welcome Page
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
46/52
46
Figure 6.1 - Welcome Page
When the user presses the LOGIN button, the login panel at Figure 6.2 appears onthe screen in overlayed form.
Figure 6.2 Login Panel When the user presses REGISTER button, the registration form at Figure 6.3
appears on the screen in overlayed form.
Figure 6.3 - The registration form
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
47/52
47
Home link directs the page to the home page, About link gives information aboutthe software, Contact link contains contact info, News link shows latest updates
about CONFMAN. When the user clicks on the Turkish flag, the page is translated into Turkish. When
the user clicks on the English flag, the page is translated into English.
6.2.2 Author Panel
Figure 6.4 Role-Based Page When the user selects Author Role at the combo box, the page is loaded with the
interface as shown Figure 6.5.
Figure 6.5 Author Panel
When the author presses NEW SUBMISSION button, the submission form at Figure6.6 appears on the screen in overlayed form.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
48/52
48
Figure 6.6 Submission Form Whenever the author presses Add Author button N times, the form expands N times
and inserts text fields for Author 2, Author 3, , Author N+1.
The user can change or remove existing submissions via Change and Removelinks respectively. He can see the status of the submission(accepted, rejected).
The user can invite a standard user to the system via pressing INVITE NEW USERbutton. After pressing, Figure 6.7 appears on the screen. The user can invite a system-in user to the conference via INVITE USER TO THE
CONFERENCE button. After pressing, a text field appears on the screen as shown at
Figure 6.8
Figure 6.7 New User Invitation
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
49/52
49
Figure 6.8 Conference Invitation
6.2.3 Reviewer Panel When the user selects Reviewer Role at the combo box, the page is loaded with the
interface as shown Figure 6.9.
Figure 6.9 - Reviewer Page When the reviewer click on the Review link, a review form appears on the screen in
the overlayed form as shown at Figure 6.10.
Figure 6.10 Review form The reviewer can edit or remove his submitted review by clicking on the Change
and Remove links respectively. The user can invite a standard user to the system via pressing INVITE NEW USER
button. After pressing, Figure 6.7 appears on the screen.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
50/52
50
The user can invite a system-in user to the conference via INVITE USER TO THECONFERENCE button. After pressing, a text field appears on the screen as shown at
Figure 6.8
6.2.4 Conference Supervisor Panel
When the user selects Supervisor at the combobox, the page is loaded with theinterface as shown Figure 6.11.
Figure 6.11 Supervisor Panel When the chair clicks on the CREATE CONFERENCE button, a form appears on
the screen in overlayed form as shown at Figure 6.12.
Figure 6.12 New Conference Form The user can invite a standard user to the system via pressing INVITE NEW USER
button. After pressing, Figure 6.7 appears on the screen.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
51/52
51
The user can invite a system-in user to the conference via INVITE USER TO THECONFERENCE button. After pressing, a text field appears on the screen as shown at
Figure 6.8 Conference supervisor can recover and backup conference information via Recover
and Backup links respectively for each conference he has been assigned assupervisor.
6.2.5 Chair Panel When the user selects Chair at the combobox, the page is loaded with the interface
as shown Figure 6.13.
Figure 6.13 Chair Panel
Chair can assign the role of chair to another person, who does not have such a role, asa helper to himself by pressing DESIGNATE CHAIR button. After pressing, a
panel, combination of the panels at Figure 6.7 and 6.8(but different business logic)
appears on the screen so that chair can assign a user no matter he is signed up to the
system. The user can invite a standard user to the system via pressing INVITE NEW USER
button. After pressing, Figure 6.7 appears on the screen. The user can invite a system-in user to the conference via INVITE USER TO THE
CONFERENCE button. After pressing, a text field appears on the screen as shown at
Figure 6.8. Chair can finalize the submission phase of the reviewed papers via clicking on
Accept or Reject links.
7. CONCLUSION
This document has been prepared for an effective implementation of CONFMAN. However, there
may be some changes at some parts of the system for the second semester.
-
7/29/2019 SOFTWARE DESIGN DOCUMENT v1.1
52/52