Describe the following with suitable examples: A) Modeling the realization of a Use case B) Modeling the realization of an operation C) Modeling a Mechanism

A) Modeling the Realization of a Use Case
One of the purposes for which you’ll use collaborations is to model the realization of a use case. You’ll typically drive the analysis of your system by identifying your system’s use cases, but when you finally turn to implementation, you’ll need to realize these use cases with concrete structures and behaviors. In general, every use case should be realized by one or more collaborations. For the system as a whole, the classifiers involved in a given collaboration that is linked to a use case will participate in other collaborations, as well. In this way, the structural contents of collaborations tend to overlap one another.

To model the realization of a use case,
· Identify those structural elements necessary and sufficient to carry out the semantics of the use case.
· Capture the organization of these structural elements in class diagrams.
· Consider the individual scenarios that represent this use case. Each scenario represents a specific path through the use case.
· Capture the dynamics of these scenarios in interaction diagrams. Use sequence diagrams if yon want to emphasize the time ordering of messages. Use collaboration diagrams if you want to emphasize the structural relationships among these objects as they collaborate.
· Organize these structural and behavioral elements as a collaboration that you can connect to the use case via realization. In most cases, you won’t need to model the relationship between a use case and the collaboration that realizes it explicitly. Instead, you’ll tend to leave that in the backplane of your model. Then let tools use that connection to help you navigate between a use case and its realization.

B) Modeling the Realization of an Operation
Another purpose for which you’ll use collaborations is to model the realization of an operation. In many cases, you can specify the realization of an operation by going straight to code. However, for those operations that require the collaboration of a number of objects, it’s better to model their implementation via collaborations before you dive into code. You can also model an operation using activity diagrams. Activity diagrams are essentially flowcharts. So for those algorithmically intensive operations that you want to model explicitly, activity diagrams are usually the best choice. However, if your operation requires the participation of many objects, you’ll want to use collaborations, because they let you model the structural, as well as behavioral, aspects of an operation. The parameters return value, and objects local to an operation provide the context for its realization. Therefore, these elements are visible to the structural aspect of the collaboration that realizes the operation, just as actors are visible to the structural aspect of a collaboration that realizes a use case. You can model the relationship among these parts using class diagrams that specify the structural part of a collaboration To model the implementation of an operation,
· Identify the parameters, return value, and other objects visible to the operation.
· If the operation is trivial, represent its implementation directly in code, which you can keep in the backplane of your model, or explicitly visualize it in a note.
· If the operation is algorithmically intensive, model its realization using an activity diagram.
· If the operation is complex or otherwise requires some detailed design work, represent its implementation as a collaboration. You can further expand the structural and behavioral parts of this collaboration using class and interaction diagrams, respectively.

C) Modeling a Mechanism
In all well-structured object oriented systems, you’ll find a spectrum of patterns. At one end, you’ll find idioms that represent patterns of use of the implementation language. At the other end, you’ll find architectural patterns and frameworks that shape the system as a whole and impose a particular style. In the middle, you’ll find mechanisms that represent common design patterns by which the things in the system interact with one another in common ways. You can represent a mechanism in the UML as collaboration. Mechanisms are collaborations that stand alone; their context is not a single use case or an operation but, rather, the system as a whole. Any element visible in that part of the system is a candidate for participation
in a mechanism. Mechanisms such as these represent architecturally significant design decisions and should not be treated lightly. Typically, your system’s architect will devise its mechanisms, and you’ll evolve these
mechanisms with each new release. At the end, you’ll find your system simple (because these mechanisms reify common interactions), understandable (because you can approach the system from its mechanisms), and resilient (by tuning each mechanism, you tune the system as a whole).
To model a mechanism,
· Identify the major mechanisms that shape your system’s architecture. These mechanisms are driven by the overall architectural style you choose tlo impose on your implementation, along with the style appropriate to your problem domain.
· Represent each of these mechanisms as a collaboration.
· Expand on the structural and behavioral part of each collaboration. Look for sharing, where possible.
· Validate these mechanisms early in the development lifecycle (they are of strategic importance), but evolve them with each new release, as you learn more about the details of your implementation.