Lecture Notes on Object-Oriented Programming

Behavior analysis

Focuses on behavior, versus properties.

Consider the responsibilities and functionality that must be represented. Form classes based on similar behavior.

Domain analysis

Consider what has come before. Study existing systems, interview domain experts.

Users are often domain experts (particularly when they are customers).

One danger of domain analysis is that you must avoid limiting yourself to the goals or paradigms of existing systems. Users often know their job too well in the context of an existing tool. They can discourage innovation.

Example: you interview the main user of a human resources application program. You find out exactly how she uses the tool, where she spends the most time, how she thinks about the tasks she performs. But what you learn is often filtered through the user interface of the tool being used. The trick is to get behind the existing system and answer the fundamental questions about what needs to be done.

Use-case analysis (aka Storyboarding)

Users and developers construct common scenarios of operation and "walk through" these scenarios looking for knowledge that must be represented and actions that must be performed. While doing this you answer the question, "who shall know/do this?", which leads to the formation of classes and objects.

The problem with this technique is that scenarios overlap, so you have a lot of redundancy to wade through. It is also very difficult to know when you've captured all (or X%) of the needed classes/objects.

Use-case is applicable to most every technique, and a valuable way to get started on the iterative process of analysis, design and implementation.

Pattern scavenging

Looking for commonality among your class descriptions, or from previous projects. This is becoming more and more important, as experience with OO becomes more widespread, certain common patterns are emerging. Gamma, et al in Design Patterns, identify 23 common patterns in 3 broad areas (creational, structural, behavioral) which have been proven useful.

Classical analysis

This approach follows the traditional approach to classification; recognize the entities that share common properties and form a class.

Look for the following in the problem description (three author's suggestions):

• Things, Roles, Events, Interactions
• People, Places, Things, Organizations, Concepts, Events
• Structure, External Systems, Devices, Events remembered, Roles played, Locations, Organizational units

This is the most pragmatic of the techniques. It can help you avoid the "blank page syndrome".

Starting from a written description of the system to be designed (a requirement specification) you analyze the English for verbs and nouns. Nouns are potential classes and objects, verbs are potential methods (to be assigned to classses).

The quality of the analysis depends a lot on the quality of the written document you start from. This technique suffers from a completeness problem.

The prime benefit of this technique is that is is very algorithmic, and hence easy to apply when you are facing a "blank page".

Summary

In reality a developer ends up using bits and pieces from all these techniques; you can readily identify fundamental classes based on commonality of knowledge (classical) and function (behavioral), you check out existing products and solutions, talk with experts in the field (domain), construct role-play scenarios (use-case), and pore over requirement specifications (English descriptions).

Tools can be helpful in this process. One such tool is the CRC card.