Sample FinalReport

Project Report
Mantaq Timetable Manager
A Project of Mantaq Solutions Pakistan
Submitted To: Dr. Arshad Ali Shahid

Submitted By: Mantaq Solutions, Group 12
January 10, 2004

Table of Contents
Introduction to Mantaq ............................................................................................ 1
The Team.............................................................................................................. 2
The Company Name............................................................................................. 2
Company Logo...................................................................................................... 2
Project Proposal....................................................................................................... 3
Project Name ........................................................................................................ 4
Client Introduction............................................................................................... 4
Goals and objectives............................................................................................. 4
Project Background.............................................................................................. 4
Target Audience ....................................................................................................5
Comparison with the previous system..................................................................5
Scope of the Project...............................................................................................5
Feasibility ..............................................................................................................5
Advantages ............................................................................................................5
Process Model .......................................................................................................... 6
Introduction ..........................................................................................................7
Purpose of This Document....................................................................................7
Process Model ...................................................................................................... 8
Meeting Minutes .................................................................................................10
Requirement Specification ..................................................................................... 11
Introduction ........................................................................................................12
Assumptions........................................................................................................12
Teacher Requirement Functions ........................................................................12
Physical Constraints............................................................................................13
Academic constraints ..........................................................................................13
Meeting Minutes .................................................................................................14
Data Flow Diagrams ............................................................................................... 15
Level 0 DFD.........................................................................................................16
Level 1 DFD ......................................................................................................... 17
Level 2 DFD.........................................................................................................18
Process 1 .................................................................................................................. 18
Process 2.................................................................................................................. 19
Process 3 .................................................................................................................. 20
Software Requirement Specification......................................................................21
Introduction ....................................................................................................... 22
Requirement specifications ...................................................................................... 23
Validate Physical Constraints Module ................................................................ 23
Validate Teacher Requirements Module ............................................................ 23
Validate Teacher Requirements Module ............................................................ 24
Validate Academic Constraints Module.............................................................. 25
Meeting Minutes ........................................................................................................ 26
Use Cases ................................................................................................................27
Purpose............................................................................................................... 28
i
UC-01 ........................................................................................................................... 29
UC-02........................................................................................................................... 30
UC-03........................................................................................................................... 31
UC-04........................................................................................................................... 32
UC-05........................................................................................................................... 33
UC-06........................................................................................................................... 34
UC-07 ........................................................................................................................... 35
Ranking of Use Cases................................................................................................. 36
Use Case Diagram ...................................................................................................... 37
Meeting Minutes ................................................................................................ 38
Domain Model ....................................................................................................... 39
Purpose of the document ................................................................................... 40
Domain model diagram ......................................................................................41
Check List ........................................................................................................... 42
Meeting minutes ................................................................................................ 43
System Sequence Diagrams................................................................................... 44
SD-01 Enter Physical Constraints...................................................................... 45
SD-02 Enter Academic Constraints................................................................... 45
SD-03 Enter Availability Time........................................................................... 46
SD-04 Modify Lecture Time .............................................................................. 46
SD-05 Modify Physical Constraints....................................................................47
SD-06 Modify Academic Constraints .................................................................47
SD-07 Show Timetable....................................................................................... 48
System Operations................................................................................................. 49
Contracts ................................................................................................................. 51
Contract 1: Enter Room Constraints.................................................................. 52
Contract 2: Enter Lab Constraints .................................................................... 53
Contract 3: Enter Projector Constraint.............................................................. 54
Contract 4: Enter Course Constraints ................................................................55
Contract 5:Enter University Constraint ............................................................ 56
Contract 6: Enter Availability Time ...................................................................57
Contract 7: Modify Lecture Time....................................................................... 58
Contract 8: Modify Room .................................................................................. 59
Contract 9: Add New Room ............................................................................... 60
Contract 10: Modify Labs....................................................................................61
Contract 11: Add New Labs ................................................................................ 62
Contract 12: Modify Section............................................................................... 63
Contract 13: Add Section to Course ................................................................... 64
Contract 14: Modify Projector............................................................................ 65
Contract 15: Modify Course Instructor .............................................................. 66
Contract 16: Modify Sections of Course..............................................................67
Contract 17: Modify Holidays ............................................................................ 68
Contract 18: Modify Official Hours.................................................................... 69
Contract 19: View Timetable .............................................................................. 70
Meeting Minutes ................................................................................................. 71
Real Use Cases ........................................................................................................72
UC-01...................................................................................................................73
ii
UC-02 ..................................................................................................................75
UC-03 ..................................................................................................................77
UC-04 ................................................................................................................. 78
UC-05 ..................................................................................................................79
UC-06 ................................................................................................................. 82
UC-07 ................................................................................................................. 84
Ranking of Use Cases ......................................................................................... 85
Use Case Diagram .............................................................................................. 86
Collaboration Diagrams......................................................................................... 87
Enter Room Constraints .................................................................................... 88
Enter Lab Constraints ........................................................................................ 88
Enter Projector Constraints ............................................................................... 88
Enter Course Constraints................................................................................... 89
Enter University Constraints ............................................................................. 89
Enter Availability Time ...................................................................................... 89
Modify Create Time............................................................................................ 90
Modify Room...................................................................................................... 90
Add New Room .................................................................................................. 90
Modify Labs.........................................................................................................91
Add New Labs .....................................................................................................91
Modify Section ....................................................................................................91
Add New Section To The Course........................................................................ 92
Modify Projector ................................................................................................ 92
Modify Course Instructor................................................................................... 92
Modify Sections of the Course ........................................................................... 93
Modify Holidays ................................................................................................. 93
Official Hours ..................................................................................................... 93
Class Diagram ........................................................................................................ 94
Meeting Minutes ................................................................................................ 96
iii
Introduction to Mantaq
1
The Team
Team Manager: Amir Touseef 425
Requirement Analyst: Naveed Ejaz Naveed 446
Manager Quality Assurance: Hamza Bin Zahid Lodhi 418
Manager Software Testing: Najm us Saqib Bajwa 436
Manager User Interface: Hafiz M. Kashif Naseer 416
Designers: Naveed Ejaz Naveed 446

