CONFMAN VERSION 1.0

7/29/2019 CONFMAN VERSION 1.0

1/40

1

SOFTWARE DESIGN DOCUMENT

for

CONFMAN

v1.0

PREPARED BY

CENGIZOVERBirand Koray EREN

Ahmet Anl PALA

Mustafa YAVUZ

Burak N


2/40

2

Table of Contents

PREFACE ........................................................................................................................................ 3

1. INTRODUCTION ........................................................................................................................ 4

1.1 Purpose ....................................................................................................................................... 4

1.2 Scope ...................................................................................................................................... 4

1.3 Overview ................................................................................................................................ 4

1.4 Reference Material ................................................................................................................. 5

1.5 Definitions & Acronyms ........................................................................................................ 5

2. SYSTEM OVERVEW ................................................................................................................ 5

2.1 Design Constraints ................................................................................................................. 6

2.1.1 Performance ..................................................................................................................... 6

2.1.2 Easiness to use ................................................................................................................. 7

2.1.3 Security ............................................................................................................................ 7

3. SYSTEM ARCHITECTURE ....................................................................................................... 8

3.1 Architectural Design ............................................................................................................... 8

3.1.1 Apache FLEX .................................................................................................................. 8

3.1.2 BlazeDS ........................................................................................................................... 9

3.1.3 Cairngorm ...................................................................................................................... 10

3.2 Decomposition Description .................................................................................................. 13

3.2.1 ER DIAGRAM .............................................................................................................. 13

3.2.2 Class Diagram ............................................................................................................... 18

3.2.3 Activity and State Diagrams .......................................................................................... 19

3.3 Design Rationale .................................................................................................................. 30

4. DATA DESIGN ......................................................................................................................... 31

4.1 Data Description ................................................................................................................... 31

4.1.1 User-oriented Classes .................................................................................................... 31

4.1.2 Conference-oriented Classes ......................................................................................... 35

4.2 Data Dictionary .................................................................................................................... 37

4.2.1 Classes ........................................................................................................................... 37


3/40

3

4.2.2 Association Classes ....................................................................................................... 38

5. HUMAN INTERFACE DESIGN .............................................................................................. 39

5.1 Screen Images ....................................................................................................................... 39

6. CONCLUSION .......................................................................................................................... 40

PREFACE

This document contains design specifications for CONFMAN (Conference Management

and Hosting System). This document has been prepared as an assignment of Computer

Engineering Design course, CENG491. This course aims to make students practice analysis,

requirement specification, design phases of a computer system, issues related to projectdesign 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.

CHANGE HISTORY

DATE DOCUMENT ID VERSI

ON

COMME

NT

WRITERS

02/12/20

12

CENGIZOVER_COFMAN_

SDD

1.0 Created CENGIZO

VER


4/40

4

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.

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.


5/40

5

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]http://livedocs.adobe.com/blazeds/1/blazeds_devguide/

[2]http://www.adobe.com/devnet/flex/articles/flex_java_architecture.html

[3]http://www.adobe.com/devnet/flex/articles/introducing_cairngorm.html

[4]http://www.unixwiz.net/techtips/sql-injection.html

[5]http://en.wikipedia.org/wiki/Cross-site_scripting

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

RDBMS Relational Database Management System

UI User Interface

API Application Programming Interface

HTTP HyperText Transfer Protocol

GUI Graphical User Interface

HTML HyperText Markup Language

RIA Rich Internet Application

MVC Model View Controller

2. SYSTEM OVERVEW
http://livedocs.adobe.com/blazeds/1/blazeds_devguide/http://livedocs.adobe.com/blazeds/1/blazeds_devguide/http://livedocs.adobe.com/blazeds/1/blazeds_devguide/http://www.adobe.com/devnet/flex/articles/flex_java_architecture.htmlhttp://www.adobe.com/devnet/flex/articles/flex_java_architecture.htmlhttp://www.adobe.com/devnet/flex/articles/flex_java_architecture.htmlhttp://www.adobe.com/devnet/flex/articles/introducing_cairngorm.htmlhttp://www.adobe.com/devnet/flex/articles/introducing_cairngorm.htmlhttp://www.unixwiz.net/techtips/sql-injection.htmlhttp://www.unixwiz.net/techtips/sql-injection.htmlhttp://en.wikipedia.org/wiki/Cross-site_scriptinghttp://en.wikipedia.org/wiki/Cross-site_scriptinghttp://en.wikipedia.org/wiki/Cross-site_scriptinghttp://en.wikipedia.org/wiki/Cross-site_scriptinghttp://www.unixwiz.net/techtips/sql-injection.htmlhttp://www.adobe.com/devnet/flex/articles/introducing_cairngorm.htmlhttp://www.adobe.com/devnet/flex/articles/flex_java_architecture.htmlhttp://livedocs.adobe.com/blazeds/1/blazeds_devguide/


