minor rewrite
This commit is contained in:
parent
7aed0cac1a
commit
9250425a61
4 changed files with 8378 additions and 46 deletions
BIN
.DS_Store
vendored
Normal file
BIN
.DS_Store
vendored
Normal file
Binary file not shown.
|
@ -147,15 +147,7 @@ Why is recording favoured over emulation, for example? How can recorded
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Section 7.1 mentions a generic module to support the development of simulators.
|
||||
Furthermore the section describes some simulators developed using the gen_fsm
|
||||
behaviour.
|
||||
Which additional features are provided by the software described in this
|
||||
thesis, which are not already present in the gen_fsm behaviour?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
In the thesis there are some unclear points:
|
||||
Specifically:
|
||||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
|
@ -167,6 +159,12 @@ In the thesis there are some unclear points:
|
|||
? Also, what is the “old work flow” in this context?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
4.2: This section states a simulation library and support for creating new
|
||||
simulators.
|
||||
Yet these are not explained like for example the convenience scripts.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
5.2: Exactly how is the quality of the simulators measured? Which metrics
|
||||
are used? Some metrics are presented here, but not motivated, also results
|
||||
|
@ -174,9 +172,21 @@ In the thesis there are some unclear points:
|
|||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
4.2: This section states a simulation library and support for creating new
|
||||
simulators.
|
||||
Yet these are not explained like for example the convenience scripts.
|
||||
7.1: mentions a generic module to support the development of simulators.
|
||||
Furthermore the section describes some simulators developed using the gen_fsm
|
||||
behaviour.
|
||||
Which additional features are provided by the software described in this
|
||||
thesis, which are not already present in the gen_fsm behaviour?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
According to 7.4, API:s and simulators must be created when they don't already
|
||||
exist, why is this not represented in the first flow chart? Does your applicati
|
||||
on provide any ways to reduce development time of simulators? The quality
|
||||
of a simulator may vary..
|
||||
You created three simple device simulators.
|
||||
How long did it take to create them? Case studies of developing these could
|
||||
motivate the usage of simulators over hardware.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
|
@ -185,13 +195,6 @@ A future improvement to the project is creating a finite state machine from
|
|||
It is unclear to us how this improves the system.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
A future improvement of the system is to implement “runtime function call
|
||||
replacement”, this directly contradicts the purpose of the thesis, which
|
||||
is to run the same code on both the simulator and the real hardware.
|
||||
Why is this considered to be an improvement?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
Also, there are some factual errors; processes do share data, and data is
|
||||
shared through message passing.
|
||||
|
@ -200,11 +203,6 @@ Also, there are some factual errors; processes do share data, and data is
|
|||
PIDs can indeed be converted to lists, using the pid_to_list/1 function.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
7.5.1 says that ember can automate the process of deploying code.
|
||||
How is this useful? What sort of code?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Section*
|
||||
Results
|
||||
\end_layout
|
||||
|
@ -233,18 +231,28 @@ How long does it take to upload the code to the hardware and how often is
|
|||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
How long, on the other hand, does it take to get to know your system, write
|
||||
the simulators and follow the steps you described?
|
||||
How long does it take to get to know your system, write the simulators and
|
||||
follow the steps you described? Is the workflow more efficient using your
|
||||
system?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Itemize
|
||||
Did you calculate a difference of time between the two approaches?
|
||||
Did you calculate a difference of time between development on the hardware
|
||||
versus in a simulated environment?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
The graphs provided are inconclusive and lack good descriptive texts.
|
||||
It is unclear which metrics are used on each axis, and exactly what is
|
||||
being measured; for instance, what is a sample?
|
||||
being measured; for instance, what is a
|
||||
\begin_inset Quotes eld
|
||||
\end_inset
|
||||
|
||||
sample
|
||||
\begin_inset Quotes erd
|
||||
\end_inset
|
||||
|
||||
?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
|
@ -254,21 +262,6 @@ The accuracy of the simulators was presented in a graph, and it can be seen
|
|||
impacts does this have on the simulation?
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
According to 7.4, API:s and simulators must be created when they don't already
|
||||
exist.
|
||||
Isn't it a huge project within itself, creating an API:s and simulators?
|
||||
Does your application provide any ways to reduce development time of simulators
|
||||
? The quality of a simulator may vary.
|
||||
There may take a long time to make it perform well and be flexible to work
|
||||
with.
|
||||
You created three simple device simulators.
|
||||
How long did it take to create them? These times could prove why the developmen
|
||||
t of simulators wouldn't be a great deal and to estimate creation time of
|
||||
other simulators.
|
||||
|
||||
\end_layout
|
||||
|
||||
\begin_layout Section*
|
||||
Language
|
||||
\end_layout
|
||||
|
@ -283,23 +276,27 @@ The language style in the thesis is not formal as it would be expected in
|
|||
\begin_layout Standard
|
||||
Some terms could be introduced better; OTP, Beagle Board, Gumstix, Ångström/Angs
|
||||
trom, distro, NAT, OS, Panda Board, VM, stub, public/subscribe, request-response
|
||||
, OS variable, ssh.
|
||||
, OS variable and SSH.
|
||||
Erlang is introduced properly, and the same could perhaps be done for these
|
||||
terms as well.
|
||||
The structure of function calls (fun/num of pars) is not obvious to the
|
||||
reader, perhaps it could be explained.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
It is hard to refer to the figures since they are not numbered.
|
||||
\end_layout
|
||||
|
||||
\begin_layout Section*
|
||||
What we would like to see ...
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
It would be interesting to see this system combined with a testing framework,
|
||||
like QuickCheck in order to create a powerful test suite which generates
|
||||
like QuickCheck, in order to create a powerful test suite which generates
|
||||
tests using real data samples.
|
||||
If the data generated by the recorder could be used as input to a testing
|
||||
framework, like QuickCheck a very powerful and random test suite could
|
||||
framework, like QuickCheck, a very powerful and random test suite could
|
||||
be created.
|
||||
\end_layout
|
||||
|
||||
|
|
BIN
report2.pdf
Normal file
BIN
report2.pdf
Normal file
Binary file not shown.
8335
report_commented.lyx
Normal file
8335
report_commented.lyx
Normal file
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue