Feature

1) A feature is defined as a prominent or distinctive aspect, quality, or characteristic of a product or software system that satisfies one or more requirements.

2) The defined requirements for a product or system are analyzed regarding necessary technology, resources and development methods and compiled into technically oriented work packages. Thus, the stated implementation of one or more requirements in a new or enhanced product characteristic is called a "feature." A feature describes the implementation, enhancement or addition of a product or system characteristic.

Realization Concept

Realization concept includes for example product design specification, ecological concept, feature concept, engineering concept, production/manufacturing concept, logistic concept, service concept, training concept, documentation concept, spare part concept, Product Master Data concept, concept of system architecture, product identification. (PLM)

Requirement (Default
Definition)

1) A condition or capability needed by a user to solve a problem or achieve an objective.

2) A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents.

3) A documented representation of a condition or capability as in (1) or (2).   (CMMI)

Requirements Analysis

The determination of product-specific performance and functional characteristics based on analyses of customer needs, expectations, and constraints; operational concept; projected utilization environments for people, products, and processes; and measures of effectiveness. (CMMI)

Requirements Elicitation

Requirements elicitation means using systematic techniques such as prototypes and structured surveys to identify and document customer and end-user needs proactively. (CMMI)

Requirements Engineering

Requirements engineering involves all lifecycle activities devoted to identification of user requirements, analysis of the requirements to derive additional requirements, documentation of the requirements as a specification, and validation and verification of the documented requirements against user needs, as well as processes that support these activities.
Requirements engineering consists of the topic requirements development and requirements management. (Derived from CMMI)

Requirements Management

The purpose of requirements management is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. (CMMI)
Requirements management contains the topic understanding and commitments to requirements, change management, bidirectional traceability, and the identification of inconsistencies.

Requirements Specification

Product requirements regarding functions, features, quality, performance, documentation, service, qualification; product models, system architecture requirements (corresponding to framework and environment) may include: updated technical discrepancy list. (PLM, enhanced)

Requirements Traceability

The evidence of an association between a requirement and its source requirement, its implementation, and its verification. (CMMI)

Requirements Validation

Requirements validation confirms that the requirements statements are correct, complete, consistent, follow the quality standards, and that they will satisfy customer needs. (Derived from CMMI)

(Equipments) Verification

Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that "you built it right." (CMMI)

Requirements Development

The purpose of requirements development is to produce and analyze customer, product, and product-component requirements. (CMMI)

(Product)
Validation

Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that "you build the right thing." (CMMI)

Requirements Consolidation

The consolidation of redundant or contradictory requirements and their confirmation by the stakeholders.

Requirements Allocation

Assignment of requirements to the next level of refinement.

Stakeholder

1) A "stakeholder" is a group or individual that is affected by or is in some way accountable for the outcome of an undertaking. Stakeholders may include project members, suppliers, customers, end users, and others. (CMMI)

2) Person or group of persons that are affected by the development or deployment of a product in any way.

Stakeholder Requirement/
Stakeholder
Request

A stakeholder requirement is a requirement that has originated from the customer(s) or stakeholders who will be using the system.

Functional Requirement

A requirement that specifies a function that a system or system component must be able to perform. (IEEE610.12 1990)

Non-Functional Requirement

1) A non-functional requirement is any requirement that cannot be derived by examination of a process (for example, use case modeling).
Non-functional requirements can include security, performance, usability, reliability, scalability, testability, maintainability, and constraints.

2) Non-functional requirements specify how and in what quality the functionalities in a system shall be implemented.

Stakeholder Requirements Specification

A document that specifies the requirements for a system/product/service from the point of view of the stakeholders.

System
Requirements Specification

A document that specifies the requirements for a system or component.

Use Case

A use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by developers and end users.

Concrete
Use Case

A set of process steps that are sufficiently well defined that test cases can be generated to verify that a product correctly executes/implements the requirements associated with the use case.

Use Case Model

A use case model is constructed with UML diagrams. It presents system functionality using structural and temporal views from the end user's perspective.

Scenario

A specific sequence of interactions between two or more actors illustrating the external behavior of those actors.
In relation to a use case, a scenario is an instance of a use case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (for example, triggered by options, error conditions, security breaches, and so on). Scenarios may be depicted using sequence diagrams.

Business
Requirement

Describes the benefits of the product for the sponsors, future customers and users

User
Requirement

Describes a goal / task / use case that the user of the system expects to perform.

Depends on at least one business requirement.

System
Requirement

