introduction to com379 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to COM379 PowerPoint Presentation
Download Presentation
Introduction to COM379

Introduction to COM379

144 Vues Download Presentation
Télécharger la présentation

Introduction to COM379

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Introduction to COM379 COM379 University of Sunderland Harry R Erwin, PhD

  2. Purpose • The purpose of COM379 (Advanced Object Oriented Design) is to prepare an advanced beginner for an entry-level programming position in an organization that uses object-oriented design. • This module corresponds to CS111o and CS112o in the ACM model curriculum. For further information, see:

  3. Responsibility • Dr. Harry Erwin is the Module Leader for COM379 at the University of Sunderland. You will see ‘I’ in these presentations from time to time. That’s Dr. Erwin speaking based on his experience. • My primary research areas are computational neuroscience and auditory neuroethology—‘How bats do it.’ • I also have 34 years of experience as a software systems engineer (mostly at TRW) on high-reliability systems. I supervise final year/MSc projects and PhD research in intelligent systems, security, and software engineering. • E-mail: or

  4. Objectives • Be able to synthesize and document an object-oriented design using object-oriented analysis and design techniques. • Develop an awareness of the development processes that underlie OO development. • Learn the principles of designing and constructing Engineered Interactive Interfaces (GUIs). • Develop a critical awareness of the concepts of event driven and client server application development. • Choose and implement appropriate OO solutions from problem descriptions, using a toolkit. • Critically appraise, evaluate, and implement designs using Java. • Understand current development practices and environments.

  5. Scope of the Module • Terminology • Theory • An Object-Oriented Programming Language (Java) • Object-Oriented Methodology • Design Patterns

  6. Outline • 25 PowerPoint Presentations • 16 Tutorials • 1 TCT (1 hour midterm) • 4 Projects • 2 marked by the local lecturer (1 and 3). These are for practice. • 2 marked by the module leader (2 and 4). These count. • 1 Comprehensive Examination

  7. Texts • Key texts that students are strongly encouraged to buy: • R Pooley and P Stevens, 2000, Using UML Software Engineering with Objects and Components, updated edition, Pearson Education Limited, ISBN: 0-201-64860-1. • J Hunt, 1999, Java for Practitioners, Springer, ISBN: 1-85233-093-7. • (a free download!) • Support texts students should have access to: • D. Flanagan, 1999, Java in a Nutshell, fourth edition, O'Reilly, ISBN: 0-596-00283-1. • Other texts in the O’Reilly Nutshell series ({Java Foundation Classes|Java Enterprise|Java Examples|UML} in a Nutshell). • I. Graham, 2001, Object-Oriented Methods, 3rd edition, Addison-Wesley. A post-graduate text for advanced students. • Gamma, et al., 1995, Design Patterns, Addison-Wesley. Also advanced. • Other texts, papers, and websites will be cited from time to time. • Cetus Links:

  8. Tutorial Topics • 4 tutorials are project surgeries. • 1 tutorial for the midterm TCT. • The 11 remaining tutorials will cover the Java language (using Sun tutorial resources) and the UML 4+1 methodology (using papers at Work through these at your own pace.

  9. Presentation Topics • Definitions (two presentations) • Theory (concepts and principles) (four presentations) • Methods (4+1 methodology) (four presentations) • Java 2 (1.3.1 SDK) (six presentations) • Design Approaches (four presentations) • Patterns (four presentations)

  10. My Informal Marking Criteria • A first is supposed to mean that the student is qualified for an entry level position and can safely work on high-reliability applications. • An upper second is supposed to mean that the student is qualified for an entry level position and—with experience—might safely work on high-reliability applications. • A lower second is supposed to mean that the student is qualified for an entry level position. • A third is supposed to mean that the student—with additional programming practice—can reach entry level qualification.

  11. Course Marking • Two elements: coursework and examination, each counting half. • Programming projects are 80% of the coursework mark. It is possible to earn 100 marks on a project. • The TCT counts 20% of the coursework mark. It has three purposes: • To reward early engagement with the module materials • To provide early warning of problems with the lecture material • As practice for the comprehensive examination • Coursework and exam marks must be at least 35% and the module mark must be at least 40% to pass.

  12. Project Marking • Deliverables include: • A floppy disk (or zipfile if electronically submitted) with the code required to run the project. This must compile and run with the Java 1.3.1 SDK. No proprietary extensions allowed! • A sample compilation and run of the project. • Program documentation, including a listing. • Marking: • 40 marks for success • 20 marks for implementation • 40 marks for documentation • The marking standard is based on what a fully competent entry-level programmer would be expected to produce.

  13. Success • 10 marks if a program designed to meet the project requirements can be compiled successfully by the Java 1.3.1 SDK, • 10 marks if it runs in that environment, • 10 marks if most of the requirements are met, and • The last 10 marks if all requirements are met. • You are expected to discuss requirements deficiencies in your status report.

  14. Implementation • 10 marks for good object-oriented design • 10 marks for good commenting and choice of names.

  15. Documentation • Up to 5 marks for your status report, discussing overall success or failure and lessons learned. • Up to 5 marks for answering the questions posed for the project. • Up to 10 marks for documentation of your requirements • Traceability to the design • A test report showing how they are met • A sample compilation and run of the project • Up to 20 marks for documentation of your design • Overview of your architecture and design, • Structural and behavioral diagrams, • Written descriptions of each class, • Any necessary algorithm documentation (NS diagrams, PDL, or similar) • Program listing

  16. Fairness in Marking • During marking, projects will be checked to determine if there is evidence for collaboration or cheating. • The mean coursework mark is expected to be about 67. Note that that students will be able to earn 100 marks on projects for professional-quality work. • The examination will be designed for a mean mark of about 53 and a standard deviation of about 18, so that passing the module is controlled by examination performance.

  17. Collaboration • The following are permitted: • Cooperation in developing an understanding of the requirements. “What we don’t understand, we explain to each other.” • Cooperation in the diagnosis of bugs and problems as long as the helper does not provide code solutions. • These are pedagogically valuable and allowed. • The following are not allowed: • Collaboration in developing project documentation and figures. Write your own report! • Collaboration in designing and coding the project. Come up with your own design and write your own code! • As long as similarity remains at or above the subsystem or pattern level, not extending into the detailed design and code, it will not be penalized as collaboration.

  18. Allowed External Sources of Code and Design • Code provided by the instructor, • Code generated by tools, • Code from the key texts • Code from the reference texts • Code from, including the supporting materials • Code from Gamma, et al., Design Patterns. You must cite your use of this material in the code module where it is used.

  19. Questions?