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 Amir Touseef

446 425

Developers/ SW Engineers:

Hafiz M. Kashif Naseer Najm us Saqib Bajwa Hamza bin Zahid Lodhi

416 436 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 # A 1.1 A 1.2 A 1.3

Function The registration has finished The students can still add / drop courses, may be to remove a clash. 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 # R 2.1 R 2.2 R 2.3 R 2.4 R 2.5

Function Teachers will enter their availability time and day based on their personal requirements. The availability time is greater than minimum time slot of a lecture. The numbers of courses/sections taught by the teacher are entered. Minimum gap between two successive lectures is notified. 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 # R 3.1 R 3.2 R 3.3

R 3.4

Function 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 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. 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. 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# R 4.1 R 4.2 R 4.3 R 4.4 R 4.5 R 4.6 R 4.7 R 4.8

Details Number of Sections for each course should be known Total Courses for each Semester must be entered first Courses taught by teacher can not schedule simultaneously University Hours should be known Classes should be according to Batch Priorities Strength of Section for each course Nation wide Holidays in a week 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: Actor: Purpose: Overview: Type:

Enter Physical Constraints. Academics Officer. To input the physical constraints (e.g. no of class rooms etc.) At the start of the semester, the academics officer enters the Physical constraints. On completion, UC03 is started.

Primary and essential

Typical Course of Events:

Actor Action 1. 2. 4.

System Response

This use case begins at the start of semester. The academic officer enters all the 3. TTM will store these constraints. constraints into the system. 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): Purpose: Overview:

Academic Officers Capturing Constraints based on university policies. 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 Typical Course of Events:

Actor Action 1. 2.

System Response

This use case begins when semester starts. 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 ¾ Line 2: Invalid Constraints entered: Indicate Error and prompt for input again.

30

UC-03 Use Case: Actor(s): Purpose: Overview: Type: Cross Reference:

Enter Availability Time Faculty Members, Academics officers To input the teacher’s availability Time for lectures 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. Primary and essential

Typical Course of Events:

1.

2.

Actor Action This use case begins when the Physical constraints (UC01) and Academic constraints (UC02) have been entered. The faculty member enters 3. his availability time through GUI.

System Response

TTM (timetable manager) will store these constraints for use at the time of timetable generation.

Alternative Courses: ¾ Line 2: Entered Time violates any constraints: Indicate Error.

31

UC-04 Use Case:

Modify Lecture time

Actors(s): Purpose: Overview:

Faculty Members, Academics officers Capture any change in class timings by the teacher. Teacher changes the time visually by dragging on to the desired time. System checks the validity of this time. Primary and Essential

Type: Cross Reference:

Typical Course of Events: Actor Action 1. 2. 4.

5

System Response

This use case begins when teacher wants to change his class time. 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. If the entered time is validated and no clash occurs and no physical constraint violated then see Section A 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: Actor: Purpose: Overview: Type:

Modify Physical Constraints Academics Officer To Change any physical constraints (e.g. no of class rooms etc.) within the semester, the academics officer can change the Physical constraints. On completion, UC03 is started.

Primary and essential

Typical Course of Events

Actor Action 1. 2. 4.

System Response

This use case begins when some change in physical constraint occurs. The academic officer will enter any 3. TTM (timetable manager) will store changed physical constraints into changed constraints. the system. 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.

33

UC-06 Use Case:

Modify Academic Constraints

Actors(s): Purpose:

Academic Officers 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. Type: Primary and Essential Cross Reference: R2.3

Typical Course of Events: Actor Action 1.

2. 4.

System Response

This use case begins when any change in academic constraints occurs (due to change in university policy.) The academic officer new 3. TTM (timetable manager) will store academic constraints into the changed constraints. system. Academic officer will wait for other constraints to be entered by other actors.

Alternative Courses ƒ Line 2: Invalid Constraints entered: Indicate Error and prompt for input again.

34

UC-07 Use Case:

View Timetable

Actors(s): Purpose: entered by

Students, Teachers, Academic officer To view the intermediate table based on the constraints

Overview: Type:

The academic officer. When academic officer enters courses and academic constraints an intermediate timetable is generated. Primary

35

Ranking of Use Cases Rank High

Use Case • • •

Mediu m

• •

Low

• • •

Justification

Enter physical constraints Without these constrarits, the system will not work Enter Academic Constraints Enter Availability Time Modify physical constraints Modify Academic Constraints Modify Availability Time Change lecture time View timetable

