Glossary Flashcards
0
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.
1
Q
abstraction
A
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).
2
Q
action
A
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.
3
Q
activation
A
On a sequence diagram, a long rectangle, coincident with the lifeline of an object, showing the entire period when an object is active.
4
Q
viewpoint
A
A perspective on a system from the point of view of a particular person or group of people.
5
Q
cohesion
A
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.
6
Q
coupling
A
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.)
7
Q
component
A
In general, this refers to an identifiable part of a system.
8
Q
encapsulation
A
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.
9
Q
interface
A
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.
10
Q
circular dependency
A
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.
11
Q
maintenance
A
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.
12
Q
Unified Modeling Language (UML)
A
A language for visualising, specifying, constructing and documenting the artefacts of a software-intensive system.
13
Q
modularity
A
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.
14
Q
context dependency
A
A service required by a module in order for it to work.
15
Q
legacy system
A
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.
16
Q
maintainability
A
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.
17
Q
malleability
A
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.
18
Q
implementation
A
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).
19
Q
complexity
A
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.
20
Q
size (of software)
A
This can be measured in terms of lines of code, number of symbols, size of source or object files etc.
21
Q
system boundary
A
A conceptual division between the system to be studied and ‘everything else’.
22
Q
activity
A
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.
23
Q
activity diagram
A
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.
24
actor
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.
25
agile
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.
26
agile UP
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.
27
analysis
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).
28
concept(ual) model
The structural model that represents the static part of the domain: the concepts and their relationships.
29
business event
A business event is something that a system must respond to.
30
business process
Definition of what gets done in the business: by whom, in what order, needing what and with what consequences.
31
context dependency
A service required by a module in order for it to work.
32
constraint
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.
33
business rule
A constraint on how the business is run; that is, a constraint on the business processes.
34
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’.
35
complexity
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.
36
aggregation
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.
37
ambiguity
Open to several interpretations.
38
viewpoint
A perspective on a system from the point of view of a particular person or group of people.
39
analysis class
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.
40
analysis model
An initial representation of the structure of a software solution by a class diagram; it represents analysis classes, their associations and constraints.
41
analysis pattern
A high-level pattern describing a solution at a conceptual analysis level problem.
42
analytical completeness
A measure of completeness where only the functional requirements are considered.
43
applet
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.
44
Application Controller pattern
A design pattern which addresses the concerns in the interaction between actors and a system, when the interaction takes place through user interfaces.
45
Architectural pattern
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.
46
architectural view
A model of the architecture, that captures the concerns of a group of stakeholders of the system.
47
architecture specialisation
The process of specialising an architecture by selecting specific components etc.
48
architecture specification
The specification of the architecture of a system. It is also the third step in the product line process, where reference architectures are produced.
49
assertion
In DbC, a precondition, a postcondition or an invariant.
50
assertion (handling) mechanism
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.
51
assertion statement
A statement of what must be true at a particular point in the execution of a method.
52
association
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.
53
association class
An association that also has class properties. Each instance of the association class defines values for those properties.
54
association loop invariant
An invariant showing the relationship between two paths around a loop.
55
assume
A condition that a component needs, to operate correctly.
56
asynchronous
(communication) When the sender can continue without waiting for an answer from another component.
57
adapter
A design pattern that addresses the problem of a class having an interface different from the one the client expects.
58
attribute
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.
59
baseline
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.
60
basis-path testing
A white box testing technique based on the cyclomatic-complexity metric which ensures that all statements in a method are tested at least once.
61
bidirectional association
An association that is navigable in both directions.
62
blackboard
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.
63
black box testing
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.
64
boundary-condition testing
Unit testing in which test data are chosen to check that methods perform correctly at the extremities of input ranges.
65
Adapter pattern
A design pattern used when a client expects to make calls to a particular interface different from the one that is implemented.
66
boundary testing
Class testing in which a class is tested according to its use and that has-a relationship in its class diagram.
67
bursty event
An event coming in sudden and unpredictable clusters overlaying normally low background activity.
68
business transaction
A significant activity, episode, interaction, in a business.
69
callee
Component that receives a procedure call in a call-return architecture.
70
caller
Component that makes a procedure call in a call-return architecture.
71
call-return style
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.
72
Cascade pattern
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.)
73
check(ing) in
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.
74
check(ing) out
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.
76
diagram
In UML, a diagram is a graphical presentation of a collection of model elements.
77
class diagram
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.
78
class invariant
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.
79
class method
A method defining how a class responds to a message, rather than how instances of the class respond to messages. (See also instance method.)
80
class model
A class model is represented in a class diagram.
81
class-responsibility-collaboration cards
An approach to identifying classes and their responsibilities using simply structured cards.
82
class variable
In Java, a data field declared as static.
83
client
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.
84
client-server
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.
84
cloud computing
A model in which software runs on remote facilities provided by a third-party supplier.
86
commitment
A move of the planning game that decides what to do next.
87
communication diagram
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.
88
compiler
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.
89
completeness
The degree to which full implementation of the required functionality has been achieved.
90
component architecture
An architecture specified in terms of components and the connections between them. It can be specialised by selecting appropriate versions of each component.
91
component-based development (CBD)
An approach to the development of software by assembling reusable self-contained software components.
92
component collection
The fourth step in the product line process where the repository of candidate components accompanying the architecture is gathered together.
93
component selection and specialisation
The process of selecting appropriate components for a system and specialising them to the application domain.
94
composite state
A state that contains some internal behaviour, which can be represented with a state diagram. (Also referred to as a compound state.)
95
composition
A form of aggregation with strong ownership; component objects of an aggregate have no life after the destruction of the aggregate.
96
computer-aided software engineering (CASE)
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.
97
concern
Some aspect of the system that is of crucial importance from the point of view of one or more groups of stakeholders.
98
configuration
All the modules (components) which together make up an executable software system. It is also a term for the collection of configuration items.
99
configuration item
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.
100
configuration management
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.
101
configuration repository
A library of configuration items managed by the configuration management system.
102
configuration version
A consistent collection of versions of configuration items.
103
conformance testing
Testing that the software product conforms to its requirements.
104
connector
An element of an architecture that establishes the communication between components.
105
consistency
The property of two descriptions agreeing with each other, that is, not making statements that cannot be simultaneously true.
106
construction
In UP, phase when the final product is implemented.
107
constructor
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.
108
consumer
A client in SOA.
109
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).
110
contract
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.
111
controller
In the MVC, the controller is the component that handles all user inputs which affect the model.
112
control-structure testing
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.
113
copyright law
The automatic legal protection afforded to an individual or organisation that publishes the expression of an idea, including software.
114
correct
A correct system is one that meets all its requirements.
115
coupling between objects (CBO) 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.
116
critical path
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.
117
cultural requirement
A non-functional requirement relating to the people involved in the product’s development and operation.
118
cyclomatic-complexity metric
A measure of the complexity of a method by counting the number of independent paths through a method body.
119
data-centred
Architectural style where there is a data provider which is a centralised store of persistent data.
120
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.
121
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.
122
data lock-in
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.
123
data loss
The amount of data lost because the system fails to record it.
124
decision nodes
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.
125
defect
A verified lack of conformance to requirements.
126
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.
127
deliverable
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.
128
denial of use of service (or loss of access)
Attack consisting of the denial of service to authorised users.
129
dependency injection
A Java EE container service that creates and manages an EJB object ‘injecting’ the necessary references into the client.
130
deployment
Configuring code to give a runnable system.
131
deployment model
A UML model describing how the components of a system are to be mapped onto different machines and how they will communicate.
132
deployment view
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.
133
depth-of-inheritance-tree (DIT) metric
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.
134
derivation
A version of a configuration item based on other configuration items, which might have to be changed if the original item changes.
135
derived association
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.
136
derived attribute
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.
137
design
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.
138
Design by Contract (DbC)
The process of developing software based on the notion of contracts between objects, which are expressed as assertions.
139
design decision
Decisions taken during design that may impact on the quality of the software eventually produced.
140
design model
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.
141
design pattern
A middle-level pattern describing a solution at a software design level.
141
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.
142
development process
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.
143
disclosure
Attack of private information or the unauthorised release of information.
144
discoverable
The property of a service in a service oriented architecture that allows the architecture to identify services on behalf of a consumer.
145
domain
An area or field of knowledge characterised by a set of concepts and terminology that is understood by practioners in that area.
146
domain analysis
A form of requirements elicitation in which existing systems in the domain are examined and domain experts are consulted.
147
domain expert
Someone who is considered to have a considerable level of knowledge or expertise in a given domain.
148
domain model
An initial representation of the structure of a domain by a class diagram; it represents domain classes (concepts), and their associations.
149
domain modelling
Modelling what already exists.
150
domain-specific knowledge
A necessary but not sufficient element of competence made up of knowledge specifically concerned with the particular task or type of application.
151
dynamic model
Describes the behaviour of a software system over time.
152
Dynamic Systems Development Method (DSDM)
An agile software development method.
153
dynamic tool
A tool that is used at run-time.
154
EJB container
A run-time environment where EJB components are deployed.
155
elaboration
In UP, phase most analysis and design occur.
156
element
In UML, an element is an atomic constituent of a model.
157
engineering
A systematic approach to efficiently developing products which are fit for purpose, based on a body of knowledge.
158
enterprise architectures
Software systems designed to meet the business needs of large organisations.
159
enterprise beans
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.
160
Enterprise JavaBeans (EJB)
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.
161
enumeration type
A user-defined type with a finite number of literals.
162
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.
163
waterfall model
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.
164
weighted-methods-per-class (WMPC) 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.
165
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.
166
workflow
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.
167
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.
168
value identity
The identity of a real-world object; how people distinguish between objects using identifiers with values which are understood by other people.
169
variables
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.
171
variant
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.
172
version
An ‘instance’ of a configuration item. Also referred to as a revision.
172
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.
173
virtual machine
A software simulation of a computer, running in a special environment.
174
visibility
The property of where named elements can be accessed in a program.
175
Unified Modeling Language (UML)
A language for visualising, specifying, constructing and documenting the artefacts of a software-intensive system.
176
Unified Process (UP)
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.
177
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.
178
usability
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.
179
usability requiremenent
A non-functional requirement about the product’s ease of use or other usability considerations.
180
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.
181
use case
A description, of a piece of functionality that a system performs to yield an observable result of some value to an actor.
182
use case diagram
A diagram that shows a set of use cases and actors and their associations.
183
use case object
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.
184
Java Enterprise Edition (Java EE)
A framework for constructing enterprise systems.
185
jitter
The amount of variation in latency, for example, are some responses very quick but others take much longer?
186
join
In activity diagrams, a join node synchronises multiple parallel flows.
187
hacking
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.
188
hardware independence
The degree to which the software is decoupled from the hardware on which it operates.
189
heroic programming
A form of software development where a single person attempts to have in mind everything concerning a given problem and its eventual solution.
190
HTTP (Hypertext Transfer Protocol)
A protocol for communication of data in the Web.
191
human factors
The discipline that deals with the relationship between people and technology.
192
hybrid cloud
A cloud offered by an organisation that combines a private cloud with externally provided cloud services.
193
namespace
A boundary within which names are unique.
194
navigability
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.
195
navigation expression
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.
196
non-deterministic
A situation where one of a number of outcomes is possible, for example when throwing a dice.
197
non-functional requirement
A quality that a system must have.
198
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.
199
number-of-children (NOC) 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 class.
200
Object Constraint Language (OCL)
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.
201
object diagram
An instance of a class model that shows objects (possibly value of attributes) and their links at a point in time.
202
object model
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.
203
observable
In the Observer pattern the object, also called the subject, that keeps objects registered with it informed when its state changes.
204
observer
In the Observer pattern objects register themselves with a Observable, in order to receive notifications when the latter's state changes.
205
Observer pattern
A design pattern that addresses the issue of supporting dependencies between objects, whilst keeping coupling low.
206
open-source software
Similar to freeware, except that it is maintained and upgraded openly by a community of expert users; code can be modified.
207
operability
The ease of operation of a program.
208
operational and environmental requirement
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.
209
oracle
The criteria in a test case that helps define whether the test is passed.
210
organisational units
The groups to which people belong.
211
factory
A specialised object for creating and initialising objects needed by clients.
212
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.
213
Factory pattern
A pattern to define a specialised object for the creation and initialisation of other objects.
214
filter
Element in a pipe and filter architecture that takes some data and processes it to produce a result.
215
final state
In a state diagram, a special mark (bull’s eye), with only incoming transitions, indicating where processing terminates.
216
fit criterion
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.
217
fixture
The state in place and the data to be used on a test case.
218
flexibility
The property of a software system that indicates how easily the system can be modified.
219
foreign key
In a database table, a column that holds a key from a different table.
220
fork
In activity diagrams, a fork node splits control into multiple parallel flows.
221
Fork (pattern)
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.)
222
formal technical review (FTR)
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.
223
forward engineering
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.
224
fragment
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.
225
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.
226
freeware
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.
227
freezing
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.
228
functional (or logical) view
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.
229
further analysis
The adding of additional detail to a system specification. In particular, system operations and model constraints.
230
Gantt chart
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.
231
generalisation
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).
232
General Responsibility Assignment Software Patterns (GRASP)
A collection of patterns which may help the designer assign responsibilities in commonly recurring design scenarios.
233
generic collection
In Java, collection types can be parameterised by the type of the objects they contain.
234
glossary
A list of terms or words relating to a particular domain or text, along with an explanation of each term.
235
grammatical parse
Used in this module to refer to process for obtaining list of nouns from a written problem description to identify candidate classes.
236
GRASP Creator
A pattern that provides guidance on which class should be responsible for creating new objects.
237
GRASP Expert
A pattern that provides guidance on which class should be responsible for initialising or changing the state of an object.
238
guarantee
A condition that a component promises to other components.
239
guard
A condition that must be satisfied in order to enable an associated transition to fire within a state machine or activity diagram.
240
guillemets
Angled brackets (« …») used in UML to show a stereotype. They have other more general uses.
241
random testing
A black box testing technique in which test data is randomly generated within the input data space.
242
realisation
An implementation of an interface.
243
record
A row of a database table.
244
recursive
A recursive association is one between a concept/class and itself.
245
refactoring
The reorganisation of code structure for reasons such as clarity or maintainability, while making no change to the external behaviour.
246
registry
A mechanism that allows clients to find services.
247
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.
248
release
A configuration version delivered on completion of the project for use by the customer.
249
reliability
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.
250
rendezvous semantics
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.
251
repository
Centralised store of persistent data in a data-centred architecture.
252
repudiation
Attack consisting of (false) claim by legitimate user that a message was not sent or received.
253
required interface
The set of operations a component needs from other components.
254
requirement
A desired feature, property or behaviour of a software system.
255
requirements analysis
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.
256
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.
257
requirements documentation
An activity undertaken to record agreed requirements.
258
requirements elicitation
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.
259
requirements engineering
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.
260
requirements negotiation
An activity undertaken to agree requirements.
261
Requirements pattern
A description of knowledge used in the elicitation of requirements.
262
requirements specification
A detailed description of the requirements for a system.
263
requirements validation
A careful check of a requirements document, usually following a checklist.
264
resource balancing/levelling
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.
265
response-for-a-class (RFC) 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.
266
response set
All the methods of a class, including those inherited, and those it invokes.
267
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.
268
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.
269
reverse engineering
The process, usually automated or semi-automated in a CASE tool, for deriving a model from source code alone.
270
review
A software inspection meeting to confirm and list major defects, and to determine who will be responsible for addressing each defect.
271
risk management
Analysis of risks in a development process and determination of steps to reduce them.
272
robustness
The degree of immunity from damage when a program encounters an error. Also referred to as error tolerance.
273
role
The behaviour of an entity participating in a particular context. It may also refer to the behaviour of people in a domain.
274
role name
The identification of a specific role for a class in a given association.
275
package
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.
276
partition
The decomposition of a problem into a number of subproblems that are independent of each other.
277
partitioning
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.)
278
path parameter
Part of a path to be replaced by the corresponding element in the actual URI the client uses when making a request.
279
peer-to-peer
An architecture where there is no clear distinction between clients and servers.
280
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.
281
performance
The ability of a system to process service requests.
282
performance requirement
A non-functional requirement about how fast, how safe, how accurate, how available and how reliable the product must be.
283
performance testing
System testing that tests that the system meets all specified operating requirements for speed, number of concurrent users permitted, etc.
284
PERT chart
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.
285
pipe
Element in a pipe and filter architecture that is a conduit along which the data flows.
286
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.
287
placeholder
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.
288
plan-driven development
Term used to distinguish traditional, more prescriptive approaches to software development from agile development approaches.
289
planning
The first stage of a formal technical review.
290
Planning Game
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.)
291
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.
292
portability
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.
293
postcondition
A constraint that must be true at the completion of an operation, or use case
294
precondition
A constraint that must be true when an operation is invoked, or when a use case is carried out.
295
predefined type
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.
296
preferred version
In configuration management, the default version which is checked out, usually the latest.
297
presentation layer
In a layered architecture, the layer concerned with the user interface.
298
primary key
In a database table, a column that uniquely identifies each row of the table.
299
private cloud
A cloud that belongs to a particular organisation, usually one large enough to generate economies of scale internally.
300
procedure
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.
301
process
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.
302
process improvement
The idea that an organisation should learn from difficulties encountered with their existing processes, and improve as a result.
303
process-related human factors
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.
304
process view
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.
305
product
In the Factory design pattern the object the factory produces.
306
product backlog
An artefact in Scrum (an agile method) that consists of an ordered structured list of what needs to be done to a system.
307
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.
308
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.
309
product operation requirements
How a product will be used
310
product-related human factors
The human factors involved in the people–technology relationship
311
product revision requirements
How a product will be maintained.
312
product transition requirements
How a product will be modified for different operating environments.
313
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.)
314
project management
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.
315
project plan
A plan breaking down the development of a system into stages and showing how much resource is required at each stage.
316
prototype
A simplified software system that is a subset of the eventual product.
317
prototypical interaction
An interaction described using some prototypical objects.
318
prototypical object
An object representing the general case rather than a specific instance.
319
provided interface
The set of operations a component makes available to other components.
320
provider
In SOA the platform on which a service is implemented.
321
public cloud
A cloud such as Amazon EC2 or Google App Engine which is available to anyone willing to purchase the service.
322
public-domain software
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.
323
publisher
Component, in a publish-subscribe architecture, that notifies other components of updates.
324
publish-subscribe
Architectural style where subscribers register to receive updates (often messages) whenever a publisher posts a new item.
325
qualified association
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 association.
326
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.
327
quality management
An activity that takes place throughout the software development process to ensure the quality of the final product.
328
quality management system (QMS)
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.
329
quality manual
A document containing quality standards, guidelines and procedures.
330
quality plan
A document specifying the quality controls for a project.
331
Quantity pattern
A pattern which provides useful guidance on how to represent dimensioned quantities, that is, values plus their units of measurement.
