Glossary

abstract class:

A class that cannot be directly instantiated (Booch et al. 2005). Compare concrete class.

abstract data type:

A data type that is defined by the operations that manipulate it and thus has its representation details hidden.

abstract interface specification:

A specification that defines the external view of the information hiding class—that is, all the information required by the user of the class.

abstract operation:

An operation that is declared in an abstract class but not implemented.

action:

A computation that executes as a result of a state transition.

active object:

See concurrent object:.

activity:

A computation that executes for the duration of a state.

actor:

An outside user or related set of users who interact with the system (Rumbaugh et al. 2005).

aggregate class:

A class that represents the whole in an aggregation relationship (Booch et al. 2005).

aggregate subsystem:

A logical grouping of lower-level subsystems and/or objects.

aggregation:

A whole/part relationship. Compare composition.

algorithm object:

An object that encapsulates an algorithm used in the problem domain.

alternative feature:

A feature that can be chosen in place of a different feature in the same software product line. Compare common feature and optional feature.

alternative use case:

A use case that can be chosen in place of a different use case in the same software product line. Compare kernel use case and optional use case.

analysis modeling:

A phase of the PLUS object-oriented software life cycle in which static modeling and dynamic modeling are performed. Compare design modeling and requirements modeling.

application deployment:

A process for deciding which component instances are required, how component instances should be interconnected, and how the component instances should be allocated to physical nodes in a distributed environment.

application engineering:

See software application engineering:.

application logic object:

An object that hides the details of the application logic separately from the data being manipulated.

architectural pattern:

See software architectural pattern:.

association:

A relationship between two or more classes.

asynchronous component:

A component that is activated on demand.

asynchronous I/O device:

An input/output device that generates an interrupt when it has produced some input or when it has finished processing an output operation.

asynchronous message communication:

A form of communication in which a concurrent producer component sends a message to a concurrent consumer component and does not wait for a response; a message queue could potentially build up between the concurrent components. Also referred to as loosely coupled message communication. Compare synchronous message communication.

at-least-one-of feature group:

A feature group in which one or more features can be selected from the group, but at least one feature must be selected.

behavioral analysis:

See dynamic analysis:.

behavioral model:

A model that describes the responses of the system to the inputs that the system receives from the external environment.

binary semaphore:

A Boolean variable used to enforce mutual exclusion. Also referred to simply as semaphore.

black box specification:

A specification that describes the externally visible characteristics of the system.

boundary object:

See interface object:.

broadcast communication:

A form of group communication in which unsolicited messages are sent to all recipients.

broker:

An intermediary in interactions between clients and servers. Also referred to as object broker or object request broker.

brokered communication:

Message communication in a distributed object environment in which clients and servers interact via a broker.

business logic object:

An object that encapsulates the business rules (business-specific application logic) for processing a client request.

callback:

An operation handle sent by a client in an asynchronous request to a server and used by the server to respond to the client request.

CASE:

See Computer Aided Software Engineering (CASE) tool:.

category:

A specifically defined division in a system of classification.

class:

An object type; hence, a template for objects. An implementation of an abstract data type.

class diagram:

A UML diagram that depicts a static view of a system in terms of classes and the relationships between classes. Compare interaction diagram.

class interface specification:

A specification that defines the externally visible view of a class, including the specification of the operations provided by the class.

class structuring criteria:

See object structuring criteria:.

client:

A requester of services in a client/server system. Compare server.

client/server system:

A system that consists of clients that request services and one or more servers that provide services.

collaboration diagram:

UML 1.x name for communication diagram.

COM:

See Component Object Model (COM):.

COMET:

See Concurrent Object Modeling and Architectural Design Method (COMET):.

commonality:

The functionality that is common to all members of a software product line. Compare variability.

commonality/variability analysis:

An approach for examining the functionality of a software product line to determine which functionality is common to all product line members and which is not.

common feature:

A feature that must be provided by every member of the software product line. Compare optional feature and alternative feature.

Common Object Request Broker Architecture (CORBA):

An open systems standard for middleware technology, developed by the Object Management Group, that allows communication between distributed objects on heterogeneous platforms.