Describes the behavior of a system in the system’s point of view.

Depends on a User requirements

“The system shall …”

Operational Requirement

A non-functional requirement that is related to the productive use of a software system, such as stability, performance, scalability, availability, and security. Operational requirements directly impact the usability and acceptance of a software system. Consequently it is mainly the customers and users of a software system that are interested in, and affected by, the operational properties of a software system. Compare with Developmental Quality.

Developmental Requirement

Non-functional requirements that is related to developing and evolving a software system, such as maintainability, extensibility, adaptability, and reusability. Developmental requirements are typically not visible for a system user, and customers tend not to be interested in them. It is mainly the software development organization that is interested in, and affected by, the developmental qualities of a software system.

Architecturally Significant Requirement

Those requirements that:

• Capture essential functionality of the system
• Have broad coverage; exercise many architectural elements
• Challenge the architecture
• Highlight identified issues/risks
• Exemplify stringent demands on the architecture
  (for example performance requirements)
• Are likely to change
• Involve communication and synchronization with external systems

(Bredemeyer)

System

A collection of software and/or hardware performing one or several services. A system can be a platform, an application, or both.

Backward Tracing

The identification of the source of a requirement, or all other requirements that impact this requirement.

Forward
Tracing

The identification of other requirements or artifacts that are impacted by a requirement.

Horizontal Tracing

The relationship of a requirement to its proof of implementation. The trace bidirectionally connects the requirement to its test cases.

RichTraceability

An advanced form of traceability in which the rationale or satisfaction argument for a set of links is captured, either as a single attribute of the linked requirement or as an additional layer of structured information between layers of requirements.

Vertical
Tracing

Connects project artifacts bidirectionally to their successors. For example, design to code.

Business Case

Business Case = Product Plan (Alan M Davis)

Which features are to be included:

• Target market
• Reachable target market
• Required resources
• Risks for development, sales, meeting schedule and budget
• Number of units sold and price of unit
• Revenue / savings (for improvement projects), cost reduction

Business Case
Analysis

Business Case Analysis considers:

• Costs
• Time to market
• Staff
• Analysis of current situation
• Prediction of future costs and benefits using current approach
• Investment analysis
• Prediction of future costs and benefits using product line approach
• Conclusion

(Bosch)

Business
Types

Product Business
Definition: Marketing of individual products, modules and components. No need for integrating services or customer specific adjustments.

System Business
Definition: Combination of different products.
A certain degree of engineering effort for systems technology. Systems can be used generally; some customer-specific costs.

Project Business / Industrial Systems Business
Definition: Combination of various products and/or systems. Substantial customer specific engineering, project planning, assembly, and startup effort. Extensive know-how is required in the technology of the industry.

Service Business
Definition: Services are usually delineated pragmatically by activities: consulting, financing, project planning, technical engineering/integration, project management, purchasing, logistics, setup/assembly, system startup, training, documentation, operation, repair, service, renovation/modernization, or recycling/disposal.

Solution Business
Definition: Customer-specific, integrated solutions
including services as consulting, design, engineering, systems integration, assembly, startup, finding an operator, etc.(possibly including procurement and integration of standard hardware).

Product
Development

One solution for all customers. The feature set for all customers is always nearly the same, only very little customization is done/possible.

Solution
Development

Individual solutions for each customer.

Economies
of Scale

The condition in which fewer inputs, such as effort and time, are needed to produce greater quantities of a single output. (J. Withey)

Economies
of Scope

The condition where fewer inputs such as effort
and time are needed to produce a greater variety of outputs.

Greater business value is achieved by jointly
producing different outputs. Producing each output independently fails to leverage commonalities that affect costs. Economies of scope occur when it is less costly to combine two or more products in one production system than to produce them separately.
Motivation for product lines

Investment Analysis

A process of estimating the value of an investment proposal to an organization.

Investment analysis involves quantifying the costs and benefits of the investment, analyzing the uncertainties, and constructing a spending strategy. This analysis links the strategic and technical merits of an investment to its financial results.

Costs

Formula per product cost of a core asset:

(Costs to build the core asset / number of products (and versions) in which the core asset is expected to be used ) + costs for building variation mechanisms

Instantiation Costs

Costs for the use of a core asset in a product during product development.

Mass
Customization

The large-scale production of goods tailored to
individual customers' needs.

SMART
targets

S: Specific

M: Measurable

A: Achievable / Action oriented

R: Realistic

T: Time-bounded

Product
Line

