Click on a letter to find a definition.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Abstract class:
a class that can have no instances; a superclass that acts only as a generalized template for its instantiated subclasses.

Abstract operation:
an operation that is not implemented in the class in which it appears (usually an abstract superclass), but that will be implemented in a subclass.

Abstraction:
a simplified representation that contains only those features that are relevant for a particular task; the act of separating out the general or reusable parts of an element of a system from its particular implementation.

Action:
a step in an activity, used to represent where work is taking place; an executable statement, commonly associated with a state or transition in a state machine.

Activation:
the execution of an operation, represented in interaction sequence diagrams as a long thin rectangle.

Activity:
an activity is a group of one or more actions that may execute as a result of a triggering event.

Activity diagram:
a diagram that shows activities and actions to describe workflows.

Activity edge:
a flow between elements in an activity.

Activity final node:
the final node in an activity that terminates the actions in that activity.

Activity partition:
a column or row in an activity diagram used to show an area of responsibility for the actions in it. Sometimes referred to as a swimlane.

Actor:
an actor is an external entity of any form that interacts with the system. Actors may be physical devices, humans or information systems.

Adornment:
an element attached to another model element, for example a stereotype icon or a constraint.

Aggregation:
a whole–part association between two or more objects or components, where one represents the whole and the others parts of that whole.

Algorithm:
a description of the internal logic of a process or decision in terms of a structure of smaller steps. The structure may consist of steps in sequence, selection between alternatives and iteration.

Analysis class stereotype:
one of three specialised kinds of class (boundary, control and entity classes (q.v.)) that feature in analysis class diagrams. These represent a separation of concerns that forms the basis of the architecture recommended for most models developed following UP guidelines (cf stereotype).

Antipattern:
documents unsuccessful attempts at providing solutions to certain recurring problems but includes reworked solutions that are effective.

Artefact:
a model element used in deployment diagrams representing a file or collection of files containing source code or an executable. (Artifact in US spelling.)

Association:
a logical connection between two instances. Associations are commonly found between classes although in some circumstances a class can have an association with itself. An association describes possible links between instances, and may correspond either to logical relationships in the application domain or to message paths in software.

Association class:
a class that is modelled in order to provide a location for attributes or operations that properly belong to an association between other classes.

Association instance:
another name for a link (q.v.).

Asynchronous message:
an asynchronous message does not cause the invoking operation to halt execution while it awaits the return of control.

Attribute:
an element of the data structure that, together with operations, defines a class. Describes some property of instances of the class.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Behavioural state machine:
see state machine.

Boundary class:
a stereotyped class that provides an interface to users or to other systems.

Business rule:
see enterprise rule.

A | B | C | D | E | F | G | H| I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Data:
raw facts, not yet identified as relevant to any particular purpose.

Decision:
a node in an activity diagram where a flow branches into multiple alternative flows.

Deep history pseudostate:
a deep history substate shows that a region in a composite state will resume at the last active substate in each of the nested submachines within that region, no matter how deeply nested they are.

Degree:
another word for multiplicity (q.v.).

Dependency:
a relationship between two model elements, such that a change in one element may require a change in the dependent element.

Deployment diagram:
A diagram that shows the run-time configuration of processing nodes (qv.) and the artefacts that are located on them.

Deployment specification:
an artefact deployed to a node in a deployment diagram in order to configure other artefacts deployed to the same node.

Design constraint:
a constraint that limits the design options that may be used. Common design constraints include cost and data storage requirements.

Destructor operation:
an operation that destroys an instance of a class.

Device:
a node representing a processor in a deployment diagram.

Domain model:
an analysis class model that is independent of any particular use cases or applications, and that typically contains only entity objects. A domain model may serve as a basis for the analysis and design of components that can be reused in more than one software system.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Encapsulation:
hiding the internal details of an element (typically a class or component) from the view of other elements, so that each can be maintained or modified without affecting the operation of other parts of the system.

Enterprise (or business) rule:
a statement that expresses business constraints on the multiplicity of an association; for example, an order is placed by exactly one customer.

Entity class:
a stereotyped class that represents objects in the business domain model.

Entry pseudostate:
an entry pseudostate shows an exceptional entry point into a submachine state.

Event:
an occurrence that is of significance to the information system and may be included in a state machine.

Exception:
a mechanism for handling errors in object-oriented languages.

Execution or Execution occurrence:
see activation.

Execution environment:
a type of node in a deployment diagram representing an implementation environment, container or platform in which an artefact is deployed.

Extend relationship:
a relationship between use cases where one use case extends or adds new actions to another. Written as a stereotype: «extend».

Extension point:
the point in a use case where an extension occurs, based on the satisfying of some condition.

Exit pseudostate:
an exit pseudostate shows an exceptional exit point from a submachine state.

