Logical Circuit Design

How to Choose a Project?

The list of projects for each semester will be available at the beginning of the semester. This list will contain the projects title and names of supervisors. The main selection and allocation of students to projects was made at the beginning of the semester. It is possible for students to propose their own projects, in which case, they should prepare a proposal and give it to the Graduation Project Committee (GPC).

Usually each project is suitable for more than one student (normally 3 students). Therefore, groups of three students should be arranged by students themselves. Each group of three students should make three choices of projects on the selection form obtained from the GPC.

Students are strongly encouraged to see the associated members of staff for projects they are interested in, to find out more about the projects.

OWN Projects

If a student has successfully negotiated a project - outside the list of projects given by the department - with the project committee, and possibly a prospective supervisor, he/she still gives another 2 choices, and code choice number 1 as "OWN"; this is likely to be the student's first choice, but it does not have to be.

Project Timetable

Students are expected to be in regular attendance working on their projects. They must co-operate in maintaining regular contact with their supervisors. It is an attendance requirement that students see their supervisors every week during term time. The formal project deliverables are a demonstration with discussion, and a written report.

The project lifecycle should follow a sensible methodology and include the various stages identified in any Software Engineering course.

Work on the project itself, in particular use of equipment and computing facilities, must finish at the end of the 12th week of the semester. In some cases, this can be extended to another semester.

The project report and the Auxiliary Appendix together with any relevant discs, logic circuit and wiring diagrams etc., must be handed in to the Graduation Project Committee after being signed by the supervisor by the end of the 15^th week of the second semester. The GPC will announce a timetable for all project discussions. It forms a number of discussion committees, where each consists of two staff members and discusses one project.

The formal demonstrations and project discussion take place within one week after the submission of the report. The demonstration and discussion will contribute to the assessment of the "Quality of the project work".
The subdivision of marks within the project is:

The supervisor mark: 35%

The Project committee mark: 65% divided into

Demonstration, 20%

Discussion, 20%

Report, 25%

Note that the 25% is awarded for the report judged as a report only, independent of the quality of the work being described.

Demonstration

The demonstration is an informal presentation of the results of the project to one of the project discussion committee. The students will say briefly, what the aims of the project are, and will then demonstrate the results for example by running the program or using the equipment constructed. The duration is about 20 minutes. See Guidance on demonstrations below for more information.

Report

The report is a formal written report on the project. This must be word processed. The report must follow a set of standards, given below, to facilitate its inclusion in the library and its usefulness for subsequent readers. Besides these, student will find it useful to read the slides of the talk given on writing, which is given in the lecture.

Copies of previous graduation project reports are available for reference in the Department.

Project documentation may be prepared on the PCs and printed on a laser printer. Students should hand in three soft cover copies of the report. After the discussion with the discussion committee, students should make all the correction that are suggested by the committee within the specified period of time under the supervision of their supervisors, then they should handed in three blue colour hard cover copies of the project. The title of the project, the University, Faculty, Department names, and students' names are all written in golden colour.

Overhead Projector

Students are expected to make reasonable use of the overhead projector or power point presentation on the day of their demonstrations.

Guidance on Demonstrations

A demonstration lasts about 20 minutes.

The group of students should aim to spend no more than 10 minutes summarising what their project is designed to achieve and showing what it currently does achieve. The rest of the time is spent in answering questions.

Note: Students should not attempt to demonstrate on the computer every last thing their program can do. A demonstration of its basic operation plus one or two highlights should suffice.
The mark given for the demonstration is based on the quality and quantity of the work attempted and the final state of achievement.

Students should have their working documents to hand and appropriate reference material, design workings, reasonably up-to-date listings, examples, tests, etc. They are not giving a 20-minute seminar; at least half the time must be available for questions.

Obviously, the kinds of things that are sensibly shown in a demonstration vary from project to project. If students are in doubt as to what to show, they should ask their Supervisors.
The discussion committee consists of two staff members. In general the supervisor of the project is not present.

In general, students should be available and ready to start their demonstrations at least within one week of their submission of the project.

Report Standards

1. 
   The report is a formal written account of the project, satisfying certain standards for inclusion in a library.
   Students must hand in all relevant work on the project by the end of the 11th week of the second semester. In addition to the report, this includes program listings, discs, detailed logic and wiring lists, etc. It is important to meet this deadline. When students hand this to their supervisors it must be accompanied by a signed version of a form supplied by the GPC. In the case of programming projects, program listings must be submitted in some bound form in an ``Auxiliary Appendix'' that does not need to satisfy any particular standard apart from being neat and tidy. It is suggested however that an economical listing would be double-sided on A4.
   

Here is a suggested structure for a report. Some projects may be rather different from others, and therefore have good reasons for not following these suggestions exactly. Supervisor guidance should anyway be sought!