communication diagram:

A UML 2.0 interaction diagram that depicts a dynamic view of a system in which objects interact by using messages. In UML 1.x, referred to as a collaboration diagram.

complex port:

A port that supports both a provided interface and a required interface.

component:

A concurrent self-contained object with a well-defined interface, capable of being used in different applications from that for which it was originally designed. Also referred to as distributed component.

component-based system:

A system in which an infrastructure is provided that is specifically intended to accommodate preexisting components.

Component Object Model (COM):

A Microsoft component technology that provides a framework for application interoperation in a Windows environment.

component structuring criteria:

A set of heuristics for assisting a designer in structuring a system into components.

composite component:

A component that contains nested components. Also referred to as composite subsystem. Compare simple component.

composite object:

An object that contains nested objects.

composite state:

A state on a statechart that is decomposed into two or more substates. Also referred to as a superstate.

composite structure diagram:

A UML 2.0 diagram that depicts the structure and interconnections of composite classes; often used to depict components, ports, and connectors.

composite subsystem:

See composite component:.

composition:

A form of whole/part relationship that is stronger than an aggregation; the part objects are created, live, and die together with the composite (whole) object.

Computer Aided Software Engineering (CASE) tool:

A software tool that supports a software engineering method or notation.

concrete class:

A class that can be directly instantiated (Booch et al. 2005). Compare abstract class.

concurrent:

Referring to a problem, process, system, or application in which many activities happen in parallel, where the order of incoming events is not usually predictable and is often overlapping. A concurrent system or application has many threads of control. Compare sequential.

concurrent collaboration diagram:

See concurrent communication diagram:.

concurrent communication diagram:

A communication diagram that depicts a network of concurrent objects and their interactions in the form of asynchronous and synchronous message communication. In UML 1.x, referred to as a concurrent collaboration diagram.

concurrent object:

An autonomous object that has its own thread of control. Also referred to as an active object, process, task, thread, concurrent process, or concurrent task.

Concurrent Object Modeling and Architectural Design Method (COMET):

A software design method for concurrent, distributed, and real-time applications.

concurrent process:

See concurrent object:.

concurrent server:

A server that services multiple client requests in parallel. Compare sequential server.

concurrent task:

See concurrent object:.

condition:

The value of a Boolean variable that represents a particular aspect of the system that can be true or false over a finite interval of time.

connector:

An object that encapsulates the interconnection protocol between two or more components.

consolidated collaboration diagram:

See integrated communication diagram:.

constraint:

A condition that must be true.

control object:

An object that provides overall coordination for a collection of objects.

coordinator object:

An overall decision-making object that determines the overall sequencing for a collection of related objects and is not state-dependent.

CORBA:

See Common Object Request Broker Architecture (CORBA):.

critical section:

The section of a concurrent object's internal logic that is mutually exclusive.

data abstraction:

An approach for defining a data structure or data type by the set of operations that manipulate it, thus separating and hiding the representation details.

data abstraction class:

A class that encapsulates a data structure or data type, thereby hiding the representation details; operations provided by the class manipulate the hidden data.

database wrapper class:

A class that hides how to access data stored in a database.

data replication:

Duplication of data in more than one location in a distributed application to speed up access to the data.

deadlock:

A situation in which two or more concurrent objects are suspended indefinitely because each concurrent object is waiting for a resource acquired by another concurrent object.

default class:

A class that is automatically selected from a group of variant classes, when no other class is explicitly chosen.

default feature:

A feature out of a group of alternative features in the same software product line that is automatically chosen if no other feature is explicitly selected in its place.

delegation connector:

A connector that joins the outer port of a composite component to the inner port of a part component such that messages arriving at the outer port are forwarded to the inner port.

deployment diagram:

A UML diagram that shows the physical configuration of the system in terms of physical nodes and physical connections between the nodes, such as network connections.

design concept:

A fundamental idea that can be applied to designing a system.

design method:

A systematic approach for creating a design. The design method helps identify the design decisions to be made, the order in which to make them, and the criteria used in making them.

