Dear,

A use case diagram is “a diagram that shows the relationships among actors and use cases within a system.” 

Use case diagrams are often used to:

Model your analysis of your usage requirements in the form of a system use case model.

 Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor. 

Use Case Names Begin with a Strong Verb.

Name Use Cases Using Domain Terminology.

Place Your Primary Use Cases In The Top-Left Corner Of The Diagram.

Imply Timing Considerations By Stacking Use Cases. 

the use cases that typically occur first are shown above those that appear later. 

In this below fig. Implying timing considerations between use cases.  

 

  Although UML class diagrams are very good at describing this very information some people find them too abstract – a UML object diagram can be a good option for explaining complex relationships between classes.   

UML sequence diagrams are a dynamic modeling technique. UML sequence diagrams are typically used to:

Validate and flesh out the logic of a usage scenario. A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course; one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action plus one or more alternate scenarios; or a pass through the logic contained in several use cases, for example a student enrolls in the university then immediately enrolls in three seminars. 

Explore your design because they provide a way for you to visually step through invocation of the operations defined by your classes.

To detect bottlenecks within an object-oriented design. By looking at what messages are being sent to an object, and by looking at roughly how long it takes to run the invoked method, you quickly get an understanding of where you need to change your design to distribute the load within your system. In fact some CASE tools even enable you to simulate this aspect of your software. 

Give you a feel for which classes in your application are going to be complex, which in turn is an indication that you may need to draw state chart diagrams for those classes.

A UML sequence diagram.

 


Collaboration Diagram

UML collaboration/communication diagrams like UML sequence diagrams, are used to

explore the dynamic nature of your software.

Collaboration diagrams show the message flow between objects in an OO application, and also imply the basic associations (relationships) between classes.

Collaboration diagrams are often used to:

Provide a birds-eye view of a collection of collaborating objects, particularly within a

real-time environment.

Allocate functionality to classes by exploring the behavioral aspects of a system.

Model the logic of the implementation of a complex operation, particularly one that

interacts with a large number of other objects.

 Explore the roles that objects take within a system, as well as the different relationships

they are involved with when in those roles.

Basic components of Collaboration Diagram

 Objects, Association Roles, Links and Messages.

The true value of a use case lies in two areas:

• The written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.

• The position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

This diagram describes the functionality of a simplistic Restaurant System. Use Cases are represented by ovals and the actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Prepare Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.

SEQUENCE DIAGRAM

A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

Simple Restaurant Sequence Diagram
This diagram represents a Patron ordering food and wine, drinking wine then eating the food, and finally paying for the food. The dotted lines extending downwards indicate the timeline, time flows from top to bottom. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.