COP290: Design Practices in CS



This is the course page for Design Practices in CS, for Semester II, 2017-2018, being taught by Subhashis Banerjee at the Department of Computer Science and Engineering, IIT Delhi.

Notice | Objectives | Honour code | Common project I | Common project II | Case study I | Case study II

Notice
  1. Please click out the slots when you are not free for this course. Please clearly indicate your entry number (not name).
  2. The starlings have arrived at IITD: https://photos.app.goo.gl/mBWCvvzTQV6eBumI3 (will update with more/better photos soon). Also see here.

    So, Godspeed!

Objective(s) and plan

To get familiar with methods for doing (large?) projects in collaborative mode with special emphasis on specification, use cases and software development.

We plan to cover: design, analysis and modeling; software requirement analysis and detailed specifications; design documentation; standard software development tools; testing; report.

The tools that we plan to cover include:

  1. Standard Unix utilities.
  2. Latex
  3. gcc/g++ - the C pre-processor, header files, #defines; object files, linking, static and run-time libraries; Makefile.
  4. using and creating libraries, ar and ranlib.
  5. Object oriented style, classes, namespaces etc.
  6. Multiprocessing and multithreading
  7. version control.
  8. debugging and profiling tools
  9. macros and in-line code, loop transformations and un-rolling, speed-up issues.
  10. Documentation tools like Doxygen.
  11. auto-configuration, Makefile generation and porting issues.
The class will be required to do two common projects (in groups of two) and one open project (in groups of three or four). The students are encouraged to select a topic for their open project in consultation with faculty and/or Ph. D. and other senior students.

We may also do case studies of one or two large projects.

Honour code

  • All students are expected to follow the highest ethical standards.
  • Collaborations and discussions are encouraged. However, all students are required to write up all solutions entirely on their own. Any collaboration, or help taken, must be declared.
  • Students are encouraged to refer to books, papers and internet resources. They may even consult other individuals. However, the source must be clearly cited if any part of the solution (or even an idea) is taken from such a source.
  • Failure to declare any help taken will be interpreted as academic misconduct.

Common project I

Rough specification
Design and implement a software package for Engineering drawing. The package should have the following functionalities:
  1. We should be able to interactively input or read from a file either i) an isometric drawing and a 3D object model or ii) projections on to any cross section.
  2. Given the 3D model description we should be able to generate projections on to any cross section or cutting plane.
  3. Given two or more projections we should be able to interactively recover the 3D description and produce an isometric drawing from any view direction.
Step I: Modeling and analysis
Work out a mathematical model for the problem. Figure out how many views are necessary? how many are sufficient? How can one compute projections given the 3D description? How can one compute the 3D description given one or more projections? What interactions are necessary?

Define the problem more precisely and submit a LaTex report by Jan 18.

Step II: Software requirement specification
Capture the functional specification in UML and submit by Feb 14. Be as comprehensive as possible.
Step III: Software design document
Specify the software architecture for program development using C++ including class diagrams and function prototypes in Doxygen and submit by March 5.
Step IV: Implementation and software documentation
Please study the following tools and commands: C pre-processor, steps in gcc compilation, linking (static and dynamic linking), Makefile, nm, objdump, strip, ldconfig, ldd, ar and ranlib. And, of course, Git and SVN. Please refer to
  1. The ``hello world'' examples in http://web.iitd.ernet.in/~suban/COP290/stuff.
  2. https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html.
  3. http://www.cse.iitd.ac.in/~avinash/ta.html.
  4. http://www.cse.iitd.ac.in/~subhajit/csp301.shtml.

Please submit a tar ball containing your software implementation and documentation by March 18.

Step V: Testing and fine tuning
Step VI: Report

Common project II

 Carefully watch the video of starling murmuration. Our next project will be to model and simulate this fascinating phenomenon. We will computationally simulate the phenomenon by modelling each bird as an independent agent communicating and cooperating with other neighbouring agents. Our objective will be to measure from a realistic simulation the average energy spend by each bird, the angular momentum and the force that each bird has to withstand in a typical flight ritual.

The instructor was recently reminded of the starling murmurations by Prof. Narayanan Kurur.

You may read/watch the following resources and start planning your simulation design.

  1. https://en.wikipedia.org/wiki/Flocking_(behavior)
  2. https://en.wikipedia.org/wiki/Starling
  3. https://en.wikipedia.org/wiki/Boids
  4. https://www.youtube.com/watch?v=U4TvNqijfC4
  5. https://www.youtube.com/watch?v=QbUPfMXXQIY
  6. http://cp3-origins.dk/a/14187
  7. https://www.wired.com/2011/11/starling-flock/
  8. https://www.technologyreview.com/s/415022/first-simulation-of-the-flocking-behavior-of-starlings/
  9. https://arxiv.org/abs/0908.2677
  10. http://www.pnas.org/content/111/29/10422
Please feel free to refer to other resources on the internet and elsewhere.

Case study I

 Elections are at the heart of democracy and all in the class (except the intstructor and perhaps some of the TAs) will vote for the first time in the general elections due in 2019. The Election Commission of India has mandated that the voting must be conducted using Electronic Voting Machines (EVMs; also see here). EVM's have been mired in controversies - see here, here, here and here or here (the last one even talks about a dubious role played by IITD in the controversy, see the technical paper). Prof. Rajat Moona (see here and here), another IITian, however is very confident of the latest design and we may someday invite him to this class. No other country in the world has used electronic voting in as large a scale as India has, and electronic voting is still far from being standradized world-wide.
  1. Please try to understand the social and political requirements of an EVM design: correctness, tamper proof guarantees, coercion free ...
  2. Work out a formal specification of an EVM design based on the requirements.
  3. Work out a functional design and verify the correctness against specification using a formal technique like Model checking or Automated theorem proving.
  4. We will try to do the last two steps jointly as a case-study in the class.

Case study II

 Hastily deployed technocratic designs among the under-privileged with poorly analysed and incomplete use cases and without adequate understanding of the social and cultural context can cause distress, as Prof. Reetika Khera has pointed out here and here. Providing food security is a necessary function of the welfare state; and PDS is a crucial part of the NFSA. It also makes a significant proportion of the total subsidy (which, in turn, makes a significant proportion of the union budget). In 2018-2019, the GOI has allocated Rs. 1,69,323 Crore for food subsidy (see here).
  1. Read about the considerations for an effective PDS design from here.
  2. Read about the three possible design alternatives mentioned here.
  3. Work out a detailed requirement specification for effective PDS and a functional design.
  4. Explore the possibilities of evaluating the designs using formal techniques.
Subhashis Banerjee / Dept. Computer Science and Engineering / IIT Delhi / Hauz Khas/ New Delhi 110016