design modeling:

A phase of the PLUS object-oriented software life cycle in which the software architecture of the system is designed. Compare analysis modeling and requirements modeling.

design notation:

A graphical, symbolic, or textual means of describing a design.

design pattern:

A description of a recurring design problem to be solved, a solution to the problem, and the context in which that solution works.

design strategy:

An overall plan and direction for developing a design.

device interface object:

An information hiding object that hides the characteristics of an I/O device and presents a virtual device interface to its users.

discrete data:

Data that arrives at specific time intervals.

distributed:

A system or application that is concurrent in nature and executes in an environment consisting of multiple nodes, which are in geographically different locations.

distributed application:

An application that executes in a distributed environment.

distributed component:

See component:.

distributed kernel:

The nucleus of an operating system that supports distributed applications.

distributed processing environment:

A system configuration in which several geographically dispersed nodes are interconnected by means of a local area or wide area network.

distributed server:

A server whose functionality is spread over several nodes.

domain analysis:

Analysis of a software product line.

domain model:

Model of a software product line.

domain modeling:

Modeling of a software product line.

domain-specific pattern:

A software pattern that is specific to a given software product line.

domain-specific software architecture:

See software product line architecture:.

dynamic analysis:

A strategy to help determine how the objects that participate in a use case interact. Also referred to as behavioral analysis.

dynamic model:

A view of a problem or system in which control and sequencing is considered, either within an object by means of a finite state machine or by consideration of the sequence of interaction among objects.

dynamic modeling:

The process of developing the dynamic model of a system or software product line.

EJB:

See Enterprise JavaBeans (EJB):.

encapsulation:

See information hiding:.

Enterprise JavaBeans (EJB):

A Java-based component technology.

entity class:

A class whose instances are long-living objects, in many cases persistent, that encapsulate data.

entity object:

A long-living object, in many cases persistent, that encapsulates data.

entry action:

An action that is performed on entry into a state. Compare exit action.

ESPLEP:

See Evolutionary Software Product Line Engineering Process (ESPLEP):.

event:

(1) In concurrent processing, an external or internal stimulus used for synchronization purposes; it can be an external interrupt, a timer expiration, an internal signal, or an internal message. (2) On an interaction diagram, a stimulus that arrives at an object at a point in time. (3) On a statechart, the occurrence of a stimulus that can cause a state transition on a statechart.

event synchronization:

Control of concurrent object activation by means of signals. Three types of event synchronization are possible: external interrupts, timer expiration, and internal signals from other concurrent objects.

event trace:

A time-ordered description of each external input and the time at which it occurred.

Evolutionary Software Product Line Engineering Process (ESPLEP):

An iterative software development process consisting of software product line engineering and software application engineering.

exactly-one-of feature group:

A group of features from which one feature must always be selected for a given product line member. Also referred to as one-and-only-one-of feature group.

exit action:

An action that is performed on exit from a state. Compare entry action.

Extensible Markup Language (XML):

A technology that allows different systems to interoperate through exchange of data and text.

external class:

A class that is outside the system and part of the external environment.

external event:

An event from an external object, typically an interrupt from an external I/O device. Compare internal event.

explicit feature:

A feature that can be selected individually for a given application member of the software product line. Compare implicit feature.

family of systems:

See software product line:.

feature:

A functional requirement; a reusable product line requirement or characteristic. A requirement or characteristic that is provided by one or more members of the software product line.

feature-based impact analysis:

A means of assessing the impact of a feature on the software product line, usually through dynamic modeling.

feature/class dependency:

The relationship in which one or more classes support a feature of a software product line (i.e., realize the functionality defined by the feature).

feature/class dependency analysis:

A means of assessing features and classes in order to determine feature/class dependency.

feature group:

A group of features with a particular constraint on their usage in a software product line member.

feature modeling:

The process of analyzing and specifying the features and feature groups of a software product line.

finite state machine:

A conceptual machine with a finite number of states and state transitions that are caused by input events. The notation used to represent a finite state machine is a state transition diagram, statechart, or state transition table. Also referred to simply as state machine.

