Glossary Flashcards
acceptance testing
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.
abstraction
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).
action
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.
activation
On a sequence diagram, a long rectangle, coincident with the lifeline of an object, showing the entire period when an object is active.
viewpoint
A perspective on a system from the point of view of a particular person or group of people.
cohesion
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.
coupling
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.)
component
In general, this refers to an identifiable part of a system.
encapsulation
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.
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.
circular dependency
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.
maintenance
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.
Unified Modeling Language (UML)
A language for visualising, specifying, constructing and documenting the artefacts of a software-intensive system.
modularity
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.
context dependency
A service required by a module in order for it to work.
legacy system
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.
maintainability
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.
malleability
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.
implementation
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).
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.
size (of software)
This can be measured in terms of lines of code, number of symbols, size of source or object files etc.
system boundary
A conceptual division between the system to be studied and ‘everything else’.
activity
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.
activity diagram
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.
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.
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.
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.
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).
concept(ual) model
The structural model that represents the static part of the domain: the concepts and their relationships.
business event
A business event is something that a system must respond to.
business process
Definition of what gets done in the business: by whom, in what order, needing what and with what consequences.
context dependency
A service required by a module in order for it to work.
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.
business rule
A constraint on how the business is run; that is, a constraint on the business processes.
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’.
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.
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.
ambiguity
Open to several interpretations.
viewpoint
A perspective on a system from the point of view of a particular person or group of people.
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.
analysis model
An initial representation of the structure of a software solution by a class diagram; it represents analysis classes, their associations and constraints.
analysis pattern
A high-level pattern describing a solution at a conceptual analysis level problem.
analytical completeness
A measure of completeness where only the functional requirements are considered.
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.
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.
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.
architectural view
A model of the architecture, that captures the concerns of a group of stakeholders of the system.
architecture specialisation
The process of specialising an architecture by selecting specific components etc.
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.
assertion
In DbC, a precondition, a postcondition or an invariant.
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.
assertion statement
A statement of what must be true at a particular point in the execution of a method.
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.
association class
An association that also has class properties. Each instance of the association class defines values for those properties.
association loop invariant
An invariant showing the relationship between two paths around a loop.
assume
A condition that a component needs, to operate correctly.
asynchronous
(communication) When the sender can continue without waiting for an answer from another component.
adapter
A design pattern that addresses the problem of a class having an interface different from the one the client expects.
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.
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.
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.
bidirectional association
An association that is navigable in both directions.
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.
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.
boundary-condition testing
Unit testing in which test data are chosen to check that methods perform correctly at the extremities of input ranges.
Adapter pattern
A design pattern used when a client expects to make calls to a particular interface different from the one that is implemented.
boundary testing
Class testing in which a class is tested according to its use and that has-a relationship in its class diagram.
bursty event
An event coming in sudden and unpredictable clusters overlaying normally low background activity.
business transaction
A significant activity, episode, interaction, in a business.
callee
Component that receives a procedure call in a call-return architecture.
caller
Component that makes a procedure call in a call-return architecture.
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.
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.)
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.
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.
diagram
In UML, a diagram is a graphical presentation of a collection of model elements.
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.
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.
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.)
class model
A class model is represented in a class diagram.
class-responsibility-collaboration cards
An approach to identifying classes and their responsibilities using simply structured cards.
class variable
In Java, a data field declared as static.
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.
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.
cloud computing
A model in which software runs on remote facilities provided by a third-party supplier.
commitment
A move of the planning game that decides what to do next.
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.
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.
completeness
The degree to which full implementation of the required functionality has been achieved.
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.
component-based development (CBD)
An approach to the development of software by assembling reusable self-contained software components.
component collection
The fourth step in the product line process where the repository of candidate components accompanying the architecture is gathered together.
component selection and specialisation
The process of selecting appropriate components for a system and specialising them to the application domain.
composite state
A state that contains some internal behaviour, which can be represented with a state diagram. (Also referred to as a compound state.)
composition
A form of aggregation with strong ownership; component objects of an aggregate have no life after the destruction of the aggregate.
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.
concern
Some aspect of the system that is of crucial importance from the point of view of one or more groups of stakeholders.
configuration
All the modules (components) which together make up an executable software system. It is also a term for the collection of configuration items.
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.
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.
configuration repository
A library of configuration items managed by the configuration management system.
configuration version
A consistent collection of versions of configuration items.
conformance testing
Testing that the software product conforms to its requirements.
connector
An element of an architecture that establishes the communication between components.
consistency
The property of two descriptions agreeing with each other, that is, not making statements that cannot be simultaneously true.
construction
In UP, phase when the final product is implemented.
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.
consumer
A client in SOA.
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).
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.
controller
In the MVC, the controller is the component that handles all user inputs which affect the model.
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.
copyright law
The automatic legal protection afforded to an individual or organisation that publishes the expression of an idea, including software.
correct
A correct system is one that meets all its requirements.
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.
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.
cultural requirement
A non-functional requirement relating to the people involved in the product’s development and operation.
cyclomatic-complexity metric
A measure of the complexity of a method by counting the number of independent paths through a method body.
data-centred
Architectural style where there is a data provider which is a centralised store of persistent data.
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.
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.
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.
data loss
The amount of data lost because the system fails to record it.
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.
defect
A verified lack of conformance to requirements.
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.
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.
denial of use of service (or loss of access)
Attack consisting of the denial of service to authorised users.
dependency injection
A Java EE container service that creates and manages an EJB object ‘injecting’ the necessary references into the client.
deployment
Configuring code to give a runnable system.
deployment model
A UML model describing how the components of a system are to be mapped onto different machines and how they will communicate.
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.
