ttool_development_infrastructure.tex

There is another gradle configuration file in the root folder of TTool:
\texttt{settings.gradle}. The purpose of this file is to list the sub-projects
of TTool. It should thus be modified when a new sub-project is created or if you
want a sub-project not to be compiled when calling \texttt{gradle build}.

In order to build all projects, run:
\begin{verbatim}
gradle build
\end{verbatim}
or 
\begin{verbatim}
gradle :ttool:build
\end{verbatim}
if you only want to build TTool.

\subsection{Executing TTool}
When TTool is executed, it fetches configuration settings from a
\texttt{config.xml} file and modifies it when closed. When you build TTool, a
default \texttt{config.xml} file is copied from
\texttt{ttool/runtime/config.xml} to \texttt{bin/config.xml}. As the
\texttt{bin} folder is not tracked by git, you can modify this configuration
file without committing your personal changes to the distant repository---which
you should not do. However, building TTool once again would replace your
personal \texttt{bin/config.xml} with the generic
\texttt{ttool/runtime/config.xml}, losing the changes you made on your
configuration file.

A better way to use your personal configuration file through different TTool
builds is to keep your own copy of \texttt{config.xml} outside of the
\texttt{bin} folder (which is removed when calling \texttt{make ultraclean}).
You can either create your own configuration file anywhere on the repository and
be careful not to add it to be tracked by git, or put it in a location where it
would not appear when doing a \texttt{git status}: either outside of the TTool
folder, or in a \texttt{.ttool} subdirectory which is explicitly ignored by git:
\begin{verbatim}
$ mkdir .ttool
$ cp ttool/runtime/config.xml .ttool/
\end{verbatim}
You could thus either call ttool directly:
\begin{verbatim}
$ java -jar bin/ttool.jar -config .ttool/config.xml
\end{verbatim}
or copy \texttt{ttool.exe} to \texttt{.ttool} subdirectory and modify it:
\begin{verbatim}
$ cat .ttool/ttool.exe
#!/bin/sh

java -version
cd .ttool;
java -Xmx1024m -Djavax.net.ssl.trustStore=ServerKeyStore \
    -Djavax.net.ssl.trustStorePassword=123456  -jar ../bin/ttool.jar \
    -config config.xml -experimental -debug -avatar -uppaal -launcher

$
\end{verbatim}

\newpage