Amir Touseef 425
Developers/ SW Engineers: Hafiz M. Kashif Naseer 416

Najm us Saqib Bajwa 436
Hamza bin Zahid Lodhi 418
The Company Name

“MANTAQ” is a Persian word which means “LOGIC”. Logic is a basic
element in Software Engineering and other Computer fields. A software
Engineer uses logic to develop software. So that’s why, we named our
company “Mantaq Solutions International”.
Company Logo
Our logo shows that behind every program or software, a ‘Mantaq’ (logic)
exist. The ones and zeros in the logo stand for the part of the software
invisible to the end users. And if we closely examine this invisible part, it is
simply based on ‘Mantaq’- that is, Logic.
2
Project Proposal
3
Project Name
Mantaq Timetable Manager (MTTM)
Client
National University of Computer and Emerging Sciences, Islamabad.
Client Introduction
The Foundation for Advancement of Science and Technology (FAST) was
established in 1980, as a private national institution.
Today it stands recognized as the leader and trendsetter in this field in Pakistan
and abroad. FAST has established the National University of Computer and
Emerging Sciences (NUCES) so as to expand the activities of existing institutes,
establish more campuses throughout the country, and to maintain its tradition of
academic excellence. The establishment of the university is a major step forward
in the technological progress of the country.
Goals and objectives

As we are doing this project as Software Engineering course project so our main
purpose is to learn the concepts of Software Engineering. This will not only
facilitate the academic office to make the timetable but also allows the students to
use their time more efficiently instead of having unnecessary gaps in their day
schedule.
Project Background
There are about six hundred students enrolled in Islamabad campus. On the
contrary the campus has only six lecture halls. In this scenario lecture scheduling
become very tedious job due to increasing number of students, year by year.
Nowadays the main problem faced by the students is the irregular timetable-with
long gaps of three to four tiring hours. We as the members of this community find
it our responsibility help the administration and students in this regard.
We contacted Mr. Ammanullah in this regard and he was kind enough to allow us
to develop a timetable manager, which would help us in lessening the grievances
of both the student community and Mr. Ammanullah.
4
Target Audience
Mr. Amanullah Khan, Academics officer, FAST-NUCES (Client)
Dr. Arshad Ali Shahid (Project Supervisor)
Mr. Muhammad Umair Hassan (Teaching Assistant)
Comparison with the previous system

Currently, time tables are generated by manual hit and trial method. No proper
algorithm is applied to generate the time tables. The process is time consuming,
tedious and leads to a lot of clashes. The concerned person-Mr. Amanullah has to
consider a lot of factors like faculty requirements, number of courses offered in
the semester etc.
The proposed system will be easy to use, will produce results quickly, and will
have minimum clashes. It will be very helpful for the academic office. It will save
a lot of effort and time.
Scope of the Project

Develop a software which generates a suitable timetable with minimum clashes
and maximum resource utilization.
Feasibility
As it is a complex problem, it needs a careful design and documentation. It is very
suitable for software engineering course because it will have a lot of design issues
and documentation.
Advantages
The main advantages of our system are:
• The documentation of software process will be maintained; hence any

Software Engineering Team can extend this application to build larger
applications.
• The precious time of administration and students would be saved.
5
Process Model
6
1.1. Introduction
Every software system developed requires proper software management and
modeling. For that purpose there are several process models for software
engineering, which help in carrying out a project effectively and efficiently
according to the project requirements. It is up to the software developers to
decide which process model to use, which suits their requirements the most.
Every system has different requirements and thus for every system a different
approach may be taken.
Since there are several process models available for this purpose , we have to
decide the process model which suits us most. Keeping in view the different
process models available for one that suits us most.
1.2. Purpose of This Document

the purpose of this is to define and describe the process model being used to carry
out the peoject TIME TABLE MANAGER within the given timeframe of four
months. This document will play a major role in future project development as it
lays the foundation for the process model being used. The document shall also
explain the reasons why we chose a particular process models and discuss the
advantages of using that process model with respect to our project.
7
2. Process Model
After much study and going through the merits and demerits of each process
model, the team has decided to use the “Iterative Model” for carrying out the
project TIME TABLE MANAGER.
The team discussed various possibilities to the project and tested different
process models upon these possibilities. Each model gave different results to
these possibilities and after much discussion Iterative Model was chosen.
2.1. Why Iterative Model?

As the project TTM is a semester project so we have only four months to complete
this project, we had to find a process model which would comply with our
requirements. After much deliberations it was decided that iterative model suited
us most.
The main reasons why we chose the iterative model as follows:
2.1.1. Modular Nature

Main reason for choosing iterative model was the divisible nature of project.
Since the project to be implemented is TTM, it is possible to divide it up into
increments, each increment adding certain functionality to the earlier
implemented increments.
2.1.2. Regular Update for The Client

It is highly convenient to keep the client updated by implementing the project in
increments. Thus the client can be regularly imformed about new updates in the
system and he would not have to wait till the very end of the entire system
2.1.3. NP-Nature of Project

TTM has a NP Complete Problem and has a lot of components to be
implemented. Moreover it is an NP Complete Problem so we cant produce an
100% efficient solution. Since many of the components can be implemented
separately and independtly of other components of others, so incremental model
was chosen.
8
2.1.4. Later Updates
The client can change or modify the requirements of the later increments anytime
he wants after looking at the existing increments. Thus the requirements for the
entire system are not frozen and infact design modifications can be made to the
later increments. The client can look at the delivered increments and specify
changes to the upcoming increments accordingly.
2.1.5. Analysis and Design

The A&D of each incremented will be carried out at the time that increment is
implemented. Thus there will be more time for the analysis and design of each
component separately rather than analyzing the entire system together at the
start.
2.1.6. Testing Would Be Easier

