Block 3 Glossary Flashcards
These cards are a copy of the glossary provided by TM354. Except where definitions are 'see x', these cards have been omitted. (168 cards)
1
Q
Acceptance Testing
A
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.
2
Q
Adapeter
A
A design pattern that addresses the problem of a class having an interface different from the one the client expects.
3
Q
Adapter Pattern
A
A design pattern used when a client expects to make calls to a particular interface different from the one that is implemented.
4
Q
Analysis Pattern
A
A high-level pattern describing a solution at a conceptual analysis level problem.
5
Q
Analytical Completeness
A
A measure of completeness where only the functional requirements are considered.
6
Q
Applet
A
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.
7
Q
Architectural Pattern
A
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.
8
Q
Arcitectural View
A
A model of the architecture, that captures the concerns of a group of stakeholders of the system.
9
Q
Architecture Specilaisation
A
The process of specialising an architecture by selecting specific components etc.
10
Q
Architecture Specification
A
The specification of the architecture of a system. It is also the third step in the product line process, where reference architectures are produced.
11
Q
Assertion (Handling) Mechanism
A
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.
12
Q
Assertion Statement
A
A statement of what must be true at a particular point in the execution of a method.
13
Q
Assume
A
A condition that a component needs, to operate correctly.
14
Q
Asynchronous
A
(communication) When the sender can continue without waiting for an answer from another component.
15
Q
Basis-Path Testing
A
A white box testing technique based on the cyclomatic-complexity metric which ensures that all statements in a method are tested at least once.
16
Q
Blackboard
A
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.
17
Q
Black Box Testing
A
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.
18
Q
Boundary Testing
A
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.
19
Q
Bursty Event
A
An event coming in sudden and unpredictable clusters overlaying normally low background activity.
20
Q
Callee
A
Component that receives a procedure call in a call-return architecture.
21
Q
Call-Return Style
A
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.
22
Q
Case Analysis
A
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.
23
Q
Class Invariant
A
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.
24
Q
Client-Server
A
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.
25
Cloud Computing
A model in which software runs on remote facilities provided by a third-party supplier.
26
Completeness
The degree to which full implementation of the required functionality has been achieved.
27
CBD
Component-Based Development
An approach to the development of software by assembling reusable self-contained software components.
28
Component Collection
The fourth step in the product line process where the repository of candidate componentsaccompanying the architecture is gathered together.
29
Component Selection and Specialisation
The process of selecting appropriate components for a system and specialising them to the application domain. (See also domain.)
30
Concern
Some aspect of the system that is of crucial importance from the point of view of one or more groups of stakeholders.
31
Connector
An element of an architecture that establishes the communication between components.
32
Consistency
The property of two descriptions agreeing with each other, that is, not making statements that cannot be simultaneously true.
33
Container
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).
34
Context Dependency
A service required by a module in order for it to work.
35
Controller
In the MVC, the controller is the component that handles all user inputs which affect the model.
36
CBO
Coupling Between Objects Metric
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.
37
Cyclomatic-Compexity Metric
A measure of the complexity of a method by counting the number of independent paths through a method body.
38
Data-Centred
Architectural style where there is a data provider which is a centralised store of persistent data.
39
Data-Centred Style
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.
40
Data-Flow Style
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.
41
Data Loss
The amount of data lost because the system fails to record it.
42
Defensive Programming
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.
43
Dependency Injection
A Java EE container service that creates and manages an EJB object ‘injecting’ the necessary references into the client.
44
Deployment Model
A UML model describing how the components of a system are to be mapped onto different machines and how they will communicate.
45
DIT
Depth-of-Inheritance-Tree
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.
46
DbC
Design by Contract
The process of developing software based on the notion of contracts between objects, which are expressed as assertions.
47
Design Pattern
A middle-level pattern describing a solution at a software design level.
48
Developmental Testing
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.
49
EJB Container
A run-time environment where EJB components are deployed.
50
Enterprise Architectures
Software systems designed to meet the business needs of large organisations.
51
Error Guessing
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.
52
Executable Assertion
An assertion that has been coded and can be executed at run-time.
53
Executable Documentation
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.
54
XP
Extreme Programming
An agile software development method.
55
Factory
A specialised object for creating and initialising objects needed by clients.
56
Factory Method
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.
57
Factory Pattern
A pattern to define a specialised object for the creation and initialisation of other objects.
58
Filter
Element in a pipe and filter architecture that takes some data and processes it to produce a result.
59
Fixture
The state in place and the data to be used on a test case.
60
Flexibility
The property of a software system that indicates how easily the system can be modified.
61
Foreign Key
In a database table, a column that holds a key from a different table.
62
Framework
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.
63
Guarantee
A condition that a component promises to other components.
64
Heuristic Evaluation
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').
65
HTTP
Hyper Text Transer Protocol
A protocol for communication of data in the Web.
66
Idiom
A pattern that applies within a programming language.
67
Ilities
Quality attributes, for instance security, reliability, availability, usability etc.
68
Independent Components
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.
69
Independent Components Style
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.
70
Inertial Convention
The assumption that state components not explicitly described as having changed in a postconditionwill remain unchanged by a method call.
71
Integration and Release
The process of bringing items together into a unified whole, and then releasing to a customer.
72
Integration Testing
The second stage of developmental testing in which previously tested units are tested together as an integrated whole.
73
Interface
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.
74
Interface Testing
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 systemcommunicates 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.
75
Java EE
Java Enterprise Edition
A framework for constructing enterprise systems.
76
Jitter
The amount of variation in latency, for example, are some responses very quick but others take much longer?
77
LCOM
Lack-Of-Cohesion-In-Methods Metric
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.
78
Latency
The time taken to process a stimulus, for example, how long does a search engine take to respond to a query?
79
Layered Style
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.
80
LOC
Lines-Of-Code Metric
A very simple measure of the complexity of a system description is given by counting the number of lines in a piece of code.
81
Location Transparency
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.
82
MTTC
Mean Time To Change
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.
83
Miss Rate
Measures the proportion of events that are not responded to.
84
Model
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.
85
MVC
Model-View-Controller
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.
86
Notification Style
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.
87
NOC
Number-Of-Children Metric
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 clas
88
Observable
In the Observer pattern the object, also called the subject, that keeps objects registered with it informed when its state changes.
89
Observer
In the Observer pattern objects register themselves with a Observable, in order to receive notifications when the latter's state changes.
90
Partitoning
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.)
91
Path Parameter
Part of a path to be replaced by the corresponding element in the actual URI the client uses when making a request.
92
Peer-To-Peer
An architecture where there is no clear distinction between clients and servers.
93
Peer-To-Peer Style
An architectural style in which all components are both clients and servers and any component can request services from any other component.
94
Performance
The ability of a system to process service requests.
95
Performance Testing
System testing that tests that the system meets all specified operating requirements for speed, number of concurrent users permitted, etc.
96
Pipe
Element in a pipe and filter architecture that is a conduit along which the data flows.
97
Pipes and Filters
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.
98
Polymorphism
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.
99
Postcondition
A constraint that must be true at the completion of an operation, or use case.
100
Precondition
A constraint that must be true when an operation is invoked, or when a use case is carried out.
101
Presentation Layer
In a layered architecture, the layer concerned with the user interface.
102
Primary Key
In a database table, a column that uniquely identifies each row of the table.
103
Product
In the Factory design pattern the object the factory produces.
104
Product Line
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.
105
Product-Line Initiation
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.
106
Product Operation Requirements
How a product will be used
107
Product Revision Requirements
How a product will be maintained.
108
Product Transition Requirements
How a product will be modified for different operating environments.
109
Profession
‘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.)
110
Provided Interface
The set of operations a component makes available to other components.
111
Publisher
Component, in a publish-subscribe architecture, that notifies other components of updates.
112
Publish-Subscribe
Architectural style where subscribers register to receive updates (often messages) whenever a publisher posts a new item.
113
Quality Attribute Scenario
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.
114
Quantity Patterns
A pattern which provides useful guidance on how to represent dimensioned quantities, that is, values plus their units of measurement.
115
Random Testing
A black box testing technique in which test data is randomly generated within the input data space.
116
Realisation
An implementation of an interface.
117
Record
A row of a database table.
118
Refactoring
The reorganisation of code structure for reasons such as clarity or maintainability, while making no change to the external behaviour.
119
Regression Testing
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.
120
Repository
Centralised store of persistent data in a data-centred architecture.
121
Required Interface
The set of operations a component needs from other components.
122
Requirements-Based Testing
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.
123
Requirements Pattern
A description of knowledge used in the elicitation of requirements.
124
RFC
Responces-For-A-Class Metric
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.
125
Response Set
All the methods of a class, including those inherited, and those it invokes.
126
Restart Testing
System testing that tests the ability of the system to recover from errors of internal state.
127
RESTful
A web service that uses a uniform interface consisting only of a set of standard methods which are always the same for every service.
128
Reusability
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.
129
Security Testing
System testing that tests that the system does not offer opportunities to breach security.
130
Self Consistency
System descriptions are said to be self consistent if they make no self contradictory statements.
131
Service Consumer
Component accessing a service.
132
Service Orchestration
Coordination of services invocation.
133
SOA
Service-Oriented Architecture
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.
134
SOCCA
Service-Oriented Cloud Computing Architecture
An architecture to address the integration of the principles of SOA with those of cloud computing.
135
Service-Oriented Style
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.
136
Service Provider
Component implementing a service.
137
Signature
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).
138
Singleton
A design pattern used where there should be only one instance of a class.
139
Singleton Pattern
A pattern to ensure that a class has only one instance, and to provide a global point of access to it.
140
Software Architecture
‘… 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.)
141
Software Metrics
Measurable quantities that can be used to infer values for the software quality factors.
142
SQF
Software Quality Factor
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, reusabilityand interoperability.
143
Specific-Requirements Capture
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.
144
Sporadic Event
An event that is infrequent and isolated.
145
Start-Up Testing
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.
146
Statelessness
A property of a component when it responds to each request as a ‘one-off’, without retaining any memory of previous requests.
147
Stochastic Event
An event that occurs randomly but according to a well-defined probability distribution: for example heads coming up when a coin is flipped.
148
Straight-Through Path
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.
149
Stress Testing
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).
150
Subdomain
Simply a set of input values that require essentially the same processing. Subdomains may be found by means of case analysis.
151
Subscriber
Component, in a publish-subscribe architecture, that registers to receive updates from another component (the publisher).
152
Subsitutability
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).
153
System Testing
The third stage of developmental testing in which the completed system is tested against the customer’s requirements.
154
Tactic
A reusable solution to the problem of achieving particular qualities.
155
Test Case
The set of conditions and data used to determine whether a system is working as intended.
156
Test-Driven Development
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.
157
Throughput
The number of events dealt with in a given time.
158
To Do List
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.
159
Unit Testing
The first stage of developmental testing in which units of functionality (for example, the classes in an object-oriented system) are tested in isolation.
160
Usability Testing
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.
161
User-Command Testing
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.
162
User-Defined Type
A data type defined by the programmer using predefined types provided by the programming language.
163
Validation
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.)
164
Verification
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’.
165
View
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.
166
Viewpoint
A perspective on a system from the point of view of a particular person or group of people.
167
WMPC
Weighted-Methods-Per-Class Metric
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.
168
White Box Testing
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.
