Responsibilities and Collaborators

Once you havfe identified the classes, define their responsibilities. These may be things the class knows or things the class does.
For example, a CheckingAccount class might know the current balance in the account and the owner of the account.
These are things the checking account knows. The CheckingAccount class might also have to deduct money from the account when a check is written. This is something the class does.

In the process of identifying a class's responsibilities, you will probably discover that the class by itself doesn't know or can not do everything it needs to know or do to carry out its responsibilities. It needs to collaborate with other classes to fulfill its obligations. Objects are particular instances of a class that contain both the data that defines the object and the methods that operate on the object. Unlike procedural programming, OOP does not separate the data structures from the algorithms. They are both bundled together inside a class.

In recent years developers have come to appreciate more and more the value of designs based on proven solutions. Patterns and collaborations allow the modelers to define standard approaches to solving common problems. A pattern may then be applied to a variety of specific situations, bringing with it a combination of predefined roles and interactions. Patterns and collaborations may be identified and defined at many levels of abstraction, cataloged, and documented for others to use. This approach brings reuse out of the realm of pure code and into every phase of the modeling effort, from requirements and architecture through implementation.

Another approach that can be used for identifying classes is Classes, Responsibilities, and Collaborators (CRC) developed by Cunningham, Wilkerson, and Beck. Classes, Responsibilities, and Collaborators, more technique than method, is used for identifying classes responsibilities and therefore their attributes and methods.