Interaction Modeling, Advanced Interaction Modeling, and System Conception

Vocabulary flashcards covering the core concepts of UML Interaction Modeling (Use Cases, Scenarios, Sequence Diagrams, and Activity Diagrams), Advanced Interaction Modeling (Include, Extend, Generalization, Procedural Models, Signals, Swimlanes, Object Flows), and System Conception.

Interaction Model

A model that describes how objects in a system interact with one another and outside actors, typically beginning with use cases and elaborated through sequence and activity diagrams.

Actor

A direct external user of a system—an object or set of objects that communicates directly with the system but is not part of the system itself.

Actor Symbol

A stick-man icon placed outside the system rectangle, with the actor's name placed below or adjacent to the icon, denoting a direct external user of the system.

Use Case

A coherent piece of functionality that a system provides by interacting with actors, representing a complete transaction of value from the user's perspective.

Use Case Symbol

An ellipse containing the use case name, used in UML diagrams to represent a coherent slice of functionality provided by a system.

System Boundary

The structural boundary in a use case model that encloses the system's internal use cases within a rectangle and separates them from outside actors.

Scenario

A sequence of events that occurs during one particular execution of a system, such as for a specific use case, documented as a list of text statements.

Sequence Diagram

An interaction diagram that shows the participants in an interaction along vertical lifelines and illustrates the explicit sequence of messages exchanged among them over time.

Lifeline

A vertical line in a sequence diagram that represents the lifetime and existence of an actor or system component during an interaction.

Message (Sequence Diagram)

A communication transmitting information from one object to another, displayed as a horizontal arrow from the sender's lifeline to the receiver's lifeline.

Activity Diagram

A diagram that shows the flow of control and sequence of steps that make up a complex process, focusing on operations, algorithms, or workflows rather than on objects.

Branch (Activity Diagram)

A decision point, represented by a diamond or multiple outgoing arrows labeled with guard conditions in square brackets, where only one successor path executes based on condition satisfaction.

Synchronization Bar

A heavy horizontal or vertical bar in an activity diagram used to fork execution into multiple concurrent threads or merge multiple concurrent activities into a single thread.

Activity Token

A conceptual marker placed on an activity diagram symbol to represent the active progression of control during execution.

Initiation Point (Activity Diagram)

A solid circle with an outgoing arrow that indicates the starting point where control enters upon activating an activity diagram.

Termination Point (Activity Diagram)

A bull's-eye symbol (a solid circle inside a ring) with only incoming arrows that marks the end of execution for an activity diagram.

Include Relationship

A relationship where a base use case incorporates the behavior sequence of another use case like a subroutine, indicated by a dashed arrow annotated with <> pointing toward the included use case.

Extend Relationship

A relationship that modularly adds incremental or optional behavior to a base use case, indicated by a dashed arrow annotated with <> pointing from the extension use case to the base use case.

Use Case Generalization

A relationship where child use cases inherit and specialize the common behavior sequence of a parent use case, indicated by a solid line with a hollow triangular arrowhead pointing to the parent.

Passive Object

An object that lacks its own thread of control and remains inactive until called by an operation, returning to an inactive state once execution completes and control returns.

Active Object

An object that has its own thread of control, remains continuously activated, and can initiate operations or respond to messages without waiting for a caller.

Activation (Focus of Control)

A thin vertical rectangle superimposed on a lifeline in a sequence diagram that represents the time period during which an object is executing a method.

Transient Object

An object created and destroyed during the execution timeline of a sequence diagram, indicated by its box appearing at the head of a creation call arrow and ending with a large 'X' at destruction.

Signals in Activity Diagrams

Constructs for asynchronous communication in activity diagrams, where sending a signal is represented by a convex pentagon and receiving a signal is represented by a concave pentagon.

Swimlanes

Parallel partitions in an activity diagram that delineate organizational or departmental responsibility for carrying out specific activities.

Object Flow

A notation in an activity diagram showing an object and its state (written in square brackets) as an input or output of activities, thereby unifying control flow and data flow.

System Conception

The earliest phase of development that deals with the genesis of an application, deferring design details to understand user needs, financial justification, feasibility, and system scope.

Requirements Statement

A description of what a system must do and how it behaves from the user's point of view, treating the system as a black box without specifying internal mechanisms.

Design Decisions

Engineering choices—such as general approaches, algorithms, data structures, architectures, and optimizations—that provide the behavior specified by the requirements.

Requirements vs. Design vs. Implementation

The distinction among defining what is needed from an external user's perspective (requirements), formulating the engineering solution and architecture (design), and realizing the solution in physical hardware and code (implementation).

Feasible Time

The timeframe within which a system can realistically be developed within the constraints of available budget, personnel, and technological resources.

Required Time

The timeframe or target date by which a software system must be completed and deployed to fulfill business goals and market demands.