OCUP 2 Foundation key terms

A structural classifier describing a set of objects that share attributes, operations, relationships, and semantics. It is the central building block for object-oriented structural models and may be specialized, generalized, or made abstract.

A typed property declared on a classifier that describes a value held by each instance. It can carry multiplicity, visibility, a default value, and constraints that restrict the values it may take.

A behavioral feature declared on a classifier that specifies a name, parameters, return type, and visibility. It describes what instances can be asked to do, while the method supplies the implementation.

A structural relationship linking classifiers whose instances can be connected at runtime. It may carry a name, role names, multiplicities at each end, navigability, and an association class for extra data.

A constraint on how many instances may participate at one end of an association or fill a property. Written as a range such as 1, 0..1, or 1..*, it bounds the cardinality of the relationship.

A taxonomic relationship in which a more specific classifier inherits the features of a more general one. The child adds or overrides features, supporting substitutability and reuse in structural and behavioral models.

A classifier that cannot be instantiated directly and typically declares incomplete behavior for subclasses to complete. Its name is shown in italics, and it usually owns abstract operations with no implementation.

A named set of public operation signatures that a classifier promises to provide. It has no implementation of its own and is connected to providers through realization, enabling substitution of implementations.

A relationship stating that a classifier commits to the contract declared by an interface. The realizing class or component must supply operations matching every signature the interface exposes.

A relationship in which a change to the supplier element may affect the client element. It is drawn as a dashed arrow and is common between packages, classes, and components in structural models.

A class attached to an association that holds attributes and operations belonging to the link itself rather than to either endpoint. It is useful when a relationship carries data such as a hire date.

A whole-part association with a hollow diamond at the whole end, indicating that parts may be shared and can outlive the whole. It is weaker than composition and imposes no lifetime dependency on the parts.

A strong whole-part association drawn with a filled diamond, in which parts belong to exactly one whole and are destroyed with it. The part's lifetime is subordinate to the composite's lifetime.

A namespace used to group model elements and organize a large model into manageable units. It can contain classes, other packages, and diagrams, and dependencies between packages reveal coupling.

A modular, replaceable part of a system that provides and requires interfaces through ports. It encapsulates its internals and is depicted as a rectangle with a component icon in component diagrams.

A distinct interaction point on a classifier or component through which it provides or requires interfaces. Ports isolate a component's external contract from its internal structure and implementation details.

A structural diagram showing components, their provided and required interfaces, ports, and wiring. It expresses the architecture of replaceable parts and how they collaborate at a coarse granularity.

A structural diagram that shows classes, interfaces, attributes, operations, and the relationships among them. It is the primary view of the static type structure of an object-oriented system.

A structural diagram capturing a snapshot of instances and the links between them at a point in time. It illustrates concrete example configurations that a class diagram permits.

A model element denoting a specific instance whose slots hold concrete values. It appears in object diagrams and may carry a name, a type, and value specifications for its features.

A structural diagram showing the internal parts of a classifier, their ports, connectors, and collaborations. It reveals how a class or component realizes its behavior through cooperating internal roles.

A structural diagram depicting nodes, artifacts, and communication paths in a physical or execution environment. It maps software artifacts onto hardware or runtime nodes and shows how they are deployed.

A physical or runtime computational resource, such as a server or device, that hosts artifacts in a deployment model. Nodes may be nested and connected by communication paths.

A concrete piece of information produced or used by development and deployment, such as a source file, library, or executable. Artifacts are deployed onto nodes and may realize components.

A behavioral diagram showing actors, use cases, and their associations, expressing system functionality from an external viewpoint. It also captures include, extend, and generalization relationships between use cases.

A role played by a person, external system, or device that interacts with the subject through use cases. Actors are drawn as stick figures and lie outside the system boundary.

A named unit of observable behavior that yields a result of value to an actor. It describes a goal-level interaction with the system rather than internal steps or implementation detail.

A use case relationship in which a base use case always incorporates the behavior of another use case. It factors out mandatory shared steps and is drawn as a dashed arrow labeled include.

A use case relationship in which an extending use case adds optional behavior to a base use case under a condition. The arrow points from the extension toward the base case.

A behavioral diagram modeling control and data flow through actions, decisions, merges, forks, and joins. It is used for workflows and algorithms and supports swimlanes and concurrency.

A single executable step within an activity that transforms inputs into outputs. Actions are connected by control flows and may have pins for their input and output tokens.

Notation for splitting one flow into concurrent flows (fork) and merging concurrent flows back into one (join). Both use a heavy bar; a join waits for all incoming flows to complete.

A diamond node that routes a flow along one guarded branch (decision) or reunites alternative branches (merge). Guards on outgoing edges determine which path is taken at a decision.

A partition in an activity diagram that groups actions by the responsible actor or organizational unit. It clarifies handoffs and accountability within a process flow.

A behavioral diagram describing the states of one object and the events that trigger transitions between them. It models event-driven behavior, including guards, effects, and composite states.

A condition or situation during an object's life in which it satisfies some invariant, performs an activity, or waits for an event. States may be simple, composite, or have entry and exit behaviors.

A directed relationship between states that fires when its trigger event occurs and its guard evaluates true. It may carry an effect action that executes when the transition is taken.

A boolean condition attached to a transition or interaction that must evaluate true for the path to be taken. Written in square brackets, it constrains when behavior may occur.

An interaction diagram showing lifelines and the time-ordered messages exchanged between them. It emphasizes the order of calls and may include combined fragments for alternatives and loops.

The vertical line in an interaction diagram representing one participant over time. It may carry an execution specification bar indicating when that participant is active.

A communication between lifelines in an interaction, shown as an arrow with a name and ordering. It may be synchronous, asynchronous, or a reply, and can carry arguments and a sequence number.

A frame in an interaction diagram that groups messages under an operator such as alt, opt, loop, or par. It expresses conditional, optional, iterative, or concurrent message ordering.

An interaction diagram that emphasizes links between objects rather than time order, with numbered messages along those links. It shows the same interactions as a sequence diagram in a different layout.

A partition is the general UML term for a grouping region inside a diagram, while a swimlane is a partition used specifically to assign responsibility in activity or interaction diagrams. Swimlanes are a kind of partition.

An abstraction of a system built for a purpose, capturing selected aspects while omitting irrelevant detail. A model enables reasoning, communication, and prediction before committing to implementation.

A projection of a model that emphasizes one concern, such as structure, behavior, or deployment, for a particular stakeholder. Multiple views together describe the whole system without duplicating it.

A graphical presentation of a set of model elements, usually chosen to illustrate one aspect of a model. Diagrams are views onto the underlying model, not the model itself.

The ability to follow relationships from requirements through design elements to implementation and tests. Modeling supports it by making links explicit, which helps assess the impact of changes.

The degree of detail at which a model represents a system, ranging from conceptual sketches to implementation-level specifications. Choosing the right level keeps models useful and avoids unnecessary complexity.