We can carry out extensive testing of each increment rather than testing the
entire system at the end. Testing an increment is much easier and more efficient
than testing the entire system together. Thus it would enable us to deliver a much
better product, which is more efficient.
9
3. Meeting Minutes
Venue:: University Café
Time: 11:00 am
Date: September 20th 2003
¾ The agenda of the meeting was to discuss and write the Process Model.
¾ Firstly, the different kinds of process models were discussed, which the
users of this system might have to go through.
¾ While discussing the process model the different kinds, we came to know
about the pros and cons.
¾ After much deliberations waterfall model was adopted
10
Requirement Specification
11
0. Introduction
The Time Table Manager (TTM) generates timetable based on the constraints
given. The academic officer will start the TTM and input all the physical and
academic constraints. Then he will give a deadline to the teachers to input their
availability constraints in the TTM. After the deadline has finished, the academic
officer will ask the TTM to generate the timetable. Now, the generated timetable
will be available in a graphical manner, and will be editable graphically. Every
one will have the read access including students. Every teacher will have the right
to change its own class schedule, provided he does not violate any constraints.
Every teacher should also be able to change his availability time. The academic
officer will have the complete write access. The academic officer should be able to
modify any of the constraints.
1. Assumptions
Assumption Function
#
A 1.1 The registration has finished
A 1.2 The students can still add / drop courses, may be to remove a
clash.
A 1.3 Most of the clashes are known
2. Teacher Requirement Functions

Teachers are an important resource of the university and their constrained and
requirements are given first preference in the schedule. As timetable will initially
made by the teachers so there are some important requirements concerning
teachers. Currently University has two types of teachers the permanent and the
visiting so their requirements can differ.
Req # Function
R 2.1 Teachers will enter their availability time and day based on their
personal requirements.
R 2.2 The availability time is greater than minimum time slot of a lecture.
R 2.3 The numbers of courses/sections taught by the teacher are entered.
R 2.4 Minimum gap between two successive lectures is notified.
R 2.5 Teacher’s Seniority should be considered when two teachers input
same availability time.
12
3. Physical Constraints
While making a decision the system should be taking into consideration some
physical constraints, failure of this may lead to serious consequences. The user
Dr. Arshad Ali Shahid proved to be a useful person. He being a faculty member
with a vast experience gave us some useful suggestions. He was of the opinion
that a teacher should be the one who should develop his own timetable, not that
he should be given time table by some one else. This practice is followed some
one of the best universities of world. Once the timetable has been developed it
should be made available online and any faculty member can make any changes
to the timetable (only of his own course).
Req Function
#
R 3.1 The system shall be able to allot the class rooms to a course based on the
actual no of class rooms present in the university campus
R 3.2 The system shall be able to allot the class rooms to a course after
considering the strength of students taking the course and the capacity
of the class room.
R 3.3 The system should highlight the potential courses with a possibility of
multimedia projector being used. The total no of multimedia projectors
present should be considered. Such courses should not be allotted the
same time period.
R 3.4 The System should be able to allot the Labs to a course which needs labs
based on the actual no of labs present in the campus.
4. Academic constraints
In our university Time Table is generated by the Academic section. Mr.
Amanullah in Academic section make timetable. The basic requirements needed
for him to make timetable without clashes are identified below
Requirement# Details
R 4.1 Number of Sections for each course should be known
R 4.2 Total Courses for each Semester must be entered first
R 4.3 Courses taught by teacher can not schedule simultaneously
R 4.4 University Hours should be known
R 4.5 Classes should be according to Batch Priorities
R 4.6 Strength of Section for each course
R 4.7 Nation wide Holidays in a week
R 4.8 Holiday for a Section on specific weekday
13
5. Meeting Minutes
Venue: Boys Common Room
Start Time: 9:50
End Time: 11:30
Date: October 07, 2003
¾ The agenda of the meeting was to discuss requirement specification document

of the project.
¾ Najum-us-Saqib proposed to allow all the faculty members to look for
possible changes in the time table.
¾ Hamza bin Zahid Lodhi proposed that faculty member should give their own
time table, further changes can be made in them.
¾ Mohammad Amir suggested that the academics officer would finalize the time
table and it would be editable.
¾ Naveed Ejaz and Hafiz Kashif scheduled a meeting with academics officer for
any further enhancements in the requirements.
¾ It was decided to circulate a document amongst all the team members to tell
them the progress made so far regarding the requirement team.
14
Data Flow Diagram
15
1. Level 0 DFD
16
2. Level 1 DFD
17
3. Level 2 DFD
3.1. Process 1
18
3.2 Process 2
19
3.3 Process 3
20
Software Requirement
Specification
21
1. Introduction
The document is the software requirement specification for the proposed system,
timetable manager.
1.1 Purpose of this document

The purpose of this document is to specify all the requirements for the Mantaq
timetabling system. The software designers should develop this system in
accordance with the requirements given in this specification. The specification
will give description of three modules of the system.
1.2 Definitions, acronyms, and abbreviations