Maybe the user has to change the requirements during the system.

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

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 A is a physical part of B A is a logical part of B

A is physically contained in/on B A is logically contained in B A is a description for B A is a line item of a transaction or report B A uses or manages B

A communicates B A is an organizational subunit of B A is a member of B A is known / logged/ captured in B A is related to a transaction B A is next to B A is owned by B

Examples Course – teacher Course – lecture Lecture – room Lecture – lab Time slot – timetable Section – course

Academic officer – timetable Teacher – timetable Teacher – timeslot Teacher – lecture Academic officer – clash Course – timetable

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

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 ‘

‘

Faculty Member

Academic Officer

SYSTEM

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: If some invalid constraints are entered indicate error.

Cross Reference: Use Case: UC-01 Enter Physical Constraints R 3.4

Output: Lab constraints are validated and stored in the system.

Pre-conditions: Registration of the students has been done.

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: If some invalid constraints are entered indicate error.

Cross Reference: Use Case: UC-01 Enter Physical Constraints

R 3.3 Output:

Projector constraints are validated and stored in the system.

Pre-conditions: Registration of the students has been done.

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: If some invalid constraints are entered indicate error.

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: If some invalid constraints are entered indicate error.

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: Registration of the students has been done. Physical and academic 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: Registration of the students has been done. Physical and academic 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: Use Case: UC-05 Modify Physical Constraints R 3.2

Output: Room input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in physical constraints is 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: Use Case: UC-05 Modify Physical Constraints R 3.4

Output: Lab input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in physical constraints is 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: Use Case: UC-05 Modify Physical Constraints R 3.4

Output: Lab input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in physical constraints is 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: Use Case: UC-05 Modify Physical Constraints R 4.6

Output: Section input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in physical constraints is 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: Registration of the students has been done. Physical and academic constraints have been entered. Some change in physical constraints is 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: Use Case: UC-05 Modify Physical Constraints R 3.3

Output: Projector input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in physical constraints is 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: Use Case: UC-06 Modify Academic Constraints

Output: Course input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic 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: Use Case: UC-06 Modify Academic Constraints R 4.1

Output: Course input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic 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.

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: Use Case: UC-06 Modify Academic Constraints R 4.8

Output: Input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in academic constraints is 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: Use Case: UC-06 Modify Academic Constraints R 4.4

Output: Input is validated and updated in the system.

Pre-conditions: Registration of the students has been done. Physical and academic constraints have been entered. Some change in academic constraints is 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: Registration of the students has been done. Physical and academic constraints have been entered. Some change in academic constraints is 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: Actor: Purpose: Overview: Type:

Enter Physical Constraints. Academics Officer. To input the physical constraints (e.g. no of class rooms etc.) At the start of the semester, the academics officer enters the Physical constraints. On completion, UC03 is started.

Primary and essential Form # 1

Form # 2

Form # 3

73

Typical Course of Events:

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

3.

The academic officer enters the number of labs in B on Form # 1.

4.

The academic officer enters the number of projectors in C on Form # 1. The academic officer presses the 6. OK button D on Form # 1.

5. 7.

Form # 2 will appear for that number of times which the academic officer has entered in A of Form # 1.

8.

The academic officer enters the room no in A of Form # 2

9.

The academic officer enters the corresponding capacity of the room in B of Form # 2.

10. The academic officer presses the 11. OK button C on Form # 2.

System Response

The TTM stores the constraints in the system.

The TTM stores the constraints in the system.

12. Form # 3 will appear for that number of times which the academic officer has entered in B of Form # 1. 13. The academic officer enters the Lab Name in A of Form # 3. 14. The academic officer enters the corresponding capacity of the lab in B of Form # 3.

74

15. The academic officer presses the 16. The TTM stores the constraints in OK button C on Form # 3. the system. 7.

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.

UC-02 Use Case:

Enter Academic Constraints

Actors(s): Purpose: Overview:

Academic Officers Capturing Constraints based on university policies. 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 Form # 4

75

Typical Course of Events: Actor Action 1. 2.

System Response

This use case begins when semester starts. The academic officer enters the start time in A on Form # 4.

3.

The academic officer enters the End time in B on Form # 4.

4.

The academic officer enters the Holiday 1 in C on Form # 4.

5.

The academic officer enters the Holiday 2 in D on Form # 4.

6.

The academic officer enters the Holiday 3 in E on Form # 4.

7.

