|
| |
[B]
- baseline
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
control.
behavior
The observable effects of an operation or event, including its results.
behavioral feature
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.
binary association
An association between two classes. A special
case of an n-ary association.
binding
The creation of a model element from a template
by supplying arguments for the parameters of the template.
boolean
An enumeration whose values are true and false.
boolean expression
An expression that evaluates to a boolean
value.
boundary class
A class used to model communication between the system's environments and
its inner workings.
build
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.
[R]
- race condition
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.
rank
An attribute of a use case or scenario
that describes its impact on the architecture,
or its importance for a release.
rationale
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,
receiver.
receiver [object]
The object handling a stimulus passed from a sender object. Contrast: sender.
reception
A declaration that a classifier is prepared to react to the receipt of a
signal.
reference
1. A denotation of a model element. 2. A named slot
within a classifier that facilitates navigation to other classifiers. Synonym:
pointer.
refinement
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.
relationship
A semantic connection among model elements. Examples of relationships
include associations and generalizations.
release
A subset of the end-product that is the object of evaluation at a major
milestone. See: prototype, baseline.
release manager
A release manager is responsible for ensuring that all software assets are
controlled and configurable into internal and external releases
as required.
report
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.
repository
A storage place for object models, interfaces, and implementations.
requirement
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:
Requirements
A desired feature, property, or behavior of a system.
requirement attribute
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.
requirements
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,
a use-case
model and software
requirements specifications.
requirements management
A systematic
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:
Requirements Management.
requirements tracing
The linking of a requirement to other
requirements and to other associated project elements.
requirement type
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:
Requirement Types
responsibility
A contract or obligation of a classifier.
result
Synonym of output. See also deliverable.
review
A review is a group activity carried out to discover potential defects and
to assess the quality of a set of artifacts.
reuse
Further use or repeated use of an artifact
The use of a pre-existing artifact.
risk
An ongoing or upcoming concern that has a significant probability of
adversely affecting the success of major milestones.
role
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).
run time
The period of time during which a computer program executes. Contrast: modeling
time.
[S]
- scenario
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.
scope management
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.
schema [MOF]
In the context of the MOF, a schema is analogous to
a package
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
metamodel semantics.
send [a message]
The passing of a stimulus from a sender instance to a receiver instance.
See: sender,
receiver.
sender [object]
The object passing a stimulus to a receiver object. Contrast: receiver.
sequence diagram
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
diagram.
signal
The specification of an asynchronous stimulus
communicated between instances. Signals may have parameters.
signature
The name and parameters of a behavioral feature. A signature may include an
optional returned parameter.
single inheritance
A semantic variation of generalization
in which a type may have only one supertype.
Synonym: multiple
inheritance [OMA].
Contrast: multiple
inheritance.
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
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
aesthetic concerns.
- 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:
Project Plan).
- specification
-
- A declarative description of what something is or does. Contrast: implementation.
- stakeholder
- 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 stakeholder.
- state
-
- 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
machine.
- state machine
- A state machine specifies the behavior of a model
element, defining its response to events and the life cycle of the
object.
-
- 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
classification.
- stereotype
- A meta-classification of an element. Stereotypes have semantic
implications which can be specified for every specific stereotype value. See
UML
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.
- stimulus
-
- 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.
See: message.
- string
-
- 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,
classes,
relationships,
attributes,
and operations.
- stub
- 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.
- subclass
-
- In a generalization relationship, the specialization of another class; the
superclass. See: generalization.
Contrast: superclass.
- submachine state
-
- A state
in a state
machine which is equivalent to a composite
state but its contents is described
by another state machine.
- substate
-
- A state that is part of a composite state.
See: concurrent
substate, disjoint
substate.
- subsystem
- 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.
See: system.
- subtype
-
- In a generalization relationship, the specialization of another type; the
supertype. See: generalization.
Contrast: supertype.
- superclass
-
- In a generalization relationship, the generalization of another class; the
subclass. See: generalization.
Contrast: subclass.
- supertype
-
- In a generalization relationship, the generalization of another type; the
subtype. See: generalization.
Contrast: subtype.
- supplier
-
- A classifier that provides services that can be invoked by others.
Contrast: client.
- swimlane
-
- 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
action.
- system
- 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
subsystem.
- system requirements review (SRR)
- In the waterfall life-cycle, the name of the major review held when the
system specification is completed (see Guidelines:
Project Plan).
[T]
- tagged value
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,
stereotype.
target (for test)
A build that is an object for testing. See: build.
task
See: operating system process,
process and thread.
team leader
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.
technical authority
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
request).
template
A pre-defined structure for an artifact.
Synonym: parameterized
element.
test
A core process workflow in the
software-engineering process whose purpose is to integrate and test the
system.
test case
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.
test coverage
The degree to which a given test or set of tests addresses all specified
test cases for a given system or component.
test driver
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.
test item
A build which is an object of testing. See: build.
test procedure
A test procedure is a set of detailed instructions for the set-up,
execution, and evaluation of results for a given test
case.
thread
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.
See process.
time
A value representing an absolute or relative moment in time.
time event
An event that denotes the time elapsed since the current state was entered.
See: event.
time expression
An expression that resolves to an absolute or relative value of time.
timing mark
A denotation for the time at which an event or message occurs. Timing marks
may be used in constraints.
tool mentor
A description which provides practical guidance on how to perform specific
process activities or steps using a specific software tool.
traceability
The ability to trace a project element to other related project elements,
especially those related to requirements.
trace
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.
transient object
An object that exists only during the execution of the process or thread
that created it.
transition
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.
type
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,
instance.
Contrast: interface.
type expression
An expression that evaluates to a reference to one or more types.
|
