ProjeX THE DEVELOPER’S GUIDE
This
guide is for anyone who wants to make maintenance or additions to the system.
Below you will find :
While
designing and implementing ProjeX, object oriented methods will mainly be
followed. Therefore we first decided on the basic entities and their attributes
that will be used in the design of the system and then elaborated the working
parts of the program. A module simulates a general view of a functional part of
the whole system. A module might take inputs that specify its action and it
includes methods or other modules that it calls to perform necessary
operations.
The
modules explained in this section include all single parts of the whole ProjeX
functioning system. These modules are a slightly revised version of the modules
we put in the initial design report o ProjeX.
The
following modules are explained in the following sections:
This
module does nothing but opens information pages of ProjeX. Any person visiting
the main page of ProjeX will be granted the opportunity to get information
about what ProjeX is and how it works. On the other hand an existing user of
ProjeX would like to consult the user manual of the program. So Help Module
will be there to open the necessary information pages of ProjeX whenever a
visitor or a user demands for it. Help Module will take as input the state of
the help button (check section 3.1 of
this report) so that when a visitor or a user clicks on this button it will
perform necessary operations for opening the necessary information pages. The
so called help button is displayed on
almost every page of ProjeX so Help Module may be called in any phase of the
program.
Ø Methods related to Help Module may be listed as:
-
CheckTheStateOfHelpButton() : Checks whether the help button is clicked
on.
-
DisplayHelpPages() : Display
user manual of ProjeX
This
is the module responsible for creating a new account for starting to use
ProjeX. Once an account is created then a company may create projects inside
the account; tasks, resources, groups inside the projects; may create user
profiles and assign users to tasks etc. The creator of the account will
automatically bear the “administrator” status and have all the permissions.
Once an account is created then the creator may add new users inside the
account by creating new users [Check User Operation Module, 4.7].
When
a new account is to be created a user profile should be created for the creator
of the account. This evidently requires providing a user name and a password
for the creator. Hence in order to create an account one must supply the
following information:
company_name [STRING] : Name of
the company for which the account is created.
This is in
fact the name of the account.
user_name [STRING] : User name
for the creator of the account.
user_password [STRING] : Password
for the creator of the account.
The
information above must obligatorily be provided to create an account. Other
information about the creator profile may be provided later [User Operation Module, section 4.7].
Once an account is created the system will automatically open it for the usage
of its creator.
Ø Methods related to Create Account Module may be listed as:
-
GetCreatorInfo() : Get the information provided by
the user to create the account.
-
CheckCreatorInfo() : Check whether the information
provided by the user to create an
account is sufficient.
-
SendInsufficientInfoMessage() : Send a message to the user stating that the
information provided is not sufficient to create
an
account.
-
CreateAccount() : Create a new account with the
information provided.
-
OpenAccount() : Open the account just created.
Login
Module is responsible for identifying an existing user of the program an
opening his account. An existing user means a user already registered to an
account inside ProjeX. Once the user provides necessary inputs for logging in
to his account Login Module will perform the operations to check the user’s
inputs and open his account. In order to open his account a user must provide
three inputs to Login Module: the name of the account (which is named as
‘company login name’, his user name and his password. So Login module will
accept the following three inputs from the user in order to identify him:
-
company_login_name [STRING] : The name of the account
-
user_name
[STRING] : Username of the user
-
user_password [STRING] : Password of the user
If
these three inputs provided by a user are not valid for any existing account,
Login Module will reject the user’s demand of logging in to an account.
If
the inputs above are valid then Login Module will open the corresponding
account for the user. Before opening the account, the status of the user will
be determined by his information in the database. This is necessary since the
session opened to a user bearing the “manager” status is different than the
session opened to other normal users. The number of operations that a manager
may perform is also greater hence the system should know who is logging in. The
status of a user is determined once when the user logs in and is kept in memory
till the user logs out of his account. This helps checking easily whether the
status of a user allows him to perform a specific operation like
adding/deleting tasks, creating new user profile etc…
Ø Methods related to Login Module may be listed as:
-
GetUserInfo() : Get the
company name, user name and password of the user
- CheckUserInfo() :
Check the company name, user name and password of the
user.
-
GetUserStatus() :
Get the status of the logged in user.
-
OpenAccount() :
Open the corresponding account of the user.
-
RejectLogin() : Reject
the login demand.
- SendRejectionMessage() : Send the necessary rejection message.
Display
Project Module is the part of the system responsible for exposing correctly the
features of a project and for calling appropriate functions or modules in order
to perform necessary operations on the exposed project. Display Project Module
is designed to be the program part running behind the
Projects Pages [see section 3.4] so
you may find it useful to have a look at that interface in order to get better
insight to the functioning mechanism of this module.
Display Project Module is invoked whenever a user opens the
interface for displaying a project. First job of the module is to properly list
the tasks of the concerned project according to three constraints:
The user would like to list all of the tasks, only the
incomplete tasks or only the complete tasks of a project. Hence Display List
Module must consider what we call ‘Task List Property’ while displaying the
tasks of a project.
The user would like to list only the tasks bearing one or
more special properties like all tasks having the ‘urgent’ priority, all tasks
whose start date is before 07/11/2004 etc… ‘Task List Filter’ will impose to
Display Project Module which tasks are to be displayed.
As the name implies, ‘Sort Criterion’ will provide necessary
information to Display Project Module for sorting the tasks by a special
property (like due date or task number) whenever the user wants so.
The above constraints for listing the tasks of a project will be
determined by the inputs taken from the user.
The interaction between the user’s demands and Display Project
Module will be performed with the use of buttons on the display project
interface. If a button on the interface is clicked on by a user, the module
will check which button is clicked and will then perform the necessary
operations.
Along with displaying the tasks of a project according to some
criteria, five other types of operation may be demanded by the user:
An operation
on,
1.
the displayed
project
2.
a task of
the displayed project
3.
a resource
4.
a group
5.
graphical
data display
This
module is responsible for performing the three main types of operations about a
project:
Project
Operation Module takes one input, operation_type [INTEGER], and it is this input that tells to the module which of
the above three operation is to be performed.
Project
Operation Module starts its function by checking the status of the user
invoking it. The module will let the user perform any operation on a project if
his status is appropriate for that operation.
When
the operation is ‘Display Project’ the system will display the attributes of
the project like due date, estimated moths etc… If the status of the user
permits it, the fields displaying the attributes of the project will be
editable. Hence a user might change the attributes of a project (if his status
allows it) after having invoked ‘Display Project’ operation.
Ø Methods related to Project Operation Module are as follows:
-
CheckUserStatus() : Check the status of the user to see
whether he is allowed to
perform the
requested operation on a project.
-
SendRejectionMessage() : Send a message to the user
stating that his status is
not appropriate to perform the requested operation on a project.
-
GetProjectInfo() : Get the
information (attributes) provided by the user
to create a project.
-
CheckProjectInfo() : Check whether the information
provided by the user to
create a
project is sufficient.
-
SendInsufficientInfoMessage() : Send a message to the user stating that the
information provided is not sufficient to create
a new project.
-
CreateProject() : Create a new project with the information
provided by
the user.
-
EditProject() : Let the user edit the
attributes of the project.
-
SaveNewProjectInformation() : Save the changes made on the project’s
attributes.
-
DeleteProject() : Delete completely a project from the
account.
Similar
to Project Operation Module, Task Operation Module is responsible for three
kinds of operations on tasks: creating a new task, editing an existing task and
deleting an existing task. Such task operations are limited only to users
bearing an appropriate status. For example a user can create a task only if his
status permits doing so. Hence whenever the Task Operation Module is invoked,
the module fist checks whether the status of the user invoking it is
appropriate. If it is so then a task operation may be performed. If not the
task operation request is rejected.
A
task has the following attributes. In
order to create a new task the creator should provide the ones marked with ‘*’:
task_name* [STRING] :
The name of the task
task_description [LONG STRING] :
Description of the task
task_status* [INTEGER] :
Official status of the task that shows whether
the task has just started or tested or
completed etc..
percentage_of_completion [INTEGER] :
Numeric data showing how much of the task
is completed.
task_priority* [INTEGER] :
Priority of the task.
start_date* [STRING] :
Starting date of the task.
due_date* [STRING] :
Due date of the task.
estimated_hours [STRING] :
Estimated hours of completion for the task
Apart
from the attributes provided by the user, the system will automatically assign
the following attributes to a newly created task:
task_number [INTEGER] : Number
of the task inside the project. The first
created task will have 1 as its number, the second 2 etc…
task_creator [INTEGER] :
ID of the user who created the task
Ø Methods related to Task Operation Module are as follows:
-
CheckUserStatus() : Check the status of the user to see
whether he is allowed to
perform the
requested operation on a task.
-
SendRejectionMessage() : Send a message to the user
stating that his status is not
appropriate to perform the requested operation on a task.
-
GetTaskInfo() : Get the information
(attributes) provided by the user to
create a
task.
-
CheckTaskInfo() : Check whether the information
provided by the user to create a
task is sufficient.
-
SendInsufficientInfoMessage() : Send a message to the user stating that the
information provided is not sufficient to create
a
new task.
-
CreateTask() : Create a new task with
the information provided by
the user.
-
EditTask () : Let the user edit the
attributes of the task.
-
SaveNewTaskInformation() : Save the changes made on the task’s
attributes.
-
DeleteTask() : Delete completely a task
from the account.
User
Operation Module, Group Operation Module and Resource Operation Module all work
in a similar manner so we choose to explain them in this same section.
These
three modules are responsible for four kinds of action:
A
project manager should first create a new user profile inside a project and
then assign this new user to a task. He is also free to edit the attributes of
the user or delete completely the user profile from the account.
On
the other hand, a group of users might be created and be assigned to a task
inside a project. Again a project manager may create a group with already
existing user profiles in a project (like database group, hardware group etc…).
One can also create a group and then edit it, to add new users to the group for
example. Finally the whole group might be completely deleted by the project
manager.
As
a user and a group, a resource for a project might be created, edited, assigned
to a task (or to the whole project) and deleted.
The
methods related to these three modules function in the same manner as the ones
related to Project Operation and Task Operation Modules. The only different
method is Assign(task_number):
- Assign( task_number [INTEGER] ) : Assigns a user, a
group or a resource to a task. The
task to which one of these three will be assigned is determined by the argument task_number. If
task_number is zero, then the concerned user, group or resource is assigned to
the whole project not to a specific task.
We
provide in Figure 4.7 the flowchart
for Resource Operation Module. The flowcharts for User Operation and Group
Operation Modules are similar.
This
module is the part of the program running behind My Office Page [section 3.8]. My Office Module is responsible the
part of the system responsible for exposing correctly the features of My Office Page and for calling appropriate
functions or modules in order to perform necessary operations invoked by the
user in ‘his ofice2.
My
Office Module is quite similar to Display Project Module in its functioning. It
is invoked whenever a user clicks on My Office button on a page of ProjeX.
All the possible operations that a user might perform by means of Display
Project Module are also possible with My Office Module and they are performed
in the same way.
The system can be decomposed to the following packages which can be
implemented independently. These packages resemble and comply with the modules
whose detailed definitions have been made in the “Modules” section of the
report. The general system is composed of the packages seen in the below
diagram:
Ø
Packages for project/task/human
scheduling (General Project Management)
Ø
Packages for GUI
Ø
Packages for database
Ø
Packages for file
management
This package is the main package that requires user-interaction. The
inputs (either from user or other modules) are processed here. It consists of
the following sub-packages:
Ø Company worker management
¨ Group Leader
¨ Administrator
¨ Project Manager
¨ Project Developer(ordinary user)
Ø Project management
¨ Discussion forum
Ø Task management
Ø Group management
Ø Account management
¨ Sign-up
¨ login
Ø Statistics & performance evaluation
¨ Listing
¨ Status overview
¨ Filtering
Ø Resource Management
¨ Hardware Resources
¨ Software Resources
¨ Human Resources
¨ Other Resources
These component relationships can be summarized as
follows:
Instead of having hardware components, the tool is just software because
it is a web based program. Thus graphical user interfaces are very important to
orient the users. The users will see the links active if they have the
permission to use that link. The GUI is divided into the modules below:
Ø
Project member GUI
Ø
Project manager GUI
Ø
Project administrator
GUI
Ø
Non-project member GUI
The tool needs a database to keep the information belonging to different
instances. The basic entities can be grouped as below:
Ø Task database
Ø Group database
Ø Project database
Ø Resource database
One
can refer to the Class diagram of the system, if he/she wants to see the
relationships between the classes in the system and their methods and
properties as below:
The
Class Diagram above shows the relationships between classes in ProjeX.
The
ProjeX has been written utilizing the Microsoft .NET Visual Studio. The
programming languages used are : C
#.NET, ASP.NET and HTML.
The
page backgrounds (the basic GUI’s and buttons) were prepared using the
Photoshop and its layering functionality. Then these backgrounds are
implemented in to the system
The
file formats in the program are composed of two extensions:
Default.aspx
page is the default page where one can start the login process. This page links
to other pages whose names are self-explaining. Ex: CompanySignUp.aspx- with
coresponding CompanySignUp.aspx.cs,
CreateUserProfile.aspx with corresponding CreateUserProfile.aspx.cs ,
etc..
The
project that is created by the Visual Studio consists of Code , Data and Images
directories also. These directories include:
The
common controls used in every file:
System,System.Data,System.Configuration,System.Web,System.Web.Security,System.Web.UI,System.Web.UI.WebControls,System.Web.UI.WebControls.WebParts,
System.Web.UI.HtmlControls
Other than these default files, the files like “.cs”
extension files in the Code Directory are included in the files if required.
Below one can find the entity-relationship diagrams for
the database of ProjeX. The dashed lines in the diagrams show the
relationships set via the FOREIGN KEY’s among entities.
1) The following
figure shows the relations among COMPANY, ADMIN, PROJECT_MANAGER, PROJECTS and
TASKS entities which are set via the FOREIGN KEYS.
The tuples in PROJECTS
table have a CompanyID field, the projects and companies are associated via
that field. Similarly, the ProjectID fields in ADMIN and PROJECT_MANAGER tables
show who is admin or project manager in which project. Admin and project
manager are automatically associated with companies since every project is
associated with a company. Tasks are associated with projects with the
ProjectID field appearing in TASKS table.
PREDECESSORS relationship
associates each task with its predecessor.
2) The second
figure has got much to say. First of all it shows the relation between a group
and its members. The relation between USER_LOGIN_DATA and USERS table is set
via the foreign key UserID in the USER_LOGIN_DATA. So that after the user
enters the login information, the tool
can identify him correctly. The remaining part of the figure shows the
relations among projects, tasks, users and groups and the rights of users.
3) The following
last figure explains the relations of the RESOURCES entity with the others.
ProjeX allows users to associate a resource with a project, a task, a user or a
group. These relations are shown in the figure.
RESOURCES TASKS PROJECTS
Requirements
for the development :
The development environment: .NET Framework 2003 version
and Visual Studio .NET coming in with the 2003 version.
Database applications: MS SQL Server 2000 and Enterprise Manager
The operating system : Windows 2000/ME/XP