CS100: Software Construction
Professor: Dr. Teodor C. Przymusinski,
Lecture: Monday, Wednesday, Friday 1:10-2:00 PM
Office hours: Monday, Wednesday, Friday 4:00-5:00 PM SURGE 335 or by appointment.
TA: Vladimir Vacic
Discussion: Wednesday 6:10-9:00 PM, SURGE 171
Consultations: Wednesday 3:10-6:00 PM, SURGE 282 or by appointment.
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.
CS 141: Intermediate Data Structures and Algorithms
Andrew Hunt, David Thomas: The Pragmatic Programmer. Addison-Wesley,
1999. You can download additional material for this book
Martin Fowler: UML Distilled. Addison-Wesley, 3rd edition, 2003.
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 will be based on team projects and several pop-up quizzes and homework
assignments. Class participation will be also considered. Approximate weights
assigned to them will be as follows:
- Quizzes 25%
- Projects 60%
- Homework Assignments & Other Lab Activity 15%
All programming must be done in C++.
Letter Grades: Letter grades are ***roughly*** assigned according to the usual 90/80/70/60 rule: 90% and above correspond to an A, 80% and above to a B, 70% and above to a C, 60% and above to a D, and less than 60% to an F. +/- grades will be given where appropriate. The exact cutoff scores will not be posted.
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
You can report cheating anonymously at:
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.
A class mailing list: email@example.com 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:
IMPORTANT: only UCR e-mail addresses will be allowed on the list!
- 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
- Know your tools (Visual Studio, Subversion, Dia)
- Editors vs. IDE's
- Version control
- Homework 1, due on Wednesday, April 13, 2005, at the begining of the lab.
- Design by contract (preconditions, postconditions, assertions)
- Run-time error checking (assertions, exceptions)
- Time management (timelines, Gantt charts)
- 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
- Coded tracer-bullet part of the application described so far in the class.
Make sure your code has no compilation errors.
- Decoupling of modules
- Synchronous vs. Asynchronous
- 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
- Coding on auto-pilot
- Analysis of algorithms (time and space complexity)
- 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
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.
- 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)
- 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.