A software product line/family consists of base assets, like a product line architecture, reusable components, and processes to build software-intensive products for a narrow scope problem domain. A single product is called a "family member." The difference between the terms "line" and "family" is that "family" already expresses a relationship among the members, whereas members of a line could theoretically be created without any relationship between each other – without any common base assets. (Kircher)

Product
Family

A software product line/family consists of base assets, like a product line architecture, reusable components, and processes to build software-intensive products for a narrow scope problem domain. A single product is called a "family member." The difference between the terms "line" and "family" is that "family" already expresses a relationship among the members, whereas members of a line could theoretically be created without any relationship between each other – without any common base assets. (Kircher)

(Software) Platform

A platform is a core asset of a product family and incorporates those features that are common to all products. (Bosch).

Domain

An area of process or knowledge driven by business requirements and characterized by a set of concepts and terminology understood by stakeholders in that area. The problem domain and the solution domain are two kinds of domains. (Böckle)

Problem
Domain

The world of the customer with their view of a system, their requirements, use cases and scenarios. (Kircher)

Solution
Domain

The world of the software developer, with their artifacts, such as source code, tools, frameworks and domain-specific languages. (Kircher)

Problem
Domain-Solution
Domain
Mapping

In both domains we try to raise the level of abstraction, for example from individual operations to framework operations in the solution domain. This makes the mapping of problem domain to solution domain easier to understand. The usage of self-explanatory identifiers in source code aligns both, but feature models and their mapping into the solution domain allow for easy and explicit reasoning about the dependencies. The hard part – which will always require human reasoning – is the traversal "hop" from the problem domain to the solution
domain.

A common way to traverse from problem to solution domain is to express responsibilities that are grouped and set in relation using CRC cards. This transformation step allows us to acquire an initial structure –the architecture – of the system. (Kircher)

Domain
Model

The domain model of a product line defines the glossary, the entities, their relationships, and key use cases that show how the entities interact with each other. The domain model essentially captures the domain knowledge, which is often considered the core competence of companies or business units operating in a domain. Further, a domain model is the basis for a feature model of a domain.

Asset

Assets can be almost anything: for example documentation, process, tools, test plans, and components. (Kircher)

Product
Asset

An artifact that is part of a product in a product line - not only the deliverables, but every artifact used for producing the product. (SEI)

Core Asset

Any reusable artifact used as the basis for the software product line. A core asset is an asset that is used in all/most products of the product family. It is built to be used in the production of more than one product. A core asset may be architecture, a software component, a process model, a plan, a document, or any other useful artifact used in building a system.

Core assets may be conditional assets, as only a subset of core assets will be implemented in a specific product. (SEI)

Software Engineering

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. (IEEE)

Product Line
Engineering

A paradigm for developing software applications using software platforms and mass customization.
Includes Domain Engineering and Product / Application Engineering. (Böckle)
Provides an architecture that is based on commonality and similarity.

Domain
Engineering

The process of software product line engineering in which the commonality and the variability of the product line are defined and realized. (Böckle)

"Domain engineering" refers to the activities necessary to produce and maintain a software product line, while "application engineering" refers to the activities necessary to produce a concrete product/member of the software product line.
Includes the collection of past experience in building products in a particular domain.
(Czarnecki-Eisenecker)

Application Engineering

The process of producing concrete members of a product family using the reusable assets developed during domain engineering. (Czarnecki-Eisenecker)

COTS

"Commercial-off-the-shelf". This term subsumes components from different sources with different degrees of modification possibilities. Sources may vary from in-house, through nuances of non-develop-mental, to commercial.

Reference
Architecture

A description of the architectural artifacts, mechanisms, and rules on how to derive concrete product architectures. The artifacts can be frameworks, components, or conceptual guidelines, such as patterns. The mechanisms describe how to integrate existing artifacts and create additional ones. The rules describe the constraints and consistency checks to ensure that derived architectures follow the mindset of the reference architecture (Kircher)

Target
Architecture

This is the architecture of the product built with the help of the reference architecture.

Scoping

Showing the context of the system
(context diagram).

Scoping is the process of identifying and bounding the focus of development for reuse in product line development. (Böckle)

Domain
Scoping

In domain engineering: finding commonalities and variabilities of the products in order to define the scope of the platform.

Setting the boundaries of the domain you are addressing with your development. (Böckle)

Application
Scoping

In product engineering: finding the context and boundaries of the product that is member of the product line. (Böckle)

