Professional Documents
Culture Documents
In the context diagram, you have to fill a table like this one:
External sensors If specified in the text you must The logic of the sensor (generally
insert the type and voltage such specified in the text) like
as: bipolar connector 0-3V. A Boolean open = something,
physical interface could be also close= something.
the Bluetooth protocol. Or also a description of the
mechanism is acceptable.
User Typically, PC or smartphone but GUI in the first case and in the
if it interacts with something second case something which
else and it is specified in the text describes how it works like
you put like buttons, screen, screenshots, recordings, etc.
keyboard, etc. In other words,
you describe the interface.
It is important to keep in mind that the table must have all the actors which are external to the system and
for this reason you have to read carefully the text in order to understand if they are considered inside or
outside. However, something that I notice doing the exercise is:
I. When a user has to register to a service before using it a possible actor that we put is the e-mail
gateway necessary to send e-mail to users.
II. If there is a website for the application we are modelling at 99% there is the Admin of the entire
system but also if there is a server in which we store data because we need someone to control and
manage them.
III. If we are in a situation in which it should be possible to receive (or send) something with post-
services we can include as external actor a logistic company.
IV. About GPS we can say that typically it is integrated in the smartphone so often it is omitted (the
same for the camera).
V. Pay attention to the bar code reader mentioned for the Clerk/Employee, if it is inside the system
(for example inside each POS system) it should not appear in the context diagram.
Remember always to be consistent between system design and context diagram; in the system design,
external actor are not allowed!
Lets see a possible example of what we explain above with a Sketch of the context diagram.
2. The second step is to design the glossary using UML:
As we can see from the picture above the user to employ certain services, offered by the Meteo
Service, need to make a subscription (if a subscription is not necessary we can substitute it with the
class Account if the user need it to access the system) and this imply the payment for a
month/year/etc. fee and for that reason that we need the class Payment record/Transaction
(similar could be the presence of a delivery record if we want to keep track of something that a user
has been sent/received). On the right, we have Forecast service and Report service that inherit the
property of the more general Service.
In other cases, we can deal a situation similar to this one in which we have, for example, to define
some jobs necessary for the maintenance of a car/motorbike/etc. It is important to keep them
separate because Job description
it is used simply to describe a
generic job, so it is a list of all the
possible job available for that car
model while the class Job is
necessary to keep track of which
job has been executed on the car
involved. So this way of thinking
may be applied every time we
have a similar situation in which
on one hand we have a list of
possible actions available and on
the other hand we have to record accurately one of them.
4. Description of a scenario:
Supposing that we want to describe a user who logs one training composed of two parts.
Postcondition: Training T is available with the two parts generated, P1 and P2.
In the first point, we said that we have to pay attention to be consistent between this and the
context diagram. In this case we report what is inside the system; for example, when there is an
administrator who control data and store them in a server this will be one of the element of our
system design. Another example could be a tablet used in a shop to read bar code and to connect to
the net to check if it is available another piece of the product chosen.
6. In the black box testing you have a function like:
int triangleType(int side1, int side2, int side3) which returns 1 if the three sides define an equilateral
triangle, 2 if isosceles, 3 if scalene, -1 if it is not possible to compose a triangle and you have to use
equivalence classes and boundary conditions.
To solve this exercise in the table you put the parameter of the given functions, the possible results,
a column to indicate if the case is valid or not and test cases:
As reported in the table you have to find out all the possible combinations supported by different
test cases in order to see if they result valid or not. Since in that case we deal with a triangle it is
obvious that well find the first valid output when all the three sides are positive integers.
Another example could be the following one: given the function int times[]
computeWaterTiming(int start, int duration, int nTimes) the timer considers only a one day range.
The first parameter defines the time (in minutes) when the valve opens, the second parameter the
duration (in minutes) the valve remains open and the last one the number of times the cycle is
repeated and it could assume only the value 1,2 and 3. If it is 1 it means that the cycle is repeated
every 24 hours, if 2 every 12 hours and if 3 every 8 hours. If the function returns correctly we obtain
an array otherwise an error.
Like the previous exercise we fill the table with the parameters of the function but we add a
condition: start+duration*Ntimes <= 1440. This is good because a day is composed of 1440 minutes
so we can define the three equivalence classes that are: [minint, 0[, [0, 1440] and [1441, maxint]
and this can be used both for start and duration. Differently for Ntimes in which we have only 3
possible values and so the equivalence classes are [minint, 0] and [4. maxint]. For the boundary
condition, instead, we have to test for start and duration values -1, 0, 1440, 1441 while for Ntimes
values 0, 4.
Last example:
Double telCallCost(int startTime, int endTime, int zone) where the first two parameters are in
seconds over a 24 hours day and the cost depends on the zone. Calls longer than 5 minutes get a
10% discount. The cost rates are: 1cent/sec for Zone1, 2cent/sec for Zone2 and 3cent/sec for Zone3.
startTime endTime Zone endTime > Call length Valid/Not Test cases
startTime vaid
[minint, 0[ - - - - I T(-1, 10, 1; err)
[0, 86400[ [minint, 0[ - - - I T(1, -1, 1; err)
[0, 86400[ [0, 86400[ [minint,0] - - I T(1, 1, -2; err)
[0, 86400[ [0, 86400[ [1,3] F <5m V T(86351, 1, 1; 50)
[0, 86400[ [0, 86400[ [1,3] F >5m V T(86101, 1, 1;
270)
[0, 86400[ [0, 86400[ [1,3] T <5m V T(2, 102, 1; 100)
[0, 86400[ [0, 86400[ [1,3] T >5m V T(0, 300, 1; 270)
[0, 86400[ [0, 86400[ [4,maxint - - I T(1, 3, 5; err)
]
[0, 86400[ [86400, - - - I T(1, 90000, 1; err)
maxint]
[86400, - - - - I T(90000, 1, 1; err)
maxint]
Also in that case we fill the table with the parameters of the function and the constraints extract
from the test such as the call length. We assume that seconds start from 0 and the total seconds in
a day are 86400 and we also assume that a call can start in a day and end the following one that
means endTime < startTime which is another parameter that we put in the table above. For the first
two we have that the equivalence classes are [minint, 0[, [0, 86400], [86400, maxint] while for the
zone we have [minint, 0], [1, 3] and [4, maxint].
To understand how it works the function we use two test cases:
T(86351,1,1) we have as result 50 because we start at second 86351, 49 before 0 and we end at 1
so 49+1, the call last less then 5minutes and we are in Zone1 where the cost is 1cent/sec. Instead if
the call last more than 5m and the test case is T(86101, 1, 1) we have 299+1=300, we applied the
10% which is 30 so the final result is 300-30=270.
7. In this case we have to perform a white box testing in which is asked to define the control flow
graph and define test cases to obtain the highest possible node coverage, edge coverage, multiple
condition coverage, loop coverage and path coverage.
1) int function(int x, int z){
2) int k, j;
3) int value = 0;
4) if (x < 0) return -1;
5) for (k = 0; k < x; k++){
6) If (z > x || z < 20){
7) for (j = 0; j < k; j++){
8) value ++;
9) }
10) }
11) }
12) return value;
13) }
Loop coverage: for each loop, you should have 3 test cases: one that does not enter in the loop, one
that enter and complete the iteration just once and the last that in which it enters many times.
Edge coverage: the aim is to cross in the graph, using a certain number of test cases, all the possible
edges (links between nodes).
Node coverage: number of test cases necessary to cross all the nodes of the graph.
Path coverage: try to cover all the possible combinations; se c una biforcazione seguita da unaltra
biforcazione bisogna seguire tutti i possibili rami con le varie combinazioni. Generalmente negli
esami presente il loop e quando lo si trova bisogna fare il numero di path possibili allinterno del
loop (ignorandolo e facendo solo gli IF) elevato al numero di volte che cicla che, se dipende da un
input, pu essere fino a maxint. Se si hanno due loop annidati, per esempio, si parte da dentro il
primo loop e si ottiene ((numero_path_dentro_loop)^numero_cicli1)^numero_cicli2. Normalmente
unfeasible.
Coverage Type TC for 100% coverage Coverage obtained Test cases
Node 3 100 T1: compute_tax(6000)
Edge 4 100 T1
Multiple Condition Not Available - -
Loop (at line 7) 1 33% T0: compute_tax(1000)
Path 4 100% T0
T1
T2: compute_tax(16000)
T3: compute_tax(32000)
In this case we notice that the loop at line 7 does not depend on the variables in input and it will be
executed three times every time we execute the function. For this reason, it is not possible to
obtain 100% coverage but just 33% (1/3). Theoretically the paths are 32:
23 ( if inside the for )4 (if else chain) but only 4 are feasible and are the ones corresponding
to the four test cases because paths depend on the value of parameter wage with the same test
defined for node and edge coverage is possible to cover all paths.
8. Q U E S T I O N S
Describe shortly the Scrum technique:
o Sprints iterations of fixed duration (at maximum 4 weeks) producing a working
application in increments. A sprint is a session of work delimited in time, with a
precise aim that, when it concludes, produces a usable derivable. Ranking of
requirements by end user/customer. Stand up meeting (15 minutes) every day
necessary for coordination.
Provide an example of a configuration item:
o A CI is a unit of the configuration management system. It may be a product, a piece
of software, one or more documents, one or more files. It has a name and a version
number, a new version is created with the commit operation and all its version
numbers are kept retrieving any version. For example, a CI may be Requirement
document v1.0 at 2015 07 11.
What is a Configuration?
o A configuration is a set of Configuration Items (CI), each in a specific version, and it
can be seen as a snapshot of the software at certain time. Some Cis may appear in
different configurations, and also configuration has a version number.
Describe the copy modify merge strategy for controlling changes. List advantages and
disadvantages:
o Many users can modify but the results are merged; when more users check-out
something, then someone commits a modified version, the next users will be
prompted with the message specifying that they nee to merge the documents. The
advantage of this approach is the fact that is more flexible rather than the others
because it allows more people working in parallel even though it is trivial about
conflicts resolution.
Describe shortly the Pair Programming technique:
o Pair programming is part of the extreme programming; for each person writing
code there is another person thinking about improvements and test cases. This
improves qualities but may waste development time. The correct pairing is
important and not too easy to realize.
Describe shortly the MVC Design pattern:
o The model view control design pattern is used in applications in which the GUI is
highly important and interactive to avoid mixing the data with how they are
presented and how user interacts with them. The pattern divides these three things
in three sections: model (describes the data; for example in a spreadsheet the
model is a matrix), view (how one or more model is presented; for example in a
spreadsheet the view is a table with certain borders, coloured cells and so on) and
control (manages user interactions; for example in a spreadsheet it can be a set of
listener on each cell/button).
Function A calls function B, that calls function C. You want to apply bottom up integration.
How do you proceed?
o Test C, test B+C, test A+B+C
Considering GIT, what are the three project sections that it defines, and how are they used?
o Git directory which includes everything in the project and it is what is copied when
a repository is cloned; the working directory which is a single checkout for one
version of the project and finally the staging area that contains information about
what will go into the next commit.
What is the typically lifecycle for a change? (draw states and transitions)Pu andare?