1. 
   Introduction (1st chapter). What is the overall aim of the project. Why is it worth doing? Who will benefit from it? If the overall aim can be split into a number of subgoals, this is a possible place to do it. Finish with a chapter by chapter overview of the rest of the report.
   
2. 
   Background (2nd chapter). Analyse the background to the project. This should mention any previous work, here or elsewhere, and explain its relevance to the project. This could be an appropriate place to justify the choice of platform/software etc. used in the project.
   
3. 
   Description of the student's own work: Design and Implementation (a chapter each). The structure of these chapters may reflect the project lifecycle, but do not write a diary of progress. The design should be clearly described and justified. Supporting diagrams should be used where appropriate and helpful. Keep your design description fairly high level. When describing implementation, confine yourself to the important, difficult, or interesting bits. Do not include large chunks of code. Figures may well be useful.
   
4. 
   Results (1 chapter). What is the resulting system like to use. Include screen shots as appropriate.
   
5. 
   Testing and Evaluation (1 chapter). What testing was done? How confident are student that everything works correctly, and what evidence can they produce to support this claim? Have students evaluated the system against its aims? How did they make this evaluation?
   

6. 
   Conclusions (last chapter). What conclusions can students draw from the whole project? This should include a clear statement of what has been achieved overall, and will normally continue by suggesting areas of further related work, which could be done.
   

2. 
   The report itself (apart from technical considerations) is worth 25% of the project mark. However, it forms the basis of an independent assessment of the project and therefore has greater effect than 25% in practice.
   

3. 
   The report must be on paper of A4 size (210 x 297 mm). Only one side of paper should be used except in the Auxiliary Appendix.
   

4. 
   The report must be produced using word processing facilities. The body of the report should be suitably divided into chapters and sections. Chapters, sections, pages, figures and appendices should all be numbered. Chapters, sections and appendices should have a heading. Each chapter should start on a new page. The body of the report should be preceded by a temporary title page, an abstract and a list of contents, and it should be followed by the references and then any appendices.
   References to other published work should follow the conventions used in giving references in published work. e.g.: [1] P.J. Denning. Human error and the search for blame. Communications of the ACM 33(1): pp 6-7, January 1990. The abstract page must give the title, author, and supervisor, as well as an abstract of the project.
   

5. 
   Straightforward and peripheral aspects of the work done should be mentioned only briefly, and description and explanation concentrated on important and interesting aspects. No extra credit is gained by writing a long report and excessive length is detrimental. More detailed description should be placed in appendices to the report. The appendices and/or the Auxiliary Appendix should contain any further documentation. Only the report itself will be held in the Department. Therefore, where important material is not included in it, e.g. because it is not convenient to produce it in A4 format, or it would be too bulky, it may sometimes be appropriate to include extracts in the report.
   

Copyright

In general, it is an infringement of copyright to reproduce any material, except short acknowledged quotations, from a published book or journal without the written permission of the publisher.

Except for the copying of material that is clearly from internal documents of the Department, any copying of books, journals, or documents required for the report should be checked with the supervisor before it is carried out.

Any material that is copied must be acknowledged as such. Attempting to present material written by others as your own is plagiarism and a serious disciplinary offence, as described in the University guidelines in the Undergraduate Handbook.

Marking Scheme for Reports

The report, as a document, is worth 25% of the project mark. These marks are divided among the following headings:

1. 
   Organisation (10%): balance of content, clarity, flow, relevance.
   
2. 
   Context (5%): discussion of background, aims, and significance of achievements.
   
3. 
   Literacy (5%): English, style, report manner.
   
4. 
   Presentation (5%): tidy layout, headings, references, diagrams.
   

750491, Special Topics
Providing Department: Computer Science, Faculty of IT

Module Coordinator(s):

Year: 4

Credit: 3 credit hours

Prerequisite: Department Agreement
Aims:

This module aims to offer any recent topic in computer science. The chosen topic may be different from semester to another.

Teaching Methods: 48 Lectures or it depends on the chosen topic that might include seminars hours as well.
Learning Outcome:

It depends on the chosen topic.

Assessment of Learning Outcome:

It depends on the chosen topic.

Modes of Assessment:

It depends on the chosen topic.

Synopsis: For this module, the department can choose any recent topic to cover it within one semester.
Textbooks and Supporting Material:

According to the selected topic

Programming Fundamentals 750112
Course/Module Objectives:

This module aims to introduce computer programming and emphasis in problem solving on the fundamentals of structured design using the principles of Top Down problem solving strategy (divide and conquer). This includes development, testing, implementation, documentation.

The module also aims to explore the logic of programming via the algorithm concepts and implement them in programming structures including functions, arrays, strings, and pointers.

Course/ module components

