Software Engineering

Report #2: SYSTEM DESIGN -- Iteration 1(b) --  (due date given here)

Note: Keep this report for future reference since it will be part of the final report (Report #3). Thus, as you progress through the semester, take every opportunity to revise, update and/or correct it.

1.   Report Format

The report must contain the following sections and sub-sections. Each section/subsection should be clearly delineated with a proper heading.

1. Cover Page and Individual Contributions Breakdown, as specified here.
   The contributions breakdown must contain the responsibility matrix and responsibility allocation chart as described in Report #1
2. Table of Contents
   Make sure that the page numbers listed here are correct
3. Interaction Diagrams
   • Do interaction diagrams for the use cases you elaborated (fully described) in Report #1
   • Mention explicitly what design principles you employ in the process of assigning responsibilities to objects. This can be done either as comment “bubbles” in the diagram, or in the caption of the diagram.
     Read the UML textbook about interaction diagrams and Section 2.4.1 in the course lecture notes, in order to learn about good design principles
4. Class Diagram and Interface Specification
   1. Class Diagram
      Show all classes and their associations. Only indicate visibilities of attributes and operations; full details about the types and signatures should be provided in the next item.
      If you cannot fit the class diagram on one page, or it looks too cluttered, I suggest you create one overall class diagram showing all classes and their relationships, but don't show any class details (attributes and operations). Then you show all the details as part of the next item.
   2. Data Types and Operation Signatures
      Independently of the class diagram, write down class specification in UML notation. For every class, specify data types of all attributes and operation signatures
5. System Architecture and System Design
   1. Architectural Styles
      Describe the architectural styles used in your design   (Google search software architectural styles example)
   2. Identifying Subsystems
      Draw and describe UML package diagram of subsystems in your system (See the UML textbook)
   3. Mapping Subsystems to Hardware
      Does you system need to run on multiple computers? For example, you may have client (web browser) and server (web server) processes, running on different machines.
      If NO, skip to the next item;
      If YES, what modules run on which machine? E.g., if you use handheld computers, what runs on the handheld and what runs on a base station?)
   4. Persistent Data Storage
      Does your system need to save data that need to outlive a single execution of the system?
      If NO, skip to the next item;
      If YES, identify the persistent objects and select the storage management strategy, e.g., flat files, relational database, etc.
      Attach the description of the file format and/or database database schema (format of database tables)
   5. Network Protocol
      If your runs on a single machine, this question probably does NOT apply; skip to the next item;
      Otherwise, which communication protocol do you use, e.g., plain Java sockets, Java RMI, Java JDBC, HTTP, etc. Explain why you made your specific choice.
      If you are using plain sockets, attach the description of the communication protocol (types of messages, message format, etc.).
   6. Global Control Flow
      
      • Execution orderness: Is your system procedure-driven and executes in a "linear" fashion, where every user every time has to go through the same steps, or is it an event-driven system that waits in a loop for events, and every user can generate the actions in a different order?
      • Time dependency: Is there any timers in your system?
        Is your system of event-response type, with no concern for real time, or is it a real-time system? If it's real-time, is it periodic, and what are the time constraints for each period?
      • Concurrency: Does your system use multiple threads?
        If NO, skip to the next item;
        If YES, identify the objects that have separate threads of control and describe any synchronization between the threads?
   7. Hardware Requirements
      What system does resources your system depend upon? Examples are, screen display, disk storage, communication network, or you may be accessing some special sensor/instrument.
      Describe exact requirements for these resources in order for your system to run. For example, you need color display, with minimum resolution of 640 × 480 pixels; minimum of 2 Gbytes hard disk space; minimum network bandwidth 56 Kbps.
6. Algorithms and Data Structures
   1. Algorithms
      Does your system use any complex algorithms? For example, when computing a motion trajectory for an animate figure in a game, you may use some numerical or computer-graphics algorithms. Or, when assessing stock market movements, you may be using statistical algorithms.
      If NO, skip to the next item;
      If YES, describe your algorithms. For example, for the animate figure example above, will the path coordinates be precomputed and stored in a look-up table or will they be computed using a spline interpolation algorithm.
      It's a good idea to use activity diagrams to describe the algorithm design.
   2. Data Structures
      Does your system use any complex data structures, such as arrays, linked lists, hash tables, or trees?
      If NO, skip to the next item;
      If YES, what criteria you used in deciding what data structure to use, e.g., performance vs. flexibility?
