Basic Behavioral Modeling in UML (OOSD)

Basic Behavioral Modeling: Interactions and Use Cases

1. UNIT - II

2. Basic Behavioral Modeling: Interactions, Use Cases, Use Case Diagrams, Interaction Diagrams, Activity Diagrams. Advanced Behavioral Modeling: Events and signals, State Machines, Processes and Threads, Times and space, State Chart Diagrams.

3. Behavioral Diagrams Behavioral UML diagrams focus on illustrating the dynamic aspects of a software system, showcasing how it behaves, responds to stimuli, and undergoes state changes during runtime. Behavioral diagrams are used to visualize, specify, construct, and document the dynamic aspects of a system. Behavior diagrams are visual tools for modeling the dynamic aspects of a system, showing how it changes and interacts over time. They depict processes, workflows, object interactions, and how a system responds to events.

4. You can think of the dynamic aspects of a system as representing its changing parts. Just as the dynamic aspects of a house encompass airflow through the rooms of a house, so too do the dynamic aspects of a software system encompass such things as the flow of messages over time and the physical movement of components across a network.

5. The UML's behavioral diagrams are roughly organized around the major ways you can model the dynamics of a system.

6. Use Case Diagram A Use Case Diagram in Unified Modeling Language (UML) is a visual representation that illustrates the interactions between users (actors) and a system. It captures the functional requirements of a system, showing how different users engage with various use cases, or specific functionalities, within the system. Use case diagrams provide a high-level overview of a system’s behavior, making them useful for stakeholders, developers, and analysts to understand how a system is intended to operate from the user’s perspective, and how different processes relate to one another. They are crucial for defining system scope and requirements.

7. Sequence Diagrams A Sequence Diagram is used to visualize the interaction between objects in a sequential order. It focuses on how objects communicate with each other over time, making it an essential tool for modeling dynamic behavior in a system. Sequence diagrams illustrate object interactions, message flows, and the sequence of operations, making them valuable for understanding use cases, designing system architecture, and documenting complex processes. The diagram captures how objects communicate with each other through a series of messages, providing a clear view of the sequence of operations or processes.

8. Collaboration Diagrams Collaboration Diagram is a type of Interaction Diagram that visualizes the interactions and relationships between objects in a system. It shows how objects collaborate to achieve a specific task or behavior. Collaboration diagrams are used to model the dynamic behavior of a system and illustrate the flow of messages between objects during a particular scenario or use case. A collaboration diagram is a behavioral UML diagram which is also referred to as a communication diagram. It illustrates how objects or components interact with each other to achieve specific tasks or scenarios within a system.

9. In simpler terms, they visually represents the interactions between objects or components in a system and show how they collaborate to accomplish tasks within a system, and also illustrate the system's object architecture.

10. State Machine Diagram A S tate diagram is used to represent the condition of the system or part of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state transitions. State Machine diagrams are also known as  State Diagrams  and  State-Chart Diagrams . A state machine diagram is used to model the dynamic behaviour of a class in response to time and changing external stimuli( events that cause the system to change its state from one to another).

11. Activity Diagram Activity diagrams show the steps involved in how a system works, helping us understand the flow of control. They display the order in which activities happen and whether they occur one after the other (sequential) or at the same time (concurrent). These diagrams help explain what triggers certain actions or events in a system. An activity diagram starts from an initial point and ends at a final point, showing different decision paths along the way. They are often used in business and process modeling to show how a system behaves over time.

12. Time Sequence Diagram Time Sequence Diagram are a special form of Sequence diagrams which are used to depict the behavior of objects over a time frame. We use them to show time and duration constraints which govern changes in states and behavior of objects. Interaction Overview Diagram An Interaction Overview Diagram models a sequence of actions and helps us simplify complex interactions into simpler occurrences. It is a mixture of activity and sequence diagrams.

13. Benefits of using Behavioral UML diagrams Understanding How Things Work: These diagrams act like visual stories, helping everyone on the team understand how different parts of a computer program or system work together. Seeing the Order of Actions: They show the order in which things happen when you use a program. Planning Step-by-Step Processes: When designing a program, these diagrams help plan step-by-step processes, making it easier for developers to know what to do next.

14. Showing Different States: For programs that can be in different states (like a traffic light changing colors), these diagrams help show how things move from one state to another. 5. Team Collaboration: When a team is working on a project, these diagrams become a shared language. Everyone can look at the pictures and quickly understand what's going on. 6. Fixing Problems Early: By looking at these diagrams, teams can catch and fix problems early on, avoiding headaches later in the project.

15. Challenges faced in developing Behavioral UML diagrams Deciding What to Show: Figuring out what to include in the pictures and what to leave out can be a bit like deciding which parts of a movie to show in a trailer. It needs to be just enough to get the idea across. Dealing with Changes: When things in the program change, updating the pictures to match can be a bit like trying to edit a video. Understanding Different Perspectives: People might look at the pictures and see things in different ways. Making sure everyone agrees on what the pictures mean can be a bit challenging.

16. Showing Time and Order: Expressing the order in which things happen or showing how a program changes over time can be a bit like drawing a comic strip. It needs to be clear and in the right sequence. Balancing Detail and Simplicity: Striking the right balance between showing enough detail without making the pictures too complicated can be a bit like finding the perfect recipe. Too much or too little can be a problem. Making Sure It's Useful for Everyone: Ensuring that the pictures are helpful for different people on the team, like designers and developers, is a bit like creating a map that everyone can use.

17. Spotting Mistakes Early: Catching and fixing mistakes in the pictures early on is a bit like proofreading a story. It's important to get it right before everyone starts working on the program. Keeping It Simple and Clear: Making sure the pictures stay simple and clear can be a bit challenging. It's important that everyone can easily understand them.

18. Interactions In every interesting system, objects don't just sit idle; they interact with one another by passing messages. An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose. You use interactions to model the dynamic aspect of collaborations, representing societies of objects playing specific roles, all working together to carry out some behavior that's bigger than the sum of the elements.

19. These roles represent prototypical instances of classes, interfaces, components, nodes, and use cases. Their dynamic aspects are visualized, specified, constructed, and documented as flows of control that may encompass simple, sequential threads through a system, as well as more-complex flows that involve branching, looping, recursion, and concurrency. You can model each interaction in two ways: by emphasizing its time ordering of messages, or by emphasizing its sequencing of messages in the context of some structural organization of objects.

20. An interaction is a behavior that contains a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message is specification of a communication between objects that conveys information with the expectation that the activity will succeed. The objects that participate in an interaction are either concerete things or prototypical things. An object represents a real world entity. Example p is an instance of a class Person .

21. A message specifies the communication between objects for an acitivity to happen. It has the following parts: it’s name, parameters(if any), and a sequence number.

22. Links We use a link to represent a relationship between two objects. We represent the number of participants on the link for each, at the end of the link. The term link is used to specify a relationship between two instance specifications or objects. We use a solid line to represent a link between two objects.

23. Messages A message is the specification of a communication among objects that conveys information with the expectation that activity will ensue. The receipt of a message instance may be considered an instance of an event. When you pass a message, the action that results is an executable statement that forms an abstraction of a computational procedure. An action may result in a change in state.

24. In the UML, you can model several kinds of actions.

25. Sequencing When an object passes a message to another object (in effect, delegating some action to the receiver), the receiving object might in turn send a message to another object, which might send a message to yet a different object, and so on. This stream of messages forms a sequence. Any sequence must have a beginning; the start of every sequence is rooted in some process or thread. Furthermore, any sequence will continue as long as the process or thread that owns it lives.

26. Use Cases A use case specifies the behavior of a system or a part of a system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor. A use case involves the interaction of actors and the system. An actor represents a coherent set of roles that users of use cases play when interacting with these use cases. Actors can be human or they can be automated systems. For example, in modeling a bank, processing a loan involves, among other things, the interaction between a customer and a loan officer.

27. A use case describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actors) with the system itself (and its key abstractions). These behaviors are in effect system-level functions that you use to visualize, specify, construct, and document the intended behavior of your system during requirements capture and analysis. A use case represents a functional requirement of your system as a whole. For example, one central use case of a bank is to process loans.

28. A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor. Graphically, a use case is rendered as an ellipse.

29. Use Cases and Actors An actor represents a coherent set of roles that users of use cases play when interacting with these use cases. Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system. For example, if you work for a bank, you might be a LoanOfficer. If you do your personal banking there, as well, you'll also play the role of Customer. An instance of an actor, therefore, represents an individual interacting with the system in a specific way.

30. Actors may be connected to use cases only by association. An association between an actor and a use case indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages.