Object-Oriented Software Development with UML - UNU-IIST ...

Creating Collaboration Diagrams 99The general steps to create collaboration diagrams is described as follows. Start with the responsibilitieswhich are identified from the use cases, conceptual model, and system operations’ contracts. Assign theseresponsibilities to objects, then decide what the objects needs to do to fulfill these responsibilities in order toidentify further responsibilities which are again assigned to objects. Repeat these steps until the identifiedresponsibilities are fulfilled and a collaboration diagram is completed.For example, we may assign the responsibility for print a K+R§Z†N to the K+R§Z†N instance (a doing responsibility),Or we assign the responsibility of knowing the date of a K-RZ†N to the K+RZ[N instance itself (a knowing responsibility).Usually, knowing responsibilities are often inferable from the conceptual model, because of theattributes and associations it illustrates.Responsibilities of an object are implemented by using methods of the object which either act alone or collaboratewith other methods and objects. For example, the K+RZ[N class might define a method that performingprinting a K+RZ[N instance; say a method named M_EWOLUsC . To fulfill that responsibility, the K+RZ[N instance mayhave to collaborate with other objects, such as sending a message to K+RZ[NWA:\ OLU+N9VWCXNY objects asking them toprint themselves.Within UML, responsibilities are assigned to objects when creation a collaboration diagram, and the collaborationdiagram represents both of the assignment of responsibilities to objects and the collaborationbetween objects for their fulfilment.For example, Figure 7.14 indicates thatK-RZ†N1. objects have been given a responsibility to print themselves, which is invoked with amessage.M_EWOLUsC2. The fulfilment of this responsibility requires collaboration with K+RZ[NWA;\]O^U-N9VWCXNDY objects asking themto print.7.3.4 GRASP: Patterns of General Principles in Assigning ResponsibilitiesExperienced OO developers build up both general principles and idiomatic solutions called patterns thatguide them in the creation of software. Most simply, a pattern is a named problem/solution pair that can beapplied to new context, with advice on how to apply it in novel situations.We shall present a pattern in the following format:Pattern Name:Solution:Problem:the name given to the patterndescription of the solution of the problemdescription of the problem that the pattern solvesNow we are ready to explore the GRASP patterns: General Responsibility Assignment Software Patterns.They include the following five pattern: Expert, Creator, Low Coupling, High Cohesion, and Controller.Report No. 259, July 2002UNU/IIST, P.O. Box 3058, Macau