|
| |
[C]
- call
An action state that invokes an operation
on a classifier.
capsule
A specific design pattern which
represents an encapsulated thread of control in
the system. A capsule is a stereotyped class
with a specific set of required and restricted associations
and properties.
cardinality
The number of elements in a set. Contrast: multiplicity.
change control board (CCB)
The role of the CCB is to provide a central control mechanism to ensure that
every change request is properly
considered, authorized and coordinated.
child
In a generalization relationship, the
specialization of another element, the parent. See: subclass,
subtype.
Contrast: parent.
change management
The activity of controlling and tracking changes to artifacts.
See also: scope management.
change request (CR)
A general term for any request from a stakeholder
to change an artifact or process.
Documented in the Change Request is information on the origin and impact of
the current problem, the proposed solution, and its cost. See also: enhancement
request, defect.
checkpoints
A set of conditions that well-formed artifacts
of a particular type should exhibit. May also be stated in the form of
questions which should be answered in the affirmative.
class
A description of a set of objects that share the same attributes,
operations, methods,
relationships, and semantics. A class may
use a set of interfaces to specify collections of operations it provides to
its environment. See: interface.
class diagram
A diagram that shows a collection of declarative (static) model
elements, such as classes, types,
and their contents and relationships.
client
A classifier that requests a service from
another classifier. Contrast: supplier.
classifier
A mechanism that describes behavioral and structural features. Classifiers
include interfaces, classes,
datatypes, and components.
collaboration
(1) Is a description of a collection of objects that interact to implement
some behavior within a context. It describes a society of cooperating objects
assembled to carry out some purpose. (2) It captures a more holistic view of
behavior in the exchange of messages within a network of objects. (3)
Collaborations show the unity of the three major structures underlying
computation: data structure, control flow, and data flow. (4) A collaboration
has a static and a dynamic part. The static part describes the roles that
objects and links play in an instantiation of the collaboration. The dynamic
part consists of one or more dynamic interactions that show message flow over
time in the collaboration to perform computations. A collaboration may have a
set of messages to describe its dynamic
behavior. (5) A collaboration with messages is an interaction.
The specification of how an operation or classifier,
such as a use case, is realized by a
set of classifiers and associations playing
specific roles used in a specific way. The collaboration defines an
interaction. See: interaction.
collaboration diagram
(1) A collaboration diagram describes a pattern of interaction among
objects; it shows the objects participating in the interaction by their links
to each other and the messages they send to each
other. (2) It is a class diagram that
contains classifier roles and association
roles rather than just classifiers and associations. (3) Collaboration
diagrams and sequence diagrams both show interactions, but they emphasize
different aspects. Sequence diagrams show time sequences clearly but do not
show object relationships explicitly. Collaboration diagrams show object
relationships clearly, but time sequences must be obtained from sequence
numbers.
A diagram that shows interactions organized around the structure of a model,
using either classifiers and associations or instances and links. Unlike a
sequence diagram, a collaboration diagram shows the relationships among the
instances. Sequence diagrams and collaboration diagrams express similar
information, but show it in different ways. See: sequence
diagram.
comment
An annotation attached to an element or a collection of elements. A note has
no semantics. Contrast: constraint.
communicates-association
An association between an actor class and
a use case class, indicating that their
instances interact. The direction of the association indicates the initiator
of the communication (Unified Process convention).
communication association
In a deployment diagram an association between nodes that implies a
communication. See: deployment
diagram.
compile time
Refers to something that occurs during the compilation of a software module.
See: modeling time,
run time.
component
A non-trivial, nearly independent, and replaceable part of a system that
fulfills a clear function in the context of a well-defined architecture.
A component conforms to and provides the physical realization of a set of interfaces.
A physical, replaceable part of a system that packages implementation and
conforms to and provides the realization of a set of interfaces. A component
represents a physical piece of implementation of a system, including software
code (source, binary or executable) or equivalents such as scripts or command
files.
component diagram
A diagram that shows the organizations and dependencies among components.
component-based development (CBD)
The creation and deployment of software-intensive systems assembled from components
as well as the development and harvesting of such components.
component subsystem
A stereotyped subsystem (i.e.
«component») representing the logical abstraction in design of a component.
It realizes one or more interfaces, and may be
dependent on one or more interfaces. It may enclose zero or more classes,
packages or other component subsystems, none of
which are visible externally (only interfaces are visible). It may also
enclose zero or more diagrams which illustrate internal behavior (e.g. state,
sequence or collaboration
diagrams).
composite [class]
A class that is related to one or more classes
by a composition relationship. See: composition.
composite aggregation
Synonym: composition.
composite state
A state that consists of either concurrent (orthogonal) substates or
sequential (disjoint) substates. See: substate.
composite substate
A substate that can be held simultaneously
with other substates contained in the same composite state. Synonym: region.
See: composite state.
composition
A form of aggregation association
with strong ownership and coincident lifetime as part of the whole. Parts with
non-fixed multiplicity may be created after
the composite itself, but once created
they live and die with it (i.e., they share lifetimes). Such parts can also be
explicitly removed before the death of the composite. Composition may be
recursive. Synonym: composite
aggregation.
concrete
An entity in a configuration that satisfies an end-use function and can be
uniquely identified at a given reference point. (ISO)
concrete class
A class that can be directly instantiated.
Contrast: abstract
class.
concurrency
The occurrence of two or more activities during the same time interval.
Concurrency can be achieved by interleaving or simultaneously executing two or
more threads. See: thread.
concurrent substate
A substate that can be held simultaneously
with other substates contained in the same composite state. See: composite
substate. Contrast: disjoint
substate.
configuration
(1) general: The arrangement of a system or network as defined by the
nature, number, and chief characteristics of its functional units; applies to
both hardware or software configuration.
(2) The requirements, design, and implementation that define a particular
version of a system or system component. See configuration
management.
configuration item
An entity in a configuration that satisfies an end-use function and can be
uniquely identified at a given reference point. (ISO)
configuration management
A supporting process whose purpose is to identify, define, and baseline
items; control modifications and releases of these items; report and record
status of the items and modification requests; ensure completeness,
consistency and correctness of the items; and control storage, handling and
delivery of the items. (ISO)
control class
A class used to model behavior specific to one,
or a several use cases.
constraint
A semantic condition or restriction. Certain constraints are predefined in
the UML, others may be user defined. Constraints are one of three
extensibility mechanisms in UML. See: tagged
value, stereotype.
construction
The third phase of the Unified Process, in which the software is brought
from an executable architectural baseline to the point at which it is ready to
be transitioned to the user community.
container
1. An instance that exists to contain other
instances, and that provides operations to access or iterate over its
contents. (for example, arrays, lists, sets). 2. A component
that exists to contain other components.
containment hierarchy
A namespace hierarchy consisting of model
elements, and the containment relationships that exist between them. A
containment hierarchy forms an acyclic graph.
context
A view of a set of related modeling elements
for a particular purpose, such as specifying an operation.
core workflow
One of nine
core workflows in the Rational Unified Process: Business
Modeling, Requirements,
Analysis
& Design, Implementation,
Test,
Deployment,
Configuration
& Change Management, Project
Management, Environment.
An abstract business use case of the Software-Engineering Business.
critical design review (CDR)
In the waterfall life-cycle, the major review held when the detailed design
is completed (see Guidelines:
Project Plan).
customer
A person or organization, internal or external to the producing
organization, who takes financial responsibility for the system. In a large
system this may not be the end user. The customer is the ultimate recipient of
the developed product and its artifacts. See also: stakeholder.
cycle
One complete pass through the four phases: inception,
elaboration, construction
and transition. The span of time between the
beginning of the inception phase and the end of the transition phase.
[D]
- datatype
A descriptor of a set of values that lack identity and whose operations do
not have side effects. Datatypes include primitive pre-defined types and
user-definable types. Pre-defined types include numbers, string and time.
User-definable types include enumerations.
deadlock
A condition in which two independent threads of control are blocked, each
waiting for the other to take some action. Deadlock often arises from adding
synchronization mechanisms to avoid race
conditions.
defect
An anomaly, or flaw, in a delivered work product. Examples include such
things as omissions and imperfections found during early lifecycle phases and
symptoms of faults contained in software sufficiently mature for test or
operation. A defect can be any kind of issue you want tracked and resolved.
See also: change request.
defining model [MOF]
The model on which a repository is based. Any number of repositories can
have the same defining model.
delegation
The ability of an object to issue a message to
another object in response to a message. Delegation can be used as an
alternative to inheritance. Contrast: inheritance.
deliverable
An output from a process that has a value, material or otherwise, to a customer
or other stakeholder.
dependency
A relationship between two modeling elements,
in which a change to one modeling element (the independent element) will
affect the other modeling element (the dependent element).
deployment
A core process workflow in the
software-engineering process, whose purpose is to ensure a successful
transition of the developed system to its users. Included are artifacts
such as training materials and installation procedures.
deployment diagram
A diagram that shows the configuration of run-time processing nodes and the components,
processes, and objects
that live on them. Components represent run-time manifestations of code units.
See: component
diagram.
deployment view
An architectural view that
describes one or several system configurations; the mapping of software components
(tasks, modules) to the computing nodes in these configurations.
deliverable
An output from a process that has a value - material or nonmaterial - to a customer
or other stakeholder.
derived element
A model element that can be computed from another element, but that is shown
for clarity or that is included for design purposes even though it adds no
semantic information.
design
The part of the software development process whose primary purpose is to
decide how the system will be implemented. During design, strategic and
tactical decisions are made to meet the required functional and quality requirements
of a system. See analysis.
design time
Refers to something that occurs during a design phase of the software
development process. See: modeling
time. Contrast: analysis
time.
design mechanism
An architectural mechanism
used during the design process, during the period in which the details of the
design are being worked-out. They are related to associated analysis
mechanisms, of which they are additional refinements. A design
mechanism assumes some details of the implementation environment, but it is
not tied to a specific implementation (as is an implementation
mechanism). For example, the analysis mechanism for inter-process
communication may be refined by several design mechanisms for interprocess
communication (IPC): shared memory, function-call-like IPC, semaphore-based
IPC, and so on. Each design mechanism has certain strengths and weaknesses;
the choice of a particular design mechanism is determined by the
characteristics of the objects using the mechanism.
design model
An object model describing the
realization of use cases; serves as an
abstraction of the implementation model
and its source code.
design package
A collection of classes, relationships,
use-case realizations, diagrams,
and other packages; it is used to structure the design
model by dividing it into smaller parts.
design pattern
A specific solution to a particular problem in software design. Design
patterns capture solutions that have developed and evolved over time,
expressed in a succinct and easily applied form. Generally design patterns
express solutions at a lower level of granularity than mechanisms, and may
very well be used to design a design mechanism.
design subsystem
A design package that contains a
collection of design packages and classes, and
used to structure the design model by
dividing it into smaller parts. See: design
package.
developer
A person responsible for developing the required functionality in accordance
with project-adopted standards and procedures. This can include performing
activities in any of the requirements,
analysis
& design, implementation,
and test
workflows.
development case
The software-engineering process used by the performing organization. It is
developed as a configuration, or customization, of the Unified Process
product, and adapted to the project's needs.
development process
A set of partially ordered steps performed for a given purpose during
software development, such as constructing models or implementing models.
device
A type of node which provides supporting
capabilities to a processor. Although it may
be capable of running embedded programs (device drivers), it cannot execute
general-purpose applications, but instead exists only to serve a processor
running general-purpose applications.
diagram
A graphical depiction of all or part of a model.
A graphical presentation of a collection of model
elements, most often rendered as a connected graph of arcs
(relationships) and vertices (other model elements). UML supports the
following diagrams: class diagram, object
diagram, use-case diagram, sequence
diagram, collaboration diagram,
statechart diagram, activity
diagram, component diagram,
and deployment diagram.
disjoint substate
A substate that cannot be held simultaneously
with other substates contained in the same composite state. See: composite
state. Contrast: concurrent
substate.
distribution unit
A set of objects or components
that are allocated to a process or a processor as a group. A distribution unit
can be represented by a run-time composite
or an aggregate.
document
A document is a collection of information that is intended to be represented
on paper, or in a medium using a paper metaphor. The paper metaphor includes
the concept of pages, and it has either an implicit or explicit sequence of
contents. The information is in text or two-dimensional pictures. Examples of
paper metaphors are word processor documents, spreadsheets, schedules, Gantt
charts, web-pages, or overhead slide presentations.
document description
Describes the contents of a particular document.
document template
A concrete tool template, such as a Adobe®
FrameMaker™ or Microsoft®
Word™ template.
domain
An area of knowledge or activity characterized by a family of related
systems.
An area of knowledge or activity characterized by a set of concepts and
terminology understood by practitioners in that area.
domain model
A domain model captures the most important types of objects in the context
of the domain. The domain objects represent the
entities that exist or events that transpire in the environment in which the
system works. The domain model is a subset of the business
object model.
dynamic classification
A semantic variation of generalization
in which an object may change type
or role. Contrast: static
classification.
|
