CS100: Software Construction

Catalog Description

Development and construction of software products. Topics include design, coding layout, and style; implementation strategies; quality attributes; prototyping, reuse, and components; debugging, testing, and performance; integration and maintenance; documentation; standards, analysis, and selection of tools and environment; and personal software processes.

Prerequisites

CS 141: Intermediate Data Structures and Algorithms

Textbooks

Andrew Hunt, David Thomas: The Pragmatic Programmer. Addison-Wesley, 1999. You can download additional material for this book here. An errata is available.

Martin Fowler: UML Distilled. Addison-Wesley, 3rd edition, 2003.

Expected coverage

The Pragmatic Programmer will be covered in full either in class or in the lab or through self-reading.

The following chapters from UML Distilled will be covered:

• Chapter 1: Introduction.
• Chapter 2: Development Process
• Chapter 3: Class Diagrams
• Chapter 4: Sequence Diagrams
• Chapter 6: Object Diagrams
• Chapter 7: Package Diagrams
• Chapter 11: Activity Diagrams

Selected topics from remaining chapters as time permits.

Important Note: Students are required to read the sections pertaining to the material covered in the class and familiarize themselves with the relevant exercises. Students are also required to attend both the lectures and the lab sections.

Grading Policy

• Quizzes 25%
• Projects 60%
• Homework Assignments & Other Lab Activity 15%

All programming must be done in C++.

Academic honesty

Programming projects must represent your original work and must be developed completely independently by each one of the students. Copying from any sources (web, other books, past or current students, etc.) is strictly prohibited. No cooperation, discussion, sharing, exchange or consultation between the students themselves is allowed. This, of course, does not apply to any discussions taking place during the lectures under the supervision of the instructor.

You can report cheating anonymously at: https://www.cs.ucr.edu/cheating/.

Students violating this policy will be given a failing grade for the course and their case will be referred to the office of Vice-Chancellor for Student Affairs. On the other hand, students are strongly encouraged to cooperate and consult each other in preparation for the exams.

Mailing List

A class mailing list: cs100@lists.cs.ucr.edu will be established to disseminate information pertaining to this class. Make sure to sign-up for the mailing list in order to receive prompt information about class assignments, additional resources and other pertinent matters.

You can sign up for it at: https://www.cs.ucr.edu/mailman/listinfo/cs100

IMPORTANT: only UCR e-mail addresses will be allowed on the list!

Lab 1

• Goals of the course
• Introduction to Software Engineering
• (Brief) Introduction to UML

• The Pragmatic Programmer, Chapter 1: A pragmatic philosophy
• UML Disitiled, Chapter 1: Introduction
• UML overview

Lab 2

• Know your tools (Visual Studio, Subversion, Dia)
• Editors vs. IDE's
• Version control

• The Pragmatic Programmer, Chapter 3: The basic tools
• UML Distiled, Chapter 3: Class diagrams (the essentials)
• Visual Studio .NET 2003 C++ Tutorial
• Using Visual C++ .NET
• Ben Collins-Sussman, Brian W. Fitzpatrick & C. Michael Pilato. Version control with Subversion
• Dia manual (Help/Contens, or F1 :) in Dia)

• Homework 1, due on Wednesday, April 13, 2005, at the begining of the lab.

Lab 3

• Design by contract (preconditions, postconditions, assertions)
• Run-time error checking (assertions, exceptions)
• Time management (timelines, Gantt charts)

• The Pragmatic Programmer, Chapter 4: Pragmatic paranoia
• Using VC++ Debugger (any C++ program would do, in case you cannot make up your mind, use heron.cpp)
• Timeline 1
• Timeline 2
• Timeline 3
• TaskJuggler is an easy way to manage your timeline for this project.

Lab 4

• Requirements / Specifications

• The Pragmatic Programmer, Chapter 7: Before the project

Project Phase 1

There are several things that need to be accomplished, some more some less immediatly connected to the project. I need you to:

• Pick up a group name (if you have not done so during the last week)
• Choose a group (team) leader
• Get together with your team and go over the project specs as presented today during the lecture. Then briefly summarise the requirements, prepare a sketch of the class diagrams and use cases (see Pragmatic Programmer pages 206-207 for templates, although you can of course omit certain items), and once you are confident about what you have, come and talk to me. There is a general timeslot on Friday 1-2PM, and there will be group-assigned 20 minute time slots on Monday. You absolutely have to see me either on Friday or on Monday. After you get an approval on the draft, you can continue to work on the details, and once you have the specs done, you can start coding.

What I am expecting to get out of this section of the project:

