American Science Institute of Technology  

 

   R to T
Home Up Feedback Legal News

 

 

[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.
 

Hit Counter

Home ] Up ]

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