formal method:

A software engineering method that uses a formal specification language—that is, a language with mathematically defined syntax and semantics.

forward evolutionary engineering:

A software product line engineering strategy that focuses initially on analyzing the kernel of the software product line before proceeding with evolutionary development. Compare reverse evolutionary engineering.

generalization/specialization:

A relationship in which common attributes and operations are abstracted into a superclass (generalized class) and are then inherited by subclasses (specialized classes).

idiom:

A low-level pattern that describes an implementation solution specific to a given programming language.

implicit feature:

A feature that is not allowed to be selected individually. Compare explicit feature.

incremental software development:

See iterative software development:.

information hiding:

The concept of encapsulating software design decisions in objects in such a way that the object's interface reveals only what its users need to know. Also referred to as encapsulation.

information hiding class:

A class that is structured according to the information hiding concept. The class hides an aspect of the system and is accessed by means of operations.

information hiding object:

An instance of an information hiding class.

inheritance:

A mechanism for sharing and reusing code between classes.

integrated communication diagram:

A synthesis of several communication diagrams depicting all the objects and interactions shown on the individual diagrams. In UML 1.x, referred to as a consolidated collaboration diagram.

interaction diagram:

A UML diagram that depicts a dynamic view of a system in terms of objects and the sequence of messages passed between them. Communication diagrams and sequence diagrams are the two main types of interaction diagrams. Compare class diagram.

interface:

The external specification of a class or component; a collection of operations that are used to specify a service of a class or component (Booch et al. 2005).

interface object:

An object that is part of the application and interfaces to the external environment. Also referred to as a boundary object.

internal event:

A means of synchronization between two concurrent objects. Compare external event.

iterative software development:

An incremental approach to developing software in stages. Also referred to as incremental software development.

JavaBeans:

A Java-based component technology.

Jini:

A connection technology used in embedded systems and network-based computing applications for interconnecting computers and devices.

kernel:

The core of a software product line or operating system.

kernel class:

A class that is required by all members of the software product line. Compare optional class and variant class.

kernel component:

A component that is required by all members of the software product line. Compare optional component and variant component.

kernel first approach:

A dynamic modeling approach to determine the objects that realize the kernel use cases and how they interact.

kernel object:

An object that is required by all members of the software product line; an instance of a kernel class. Compare optional object and variant object.

kernel system:

A minimal member of the software product line composed of the kernel classes and any required default classes.

kernel use case:

A use case that is required by all members of the software product line. Compare optional use case and alternative use case.

loosely coupled message communication:

See asynchronous message communication:.

mathematical model:

A mathematical representation of a system.

message buffer and response connector:

A connector object that encapsulates the communication mechanism for synchronous message communication with reply.

message buffer connector:

A connector object that encapsulates the communication mechanism for synchronous message communication without reply.

message dictionary:

A collection of definitions of all aggregate messages depicted on interaction diagrams that consist of several individual messages.

message queue connector:

A connector object that encapsulates the communication mechanism for asynchronous message communication.

message sequence description:

A narrative description of the sequence of messages sent from source objects to destination objects, as depicted on a communication diagram or sequence diagram, describing what happens when each message arrives at a destination object.

middleware:

A layer of software that sits above the heterogeneous operating system to provide a uniform platform above which distributed applications can run (Bacon 1997).

monitor:

A data object that encapsulates data and has operations that are executed mutually exclusively.

multicast communication:

See subscription/notification:.

multiple readers and writers:

An algorithm that allows multiple readers to access a shared data repository concurrently; however, writers must have mutually exclusive access to update the data repository. Compare mutual exclusion.

mutual exclusion:

An algorithm that allows only one concurrent object to have access to shared data at a time, which can be enforced by means of binary semaphores or through the use of monitors. Compare multiple readers and writers.

mutually exclusive feature group:

A feature group from which no more than one feature can be selected for any given software product line member. Compare mutually inclusive feature.

mutually inclusive feature:

A feature that must be used together with another feature. Compare mutually exclusive feature group.

negotiated communication:

