C# Program & Documentation Assignment

**_ASSIGNMENT 2_** **Due date:** Thursday, 26th May, 2005. (4:00 *p.m.*) Design and implement a set of programs that allow users logged on to a host to send messages to each other. You should start with the program you developed for lab 8 and add to it a coordination program. The coordinator should accept messages from the clients and forward them to all attached clients. You should also add a command to the client that allows it to log to a specified text file all received messages. You should use a message queue for IPC but you should attempt to encapsulate the message queue in a module that your clients and coordinator call. ## Deliverables 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. 2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables): * **Title page**, including table of contents. * **Specification: (6 marks)** * * a brief description of the _function(s)_ of the program/module(s); *[Note: "Function" has its English meaning here and doesn't refer to any subroutines (functions or procedures) of the program/module(s) required by the specification.]* * command line synopsis and description of arguments (where applicable) in the case of programs, or function prototypes in the case of modules; * specification of input / dialogue (including examples) - if any; * specification of any *config*, or other special files; * specification of output; * specification of return value(s), exit status *etc*.; * level of implementation. (This section should be similar in style to UNIX _man_ entries and should provide enough information for a _man_ entry to be constructed. Avoid verbosity!) Alternatively, you may provide a complete _man_ entry for this section. * **Assumptions and Limitations: (2 marks)** You must take a good deal of care with this section. Don't write under this heading "assumptions" in the everyday sense; *e.g.* "Assume the user won't make any keying errors on input...". An assumption describes a decision you had to make when designing the program on a point which wasn't covered in the specification; *e.g.* how the program is to _react_ to a keying error. Also include any assumptions transmitted in the specification; *e.g.* "Input lines will have less than 80 characters .." and, as well, _your_ assumption as to how the program is to react if it detects such an assumption isn't met. The term "limitations" is used to describe those circumstances in which, for practical reasons, the program will not function according to specification; often because of finite memory size. You must not list circumstances in which the program simply doesn't work because it's an incorrect program. If the program is incomplete then this should be described under "implementation level" in the specification section. NOT EVERY PROGRAMMING EXERCISE YOU ARE GIVEN WILL NEED "ASSUMPTIONS" OR "LIMITATIONS" - *DON'T INVENT THEM.* * **Solution Logic: (6 marks)** Specify program logic in a conventional (Pascal-like) pseudocode, including parenthesised assertions. Where you need to represent parallelism, use one of the formalisms presented in lectures. This section is to provide an explanation in an algorithmic style of how the program actually works. You must not obscure the explanation with programming language specific detail. Also 'low level' routines for operating on wellknown data structures need not be explained at this level. There is no reason not to accompany the pseudocode with brief explanatory notes if that is desirable in making its meaning clearer. Don't go overboard with such notes however since that only produces the opposite effect. * **Test plan : (6 marks)** Give a full but concise description of test _procedures_ to be used. Provide and explain test _data_. _Each test case must show_: * test data; * expected output; or expected program behaviour * reasons for choice, *i.e.* what aspect have these data actually tested. Include testing of any system calls for which it was appropriate. Where the assignment relates to the construction of modules, rather than a program, you must include details of drivers *etc*. It would not be usual to include trivial tests, *e.g.* those done to elicit command line error messages. * **Source code : (6 marks)** * * Specify a complete pathname for the source code; this file may be accessed by academic staff.(*Warning*: no marks for this section if you claim a clean compilation but your code won't compile or has somehow "disappeared".) * Provide a listing of source code. * If your program doesn't compile cleanly, provide a listing of compiler diagnostics. <!-- --> * **Test runs : (4 marks)** Provide sufficient hardcopy to demonstrate how actual output/behaviour matched expected output/behaviour from the test plan. Any discrepancies require explanation. There is no point in providing any test runs which use data not described in your test plan and, indeed, marks will be deducted if you do, since this practice severely detracts from the quality of documentation and validity of testing. ## Platform the program must operate in UNIX and run through secure shell (SSH)