Tm354 (Open University)

Front 1

abstraction

Back 1

The process of describing the essential features of a problem and ignoring other details. It permits you to concentrate on a problem at some level of generalisation, without regard to irrelevant detail. It also permits you to work with concepts, terms and models that are familiar in the problem environment (or domain).

Front 2

acceptance testing

Back 2

The formal testing of an entire system, conducted by a customer, to determine whether it satisfies its acceptance criteria and thus whether the customer should accept the system.

Front 3

action

Back 3

An action is an atomic execution (contrast with activity) that results in a change in the state of the model. In an object-oriented context it can be realised by sending a message to an object or by modifying a link or the value of an attribute.

Front 4

activation

Back 4

On a sequence diagram, a long rectangle, coincident with the lifeline of an object, showing the entire period when an object is active.

Front 5

activity

Back 5

In UML, an activity is an ongoing non-atomic execution (contrast with action) within a state machine or within an activity diagram; in a given context, activities result in one or more actions.In a software development process, it is a unit of work comprising one or more tasks that someone may be asked to perform.

Front 6

activity diagram

Back 6

A representation of a workflow through activity states or action states and in which most or all of the transitions are triggered by completion of an activity in the source states; an activity diagram can be used to represent the workflows within the business domain.

Front 7

actor

Back 7

A representation of users of a software system in a particular role, when interacting with use cases. An actor can also represent the role of an external system that interacts with a software system.

Front 8

adapter

Back 8

A design pattern that addresses the problem of a class having an interface different from the one the client expects.

Front 9

Adapter pattern

Back 9

A design pattern used when a client expects to make calls to a particular interface different from the one that is implemented.

Front 10

aggregation

Back 10

A relationship between an aggregate class and other classes. An aggregate object is an object which can be thought of as being composed of other objects (components), respectively, instances of the other classes. Some authors consider that the objects that are components in one aggregate object cannot be components in another aggregate.

Front 11

agile

Back 11

An umbrella term used to describe a variety of methods that promote a set of practices that encourage simpler, more light-weight, faster and nimbler software development that can adapt to the inevitable changes in customer requirements. The continual realignment of development goals with the needs and expectations of the customer aims at software that better serves its purpose.

Front 12

agile UP

Back 12

A version of UP where the initial disciplines (business/domain model, requirements, analysis and design) are collapsed into a single 'model' discipline and where iterations are short (weeks rather than months) and frequent; product is delivered incrementally if at all possible; design and implementation do not wait until all the requirements are found.

Front 13

ambiguity

Back 13

Open to several interpretations.

Front 14

analysis

Back 14

The term analysis is often used as a generic term for the activities that precede design, the process of eliciting the requirements of a system from the user (requirements elicitation), and then generating the requirements specification document that identifies (among other things) what the software should do (its functional requirements) and the environment in which it must work. In this module we use the term analysis to refer specifically to a set of activities that follow an initial requirements phase: modelling how the structure and behaviour of the system will meet its specification from a user's perspective. (See also requirements, design, implementation and testing).

Front 15

analysis class

Back 15

A class that represents structural elements of an initial software solution. Unlike a concept (a domain class), it may define attributes but operations will be added later during design.

Front 16

analysis model

Back 16

An initial representation of the structure of a software solution by a class diagram; it represents analysis classes, their associations and constraints.

Front 17

analysis pattern

Back 17

A high-level pattern describing a solution at a conceptual analysis level problem.

Front 18

analytical completeness

Back 18

A measure of completeness where only the functional requirements are considered.

Front 19

applet

Back 19

A small Java program that is downloaded from a server and executes in a container consisting of a Java plug-in installed in the client's browser.

Front 20

Application Controller pattern

Back 20

A design pattern which addresses the concerns in the interaction between actors and a system, when the interaction takes place through user interfaces.

Front 21

Architectural pattern

Back 21

Codifies recurrent software architectures by describing the key elements of the architecture and how they fit together. It also describes the qualities of systems that are assembled following the pattern.

Front 22

architectural view

Back 22

A model of the architecture, that captures the concerns of a group of stakeholders of the system.

Front 23

architecture specialisation

Back 23

The process of specialising an architecture by selecting specific components etc.

Front 24

architecture specification

Back 24

The specification of the architecture of a system. It is also the third step in the product line process, where reference architectures are produced.

Front 25

assertion

Back 25

In DbC, a precondition, a postcondition or an invariant.

Front 26

assertion (handling) mechanism

Back 26

A programming construct which, at run-time, allows an assertion to be executed, and alerts the user to an assertion violation. Also referred to as an assertion mechanism.

Front 27

assertion statement

Back 27

A statement of what must be true at a particular point in the execution of a method.

Front 28

association

Back 28

A structural element that describes a set of links, in which a link is a connection between objects. It is a semantic relationship between two or more classifiers that involves the connections among their instances.

Front 29

association class

Back 29

An association that also has class properties. Each instance of the association class defines values for those properties.

Front 30

association loop invariant

Back 30

An invariant showing the relationship between two paths around a loop.

Front 31

assume

Back 31

A condition that a component needs, to operate correctly.

Front 32

asynchronous

Back 32

(communication) When the sender can continue without waiting for an answer from another component.

Front 33

attribute

Back 33

A property of an object which is part of the object's state, and which can be changed. In object-oriented analysis and design, attributes generate accessor methods: one to 'get' the value of the attribute and one to 'set' or 'reset' its value.

Front 34

baseline

Back 34

A configuration version singled out as special because it forms a foundation from which further development can progress, typically associated with the major milestones of a project.

Front 35

basis-path testing

Back 35

A white box testing technique based on the cyclomatic-complexity metric which ensures that all statements in a method are tested at least once.

Front 36

bidirectional association

Back 36

An association that is navigable in both directions.

Front 37

blackboard

Back 37

A variant of a data-centred architectural style in which the store is active and informs users of changes, so that communication may be initiated from either end.

Front 38

black box testing

Back 38

Used to test that each aspect of the customer's requirements is handled correctly by an implementation. Black box testing 'sees' a system through its specification - the specification defines what the system should do and, through black box testing, we make sure it does it.

Front 39

boundary-condition testing

Back 39

Unit testing in which test data are chosen to check that methods perform correctly at the extremities of input ranges.

Front 40

boundary testing

Back 40

A type of black box testing that focuses on producing test data at the boundaries between partitions of the input data space (also know as fence testing).Note that the input data space is simply the set of all values that an input can take, and a partition, also known as a subdomain, is simply a set of input values that require essentially the same processing.

Front 41

bursty event

Back 41

An event coming in sudden and unpredictable clusters overlaying normally low background activity.

Front 42

business event

Back 42

A business event is something that a system must respond to.

Front 43

business process

Back 43

Definition of what gets done in the business: by whom, in what order, needing what and with what consequences.

Front 44

business rule

Back 44

A constraint on how the business is run; that is, a constraint on the business processes.

Front 45

business transaction

Back 45

A significant activity, episode, interaction, in a business.

Front 46

callee

Back 46

Component that receives a procedure call in a call-return architecture.

Front 47

caller

Back 47

Component that makes a procedure call in a call-return architecture.

Front 48

call-return style

Back 48

An architectural style in which one component (the caller) makes a procedure call to another component (often known as the callee) and waits for the call to return.

Front 49

Cascade pattern

Back 49

When designing an interaction diagram to implement a use case, there is a need for an object to send messages to another object with which it does not directly have an association. The Cascade pattern delegates responsibility to another object along a single thread of control (in contrast to the Fork pattern). (See also Law of Demeter.)

Front 50

case analysis

Back 50

When carrying boundary testing, case analysis is the process used to partition test data into subdomains, i.e. sets of input values that require similar processing.Case analysis aids the identification of boundaries between subdomains. At these boundaries, the kind of processing required changes.

Front 51

check(ing) in

Back 51

A part of the configuration management process where a configuration item is returned to the configuration repository after editing, usually with a new version number, and it is made available for others to check out.

Front 52

check(ing) out

Back 52

A part of the configuration management process where a specific version (usually the latest) of a configuration item is removed from the configuration repository so that a developer can edit it.

Front 53

circular dependency

Back 53

A series of two or more dependencies between different things (typically modules within a software system) that form a closed loop. If module A depends on module B which depends on module C, then a circular dependency arises if module C depends on module A.

Front 54

class diagram

Back 54

A diagram that shows a set of classes, interfaces and collaborations, as well as their relationships. It is a representation of a structural (or static) model of a domain or of a system.

Front 55

class invariant

Back 55

A constraint that must be true at all times, other than during when one of its methods is executing. A statement about the values of the attributes of a class that must hold for all instances of that class.

Front 56

class method

Back 56

A method defining how a class responds to a message, rather than how instances of the class respond to messages. (See also instance method.)

Front 57

class model

Back 57

See structural model. A class model is represented in a class diagram.

Front 58

class-responsibility-collaboration cards

Back 58

An approach to identifying classes and their responsibilities using simply structured cards.

Front 59

class variable

Back 59

In Java, a data field declared as static. (See also instance variable.)

Front 60

client

Back 60

In software development, the term refers to the person (or company) who commissions and pays for a piece of software to be developed or to be purchased as a package (in this context the term client is synonymous with the term customer).In programming, the term often refers to the method/class/object that uses the methods of another class/object (the supplier or server).In network programming, the term refers to a program/process running on one computer that can obtain services from a server program running (usually) on another computer.

Front 61

client-server

Back 61

An architectural style in which one component (the server) waits for requests from clients, processes each one as it as received, and returns a response to the client.