% \section{GUI Automated Tests}
% \subsection{Research Stage}
% In order to find the right framework, it needed to put some criteria in our research to determine : \textit{What is a good GUI automated testing framework ?}
% After research, to answer this question, we need : \textit{"Flexibility, Capacity to work with the other framework already implemented and to be updatable"}
% But this criterias are not enougth to make a good and stable framework. \newline
% Then, for it, the team added the following criteria :
% 
% \begin{itemize}
%   \item \textbf{Work on all operating systems}: to work on MacOS, Linux and Windows
%   \item \textbf{Good Documentation}: to have a simple, understable documentation wioth possibly tutorials or others things
%   \item \textbf{Support Java}
%   \item \textbf{Support Swing}
%   \item \textbf{Open Source}: and possibly have a simple meaning to see the source
%   \item \textbf{Test Automation}: Unit test with a robot
%   \item \textbf{Regression Testing}: re-running functional/non-functional test to ensure that previously developed and tested software still performas
%   \item \textbf{Flexible}
%   \item \textbf{Record and Replay capabilities}: to record and replay the test
%   \item \textbf{Living Framework}: Updated regulary
%   \item \textbf{Work with other frameworks}
% \end{itemize}
% 
% After a few weeks of research, it had been decided to choose the framework named \textbf{AssertJ}
% 
% \subsection{AssertJ}
% AssertJ is a project developed by \textbf{Joel Costigliola}, which purpose is to rovides a fluent interface for writing assertions. 
% AssertJ is a fork of a previous project named \textbf{FEST Assert}. Its main goal is to improve test code readability and make maintenance of tests easier.
% AssertJ works like a Java Library and support also Swing.\newline
% In order to create the automated tests sequence, we use a part of the library, named \textbf{AssertJ Swing}.
% AssertJ Swing is based on JDK standard types assertions and can be used with either JUnit or TestNG. \newline
% The current verion of AssertJ Swing use in this project is the \textbf{3.8.0}, which works with \textit{Java 8} or higher.
% 
% \newpage
% 
% \subsection{Coding Instructions}
% Before doing any tests, make sure that all the libs are present and available. \newline
% If you are coding under an Integrated Development Environment (IDE) as Eclipse or IntelliJ, you should also download the AssertJ plugin. More informations here for :
% 
% \begin{itemize}
%    \item \textbf{Eclipse}: \url{http://joel-costigliola.github.io/assertj-eclipse-plugin/}
%    \item \textbf{IntelliJ}:\url{https://plugins.jetbrains.com/plugin/10345-assertions2assertj}
% \end{itemize}
% 
% All the files about this automated sequence of tests, are in the following directory : \textbf{ttool/src/test/java/ui/bot/}
% 
% \subsubsection{File Instructions}
% In order to create a class of tests, the developer need to find the package \textbf{ui.bot}, then to click on it and to select the tab \textbf{New/Class}.The developper will see the following window appear as in figure~\ref{fig:image15}:
% 
% \begin{figure}[H]
% \begin{center}
% \includegraphics[width=0.8\textwidth]{images/image16.png}
% \end{center}
% \caption{}
% \label{fig:image15}
% \end{figure}
% 
% The developer only need to change one thing: the superclass of the class. The superclass has to be from \textbf{AssertJ library}, and the most useful one is the superclass \textbf{AssertJSwingJUnitTestCase} \newline
% The example in figuree~\ref{fig:image16} is what the developer should find as superclass.
% 
% \begin{figure}[H]
% \begin{center}
% \includegraphics[width=0.9\textwidth]{images/image17.png}
% \end{center}
% \caption{}
% \label{fig:image16}
% \end{figure}
% 
% Now that constraint is done, here is the following files instructions:
% 
% \begin{itemize}
%   \item \textbf{Avoid bad names}: for the files, it has to be clear on what the developers are doing on the file itself.
%   \item \textbf{Not too much tests by files}: no more than 10 tests by files. Its avoid to have files with a lot of tests, to be lost between some tests, to have file with too much lines and also to have tests that have no record with the name of the file. Its allow the developer to find more quickly tests and to ensure the name of the file.
%   \item \textbf{Following the previous instructions}: see ~\ref{sec:code_info}
% \end{itemize}
% 
% The main function of each file will, if the developer do his job fine, have to extends \textbf{AssertJSwingJUnitTestCase}.Thus the developer will have to implement a method named : \textbf{onSetUp()} \newline
% This method has for purpose to initializes the test fixtures and to initializes also the frame on which tests are based. Here is an example of what could be the method :
% 
% \begin{verbatim}
% @Override
% protected void onSetUp() {
%    Main frame = GuiActionRunner.execute(()-> new Main(false, false, false, false, false, false, false, false, false, false, false, false, false));
%    window = new FrameFixture(robot(), frame.getFrame());
%    window.show();
% }
% \end{verbatim}
% 
% In this example there is some points to clarify. First of all the Main obeject is an object containing a frame (the frame on which the tests are based). The robot() in the definition of FrameFixture is not forced. The robot() allow to automate the test. Finally the window.show allow the user to see all the tests on the frame.\newline
% At the end of the file, it is better but not forced to have a method called \textbf{onTearDown()} whose aim is to clean up the frame fixture, thanks to the method named \textbf{cleanUp()}.
% Here is an example of the method onTearDown:
% 
% \begin{verbatim}
% @Override
% protected void onTearDown() {
%    super.onTearDown();
%    window.cleanUp();
% }
% \end{verbatim}
% 
% \subsubsection{Test Instructions}
% The following rules are:
% 
% \begin{itemize}
%   \item \textbf{@Test}: First of all, before eveything you need to precise that the method is a test. For that, the developer only need to put \textbf{@Test} before the name of the function
%   \item \textbf{Name}: Clear name in order to understand the meanning of the test
%   \item \textbf{Description}: Need to be clear and not too long on the subject of the test
%   \item \textbf{Trace in Console}: As saw in \ref{sec:debug_info}, the developer need to use TraceManager.addDev() to put some words in the console. Now the real utilisation of TraceManager here is to inform what the test is doing and to have a trace in the console. The fact that there is trace in the console allow to debug and to know where a test could fail.\newline
% The developer need to put a trace before and after an action is performed
%   \item \textbf{Debug}: For that the developer can usesome of the functions developed in the file UsefulTools.java. This file has some functions useful for debugging or even just transform a string into KeyEvent for an input
% \end{itemize}
% 
% With all the rules, here is an example of a fine test:
% \begin{verbatim}
% private FrameFixture window;
% private UsefulTools ut;
% private boolean debug = true;
% 
% @Test
% public void createANewFile() {
%    /*
%     * Description : Verify if TTool can create a new file, by clicking on the File menu then on
%     * the tab New. Then right click on it.
%     */
% 
%    TraceManager.addDev("==============" + System.lineSeparator() +
%                        "MainFrameTest: createANewFile: Started");
%    JMenuItemFixture jmf = window.menuItem("File New");
%    TraceManager.addDev("MainFrameTest: createANewFile: Creating a new file by clicking on New");
%    jmf.click();
%    if (debug)
%       ut.debugThread(3600, "MainFrameTest: createANewFile: ");
%    TraceManager.addDev("MainFrameTest: createANewFile: File created");
% 		
%    TraceManager.addDev("MainFrameTest: createANewFile: Right clicking on the file");
%    window.rightClick();
%    if (debug)
%       ut.debugThread(3600, "MainFrameTest: createANewFile: ");
%    TraceManager.addDev("MainFrameTest: createANewFile: Done clicking");
%    TraceManager.addDev("MainFrameTest: createANewFile: Finished" + 
%                        System.lineSeparator() + "==============");
% }
% \end{verbatim}
% 
% \subsubsection{Run as Configuration}
% 
% When you create a Configuration for a file of tests, in order to not have some bugs, you need to had some others files in the \textbf{Bootstrap Entries} \newline
% \begin{itemize}
% \item \textbf{AssertJ Swing}: you need to had all the assertj libraries for the swing (and of course the last version of them)
% \item \textbf{Ressources}: in \textbf{/src/main/}
% \item \textbf{src}
% \end{itemize}
% 
% As you can see in the following figure. Then you will need to save it. In order to save your configuration, you will need to go to the section \textbf{Common} and to save the configuration as \textbf{Shared file}
% 
% \begin{figure}[H]
% \begin{center}
% \includegraphics[width=0.9\textwidth]{images/image18.png}
% \end{center}
% \caption{}
% \label{fig:image17}
% \end{figure}
% 
% \newpage 

\section{TTool Installer}

This section documents the installer that was developed for TTool. The installer is using the IzPack tool for packaging Java applications.

\subsection{IzPack}

IzPack is an installer generator for the Java platform. It produces lightweight
installers that can be run on any operating system where a Java virtual machine
is available. Depending on the operating system, it can be launched by a
double-click or a simple 'java -jar installer.jar' on a shell. More information on IzPack can be found at:

\begin{itemize}
\item Main Page: \url{http://www.izforge.com/izpack/}
\item Documentation: \url{https://www.izforge.com/izpack/izpack-doc.pdf}
\end{itemize}

The current version of IzPack used by TTool is 5.1.3.

\subsection{Sources}

The sources of the installer are located in the TTool-Private Gitlab project at \url{https://gitlab.telecom-paris.fr/mbe-tools/TTool-Private/tree/master/installer}. 

\subsection{Configuration File}

The file \emph{install.xml} specifies the main configuration of the installer. The parameters are:

\begin{itemize}
	\item \textbf{info}: Section for project's informations.
	\item \textbf{guiprefs}: Graphical preferences (e.g.: size of window)
	\item \textbf{locale}: Set which language can be used in the installer
	\item \textbf{ressource}: All files used for by installer (html, images, etc.)
	\item \textbf{panels}: All panels used for the installer (in appearing order)
	\item \textbf{packs}: Sources of TTool, divided in packs
\end{itemize}

\subsection{Operating System Configuration}

There are some configuration files dependent on the operating system:

\begin{itemize}
	\item \textbf{Windows}: Named config\_win.xml
	\item \textbf{Linux}: Named config.xml
	\item \textbf{MacOs}: There is currently no configuration file for MacOs
\end{itemize}

\subsection{Companion Tools}

Besides installing TTool, the purpose of the installer is to install the many
companion tools of TTool such as \emph{Gtkwave} and \emph{Proverif}. The
binaries for those tools can be found under directory \emph{installer/lib}.

\subsection{Compilation of the Installer}

First, you have to export in an environment variable named \emph{JAVA\_HOME} the
path to your Java virtual machine directory (for example, /usr/lib/jvm/). The
script to compile the installer is \emph{src/compile.sh} passing the xml
configuration file of the installer as argument. In order to test the installer,
make a copy of the \emph{installer.xml} file and edit the paths to set the TTool
installation directory (IzPack does not allow to use a variable for this path).
However \textbf{do not push your changes ot the repository!} The install.xml is
configured for Ludovic Apvrille's computer and should stay as is for the
automatic build of the installer. In order to launch the installer, execute the
\emph{installer/src/install.exe} file from the \emph{installer/src} directory.

\section{Adding a Graphical Operator to a Diagram}
This section addresses the adding of a specific graphical component to a diagram. To better show how to do this, we use the example on how we have added a FPGA component to the DIPLODOCUS deployment diagram. A FPGA is a \textit{computation unit}, just like a CPU, but the steps listed are valid for any kind of graphical component like memories or communication nodes, of for any other diagram of TTool. A few things to remember:
\begin{itemize}
\item Add each new file (e.g. java file) that you create to the git repository, e.g.:
\begin{lstlisting}[showspaces=true, language=bash, commentstyle=\color{pgreen},
keywordstyle=\color{pblue}, stringstyle=\color{pred}, basicstyle=\ttfamily]
$git add myNewJavaFile
\end{lstlisting}
\item Remember also to change properly the \texttt{import} at the beginning of a java file if necessary. 
\end{itemize}
Adding a new component requires a serie of steps listed as follows: 

\paragraph{Deployment diagram:} The complete list of diagrams is located in \texttt{.src/ui} directory. In order to add a graphical component to the diagram we are interested in (e.g., \textit{TML Deployment Diagrams}), we first need to locate the corresponding sub-directory, in our case:  \texttt{tmldd}. Since our FPGA component is very similar to  the CPU component, we duplicated the class \textit{TMLArchiCPUNode.java} naming it \textit{TMLArchiFPGANode.java}. The main changes to do in this new class are: 
\begin{itemize}
\item \textbf{Stereotype}. Change the \texttt{String stereotype} value

\item \textbf{List of attributes}. Modify the list of attributes by adding or removing items: for example, we do not need the parameter \textit{number of cores} to describe the FPGA, so we removed \texttt{private int nbOfCores = HwCPU.DEFAULT\_NB\_OF\_CORES;}. Similarly, we need  a parameter that expresses the \textit{capacity} of the FPGA in terms of logical gates, so we added a new attribute.

\item \textbf{Manipulating attributes}. In order to manipulate the attributes, we weed to add/remove the corresponding setter/getter methods.
\texttt{private int capacity = HwCPU.DEFAULT\_CAPACITY;}

\item \textbf{Graphical connection and manipulation}. You can update graphic parameters such as: the connecting points (to connectors, including connectors for comments), the fact to make the diagrams editable, movable, removable, \ldots 

\item \textbf{Update the edition of the components' parameters}. Handle the lines like \texttt{if (dialog.getNbOfCores().length() != 0)} according with your previous modifications on the parameters' list. You can notice the usage of the \texttt{tmp} variable to recover the values in the case that the user closes the window or enters a non valid data (e.g., a word instead of a number).

\item \textbf{Unique identifier}. The method \texttt{public int getType()} returns a unique ID, defined in \texttt{TGComponentManager.java}. You thus need to update the two classes accordingly e.g., \texttt{public static final int TMLARCHI\_FPGANODE = 1116;} in \texttt{TGComponentManager.java} and  \texttt{public int getType()}. You have to choose an available number, and be sure to complete the switch/case in  \texttt{TGComponentManager.java}: one to create the component when the identifier is given, and one to obtain the identifier from a component:

In \texttt{TGComponentManager.java} you have also to add the new value that the \texttt{tgc} variable (that represents the graphical component) can take:
\begin{lstlisting}
 case TMLARCHI_FPGANODE:
                tgc = new TMLArchiFPGANode(x, y, tdp.getMinX(),
                      tdp.getMaxX(), tdp.getMinY(), tdp.getMaxY(),
                      false, null, tdp);
                break;
\end{lstlisting}

and 

\begin{lstlisting}
else if (tgc instanceof TMLArchiFPGANode) {
            return TMLARCHI_FPGANODE;
\end{lstlisting}



\item \textbf{Saving and loading the component}. TTool handles the saving and loading of default component attributes. Yet, for the specific attributes (e.g., the capacity of a FPGA), you need to explain to TTool how to save and load them. To save extra attributes, you can use the  \texttt{protected String translateExtraParam()} method e.g. add:
\texttt{sb.append("<attributes capacity=\"" + capacity + "\" byteDataSize=\"" + byteDataSize + "\" ");}

\item \textbf{Information on the component}. If the component implements the \texttt{WithAttributes} interface, then modify the \texttt{getAttribute()} method according to the new parameters. These methods are useful for the action \textit{Show/Hide element attributes} triggered by an icon in the architectural diagram, and for displaying an information in the status bar of TTool when the mouse is brought over the component.

\end{itemize}

\paragraph{Icon:} 
\begin{itemize}
\item Icons are stored in \texttt{./src/main/resources/ui/util}. You can easily use GIMP to create one of them, modifying an existing one to be sure to fit the proper dimensions. Don't forget to add the new icons to the git.

\item The class \texttt{.src/main/java/ui/util/IconManager.java} is responsible to load the icons when TTool starts. Let's assign a number to our icon. The convention is: an odd number for the \textit{big} sized icons, an even number for the \textit{small} sized icon. So, we assigned number 1120 to our new fpga icon: \texttt{private static String icon1120 = "tmlfpganode.gif";}

\item Next to the \texttt{//TDD} comment, create an object icon: \texttt{public static ImageIcon imgic1120;}

\item Associate the icon object to the previously defined string value: \texttt{imgic1120 = getIcon(icon1120);} 
\end{itemize}

\paragraph{Associate an action to the icon: } Actions list is contained in the file \texttt{.src/main/java/ui/TGUIAction.java}.
\begin{itemize}
\item The first step is to associate a unique number to the action that we aim to create. Let's search in the code for the parameter \texttt{public static final int NB\_ACTION = 474;}. All the actions are in a table named \texttt{private static final TAction [] actions = new TAction[NB\_ACTION];}. So, the number associated to our action should be equal to the number present in \texttt{NB\_ACTION}. Moreover, we need to reserve one more space for the action in the table, so we increment \texttt{NB\_ACTION} by one. In this case, \texttt{public static final int NB\_ACTION = 475;}.

\item Declare the action: taking inspiration from \texttt{public static final int TMLARCHI\_CPUNODE = 218;}, we similarly  create \texttt{public static final int TMLARCHI\_FPGANODE = 474;}

\item Then, add the action to the table, with the previously defined icon and a short description: 

\begin{lstlisting}
actions[TMLARCHI_FPGANODE] = new TAction("add-tmlarchi-fpganode", 
       "Add a FPGA node", IconManager.imgic1120, 
       IconManager.imgic1120, "FPGA node", "Add a fpga node to the 
       currently opened DIPLODOCUS architecture diagram", 0);
\end{lstlisting}

\item Finally, it is necessary to create the graphical component of such ID when this action on a FPGA node is triggered. To do that, open \texttt{.src/main/java/ui/ActionPerformer.java} and search for the string \texttt{CPUNode}. Then, similarly add:
 \begin{lstlisting}
else if (command.equals(mgui.actions[TGUIAction.TMLARCHI_FPGANODE]
		.getActionCommand())) {
            mgui.actionOnButton(TGComponentManager.COMPONENT, 
            TGComponentManager.TMLARCHI_FPGANODE);
\end{lstlisting}

\end{itemize}

\paragraph{Show and enable the icon in the diagram toolbar: }
\begin{itemize}
\item Open \texttt{.src/main/java/ui/tmldd/TMLArchiDiagramToolBar.java}
\item \textbf{Set the FPGA action as active} when the corresponding diagram is opened:
\begin{lstlisting}
protected void setActive(boolean b) {
     //[...]
     mgui.actions[TGUIAction.TMLARCHI_CPUNODE].setEnabled(b);
     mgui.actions[TGUIAction.TMLARCHI_FPGANODE].setEnabled(b);
     mgui.actions[TGUIAction.TMLARCHI_HWANODE].setEnabled(b);		
     //[...]
}		
\end{lstlisting}
\item\textbf{ Adding the FPGA icon to the toolbar}. 
Now, we are going to add the icon to the toolbar. 
Notice that the order is important! For example, we aim to place the FPGA icon before the HWACC icon and after the CPU node. Let's notice also that in order to add the icon we do not manipulate the icon object, but the action that contains the icon.
 
Since the implementation of the FPGA block was not still not supported by the DIPLODOCUS simulator when we created the graphical component, we hide the icon to regular users, and make it available only running TTool with the command line option \texttt{-experimental}. So, within the same class we can add the condition:
\begin{lstlisting}
if (mgui.isExperimentalOn()) {
            button = this.add(mgui.actions[TGUIAction.
                     TMLARCHI_FPGANODE]);
            button.addMouseListener(mgui.mouseHandler);
}
\end{lstlisting}
\end{itemize}

\paragraph{Dialog window:} Since the FPGA component is "editable", a double-click on it should open a dialog window in order to be able to edit the attribute of the corresponding component. The classes that handle the dialog box are usually located in \texttt{./src/main/java/ui/window}. Some complex components have these classes in their own subdirectories. 
\begin{itemize}
\item Let's have a look to \texttt{JDialogCPUNode.java}, copy/paste it, git add and modify the import.
\item Let's modify properly this new JDialog class. For example, we modified the JText fields and the getters in accordance to the declared parameters, we modified the constructor and we removed the stuff in which we're not interested on. The latter includes the things related to the MEC (useful for the code generation), tracemode, the useless grids, everything after the getters. 
\end{itemize}

\paragraph{Pivot language}.  TTool contains an internal pivot language that is used as an entry point to generate formal or textual specifications (e.g., C code). We therefore need to enhance the pivot language with the FPGA component.

\begin{itemize}
\item Let's have a look to \texttt{src/main/java/tmltranslator/HwCPU.java} and copy/paste it renaming the file \texttt{src/main/java/tmltranslator/HwFPGA.java} (don't forget to change the imports, and to add the new file to the git, as usual).

\item Modify the class according to your previous modifications. In particular, ensure the coherency between the list of attributes of your graphical component and of your pivot component. Then set their default value. Modify \texttt{toXML()} (useful for plugins) and \texttt{getType()} methods as well. 

\item Some attributes seems to be absent from the class  (e.g., \texttt{EXECI} and \texttt{EXECC}), but they are actually inherited from  \texttt{HwExecutionNode.java}, in the same package.

\item We also need to update the translation from the graphical DIPLODOCUs diagram to the pivot language. This translation is performed by the \texttt{.src/main/java/ui/GTMLModeling.java} class. In this class, we do quite exactly as for  \texttt{HwCPU cpu} and \texttt{TMLArchiCPUNode node}.
\end{itemize}


\paragraph{Textual representation (TML)} All the graphical components of DIPLODOCUS have a correspondence in  a textual format called TML. We thus need to add the FPGA component to the textual format as well, and to update the save and load functions to/from TML.

\begin{itemize}
\item Open \texttt{./tmltranslator/TMLArchiTextSpecification.java}.

\item Modify the string \texttt{private String keywords[] = {"NODE", "CPU", "FPGA", "SET", "BUS", "LINK", "BRIDGE", "MEMORY", "MASTERCLOCKFREQUENCY", "DMA"};} adding the FPGA word.

\item Exactly like for \texttt{private String cpuparameters[]}, declare \texttt{private String fpgaparameters[] = {"capacity", "byteDataSize", "mappingPenalty", "goIdleTime", "maxConsecutiveIdleCycles", "reconfigurationTime", "execiTime", "execcTime"};}. 

\item In the method \texttt{public String makeNodes(TMLArchitecture tmla)} let's declare \texttt{HwFPGA fpga;} variable, then have a look to \texttt{if (node instanceof HwCPU)} and handle similarly the corresponding FPGA case.

\item To load FPGA nodes from TML specification, consider the following method \texttt{public int analyseInstruction(String \_line, int \_lineNb, String[] \_split)}:
 \begin{lstlisting}
if (_split[1].equals("CPU")) {
                HwCPU cpu = new HwCPU(_split[2]);
                tmla.addHwNode(cpu);
            }
\end{lstlisting}
and do the same for the FPGA component.

\item Finally, in the same method, have a look to the case \texttt{if (node instanceof HwCPU)} and do the same for FPGA. To make the comparison easier, capitalize the name of the FPGA's parameters. 
\end{itemize}   

\end{document}