American Science Institute of Technology  


   C to D
Home Up Feedback Legal News




An action state that invokes an operation on a classifier.
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.
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.
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.
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.
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.
A classifier that requests a service from another classifier. Contrast: supplier.
A mechanism that describes behavioral and structural features. Classifiers include interfaces, classes, datatypes, and components.
(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.
An annotation attached to an element or a collection of elements. A note has no semantics. Contrast: constraint.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
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).
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.
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.


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.
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.
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.
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.
An output from a process that has a value, material or otherwise, to a customer or other stakeholder.
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).
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.
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.
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.
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.
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.
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.
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.
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.

Hit Counter

Home ] Up ]

Send mail to with questions or comments about this web site.
Copyright © 1997 - 2006 American Science Institute of Technology