Appendix A. Glossary

This glossary presents terms in “Mere Mortals” fashion. More formal definitions can be found in the various references cited in this book. Terms in bold, used in a definition, are defined elsewhere in the glossary.

abstraction—

A representation that focuses on certain aspects of a thing and that might eliminate other aspects.

action—

A processing step (an atomic behavior) taken as part an activity.

activity—

A series of actions executed to provide a certain behavior.

activity diagram—

A diagram that shows the flow of activities related to various actors.

actor—

A role that a person, system, or other entity plays when interacting with the system being developed. Actors are external to the system.

aggregate—

The class in an aggregation that represents the “whole” in the “whole-part” relationship.

aggregation—

An association that represents a “whole-part” relationship between an aggregate and its parts.

analysis—

A phase in the development lifecycle where you consider the requirements and determine what needs to be done to satisfy those requirements, not how they are to be satisfied.

argument—

The value of a parameter of an operation.

association—

A relationship between classes.

association class—

A class that also has properties of an association.

attribute—

Part of a class that describes or captures some property of that class.

cardinality—

The number of things in a set.

child (a.k.a. subclass)—

A specialization of the parent (a.k.a. superclass) in a generalization relationship.

class—

An element that describes a group of objects that have the same attributes, operations, relationships, constraints, and meaning.

class diagram—

A diagram that provides a static view of the system.

collaboration—

The cooperative behavior of a group of elements.

collaboration diagram—

See communication diagram.

communication diagram—

A type of interaction diagram that focuses on the relationships between the objects that participate in an interaction.

component—

A replaceable physical part in a system that provides a specified set of interfaces and capabilities.

component diagram—

A diagram that shows the relationships between components.

composite—

A class that is related to one or more classes (a.k.a. the parts) by a composition relationship. The composite is responsible for the creation and destruction of the parts.

composite aggregation—

A tighter, more intimate form of aggregation where the “parts” cannot exist without the “whole” (a.k.a. the composite). In a composition, a part can only be included in one composite at a time.

composition—

See composite aggregation.

constraint—

A restriction on a model element.

delegation—

The capability of an object to send a message to a second object, typically for the purpose of having the second object perform a function for the originating object.

dependency—

A relationship between two modeling elements in which a change to the independent element affects the dependent element.

deployment diagram—

A diagram that shows the runtime configuration of a system.

design—

A phase in the development lifecycle where you focus on how the system will be built to meet its requirements.

domain—

A body of knowledge that has a commonly understood set of terms, concepts, and techniques used by the people working in that area.

encapsulation—

A concept whereby an class's data is hidden from outside entities and can only be accessed by external entities through the operations provided by that class.

event—

Something that occurs that can trigger a transition in a statechart diagram.

extend—

A relationship between an extending use case to a base use case, typically showing how the extending use case can change the behavior of the base use case under certain conditions.

focus of control—

A rectangular bar on a lifeline in a sequence diagram that shows the period of time during which an object is performing an action (i.e., has the “thread of control”).

generalization—

A relationship between elements where the child elements are specialized versions of their parent element and can inherit the structure and behavior of their parent.

guard condition—

A condition that, when satisfied, enables a transition to execute.

include—

A relationship between a base use case to an inclusion use case, showing how the base use case includes the behavior of the inclusion use case.

inheritance—

The mechanism in a generalization that enables the more specialized elements to inherit the structure and behavior of the more general element.

instance—

A unique occurrence of an abstract element (e.g., an object instance of a class).

interaction—

The specification of how messages flow among a group of objects for a given purpose.

interaction diagram—

The name for a set of diagrams that depict the dynamic behavior of a set of objects. These include communication diagrams, sequence diagrams, and interaction overview diagrams.

interaction overview diagram—

A type of high-level activity diagram that depicts an overview of the control flow of an interaction.

interface—

A set of operations that specify the services provided by an element.

lifeline—

A line that represents the existence, over time, of an individual element in an interaction.

message—

A communication between objects.

meta-model—

A model that is built to describe a model.

method—

The detailed implementation of an operation.

multiple inheritance—

A situation where a subclass inherits from more than one superclass.

multiplicity—

The specification of the allowed cardinalities on an end of an association.

n-ary association—

An association between three or more classes.

object—

An instance of a class.

object diagram—

A diagram that shows objects and their relationships at a given point in time.

operation—

A service provided by a class.

package—

A general mechanism for gathering model elements into groups.

package diagram—

A diagram that depicts the dependencies between packages.

parameter—

The specification of an argument.

parent (a.k.a. superclass)—

A generalization of the child (a.k.a. subclass) in a generalization relationship.

polymorphism—

The ability of a child class to override (and thus redefine) the operations of its parent class.

postcondition—

A condition that must be true after an operation is completed.

precondition—

A condition that must be true when an operation is executed.

profile—

A set of model elements that have been customized (using standard UML extension mechanisms) for a specific purpose.

qualifier—

An association attribute that partitions a set of objects on one side of an association.

realization—

The implementation of something specified by another model element (e.g., a use case realization implements a use case).

relationship—

A general term denoting a connection between model elements (e.g., association, composition, generalization).

role—

A specific set of behaviors of a given model element.

sequence diagram—

A type of interaction diagram that focuses on the messages passed between objects in time order.

signature—

An operation's name and parameters.

single inheritance—

A situation where a subclass inherits from one superclass.

state—

The condition of an object at a point in time.

state machine diagram (a.k.a statechart diagram)—

A diagram that depicts the states of an object and its transitions between those states over the object's lifetime.

stereotype—

A standard UML mechanism used to extend existing UML elements for specific purposes.

subclass (a.k.a. child)—

A specialization of the superclass (a.k.a. parent) in a generalization relationship.

superclass (a.k.a. parent)—

A generalization of the subclass (a.k.a. child) in a generalization relationship.

swimlane—

A partitioning of elements in an activity diagram.

tagged value—

A standard extension mechanism of the UML where a property of an element is defined as a name-value pair.

timing diagram—

A diagram that depicts changes in state or condition of a lifeline (typically an object) with a focus on the timing of events.

transition—

A relationship between two states that depicts how an object will change state.

trigger—

An event that causes an object to change state.

use case—

A series of transactions performed between the system and an actor that yields valuable results to the actor.

use case diagram—

A diagram that depicts the relationships between the actors and the system's use cases.

view—

A depiction of certain aspects of a model, which addresses the particular viewer's interests or concerns.

visibility—

The specification of how or whether a model element can be seen by other elements.