Organization of a Large Object-Oriented Project

Clarify the purpose of the project and set short-term goals

  1. Make a list of features that the client wants
  2. Think about each feature. Who is it for, and why is it important
  3. Clarify each feature so you make sure you know its purpose
  4. Prioritize your features list
  5. Use the features list for planning and building frequent, tangible working results

Create an interface and see if it meets the needs of the user

  1. For each part of the project see what the user wants and when it is needed.
  2. What input and output will best serve the user.
  3. Sometimes in discussing the interface you get a better idea of what the user actually wants and needs. Also get a better idea of what is easiest for the user.
  4. Once you have discussed the interface with drawings, do a mockup of the interface and see if the user is still happy.
  5. Your mockup can simply ask for input (if required) and pass back faked data to show how the program will work.

Determine the class structure of the Application Classes

When you have a firm idea of what the user wants, you can design classes based on these requests.

How do you decide on the classes needed?

  1. Locate nouns in your description of the problem. Most of these will be classes.
  2. Are there a series of related operations? If so, you may use a hierarchy of classes, one for each operation, to represent these operations.

How do you determine the operations on each class?

Once you have a list of classes you can determine functions by finding verbs associated with each class.

Set short term goal to get the project started.

What are the highest priority items on your list of features? To accomplish the high priority items which classes and files must be implemented? Once you have a list of classes, sketch the functions that accomplish the highest priority feature using scenarios. From the scenarios you will learn what other classes are involved in this operation and what functions must be defined for these other classes. Complete one of the features. If this goes smoothly create the code for the next feature. Continue down the priority list until you have finished. Communicate with the user frequently, showing features that have been completed and getting feedback. This accomplishes two things. First, the user has confidence that progress is being made and will not bug the programmers. Second, the programmers get regular feedback, so they are more confident they are heading in the right direction, or catch problems early on so they don't get out of hand. Set up regular meetings with the client, so the programmers know that on a given day of the week or month, a segment of the program must be complete. Also set up a regular time for groups to get together to insure that their programs can communicate.

Some design suggestions

  1. Each programming group should be responsible for one DLL
  2. Include a dummy function for each of the application functions, so you can compile the whole interface before application is complete.
  3. Make sure each application function returns a string that can be used by the interface to indicate the result of the operation. This will ensure that the application can be moved to another type of windowing system. The dummy functions should return dummy strings so if they are called we know they are dummys.
  4. Look for classes you have already built to see if they can be reused.
  5. Make some DLLs from interface items that you use such as right-button selection in a list box.
  6. Limit the depth of your hierarchy to four levels. A wide shallow tree is preferable to a narrow deep tree. Use containment rather than inheritence when possible.

How will the various parts of the program communicate? Where will the action take place?

  1. If one object is changed, will other objects change as a result?
  2. Will interfaces have to change to reflect changes in an object? If so which ones?
  3. Can you create a mediator to receive messages from the classes and send messages to other classes to indicate changes that are needed?
  4. Changes are best stored in the application classes since windows messages have a fixed format that will not hold changes.