Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

TM354 > Block 3 - From architecture to product > Flashcards

Block 3 - From architecture to product Flashcards

1
Q

Adapter pattern

A

where component_A wraps component_B thereby becoming its interface;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

analysis pattern

A

a high-level conceptual-analysis solution;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

analytical completeness (FRs)

A

where SS is complete w.r.t. solely FRs;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

applet

A

a plug-in component installed in the client browser;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Architectural pattern

A

describes a high-level recurring design solution;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

architectural view

A

a model of the SS framed w.r.t. a specific stakeholder;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

architecture specialisation

A

where specific components are selected;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

assertion (handling) mechanism

A

a run-time construct evaluating SO precons / postcons / invariants;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

assertions

A

= {precons, postcons, invariants}

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

asynchronous

A

where clientComponent can carry on without waiting for serverComponent’s response

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

basis-path testing (WBT)

A

where each statement in a method is tested 1+ times;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

blackboard (data-centred)

A

an arch-pattern where users can update store and vice versa;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

black box testing (BBT)

A

testing w.r.t. component’s spec;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

boundary testing

A

where test data is produced around the partitions between the input subdomains;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

bursty event

A

where event occurs in unpredictableClusters;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

(test) case analysis (partitioning)

A

partitioning test data into subdomains;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

cloud computing

A

where all software runs on third-party servers;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

completeness (FRs)

A

where all FRs have been implemented;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

component-based development (CBD)

A

where the SS is built with pre-existing components;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

connector

A

reps the comm. between components in an arch-pattern;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

container

A

a component that creates and encompasses other objects;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

context dependency

A

where a component requires other services to provide its service;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

coupling between objects (CBO) metric

A

the number of associations a class has with other classes;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

cyclomatic-complexity metric (CCM)

A

= numberDecisionPoints + 1;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
data-centred
an arch-pattern where there is a centralised persistent data store;
26
defensive programming
where precons should always be checked;
27
dependency injection
where a container object appropriately initialises a specific object for a client;
28
deployment model
reps specific components being implemented on machines;
29
depth-of-inheritance-tree (DIT) metric
the number of anscestors a class has;
30
Design by Contract (DbC)
where precons are assumed to have been met;
31
design pattern
describes a mid-level recurring design solution;
32
enterprise architectures
SSs designed for large orgs;
33
error guessing
where SOs are tested with random data;
34
executable documentation
where code is automatically checked against documentation at run-time;
35
extreme programming (XP)
an agile software development method;
36
Factory pattern
where a specialised object creates and initialises other objects;
37
fixture
the conditions&InputData for a test;
38
flexibility
how easily the SS can be modified;
39
foreign key
a column in a database table holding a key from a different table;
40
framework
a package providing behaviour common to a variety of applications;
41
heuristic evaluation
testing the SS wihout users;
42
HTTP
an interface for web-components to exchange data;
43
idiom
a programming-language specific pattern;
44
inertial convention
where componentStates outwith postcons are assumed to be unchanged;
45
integration testing
where the emergent properties of sets of components are tested;
46
interface
the SOs of a component;
47
Java Enterprise Edition (Java EE)
a framework for consructing enterprise systems;
48
jitter
variationInLatency;
49
lack-of-cohesion-in-methods (LCOM) metric
numPairs of methods referencing the same attributes minus the numPairs that don't;
50
latency
stimulusProcessingTime;
51
layered style
where components form a chain and can only message their immediate neighbours;
52
location transparency
where consumers use a service without knowing where service is hosted;
53
Mean Time to Change (MTTC)
the averageTime to fix a bug;
54
miss rate
proportion of requests not responded to;
55
model
a simplified rep of a problemDomain or softwareSolution;
56
Model-View-Controller (MVC) pattern
``` model = database; view = UI-output; controller = UI-input; ```
57
notification pattern
where observerComponents register with a subjectComponent for updates;
58
number-of-children (NOC) metric
numImmediateDescendants of a parentClass;
59
path parameter
URI/pathParameter;
60
peer-to-peer
a cliver network;
61
performance
how well a SS can process serviceRequests;
62
pipe and filters
filter = processor; pipe = pipe
63
polymorphism
where the particular object responding to a serviceRequest is determined at runTime;
64
postcondition
an assertion that must be true on completion of a UC or SO;
65
precondition
an assertion that must be true commencement of a UC or SO;
66
presentation layer
= UI;
67
primary key
the attribute that uniquely identifies each row of a databaseTable;
68
product
the object produced by the Factory object;
69
product line
a set of related software products;
70
provided interface
the SO-outputs of a component;
71
publish-subscribe
where subscribersComponents register to receive updates from a publisherComponent;
72
quality attribute scenario
specifying an NFR in detail to inform arch-decisions;
73
Quantity pattern
gives guidance on how to rep dimensioned quantities;
74
random testing (BBT)
where testData is randomly generated for the input domain;
75
record
a row of a database table;
76
refactoring
improving clarity of an SO's code without changing without changing the SO's precons / postcons / invariants;
77
regression testing
test(allPreviousTests & newTest);
78
repository
centralised store of persistent data;;
79
required interface
the SO-inputs of a component;
80
Requirements pattern
a description of knowledge used in the elicitation of requirements;
81
response-for-a-class (RFC) metric
size(classResponseSet);
82
response set
all (own, inherited and invoked) methods of a class;
83
restart testing
testing that SS can recover from errors of internal state;
84
RESTful
= REpresentational State Transfer + ful = where a webService users a lean interface (e.g. HTTP);
85
security testing
tests that SS's security cannot be breached;
86
service-oriented architecture (SOA)
where applications are built out of loosely coupled services;
87
service-oriented pattern
where providers make services available to consumers;
88
signature
= SO-returnType + SO-name + SO-parameters;
89
Singleton pattern
where no more than one instance of a specific class is created;
90
software architecture
= components + relations;
91
software metrics
measurable quantities that inform SQFs;
92
SQF
one of the 11 attributes of a SS: - correctness - reliability - efficiency - integrity - usability - maintainability - flexibility - testability - portability - reusability - interoperability
93
sporadic event
= infrequent&Isolated;
94
start-up testing
tests that SS can start in a working configuration;
95
statelessness
= component has no memory;
96
stochastic event
occurs according to a well-defined probability distribution;
97
straight-through path
the path where all loop / if conditions evaluate to false and switch statements evaluate to default;
98
stress testing
testing that SS can operate at limits of its resources;
99
subdomain
a set of inputValues requiring the same processing = equivalenceClass;
100
test case
the conditions&Data for checking whether SO satisfies its assertions;
101
test-driven development (TDD)
tests before code;
102
throughput
numEvents dealt with in a given time;
103
unit testing
where components are tested in isolation;
104
usability testing
where UI is tested w.r.t. intendedUsers;
105
user-command testing
testing userCommands w.r.t. tolerance to syntax / dataInput errors;
106
user-defined type
a bespoke sourceAlphabet;
107
validation
checking SS w.r.t. customerRequirements;
108
verification
checking SS w.r.t. designSpec;
109
view (MVC)
UI-output;
110
viewpoint / concern
a perspective on SS w.r.t. a particular stakeholder;
111
virtual machine
a simulation of a computer;
112
weighted-methods-per-class (WMPC) metric
= sumForClass(method-CCMs);
113
white box testing (WBT)
testing w.r.t. component's code;

TM354 (3 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions