OCUP 2 Foundation flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Use case diagram purpose

Shows actors (external users or systems) and the use cases (system capabilities) they interact with, plus include/extend relationships, to capture functional scope from an external viewpoint.

Activity diagram notation

Rounded rectangles are actions; diamonds are decisions/merges; bars are forks/joins; solid circle is initial; bullseye is final; arrows show control or object flow.

State machine transition syntax

A transition label is written trigger [guard] / effect. The trigger is an event, the guard a boolean condition, and the effect an action executed when the transition fires.

Sequence diagram lifeline

A lifeline is drawn as a dashed vertical line under a name:Class or actor; the activation bar on it represents an execution occurrence while a message is being processed.

Synchronous vs asynchronous message

In sequence diagrams, a solid arrow with a filled arrowhead is a synchronous call (waits for reply); an open arrowhead is an asynchronous message (no wait). A dashed arrow is a reply.

Communication diagram numbering

Messages on links are numbered to express ordering (1, 1.1, 2, 2.1) because the diagram has no time axis; nested numbers show call nesting on the same link.

Timing diagram notation

Time runs left to right; horizontal lines show state or value changes of lifelines; a slanted arrow is a message; {d..d} is a duration constraint.

Interaction overview diagram

A hybrid diagram whose frames are interaction uses or inline interactions, connected by activity control nodes such as decision, fork, join, initial, and final.

Behavioral diagram list

UML 2.5 behavioral diagrams are use case, activity, state machine, and the interaction diagrams: sequence, communication, timing, and interaction overview.

Class compartment layout

A class rectangle has three compartments: class name on top, attributes in the middle, operations at the bottom; visibility markers are + public, - private, # protected, ~ package.

Aggregation vs composition

Aggregation uses a hollow diamond at the whole and is a weak whole-part relationship; composition uses a filled diamond and implies strong ownership with coincident lifetimes.

Realization notation

Realization is a dashed line with a hollow triangle at the target; it links a class to an interface it implements, or a use case to a collaboration that realizes it.

Component provided/required interface

A provided interface is drawn as a ball (lollipop) on the component boundary; a required interface is a socket (cup) that receives another component's ball.

Deployment diagram nodes

A node is a 3-D box representing hardware or execution environment; artifacts (rectangles with «artifact») are deployed on nodes; communication paths are solid lines between nodes.

Package import vs merge

«import» is a dashed arrow that makes public contents of the target package visible; «merge» combines package contents into a single namespace with merge rules.

Object diagram instance notation

An instance specification is written name:Class with the whole string underlined; links connect instances and are drawn as solid lines, mirroring associations in a class diagram.

Composite structure ports

A port is a small square on the boundary of a classifier; it defines a distinct interaction point; parts inside are roles typed by classifiers and connected by connectors.

Profile and stereotype

A profile packages stereotypes; a stereotype extends a metaclass to add domain-specific properties; it is applied to elements as «stereotypeName» above the name.

Classifier definition

A classifier is a model element with features that can be generalized; Class, Interface, DataType, Component, Node, and Actor are classifiers in UML.

Multiplicity syntax

Multiplicity is lower..upper, e.g., 0..1, 1..*, *; the default is 1; it constrains how many instances may participate at an association end or attribute.

Operation parameter direction

Parameters have direction in, out, inout, or return; syntax is direction name: Type [multiplicity] = default; return parameters are shown after a colon on the operation.

Association end properties

An association end carries navigability, multiplicity, aggregation kind (none, shared, composite), and a role name; these properties define how instances are linked.

Constraint and OCL

A constraint is a boolean expression in braces {…}; OCL (Object Constraint Language) is the standard language; pre/postconditions are written {pre: …} and {post: …}.

Property metaclass

Property is the UML metaclass for attributes and association ends; it has type, multiplicity, visibility, and default value, and may be static or derived.

Generalization relationship

Generalization is a taxonomic relationship shown by a solid line with a hollow triangle at the parent; the child inherits features and may override operations; multiple inheritance is allowed.

Comment (note) notation

A comment is a rectangle with a folded corner containing text; it may be attached to any element by a dashed line and has no semantic effect on the model.

Abstraction benefit of models

Models raise the level of abstraction so stakeholders can reason about structure and behavior before code exists; models are cheaper to change than source code.

Models as communication medium

Models give analysts, architects, developers, and testers a shared, precise notation, reducing ambiguity in requirements and design discussions across disciplines.

Model-based analysis

Models enable consistency checks, traceability from requirements to design, and early detection of design defects before implementation costs are incurred.

Executable UML

Executable UML (fUML and action languages) lets models be simulated and validated for behavior before code is written, supporting early verification.

Model-driven engineering

MDE/MDA uses models as primary artifacts and applies model-to-model and model-to-text transformations, improving repeatability and reducing manual coding errors.

When modeling is not justified

Small, well-understood problems may not need models; the cost/benefit of modeling depends on complexity, team size, and lifecycle, so modeling is not universally required.