eXtreme Programming (XP):
an approach to systems development that focuses on producing the simplest coding solution for application requirements. One characteristic is the use of pair programming, with code being written by two developers working at a single workstation.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Final pseudostate:
a final pseudostate is a notational convenience used to indicate the final state in a state machine.

Flow final node:
the final node in a flow within an activity diagram that terminates that flow but leaves other flows unaffected.Forces (of a pattern): the particular issues that must be addressed in resolving a problem.

Fork:
a node in an activity diagram where a flow is split into multiple parallel flows.

Frame:
a frame is a labelled rectangle that represents the boundary of a diagram; frames may be used for all diagram types but may be omitted where the boundary of the diagram is clear; they are an integral part of the notation for interaction diagrams and should be used for these.

Functional requirement:
a requirement that specifies a part of the functionality required by the user.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Generalization:
the abstraction of common features among elements (for example, classes) by the creation of a hierarchy of more general elements (for example, superclasses) that encapsulate the common features.

Guard condition:
a Boolean expression associated with a transition that is evaluated at the time the event fires. The transition only takes place if the condition is true. A guard condition is a function that may involve parameters of the triggering event and also attributes and links of the object that owns the statechart.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Implementation diagram:
a generic term for the UML diagrams used in modelling the implementation of a system.

Include relationship:
a relationship between use cases where one use case includes the actions described in another use case. Written as a stereotype: «include».

Incremental development:
development and delivery of software in incremental stages, where each increment provides some useful functionality. Some initial analysis scopes the problem and identifies major requirements. These are then reviewed and those that deliver most benefit to the client become the focus of the first increment. The installation of the first increment provides feedback to the team, which informs the second increment and so on.

Information:
facts that have been selected as relevant to a purpose and then organized or processed in such a way that they have meaning for that purpose.

Inheritance:
the mechanism by which object-oriented programming languages implement a relationship of generalization and specialization between classes. A subclass automatically acquires features of its superclasses.

Initial node:
the entry point to an activity diagram.

Initial pseudostate:
an initial pseudostate is a notational convenience used to indicate the starting state in a state machine. A state machine may not remain in its initial pseudostate.

Instance:
a single classifier, for example an object. Usually called an instance in the context of its membership of a particular class or type (also object instance).

Instance diagram:
a UML diagram similar in form to a class diagram, but that contains object instances instead of classes, links instead of asociations and may show attribute values (also known as an object diagram).

Instance value (of an attribute):
the value of an attribute that is taken by a particular object at a particular time.

Integrity constraint:
ensures that an information system holds data that is mutually consistent and is manipulated correctly. Referential integrity ensures that object identifiers in one object refer only to objects that exist. Dependency constraints ensure that attribute dependencies, where one attribute may be calculated from other attributes, are maintained consistently. Domain integrity ensures that attributes hold only permissible values.

Interaction:
defines the message passing between lifelines (e.g. objects) within the context of a collaboration to achieve a particular behaviour.

Interaction constraint:
an interaction constraint is a Boolean expression that must be true before the the interaction fragment in the combined fragment region it guards can execute.

Interaction diagram:
an umbrella term for sequence, communication, timing and interaction overview diagrams.

Interaction occurrence:
an interaction occurrence is a frame that does not show the detail of an interaction fragment but refers to another sequence diagram that does show this detail. It provides a mechanism to hide complex detail and it may be included in a sequence diagram or an interaction overview diagram.

Interaction operand:
an interaction operand is a compartment in a combined fragment and contains an interaction fragment.

Interaction operator:
an interaction operator determines the meaning of a combined fragment, for example the interaction operator ‘loop’ specifies that the combined fragment is specifying an iteration.

Interaction overview diagram:
an interaction overview diagram is a variant of an activity diagram and incorporates interaction diagrams. An interaction overview diagram focuses on the overview of flow of control in an interaction where the nodes in the diagram are interactions or interaction occurrences.

Interface:
that part of the boundary between two interacting systems across which they communicate; the set of all signatures for the public operations of a class, package or component.

Interface class:
a system interacts with its actors via its interface or boundary classes.

Invariant:
an aspect of a UML model expressed as a formal statement that must always remain true. For example, the value of a derived attribute totalCost may need always to be equal to the total of all cost attribute values.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Join:
a node in an activity diagram where multiple parallel flows are merged into a single flow.

Junction pseudostate:
a junction pseudostate allows the merging or splitting of transitions. When there are several exit transitions and only one entry transition this is known as a static conditional branch.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Knowledge:
a complex structure of information, usually one that allows its possessor to decide how to behave in particular situations.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Legacy system:
a computerized information system, probably in use for a long time and built with technologies that are now outmoded (perhaps also using different technologies and/or development approaches at different times)—but that continues to deliver benefit to the organization.

Life cycle (of a project):
the phases through which a development project passes from the inception of the idea to completion of the product and its eventual decommissioning.

Lifeline:
a lifeline represents the existence of a modelling element (e.g. object, subsystem) in an interaction diagram.

Link:
a connection between objects; an instance of an association.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Merge:
a node in an activity diagram where alternative flows created at a decision node are merged back to a single flow.

Message:
a request to an object that it provide some specified service, either an action that it can carry out or some information that it can provide. A message will invoke an operation or service.

Message passing:
a metaphor for the way that objects interact in an object-oriented system by sending each other messages that request services, or request or supply information. Since objects interact only through the messages they exchange, their internal details can remain hidden from each other.

Method:
the implementation of an operation.

Methodology:
typically comprises an approach to software development (e.g. object-orientation), a series of techniques and notations (e.g. the Unified Modelling Language—UML) that support the approach, a life cycle model (e.g. spiral incremental) to structure the development process, and a unifying set of procedures and philosophy.

Model Driven Architecture (MDA):
an OMG initiative and an approach to developing systems in which an platform-independent architectural model (q.v.) is produced and transformed into a platform-specific model (q.v.) from which code can be generated.

Modular construction:
an approach that aims to build component-based systems that are easy to maintain, modify or extend. Modular construction relies on modules that are essentially decoupled sub-systems, with their internal details encapsulated.

Multiplicity:
a constraint that specifies the range of permitted cardinalities (q.v.), for example in an association role or in a composite class. An association may have a multiplicity of 1..5; a partciular instance of that association may have a cardinality of 3.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Node:
A physical computational resource used by a system at run-time, typically having processing capability and memory in a deployment diagram. Also an element in an activity diagram.

Non-functional requirement:
a requirement that relates to system features such as performance, maintainability and portability.

Normalization:
a technique that groups attributes based upon functional dependencies according to several rules to produce normalized data structures that are largely redundancy free.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Object:
a single thing or concept, either in a model of an application domain or in a software system, that can be represented as an encapsulation of state, behaviour and identity; a member of a class that defines a set of similar objects.

Object diagram:
see instance diagram.

Object flow:
flow between an object and an action or activity in an activity diagram, that indicates that the object is used or its state changed by the action or activity.

Operation:
an aspect of the behaviour that defines a class; an element of the services that are provided by a class; a specification of an element of system functionality that will be implemented as a method of an object.

Operation signature:
determined by the operation’s name, the number and type of its parameters and the type of the return value if any. Polymorphically redefined operations have the same signature.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Package:
a mechanism for grouping UML elements, usually classes, into groups. Packages can be nested within other packages.

Pattern:
a pattern is an abstract solution to a commonly occurring problem in a given context.

Platform-independent model (PIM):
a model produced in model driven architecture (q.v.) that is independent of a development or deployment environment.

Platform-specific model (PSM):
a model produced in model driven architecture (q.v.) that is generated from a platform-independent model (q.v.) for a particular deployment environment.

Polymorphism:
the ability of different methods to implement the same operation, and thus to respond to the same message in different ways that are appropriate to their class. For example, objects of different subclasses in an inheritance hierarchy may respond differently to the same message, yet with a common meaning to their responses.

Post-condition:
part of an operation specification or used in a protocol state machine; those conditions that must be true before the operation can execute in an operation specification or before a transition may fire in a protocol state machine.

Pre-condition:
part of an operation specification or used in a protocol state machine; those conditions that must be true after the operation has executed or a transition has fired—in other words the valid results of the operation or the completion of the transition.

Primary operation:
an operation to create or destroy an instance of an class, or to get or set the value of an attribute.

Processing node:
a node in a deployment diagram.

Procedural call:
see synchronous message.

Property:
a feature or characteristic of a UML element, usually one for which there is no specific UML notation.

Protocol state machine:
see state machine.

Prototype:
a prototype is a system or partially complete system that is built quickly to explore some aspect of the system requirements. It is not intended as the final working system.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Query operation:
an operation that returns information but causes no change of state within a model or a software system.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Realize relationship:
a relationship between two elements where one is in some sense an implementation of the other, although it may not necessarily have the same structure. Commonly used to show that a class supports an interface. Written as a stereotype: «realize».

Refactoring:
to refactor program code is to restructure and simplify it so that duplication is removed and flexibility is enhanced.

Relation:
a group of related data items organized in columns and rows, also known as a table.

Reply:
A reply is a return of control to the object that originated the message that began the activation.

Repository:
the part of a modelling tool environment that handles the storage of models, including diagrams, specifications and definitions.

Responsibility:
a high level description of behaviour a class or component exhibits. It primarily reflects the the services that it can offer to other objects or components, and also the knowledge or information that is available to that class or component, either stored internally or requested via collaboration with other elements.