Front 62

cloud computing

Back 62

A model in which software runs on remote facilities provided by a third-party supplier.

Front 63

cohesion

Back 63

A way of describing how closely the activities within a single module are related to each other. A cohesive module should, ideally, do just one thing. In software development, high cohesion is preferred to low cohesion as it results in a more flexible software system because each module performs clearly defined operations/tasks.

Front 64

commitment

Back 64

A move of the planning game that decides what to do next.

Front 65

communication diagram

Back 65

A UML interaction diagram that focuses on the structural aspect (instances and links) of an interaction. In previous versions of UML a communication diagram was known as a collaboration diagram.

Front 66

compiler

Back 66

A software tool that translates (compiles) a program written in one language (the source code) into a program in another language and, in so doing, identifies errors in the source code.

Front 67

completeness

Back 67

The degree to which full implementation of the required functionality has been achieved.

Front 68

complexity

Back 68

A complex system consists of a number of parts with a large number of relationships between them. A complex program is one that is difficult to understand.

Front 69

component

Back 69

In general, this refers to an identifiable part of a system. For its use in connection with software systems, see software component.

Front 70

component architecture

Back 70

An architecture specified in terms of components and the connections between them. It can be specialised by selecting appropriate versions of each component.

Front 71

component-based development (CBD)

Back 71

An approach to the development of software by assembling reusable self-contained software components.

Front 72

component collection

Back 72

The fourth step in the product line process where the repository of candidate components accompanying the architecture is gathered together.

Front 73

component selection and specialisation

Back 73

The process of selecting appropriate components for a system and specialising them to the application domain. (See also domain.)

Front 74

composite state

Back 74

A state that contains some internal behaviour, which can be represented with a state diagram. (Also referred to as a compound state.)

Front 75

composition

Back 75

A form of aggregation with strong ownership; component objects of an aggregate have no life after the destruction of the aggregate.

Front 76

computer-aided software engineering (CASE)

Back 76

The use of specialised application programs (tools) that provide some form of automated support during the development of a software system for the benefit of its eventual implementation. Consequently, it includes one or more methods, as well as their accompanying techniques and notations, used for activities such as analysis and design.

Front 77

concept(ual) model

Back 77

The structural model that represents the static part of the domain: the concepts and their relationships.

Front 78

concern

Back 78

Some aspect of the system that is of crucial importance from the point of view of one or more groups of stakeholders.

Front 79

configuration

Back 79

All the modules (components) which together make up an executable software system. It is also a term for the collection of configuration items.

Front 80

configuration item

Back 80

The configuration items are the items produced during the development and maintenance of software, which are stored, retrieved, changed, stored again, and so on. These include: use case diagrams and other UML diagrams; individual Java programs or classes, or the compiled versions of these; architectures and patterns; test plans and test cases.

Front 81

configuration management

Back 81

The task of managing configuration items, which involves identifying the components of a continuously evolving system (the configuration) at discrete points in time, for the purposes of controlling changes to the configuration, and maintaining integrity and traceability throughout the system's lifetime.

Front 82

configuration repository

Back 82

A library of configuration items managed by the configuration management system.

Front 83

configuration version

Back 83

A consistent collection of versions of configuration items.

Front 84

conformance testing

Back 84

Testing that the software product conforms to its requirements.

Front 85

connector

Back 85

An element of an architecture that establishes the communication between components.

Front 86

consistency

Back 86

The property of two descriptions agreeing with each other, that is, not making statements that cannot be simultaneously true.

Front 87

constraint

Back 87

A limitation on or restriction of behaviour, or structure. In UML, a constraint expresses a rule that governs a model element or a combination of model elements.

Front 88

construction

Back 88

In UP, phase when the final product is implemented.

Front 89

constructor

Back 89

Used to initialise a new object. Technically it is not a method, though it is similar in structure. A constructor handles the dual tasks of allocating memory for the new object and ensuring that this memory is properly initialised. The programmer is expected to provide the code that will accomplish this initialisation. If not, a default constructor will be called that has no parameters and performs default initialisations.In Java, a constructor has the same name as the class in which it appears. Constructors are not members; they are never inherited.

Front 90

consumer

Back 90

A client in SOA.

Front 91

container

Back 91

An object (or component) that exists to encompass other objects and provide operations to access or iterate over its contents. In Java EE, a special run time environment that provides components with supporting services (for example, life-cycle management, security, deployment, and run-time services).

Front 92

context dependency

Back 92

A service required by a module in order for it to work.

Front 93

contract

Back 93

A legal document describing the obligations of two parties entering into an agreement; important contract issues include confidentiality and intellectual property rights. In a software project, a contract exists between the customer (client) and developer (supplier) for the provision of a software product. Also, a way of describing what each task, activity or operation commits to achieve by stating the pre- and postconditions. (See also Design by Contract.)

Front 94

controller

Back 94

In the MVC, the controller is the component that handles all user inputs which affect the model.

Front 95

control-structure testing

Back 95

Unit testing in which test data is chosen to check that algorithms are coded correctly and to execute each statement in the code at least once.

Front 96

copyright law

Back 96

The automatic legal protection afforded to an individual or organisation that publishes the expression of an idea, including software.

Front 97

correct

Back 97

A correct system is one that meets all its requirements.

Front 98

coupling

Back 98

A measure of interconnection among modules in a software system. In software development, low coupling is preferred to high coupling as it results in a more flexible software system. (See also encapsulation.)

Front 99

coupling between objects (CBO) metric

Back 99

For a given class, CBO is defined as the number of relationships the class has with other classes. The more relationships a class has, and so the higher the value of this metric, the more difficult it is to understand the use of the given class.

Front 100

critical path

Back 100

A series of activities in a PERT chart which have no slack and therefore must be completed on time to ensure that the project is not late.

Front 101

cultural requirement

Back 101

A non-functional requirement relating to the people involved in the product's development and operation.

Front 102

cyclomatic-complexity metric

Back 102

A measure of the complexity of a method by counting the number of independent paths through a method body.

Front 103

data-centred

Back 103

Architectural style where there is a data provider which is a centralised store of persistent data.

Front 104

data-centred style

Back 104

An architectural style in which there is a centralised data provider, together with a number of clients who are data consumers. If the provider simply responds to client requests it is called a database. A variant in which the data store informs clients when a change occurs is known as a blackboard.

Front 105

data-flow style

Back 105

An architectural style in which each component (called a filter) accepts a stream of data, processes it, and passes the result on to the next filter. A filter has no knowledge of other filters upstream or downstream but simply operates on the data it is given.

Front 106

data lock-in

Back 106

The fact that each cloud service presents users with what is in effect a unique interface, making it difficult for a user to move their data and software from one cloud provider to another, as well as presenting problems in integrating with other systems.

Front 107

data loss

Back 107

The amount of data lost because the system fails to record it.

Front 108

decision nodes

Back 108

In an activity diagram a node that is used to indicate alternative transitions that can be made when leaving an activity; it is represented by a diamond shape. A decision node has a single incoming transition; the guards on outgoing transitions are mutually exclusive.

Front 109

decomposition

Back 109

Splitting a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual. In software we identify a number of different activities or tasks that an individual or a group of individuals might perform. (See also partition.)

Front 110

defect

Back 110

A verified lack of conformance to requirements.

Front 111

defensive programming

Back 111

A design philosophy that says preconditions should always be checked. Each operation is responsible for making sure that it is safe to proceed. The checking is placed very close to the code that depends on it.

Front 112

deliverable

Back 112

An output, such as a design document or source code, of some software development activity whose production gives evidence of the completion of the activity.

Front 113

denial of use of service (or loss of access)

Back 113

Attack consisting of the denial of service to authorised users.

Front 114

dependency injection

Back 114

A Java EE container service that creates and manages an EJB object 'injecting' the necessary references into the client.

Front 115

deployment

Back 115

Configuring code to give a runnable system.

Front 116

deployment model

Back 116

A UML model describing how the components of a system are to be mapped onto different machines and how they will communicate.

Front 117

deployment view

Back 117

The identification of all the nodes that comprise a distributed software system, the components that are stored on each node and the objects that are stored there.

Front 118

depth-of-inheritance-tree (DIT) metric

Back 118

For a given class, this is defined as its number of ancestors. Because of inheritance, a method in the given class can be defined in any of its ancestors. DIT is, therefore, a measure of the number of classes essential to the understanding of the methods of the given class. The deeper a class is in an inheritance tree, and so the higher the value of this metric, the more difficult the class may be to understand.

Front 119

derivation

Back 119

A version of a configuration item based on other configuration items, which might have to be changed if the original item changes.

Front 120

derived association

Back 120

In UML, an association that can be computed from one or more other elements. Although it adds no semantic information, it may aid understanding or be useful for design purposes.

Front 121

derived attribute

Back 121

In UML, an attribute that can be computed from one or more other elements. Although it adds no semantic information, it may aid understanding or be useful for design purposes.

Front 122

design

Back 122

The process of determining how to build an artefact that meets a set of objectives that are normally identified during analysis. It is one of the four basic technical activities within a software development process (see also analysis, implementation and testing).

Front 123

Design by Contract (DbC)

Back 123

The process of developing software based on the notion of contracts between objects, which are expressed as assertions.

Front 124

design decision

Back 124

Decisions taken during design that may impact on the quality of the software eventually produced.

Front 125

design model

Back 125

A representation of the structure of a software solution by a class diagram; it represents classes, their associations and constraints and their responsibilities in terms of operations.

Front 126

