Uday Khedker

Associate Professor Department of Computer Science & Engg., IIT Bombay

Common Design Errors

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 good!

In particular, the following issues were not adequately addressed by many groups. Either they are not understood well or they were simply ignored.

1. Class Relationships

   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.
   
   

2. Access controls

   Not much thought was given to which data/function member should be made public.
   
   

3. 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.
   
   

4. The role of internal representation of data

   Many groups tried to
   
   
   1. 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 multiple times.
   2. store the data in "string" form rather than converting it to a simpler internal form.
   
   
   

5. 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.