6/40

6

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 its

representation 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.

Figure 2.1 - MVC Schema

2.1 Design Constraints

2.1.1 Performance


7/40

7

* 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 Easiness 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.

1. The system should be invulnerable to the SQL injection attacks. In order to preventsystem from SQL injection 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) is another widely used type of attack from the malicioususers, 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. An

example 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


8/40

8

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

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

3.1.1 Apache FLEX

Although we have not decided on the appearance of user interfaces yet, we will develop

this 2on APACHE FLEX. Apache Flex, formerly known as Adobe Flex is a software

development kit for the development and deployment of cross-platform rich Internet

applications based on the Adobe Flash platform. Initially developed by Macromedia and then

acquired by Adobe Systems, Flex was donated by Adobe to the Apache Software Foundation

in 2011.


9/40

9

Flex is a client-side technology that provides developers with a rich set of API calls for

creating GUIs, drawing graphics, playing and streaming media, and connecting to the Web

services.

Application development happens in an environment behind the firewall, the SWF file is

deployed on the web server directory. To run the application, you have to make request to it

from a computer within the firewall. SWF (ShockWave Flash) is an Adobe flash format used

for multimedia and ActionScript. The executing SWF file can access resources on any other

server as necessary. In the development environment, the SWF file can directly access web

services, or it can access them through a proxy server.

On the server side, Java technology provides abilities such as connecting to RDBMSs,

multi-threaded processing of the service requests and optimum scaling with increasing

demand. The architecture of client-server relationship [2] for Java is shown in Figure 3.1.

Figure 3.1 - Client - server relationships in FLEX

A FLEX application is embedded in a single HTML page rendered by Flash Player. The

Flex application can dynamically send and retrieve data asynchronously to the server in the

background, updating but never leaving the single application interface.

3.1.2 BlazeDS

Flex applications can communicate with back-end server(s) using HTTP. The FLEX

framework hasRemoteObjectAPI to make Flash Remoting to a method of a server-side Java

class that returns binary Action Message Format over HTTP.

BlazeDS[1] is the server-based Java remoting and web messaging technology that enables

developers to easily connect to back-end distributed data and push data in real-time FLEX

applications for more responsive RIAs.

The following figure shows BlazeDS architecture.


10/40

10

Figure 3.2 - BlazeDS architecture

3.1.3 Cairngorm

Cairngorm[3] is one of the primary open source frameworks for application architecture

in FLEX.

Cairngorm is based on MVC model. It aims to facilitate complex state and data

synchronization between the client and the server, while keeping the programming of View

layer independent from data implementation.

Model holds data objects and the state of the data. Controller processes business logic. View renders data and announces gesture with events. View communicates with Controller using events. Views watch Model with data bindings. Views are GUIs or visual portions of FLEX application. Views can contain child views.The architecture of Cairngorm is shown at Figure 3.3.


11/40

11

Figure 3.3 - Cairngorm architecture

Six major components are used in Cairngorm projects.

ModelLocatorThe ModelLocator serves as a central repository for shared application data. It allows

components of the application to have access to the same set of data to ensure

synchronization. Moreover, it notifies views of any changes to the data so that the views can

update themselves

ServiceLocatorCommunication with the back-end server for RIA applications is accomplished with one

of the remoting classes, such asHTTPService and WebService. The ServiceLocator provides

a centralized location for access and sharing these services not to declare them in each

component needing to access them.

CommandsThis component is triggered by the Event class to trigger business logic and update the

ModelLocator.

EventsThe Event is used to trigger the Command component and pass along any data they

require.

FrontControllerThe FrontController provides a centralized location to define the way Cairngorm events

are handled. Additionally, this component triggers event-command relationships and triggers

the registered command for a given event when that event is fired.


12/40

12

Value ObjectsValue objects represent conceptually related sets of data and contain public properties to

represent individual parts of the data. They are also used to transfer related sets of data

between components in the application and the server.