SRS – software requirement specifications
TTM – timetable manager
1.3 Overview
In the following sections of this specification, three major modules of TTM will be
presented. First, the general product and its functions will be introduced. Second,
all detailed requirements of three modules will be specified.
22
2. Requirement specifications
2.1 Validate Physical Constraints Module
Function:
Checks the validity of the physical constraints entered by the academic officer to
generate the timetable.
Description:
The function ensures that the constraints entered by the academic officer are
valid.
Inputs:
The total no of classrooms, the amount of multimedia projector available, total no
of labs and the strength of students in each batch.
Source:
Academic officer will enter the physical constraints to the system.
Output:
Physical constraints are validated or not.
Destination:
After validation, the teacher constraints are input to the “wait for teacher”
module.
Requirements:
Information about the university.
Pre-conditions:
Registration of the students has been done. This is the module of the project.
Post-conditions:
All physical constraints are validated.
23
2.2 Validate Teacher Requirements Module
Function:
Checks the validity of the constraints entered by the teacher to generate the
timetable.
Description:
The function ensures that the constraints entered by the teacher are valid.
Inputs:
The availability time and day of the teacher, number of courses/sections taught
by the teacher, minimum gap the teacher wants between the two lectures.
Source:
teacher will enter the physical constraints to the system.
Output:
teacher constraints are validated or not.
Destination:
After validation, the teacher constraints are input to the “wait for teacher”
module.
Requirements:
Semester information, teacher’seniority.
Pre-conditions:
Registration of the students has been done. The academic officer has entered
physical and academic constraints.
Post-conditions:
All teacher constraints are validated,availability time and day, number of
courses/sections taught by the teacher, minimum gap the teacher wants between
the two lectures are valid.
24
2.3 Validate Academic Constraints Module
Function:
Checks the validity of the academic constraints entered by the academic officer to
make the TTM usable.
Description:
The function ensures that the constraints entered by the academic officer are valid.
Inputs:
The number of sections for each course, total number of courses offered in the
semester, course instructor for each course, university official hours, strength of
each batch and section, scheduled holidays of the university.
Source:
academic officer will enter the academic constraints based on the university
policies.
Output:
academic constraints are validated or not.
Destination:
After validation, the academic constraints are input to the “wait for teacher”
module.
Requirements:
Academic officer should be aware of the university policies.
Pre-conditions:
Registration of the students has been done. The academic officer has entered
physical constraints.
Post-conditions:
All academic constraints are validated, i.e. number of sections for each course,
total courses, courses taught by the teacher, university hours, strength of each
section, university holidays.
25
3. Meeting Minutes
Venue: Marriot hotel, Islamabad
Start time: 4:50
End time: 6:00
Date: October 11, 2003
Agenda: design of DFDs and SRS
¾ Firstly, the different kinds of use cases were discussed, which the users of
this system might have to go through.
¾ While discussing the use cases the different kinds of users of the system as
specified in the Requirement Specification Document were also
considered. Hence the actors were defined.
¾ The use cases were defined and described briefly with the information of
the actors related to that particular use case.
¾ Similarly all the use cases were defined discussed elaborated and written
down for further critical analysis.
¾ Out of all the real use cases, some use cases were selected for expansion
i.e. expanded use cases, as only the essential and primary are the ones to
be expanded earlier and were required for our first iteration.
¾ All of the use cases were finalized and put to paper.
26
Use Cases
27
Purpose
The purpose of this document is to write use cases of TTM. The use cases help to
describe and understand the requirements of the system.
28
UC-01
Use Case: Enter Physical Constraints.
Actor: Academics Officer.
Purpose: To input the physical constraints (e.g. no of class rooms etc.)
Overview: At the start of the semester, the academics officer enters the Physical
constraints. On completion, UC03 is started.
Type: Primary and essential
Typical Course of Events:
Actor Action System Response

1. This use case begins at the start of
semester.
2. The academic officer enters all the 3. TTM will store these constraints.
constraints into the system.
4. Academic officer will have to wait
for other constraints to be entered
by other actors (faculty members
in this case).
Alternative Courses
¾ Line 2: Invalid Constraints entered: Indicate Error and prompt for input
again.
29
UC-02
Use Case: Enter Academic Constraints
Actors(s): Academic Officers
Purpose: Capturing Constraints based on university policies.
Overview: Academic Officer enters the Number of Sections for each
course, Total number of courses offered in semester, Clash
between the courses, Course Instructor for each course,
University official hours, Strength of each section and batch,
weekly holidays of the university
Type: Primary and Essential.
Cross Reference: R2.3

1. This use case begins when
semester starts.
2. The academic officer enters all the 3. TTM (timetable manager) will store
constraints into the system. these constraints for use at the time
of timetable generation.
Alternative Courses
again.
30
UC-03
Use Case: Enter Availability Time
Actor(s): Faculty Members, Academics officers
Purpose: To input the teacher’s availability Time for lectures
Overview: The faculty member will input his/her availability time for
lectures through the GUI. The teacher will highlight different
time slots for his/her lecture hours.
Cross Reference:

1. This use case begins when the
Physical constraints (UC01)
and Academic constraints
(UC02) have been entered.
2. The faculty member enters 3. TTM (timetable manager) will store
his availability time through these constraints for use at the time of
GUI. timetable generation.
Alternative Courses:
¾ Line 2: Entered Time violates any constraints: Indicate Error.
31
UC-04
Use Case: Modify Lecture time
Actors(s): Faculty Members, Academics officers
Purpose: Capture any change in class timings by the teacher.
Overview: Teacher changes the time visually by dragging on to the
desired time. System checks the validity of this time.
Type: Primary and Essential
Cross Reference:

1. This use case begins when teacher
wants to change his class time.
2. The teacher will enter new time of 3. TTM will check this time against
the class on the time table. physical and academic constraints
and validate this entered time.
4. If the entered time is validated and
no clash occurs and no physical
constraint violated then see
Section A
5 If some clash occurs or some
physical constraint validated then
see Section B.
Section A
If the entered time is valid TTM will change the timing of the class, timetable is
updated and made available to the users.
Section B
If some clash occurs at that time then clash and its reason are reported to the
teacher and he is asked to input another time.
Alternative Courses
Line 2: Invalid time entered here. Input again.
32
UC-05
Use Case: Modify Physical Constraints
Actor: Academics Officer
Purpose: To Change any physical constraints (e.g. no of class rooms etc.)
Overview: within the semester, the academics officer can change the Physical
Typical Course of Events

1. This use case begins when some
change in physical constraint
occurs.
2. The academic officer will enter any 3. TTM (timetable manager) will store
changed physical constraints into changed constraints.
the system.
by other actors(faculty members in
this case).
Alternative Courses
Line 2: Invalid Constraints entered: Indicate Error and prompt for
input again.
33
UC-06
Use Case: Modify Academic Constraints
Purpose: Modify Academic constraints based on any change in
university policies.
Overview: Academic Officer can enter any change in the academic
constraints e.g. Number of Sections for each course, Total
number of courses offered in semester, Clash between the
courses, Course Instructor for each course, University official
hours, Strength of each section and batch, weekly holidays of
the university etc.