design pattern

Back 126

A middle-level pattern describing a solution at a software design level.

Front 127

developmental testing

Back 127

One of the four major types of software testing which checks that developmental activities have been carried out correctly, and ideally is performed by development staff and checked by quality assurance (QA) staff.

Front 128

development process

Back 128

A set of rules that define how a software development project should be carried out. It incorporates a life cycle and involves a number of methods and procedures.

Front 129

diagram

Back 129

In UML, a diagram is a graphical presentation of a collection of model elements.

Front 130

disclosure

Back 130

Attack of private information or the unauthorised release of information.

Front 131

discoverable

Back 131

The property of a service in a service oriented architecture that allows the architecture to identify services on behalf of a consumer. (See also service and service-oriented architecture.)

Front 132

domain

Back 132

An area or field of knowledge characterised by a set of concepts and terminology that is understood by practioners in that area.

Front 133

domain analysis

Back 133

A form of requirements elicitation in which existing systems in the domain are examined and domain experts are consulted.

Front 134

domain expert

Back 134

Someone who is considered to have a considerable level of knowledge or expertise in a given domain.

Front 135

domain model

Back 135

An initial representation of the structure of a domain by a class diagram; it represents domain classes (concepts), and their associations.

Front 136

domain modelling

Back 136

Modelling what already exists.

Front 137

domain-specific knowledge

Back 137

A necessary but not sufficient element of competence made up of knowledge specifically concerned with the particular task or type of application.

Front 138

dynamic model

Back 138

Describes the behaviour of a software system over time.

Front 139

dynamic modelling

Back 139

Modelling of behaviour as opposed to structure.

Front 140

Dynamic Systems Development Method (DSDM)

Back 140

An agile software development method.

Front 141

dynamic tool

Back 141

A tool that is used at run-time.

Front 142

EJB container

Back 142

A run-time environment where EJB components are deployed.

Front 143

elaboration

Back 143

In UP, phase most analysis and design occur.

Front 144

element

Back 144

In UML, an element is an atomic constituent of a model.

Front 145

encapsulation

Back 145

Hiding from the clients of a class the details of how the class is implemented. In other words, it is the process of hiding (making private) all the methods and data fields of a class used in the implementation of the public methods (or interface) of the class.

Front 146

engineering

Back 146

A systematic approach to efficiently developing products which are fit for purpose, based on a body of knowledge.

Front 147

enterprise architectures

Back 147

Software systems designed to meet the business needs of large organisations.

Front 148

enterprise beans

Back 148

Another name for EJB components. They are server-side components, that is to say, they are distributed entities that provide remote services to clients distributed throughout the network.

Front 149

Enterprise JavaBeans (EJB)

Back 149

A component technology, based on the Java programming language. It defines a standard that allows organisations to build their own components or acquire components from third-party vendors.

Front 150

enumeration type

Back 150

A user-defined type with a finite number of literals.

Front 151

error guessing

Back 151

An informal but successful black box testing technique in which the wildest test data that can be thought of is presented to the program unit.

Front 152

ethical decision

Back 152

A decision which may result in a living thing, including its environment, being adversely affected - emotionally, practically or morally.

Front 153

ethical decision making

Back 153

Choosing between behaviour that is morally 'right' and that which is morally 'wrong'.

Front 154

event

Back 154

In a Java system, an event is an action, such as the user clicking on a button; the system will respond to such an event by carrying out certain actions, provided the program defines an appropriate listener object for that event.In operating systems, an event represents a signal to the CPU to interrupt its operation and switch context.In analysis and design, events are elements of state transition diagrams which cause transitions between states.In UML, an event is a specification of a noteworthy occurence that has a location in time and space. There are four kinds of event in UML: call event: the event of receiving a call for an operation that is implemented by actions on transitions; change event: the event of a Boolean expression becoming satisfied because of a change to one or more of the values it references; signal event: an event that is the receipt by an object of a signal sent to it, which may trigger a transition between two states; time event: an event that denotes the satisfaction of a time expression, such as the occurrence of an absolute time or the passage of a given amount of time after an object enters a state.

Front 155

executable assertion

Back 155

An assertion that has been coded and can be executed at run-time.

Front 156

executable documentation

Back 156

Executable documentation is documentation tht allows code to be automatically checked against documention at run time. It should have no effect on program logic, and should be able to be switched on or off globally - so as not to impact performance. Not all aspects of documentation can be checked in this way, but Design by Contract and Test Driven Development are two different systematic approaches to executable documentaion.

Front 157

exploration

Back 157

A move of the planning game that finds out new things that can be done.

Front 158

extension

Back 158

A form of inheritance in which the child class adds functionality to the parent class but does not change any inherited behaviour.

Front 159

extension points

Back 159

A place in the main success scenario of a use case where the condition that triggers a subsidiary use case is tested.

Front 160

external event

Back 160

An event that links a system to its actors, such as the pressing of a button or the sounding of an alarm. (Contrast with internal event.)

Front 161

extreme programming (XP)

Back 161

An agile software development method.

Front 162

factory

Back 162

A specialised object for creating and initialising objects needed by clients.

Front 163

factory method

Back 163

A variant of the Factory pattern particularly useful in the definition of frameworks in which application-specific factories and products can be defined based on the interfaces defined in the framework.

Front 164

Factory pattern

Back 164

A pattern to define a specialised object for the creation and initialisation of other objects.

Front 165

filter

Back 165

Element in a pipe and filter architecture that takes some data and processes it to produce a result.

Front 166

final state

Back 166

