Object-Oriented Analysis and Design (OOAD) with UML

Comprehensive practice flashcards defining core Object-Oriented Analysis and Design (OOAD) and Unified Modeling Language (UML) terminology, diagrams, views, principles, and team roles.

Unified Modeling Language (UML)

A standard visual modeling language used for specifying, visualizing, constructing, and documenting the artifacts of software-intensive systems, business models, and non-software systems.

Artifact

A physical piece of information produced by the software development process, which includes requirements, architecture, design specifications, source code, project plans, test suites, prototypes, and user manuals.

Things (UML)

The primary structural, behavioral, grouping, and annotational abstractions that serve as first-class citizens in a UML model.

Relationships (UML)

The semantic connections that tie UML things together, including dependency, association, generalization, and realization.

UML Diagram Views

The architectural perspectives used to model a system, comprising the User View, Structure View, Behavioral View, Implementation View, and Environmental View.

User View

The system perspective that defines external functionalities and facilities made available by the system to its users, represented using use case diagrams.

Structure View

The system perspective that defines the static composition of objects and classes along with their relationships, captured using class and object diagrams.

Behavioral View

The system perspective that captures dynamic, time-dependent interactions between objects to realize system operations, represented by sequence, collaboration, state-chart, and activity diagrams.

Implementation View

The system perspective that captures the packaged structural code components of the system and their dependencies, modeled through component diagrams.

Environmental View

The system perspective that models the physical layout, hardware nodes, and execution deployment of software components across an enterprise, represented by deployment diagrams.

Use Case

A sequence of actions and scenarios that describes an interaction between an actor and the system, yielding measurable value to the actor from the user's perspective.

Actor

A role played by a person, organization, machine, or external system that resides outside the system boundary and directly interacts with the system.

System Boundary Box

A rectangular boundary drawn in a use case diagram indicating the scope of the system; elements inside represent internal functionality, whereas elements outside are external.

Essential Scenario

A use case scenario that focuses purely on core user intent and system response while deliberately excluding specific user interface technology or interaction mechanics.

Elaborate Scenario

A detailed use case scenario that explicitly incorporates interface mechanisms and operational specifics, such as mouse or keyboard navigation steps.

Class

An abstract blueprint, template, or description defining a category of objects that share common attributes, operations, methods, relationships, and semantics.

Object

A discrete software bundle of variables and related methods representing an entity with an identity, a state, and defined behavior.

Attribute

A named data property of a class describing the type and range of values that instances can hold, collectively defining an object's state.

Operation

The implementation of a service, command, or query that can be requested from any instance of a class to execute a specific behavior.

CRC Card Layout

A three-part index card template used in object modeling that organizes the Class Name at the top, Responsibilities on the left, and Collaborators on the right.

Responsibilities (CRC)

The knowledge and behavioral duties allocated to a class, specifying what the class knows (attributes) and what it does (operations).

Collaborator (CRC)

Another class that a given class must interact with or request services from in order to satisfy its assigned responsibilities.

Multiplicity

A numerical indicator placed at the ends of an association line (such as $1$, $0..1$, or $1..\text{*}$) that specifies how many instances of one class can link to one instance of the target class.

Association Class

A class attached to an association line via a dashed line that holds properties, attributes, or methods belonging to the relationship itself rather than to either related class.

Ternary Association

An association connecting three classes simultaneously, represented graphically in UML by a hollow diamond.

Recursive Association

An association where a class maintains a relationship with itself, also referred to as a reflexive association.

Interaction Diagram

A graphical representation depicting the dynamic message-passing behavior and collaboration among a community of objects fulfilling a specific scenario.

Sequence Diagram

An interaction diagram that illustrates object interactions chronologically, emphasizing the time ordering of messages flowing from top to bottom.

Lifeline

A vertical dashed line extending downward from an object box in a sequence diagram representing the existence and duration of that object over time.

Focus of Control

A tall, thin rectangle positioned along an object's lifeline in a sequence diagram that indicates the exact period an object directs messages or executes an action.

Guard

A boolean condition enclosed within square brackets ($[ ]$) in interaction and activity diagrams that must evaluate to true for an operation or transition to execute.

Controller

A dedicated class that coordinates application workflow, handles incoming requests from the GUI, and manages core business logic operations.

Collaboration Diagram

A spatially oriented interaction diagram that emphasizes the structural organization and communication links between objects, using numbered labels to indicate message order.

State Transition Diagram

A dynamic model describing the sequence of states an individual object passes through over its lifetime in response to external events, conditions, and actions.

Activity Diagram

A workflow diagram representing step-by-step procedural flows where states primarily represent actions and transitions are triggered by the completion of internal activities.

Fork (Activity Diagram)

A solid horizontal or vertical synchronization bar used to split a single incoming flow into multiple parallel, concurrent activity branches.

Join (Activity Diagram)

A solid horizontal or vertical synchronization bar used to synchronize and merge multiple concurrent activities back into a single outgoing control flow.

Branch (Activity Diagram)

A diamond symbol representing a decision point where an incoming flow is directed along alternative paths according to evaluated guard expressions.

Component Diagram

A structural diagram showing the physical organization and dependencies among software modules, libraries, tables, executables, and documents.

Deployment Diagram

A diagram that visualizes the distribution of software components and artifacts across physical computational nodes and hardware configurations.

Node (Deployment)

A computational hardware or execution environment element depicted as a three-dimensional box upon which software artifacts reside and run.

Encapsulation

The object-oriented principle of packaging attributes and methods within a single class while hiding internal data representations from outside unauthorized access.

Abstraction

The design process of isolating and emphasizing essential properties of an entity while suppressing implementation and operational details that are irrelevant to the current perspective.

Modularity

The structural property of a system that has been decomposed into a collection of cohesive, loosely coupled, and independently manageable modules.

Hierarchy (Inheritance)

A structural ordering where subclasses derive operations and information structures from a generalized superclass, facilitating code reuse and specialization.

Polymorphism

A type-theoretic principle allowing a single interface or operation identifier to execute different underlying implementations depending on the target object's class.

Algorithmic Decomposition

A top-down structured design technique where a software system is partitioned into major processing steps and functional procedural modules.

Object-Oriented Decomposition

A system partitioning strategy based on modeling problem-domain entities as autonomous interacting objects that encapsulate state and behavior.

Business Domain Experts (BDEs)

Team members who work directly with business operations daily (such as operational clerks) and provide direct domain knowledge to guide system requirements.

Object Design Analyst

A modeling team specialist with expertise in object-oriented methodologies responsible for shaping object architectures and continuing into implementation phases.

Facilitator

The analysis and design team leader who organizes modeling sessions, guides technical discussions, ensures active contribution, and maintains requirement alignment.

Scribe

A team member possessing strong listening and written skills assigned to record discussions and capture secondary details during modeling sessions.

Rational Unified Process (RUP)

An iterative software engineering framework divided into four phases that repeatedly executes analysis, design, implementation, and testing cycles.

Time Boxing

An iterative project management technique where development cycles are set to a fixed duration, requiring teams to adjust deliverables to fit the designated window.