Reference no: EM133349928

Advanced Programming Practices

1. INTRODUCTION

For many, a cold beverage in a glass is among the means for survival during summer. The main purpose of a coaster is to absorb condensation dripping along the glass, and thereby protect the surface of a table or any other surface used for placing the glass. The coasters are also of interest to tegestologists.

For the sake of reference, the project as well as its product is called CHEERS.

2. PROBLEM

Let there be two circular coasters of equal area (and negligible height). The purpose of CHEERS is to find how far the two coasters need to be moved on top of each other such that the area of the overlapping region is half the area of any one of the coasters, as illustrated in Figure 1.

PROBLEM 1.

T must provide an outline of the solution, including the object-oriented design corresponding to P.

T must construct a CRC card model. NOTE
For each CRC card, the following must be described: (a) role, (b) responsibilities and the rationale for the responsibilities, and (c) collaborations and reasons for collaborating.

PROBLEM 2.

T must rationalize the selection of each algorithm deployed in S, and document the algorithms using pseudocode (as well as natural language, if necessary).

NOTE

The pseudocode should not be too close to the implementation.

PROBLEM 3.

(a) This is Incarnation 1.

S must be written from scratch. S must not make use any native support in programming languages for trigonometric functions, such as sin(x) and cos(x), and for the mathematical constants, such as π. S must not make use any application programming interfaces or library functions, other than for input, output, and basic arithmetic.

T must not use any source code from any other courses or any place on the Web.

NOTE

The following applies to (a) only.

T must provide the steps taken towards making S to be modifiable, readable, reusable, testable, and understandable.

T must provide the steps taken towards making the corresponding P to be general, robust, and usable.

T must provide a sample output, say, for different values of R. The output of P must be in structured plain text.

(b) This is Incarnation 2.

S must be written in a manner that seeks as many opportunities for reuse as possible. S could, for example, make use of application programming interfaces or library functions, available natively or otherwise.

T must not use any source code from any other courses.

NOTE

The following applies to (b) only.

T must provide the steps taken towards making S to be readable, modifiable, testable, and understandable.

T must provide the steps taken towards making the corresponding P to be general, robust, and usable.

T must provide a sample output, say, for different values of R. The output of P must be expressed in XML. This output must be valid with respect to some XML DTD.

NOTE

The following apply to both (a) and (b).

S must be written in Python. T must select the same version of Python (2.x or 3.y) for both (a) and (b).

S must not depend on any particular development environment (such as a specific operating system or an IDE). (T must prove that S is independent of any IDE.)

S must be placed on a distributed version control system. S must evolve iteratively, incrementally, and regularly. (T must at least twice a week commit non-trivially to a distributed version control system, and make his or her account accessible to the teaching assistants.) T is encouraged to use Semantic Versioning for versioning of artifacts.

T must use a debugger. (T must prove that a debugger was used.)

S must follow a style of programming recommended by an authoritative source. (For Python, one such authoritative source is PEP 8.) The actual style of programming must aim to be consistent across T. T must provide a pointer to the style guidelines used.

S must be documented appropriately using a ‘standard' documentation system. (For Python, such a documentation system is Pydoc.) It is recommended that the internal documentation and the source code evolve synchronously.

S must not violate established principles of programming. (For example, such principles for object-oriented programming are those related to abstraction, encapsulation, inheritance, and/or polymorphism.)

S must not declare π as a named constant. (It must compute the value of π.)

S must have proper support for handling exceptions. S must have proper error messages.
T must provide a listing of S.

T must provide a description of instructions for processing S (by compiling or interpreting it, as the case may be).

T must provide information related to any (reasonable) assumptions made by S, references for supporting technical arguments, claims, and any non-original work (that is, any work external to T), and so on. A comprehensive collection of resources on citing and referencing is available1. For example, ACM, APA, and IEEE provide standard formats for citing and referencing. It is important not to make claims that cannot be substantiated, and not to copy others' work verbatim regardless of whether it is cited. A work that is copied in any manner (syntactically, semantically, or pragmatically) does not earn any credit.

PROBLEM 4.

This is about static testing.

S must be reviewed (inspected) systematically against the "best practices" and style guidelines it is supposed to conform to.

NOTE

The static testing process must non-reciprocally rotate across the class.

Let T1, ..., Tn be the teams in the class. To make the process predictable, T1 will review S
T2, T2 will review S by T3, ..., Tn will review S by T1. (This is always possible if n > 2.)

Let Tα and Tβ be two arbitrary teams in the class. Then, a static testing of P by Tα can be carried out by Tβ, but not conversely, that is, a static testing of P by Tβ cannot be carried out by Tα.

Tα must make available all its incarnations to Tβ. Tβ must provide a record of the outcome of review.

PROBLEM 5.

This is about dynamic testing.

P must be tested systematically. There must be a list of test cases. There must be a description of each test case. A test case must clearly outline the input and expected output.

The dynamic testing process must non-reciprocally rotate across the class.

Let T1, ..., Tn be the teams in the class. To make the process predictable, T1 will test P by T2, T2 will test P by T3, ..., Tn will test P by T1. (This is always possible if n > 2.)

Let Tα and Tβ be two arbitrary teams in the class. Then, a dynamic testing of P by Tα can be carried out by Tβ, but not conversely, that is, a dynamic testing of P by Tβ cannot be carried out by Tα.

Tα must make available all its incarnations to Tβ. Tα must provide a collection of test cases.
Tβ must provide a record of the outcome of testing.

PROBLEM 6.
T must give a presentation that (a) using sample data, demonstrates and compares both the incarnations of P, and (b) highlights lessons learned from working together, reviewing, and testing efforts, and (c) points out limitations of any tools used.

Attachment:- Advanced Programming Practices.rar