set of messages exchanged among objects in a set of roles within a context to accomplish a purpose. • A message is a specification of a Collaboration between objects that conveys information with the expectation that activity will ensue. 2. Use Cases and Use Case Diagram • Only static behavior is not sufficient to model a system rather dynamic behavior is more important than static behavior. • In UML, there are five diagrams available to model the dynamic nature and use case diagram is one of them. • A use case model describes a system’s functionality from the point of view of the different actors that interact with the system to receive services. • These internal and external agents are known as actors. • A use case diagram shows the relationships among actors and use cases within a system. Use case diagrams address the static use case view of a system. • Use case diagrams consists of actors, use cases and their relationships. The diagram is used to model the system/subsystem of an application. • A single use case diagram captures a particular functionality of a system. • Hence to model the entire system, a number of use case diagrams are used. • The purposes of use case diagrams can be said to be as follows − – Used to gather the requirements of a system. – Used to get an outside view of a system. – Identify the external and internal factors influencing the system. – Show the interaction among the requirements are actors. i. Actors • A coherent set of roles that users of use cases play when they interact with use cases • Typically represents the role that a human, hardware device or another system plays with the system • Actors are not part of the system • As an actor is a class, it can be generalized ii. Use cases • Someone interacts with use case (system function). • Named by verb + Noun (or Noun Phrase). • i.e. Do something • Each Actor must be linked to a use case, while some use cases may not be linked to actors. iii. System Boundary • The system boundary is potentially the entire system as defined in the requirements document. • For large and complex systems, each module may be the system boundary. • The entire system can span all of these modules depicting the overall system boundary. • It is optional. Relationships: i. Communicates Relationships • The participation of an actor in a use case is shown by connecting an actor to a use case by a solid link. • Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages. • In this relationship <<communicates>> keyword is used. ii. Extends relationship • Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case. • Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. • The extend relationship is owned by the extending use case • The extension takes place at one or more extension points defined in the extended use case. • Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. • The arrow is labeled with the keyword «extend». iii. Include relationship or uses relationship • When a use case is depicted as using the functionality of another use case, the relationship between the use cases is named as include or uses relationship. • A use case includes the functionality described in another use case as a part of its business process flow. • A uses relationship from base use case to child use case indicates that an instance of the base use case will include the behavior as specified in the child use case. • An include relationship is depicted with a directed arrow having a dotted line. • The tip of arrowhead points to the child use case and the parent use case connected at the base of the arrow. • The stereotype "<<include>>" identifies the relationship as an include relationship. iv. Generalization Relationship • A generalization relationship means that a child use case inherits the behavior and meaning of the parent use case. • The child may add or override the behavior of the parent. How to Draw a Use Case Diagram? • Use case diagrams are drawn to capture the functional requirements of a system. After identifying the above items, we have to use the following guidelines to draw an efficient use case diagram • The name of a use case is very important. The name should be chosen in such a way so that it can identify the functionalities performed. • Give a suitable name for actors. • Show relationships and dependencies clearly in the diagram. • Do not try to include all types of relationships, as the main purpose of the diagram is to identify the requirements. • Use notes whenever required to clarify some important points. Example 1 Example 2 Example 3