A reviewed and approved release of artifacts
that constitutes an agreed basis for further evolution or development and that
can be changed only through a formal procedure, such as change
management and configuration
The observable effects of an operation or event, including its results.
A dynamic feature of a model element,
such as an operation or method.
behavioral model aspect
A model aspect that emphasizes the
behavior of the instances in a system,
including their methods, collaborations,
and state histories.
An association between two classes. A special
case of an n-ary association.
The creation of a model element from a template
by supplying arguments for the parameters of the template.
An enumeration whose values are true and false.
An expression that evaluates to a boolean
A class used to model communication between the system's environments and
its inner workings.
An operational version of a system or part of a system that demonstrates a
subset of the capabilities to be provided in the final product.
A condition which occurs when two or more independent tasks may
simultaneously access and modify the same state information. This condition
can lead to inconsistent behavior of the system and is a fundamental issue in
concurrent system design.
An attribute of a use case or scenario
that describes its impact on the architecture,
or its importance for a release.
A statement, or explanation of the reasons for a choice
receive [a message]
The handling of a stimulus passed from a sender instance. See: sender,
The object handling a stimulus passed from a sender object. Contrast: sender.
A declaration that a classifier is prepared to react to the receipt of a
1. A denotation of a model element. 2. A named slot
within a classifier that facilitates navigation to other classifiers. Synonym:
A relationship that represents a fuller
specification of something that has already been specified at a certain level
of detail. For example, a design class is a refinement of an analysis class.
A semantic connection among model elements. Examples of relationships
include associations and generalizations.
A subset of the end-product that is the object of evaluation at a major
milestone. See: prototype, baseline.
A release manager is responsible for ensuring that all software assets are
controlled and configurable into internal and external releases
An automatically generated description, describing one or several artifacts.
A report is not an artifact in itself. A report is in most cases a transitory
product of the development process, and a vehicle to communicate certain
aspects of the evolving system; it is a snapshot description of artifacts that
are not documents themselves.
A storage place for object models, interfaces, and implementations.
A requirement describes a condition or capability to which a system must
conform; either derived directly from user needs, or stated in a contract,
standard, specification, or other formally imposed document. See: Concept:
A desired feature, property, or behavior of a system.
Information associated with a particular requirement providing a link
between the requirement and other project elements - e.g., priorities,
schedules, status, design elements, resources, costs, hazards.
A core process workflow in the
software-engineering process, whose purpose is to define what the system
should do. The most significant activities are to develop a vision,
model and software
approach to eliciting, organizing and documenting the requirements
of the system, and establishing and maintaining agreement between the customer
and the project team on the changing requirements of the system. See: Concept:
The linking of a requirement to other
requirements and to other associated project elements.
A categorization of requirements (e.g., stakeholder need, feature, use case,
supplementary requirement, test requirement, documentation requirement,
hardware requirement, software requirement, etc.) based on common
characteristics and attributes. See: Concept:
A contract or obligation of a classifier.
Synonym of output. See also deliverable.
A review is a group activity carried out to discover potential defects and
to assess the quality of a set of artifacts.
Further use or repeated use of an artifact
The use of a pre-existing artifact.
An ongoing or upcoming concern that has a significant probability of
adversely affecting the success of major milestones.
The behavior of a design element participating in a particular context (e.g.
use-case realization). See also: analysis class.
The named specific behavior of an entity
participating in a particular context. A role may be static (e.g., an
association end) or dynamic (e.g., a collaboration role).
The period of time during which a computer program executes. Contrast: modeling
- race condition
A described use-case instance, a
subset of a use case.
A specific sequence of actions that illustrates
behaviors. A scenario may be used to illustrate an interaction or the
execution of a use case instance. See: interaction.
The process of prioritizing and determining the set of requirements that can
be implemented in a particular release cycle, based on the resources and time
available. This process continues throughout the lifecycle of the project as
changes occur. See also: change management.
In the context of the MOF, a schema is analogous to
which is a container of model
elements. Schema corresponds to an MOF
package. Contrast: metamodel,
package corresponds to an MOF package.
semantic variation point
A point of variation in the semantics of a metamodel.
It provides an intentional degree of freedom for the interpretation of the
send [a message]
The passing of a stimulus from a sender instance to a receiver instance.
The object passing a stimulus to a receiver object. Contrast: receiver.
A diagram that shows object interactions arranged
in time sequence. In particular, it shows the objects participating in the
interaction and the sequence of messages exchanged. Unlike a collaboration
diagram, a sequence diagram includes time sequences but does not include
object relationships. A sequence diagram can exist in a generic form
(describes all possible scenarios)
and in an instance form (describes one actual scenario). Sequence diagrams and
collaboration diagrams express similar information, but show it in different
ways. See: collaboration
The specification of an asynchronous stimulus
communicated between instances. Signals may have parameters.
The name and parameters of a behavioral feature. A signature may include an
optional returned parameter.
A semantic variation of generalization
in which a type may have only one supertype.
single valued [MOF]
A model element with multiplicity
defined is single valued when its Multiplicity Type:: upper attribute is set
to one. The term single-valued does not pertain to the number of values held
by an attribute, parameter, etc., at any point in time, since a single-valued
attribute (for instance, with a multiplicity lower bound of zero) may have no
value. Contrast: multi-valued.
Software architecture encompasses:
- the significant decisions about the organization of a software system,
- the selection of the structural elements and their interfaces by which
the system is composed together with their behavior as specified in the
collaboration among those elements,
- the composition of the structural and behavioral elements into
progressively larger subsystems,
- the architectural style that guides this organization, these elements
and their interfaces, their collaborations, and their composition.
- Software architecture is not only concerned with structure and behavior,
but also with usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technology constraints and tradeoffs, and
- Software Engineering Process Authority (SEPA)
- The organizational entity with responsibility for process definition,
assessment and improvement (see Concepts:
Organizational Context for the Rational Unified Process).
- software requirement
- A specification of an externally observable behavior of the system, (e.g.,
inputs to the system, outputs from the system, functions of the system,
attributes of the system, or attributes of the system environment).
- software requirements specifications (SRS)
- A set of requirements which completely defines the external behavior of
the system to be built. (sometimes called a functional specification)
- software specification review (SSR)
- In the waterfall life-cycle, the major review held when the software
requirements specification is complete (see Guidelines:
- A declarative description of what something is or does. Contrast: implementation.
- An individual who is materially affected by the outcome of the system.
- stakeholder need
- The business or operational problem (opportunity) that must be fulfilled
in order to justify purchase or use.
- stakeholder request
- A request of any type (e.g., Change
Request, enhancement request,
request for a requirement change, defect) from
- A condition or situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event.
Contrast: state [OMA].
- statechart diagram
- A diagram that shows a state machine. See: state
- state machine
- A state machine specifies the behavior of a model
element, defining its response to events and the life cycle of the
- A behavior that specifies the sequences of states
that an object or an interaction goes through during its life in response to
events, together with its responses and actions.
- static artifact
- An artifact that is used, but not changed, by a process.
- static classification
- A semantic variation of generalization
in which an object may not change type or may not change role. Contrast: dynamic
- A meta-classification of an element. Stereotypes have semantic
implications which can be specified for every specific stereotype value. See
Stereotypes in the Rational Unified Process for information on the
pre-defined stereotypes in use in the Rational Unified Process.
- A new type of modeling element that extends the
semantics of the metamodel. Stereotypes must be based on certain existing
types or classes in the metamodel. Stereotypes may extend the semantics, but
not the structure of pre-existing types and classes. Certain stereotypes are
predefined in the UML, others may be user defined.
- The passing of information from one instance to another, such as raising a
signal or invoking an operation.
The receipt of a signal is normally considered an event.
- A sequence of text characters. The details of
string representation depend on implementation, and may include character
sets that support international characters and graphics.
- structural feature
- A static feature of a model element,
such as an attribute.
- structural model aspect
- A model aspect that emphasizes the structure of
the objects in a system, including their types,
- A component containing functionality for testing purposes. A stub is
either a pure "dummy", just returning some predefined values, or
it is "simulating" a more complex behavior.
- subactivity state
- A state in an activity
graph that represents the execution of a non-atomic sequence of
steps that has some duration.
- In a generalization relationship, the specialization of another class; the
superclass. See: generalization.
- submachine state
- A state
in a state
machine which is equivalent to a composite
state but its contents is described
by another state machine.
- A state that is part of a composite state.
- A model element which has the
semantics of a package, such that it can
contain other model elements, and a class, such
that it has behavior. (The behavior of the subsystem is provided by classes
or other subsystems it contains). A subsystem realizes one or more
interfaces, which define the behavior it can perform.
- A subsystem is a grouping of model elements, of
which some constitute a specification of the behavior offered by the other
contained model elements. See package.
- In a generalization relationship, the specialization of another type; the
supertype. See: generalization.
- In a generalization relationship, the generalization of another class; the
subclass. See: generalization.
- In a generalization relationship, the generalization of another type; the
subtype. See: generalization.
- A classifier that provides services that can be invoked by others.
- A partition on a activity diagram for
organizing the responsibilities for actions. Swimlanes typically correspond
to organizational units in a business model. See: partition.
- synch state
- A vertex in a state machine used for
synchronizing the concurrent regions of a state machine.
- synchronous action
- A request where the sending object pauses to wait for results. Contrast: asynchronous
- As an instance, an executable configuration of a software application or
software application family; the execution is done on a hardware platform.
As a class, a particular software application or software application family
that can be configured and installed on a hardware platform. In a general
sense, an arbitrary system instance.
- 1. A collection of connected units that are organized to accomplish a
specific purpose. A system can be described by one or more models, possibly
from different viewpoints. Synonym: physical system. 2. A top-level
- system requirements review (SRR)
- In the waterfall life-cycle, the name of the major review held when the
system specification is completed (see Guidelines:
The explicit definition of a property as a
name-value pair. In a tagged value, the name is referred as the tag. Certain
tags are predefined in the UML; others may be user defined. Tagged values are
one of three extensibility mechanisms in UML. See: constraint,
target (for test)
A build that is an object for testing. See: build.
See: operating system process,
process and thread.
The team leader is the interface between project management and developers.
The team leader is responsible for ensuring that a task is allocated and
monitored to completion. The team leader is responsible for ensuring that
development staff follow project standards, and adhere to project schedules.
The project's technical authority has the authority and technical expertise
to arbitrate on if, and how, a change request is to be implemented. The
technical authority defines change tasks, and estimates the effort of
engineering the work tasks (corresponding to a change
A pre-defined structure for an artifact.
A core process workflow in the
software-engineering process whose purpose is to integrate and test the
A set of test inputs, execution conditions, and expected results developed
for a particular objective, such as to exercise a particular program path or
to verify compliance with a specific requirement.
The degree to which a given test or set of tests addresses all specified
test cases for a given system or component.
A software module or application used to invoke a test item and, often,
provide test inputs (data), control and monitor execution, and report test
results. A test driver automates the execution of test procedures.
A build which is an object of testing. See: build.
A test procedure is a set of detailed instructions for the set-up,
execution, and evaluation of results for a given test
An independent computation executing within an the execution environment and
address space defined by an enclosing operating system process.
Also sometimes called a 'lightweight process'.
thread [of control]
A single path of execution through a program, a
dynamic model, or some other representation of control flow. Also, a
stereotype for the implementation of an active object as lightweight process.
A value representing an absolute or relative moment in time.
An event that denotes the time elapsed since the current state was entered.
An expression that resolves to an absolute or relative value of time.
A denotation for the time at which an event or message occurs. Timing marks
may be used in constraints.
A description which provides practical guidance on how to perform specific
process activities or steps using a specific software tool.
The ability to trace a project element to other related project elements,
especially those related to requirements.
A dependency that indicates a historical or process relationship between two
elements that represent the same concept without specific rules for deriving
one from the other.
An object that exists only during the execution of the process or thread
that created it.
The fourth phase of the process in which the
software is turned over to the user community.
A relationship between two states indicating
that an object in the first state will perform certain specified actions and
enter the second state when a specified event occurs and specified conditions
are satisfied. On such a change of state, the transition is said to fire.
Description of a set of entities which share common characteristics,
relations, attributes, and semantics.
A stereotype of class that is used to specify a domain of instances
(objects) together with the operations applicable to the objects. A type may
not contain any methods. See: class,
An expression that evaluates to a reference to one or more types.
- tagged value