1. This use case begins when any
change in academic constraints
occurs (due to change in university
policy.)
2. The academic officer new 3. TTM (timetable manager) will store
academic constraints into the changed constraints.
system.
4. Academic officer will wait for other
constraints to be entered by other
actors.
Alternative Courses
input again.
34
UC-07
Use Case: View Timetable
Actors(s): Students, Teachers, Academic officer
Purpose: To view the intermediate table based on the constraints
entered by
The academic officer.
Overview: When academic officer enters courses and academic
constraints an intermediate timetable is generated.
Type: Primary
35
Ranking of Use Cases
Rank Use Case Justification
High • Enter physical constraints Without these constrarits,

• Enter Academic the system will not work
Constraints
• Enter Availability Time
Mediu • Modify physical Maybe the user has to change

m constraints the requirements during the
• Modify Academic system.
Constraints
• Modify Availability Time
• Change lecture time
Low • View timetable The students, faculty
members & academic officer
will obviously view the
timetable.
36
Use Case Diagram
37
Meeting Minutes
Venue:: Nawaz Sharif Park, Rawalpindi.
Start Time: 3:00 pm
End Time: 6:30 pm
Date: October 26th 2003
¾ The agenda of the meeting was to discuss and write the Use Cases.
¾ Firstly, the different kinds of use cases were discussed, which the users of
this system might have to go through.
¾ While discussing the use cases the different kinds of users of the system as
specified in the Requirement Specification Document were also
considered. Hence the actors were defined.
¾ The use cases were defined and described briefly with the information of
the actors related to that particular use case.
38
Domain Model
39
Purpose of the document
The purpose of this document is to decompose the domain of the project. During this
decomposition concept, attributes and association were identified. This helped us in
better understanding of the whole problem domain.
40
Domain model diagram
41
Check List
Category Examples
A is a physical part of B
A is a logical part of B Course – teacher
Course – lecture
Lecture – room
Lecture – lab
A is physically contained in/on B
A is logically contained in B Time slot – timetable
Section – course
A is a description for B
A is a line item of a transaction or
report B
A uses or manages B Academic officer – timetable
Teacher – timetable
Teacher – timeslot
Teacher – lecture
A communicates B Academic officer – clash
A is an organizational subunit of B
A is a member of B Course – timetable
A is known / logged/ captured in B
A is related to a transaction B
A is next to B
A is owned by B
42
Meeting minutes
Venue:: FAST café
Start Time: 3:00 pm
End Time: 6:30 pm
Date: September 30th 2003
¾ The agenda of the meeting was to discuss the domain model.

¾ The domain model was defined and described briefly.
43
System Sequence
Diagrams
44
SD-01 Enter Physical Constraints
SD-02 Enter Academic Constraints
45
SD-03 Enter Availability Time
SD-04 Modify Lecture Time
46
SD-05 Modify Physical Constraints
SD-06 Modify Academic Constraints