• A design document for this project module (the initial draft should be just a draft, but the final version will become part of your final project report, so spending some time now to do it right *will* save you some time later). It has to have:
  • Cover page, with the school name, class code and name, group name, group members, and the team leader outlined somehow (for all I care, he can be underlined or have a little purple heart next to his name).
  • Table of contents (pretty slim at this point, but it will grow as you add more documentation). To have the table of contents make any sense, the pages of your report should be clearly numbered.
  • Short summary of the specs as presented in class.
  • Use cases for the part of the project described so far.
  • Class diagrams for the project (a current version thereof, they can and should grow as specifications become more specific).
  • Sequence diagrams.
  • A *rough* Gantt chart describing how you intend to spend the time until the end of the quarter. At this point I am not expecting that you have a day-by-day plan, but rather a general idea of the scope of the project and how much time you have, as well as how you plan to split the project between the members of your team. You can always improve this once you get more information. Important: Make sure you allocate time for testing after you have completed coding and integration. This testing time is in *addition* to all the testing you will be performing *while* you code. More about testing -- next time.
• Coded tracer-bullet part of the application described so far in the class. Make sure your code has no compilation errors.

Lab 5

• Decoupling of modules
• Metaprogramming
• Synchronous vs. Asynchronous
• Testing
• Documentation (using Doxygen)

• Doxygen manual, sections 2 (Getting started), 3 (Documenting the code) and 10 (Output formats)
• The Pragmatic Programmer, Chapter 5: Bend, or break
• The Pragmatic Programmer, Chapter 8: Pragmatic projects

Lab 6

• Coding on auto-pilot
• Analysis of algorithms (time and space complexity)
• Refactoring
• Testing (once again)

• The Pragmatic Programmer, Chapter 6: While you are coding

Project Phase 2

Keep on working on your project according to the specs you got in class today. You should update the documentation and your code according to the latest batch of requirements. Clearly a lot of things will be new. Clearly a lot of things will be what you had before, if maybe slightly modified. Some things might get refactored. Make sure all of them work together. Make sure your documentation is consistent.

The nature of this project is cumulative. So should be your submissions. At any point when you are turning something in, you will have to turn in everything you worked on until that point. This does make your life easier in some sense because a lot of things will be done when you start coding, but you have to perform some integration testing, and if you are modifying your code from before, regression testing.

Deliverables for the second phase of the project include everything from before for the first part of the project, everything from before for the second part of the project, *plus* some methodology and discussion of testing mechanisms you employed. Include test samples, code that tests your code, etc. One of the goals of this phase of the project is to make you view testing as a necessary part of the development process.

Lab 7

• Project consultations

Lab 8

• Project consultations

Project Phase 3

As said before, this project is cumulative. For Phase 3, you need to add details presented in class on Friday, May 20. Essentially, after completing Phase 3, you should have a working application *AND* complete documentation of the process that made the application.

As far as documentation goes, there is only one new area in addition to what you had in Phase 2, and it will be graded lightly. What you had before clearly needs to be extended with Phase 3 data (use cases, CSV file descriptions, sequence diagrams, Doxygen documentation for new modules, and so on). Once again, these are the specific sections I would like to see in the write-up:

• Cover page
• Table of contents
• High level overview of the application
• High level requirements (including descriptions of CSV files, and so on)
• Use cases (which should include success and error scenarios)
• Class diagrams
• Sequence diagrams
• Section discussing the testing methodology you employed (this is in addition to the testing code and test CSV files you might have made)
• Doxygen documentation for the code (if you rendered it into html, put the link to where it can be found)
• Gantt chart for the project
• Reflection on the project (this is new). Informally, reflect on what you have learned, problems you faced and how you went about solving them. Would you do something in a different way, now that you have gone through the whole course? Do not write more than a page. In my experience it is useful (and very importnat) to look back and think about your actions and what you can do to make your future endeavors more successful.

For next Wednesday (May 25), prepare a draft for Phase 3. We will follow the usual schedule: group Eelko at 5:00PM, Discovery at 5:30PM, T.P.O at 6:00PM and Red at 6:30PM.

Phase 3 is due on Wednesday of last week of classes (June 1), in the lab, same as before, printout + demo + files uploaded into turn-in.

Lab 9

• Project consultations (Phase 3 draft, group Eelko at 5:00PM, Discovery at 5:30PM, T.P.O at 6:00PM and Red at 6:30PM)

Lab 10

• Project consultations (Phase 3 submission and demo, group Eelko at 5:00PM, Discovery at 5:30PM, T.P.O at 6:00PM and Red at 6:30PM)

Project Phase 4

Phase 3 finishes your application. Phase 4 deals with making interfaces to what you have built before -- GUI to enter data, etc. Details will be covered in class on Wednesday, June 1.

On Tuesday, June 7, you will demo the whole application, GUI included. You do not have to turn in the code for Phase 4. You do not have to make any additions to the documentation as far as Phase 4 goes. I will be available the whole day (more or less), so please pick half an hour which does not conflict with your teammates' finals, and let me know via e-mail, so I can pen down your time slot.