A communication approach used in multi-agent systems to allow software agents to negotiate with each other so that they can cooperatively make decisions.

node:

In a distributed environment, a unit of deployment, usually consisting of one or more processors with shared memory.

object:

An instance of a class that contains both hidden data and operations on that data.

object-based design:

A software design method based on the concept of information hiding.

object broker:

See broker:.

object-oriented analysis:

An analysis method that emphasizes identifying real-world objects in the problem domain and mapping them to software objects.

object-oriented design:

A software design method based on the concept of objects, classes, and inheritance.

object request broker:

See broker:.

object structuring criteria:

A set of heuristics for assisting a designer in structuring a system into objects. Also referred to as class stucturing criteria.

one-and-only-one-of feature group:

See exactly-one-of feature group:.

operation:

A specification of a function performed by a class. An access procedure or function provided by a class.

optional class:

A class that is required by some members of the software product line. Compare kernel class and variant class.

optional component:

A component that is required by some members of the software product line. Compare kernel component and variant component.

optional feature:

A feature that is required by some members of the software product line. Compare common feature and alternative feature.

optional object:

An object that is required by some members of the software product line; an instance of an optional class. Compare kernel object and variant object.

optional use case:

A use case that is required by some members of the software product line. Compare kernel use case and alternative use case.

package:

A grouping of UML model elements.

parameterized feature:

A feature that defines a software product line parameter whose value needs to be defined for a given product line member.

part component:

A component within a composite component.

passive I/O device:

A device that does not generate an interrupt on completion of an input or output operation. The input from a passive input device needs to be read either on a polled basis or on demand.

passive object:

An object that has no thread of control; an object with operations that are invoked directly or indirectly by concurrent objects.

performance analysis:

A quantitative analysis of a real-time software design conceptually executing on a given hardware configuration with a given external workload applied to it.

performance model:

An abstraction of the real computer system behavior, developed for the purpose of gaining greater insight into the performance of the system, whether or not the system actually exists.

periodic object:

A concurrent object that is activated periodically (i.e., at regular, equally spaced intervals of time) by a timer event.

PLUS:

See Product Line UML-Based Software Engineering (PLUS):.

port:

A connection point through which a component communicates with other components.

prerequisite feature:

A feature that another feature depends on.

primary actor:

An actor that initiates a use case. Compare secondary actor.

priority message queue:

A queue in which each message has an associated priority. The consumer always accepts higher-priority messages before lower-priority messages.

process:

See concurrent object:.

product family:

See software product line:.

product family engineering:

See software product line engineering:.

product line:

See software product line:.

product line context class diagram:

See software product line context class diagram:.

product line engineering:

See software product line engineering:.

Product Line UML-Based Software Engineering (PLUS):

A design method for software product lines that describes how to conduct requirements modeling, analysis modeling, and design modeling for software product lines in UML.

product line scoping:

See software product line scoping:.

product line system:

See software product line system:.

provided interface:

A collection of operations that specify the services that a component must fulfill. Compare required interface.

provided port:

A port that supports a provided interface. Compare required port.

pseudocode:

A form of structured English used to describe the algorithmic details of an object.

queuing model:

A mathematical representation of a computer system that analyzes contention for limited resources.

Rational Unified Process (RUP):

See Unified Software Development Process (USDP):.

real-time:

Referring to a problem, system, or application that is concurrent in nature and has timing constraints whereby incoming events must be processed within a given time frame.

remote method invocation (RMI):

A middleware technology that allows distributed Java objects to communicate with each other.

required interface:

The services that another component (or object) provides for a given component (or object) to operate properly in a particular environment. Compare provided interface.

required port:

A port that supports a required interface. Compare provided port.

requirements modeling:

A phase of the PLUS object-oriented software life cycle in which the functional requirements of the system are determined through the development of use case models and feature models. Compare analysis modeling and design modeling.

reuse category:

A classification of a modeling element (use case, feature, class, etc.) in a software product line by its reuse properties, such as kernel or optional. Compare role category.

reuse stereotype:

A UML notation for depicting the reuse category of a modeling element.

