UNIT IV:

Basic Behavioral Modeling-I: Interactions, Interaction diagrams Use cases, Use case Diagrams,
Activity Diagrams.Case Study: Web Application: Vacation Tracking System

INTERACTIONS

The provided explanation outlines the key concepts related to interactions, messages, links,
sequencing, and creation, modification, and destruction in the context of object-oriented analysis
and design (OOAD). Here's a breakdown of the main points:

1. **Interactions and Messages:**

- Interactions involve a set of messages exchanged among objects within a context to achieve a
specific purpose.

- A message specifies communication between objects, conveying information with the expectation
of initiating activity.

- Messages can be of different types, such as call, return, send, create, and destroy, each
representing a different action or event.

2. **Objects and Roles:**

- Objects participating in an interaction can be concrete (representing real-world entities) or

prototypical (representing any instance of a class).

- Roles denote the behavior or responsibilities associated with objects within an interaction.

3. **Links:**

- Links represent semantic connections among objects and are instances of associations between
classes.

- Links are established wherever a class has an association with another class, enabling
communication between instances of those classes.

4. **Sequencing:**

- Sequencing involves the order of messages exchanged between objects during an interaction.

- Messages form sequences, with the flow of control specified either procedurally or non-
procedurally, depending on the context.

5. **Creation, Modification, and Destruction:**

- Objects and links can enter, leave, or be modified during an interaction, which can be specified
using constraints such as New, Destroyed, or Transient.

- These constraints indicate whether an instance or link is created, destroyed, or modified during
the execution of the interaction.

6. **Representation:**

- Interactions can be represented using sequence diagrams or collaboration diagrams.

- Sequence diagrams emphasize the time ordering of messages, while collaboration diagrams focus
on the structural organization of objects involved in the interaction.
Overall, understanding interactions, messages, links, sequencing, and
creation/modification/destruction concepts is crucial for modeling and analyzing system behavior
and communication in OOAD. These concepts help in designing effective software systems that fulfill
specific requirements and objectives.

Common Modeling Techniques

1. Modeling a flow control

The explanation provided outlines the common modeling technique for representing flow control in
an interaction, typically depicted using sequence diagrams or collaboration diagrams. Here's a
breakdown of the steps involved:

1. **Set the Context:**

- Define the context for the interaction, specifying whether it pertains to the entire system, a
specific class, or an individual operation.

2. **Set the Stage:**

- Identify the objects participating in the interaction and define their initial properties, including
attribute values, states, and roles.

3. **Identify Links:**

- If the emphasis is on the structural organization of objects, identify the links connecting them.
These links represent paths of communication within the interaction.

- Specify the nature of these links using UML's standard stereotypes and constraints, if necessary.

4. **Specify Messages:**

- Specify the messages passed between objects in chronological order. Distinguish between
different types of messages and include parameters and return values as needed to convey detailed
information about the interaction.

5. **Adorn Objects:**

- Visualize each object at every point in time, indicating its state and role within the interaction.

6. **Representation:**

- Sequence Diagram: Emphasizes the time order of messages exchanged between objects. Each
object is depicted along a timeline, with messages passing between them in a sequential manner.

- Collaboration Diagram: Emphasizes the structural organization of objects and the links between
them. Objects are arranged spatially, and the links among them are depicted to show how they
interact with each other.

Overall, these modeling techniques provide a clear visualization of the flow of control within an
interaction, allowing for a detailed understanding of how objects communicate and collaborate to
achieve specific objectives within a system.

INTERACTION DIAGRAMS: Interaction diagrams, such as sequence diagrams and collaboration

diagrams, are vital for capturing the dynamic behavior of a system and facilitating both system
modeling and implementation. Here's a breakdown of their key features:
**Sequence Diagrams:**

- **Purpose:** Describe the flow of messages, events, and actions between objects.

- **Representation:** Emphasizes the time ordering of messages, making it easier to understand the
sequence of interactions.

- **Contents:**

- Objects: Represent entities or actors participating in the interaction.

- Links: Represent relationships or connections between objects.

- Messages: Depict communication between participating objects.

- **Usage:** Useful during analysis and design phases to document and comprehend the logical flow
of the system.

- **Key Parts:**

- Participants: Objects or entities acting within the diagram.

