OCUP 2 Foundation cheat sheet

Use case diagram: actors (stick figure, external to system) connect to use cases (ellipse) via associations; include/extend are dashed dependency arrows labeled «include» / «extend».

Activity diagram: rounded rectangle = action; diamond = decision/merge; bar = fork/join; solid circle = initial node; bullseye = activity final; flow arrows show control or object flow.

State machine diagram: rounded rectangle = state; solid circle = initial pseudostate; bullseye = final state; transition label syntax is trigger [guard] / effect.

Sequence diagram: lifeline (name:Class or actor) with dashed line; activation bar = execution occurrence; solid arrow = synchronous call; open arrow = asynchronous message; dashed arrow = reply.

Communication diagram: objects linked by lines; message arrows numbered to show ordering (e.g., 1, 1.1, 2); emphasizes structural links over time axis.

Interaction overview diagram: frames are interaction uses or inline interactions connected by control-flow nodes (decision, fork, join) - a hybrid of activity and sequence.

Timing diagram: horizontal axis is time; state/condition lines show value changes; a message is a slanted arrow crossing lifelines; duration constraint is {d..d}.

Behavioral diagrams in UML 2.5: use case, activity, state machine, and the four interaction diagrams (sequence, communication, timing, interaction overview).

Class diagram: rectangle with three compartments (name, attributes, operations); visibility markers + public, - private, # protected, ~ package.

Class relationships: association (solid line, optional navigability arrow), aggregation (hollow diamond at whole), composition (filled diamond at whole), generalization (hollow triangle at superclass), realization (dashed line + hollow triangle).

Component diagram: component is a rectangle with the «component» keyword or component icon; provided interface = ball (lollipop); required interface = socket (cup).

Deployment diagram: node is a 3-D box; artifact is a rectangle with «artifact» keyword; communication path is a solid line between nodes.

Package diagram: folder-shaped icon; «import» is a dashed arrow with keyword; «merge» combines package contents; nesting shown by containment.

Object diagram: instance specification written name:Class (underlined); link is a solid line between instances; used to show a snapshot of instances and their relationships.

Composite structure diagram: internal structure of a classifier; parts are roles typed by classes; ports are small squares on the boundary; connectors link parts and ports.

Profile diagram: «stereotype» extends a metaclass; «profile» packages stereotypes; applied via «apply» dependency; used for domain-specific UML extensions.

A classifier is a generalizable element with features; Class, Interface, DataType, Component, Node, and Actor are all classifiers.

Property is the metaclass for attributes and association ends; multiplicity is written as lower..upper (e.g., 0..1, 1..*, *), default 1.

Operation has parameters with direction in, out, inout, return; parameter syntax: direction name: Type [multiplicity] = default.

Association end properties include navigability, multiplicity, aggregation kind (none, shared, composite), and role name.

Constraint is a boolean expression in braces {…}; OCL is the standard constraint language; pre/postconditions attach to operations as {pre: …} {post: …}.

Stereotype extends a metaclass; notation is «stereotypeName» above the element name; a profile packages stereotypes for a domain.

Generalization is a taxonomic relationship; the child inherits features of the parent; multiple inheritance is permitted in UML.

Comment (note) is a rectangle with a folded corner; it may be attached to any element by a dashed line.

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

Models serve as a communication medium across business analysts, architects, developers, and testers, reducing ambiguity in requirements.

Models support analysis: consistency checks, traceability from requirements to design, and early detection of design defects.

Models enable simulation and executable UML (fUML, action languages) for validating behavior before implementation.

Models drive code generation and model-to-model transformation (MDA/MDE), improving repeatability and reducing manual coding errors.

Models capture architecture and design rationale, supporting maintenance and onboarding of new team members.

Models support testing: test cases can be derived from use cases, state machines, and interactions; coverage can be measured on models.

Modeling is not always justified: small, well-understood problems may not need models; cost/benefit depends on complexity, team size, and lifecycle.