4.2. Key Components

● Actors: External users or systems interacting with the application

In software modeling, 'Actors' refer to individuals or external systems that engage with the application being developed. They represent the roles of users or other systems that initiate or interact with specific functionalities of the software. It's crucial to identify who these actors are early in the design process, as they help define the system's requirements and functionalities.

Think of actors in a software system like roles in a play. Each actor has their own unique part and interacts with the environment (the play) in specific ways. For instance, in an e-commerce system, a customer (an actor) interacts with the shopping cart (the system) to add items for purchase, just as an actor might deliver their lines in response to the script.

● Use Cases: Functionalities the system provides

Use Cases describe specific functionalities or features that the software offers from the end-users' perspective. Each use case outlines a sequence of interactions between the actor and the system, detailing how the actor accomplishes a goal using the software. This allows developers to understand user needs and prioritize functionality during development.

Consider a use case as a recipe in cooking. Just like a recipe outlines the steps needed to prepare a dish, a use case details how a user will interact with the system to achieve a particular outcome, such as placing an order. Each component of the recipe corresponds to actions the user will take.

● System Boundary: Encapsulates use cases within the system

The System Boundary is a visual delimiter that defines what functionalities are included within the software system and what lies outside it. It helps to clarify the scope of the project by distinguishing between the system's internal processes and external actors or systems that interact with it. This is vital for managing expectations and ensuring comprehensive understanding among stakeholders.

Imagine the system boundary as the walls of a house. While the house contains various rooms (functionalities), anything outside the walls represents external influences (like other houses or the street) that can affect what happens inside. Knowing where the house ends helps you understand what can be managed within versus what needs to be dealt with externally.

● Relationships: ○ Include: A use case always includes another (common logic) ○ Extend: A use case optionally extends another (conditional logic) ○ Generalization: Inheritance between actors or use cases

In UML, Relationships define how use cases are connected to one another. The 'Include' relationship indicates that one use case is always invoked as part of another, ensuring that crucial steps are consistently followed. The 'Extend' relationship allows for optional use cases that add extra functionality based on certain conditions. Lastly, 'Generalization' shows how one use case can inherit characteristics from another, allowing for a hierarchy.

Think of relationships between use cases like a family tree. The 'Include' relationship is like a child always following their parent to school; they can't go without that routine. The 'Extend' relationship is akin to a child choosing to join an after-school club only on certain days; they are not required to attend every time. Generalization is similar to how a child might adopt traits from their parents while also developing their own unique characteristics.

--