(Core) Asset
Scoping

The process of identifying the various elements that should be made reusable, that is, the specific assets that should be part of the reuse infrastructure, as opposed to being developed specifically for the product. (Böckle)

Commonality-/
Variability
Analysis

In this domain engineering step the set of desired family members (products) is analyzed to identify features that are present in every family member, and features that are optional or have to be adapted for a specific member.

The result of this analysis also shapes the solution domain. It determines the core assets and the necessary level of configuration of the variable assets. The result of the commonality-variability analysis is most commonly documented using feature modeling.

The "how" and "when" of binding the variabilities is crucial to the architecture. Specific infrastructure such as containers or interceptors needs to be provisioned, especially for runtime binding. (Böckle)

The result of the commonality/variability analysis can be documented as a feature model.

Commonality

Features that are present in most members of a product line.

Variability

Assets that are optional or that have to be adapted for a specific member of a product line.

Variability appears in the problem domain and in the solution domain and there must be a mapping between both.

Variation

Variation is the way in which variants can differ from each other (Kircher)

Variation is usually described in general terms, such as the capabilities or properties that the variants have. It is not the mechanism used to implement the variation. (SEI)

Variation Point

A variation point is a location in the product line, where a customization for a specific product can occur (Kircher)

Variant

A variant is one value or instance for this customization (Kircher)

The realization of a variable part of a core asset achieved through exercising its variation
mechanism. (SEI)

Variation
Mechanism

A mechanism to support the creation and/or selection of variants that are compliant with the constraints for a variable part of a core asset.

Examples are:

• Inheritance, strategy patterns
• Component substitution
• Plug-ins
• Interceptor pattern
• Templates
• Parameters
• Generator
• Runtime conditionals
• Configurator (SEI)

Feature
Analysis

Feature analysis is a domain analysis method based on identifying the prominent or distinctive features of a class of products. (SEI)

Product and
Feature Matrix

A matrix that shows the relation between features and products that need that feature. Used to decide which features will be part of a platform. Typical columns titles might be "product1," "product2,"… "product n", "platform release 1." Row titles might be "feature1," "feature2,"... "feature n."

Feature Model

Feature modeling is a method with a notation to elicit and represent common and variable features of a product family.

A feature model can in most cases only be created when the domain is understood well enough, for example when multiple similar products have been built in a domain.

(Kircher)

Feature Graph

A feature graph is a graphical representation of a feature model showing relations between features.

It may use relations of different types like "depends on" "mutually exclusive" "conflicting" and others.
It provides relations among features and not relations of feature to product. The latter is provided by the product feature matrix. (Bosch)

Feature-
Oriented
Domain
Analysis
(FODA)

A domain analysis method based on identifying the prominent or distinctive features of a class of systems. The FODA methodology was founded on two modeling concepts: abstraction and refinement.
Abstraction is used to create domain products from the specific applications in the domain. These generic domain products abstract the functionality and designs of the applications in a domain. The generic nature of the domain products is created by abstracting away "factors" that make one application different than other related applications. The FODA method advocates that applications in the domain should be abstracted to the level where no differences exist between the applications. Specific applications in the domain are developed as
refinements of the domain products. (SEI)

Abstract Class

A class that does not implement all the methods defined in its interface. An abstract class defines a common abstraction for its subclasses.

Abstract
Component

A component that specifies one or more interfaces for other components. An abstract component can either be explicit, such as an abstract class, or implicit, such as a class parameter of a C++ template function. Abstract components form the basis for exploiting polymorphism and implementing flexible systems. This term is used in the same way as abstract class, to avoid restricting patterns to object-oriented languages.

Active
Connection Establishment

The connection role played by a peer application that initiates a
connection to a remote peer. (Compare with Passive Connection Establishment.)

Active Object

An object that executes its methods in a different thread than the
clients that invoke its methods. (Compare with passive object.)

API

Application programming interface. The external interfaces of a reusable software platform, such as an operating system, that is used by systems or applications built on top of it.

Application

A program or collection of programs that fulfills a customer or user's requirements.

Application
Framework

An integrated set of components that collaborate to provide a reusable software architecture for a family of related applications. In an object-oriented environment, an application framework consists of abstract and concrete classes, and inversion of control. Instantiation of such a framework consists of composing and sub classing from existing classes.

Architectural Drift

As the system gets built and (especially) maintained, the system drifts further away from its original intended design/architecture. The architect should control and minimize the gap. Often used as synonym to Design Erosion. Phenomenon of “architectural drift” (Garlan & Allen)