- Messages: Communications between participant objects.

- Axes: Horizontal axis denotes the participating objects, while the vertical axis indicates time (from
top to bottom).

**Collaboration Diagrams:**

- **Purpose:** Emphasize the structural organization of participating objects in an interaction.

- **Representation:** Method call sequences are indicated using numbering techniques to show the
order of method calls.

- **Distinct Features:**

- Path Stereotypes: Indicate the relationship between objects (e.g., <<local>> for denoting local
associations).

- Sequence Numbers: Prefix messages with numbers to indicate the order of message exchanges
(starting from 1).

- **Usage:** Helps understand how objects are structured and interact within the system.

Both sequence and collaboration diagrams serve as effective tools for visualizing and understanding
the dynamic behavior of a system, offering different perspectives on the same interactions.

COMMON MODELING TECHNIQUES FOR INTERACTION DIAGRAMS:

These modeling techniques provide a structured approach to representing flow control in interaction
diagrams:

**Modeling Flow Control by Time Ordering:**

1. **Set Context:** Define the scope and context of the interaction, such as the system, subsystem,
operation, or class involved.
2. **Identify Objects:** Determine the objects participating in the interaction and arrange them on
the sequence diagram from left to right, prioritizing their importance.

3. **Set Lifelines:** Establish the lifeline for each object, indicating its existence throughout the
interaction. For objects created and destroyed during the interaction, explicitly mark their birth and
death with stereotyped messages.

4. **Sequence Messages:** Begin with the initiating message and lay out subsequent messages
from top to bottom between the lifelines. Specify message properties, such as parameters, as
needed.

5. **Adorn Lifelines:** If necessary, adorn each object's lifeline with its focus of control to visualize
nesting or points of actual computation.

6. **Attach Timing Marks:** Adorn messages with timing marks and attach suitable time constraints
to specify time or space constraints.

7. **Formal Specification:** If required, attach pre- and post-conditions to each message to formally
specify the flow of control.

**Modeling Flow Control by Organization:**

1. **Set Context:** Define the context of the interaction, similar to the time ordering approach.

2. **Identify Objects:** Identify participating objects and lay them out as vertices in a graph on the
collaboration diagram, with more important objects in the center.

3. **Set Initial Properties:** Define initial properties of objects and update them as needed during
the interaction. Use duplicate objects and messages stereotyped as "become" or "copy" to represent
changes.

4. **Specify Links:** Establish association links first, followed by other links adorned with suitable
path stereotypes to specify relationships.

5. **Sequence Messages:** Attach subsequent messages to the appropriate link, specifying

sequence numbers. Use Dewey decimal numbering to show nesting.

6. **Adorn Messages:** Adorn messages with timing marks and attach time or space constraints if
needed.

7. **Formal Specification:** Optionally, attach pre- and post-conditions to each message for formal
specification.

**Forward and Reverse Engineering:**

- Forward engineering involves generating code from the model, which is facilitated by tools that can
interpret the diagram's context and generate corresponding code.

- Reverse engineering involves creating a model from existing code, which can be achieved by
analyzing code segments and deriving interaction diagrams based on observed behavior during
execution.

USE CASES:

Use cases are a fundamental aspect of requirements engineering in software development. Here's an
overview of key concepts related to use cases:
**Use Case Definition:**

- A use case describes a set of interactions between the system (or subsystem) and its actors to
achieve a specific goal or outcome.

- It outlines a sequence of actions performed by the system in response to inputs from the actors.

- Use cases are valuable for capturing system functionality from the user's perspective.

**Names:**

- Each use case must have a unique name to distinguish it from others. Names can be simple or path
names, depending on the context.

- Use case names should be descriptive and meaningful, reflecting the functionality they represent.

**Actors:**

- Actors represent roles played by users, hardware devices, or other systems interacting with the
system under consideration.

- Actors are depicted as stick figures in use case diagrams and can be generalized or specialized to
represent different kinds of users or entities.

**Flow of Events:**

- Use cases consist of a main flow of events and optional exceptional flows that describe alternate
paths or error conditions.

- The main flow outlines the typical sequence of interactions between the actor and the system to
accomplish the use case's goal.

- Exceptional flows handle error conditions or exceptional situations that may arise during use case
execution.

**Scenarios:**

