Object Oriented Software Design

Subsystem Design. Once more analyze your System and Software Specs; determine whether all the Use Cases are supported by your packages and classes. Determine if you need any additional components (eg., Java Beans) to implement your User Interface. Add more classes/packages, if necessary.

Show the new packages and relationships among the packages. Briefly describe the changes you made (with respect to your System Spec) and why.

Analyze packages (developed in the System Specification phase) with respect to modularity (cohesion and coupling). Your subsystems should have strong internal cohesion and weak external coupling. If this is not the case, redefine your packages (subsystems).

Analyze your classes from the point of view of inheritance. If some classes have much in common try to define a superclass and make the subclasses inherit from the superclass. This will save you some coding and testing time later.

List all the packages and state their level of cohesion and coupling. Explain how/why you arrived at this estimate of cohesion and coupling.

Decide whether your subsystems will be implemented as concurrent tasks. If so, identify/add a task management component and identify/describe the task management mechanism (provide a verbal description of synchronization with references to your class and state machine diagrams).

Decide whether your systems needs a data management component. If so, and if your system does not have one yet, add it. It might be useful to keep some permanent data, so that you don't need to bring into the memory all of your data each time you interact with the system. The data management component must be compatible with the ER diagrams you developed in System Spec.

Class and Object Design. Analyze your Software Spec, all of the classes from the point of view of completeness, i.e., whether your classes have all the necessary attributes and all the necessary methods. Make sure your State Diagrams are consistent with your Class Diagrams. All the events and messages must have their sources (where they are generated) and destinations (where they are applied). If you make changes to your Software Spec as a result of this step, document it (provide a paragraph or more, if necessary).

Provide more detail on your class attributes, i.e., design data structures for the attributes. You can use either pseudo-code or the programming language you are going to implement the system in.

Provide pseudo-code (not your programming language!) description for all the algorithms (methods). Use procedural abstraction for progressive pseudocode development. Include short narrative overview of each function.

Message Design. Define all the messages (all the parameters that are passed).

Optimize your class diagrams for efficiency. Analyse access paths. If some access paths are too long, provide simpler access to methods. Document your changes.

Behavior Design. Analyze your state transition diagrams. Decide how to implement the control structure defined in the STDs. The options are: (1) procedural (similar to structure charts), (2) generic state transition engine (state transition table plus the engine that serves as a dispatcher), (3) concurrent processes with concurrency mechanisms to control interprocess communication (semaphores, sockets).

Final Thoughts. Now take a look at your design from a distance. See if it "makes sense". See if you can apply some design heuristics. Show how you used heuristics in the design process.