Architectural Pattern

An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Associative
Array

An array indexed via arbitrary key values such as strings, rather than by integers. Hash tables and binary search trees are a common way to implement associative arrays.

Asynchronous I/O

A mechanism for sending or receiving data in which an I/O operation is initiated, but the caller does not block waiting for the operation to complete.

Backus Naur Form (BNF)

A standard technique for describing the syntax of a language.

Bandwidth

The capacity of a communication medium, such as a network or bus.

Broadcast

A special form of multicast in which messages are transmitted to all servers in a particular domain.

Bus

A high-speed communication channel that links computing devices, such as CPUs, disks, and network interfaces.

Busy Wait

A technique used by a thread to wait for a lock by executing a tight loop and polling to see if the lock is available on each iteration, in contrast to waiting for the lock to be released by sleeping and allowing other threads to run.

Cache Affinity

A thread scheduling optimization that gives preference to dispatching a thread on the CPU on which it most recently ran, to maximize the probability of its state being present in the CPUs instruction and data caches.

Callback

A function or object that specifies the action that should occur
whenever a particular event happens.

Class

A fundamental building block in object-oriented languages. A class specifies an interface and encapsulates its internal data structure as well as the functionality of its instances or objects. A class can extend one or more other super classes via inheritance, in which case it is also known as a subclass.

Client

In our descriptions client denotes a role, component, or subsystem that invokes or uses the functionality offered by other components.

Collaborator

A component that cooperates with another component. An element of a CRC card.

Collocation Optimization

A technique used in middleware to remove unnecessary overhead of (de)marshaling data or transmitting requests/replies when the sender and receiver are collocated, that is, when communication occurs in the same process or on the same computer.
(Compare with Distribution.)

Completion Event

An event containing response information related to a request event initiated by a client.

Component

A self-contained, deployable, and executable part of a software system that implements a specific service or set of services to other components or clients. A component has one or more interfaces that provide access to its services. Components serve as building blocks for structuring a system. Although a component is self-contained, it can be composed of, or have dependencies on, other components. At the programming language level, components may be represented as modules, classes, or a set of related functions.

Component Object

An object whose class definition is encapsulated within a deployed component. The interface a component object implements is made up of methods and exposes no implementation. A component
object's class is encapsulated within a component.

Concrete Class

A class from which objects can be instantiated. In contrast to abstract classes, all methods are implemented in a concrete class. The term is used to distinguish concrete subclasses from their abstract superclass.

Concrete Component

A component that implements all elements defined in its interfaces. Used to distinguish components from the abstract component that defines their interface, in the same way that a concrete class is distinguished from an abstract class.

Concurrency

The ability of an object, component, or system to execute operations that are 'logically simultaneous.' (Compare with parallelism.)

Condition Variable

A condition variable is a synchronization mechanism used by collaborating threads to suspend themselves temporarily until condition predicates involving data shared between the threads attain desired states. A condition variable is always used in conjunction with a mutex, which the thread must acquire before evaluating the condition predicate. If the condition predicate is false the thread atomically suspends itself on the condition variable and releases the mutex, so that other threads can change the shared data. When a cooperating thread changes this data, it can notify the condition variable, which atomically resumes a thread that had previously suspended on the condition variable, and acquires its mutex again.

Connection

A full association that is used by peers to exchange data between endpoints of a networked application.

Container

A common name for data structures that hold a collection of elements. Examples of containers are lists, sets, and associative arrays. In addition, component models, such as Enterprise JavaBeans, ActiveX Controls, and the CORBA Component Model, define containers that provide a runtime environment that shields components from the details of their underlying infrastructure, such as an operating system.

CORBA

The Common Object Request Broker Architecture, a distributed object computing middleware standard defined by the Object Management Group (OMG).

CPU

Central processing unit. A hardware component that executes binary program instructions.

CRC Card

Class-Responsibility-Collaborator card. A design tool and notation for describing the responsibilities and collaborators of classes in a software architecture.

Critical
Section

Code that should not execute concurrently in an object or subsystem can be synchronized by a critical section. A critical section is a sequence of instructions that obeys the following invariant: while one thread or process is executing in the critical section, no other thread or process can execute in the critical section. (Compare with Read- side and Write-side Critical Section.)

Data Caches

Special high-speed memory collocated with a CPU that can improve overall system performance. A cache holds a copy of a specific portion of the main memory which then gives an application the illusion of access to the main memory.