DelegatesDelegates serve as proxy objects that take care of the details of accessing a particular

service and return the data from the service via responder functions.

Figure 3.4 shows the basic chain of events in Cairngorm between components.

Figure 3.4 - Interaction between Cairngorm components


13/40

13

3.2 Decomposition Description

3.2.1 ER DIAGRAM


14/40

14

Figure 3.5ER diagram of CONFMAN

ConferencesThis table keeps information about the conferences currently being held.

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.


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



15/40

15

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

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 atSRS 1.0 Section 2.2)

SubconferencesThis table keeps information about the branches of a conference, if any.


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

Schedule


16/40

16

This table keeps information about the timetables of the conference.


sch_id The number uniquely given to each

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.


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.


a_position The order in which authors has been entered

to the system (i.e. '1' for the author entered


17/40

17

first,'2' for the second etc.)

a_paperid Referring to papers table, p_id of the paper

that corresponding author(s) has written.

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


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


18/40

18

3.2.2 Class Diagram

Figure 3.6Class Diagram of CONFMAN


19/40

19

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


20/40

20

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.


21/40

21

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.


22/40

22

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.


23/40

23

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


24/40

24

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


25/40

25

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


26/40

26

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.


27/40

27

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.


28/40

28

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. Actor clicks 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.


29/40

29

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.


30/40

30

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.3 Design Rationale

FLEX allows us to develop UIs independent of some criteria such as browser type andscreen size.

FLEX allows us to put business logic behind the UIs due to its strong event handlingsystem.

GUIs can be developed by using Flex Builder 3 easily. It has a Source part where wecan edit the GUI file. Furthermore, it has Design part where we can edit the interface

by dragging components to the interface layer and edit the properties of components

such as text alignment, color etc. Changes made in Design part can be seen at the

Source part, because Flex Builder inserts the corresponding code to the GUI file.


31/40

31

We decided to choose Cairngorm as design pattern, because it has a steady structurefor mid-large applications where all responsibilities of MVC layers can be divided

effectively.

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 dividedinto 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.


32/40

32

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,

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


33/40

33

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

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 chairwants 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 conference

panel 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 one

which 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


34/40

34

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.

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.


35/40

35

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.

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 by

ConferenceSupervisor 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


36/40

36

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.

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.


37/40

37

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.

4.2.1 Classes

Classes Description Attributes Methods

SystemUser Users Signed Up

CONFMAN

name(string)

surname(string)email(string)

systemRole(int)

norifications(Notification[])

inviteNewUser(uint user_id):void

seeNotifications():NotificationreceiveNotification(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 during

the conference will be

held

name(string)

capacity(uint)

N/A

TimeSlot Entry of Schedule presenter_id(uint) N/A


38/40

38

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 a

StdMember

with aConference

StdMember,

Conference

(many-to-many)

role(uint) inviteUserToConf(uint

user_id)

payConferenceFee():void

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 an

Outsider with a

Conference

Outsider, Conference

(many-to-many)

isInvited(Boolean) RequestForSign():void

PCmember Associate a PCmember, N/A N/A

slotNumber(uint)

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

Notification Notification to be sent

and received by

SystemUser objects

notificationMessage(uint)

from_ID(uint)

N/A

Message Message to be sent

and 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


39/40

39

PCmember with

a Conference

Conference

(many-to-many)

Reviewer Associate a

Reviewer with a

Conference

Reviewer,

Conference

(many-to-many)

N/A N/A

Participant Associate aParticipant with

a Conference

Participant,Conference

(many-to-many)

N/A N/A

ConfirmPaperSession Associate a

Paper with a

Chair

Paper, Chair

(one-to-many)

isEvaluated(Boolean) confirm():void

reject():void

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 a

Reviewer

Paper, Reviewer

(many-to-many)

isReviewed(Boolean) grade():void

seePaper():void

5. HUMAN INTERFACE DESIGN

5.1 Screen Images

These panels will be on the home page of users. Notification area shows the news about the

conferences and my conferences is the list that the user signed in.

Figure 5.1 Panel for the User

Figure 5.2 shows the login panel where users enter the system.


40/40

Figure 5.2 Login Panel

6. CONCLUSION

This document has been prepared for an effective implementation of CONFMAN. However,

there may be some changes at some parts of the system later.

CONFMAN VERSION 1.0

Documents

Transcript of CONFMAN VERSION 1.0