In a state diagram, a special mark (bull's eye), with only incoming transitions, indicating where processing terminates.

Front 167

fit criteria

Back 167

Plural of fit criterion.

Front 168

fit criterion

Back 168

A quantification or a measurement of a requirement expressed in a way that allows you to assess whether or not the final product satisfies, or fits, that requirement.

Front 169

fixture

Back 169

The state in place and the data to be used on a test case.

Front 170

flexibility

Back 170

The property of a software system that indicates how easily the system can be modified.

Front 171

foreign key

Back 171

In a database table, a column that holds a key from a different table.

Front 172

fork

Back 172

In activity diagrams, a fork node splits control into multiple parallel flows.

Front 173

Fork (pattern)

Back 173

When designing an interaction diagram to implement a use case, there may be a need for an object to send messages to another object with which it does not directly have an association. The Fork pattern centralises control in the sender (in contrast to the Cascade pattern). (See also Law of Demeter.)

Front 174

formal technical review (FTR)

Back 174

A process to critique a product of the software development process with a view to improving it. The product might be a customer requirements document, a piece of code, or a test or maintenance plan.

Front 175

forward engineering

Back 175

The process, usually automated or semi-automated in a CASE tool, for producing programming language source code from a model. If the code is automatically generated it usually requires additional human input before it is complete and can be machine compiled or interpreted.

Front 176

fragment

Back 176

For our purposes, a way of encapsulating behaviour inside a labelled box. The label can be, for example, opt, alt or loop, standing for optional, alternative and looping behaviour. Sometimes referred to as a frame.

Front 177

framework

Back 177

A collection of classes that together provide behaviour common to a variety of applications. The programmer creates a new application by extending and, perhaps, overriding the behaviour of the classes contained in the framework.Also, the part of an architecture that can be reused.

Front 178

freeware

Back 178

A piece of software that is given away free to users, although the copyright remains with the originator and the original software cannot be distributed by anyone else.

Front 179

freezing

Back 179

A stage in change control where any further changes to a baseline are forbidden, which means disabling further check in operations for the items in the corresponding configuration.

Front 180

functional (or logical) view

Back 180

In a software architecture it describes the system's main functional elements, their responsibilities, interfaces and primary interactions. A functional view is the cornerstone of most architectural descriptions.

Front 181

functional requirement

Back 181

a specified action that a system has to perform

Front 182

further analysis

Back 182

The adding of additional detail to a system specification. In particular, system operations and model constraints.

Front 183

Gantt chart

Back 183

A project management chart named after its originator, the American management consultant Henry Laurence Gantt, in which the horizontal direction represents time and the vertical direction represents activities, and which can be set out as a table, whose rows show when the work takes place, or as a bar chart, whose horizontal bars show when the work takes place. Gantt charts emphasise the times at which things happen.

Front 184

generalisation

Back 184

A relationship between classes in the object-oriented model that captures the fact that one class of objects is more generalised than another, that is, the methods and data fields of the generalised class (superclass) are a subset of the specialised class (subclass).

Front 185

General Responsibility Assignment Software Patterns (GRASP)

Back 185

A collection of patterns which may help the designer assign responsibilities in commonly recurring design scenarios.

Front 186

generic collection

Back 186

In Java, collection types can be parameterised by the type of the objects they contain.

Front 187

glossary

Back 187

A list of terms or words relating to a particular domain or text, along with an explanation of each term.

Front 188

grammatical parse

Back 188

Used in this module to refer to process for obtaining list of nouns from a written problem description to identify candidate classes.

Front 189

GRASP

Back 189

See General Responsibility Assignment Software Patterns.

Front 190

GRASP Creator

Back 190

A pattern that provides guidance on which class should be responsible for creating new objects.

Front 191

GRASP Expert

Back 191

A pattern that provides guidance on which class should be responsible for initialising or changing the state of an object.

Front 192

guarantee

Back 192

A condition that a component promises to other components.

Front 193

guard

Back 193

A condition that must be satisfied in order to enable an associated transition to fire within a state machine or activity diagram.

Front 194

guillemets

Back 194

Angled brackets (<< ...>>) used in UML to show a stereotype. They have other more general uses.

Front 195

hacking

Back 195

In the popular media, the term is synonymous with computer misuse. In the computing community, a hacker is one who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorising about programming.

Front 196

hardware independence

Back 196

The degree to which the software is decoupled from the hardware on which it operates.

Front 197

heroic programming

Back 197

A form of software development where a single person attempts to have in mind everything concerning a given problem and its eventual solution.

Front 198

heuristic evaluation

Back 198

User interface code should always be user tested. However, heuristic testing allows preliminary testing of interaction designs without users. Heuristic evaluation involves analysing interaction designs against recognised checklists for good practice ('heuristics').

Front 199

HTTP (Hypertext Transfer Protocol)

Back 199

A protocol for communication of data in the Web.

Front 200

human factors

Back 200

The discipline that deals with the relationship between people and technology.

Front 201

hybrid cloud

Back 201

A cloud offered by an organisation that combines a private cloud with externally provided cloud services.

Front 202

idiom

Back 202

A pattern that applies within a programming language.

Front 203

ilities

Back 203

Quality attributes, for instance security, reliability, availability, usability etc.

Front 204

implementation

Back 204

The process of building a coherent set of instructions for a computer, that will cause it to exhibit a behaviour specified by the artefacts which are normally devised during design. It is one of the four basic technical activities within a software development process (see also analysis, design and testing).

Front 205

inception

Back 205

In UP, phase when the initial planning of development occurs.

Front 206

inclusion

Back 206

A relationship between two or more use cases, when there is an overlapping area of functionality - that is, a common task - that can be factored out as a distinct use case. The new use case can then be used by each of the original use cases, so avoiding duplication.

Front 207

increment

Back 207

The difference between two releases of a (software) deliverable at the end of successive iterations.

Front 208

incremental development

Back 208

This development approach partitions the system into a number of independent or reasonably independent 'chunks'. The process begins by developing one chunk - the core - and adding successive increments to it over time. A significant point about this method is that the core is a functioning item of software that meets some of the requirements. As each increment is added, the resulting software is still functional.

Front 209

independent components

Back 209

Architectural style where components execute concurrently and are decoupled as far as possible, but can communicate by messages that allow them to exchange data or coordinate their operations.

Front 210

independent components style

Back 210

An architectural style in which components are largely decoupled and execute concurrently, but coordinate with one another or exchange data by means of asynchronous messages.

Front 211

inertial convention

Back 211

The assumption that state components not explicitly described as having changed in a postcondition will remain unchanged by a method call.

Front 212

inheritance

Back 212

The consequence of a generalisation/specialisation relationship; a subclass inherits the features of the superclass.

Front 213

initialisation testing

Back 213

See start-up testing.

Front 214

initial problem statement

Back 214

An initial statement of a problem from which development proceeds. In order to draw up detailed requirements it will usually be necessary to clarify and expand on the information in the initial problem statement during requirements elicitation. (See also requirements elicitation.)

Front 215

initial state

Back 215

In a statechart diagram, an initial state is a way of indicating the default starting state. An initial state is not a true state; it is a marker with only one outgoing transition to the first state an object finds itself on creation. A statechart diagram must show no more than one initial state.

Front 216

instance method

Back 216

A method that describes how a particular operation is carried out by every instance of a class. It contains the code that determines how every instance of a class responds to a particular message. (See also class method.)

Front 217

instance variables

Back 217

A data field that is common to all the objects (instances) of a class but the value of which is specific to each object. This contrasts with a class variable (a data field defined as static in Java), whose fixed value is shared by all the instances of a class.

Front 218

instrumentation

Back 218

The degree to which the system monitors its own operation and identifies errors that occur.

Front 219

integration

Back 219

An activity in which individual software modules or components are combined into an executable whole.

Front 220

Integration and release

Back 220

The process of bringing items together into a unified whole, and then releasing to a customer.

Front 221

integration testing

Back 221

The second stage of developmental testing in which previously tested units are tested together as an integrated whole.

Front 222

integrity

Back 222

in general, the property that data has not been subject to unauthorised change. In particular, a software quality factor affecting product operation requirements which determines the extent to which access to data by unauthorised persons can be controlled, that is, how well the data is secured.

Front 223

interaction diagram

Back 223

A UML diagram that shows the sequencing of messages in an interaction. (See also sequence diagram and communication diagram.)

Front 224

interface

Back 224

In general, this refers to the operations (methods), including their syntax and semantics, that a software system/subsystem/module provides to the clients of the system. In the object-oriented approach, the public operations associated with an object are referred to as its interface, or its interface operations. In Java, an interface is a construct similar to a class, which provides a specification (in the form of method headings but no implementation) of the methods for which classes implementing the interface must provide implementations.

Front 225

interface testing

Back 225

Unit testing in which test data is chosen to check that the flow of information into and out from an object of the class is correct. Also a form of system testing, in the case where the system communicates with other systems in the outside world, that tests its interaction with the communication system; in this context it is also referred to as protocol testing.

Front 226

internal event

Back 226

An event that links the objects within a system, such as the throwing of a language exception. (Contrast with external event.)

Front 227

internal transition

Back 227

A special transition that does not involve a change of state. An internal transition does not cause the execution of any entry or exit actions.

Front 228

interoperability

Back 228

A software quality factor affecting product transition requirements which determines the effort required to couple one system to another, that is, how easy it is to interface the system with another, should the customer require it.

Front 229

invariant

Back 229

See class invariant.

Front 230

iteration

Back 230

A distinct sequence of activities within a life cycle that may be repeated. Within a development process, the result is a (software) deliverable that conforms to certain criteria.

Front 231

iteration planning game

Back 231

A planning game for an iteration, played even more frequently, on tasks instead of stories; the players are the programmers.

Front 232

iterative and incremental development

Back 232

This development approach starts with a subset of the requirements and incrementally grows the system with further increments. Each increment is developed over several iterations; an iteration is a complete small project, with a short timeframe, consisting of analysis, design, implementation, testing and integration, and results in a partially working system.

Front 233

iterative development

Back 233

This development approach continuously repeats a set of activities improving the outputs each time at the feedback received from a previous iteration.

Front 234

Java Enterprise Edition (Java EE)

Back 234

A framework for constructing enterprise systems.

Front 235

java platform, enterprise edition

Back 235

See Java Enterprise Edition.

Front 236

jitter

Back 236

The amount of variation in latency, for example, are some responses very quick but others take much longer?

Front 237

join

Back 237

In activity diagrams, a join node synchronises multiple parallel flows.

Front 238

lack-of-cohesion-in-methods (LCOM) metric

Back 238

The number of pairs of methods that make reference to the same attributes minus the number of pairs of methods that do not; or zero should this be negative. In highly cohesive classes, methods will manipulate the same attributes.

Front 239

latency

Back 239

The time taken to process a stimulus, for example, how long does a search engine take to respond to a query?

Front 240

Law of Demeter

Back 240

A design principle governing the flow of messages among objects. It says that in response to a message m, an object O should send messages only to the following objects:O itself;objects that are sent as parameters to the message m;objects that O creates as part of its reaction to m;objects that are directly accessible from O (using values of the attributes of O).

Front 241

law of patents

Back 241

The law that relates to the protection of inventions.

Front 242

layer

Back 242

A logical partitioning of a system.

Front 243

layered architecture

Back 243

An architecture organised using a Layers pattern.

Front 244

layered style

Back 244

An architectural style in which the system is structured as a series of layers, each layer communicating only with the layers immediately above and below it.

Front 245

Layers pattern

Back 245

This organises the large-scale functional structure of a system into discrete layers of distinct, related responsibilities, with a clear separation of concerns between the layers.

Front 246

legacy system

Back 246

An old software system that is still required because it meets some useful purpose to an organisation. It is not considered to be replaceable and so it is maintained, usually on a restricted budget.

Front 247

legal contract

Back 247

A legal contract sets out the parameters of an agreement in a legally binding way. Breaking such a contract can result in legal action being taken.

Front 248

legal requirement

Back 248

A non-functional requirement about laws and standards that apply to the product.

Front 249

life cycle

Back 249

The sequence in which a number of different activities are carried out to define an overall process for the development of a software system.

Front 250

lines-of-code (LOC) metric

Back 250

A very simple measure of the complexity of a system description is given by counting the number of lines in a piece of code.

Front 251

link

Back 251

An instance of an association that shows a semantic connection between objects.

Front 252

location transparency

Back 252

In a service-oriented architecture (SOA) it allows consumers to make use of the service without being aware of where the service is actually located, i.e. on which machine or even in which business organisation. The requester of the service and the service itself are only loosely bound; in particular, the requester has no knowledge of the service implementation or its platform, and they only communicate through messages. It is also possible for components to be location transparent and be invoked using a logical name rather than a physical address.

Front 253

locator

Back 253

See registry.

Front 254

look and feel requirement

Back 254

A non-functional requirement about the product's appearance.

Front 255

loop

Back 255

See fragment.

Front 256

loop fragment

Back 256

See loop.

Front 257

loop testing

Back 257

A white box testing technique that is used to test loop constructs to ensure they execute the right number of times.

Front 258

mailbox semantics

Back 258

A way of getting two active objects to communicate. The sender sends a message and then carries on processing, regardless of what the receiver is doing. The receiver, working at its own speed, can then read waiting messages and process them.

Front 259

maintainability

Back 259

This is a software quality factor affecting maintainability and portability requirements, which determines the effort required to understand, locate and fix errors in a system, that is, how easily bugs can be found and fixed.

Front 260

maintainability and portability requirement

Back 260

A non-functional requirement about expected changes to a system and allowed time to make them.

Front 261

maintenance

Back 261

An activity in which the artefacts or products of a software development process are changed. It includes all changes made to a software system after it has been released.

Front 262

major defect

Back 262

A defect which, if not corrected, would either cause a malfunction or prevent the attainment of a required result.

Front 263

malleability

Back 263

Characteristic of software as being easy to change. Malleability creates a constant pressure for software to be changed rather than be replaced. Every change that is made to the software introduces the possibility of new errors.

Front 264

Mean Time To Change (MTTC)

Back 264

The average of the time it takes to analyse a bug report, design an appropriate modification, implement the change, test it, and distribute the change to all users. In general, the lower the MTTC (for equivalent types of changes), the more maintainable the software product is.

Front 265

merge node

Back 265

In an activity diagram, this is a node that brings together multiple alternative flows; represented by a diamond shape; a merge node has a single outgoing transition.

Front 266

message-driven beans

Back 266

EJB beans that support asynchronous processing through message passing.

Front 267

message number(ing)

Back 267

A means of identifying the ordering of messages in a flow of control. On an interaction diagram, the messages may proceed in a nested or hierarchical fashion. Ambiguity in the message flow is removed by using a multi-stage decimal for each message in an interaction. Thus each message always contains as its prefix the number of the message that gave rise to it. If an object receives a message prefixed 2.6, all messages it sends until it has finished processing 2.6.1, 2.6.2 and so on (this is known as decimal message numbering).

Front 268

method

Back 268

In object-oriented terminology, it is an operation that manipulates an object in some way.In Java, a method is a member of a class and has a method heading (which incorporates its signature) and a method body.In software development, it is a collection of integrated techniques, with their associated notations and rules, that takes a set of predefined inputs and converts them to a set of predefined outputs.

Front 269

milestone

Back 269

In project management, the points where key deliverables are completed, reviewed and then frozen.

Front 270

minor defect

Back 270

A defect which, if not corrected, would neither cause a malfunction nor prevent the attainment of a required result.

Front 271

miss rate

Back 271

Measures the proportion of events that are not responded to.

Front 272

model

Back 272

A simplification of reality, created in order to understand an aspect or viewpoint of the system being created. In the MVC, the model the component that does the processing.

Front 273

modelling

Back 273

A way of thinking about things and ideas in the real world. A model is a way of expressing a particular view of an identifiable system.

Front 274

modelling language

Back 274

A way of expressing the various models produced during the development process. A modelling language defines a collection of model elements, which are roughly equivalent to the utterances in a spoken language. (A model is made up of model elements, as sentences are made up of words.) UML is a modelling language.

Front 275

Model-View-Controller (MVC) pattern

Back 275

Describes a high-level solution to the general problem of human-computer interaction, relating what the user sees on a screen and does with a keyboard, mouse or other interaction device, to the functions of an application and the data that it stores. The 'model' is the internal workings of the program, the 'view' is how the user sees the state of the model and the 'controller' is how the user changes the state or provides input. Whenever some input through a controller changes the primary data of the model, the model then informs all views and all controllers so that they in turn can update their representation of the data.

Front 276

modifiability

Back 276

See flexibility.

Front 277

modification (or loss of integrity)

Back 277

Attack consisting of the unauthorised modification of data.

Front 278

modularisation

Back 278

See modularity.

Front 279

modularity

Back 279

The division of a software system into separately named and addressable components, called modules, that are integrated to meet the requirements. Modularity is a basic attribute of software that allows the partition of a set of requirements into a number of intellectually manageable subsets.

Front 280

module

Back 280

A program unit (or component) that is used exclusively through an external interface. It is important for enabling a system to be comprehended at any required level of detail. A software system is a collection of modules.

Front 281

morality

Back 281

The degree of conformity to a set of principles that determine 'rightness'.

Front 282

MoSCoW

Back 282

A scheme in DSDM classifying requirements into Must have, Should have, Could have, and Won't have.

Front 283

multiplicity

Back 283

A specification of how many objects of one class are related to one object of another class.

Front 284

namespace

Back 284

A boundary within which names are unique.

Front 285

navigability

Back 285

Refers to the ability to traverse one or more associations to obtain the object or set of objects associated with an instance of a class through those associations.

Front 286

navigation expression

Back 286

A description of the path taken to traverse the links (corresponding to one or more associations) from one object to another object (or set of objects) or to its (or their) attributes.

Front 287

non-deterministic

Back 287

A situation where one of a number of outcomes is possible, for example when throwing a dice.

Front 288

non-functional requirement

Back 288

A quality that a system must have.

Front 289

notification

Back 289

See publish-subscribe.

Front 290

notification style

Back 290

An architectural style in which one kind of component, the observer, registers itself with another component, the subject, in order to be notified when some particular event occurs at the subject's end.

Front 291

number-of-children (NOC) metric

Back 291

For a given class, NOC is defined as the number of children for that class. This metric is a measure of the number of classes that will be affected by changes to a given parent class.

Front 292

Object Constraint Language (OCL)

Back 292

A text language for specifying constraints, Boolean expressions and queries. OCL can be used to construct expressions for constraints, guards, actions, preconditions, postconditions and assertions. OCL is part of UML.

Front 293

object diagram

Back 293

An instance of a class model that shows objects (possibly value of attributes) and their links at a point in time.

Front 294

object model

Back 294

A collection of objects and their links, where every object in the model is an instance of a class, and each link is an instance of an association in the corresponding class model. An object model is represented by an object diagram.

Front 295

observable

Back 295

In the Observer pattern the object, also called the subject, that keeps objects registered with it informed when its state changes.

Front 296

observer

Back 296

In the Observer pattern objects register themselves with a Observable, in order to receive notifications when the latter's state changes.

Front 297

Observer pattern

Back 297

A design pattern that addresses the issue of supporting dependencies between objects, whilst keeping coupling low.

Front 298

OCL

Back 298

See Object Constraint Language.

Front 299

open-source software

Back 299

Similar to freeware, except that it is maintained and upgraded openly by a community of expert users; code can be modified.

Front 300

operability

Back 300

The ease of operation of a program.

Front 301

operation

Back 301

See method.

Front 302

operational and environmental requirement

Back 302

A non-functional requirement about how the environment on which the product will have to work (under water, for example), and what considerations must be made for this environment.

Front 303

operator testing

Back 303

See user-command testing.

Front 304

opt

Back 304

See fragment.

Front 305

optional fragment

Back 305

See opt.

Front 306

oracle

Back 306

The criteria in a test case that helps define whether the test is passed.

Front 307

organisational units

Back 307

The groups to which people belong.

Front 308

package

Back 308

UML employs the concept of a package to enable the developer to modularise a given system or part of that system. A model comprises a set of packages that hold model elements, such as classes and use cases. A package may contain other packages.

Front 309

partition

Back 309

The decomposition of a problem into a number of subproblems that are independent of each other.

Front 310

partitioning

Back 310

This black box testing technique focuses on producing test data at the boundaries between partitions of the input data space (or input domain). Partitioning is based on the observation that common errors are often caused by a data item being just one out, or a loop being executed one too many or one too few times, for example; such errors are most visible at the boundaries of the input data space. (Also referred to as equivalence partitioning.)

Front 311

path parameter

Back 311

Part of a path to be replaced by the corresponding element in the actual URI the client uses when making a request.

Front 312

peer-to-peer

Back 312

An architecture where there is no clear distinction between clients and servers.

Front 313

peer-to-peer style

Back 313

An architectural style in which all components are both clients and servers and any component can request services from any other component.

Front 314

performance

Back 314

The ability of a system to process service requests.

Front 315

performance requirement

Back 315

A non-functional requirement about how fast, how safe, how accurate, how available and how reliable the product must be.

Front 316

performance testing

Back 316

System testing that tests that the system meets all specified operating requirements for speed, number of concurrent users permitted, etc.

Front 317

PERT chart

Back 317

A project management chart in which PERT stands for Project (or Program) Evaluation and Review Technique. It shows the activities as boxes with lines joining them to indicate the interdependencies and the flow of critical information. PERT charts emphasise interdependencies and allow critical path analysis.

Front 318

pipe

Back 318

Element in a pipe and filter architecture that is a conduit along which the data flows.

Front 319

pipes and filters

Back 319

An architecture where filters are the elements that take some data and process it to produce a result, and pipes are the conduits along which the data flows. Also known as data-flow.

Front 320

placeholder

Back 320

Used in this module to refer to the name of a type that is being used as a stand-in until there is sufficient information to make an informed decision.

Front 321

plan-driven development

Back 321

Term used to distinguish traditional, more prescriptive approaches to software development from agile development approaches.

Front 322

planning

Back 322

The first stage of a formal technical review.

Front 323

Planning Game

Back 323

An XP practice with two participants, the business and the development. This game takes place not only at the beginning of the project but at regular intervals (say every three weeks) to determine the priorities and work for the next release and to define a plan. It is played with story cards. (See iteration planning game.)

Front 324

polymorphism

Back 324

In object oriented programming, when a program specifies that some message is to be sent to some object, it is not always possible at compile time to determine which of several candidate methods should correspond to the message. This is because, for inheritance or other reasons, there may be several classes of object with a common interface, and the identity of the class of the receiver may not be determined till run time.Such a message is said to be polymorphic.

Front 325

portability

Back 325

A software quality factor affecting product transition requirements which determines the effort required to transfer the system from one hardware platform and/or software environment to another, that is, how easily the system can be used on another machine should the customer change their platform or should other customers require it.

Front 326

postcondition

Back 326

A constraint that must be true at the completion of an operation, or use case.

Front 327

precondition

Back 327

A constraint that must be true when an operation is invoked, or when a use case is carried out.

Front 328

predefined type

Back 328

A data type that is provided by a programming or a modelling language and available to the developer. Examples are data types for numbers, strings and collections.

Front 329

preferred version

Back 329

In configuration management, the default version which is checked out, usually the latest.

Front 330

presentation layer

Back 330

In a layered architecture, the layer concerned with the user interface.

Front 331

primary key

Back 331

In a database table, a column that uniquely identifies each row of the table.

Front 332

private cloud

Back 332

A cloud that belongs to a particular organisation, usually one large enough to generate economies of scale internally.

Front 333

problem domain

Back 333

See domain.

Front 334

procedure

Back 334

In general, a procedure is a prescribed set of steps for carrying out a task. In programming, it refers to a block of code that carries out a specified programming task and may or may not have input and output parameters. In object-oriented systems, methods are used to implement procedures.

Front 335

process

Back 335

In program execution, a process is a dynamic (abstract) entity that executes a program on a processor. It is associated with resources such as a main memory and files. In this context, processes are also sometimes referred to as tasks.In software development, a process is a set of activities or operations that takes one or more inputs, such as a design document, and results in one or more products, such as a software module and its test cases.

Front 336

process improvement

Back 336

The idea that an organisation should learn from difficulties encountered with their existing processes, and improve as a result.

Front 337

process model

Back 337

See life cycle.

Front 338

process-related human factors

Back 338

Factors affecting the performance of a software engineer which arise either from the characteristics and skills of the engineer or are external influences that have an impact on how effectively they can apply themselves to the task. They include person-related human factors, task-related human factors, and environment-related human factors.

Front 339

process view

Back 339

In a system architecture, this view addresses concurrent aspects of the system at run-time, including all system processes and system start-up and shut-down.

Front 340

product

Back 340

In the Factory design pattern the object the factory produces.

Front 341

product backlog

Back 341

An artefact in Scrum (an agile method) that consists of an ordered structured list of what needs to be done to a system.

Front 342

product line

Back 342

A set of related software products for different customers, reusing major parts of the software from customer to customer, with only those parts peculiar to the particular customer being different.

Front 343

product-line initiation

Back 343

This is the first step in the product line process, where it is recognised that there is a class of commonly recurring software systems where solutions do not differ much from each other.

Front 344

product operation requirements

Back 344

How a product will be used

Front 345

product-related human factors

Back 345

The human factors involved in the people-technology relationship.

Front 346

product revision requirements

Back 346

How a product will be maintained.

Front 347

product transition requirements

Back 347

How a product will be modified for different operating environments.

Front 348

profession

Back 348

A form of employment, esp. one that is possible only for an educated person and after training (such as law, medicine or teaching) and that is respected in society as honourable.' (Longman Dictionary of Contemporary English, 1987.)

Front 349

project management

Back 349

The activity concerned with ensuring that a software project is completed within the estimated time. It involves determining the work involved, assigning work units to people or teams for periods of time, and giving a work plan for the project.

Front 350

project plan

Back 350

A plan breaking down the development of a system into stages and showing how much resource is required at each stage.

Front 351

protocol testing

Back 351

See interface testing.

Front 352

prototype

Back 352

A simplified software system that is a subset of the eventual product.

Front 353

prototypical interaction

Back 353

An interaction described using some prototypical objects.

Front 354

prototypical object

Back 354

An object representing the general case rather than a specific instance.

Front 355

provided interface

Back 355

The set of operations a component makes available to other components.

Front 356

provider

Back 356

In SOA the platform on which a service is implemented.

Front 357

public cloud

Back 357

A cloud such as Amazon EC2 or Google App Engine which is available to anyone willing to purchase the service.

Front 358

public-domain software

Back 358

Similar to freeware except that the originator has signed away the copyright. This means that users can modify the software, redistribute it or incorporate it into their own work.

Front 359

publisher

Back 359

Component, in a publish-subscribe architecture, that notifies other components of updates.

Front 360

publish-subscribe

Back 360

Architectural style where subscribers register to receive updates (often messages) whenever a publisher posts a new item.

Front 361

qualified association

Back 361

An association that uses attributes of one class to partition the set of objects related to an object across the original association; those attributes are the qualifier of the assocation.

Front 362

quality attribute

Back 362

See non-functional requirement.

Front 363

quality attribute scenario

Back 363

A tool which allows specification of non-functional requirements in a more precise and detailed form which can be used to help make architectural decisions.

Front 364

quality management

Back 364

An activity that takes place throughout the software development process to ensure the quality of the final product.

Front 365

quality management system (QMS)

Back 365

An organisation-wide mechanism for building quality into projects and for managing the quality control process. Consists of the managerial structure, responsibilities, capabilities and resources that ensure that software products developed by projects will have the qualities desired by both the customer and the developer.

Front 366

quality manual

Back 366

A document containing quality standards, guidelines and procedures.

Front 367

quality plan

Back 367

A document specifying the quality controls for a project.

Front 368

Quantity pattern

Back 368

A pattern which provides useful guidance on how to represent dimensioned quantities, that is, values plus their units of measurement.

Front 369

random testing

Back 369

A black box testing technique in which test data is randomly generated within the input data space.

Front 370

realisation

Back 370

An implementation of an interface.

Front 371

record

Back 371

A row of a database table.

Front 372

recursive

Back 372

A recursive association is one between a concept/class and itself.

Front 373

refactoring

Back 373

The reorganisation of code structure for reasons such as clarity or maintainability, while making no change to the external behaviour.

Front 374

registry

Back 374

A mechanism that allows clients to find services.

Front 375

regression testing

Back 375

One of the four major types of software testing, which occurs during developmental testing and system maintenance, and which checks that fixing one bug has not introduced others.

Front 376

release

Back 376

A configuration version delivered on completion of the project for use by the customer.

Front 377

reliability

Back 377

A software quality factor affecting product operation requirements which determines the likelihood with which a system can be expected to perform its intended function, that is, how well the software does what it is supposed to do.

Front 378

rendezvous semantics

Back 378

A way of getting two active objects to communicate. The sender indicates a desire to talk and the receiver indicates a desire to listen. Whichever of these happens first causes that thread to block until the other has happened, at which point communication takes place.

Front 379

repository

Back 379

Centralised store of persistent data in a data-centred architecture.

Front 380

repudiation

Back 380

Attack consisting of (false) claim by legitimate user that a message was not sent or received.

Front 381

required interface

Back 381

The set of operations a component needs from other components.

Front 382

requirement

Back 382

A desired feature, property or behaviour of a software system.

Front 383

requirements

Back 383

See requirements engineering.

Front 384

requirements analysis

Back 384

An activity undertaken to decide what needs to be done to solve the problem that has been articulated during requirements elicitation. The result is a deliverable that forms the basis for a solution to be implemented. It is expressed in technical terms that are understandable to the developers.

Front 385

requirements-based testing

Back 385

One of the four major types of software testing which checks that a system meets the customer's requirements, and is carried out by QA staff in conjunction with the customer.

Front 386

requirements documentation

Back 386

An activity undertaken to record agreed requirements.

Front 387

requirements elicitation

Back 387

An activity undertaken to discover, identify, review, articulate and understand the users' needs and constraints on the software and its development. The result is a clear statement of the problem to be addressed.

Front 388

requirements engineering

Back 388

An activity in the process of developing software that aims to elicit and specify the requirements of the client(s)/user(s) in a form that can be used in the design of the software and in assessing its quality once it is built. It can be divided into two main activities: requirements elicitation and requirements analysis.

Front 389

requirements negotiation

Back 389

An activity undertaken to agree requirements.

Front 390

Requirements pattern

Back 390

A description of knowledge used in the elicitation of requirements.

Front 391

requirements specification

Back 391

A detailed description of the requirements for a system.

Front 392

requirements validation

Back 392

A careful check of a requirements document, usually following a checklist.

Front 393

resource balancing/levelling

Back 393

The process of juggling the assignment of resources to activities over time so that each resource is used at its capacity, and each activity receives the resources that it needs.

Front 394

response-for-a-class (RFC) metric

Back 394

For a given class, RFC is defined as the size of the response set for the class. Classes with high values for this metric will be more difficult to understand than classes with low values.

Front 395

response set

Back 395

All the methods of a class, including those inherited, and those it invokes.

Front 396

restart testing

Back 396

System testing that tests the ability of the system to recover from errors of internal state.

Front 397

RESTful

Back 397

A web service that uses a uniform interface consisting only of a set of standard methods which are always the same for every service.

Front 398

reusability

Back 398

A software quality factor affecting product transition requirements which determines the extent to which a system (or system component) can be reused in other applications, that is, how easy it is to reuse some of the software to make future developments more cost-effective.

Front 399

reverse engineering

Back 399

The process, usually automated or semi-automated in a CASE tool, for deriving a model from source code alone.

Front 400

review

Back 400

A software inspection meeting to confirm and list major defects, and to determine who will be responsible for addressing each defect.

Front 401

risk management

Back 401

Analysis of risks in a development process and determination of steps to reduce them.

Front 402

robustness

Back 402

The degree of immunity from damage when a program encounters an error. Also referred to as error tolerance.

Front 403

role

Back 403

The behaviour of an entity participating in a particular context. It may also refer to the behaviour of people in a domain.

Front 404

role name

Back 404

The identification of a specific role for a class in a given association.

Front 405

scenario

Back 405

A specific sequence of actions that illustrates how a task can be performed. It is also a textual description of a specific instance of a use case or interaction with a user interface.

Front 406

Scrum

Back 406

An agile software development method.

Front 407

security

Back 407

A term used in connection with controlling access to the data stored in computers and in connection with the availability of mechanisms that control or protect programs and data.

Front 408

security requirement

Back 408

A non-functional requirement concerned with aspects of a product such as security and confidentiality.

Front 409

security testing

Back 409

System testing that tests that the system does not offer opportunities to breach security.

Front 410

self consistency

Back 410

System descriptions are said to be self consistent if they make no self contradictory statements.

Front 411

self-documentation

Back 411

The degree to which the source code of a program provides meaningful documentation.

Front 412

self-transition

Back 412

In a state machine, this is a transition that originates in one state and returns to the same state. They are commonly used to model loops or cycles.

Front 413

sequence diagram

Back 413

A UML interaction diagram that focuses on the time-ordering of the messages.

Front 414

server

Back 414

See supplier.

Front 415

service

Back 415

A unit of reuse corresponding to a piece of functionality, described in a standard language, with published interfaces through which the service execution can be requested.An abstract description of some unit of business functionality, usually described in terms that are meaningful from both a business and a technical perspective. (See also service-oriented architecture.)

Front 416

service consumer (or consumer)

Back 416

Component accessing a service.

Front 417

service description

Back 417

Specifies how a consumer can interact with a service.

Front 418

service level agreement (SLA)

Back 418

A statement of the assume-guarantee contract of the cloud service.

Front 419

service orchestration

Back 419

Coordination of services invocation.

Front 420

service-oriented architecture (SOA)

Back 420

SOA is an approach to build enterprise systems that deliver application functionality either as services to end-user applications or to build other services. In this approach, services are software assets, which are described and interact in a standard way, so that the focus of application development is the assembly of services as building blocks.

Front 421

service-oriented cloud computing architecture (SOCCA)

Back 421

An architecture to address the integration of the principles of SOA with those of cloud computing.

Front 422

service-oriented style

Back 422

An architectural style in which set of service providers makes services available to a set of service consumers. Consumers can combine services in order to carry out business processes.

Front 423

service provider (or provider)

Back 423

Component implementing a service.

Front 424

service registry (or registry, or locator)

Back 424

Allows a consumer to find a service.

Front 425

service requester (or requester)

Back 425

See service consumer.

Front 426

session beans

Back 426

A session bean represents a single client inside the application server. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server.

Front 427

shareware

Back 427

Software that is intended to be trialled for a limited period (often 30 days). Users are expected to register and pay any appropriate fee after this time has elapsed.

Front 428

signature

Back 428

In general, the combination of name, parameters and return type of an operation. In Java, the combination of name and formal parameters in a method heading (that is, excluding method's return type).

Front 429

simple state

Back 429

A state that contains no substructure. (See also composite state.)

Front 430

singleton

Back 430

A design pattern used where there should be only one instance of a class.

Front 431

Singleton pattern

Back 431

A pattern to ensure that a class has only one instance, and to provide a global point of access to it.

Front 432

size (of software)

Back 432

This can be measured in terms of lines of code, number of symbols, size of source or object files etc.

Front 433

snapshot

Back 433

A representation (using a UML object diagram) of objects and their links at a certain instant in time.

Front 434

socio-technical systems

Back 434

A system seen as a whole, including the software, the hardware where it is installed and running, and the wider context that involves other technical components, but also people, organisations and other social structures.

Front 435

software architecture

Back 435

... the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.' (Bass, Clements and Kazman, 2012.)

Front 436

software component

Back 436

In the context of testing, the minimal software item for which a separate specification is available. In the context of reuse, usually a routine, a class (consisting of a collection of routines), or a collection of classes (a package), which has a specification (including interfaces) and a list of its underlying principles and concepts, as well as quality information such as levels of proof and testing.

Front 437

software development

Back 437

The process whose end product is a software product.

Front 438

software engineer

Back 438

A person employed to undertake software engineering.

Front 439

software metrics

Back 439

Measurable quantities that can be used to infer values for the software quality factors.

Front 440

software quality

Back 440

At a general level, this defines the extent to which the customer is satisfied with the software product delivered at the end of the development process. At a more detailed level, it involves conformance to explicitly stated requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

Front 441

software quality factor (SQF)

Back 441

An attribute of a software product affected by product operation requirements, product revision requirements and product transition requirements. There are 11 such attributes: correctness, reliability, efficiency, integrity, usability, maintainability, flexibility, testability, portability, reusability and interoperability.

Front 442

software requirement

Back 442

See system requirement.See in contrast, user requirements.

Front 443

software system

Back 443

A general term referring to the end-product of software development. It embraces both application software and system software.

Front 444

specialisation

Back 444

A relationship between classes in the object-oriented model that captures the fact that a child class is a subtype of the parent class, that is, the methods and data fields of the specialised class (subclass) are a superset of the generalised class (superclass specialised class).

Front 445

specific-requirements capture

Back 445

Capturing the specific requirements for a new product, when using a product-line process. These are captured as specialisations and extensions of the domain model.

Front 446

sporadic event

Back 446

An event that is infrequent and isolated.

Front 447

sprint

Back 447

In Scrum, a timeboxed period of to a maximum of a month where useable software is delivered.

Front 448

stakeholder

Back 448

An individual and/or an organisation affected by the success or failure of a software system.

Front 449

start-up testing

Back 449

System testing that tests the system's ability to be started in a working hardware/software configuration. Following such tests, all configurations should be fully system tested individually.Also referred to as initialisation testing.

Front 450

state

Back 450

A condition or situation during the lifetime of an object during which it satisfies some condition, performs some activity or waits for some event. In object-oriented terms, it is the value of an object's attributes. From the client's point of view, the state of an object is implemented in terms of methods (that is, its accessor methods). However, inside the object's class definition, the accessor methods may be implemented in terms of private instance variables which are used to store the state (although on occasion the implementation may be in terms of methods which calculate the state). In formal specification, it refers to the stored data that a system accesses and alters.

Front 451

statechart

Back 451

Formalism introduced by David Harel for the representation of complex state transitions; it was adopted by the UML in its state machines.

Front 452

state-dependent/independent

Back 452

An object that always responds in the same way to a given event is state-independent. In contrast, objects that react differently to a given event are state-dependent.

Front 453

state diagram

Back 453

See statechart.

Front 454

statelessness

Back 454

A property of a component when it responds to each request as a 'one-off', without retaining any memory of previous requests.

Front 455

state machine

Back 455

A specification of the sequences of states that an object goes through in response to events during its life, together with its responsive actions. A state machine is attached to a source class, collaboration or method and specifies the behaviour of the instances of the source elements. State machines are represented in UML by state diagrams.

Front 456

static analysis tools

Back 456

Tools that allow software or other development artefacts to be checked for some properties or tested at compile time.

Front 457

static model

Back 457

A model that describes structure rather than behaviour. See structural model.

Front 458

static modelling

Back 458

Modelling of structure as opposed to behaviour.

Front 459

steering

Back 459

A move of the planning game that updates the plan based on reality.

Front 460

stereotype

Back 460

An extension mechanism in UML; it allows the creation of a new category of modelling element.

Front 461

stochastic event

Back 461

An event that occurs randomly but according to a well-defined probability distribution: for example heads coming up when a coin is flipped.

Front 462

straight-through path

Back 462

Basis-path testing is a white box testing technique that involves choosing test data to exercise all of the paths in code.In order to enumerate basis-path test cases, a first stp is typically to identify the straight-through path. This is the path where all loop and if conditions evaluate to false, and only default cases are selected in switch statements.

Front 463

stress testing

Back 463

System testing that tests that the system can operate reliably at the limits of each of its resources (for example, to stress test a web server, we may simulate the accesses of hundreds or thousands of users all at the same time to see if it can cope with the load).

Front 464

structural domain model

Back 464

See concept model.

Front 465

structural model

Back 465

See domain structural model, analysis structural model or design structural model.

Front 466

style

Back 466

See architectural style.

Front 467

subclass

Back 467

In object-oriented terms, the subclass inherits from the superclass, or parent class. In Java, all classes are subclasses of Object. A subclass may define its own methods and data fields in addition to those that are inherited. It may also override any of its inherited methods.

Front 468

subdomain

Back 468

Simply a set of input values that require essentially the same processing. Subdomains may be found by means of case analysis.

Front 469

subscriber

Back 469

Component, in a publish-subscribe architecture, that registers to receive updates from another component (the publisher).

Front 470

substitutability

Back 470

Substitutability means that an object of one type is legitimately substitutable for an object of another type. This is allowed in Java when objects are related through inheritance (that is, an object of the child class may be substituted for an object of the parent class). However, substitutability is only sensible when the objects are related as subtype to supertype (that is, when the inheritance is inheritance for specialisation and not inheritance for construction).

Front 471

superclass

Back 471

In Java, the (parent) class that is extended by another class (the child class or subclass).

Front 472

supplier

Back 472

In software development, the term refers to the person (or company) who develops a piece of software as a package.In programming, the term often refers to the method/class/object that is used by methods of another class/object (the client).In network programming, the term refers to a program/process running on one computer that provides services to another program running (usually) on another computer.

Front 473

swimlane

Back 473

A means of indicating a role's responsibilities in an activity diagram. Swimlanes show the concurrent activities of actors as separate partitions.

Front 474

synchronisation bar

Back 474

A means of describing the coordination of activities. Once all the activities leading to the synchronisation bar have completed, the transitions leaving it will be fired. Thus, it is a point where the flow of control may change. A synchronisation bar is used to identify the points at which concurrent threads begin (a fork) or end (a join).

Front 475

system

Back 475

An assembly of components that are connected in an organised way to perform some activity, that is, they behave dynamically.

Front 476

system boundary

Back 476

A conceptual division between the system to be studied and 'everything else'.

Front 477

system class

Back 477

In analysis, a class with a single instance that represents the whole system.

Front 478

system independence

Back 478

The degree to which a system is independent of non-standard programming language features, operating system characteristics, and other environmental constraints.

Front 479

system operation

Back 479

An operation executed by a software system as a response to an external event.

Front 480

system requirement

Back 480

...are a more detailed description of the functionality to be provided.' (Somerville, 2011.)

Front 481

system size

Back 481

A method for estimating the time to complete a software project based on the number of functions, the amount of data and the number of users. At completion of the project, it can be measured by the number of lines of code (LOC or KLOC) and the volume of data.

Front 482

system testing

Back 482

The third stage of developmental testing in which the completed system is tested against the customer's requirements.

Front 483

tactic

Back 483

A reusable solution to the problem of achieving particular qualities.

Front 484

tangible objects

Back 484

Physical objects identified during modelling.

Front 485

task

Back 485

A single path of execution through a program, dynamic model or other representation of control flow such as an activity diagram. In general, it is a piece of work to be done by someone, such as an actor involved in a use case. It is also used as a synonym for process.

Front 486

technical solution requirements

Back 486

These relate to functionality that is needed purely because of the chosen technology.

Front 487

testability

Back 487

A software quality factor affecting product revision requirements which determines the effort required to test a system to ensure that it performs its intended function, i.e. how easily the system can be tested to show that the customer's requirements have been met.

Front 488

test case

Back 488

The set of conditions and data used to determine whether a system is working as intended.

Front 489

test-driven development

Back 489

Test driven development demands that, before any code is written, tests should be written for that code to meet. Just enough code should be written to pass those tests, and the further tests should be written and so on. On each iteration, all the tests should be run. Test driven development eases the business of making late changes to code, because the accumulated tests provide assurance that changes have not broken the code.

Front 490

test harness

Back 490

Software added to a system to facilitate testing.

Front 491

testing

Back 491

The process of determining if an artefact meets a given specification. It is one of the four basic technical activities within a software development process (see also analysis, design and implementation). In practice, it is the use of techniques for the validation or verification of products or the processes by which they are made.

Front 492

test stub

Back 492

A testing tool providing very simple pieces of code which stand in for the called method. A test stub will implement the same signature as the called method, but provide none of its functionality, printing only verification messages for the data sent to it and returning to the caller with the 'expected' value.

Front 493

throughput

Back 493

The number of events dealt with in a given time.

Front 494

tier

Back 494

A physical partitioning of a system.

Front 495

timeboxed

Back 495

Within a short time frame.

Front 496

timeboxing

Back 496

Allocating short fixed periods - for example, three to four weeks - to each iteration.

Front 497

to do list

Back 497

In Test-driven development, when coding anything that turns out to need more than two or three TDD cycles, it can be useful to maintain a short to do list that can feed into the first steps of future cycles. This list should be kept short.

Front 498

tool

Back 498

Software used to support the software development process.

Front 499

traceability

Back 499

The ability to trace the history of each requirement from problem description through conceptual and specification models to the implementation and deployment models in order to reconstruct the significant events that led to the final operational software system. The ability to record information that will allow any investigation to reconstruct events, changes and reasons for change.

Front 500

trade

Back 500

A job, especially needing a special skill with the hands: Being a printer is a trade; being a lawyer is a profession.' (Longman Dictionary of Contemporary English, 1987.)

Front 501

training

Back 501

A process which assists in enabling new users to use a system effectively. It may include manuals, self-study modules or face-to-face lecturing.

Front 502

transition

Back 502

In state machines or activity diagram, the movement between states or activities triggered by an event. In UP, phase when the final product is tested and deployed.

Front 503

UML

Back 503

See Unified Modeling Language.

Front 504

Unified Modeling Language (UML)

Back 504

A language for visualising, specifying, constructing and documenting the artefacts of a software-intensive system. (See also modelling language.)

Front 505

Unified Process (UP)

Back 505

A popular iterative and incremental process for building enterprise systems based on an object-oriented approach. It consists of four phases: inception, elaboration, construction and transition.

Front 506

unit testing

Back 506

The first stage of developmental testing in which units of functionality (for example, the classes in an object-oriented system) are tested in isolation.

Front 507

usability

Back 507

The effectiveness, efficiency and satisfaction with which users can achieve tasks in a particular environment. High usability means a system is easy to learn and remember; efficient, visually pleasing and fun to use; and quick to recover from errors. Also, usability is a software quality factor affecting product operation requirements which determines the effort required to learn about, to operate, to prepare input for, and to interpret the output of a system, that is, how easy the system is to use.

Front 508

usability requiremenent

Back 508

A non-functional requirement about the product's ease of use or other usability considerations.

Front 509

usability testing

Back 509

One of the four major types of software testing in which the functionality and user interface are tested to ensure that they are fit for the intended users. This generally involves selected users undertaking carefully designed tasks so that measures of usability can be calculated and fed back into the development process.

Front 510

use case

Back 510

A description, of a piece of functionality that a system performs to yield an observable result of some value to an actor. (See also task.)

Front 511

use case diagram

Back 511

A diagram that shows a set of use cases and actors and their associations.

Front 512

use case object

Back 512

An object which is an instance of a class defined for each use case. In a hotel system, for example, there might be classes such as CheckerIn, CheckerOut and RoomMover. Each would have a method with a name like run(). The user interface would then create a single instance of the appropriate class, initialise it suitably, and then send it the run() message.

Front 513

use case realisation

Back 513

An activity that consists of linking the use cases to the classes which are going to carry them through.

Front 514

user

Back 514

A person who uses the software system on a day-to-day basis.

Front 515

user-centred design

Back 515

During analysis and design, a way of taking into account the different perspectives of different users when looking at the tasks that they perform; typically found in techniques used for requirements engineering.

Front 516

user-command testing

Back 516

System testing that tests all user commands from the point of view of tolerance to syntax errors and data input errors. Also referred to as operator testing.

Front 517

user-defined type

Back 517

A data type defined by the programmer using predefined types provided by the programming language.

Front 518

user requirements

Back 518

... abstract statements of the software requirements for the customer and end-user of the system.' (Somerville, 2004.)See in contrast, software requirements.

Front 519

user story

Back 519

A story written by an intended user of a system; it describes some functionality that is of value to the person(s) writing the story. It represents a user's expectation of the system.

Front 520

validation

Back 520

The process of checking that a software system is consistent with the customer's requirements; that is, the developer is building the 'right' product. (See also verification.)

Front 521

value identity

Back 521

The identity of a real-world object; how people distinguish between objects using identifiers with values which are understood by other people.

Front 522

variables

Back 522

In Java, a data field that holds a particular type of value or refers to a particular type of object. Unlike a data field declared as static, the value associated with a variable data field may be changed. (See also class variable and instance variable.)

Front 523

variant

Back 523

In a configuration management system, two configuration items which are essentially the same but differ in some well defined sense are called variants. Variants are distinguished by having different descriptive names, and also have descriptions characterising them. Variants themselves undergo revisions and thus have versions.

Front 524

verification

Back 524

A process of ensuring that the design of a system corresponds to its specification, and that the system is correctly coded according to its design; that is, all the different system descriptions are consistent and complete with respect to each other. If validation is about building the 'right' product, then verification is about the product being built 'right'.

Front 525

version

Back 525

An 'instance' of a configuration item. Also referred to as a revision.

Front 526

view

Back 526

In the MVC, the view is the representation of the model in the user interface: it displays the output from the system and is what the user perceives of the model's state.

Front 527

viewpoint

Back 527

A perspective on a system from the point of view of a particular person or group of people.

Front 528

virtual machine

Back 528

A software simulation of a computer, running in a special environment.

Front 529

visibility

Back 529

The property of where named elements can be accessed in a program.

Front 530

Volere template

Back 530

This is a template for a document that collates all the requirements of a system, together with other issues that may affect those requirements. The template provides a sort of container, in which the information can be organised systematically.

Front 531

waterfall model

Back 531

A particular life cycle that uses the analysis, design, implementation and testing activities in a simple sequence with little or no iteration. Some versions append the maintenance activity.

Front 532

weighted-methods-per-class (WMPC) metric

Back 532

A measure of the complexity of behaviour of a given class. It is defined as the sum of the cyclomatic complexities of each method of the class. The relationship between this metric and complexity is that a class with many simple methods may be as difficult to understand as a class with a few complicated methods.

Front 533

white box testing

Back 533

Used to check that the details of an implementation are correct. White box testing ignores the 'big picture' of the requirements, and instead looks to detailed designs to check that the system does what it is supposed to do, correctly.

Front 534

workflow

Back 534

The steps that people go through when doing their jobs. A workflow may contain a number of activities that must be coordinated and arranged in a specified order to achieve a goal. A workflow can be used to represent the flow of activities that takes place in a business process.

Front 535

wrapper

Back 535

See Adapter pattern.

Front 536

XP

Back 536

See extreme programming.