• 
  Textbook:
  

D.S. Malik , Thomson, C++ Programming: From Problem Analysis to Program Design, Third Edition, Course Technology, 2007

• 
  Supporting material(s): Lectures handouts
  

Teaching methods:

Duration: 16 weeks, 80 hours in total

Lectures: 32 hours (2 hours per week),

Tutorials: 16 hours (1 per week),

Laboratories: 32 hours, 2 per week

750351, Fundamentals of Artificial Intelligence
Providing Department: Computer Science, Faculty of IT

Module Coordinators:

Year: 2

Credit: 3 credit hours

Prerequisite: 710104

Prerequisite for: 750352, 750354, 750424

Aims:

The module is the primary introduction to artificial intelligence. Halve of the module material is delivered in-class and the other halve is distant learning using the e-learning module designed at faculty of IT in Philadelphia University. The module aims to present the basic representation and reasoning paradigms used in AI in both theory and practice with careful attention to the underlying principles of logic, search, and probability. It is also designed to show students practical examples of the use of AI in applications and to encourage further reading. The e-learning part enables students to practice self learning. The Assignments aim to give students a sound practical introduction to knowledge based systems and a basic introduction to modern paradigms of knowledge representation and belief networks. The examples classes aim to provide an introduction to the underlying issues in cognitive emulation and to provide an opportunity for practical exercises in logic and probability.

Teaching Methods: 22 hours In-class Lectures (1-2 per week) + 16 hour E-learning Lectures (1 per week) + 8 hours Tutorials (1 per 2 weeks)
Learning Outcomes

A student completing this module should

1- have an understanding of search, logic based knowledge representation, of issues in planning and learning. (A, D)

2- have an understanding of the limitations of current symbolic AI paradigm (A).

3- be able to select appropriate search paradigms for appropriate problems (A, B)

4- have knowledge of Bayes' Rule and its use in Belief Networks and be able to solve problems concerning updating of prior probabilities with evidence using it and to construct belief networks for simple problems. (A., B)

5- be able to design a simple agent system and associated ontology and justify the design (B)

6- be able to design and implement a forward chaining knowledge based system including rule base (C)

7- be able to study on-line (B, C).
Assessment of Learning Outcomes

Learning outcomes (1) to (3) are assessed by examination. Learning outcomes (4, 5) are assessed by coursework of the unsupervised laboratory and by examination. Learning outcome (6) is assessed by coursework. Learning outcome (7) is assessed by on-line course.

Contribution to Programme Learning Outcomes:

A2, A3, A4, B1, B2, B3, B4, C4, C5, C6, D6

Synopsis: Introduction to AI (what is AI? foundations of AI); Intelligent agents (What is an agent? structure of agents); Intelligent agents (types of agents, environments); Problem Solving (search algorithms, understand the search problems and their algorithms); Problem Solving (introduce search algorithms, uninformed search algorithms); Problem Solving (iterative deepening search, informed search algorithms); Problem Solving (best-first search, A* search algorithm); Problem Solving (admissibility and dominance, simulated annealing search); Knowledge representation (Introduction, history of knowledge representation, semantic networks); Knowledge representation (frames, scripts, conceptual graphs, and conceptual dependency); Knowledge representation (production rules, logic knowledge representation, propositional logic); Knowledge representation (first-order logic, inference rules in first-order logic, Prolog and Lisp); Expert System (Introduction, components of an expert system); Expert System (compare between human thinking and computer thinking, rules based systems); Expert System (programs required to develop an expert system, types of expert systems). Expert System (examples of well known expert systems, strategies in expert systems, develop an expert system).
Modes of Assessment:

Two 1-hour midterm exams (20% each); Assignments (5%); Tutorial contributions (5%); Final Examination: 2-hours written exam (40%) + defended project (10%).

Textbooks and Supporting Material:

1- S.J. Russell & P. Norvig, Artificial Intelligence: A Modern Approach, 2^nd edition, Prentice Hall, 2002.

2- G.F. Luger & W.A. Stubblefield, Artificial Intelligence: Structures and Strategies for Complex Problem Solving, 3^rd edition, Addison Wesley, 1998.

3- N. J. Nilsson, Artificial Intelligence: A New Synthesis, Morgan Kaufmann Publishers, 1998.

4- P.H. Winston, Artificial Intelligence, 3^rd edition, Addison Wesley, 1992.

5- E. Rich, K. Knight, Artificial Intelligence, 2^nd edition, McGraw Hill, 1991.

6- Charniak, D. McDermott, Introduction to Artificial Intelligence, Addison Wesley, 1985.

750371, Computer Graphics
Providing Department: Computer Science, Faculty of IT

Module Coordinator(s):

Year: 3

Credit: 3 credit hours

Prerequisite: 210103 + 721211