Reuse:
assembly of all or part of a new software system from elements, components or abstractions that already exist. Reuse can refer to binary software, designs, specifications, or to more abstract features such as elements in a generalization hierarchy.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Shallow history pseudostate:
a shallow history substate shows that a region in a composite state will resume at the last active substate at the level of the shallow history pseudostate.

Sequence diagram:
or interaction sequence diagram, shows an interaction between objects arranged in a time sequence. Sequence diagrams can be drawn at different levels of detail and also to meet different purposes at several stages in the development life cycle.

Service:
a useful function (or set of functionality) that is carried out by an object, component or sub-system) when requested to do so by another object or component.

Signal:
see asynchronous message.

Software architecture:
describes the sub-systems and components of a software system and the relationships between the components.

Specialization:
the other face of generalization; an element (for example, a class) is said to be specialized when it has a set of characteristics that uniquely distinguish it from other elements. Distinguishes subclasses from their superclass.

Stakeholders:
anyone who is affected by the information system. Stakeholders not only include users and development team members, but also resource managers and the quality assurance team, for example.

State machine:
a state machine models states and state dependent behaviour for a modelling element (e.g. object, subsystem, port, interface) and for interactions. There is a distinction between protocol and behavioural state machines in that protocol state machines only show all the legal transitions with their pre- and post-conditions. Behavioural state machines include activity expressions to show the actions that result from triggering events. State: the state of an object is determined by values of some of its attributes and the presence or absence of certain links with other objects. It reflects a particular condition for the object and normally persists for a period of time until a transition to another state is triggered by an event.

Static conditional branch:
see junction pseudostate.

Stereotype:
a specialized UML modelling element. The stereotype name is contained within matched guillemets «...». For example, an interface package is a stereotype of a package.

Subclass:
a specialized class that acquires general features from its ancestor superclasses in a generalization hierarchy, but that also adds one or more specialized characteristics of its own.

Subsystem:
a part of a system that can be regarded as a system in its own right.

Superclass:
a generalized class that is an abstraction of the common characteristics of its subclasses in a generalization hierarchy.

Synchronous message:
a synchronous message (or procedural call) causes the invoking operation to suspend execution until control has been returned to it.

Synchronizing operation:
an operation that ensures that those attribute values which are dependent upon each other (e.g. may be calculated from each other) have consistent values.

System:
an abstraction of a complex interacting set of elements, for which it is possible to identify a boundary, an environment, inputs and outputs, a control mechanism and some process or transformation that the system achieves.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Table:
group of related data items organized in columns and rows. Used to store data in relational databases.

Task:
a specific activity or step in a project.

Technique:
a method for carrying out a project task.

Template collaboration:
a template collaboration is a parameterized collaboration which may be implemented (that is instantiated) with different classes or objects.

Timing diagram:
a timing diagram shows the state changes for one or more lifelines, typically those with important time dependent; messages between lifelines may be shown.

Transaction:
an elementary exchange, say of an item of capta (qv.) or of a unit of value.

Transition:
the movement from one state or activity to another, triggered by an event. A transition may start and end at the same state.

Type:
a stereotype of class that is distinct from an implementation class; a type is defined by attributes and operations but, since it is a pure specification, may not have methods. Classes that represent application domain concepts are in fact types. An object may change type dynamically during system execution, and may thus appear at different times to belong to different classes.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Usability requirement:
user requirement that describes criteria by which the ease of use of the system can be judged.

Use case:
describes, from a user’s perspective, a behaviourally related set of transactions that are normally performed together to produce some value for the user. Use cases can be represented graphically in a use case diagram, each use case being described in the data dictionary. Use cases may be modelled at varying degrees of abstraction, essential use cases, the most abstract, are technologically and implementation independent whereas real use cases describe how the use case actually operates in a particular environment.

Use case realization:
a set of model elements that show the internal behaviour of the software that corresponds to the use case—usually a collaboration.

User requirement:
something that users require a software system to do (functional requirement); alternatively, a standard for the performance of a system (non-functional requirement).

User story:
in eXtreme Programming requirements are captured as user stories. A user story is similar to a use case.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Vertex:
a vertex is a node in a state machine diagram.

Visibility:
UML modelling elements (e.g. attributes or operations) may be designated with different levels of accessibility or visibility. Public visibility means that the element is directly accessible by any class; private visibility means that the element may only be used by the class that it belongs to; protected visibility means that the element may only be used by either the class that includes it or a subclass of that class; and package visibility means that an element is visible to objects in the package.

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

Wrapper:
or object wrapper, used to integrate object-oriented and non-object-oriented systems by encapsulating the non-object-oriented system with an object-oriented style of interface.