Department of Computer Science & Engg.,
Common Design Errors
Here is a summary of the design review of the
course projects of
23 groups carried out on 6 and 7 September.
The groups were asked to submit design documents in plain text and
C class diagrams drawn using "dia" program. In some cases, drawing
class diagrams provided clarity (some groups mixed it
with entity relationship diagrams or UML diagrams) while some groups
seemed to become complacent and ignored the semantics of the
diagram perhaps because the resulting diagrams looked
In particular, the following issues were not adequately addressed by many groups.
Either they are not understood well or they were simply ignored.
Back to top of the page
Many goups did not specify the relationships clearly. Issues
like base class, subclass, friend class, inheritance,
containment/aggregation, method invocations across
classes etc. were not thought out well.
Not much thought was given to which data/function
member should be made public.
Encapluation and grouping of related data
In many cases, the data was "spread" across
many classes each of which contained data as either basic types
or arrays of basic types. The relationship between these
pieces of data seemed to be implicitly captured by the
code (i.e. executable statements of the program) rather than by explicit grouping of data.
The role of internal representation of data
Many groups tried to
- process the data "on the fly" without realising
that the input data may have to be remembered
after having read once and may have to be accessed
- store the data in "string" form rather than
converting it to a simpler internal form.
Processing program input
Most of the groups had a parsing phase which in many
cases somehow "magically" made all the data available
whenever it was required.
Back to the main page
Last updated on 9 Sept 2003.