reverse evolutionary engineering:

A product line engineering strategy that reverse-engineers the software product line functional requirements by analyzing existing systems and then integrating the individual use case models into a product line use case model, before proceeding with evolutionary development. Compare forward evolutionary engineering.

RMI:

See remote method invocation (RMI):.

role category:

A classification of a modeling element (class, object, component) by the role it plays in an application, such as control or entity. Compare reuse category.

role stereotype:

A UML notation for depicting the role category of a modeling element.

RUP:

See Rational Unified Process (RUP):.

scenario:

A specific path through a use case.

secondary actor:

An actor that participates in (but does not initiate) a use case. Compare primary actor.

semaphore:

See binary semaphore:.

sequence diagram:

A UML 2.0 interaction diagram that depicts a dynamic view of a system in which the objects participating in the interaction are depicted horizontally, the vertical dimension represents time, and the sequence of message interactions is depicted from top to bottom.

sequential:

Referring to a problem, process, system, or application in which activities happen in strict sequence; a sequential system or application has only one thread of control. Compare concurrent.

sequential server:

A server that completes one client request before it starts servicing the next. Compare concurrent server.

server:

A provider of services in a client/server system. Compare client.

simple component:

A component that has no components within it. Compare composite component.

simulation model:

An algorithmic representation of a system, reflecting system structure and behavior, that explicitly recognizes the passage of time, hence providing a means of analyzing the behavior of the system over time.

software application engineering:

A process within software product line engineering in which the software product line architecture is adapted and tailored to derive a given software application, which is a member of the software product line. Also referred to as application engineering.

software architectural pattern:

A recurring architecture used in a variety of software applications. Also referred to simply as architectural pattern.

software architectural communication pattern:

A software architectural pattern that addresses the dynamic communication among distributed components of the software architecture.

software architectural structure pattern:

A software architectural pattern that addresses the static structure of the software architecture.

software architecture:

A high-level design that describes the overall structure of a system in terms of components and their interconnections, separately from the internal details of the individual components.

software decision class:

A class that hides a software design decision that is considered likely to change.

software product family:

See software product line:.

software product family engineering:

See software product line engineering:.

software product line:

A family of software systems that have some common functionality and some variable functionality; a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way (Clements and Northrop 2002). Also referred to as family of systems, software product family, product family, or product line.

software product line architecture:

The architecture for a family of products, which describes the kernel, optional, and variable components in the software product line, and their interconnections. Also referred to as domain-specific software architecture.

software product line context class diagram:

A class diagram that defines the hardware/software boundary of a member of the software product line. Also referred to as product line context class diagram.

software product line engineering:

A process for analyzing the commonality and variability in a software product line, and developing a product line use case model, product line analysis model, software product line architecture, and reusable components. Also referred to as software product family engineering, product family engineering, or product line engineering.

software product line evolution approach:

A dynamic modeling approach to determine the objects that realize the optional and alternative use cases and how they interact.

software product line scoping:

An early software product line feasibility study to provide a preliminary estimate of the size of the product line, the degree of common functionality with respect to total product line functionality, the degree of variable functionality in the product line, and a preliminary identification of the potential members of the product line. Also referred to as product line scoping.

software product line system:

A member of the software product line. Also referred to as product line system.

spiral model:

A risk-driven software process model.

state:

A recognizable situation that exists over an interval of time.

statechart:

A UML hierarchical state transition diagram in which the nodes represent states and the arcs represent state transitions. Also referred to as statechart diagram.

statechart diagram:

See statechart:.

state-dependent control object:

An information hiding object that hides the details of a finite state machine; that is, the object encapsulates a statechart, a state transition diagram, or the contents of a state transition table.

state machine:

See finite state machine:.

state transition:

A change in state that is caused by an input event.

state transition diagram:

A graphical representation of a finite state machine in which the nodes represent states and the arcs represent transitions between states.

state transition table:

A tabular representation of a finite state machine.

static modeling:

The process of developing a static, structural view of a problem, system, or software product line.

stereotype:

