The Deacon OOAD method outline

The Deacon OOAD method outline

Three Model Approach:

Subject Matter Model: Comprises of domain entities(discovered in the subject matter), which are intrinsic and extrinsic state storing packets with identy, and sometimes state transition diagrams

From requirements and other architecture considerations, compatibility with legacy frameworks and code etc. find the 'entities' of the domain from 'nouns', 'relevant remembered events' etc. 

Chunking is used to breakup the domain into right-sized chunks, relevant to the domain,  that have high cohesion and low coupling.

DOn't pay attention to the behaviour of the domain entities. They are unlikely to carry over to the final software system.

Pay attention to the intrinsic state of the entities i.e. the value attributes of an entity - like mass, colour, interest rate etc. and record them

Pay attention to the extrinsic state of the entities i.e. their associations with other entities, along with cardinality.

Rarely, you may need to record State transition diagrams for one or (very rarely) more entities.
Avoid Many-many relationships between entities by trying to find a connecting 'hub' entity that connects the two entities.

Object Type Model: Comprises the Entity Types that comprise the design along with interaction diagrams like sequence diagrams for different use cases

Using CRC (Class-Responsibility-Collaboration) card method, employed on Use cases of interest, come up with the messages that need to passed to an entity, which translate to responsibilities that entities have to own. When the number of such responsibilities exceed 7 or so, try to see if the responsibilities can be delegated to other entities keeping in mind high Cohesiveness and low Coupling considerations. If no suitable existing entities are found see if you can come up with new entities - these are the speculative and contrived, not discovered or inherent in the subject matter. 

 A responsibility, in turn requires to pass other messages to other entities, to do it job. This leads to Sequence diagrams or collaboration diagrams. 

 The entities themselves lead to discovering of Object Types.

The whole philosophy is to follow outside-in design. Responsibilities and more entities are introduced on an entity because some entities outside it require services from it.

Technical Model: Comprises the Type and Class hierarchy, properly named

This finally leads to Class diagrams. Here again you use CRC's to allot reponsibilities. Naming should be most general for the root and intermediate classes/interfaces and specific for the concrete classes/interfaces.