- Scenarios are specific instances or examples of how a use case can be executed.

- They provide concrete illustrations of use case behavior and help stakeholders understand system
functionality in real-world contexts.

**Collaborations:**

- Collaborations involve interactions among multiple objects or components to achieve a use case's
objectives.

- Use cases capture the intended behavior of the system without specifying how that behavior is
implemented, promoting separation of concerns between analysis and implementation.

**Organizing Use Cases:**

- Use cases can be organized hierarchically using generalization relationships to factor common
behavior or variants.

- Include relationships allow one use case to explicitly incorporate the behavior of another at specific
locations.
- Extend relationships enable one use case to implicitly incorporate the behavior of another at
specified locations indirectly.

Overall, use cases provide a structured approach to capturing system requirements, facilitating
communication between stakeholders and guiding system design and development.

COMMON MODELING TECHNIQUES FOR USECASES:

Modeling the behavior of an element is a crucial aspect of system design and analysis. Here's a step-
by-step approach to effectively model the behavior of an element:

1. **Identify Actors:**

- Start by identifying the actors that interact with the element. Actors can be users, systems, or
external entities that interact with the element to achieve certain goals.

- Consider both primary actors who directly interact with the element and secondary actors who
may indirectly influence its behavior.

2. **Organize Actors:**

- Organize the identified actors by identifying general roles and more specialized roles they may
play in relation to the element.

- General roles represent broader categories of actors, while specialized roles represent specific
types or instances of actors within those categories.

3. **Define Interactions:**

- For each actor, analyze the primary ways in which they interact with the element. This involves
identifying the actions or tasks performed by the actor to accomplish specific goals related to the
element.

- Consider interactions that may trigger changes in the state of the element or its environment, as
well as interactions that involve responses to events or stimuli.

4. **Consider Exceptional Interactions:**

- In addition to primary interactions, consider exceptional interactions where actors deviate from
the typical behavior or encounter unusual scenarios.

- Exceptional interactions may involve error handling, recovery processes, or alternative pathways
to achieve the same goal.

5. **Model Use Cases:**

- Organize the identified behaviors as use cases, which represent specific scenarios or sequences of
actions performed by actors to achieve desired outcomes.

- Apply include and extend relationships between use cases to factor common behavior and
distinguish exceptional behavior.

- Use include relationships to incorporate common steps or functionalities shared across multiple
use cases.

- Use extend relationships to define optional or alternative steps that can be added to existing use
cases based on specific conditions or circumstances.
By following this approach, you can systematically model the behavior of an element, ensuring
comprehensive coverage of interactions with various actors and scenarios while effectively managing
common and exceptional behaviors through structured use case modeling.

USE CASE DIAGRAMS:

Use Case Diagrams

• A use case diagram is a diagram that shows a set of use cases and actors and their relationships.
Common Properties

• A use case diagram is just a special kind of diagram and shares the same common properties as all
other diagrams.

• a name and graphical contents that are a projection into a model.

Contents Use case diagrams commonly contain

• Use cases

• Actors

• Dependency, generalization, and association relationships

Like all other diagrams, use case diagrams may contain notes and constraints.

COMMON MODELING TECHNIQUES OF USE CASE DIAGRAM:

Use case diagrams are powerful tools for visualizing the interactions between actors and the system
they interact with. Here are some common modeling techniques for creating use case diagrams:

1. **Modeling the Context of a System:**

- Identify the actors surrounding the system, considering groups requiring assistance from the
system, those executing its functions, and those interacting with external hardware or software.

- Organize actors with similar roles into a hierarchy using generalization/specialization.

- Provide stereotypes for actors to aid in understanding.

- Populate the use case diagram with actors and illustrate the paths of communication between
each actor and the system's use cases.

2. **Modeling the Requirements of a System:**

- Establish the system's context by identifying surrounding actors.

- Consider the behavior each actor expects from the system and name these behaviors as use
cases.

- Factor common behavior into new use cases and variant behavior into extending use cases.

- Model these relationships in a use case diagram and add notes specifying nonfunctional
requirements.

3. **Forward and Reverse Engineering:**

 - Forward engineering involves transforming a model into code by mapping it to an implementation
language.

- Identify the flow of events and exceptional flows for each use case, and generate test scripts
accordingly.