The academic officer presses the 8. OK button F on Form # 1.

TTM (timetable manager) will store these constraints for use at the time of timetable generation.

Alternative Courses ¾ Line 2: Invalid Constraints entered: Indicate Error and prompt for input again.

76

UC-03 Use Case: Actor(s): Purpose: Overview: Type: Cross Reference:

Enter Availability Time Faculty Members, Academics officers To input the teacher’s availability Time for lectures 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. Primary and essential

Typical Course of Events:

1.

2. 3.

Actor Action This use case begins when the Physical constraints (UC01) and Academic constraints (UC02) have been entered. The faculty member enters his Start availability time in Field A. The faculty member enters 4. his End availability time in Field B.

System Response

TTM (timetable manager) will store these constraints for use at the time of timetable generation.

Alternative Courses: ¾ Line 2: Entered Time violates any constraints: Indicate Error.

77

UC-04 Use Case:

Modify Lecture time

Actors(s): Purpose: Overview:

Faculty Members, Academics officers Capture any change in class timings by the teacher. Teacher changes the time visually by dragging on to the desired time. System checks the validity of this time. Primary and Essential

Type: Cross Reference:

Typical Course of Events:

1.

2. 3.

Actor Action This use case begins when the Physical constraints (UC01) and Academic constraints (UC02) have been entered. The faculty member enters his New Start availability time in Field A. The faculty member enters 4. his New End availability time in Field B.

System Response

TTM (timetable manager) will store these constraints for use at the time of 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: Actor: Purpose: Overview: Type:

Modify Physical Constraints Academics Officer To Change any physical constraints (e.g. no of class rooms etc.) within the semester, the academics officer can change the Physical constraints. On completion, UC03 is started.

Primary and essential

Typical Course of Events

FORM # 1

79

FORM # 2

FORM # 3

Actor Action 1.

This use case begins when the actor has already entered the Physical constraints

2.

To modify Room actor will select the B Option.

3.

To modify Labs actor will select the C Option.

4.

The academic officer enters the number of new class rooms in A on Form # 1.

5.

The academic officer enters the number of labs in B on Form # 1.

6.

The academic officer enters the number of projectors in C on Form # 1. The academic officer presses the 8. OK button D on Form # 1.

7.

System Response

A new window which user can information. A new window which user can information.

will pop up, in enter new room will pop up, in enter new Lab

The TTM stores the constraints in the system.

80

9.

Form # 2 will appear for that number of times which the academic officer has entered in A of Form # 1.

10. The academic officer enters the room no in A of Form # 2 11.

The academic officer enters the corresponding capacity of the room in B of Form # 2.

12. The academic officer presses the 13. The TTM stores the constraints in OK button C on Form # 2. the system. 14. Form # 3 will appear for that number of times which the academic officer has entered in B of Form # 1. 15. The academic officer enters the Lab Name in A of Form # 3. 16. The academic officer enters the corresponding capacity of the lab in B of Form # 3. 17.

The academic officer presses the 18. The TTM stores the constraints in OK button C on Form # 3. the system.

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

81

UC-06 Use Case:

Modify Academic Constraints

Actors(s): Purpose:

Academic Officers 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. Type: Primary and Essential Cross Reference: R2.3

Typical Course of Events:

Form # 4

82

Actor Action 1. 2. 3. 4. 5..

System Response

This use case Academic Officer has already entered the Academic Constraints. To modify a section Academic Officer will select the option C. To modify a section Academic Officer will select the option D. The academic officer enters the start time in A on Form # 4. The academic officer enters the End time in B on Form # 4.

6.

The academic officer enters the Holiday 1 in C on Form # 4.

7.

The academic officer enters the Holiday 2 in D on Form # 4.

8.

The academic officer enters the 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 ƒ Line 2: Invalid Constraints entered: Indicate Error and prompt for input again.

83

UC-07 Use Case:

View Timetable

Actors(s): Purpose: entered by

Students, Teachers, Academic officer To view the intermediate table based on the constraints

Overview: Type:

The academic officer. When academic officer enters courses and academic constraints an intermediate timetable is generated. Primary

84

Ranking of Use Cases Rank High

Use Case • • •

Mediu m

• •

Low

• • •

Justification

Enter physical constraints Without these constrarits, the system will not work Enter Academic Constraints Enter Availability Time Modify physical constraints Modify Academic Constraints Modify Availability Time Change lecture time View timetable

Maybe the user has to change the requirements during the system.

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