A classification that defines a new building block that is derived from an existing UML modeling element but is tailored to the modeler's problem (Booch et al. 2005).

subscription/notification:

A form of group communication in which subscribers receive event notifications. Also referred to as multicast communication.

substate:

A state that is part of a superstate.

subsystem:

A significant part of the whole system; a subsystem provides a subset of the overall system functionality.

subsystem communication diagram:

A high-level communication diagram depicting the subsystems and their interactions.

superstate:

A composite state.

synchronous message communication:

A form of communication in which a producer component sends a message to a consumer component and then immediately waits for an acknowledgment. Also referred to as tightly coupled message communication. Compare asynchronous message communication.

synchronous message communication with reply:

A form of communication in which a client (or producer) component sends a message to a server (or consumer) component and then waits for a reply. Also referred to as tightly coupled message communication with reply.

synchronous message communication without reply:

A form of communication in which a producer component sends a message to a consumer component and then waits for acceptance of the message by the consumer. Also referred to as tightly coupled message communication without reply.

system context class diagram:

A class diagram that depicts the relationships between the system (depicted as one aggregate class) and the external classes outside the system.

system context model:

A model of a system or software product line boundary that is depicted on a system context class diagram.

system interface object:

An object that hides the interface to an external system or subsystem.

task:

See concurrent object:.

task architecture:

A description of the concurrent objects in a system or subsystem in terms of their interfaces and interconnections.

thread:

See concurrent object:.

tightly coupled message communication:

See synchronous message communication:.

tightly coupled message communication with reply:

See synchronous message communication with reply:.

tightly coupled message communication without reply:

See synchronous message communication without reply:.

timer event:

A stimulus used for the periodic activation of a concurrent object.

timer object:

A control object that is activated by an external timer.

timing diagram:

A diagram that shows the time-ordered execution sequence of a group of concurrent objects.

transaction:

A request from a client to a server consisting of two or more operations that must be completed in its entirety or not at all.

two-phase commit protocol:

An algorithm used in distributed applications to synchronize updates to ensure that an atomic transaction is either committed or aborted.

UML:

See Unified Modeling Language (UML):.

Unified Modeling Language (UML):

A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system (Booch et al. 2005).

Unified Software Development Process (USDP):

An iterative use case-driven software process that uses the UML notation. Also known as the Rational Unified Process (RUP).

USDP:

See Unified Software Development Process (USDP):.

use case:

A description of a sequence of interactions between one or more actors and the system.

use case diagram:

A UML diagram that shows a set of use cases and actors and their relationships (Booch et al. 2005).

use case model:

A description of the functional requirements of the system or product line in terms of actors and use cases.

use case modeling:

The process of developing the use cases of a system or software product line.

use case package:

A group of related use cases.

user interface object:

An object that hides the details of the interface to a human user.

variability:

The functionality that is provided by some but not all members of the software product line. Compare commonality.

variant class:

A class that is similar to but not identical to another class; a subclass that is similar to but not identical to another subclass of the same superclass. Compare kernel class and optional class.

variant component:

A component that is similar to but not identical to another component. Compare kernel component and optional component.

variant object:

An object that is similar to but not identical to another object; an instance of a variant class. Compare kernel object and optional object.

variation point:

A location at which change can occur in a software product line artifact (e.g., in a use case or class).

visibility:

The characteristic that defines whether an element of a class is visible from outside the class.

Web service:

Business functionality provided by a service provider over the Internet to users of the World Wide Web.

white page brokering:

A pattern of communication between a client and a broker in which the client knows the service required but not the location. Compare yellow page brokering.

whole/part relationship:

A composition or aggregation relationship in which a whole class is composed of part classes.

wrapper component:

A distributed component that handles the communication and management of client requests to legacy applications (Mowbray and Ruh 1997).

XML:

See Extensible Markup Language (XML):.

yellow page brokering:

A pattern of communication between a client and a broker in which the client knows the type of service required but not the specific service. Compare white page brokering.

zero-or-more-of feature group:

A feature group consisting of optional features.

zero-or-one-of feature group:

A feature group in which all features are mutually exclusive.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.21.93.245