‘ ‘
SYSTEM
Faculty Academic
Member Officer
ModifyUniversityConstraints (StartTime, EndTime, Holidays)
AddNewSection (Course, SectionName, Strength)
ModifySection (Course, SectionName, Strength)
ModifyCourseInstructor (Course, Instructor)
ModifyHolidays (Holidays)
ModifyOfficialHours (StartTime,EndTime)
EnterNewAcademicConstraints(AcademicConstraints)
47
SD-07 Show Timetable
48
System Operations
49
1. Enter Room Constraints (Number of Rooms)
2. Enter Lab Constraints (Number of Labs)
3. Enter Projector Constraints(Number of Projectors)
4. Enter Course Academic Constraints (Course ID, Course Name,
Course Credit Hours, Course Instructor, Sections of the course,
Section strength)
5. Enter University Constraints (Start Time, End Time, Holidays)
6. Enter Availability Time (Start Time, End Time)
7. Modify Lecture Time (Start Time, End Time)
8. Modify Room (Room Number, Capacity)
9. Add New Room (Room Number, Capacity)
10. Modify Labs (Lab Name, Capacity)
11. Add New Lab (Lab Name, Capacity)
12. Modify Section (Course, Section Name, Strength)
13. Add New Section to the Course (Course, Section Name, Strength)
14. Modify Projector (Number of Projectors)
15. Modify Course Instructor (Course Instructor)
16. Modify Sections of the Course (No. Of Sections of the course, Section
Strength)
17. Modify Holidays (Holidays)
18. Modify Official Hours (Start Time, End Time)
19. View Timetable ()
50
Contracts
51
Contract 1: Enter Room Constraints
Name:
Enter Room Constraints (Number of Rooms)
Responsibility:
To capture the room constraints of the University.
Type:
System
Exceptions:
If some invalid constraints are entered indicate error.
Cross Reference:
Use Case: UC-01 Enter Physical Constraints
R 3.1, R 3.2
Output:
Room constraints are validated and stored in the system.
Pre-conditions:
Registration of the students has been done.
Post-conditions:
¾ A new instance of Time Slot is created with attributes set to the parameters
entered.
¾ A new instance of Time Table is generated.
¾ For each room entered a new instance of Room is created.
¾ An association between each room and academic officer is created.
52
Contract 2: Enter Lab Constraints
Name:
Enter Lab Constraints (Number of Labs)
Responsibility:
To capture the lab constraints of the University.
Type:
System
Exceptions:
Cross Reference:
R 3.4
Output:
Lab constraints are validated and stored in the system.
Pre-conditions:
Post-conditions:
¾ The instance of Time Slot is modified with attributes set to the parameters
entered.
¾ An instance of Time Table is modified.
¾ For each lab entered a new instance of Lab is created.
¾ An association between each lab and academic officer is created.
53
Contract 3: Enter Projector Constraint
Name:
Enter Projector Constraints (Number of Labs)
Responsibility:
To capture the projector constraints of the University.
Type:
System
Exceptions:
Cross Reference:
R 3.3
Output:
Projector constraints are validated and stored in the system.
Pre-conditions:
Post-conditions:
¾ The instance of Time Slot is modified with attributes set to the parameters
entered.
¾ An instance of Time Table is modified.
¾ An instance of projector is created.
¾ An association of Projector and Academic officer is formed.
54
Contract 4: Enter Course Constraints
Name:
Enter Course Constraints (Course ID, Course Name, Course Credit Hours,
Course Instructor, Sections of the course, Section strength)
Responsibility:
To capture the course related academic constraints of the University.
Type:
System
Notes:
Total Courses is kept as static variable. With each new course added it is
incremented.
Exceptions:
Cross Reference:
Use Case: UC-02 Enter Academic Constraints
R 4.2, R 4.3
Output:
Academic constraints are validated and stored in the system.
Pre-conditions:
Registration of the students has been done. Physical constraints have been
entered.
Post-conditions:
¾ A new instance of Course is created with attributes set to input
parameters.
¾ For each Section for each course a new instance of Section is created.
¾ An association of each class instance is built with Section instance.
55
Contract 5:Enter University Constraint
Name:
Enter University Constraints (Start Time, End Time, Holidays)
Responsibility:
Get the constraints of the University. System should know the official
hours and holidays to generate timetable.
Type:
System
Exceptions:
Cross Reference:
Use Case: UC-02 Enter Academic Constraints
R 4.4
Output:
Academic constraints are validated and stored in the system.
Pre-conditions:
Registration of the students has been done. Physical constraints have been
entered.
Post-conditions:
¾ Time Slot instance is modified based on the new constraints.
¾ Attribute modification in Time Table instance based on the new
constraints entered.
56
Contract 6: Enter Availability Time
Name:
Enter Availability Time (Start Time, End Time)
Responsibility:
To get the availability time of teacher so that time table can be generated
based on teacher preferences.
Type:
System
Exceptions:
If a time, violating physical or academic constraints is entered then
indicate error.
Cross Reference:
Use Case: UC-03 Enter Availability Time
R 2.1, R 2.2, R 2.3
Output:
Entered time is validated and stored in the system.
Pre-conditions:
Registration of the students has been done. Physical and academic
constraints have been entered.
Post-conditions:
¾ For each availability time entered a new attribute of Availability Time is
created holding start and end timing of that slot.
¾ An association between Availability time and Teacher is formed.
¾ Time Slot instance is changed.
¾ Time Table instance is changed.
57
Contract 7: Modify Lecture Time
Name:
Modify Lecture Time (Start Time, End Time)
Responsibility:
Modify the timings of a lecture in the timetable.
Type:
System
Exceptions:
If a time violating physical or academic constraints is given then indicate
error. If a clash occurs then an error and reason of clash is reported.
Cross Reference:
Use Case: UC-04 Modify Lecture Time
R 2.2
Output:
Entered time is validated and stored in the system.
Pre-conditions:
constraints have been entered. Lecture timing is already there in the
timetable.
Post-conditions:
¾ Time Slot instance is changed and its attributes are set to the parameters
entered.
¾ Time Table instance is changed.
58
Contract 8: Modify Room
Name:
Modify Room (Room Number, Capacity)
Responsibility:
Change the room capacity. (Of already existing room)
Type:
System
Exceptions:
If some invalid capacity (number) entered then indicate error.
Cross Reference:
Use Case: UC-05 Modify Physical Constraints
R 3.1
Output:
Room input is validated and updated in the system.
Pre-conditions:
constraints have been entered. Some change in physical constraints is
required.
Post-conditions:
Room instance is modified. Attributes set to the input parameters.
59
Contract 9: Add New Room
Name:
Add New Room (Room Number, Capacity)
Responsibility:
Adds new room to the system.
Type: System
Exceptions:
If some invalid capacity (number) or already existing room number is
entered then indicate error.
Cross Reference:
R 3.2
Output:
Room input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
¾ A new Room instance is instantiated.
¾ Room is associated with academic officer.
60
Contract 10: Modify Labs
Name: Modify Labs (Lab Name, Capacity)
Responsibility:
Change the lab capacity of the given lab name. (Of already existing lab)
Type:
System
Exceptions:
If some invalid capacity or name entered then indicate error.
Cross Reference:
R 3.4
Output:
Lab input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
Lab instance is modified. Attributes set to the input parameters.
61
Contract 11: Add New Labs
Name:
Add New Lab (Lab Name, Capacity)
Responsibility:
Adds a new lab to the system with given name and capacity.
Type:
System
Exceptions:
If some invalid capacity or name entered then indicate error.
Cross Reference:
R 3.4
Output:
Lab input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
¾ A new Lab instance is created with attributes set to the input parameters.
¾ Association between lab and academic officer is made.
62
Contract 12: Modify Section
Name:
Modify Section (Course, Section Name, Strength)
Responsibility:
Change the Section strength of a given course. (Of already existing section)
Type:
System
Exceptions:
If some invalid name or strength entered then indicate error.
Cross Reference:
R 4.6
Output:
Section input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
¾ Section instance is modified. Attributes set to the input parameters.
¾ Course instance is modified.
¾ Timetable may be modified based on strength as system can arrange
lecture in a room with less capacity.
63
Contract 13: Add Section to Course
Name:
Add New Section to the Course (Course, Section Name, Strength)
Responsibility:
Adds a new Section to the given course (Of already existing Course)
Type:
System
Exceptions:
If some invalid name or strength entered then indicate error.
Cross Reference:
Use Case: UC-06 Modify Academic Constraints
R 4.6
Output:
Section input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
¾ A new Section instance is created. Attributes set to the input parameters.
¾ Course instance is modified.
¾ Timetable instance is modified to allot slots to the new section.
¾ Association between class and section is made.
64
Contract 14: Modify Projector
Name:
Modify Projector (Number Of Projectors)
Responsibility:
Change the number of projectors in the system if a new projector is added
to the system.
Type:
System
Exceptions:
If some invalid number is entered then indicate error.
Cross Reference:
R 3.3
Output:
Projector input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
Projector instance is modified. Attributes set to the input parameters.
65
Contract 15: Modify Course Instructor
Name:
Modify Course Instructor (Course Instructor)
Responsibility:
Change the Course Instructor if required.
Type:
System
Exceptions:
If some invalid name is entered then indicate error.
Cross Reference:
Output:
Course input is validated and updated in the system.
Pre-conditions:
constraints have been entered. Some change in academic constraints is
required.
Post-conditions:
Course instance is modified. Attribute Instructor Name set to the input
parameters.
66
Contract 16: Modify Sections of Course
Name:
Modify Sections of the Course (No. Of Sections of the course, Section
Strength)
Responsibility:
Change the Course sections if required.
Type:
System
Exceptions:
If some invalid section information is entered then indicate error.
Cross Reference:
R 4.1
Output:
Course input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
Course instance is modified. Attribute Instructor Name set to the input
parameters.
67
Contract 17: Modify Holidays
Name:
Modify Holidays (Holidays)
Responsibility:
Change the official holidays Information.
Type:
System
Exceptions:
If some invalid day entered then indicate error.
Cross Reference:
R 4.8
Output:
Input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
Time Slot instance is modified. Holiday attributes set to the input
parameters.
68
Contract 18: Modify Official Hours
Name:
Modify Official Hours (Start Time, End Time)
Responsibility:
Change the holidays or official hours Information.
Type:
System
Exceptions:
If some invalid timing entered then indicate error.
Cross Reference:
R 4.4
Output:
Input is validated and updated in the system.
Pre-conditions:
required.
Post-conditions:
Time Slot instance is modified. Time attributes set to the input
parameters.
69
Contract 19: View Timetable
Name:
View Timetable ()
Responsibility:
To view the intermediate timetable based on the constraints entered by the
academic officer.
Type:
System
Exceptions:
If timetable is not ready then give an error.
Cross Reference:
Use Case: UC-07 View Timetable
Output:
Visual timetable is shown on to the screen.
Pre-conditions:
required.
Post-conditions:
Time Table instance is shown on to the screen.
70
Meeting Minutes
Venue: Melody Food Park
Start Time: 5:30
End Time: 9:00
Date: November 10, 2003
¾ The agenda of the meeting was to discuss system sequence diagram,