Deadlock

A deadlock is a concurrency hazard that occurs when multiple threads attempt to acquire multiple locks and become blocked indefinitely in a circular wait state.

Demarshaling

The conversion of a marshaled message from a system- and application-independent format into a system- and application- specific format.

Demultiplexing

A mechanism that routes incoming events from an input port to its intended receivers. There is a 1:N relationship between input port and receivers. Demultiplexing is commonly applied to incoming events and data streams. The reverse operation is known as 'multiplexing.'

Design

The activities performed by software developers that result in the software architecture of a system. The term is also used as a name for the result of these activities.

Design Erosion

Design erosion is a step-wise violation of the original architecture during the maintenance phase of a software, due to uncontrolled and ad hoc changes of its local design and code. Often used as synonym to Architectural Drift.

Design
Pattern

A design pattern provides a scheme for refining elements of a software system or the relationships between them. It describes a commonly recurring structure of interacting roles that solves a general design problem within a particular context.

Developmental Property

A non-functional property that addresses requirements related to developing and evolving a software system, such as maintainability, extensibility, adaptability, and reusability. Developmental qualities are typically not visible for a system user, and customers tend not to be interested in them. It is mainly the software development organization that is interested in, and affected by, the developmental qualities of a software system. (Compare with Operational Quality.)

Device Driver

A software component in an operating system kernel that is responsible for controlling a hardware device attached to the computer, or a software device, such as a RAM disk.

Distribution

The activities associated with placing an object into a different process or host than the clients that access it. Distribution is often applied to improve fault tolerance or to access remote resources. (Compare with Collocation.)

Distributed System

A distributed system is a computing system in which a number of components cooperate by communicating over a network. The explosive growth of the Internet and the World Wide Web in the mid-1990s moved distributed systems beyond their traditional application areas such as industrial automation, defense, and telecommunications, into nearly all domains, including e-commerce, financial services, health care, government, and entertainment.

Domain

Denotes concepts, knowledge and other items that are related to a particular problem area. Often used in 'application domain' to denote the problem area addressed by an application. On the Internet, a domain is a logical addressing entity, such as uci.edu or siemens.de.

Domain
Analysis

An inductive, feedback-driven process that examines an application domain systematically to identify its core challenges and design dimensions in order to map them to effective solution techniques.

Dynamic
Binding

A mechanism that defers the association of an operation name (a message) to the corresponding code (a method) until runtime. Used to implement polymorphism in object-oriented languages.

Dynamically
Linked
Library (DLL)

A library that can be shared by multiple processes and linked into and out of a process' address space dynamically, to improve application flexibility and extensibility at runtime.

Endpoint

The termination point of a connection.

Event

A message that conveys the occurrence of a significant activity, together with any data associated with the activity.

Event Handler

An object whose interface consists of one or more methods that can process application-specific events.

Exception-Safe

A unit of code is exception-safe if an exception raised in the code, or propagated from other code called by the unit of code, does not cause resource leaks or an unstable state.

Factory

A method or function that creates and assembles the resources needed to instantiate and initialize an object or component instance.

Flow Control

A communication protocol mechanism that prevents a fast sender from overrunning the buffering and computing resources of a slow receiver.

Full
Association

The five-tuple in the Internet protocol domain that identifies a TCPconnection. It consists of the protocol type, the local address and portnumber, and the remote address and port number.

Function

A closed subroutine that is passed zero or more parameters and which may return a value to its caller. Functions are typically 'stand-alone,' as opposed to methods, which are associated with a class.

Functional Property

A particular aspect of a system's functionality, usually related to a specified functional requirement. A functional property may be either made directly visible to users of an application by means of a particular function, or it may represent aspects of its implementation, such as the algorithm used to compute the function.

Future

A future allows a client to obtain the result of a method at any point in time after its invocation. The future reserves space for the invoked method to store its result. When a client wants to obtain the result, it can rendezvous with the future, either blocking or polling until the result is computed and stored in the future.

Gateway

A gateway decouples cooperating components in a network and allows them to interact without having direct dependencies between each other.

GUI

Graphical user interface.

Handle

A handle identifies resources that are managed by an operating system kernel. These resources commonly include network connections, open files, timers, and synchronization objects.

Hardwiring

Writing inflexible programs, for example by using a literal number or string instead of a variable. Such literals are also known as 'magic numbers,' because the number itself provides no clue to understanding its origin or purpose. Another form of hardwiring is to make code dependent on concrete types.