7. User Interface Design and Implementation
   • Describe whether and how you modified and implemented the initial screen mock-ups developed for Report #1. Comment only on significant changes in your user interface, those that reduce (or increase) the user effort. Changes of colors or styles are less important and should be omittted from your report.
   • The textbook does not deal much with the GUI design. Excellent guidelines for GUI design can be found here:
     Sun Microsystems, Inc. Java Look and Feel Design Guidelines. Mountain View, CA, 1999. Available at: http://java.sun.com/products/jlf/ed2/book/
   • "Ease-of-use" is generally considered the key characteristic of user interface. "Ease-of-use" should not be confused with a flashy interface, with lots of colors, picture, graphics, etc. On the contrary, you should avoid flashy user interfaces. "Ease-of-use" means that interface is intuitive, easy to understand and operate, without having to ask many questions or read voluminous documentation. A minimal user interface that is well organized should be sufficient. You already considered the user effort as part of Report #1, and here you should strive to minimize the user effort, thus maximizing the "ease-of-use".
8. Progress Report and Plan of Work
   1. Progress Report
      What use cases have been implemented?
      What is already functional, what is currently being tackled?
   2. Plan of Work
      List the projected milestones and dates by which you plan to accomplish them. Preferably, you should use Gantt charts for planning and scheduling your project.
   3. Breakdown of Responsibilities
      • List the names of modules and classes that each team member is currently responsible for developing, coding, and testing
      • Who will coordiante the integration?
      • Who will perform the testing of the integrated system?
9. References
   The list of references should contain exact references and URLs of any material that is used in the project and doesn't come from the textbook.

NOTE: No matter what programming language (Java or something else) you use to implement your software, you must provide design diagrams (interaction diagrams) in UML. Those diagrams must correspond with the implemenation source code, and this will be checked when with Report #3 you submit the source code, too. This means that the class, method, and variable names should be the same in the code and in the UML diagrams. Also, the methods n the source code must be called in the order indicated in the UML diagrams. See Chapter 2 in the textbook and Miles & Hamilton: Learning UML 2.0 for the how to create interaction diagrams.
Source code should not be submitted with this report.

NOTE: Comment your diagrams! Describe all design decisions and other things that are not obvious from the diagrams. Any useful information is welcome. There is no limit on the number of pages for the report. Having good comments and explanations greatly helps in reading and evaluating the project and will positively contribute to your grade.

Updating Use Cases From Report#1. The use case diagrams would presumably remain the same from the previous report on object oriented-analysis (Report #1), at least for now, so no need to repeat any material from that report. If any changes are made, these should be documented in Report #3.

Drawing Interaction Diagrams. Theoretically, a single interaction diagram should be drawn for each system function (check your system sequence diagram - SSD). Since some system functions are trivial, I suggest the following practical technique. Start drawing one interaction diagram per use case. If, at some point, the diagram overflows to the next page, split your interaction diagram and draw one diagram per system function.

Applying Design Principles.It is very critical to pay attention to the proper use of the design principles covered in Section 2.4 of class lecture notes. (Quick refresher: design principles include: Expert Doer, High Cohesion, Low Coupling.) Proper responsibility assignment, separation of application logic from presentation and storage tiers is of the utmost importance and will be given a great weight in grading the reports. It is important to document the alternative solutions that were considered in the design process, identify all the tradeoffs encountered and explain why the alternatives were abandoned.

This report is the final "blueprint" before the construction phase comences. Given your report, anyone who knows how to read UML diagrams should be able to implement the product in a straightforward manner. This means that you need to clearly specify all details about the algorithms and data structures used, as well as about the target runtime environment. This is by no means an exhaustive list! Please include any other information that you feel the implementer may find useful.

2.   Report Preparation

The guidelines remain the same as for Report #1.

3.   Grading

See also the grading policy for the assigning the overall team grade vs. grades for the individual members.

The reports will be graded as follows:
(NOTE: Check also the detailed grading criteria for report #2, available here.)

Aspect

Interaction Diagrams

Classes + Specs

Sys Arch & Design

Alg's & data struct

User Interface

Plan of Wrk

Ref's

Project mgmt

Applicat. of design principles

UML nota tion

Prose descr. (#)

Class diag

Signa tures

Sty les

Pckg diag

Map hard ware

Data base

other ($)

App ear ance

Prose descr. (+)

Points

20

5

10

8

5

5

5

2

5

* 5

* 4

5

5

4

2

10

Total points

100

* Point numbers preceded with an asterisk will be graded only if applicable. Otherwise, these         points will be re-assigned to other sub-sections of Section 5 of this report: System         Architecture and System Design. (#) This refers to the narrative describing your interaction diagrams.         State explicitly what design choices were made and provide the rationale for your choices. ($) Other design aspects, if applicable, given in the list above, such as network protocol, global         control flow, and hardware requirements. (+) This refers to the narrative describing your user interface design.         State explicitly what design choices were made and provide the of rationale for your choices.

See Report #1 for explanation about the "Project Management" part of the grade.

4.   Report Submission

Each team should submit only one report to the TA. Bring the report to the TA's office on or before the due date.

Please also hand in your graded report #1, if it is currently with you. This will allow us to compare the progress and facilitate our grading process.

Submission deadline: 5:00 p.m. on the due date.