system operations and contracts.
¾ Najum-us-Saqib proposed to first review all the use cases in detail.
¾ All the Use Cases were re-examined in detail.
¾ Domain Model was re-considered.
¾ Hamza bin Zahid Lodhi proposed to make system sequence diagrams in
one go and then everyone must re-consider it at home and discuss it.
¾ Muhammad Aamir suggested discussing each system operation separately.
¾ During meeting we enjoyed Aftar as well.
71
Real Use Cases
72
UC-01
Use Case: Enter Physical Constraints.
Actor: Academics Officer.
Purpose: To input the physical constraints (e.g. no of class rooms etc.)
Overview: At the start of the semester, the academics officer enters the Physical
Form # 1
Form # 2
Form # 3
73

1. This use case begins at the start of
semester.
2. The academic officer enters the

number of class rooms in A on
Form # 1.

number of labs in B on Form # 1.

number of projectors in C on
Form # 1.
5. The academic officer presses the 6. The TTM stores the constraints in
OK button D on Form # 1. the system.
7. Form # 2 will appear for that

number of times which the
academic officer has entered in A
of Form # 1.

room no in A of Form # 2

corresponding capacity of the
room in B of Form # 2.
OK button C on Form # 2. the system.

academic officer has entered in B
of Form # 1.

Lab Name in A of Form # 3.

corresponding capacity of the lab
in B of Form # 3.
74

in this case).
Alternative Courses
again.
UC-02
Use Case: Enter Academic Constraints
Purpose: Capturing Constraints based on university policies.
Overview: Academic Officer enters the Number of Sections for each
course, Total number of courses offered in semester, Clash
between the courses, Course Instructor for each course,
University official hours, Strength of each section and batch,
weekly holidays of the university
Type: Primary and Essential.
Form # 4
75

1. This use case begins when
semester starts.
start time in A on Form # 4.

End time in B on Form # 4.

Holiday 1 in C on Form # 4.

Holiday 2 in D on Form # 4.

Holiday 3 in E on Form # 4.
7. The academic officer presses the 8. TTM (timetable manager) will

OK button F on Form # 1. store these constraints for use at
the time of timetable generation.
Alternative Courses
again.
76
UC-03
Use Case: Enter Availability Time
Actor(s): Faculty Members, Academics officers
Purpose: To input the teacher’s availability Time for lectures
Overview: The faculty member will input his/her availability time for
lectures through the GUI. The teacher will highlight different
time slots for his/her lecture hours.
Cross Reference:

2. The faculty member enters
his Start availability time in
Field A.
his End availability time in these constraints for use at the time of
Field B. timetable generation.
Alternative Courses:
¾ Line 2: Entered Time violates any constraints: Indicate Error.
77
UC-04
Use Case: Modify Lecture time
Actors(s): Faculty Members, Academics officers
Purpose: Capture any change in class timings by the teacher.
Overview: Teacher changes the time visually by dragging on to the
desired time. System checks the validity of this time.
Cross Reference:

2. The faculty member enters
his New Start availability time
in Field A.
his New End availability time these constraints for use at the time of
in Field B. timetable generation.
Section A
If the entered time is valid TTM will change the timing of the class, timetable is
updated and made available to the users.
Section B
If some clash occurs at that time then clash and its reason are reported to the
teacher and he is asked to input another time.
Alternative Courses
Line 2: Invalid time entered here. Input again.
78
UC-05
Use Case: Modify Physical Constraints
Actor: Academics Officer
Purpose: To Change any physical constraints (e.g. no of class rooms etc.)
Overview: within the semester, the academics officer can change the Physical
Typical Course of Events
FORM # 1
79
FORM # 2
FORM # 3

actor has already entered the
Physical constraints
2. To modify Room actor will select A new window will pop up, in
the B Option. which user can enter new room
information.
3. To modify Labs actor will select A new window will pop up, in
the C Option. which user can enter new Lab
information.
number of new class rooms in A
on Form # 1.

number of labs in B on Form # 1.

number of projectors in C on
Form # 1.
OK button D on Form # 1. the system.
80
academic officer has entered in A
of Form # 1.

room no in A of Form # 2

corresponding capacity of the
room in B of Form # 2.

academic officer has entered in B
of Form # 1.

Lab Name in A of Form # 3.

corresponding capacity of the lab
in B of Form # 3.

in this case).
Alternative Courses
input again.
81
UC-06
Use Case: Modify Academic Constraints
Purpose: Modify Academic constraints based on any change in
university policies.
Overview: Academic Officer can enter any change in the academic
constraints e.g. Number of Sections for each course, Total
number of courses offered in semester, Clash between the
courses, Course Instructor for each course, University official
hours, Strength of each section and batch, weekly holidays of
the university etc.
Form # 4
82
1. This use case Academic Officer
has already entered the Academic
Constraints.
2. To modify a section Academic
Officer will select the option C.
3. To modify a section Academic
Officer will select the option D.
start time in A on Form # 4.
5.. The academic officer enters the
End time in B on Form # 4.

Holiday 1 in C on Form # 4.

Holiday 2 in D on Form # 4.

Holiday 3 in E on Form # 4.
9. The academic officer presses the 10. TTM (timetable manager) will
OK button F on Form # 1. store these constraints for use at
the time of timetable generation.
Alternative Courses
input again.
83
UC-07
Use Case: View Timetable
Actors(s): Students, Teachers, Academic officer
Purpose: To view the intermediate table based on the constraints
entered by
The academic officer.
Overview: When academic officer enters courses and academic
constraints an intermediate timetable is generated.
Type: Primary
84
Ranking of Use Cases
Rank Use Case Justification
High • Enter physical constraints Without these constrarits,

• Enter Academic the system will not work
Constraints
• Enter Availability Time
Mediu • Modify physical Maybe the user has to change

m constraints the requirements during the
• Modify Academic system.
Constraints
• Modify Availability Time
• Change lecture time
Low • View timetable The students, faculty
members & academic officer
will obviously view the
timetable.
85
Use Case Diagram
86
Collaboration Diagrams
87
01. Enter Room Constraints
02. Enter Lab Constraints
88
04. Enter Course Constraints
05. Enter University Constraints
06. Enter Availability Time
89
07. Modify Create Time
08. Modify Room
09. Add New Room
90
10. Modify Labs
11. Add New Labs
12. Modify Section
91
13. Add New Section To The Course
14. Modify Projector
15. Modify Course Instructor
92
16. Modify Sections of the Course
17. Modify Holidays
18. Official Hours
93
Class Diagram
94
95
Meeting Minutes
Venue: Najum’s House
Start Time: 5:30
End Time: 9:00
Date: November 29,2003
¾ The agenda of the meeting was to discuss real use cases, collaboration
diagrams and class diagrams.
¾ Naveed proposed to first review all the use cases in detail.
¾ All the Use Cases were transformed into Real Use Cases.
¾ Real Use Cases were examined individually by all group members.
¾ Hamza bin Zahid Lodhi proposed to make collaboration diagrams and
class diagrams in one go.
¾ Muhammad Amir finalized the document.
96

Sample FinalReport

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sample FinalReport

Încărcat de

Drepturi de autor:

Formate disponibile

Project Report

Mantaq Timetable Manager

A Project of Mantaq Solutions Pakistan

Submitted To: Dr. Arshad Ali Shahid

January 10, 2004

Requirement Analyst: Naveed Ejaz Naveed 446

Manager Quality Assurance: Hamza Bin Zahid Lodhi 418

Manager Software Testing: Najm us Saqib Bajwa 436

Manager User Interface: Hafiz M. Kashif Naseer 416

Designers: Naveed Ejaz Naveed 446

Developers/ SW Engineers: Hafiz M. Kashif Naseer 416

The Company Name

Goals and objectives

Comparison with the previous system

Scope of the Project

• The documentation of software process will be maintained; hence any

1.2. Purpose of This Document

2.1. Why Iterative Model?

The main reasons why we chose the iterative model as follows:

2.1.1. Modular Nature

2.1.2. Regular Update for The Client

2.1.3. NP-Nature of Project

2.1.5. Analysis and Design

2.1.6. Testing Would Be Easier

Date: September 20th 2003

2. Teacher Requirement Functions

¾ The agenda of the meeting was to discuss requirement specification document

1.1 Purpose of this document

1.2 Definitions, acronyms, and abbreviations

2.1 Validate Physical Constraints Module

Typical Course of Events:

Actor Action System Response

Typical Course of Events:

Actor Action System Response

Typical Course of Events:

Actor Action System Response

Typical Course of Events:

Actor Action System Response

Typical Course of Events

Actor Action System Response

Typical Course of Events:

Actor Action System Response

High • Enter physical constraints Without these constrarits,

Mediu • Modify physical Maybe the user has to change

Start Time: 3:00 pm

End Time: 6:30 pm

Date: October 26th 2003

Start Time: 3:00 pm

End Time: 6:30 pm

Date: September 30th 2003

¾ The agenda of the meeting was to discuss the domain model.

SD-02 Enter Academic Constraints

SD-04 Modify Lecture Time

SD-06 Modify Academic Constraints

ModifyUniversityConstraints (StartTime, EndTime, Holidays)

AddNewSection (Course, SectionName, Strength)

ModifySection (Course, SectionName, Strength)

ModifyCourseInstructor (Course, Instructor)

¾ The agenda of the meeting was to discuss system sequence diagram,

Actor Action System Response

2. The academic officer enters the

3. The academic officer enters the

4. The academic officer enters the

7. Form # 2 will appear for that