UML Collaboration Diagrams
A major task of the design phase is creating the interaction diagrams for the system operations. Read this section to learn more about collaboration diagrams. As you review the examples, consider general principles in assigning responsibilities. Ask yourself, how do you determine the relationship between objects? How can you extract the classes? How do you determine whether a mentioned feature can be considered a class attribute? How would you determine class methods?
Overview of Design Phase
Complex system operations must be decomposed into simpler internal operations which are assigned to (or carried out by) objects. The major task in the design is to create the collaboration diagrams for the system operations identified in the requirement analysis phase. The most important and difficult part in the generation of collaboration diagrams is the assignment of responsibilities to objects. This activity discusses the general principles for responsibility assignment, which are structured in a format called patterns.
Artifacts needed for creating collaboration diagrams:
(a) Conceptual model: In this, software classes corresponding to concepts are defined.
(b) System operations contracts: which deals with the identification of responsibilities and post conditions that the interaction diagrams must fulfill
(c) Essential (or real) use cases: Involves collection of information about what tasks the interaction diagrams fulfill, in addition to what is in the contracts
GRASP: Patterns for Assigning Responsibilities
Deciding what methods belong where and how objects should interact is terribly important and trivial. Assigning responsibility is a crucial/critical step in developing object-oriented systems.
By definition; a responsibility is a contract or obligation of an object. Responsibilities are related to the obligations of objects in terms of their behaviour. The purpose is to help methodically apply fundamental principles for assigning responsibilities to objects. Within the UML artifacts, a common context where these responsibilities (implemented as methods) are considered is during the creation of interaction diagrams. Responsibilities can be grouped into two main types:
Doing responsibilities: These are about the actions that an object can perform including: doing something itself such as creating an object or doing a calculation, initiating an action or operation in other objects, controlling and coordinating activities in other objects
Knowing responsibilities: These are about the knowledge an object maintains: knowing about private encapsulated data, knowing about related objects, knowing about things it can derive or calculate.