Design Document 2, CSC/CPE 203

In the first pair of assignments you identified methods and moved them into the most appropriately associated classes. In doing so, you may have noticed that some classes support functionality (methods) that are not appropriate for all instances of the class. Moreover, these classes support data attributes that are not used by all instances of the class.

This is an issue of cohesion. Specifically, these classes (tips for identifying them are given later) exhibit low (poor) cohesion by representing multiple (admittedly related) concepts by combining all attributes and methods used by each concept.

This pair of assignments asks that you improve the code base by splitting each class exhibiting low cohesion into multiple highly cohesive classes. Doing so in the context of Java will require identifying common methods for each subset of these new classes and then introducing a new interface for each logical grouping of these methods (more on this below).

Objectives

Task Overview

You must identify those classes with low cohesion and then split these classes into separate classes exhibiting high cohesion. Since each of these new classes will introduce a separate type, you may need to "root" them at a single type (as defined by an interface) to satisfy Java's type checking rules. You will not introduce any additional classes beyond those used to improve cohesion (e.g., you will not use inheritance in this pair of assignments). This refactoring is quite likely to increase the amount of code through the duplication of some methods; this is expected and ok at this time.

Based on the original source code, there are likely two categories of classes with low cohesion. The first category consists of those classes that depend on ActionKind or EntityKind. The second category depends on your final distribution of the methods in the original Functions class.

As before, you are encouraged to develop both the UML design document and the code refactoring at the same time. You are further encouraged to implement the refactoring incrementally so that your refactored program executes properly at each step. You will submit the design document before the final refactoring submission to allow for feedback on your design that can then be incorporated into your refactoring.

Introducing Interfaces

The following are some tips on approaching the introduction of interfaces to support splitting classes.

Note: A class should very rarely implement an interface only to then define a method required by the interface to do nothing at all. A class should not implement an interface and then define a method required by the interface to raise an exception indicating that the method is not supported.

Your introduction of interfaces for this project must be meaningful. It is insufficient to define a single interface with all methods that are then only partially implemented by each of the classes.

Design Document

Your "design document" will consist only of an updated UML diagram. Copy the UML diagram from the prior design assignment to Interfaces.graphml. Then update this copy to reflect the new classes and the interfaces.

You can add an interface to the UML document by adding a class and then, under the UML tab in properties, setting the Stereotype field to "interface". For each interface that a class implements, be sure to draw an appropriate arrow (dashed line with open triangle head) from the class to the interface. If an interface extends another interface in your design, then be sure to connect them with an appropriate arrow (solid line with open triangle head).

Assignment Submission

A github repository will be provided for you to submit your UML redesign - stay tuned for instructions.

Your submission of your design document will consist of the following files.