summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report/test.tex~
diff options
context:
space:
mode:
Diffstat (limited to 'notFinishedCode/Report/test.tex~')
-rw-r--r--notFinishedCode/Report/test.tex~27
1 files changed, 25 insertions, 2 deletions
diff --git a/notFinishedCode/Report/test.tex~ b/notFinishedCode/Report/test.tex~
index 7f8188a..40ca64a 100644
--- a/notFinishedCode/Report/test.tex~
+++ b/notFinishedCode/Report/test.tex~
@@ -188,6 +188,23 @@ However, all the test tasks even after deleting them from \emph{TempTaskTable} a
\newpage
\section{Software design} % section 2.1
+Software design was the next step after we analyzed the problem and developed a plan how to proceed further. Good analysis and planning with poor algorithmic implementation is valueless.
+During the work on the project, we had spent most of our time for software design.
+We kept in mind that our software should satisfy major paradigms of software engineering,
+like compatibility, extensibility, maintability, modularity, relliability, security, fault-tolerance and usability.
+The software engineering design concepts were achieved following way:
+\begin{itemize}
+\item Compatibility - we used Python and MySQL which are multiplatform and work on major OS
+\item Extensibility - new parts of code can be easily added by just modifying the classes
+\item Maintability - the test software can recognize new added cell phones to the system and dynamically
+\item Mudalarity - the components are independent black boxes, they are tested and validated independently
+\item Reliability - we use mutex locks to perform tests and database transaction operations to insert data into the database
+\item Security - all communication channels are encrypted with asymmetric key cryptography
+\item Fault-tolerance - the classes were designed to continue operating even if error events appear and handlers are logging everything
+\item Usability - we tried to create the
+\end{itemize}
+
+
\begin{figure}[ht!]
\centering
\includegraphics[width=140mm]{activityControllerEdited.png}
@@ -297,7 +314,13 @@ At the start we did not have a cable supplied for the Siemens S55 phone. We cont
\subsection{Cables for the cell phones}
Due to the fact that we had used 5 cell phones on a single computer, the best solution was to order 5 USB cables.
-Konrad bought 5 cables for 5 Siemens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them.
+Konrad bought 5 cables for 5 Sie\begin{itemize}
+\item Triangles represent BTS stations
+\item Cellphones represent the external networks (E-Plus, Vodaphone, T-Mobile and O2)
+\item Telephone represents the landline and a telephone with a mortarboard the University telephone network
+\item Servers represent the OpenBSC and LsfKs-Asterisk
+\item Two monitors represent the SIP system
+\end{itemize} mens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them.
Once they were plugged into the USB port, Ubuntu automatically recognized the cables and installed the drivers.
The virtual serial ports were created and could be found on \emph{/dev/ttyUSBx}, where $x$ is the automatically assigned number for the port.
Some of the cables had the capability to charge the Siemens S55 phones.
@@ -313,7 +336,7 @@ response from the other side. Our approch to this problem was to build a simple
confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum
protocol\footnote{Design concepts and paradigms for the protocol design have been used from the
-``Network Protocol Design and Evaluation'' course, lectured by Stefan R\"{u}hrup}.
+``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}.
In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device
that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software