- Use tools to run these tests during system releases.

- Reverse engineering entails creating a use case diagram from an existing system:

- Identify actors and their interactions with the system, changes in the system's state, and
responses to events.

- Trace the flow of events in the executable system and cluster related flows into corresponding
use cases using extend and include relationships.

- Render actors and use cases in a use case diagram and establish their relationships.

These techniques provide a structured approach to developing comprehensive use case diagrams,
ensuring alignment with system requirements and facilitating both forward and reverse engineering
processes.

Case study vacation tracking system:

Sure, I can provide an example of a case study for a "Vacation Tracking System."

### Case Study: Vacation Tracking System

#### Inception Phase:

- **Problem Statement:** A company with a large number of employees needs to efficiently manage
and track employee vacations.

- **Stakeholders:** HR department, employees, managers.

- **Goals:** Implement a centralized system for requesting, approving, and tracking employee
vacations to streamline the process and ensure accurate records.

#### Elaboration Phase:

- **Functional Requirements:**

1. **User Authentication:** Employees should be able to log in securely to access the system.

2. **Vacation Request:** Employees can submit vacation requests specifying dates and duration.

3. **Manager Approval:** Managers should receive notifications of vacation requests and be able
to approve or deny them.

4. **Vacation Calendar:** The system should maintain a calendar displaying approved vacations to
avoid scheduling conflicts.

5. **Accrual Tracking:** Track vacation days accrued and used by each employee.

- **Non-Functional Requirements:**

1. **Security:** Ensure data security and access control to protect employee information.
 2. **Scalability:** The system should be scalable to accommodate a growing number of users and
data.

3. **Usability:** User interface should be intuitive and user-friendly for easy adoption.

4. **Reliability:** Ensure the system is available and performs reliably to prevent disruptions.

- **Use Cases:**

- **Employee:**

- Login

- Submit Vacation Request

- View Vacation Balance

- **Manager:**

- Approve Vacation Request

- View Vacation Calendar

- **Domain Model:** Identify key concepts such as Employee, Manager, VacationRequest, etc., and
their relationships.

#### Construction Phase:

- **Architecture:** Design a web-based system using a client-server architecture.

- **Database Design:** Create a relational database schema to store employee data, vacation
requests, and approvals.

- **User Interface:** Develop user interfaces for employees to submit requests and for managers to
approve them.

- **Backend Development:** Implement the business logic to handle vacation requests,

notifications, and calendar updates.

- **Testing:** Perform unit testing, integration testing, and user acceptance testing to ensure the
system meets requirements.

#### Transition Phase:

- **Deployment:** Deploy the vacation tracking system to production servers.

- **Training:** Provide training sessions for employees and managers on how to use the system
effectively.

- **Monitoring and Maintenance:** Monitor system performance, address any issues, and
implement updates or enhancements as needed.

#### Conclusion:

The Vacation Tracking System provides an efficient and organized way for employees to request
vacations and for managers to approve them, leading to better management of employee time off
and improved workflow within the organization.
Additional information:

A vacation tracking system is a software application or tool designed to streamline and automate the
process of managing employee vacation requests, approvals, and tracking accrued and used vacation
days.

Here are some key features typically found in a vacation tracking system:

1. **Employee Self-Service:** Employees can log in to the system to view their vacation balances,
submit vacation requests, and check the status of their requests.

2. **Manager Approval Workflow:** Managers are notified when employees submit vacation
requests. They can review and approve or deny requests directly within the system.

3. **Vacation Calendar:** The system maintains a centralized calendar showing approved vacations
for all employees, making it easy to identify potential scheduling conflicts.

4. **Accrual Tracking:** The system tracks the number of vacation days accrued and used by each
employee, ensuring compliance with company policies and regulations.

5. **Reporting and Analytics:** Generate reports on vacation usage, trends, and patterns to help HR
managers make informed decisions and plan resources effectively.

6. **Notifications:** Automatic email notifications are sent to employees and managers when
vacation requests are submitted, approved, or denied.

7. **Integration:** Integration with other HR systems such as payroll and employee management
software for seamless data exchange and updates.

Overall, a vacation tracking system helps organizations improve efficiency, transparency, and
compliance in managing employee time off, leading to better employee satisfaction and workforce
management.