Merge branch 'master' of https://github.com/MattePalte/ing-soft-2018-…

…paltenghi-parravicini-pellizzi

README.md

@@ -38,6 +38,9 @@ Here below there are the coverage metrics of Intellij both of the package and th
 <div align="CENTER"><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/SCREEN/screenTestPackage.png?raw=true"/></div>
 <div align="CENTER"><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/SCREEN/screenTestModel.png?raw=true"/></div>
 Here the metrics of Sonarqube:
+<div align="CENTER"><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/SCREEN/screenSonarOverall.png?raw=true"/></div>
+<div align="CENTER"><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/SCREEN/screenCoverageSonarGraphic.png?raw=true"/></div>
+<div align="CENTER"><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/SCREEN/screenSonarCoverageDatails.png?raw=true"/></div>
 
 <a name="UML"></a>3. UML
 ---
@@ -180,26 +183,26 @@ On the client there is player's view, which contains a reference to the remote c
 
 The model is divided into more classes, to let every class represent a single object and to separate methods and attributes according to their context. A central class, called GameModel, is used to integrate every class of the model and let them interact each other. This class is also responsible for the game flow management by sending events to connected player. In particular, every time the model state changes, it sends a ModelChangedEvent, to let players save an up-to-date copy of the model.
 
-The controller is divided into 2 different entities: there is a GameController, which is responsible of thread synchronization and checks the legitimacy of the requested action, for example discarding requests from players non-current player. Its duties include also timeout handling. After these checks it delegate the request to the Model. On the other hand if any of these validations fails the controller won't ask the model to perform any action and an exception will be returned to the client explaining what happened.  
+The controller is divided into 2 different entities: the first is the GameController. It is responsible for thread synchronization and checks the legitimacy of the requested action, for example discarding requests from players non-current player. Its duties include also timeout handling. After these checks it delegate the request to the Model. On the other hand if any of these validations fails the controller won't ask the model to perform any action and an exception will be returned to the client explaining what happened.  
 
-The second part of the controller is called PlayerController. Each player is associated with its own PlayerController. This controller is used to avoid spoofing by other players: every request to the server is done by passing as a parameter also the name of the player itself. If a player A (using a custom client) tries to perform any action pretending to be player B, player A's PlayerController, who knows the name of the player associated, delegates the request to the GameController with the real name of the player. This way, if the player who asked for an action is not the current player, the GameController will return to him an Exception.
+The second part of the controller is called PlayerController. Each player is associated with its own PlayerController. This controller is used to avoid spoofing by other players. If a player A (using a custom client) tries to perform any action pretending to be player B, player A's PlayerController, who knows the name of the player associated, delegates the request to the GameController with the real name of the player. This way, if the player who asked for an action is not the current player, the GameController will return to him an Exception.
 
 Here is a graphical representation of client-server interaction:
 ![client-server interaction](https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/UML/Client-Server%20interaction.PNG?raw=true)
 
 <a name="Design_Patterns"></a>
 ### Design Pattern used
 In addition to MVC pattern, already explained, we implemented:
-- <a name="Command"></a>**Command Pattern** to implement ToolCards: there is a ToolCard interface, which contains all the methods needed to let players use them. Since every ToolCard applies a different effect, there is a specific implementeation for every single existing ToolCard in the game, but, since some ToolCards have quite similar effects, the operations to be executed above the GameModel are coded into the GameModel itself, and the ToolCards call them in the order they need. Here is a scheme of the pattern: 
+- <a name="Command"></a>**Command Pattern** to implement ToolCards: there is a ToolCard interface, which contains all the methods needed to let model use them. Since every ToolCard applies a different effect, there is a specific implementeation for every single existing ToolCard in the game, but the operations to be executed above the GameModel are coded into the GameModel itself, and the ToolCards call them in the order they need. Here is a scheme of the pattern: 
 <div align=CENTER><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/UML/ToolCards.png?raw=true" width=400/></div>
 
 - <a name="Strategy"></a>**Strategy Pattern** to implement public objectives: there is a PublicObjective interface, which contains the methods needed to count points on players' boards. Since the way to count points changes according to the specific public objective, there is a specific implementation for every one of them. Here is a scheme of the pattern: 
 <div align=CENTER><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/UML/PublicObjectives.png?raw=true" width=300/></div>
 
-- <a name="Proxy"></a>**Proxy Pattern** to implement communication through socket: if a player connects to the game through socket, since its view can't have a reference to the remote object, as it happens with RMI, a ControllerProxy is created. The view can't distinguish through a real controller or a proxy, so, it asks for an operation normally. The controller proxy, creates a Request object, which will be sent to the server, and received by a ViewProxy. The ViewProxy can understand the request, and asks to the real Controller to execute the method asked by the player. In a similar way, the communication goes also from server to client: when something is needed to be sent from server to client, such as GameModel's events, it is incapsulated in a Response object by the ViewProxy and sent to the ControllerProxy on the player's client. The ControllerProxy can understand the response, and sends it to the view in a format he can manage, typically an Event. Here is an example scheme of the pattern:
+- <a name="Proxy"></a>**Proxy Pattern** to implement communication through socket: if a player connects to the game through socket, since its view can't have a reference to the remote Controller, as it happens with RMI, homogeneously a ControllerProxy is created. The view can't distinguish through a real controller or a proxy, so, it asks for an operation normally. The controller proxy, creates a Request object, which will be sent to the server, and received by a ViewProxy. The ViewProxy can understand the request, and asks to the real Controller to execute the method asked by the player. In a similar way, the communication goes also from server to client: when something is needed to be sent from server to client, such as GameModel's events, it is incapsulated in a Response object by the ViewProxy and sent to the ControllerProxy on the player's client. The ControllerProxy can understand the response, and sends it to the view in a format he can manage, typically an Event. Here is an example scheme of the pattern:
 <div align=CENTER><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/UML/Proxy.png?raw=true" height=75 /></div>
 
-- <a name="Visitor"></a>**Visitor Pattern** to let ControllerProxy and ViewProxy manage, respectively, Response and Request objects and to let the View manage Event objects: the behavior of the proxy pattern implemented in the socket communication has already been explained. When a ViewProxy receives a Request, it recognizes and manages the specific Request object through a Visitor pattern: for every kind of request, a specific implementation and a method in the RequestHandler interface exist. The RequestHandler interface is implemented by the ViewProxy. In a similar way is implemented the visitor Pattern in the ControllerProxy: for every kind of Response, a specific implementation and a method in the ResponseHandler interface exist. The ResponseHandler interface is implemented by the ControllerProxy. As said at the beginning, the visitor Pattern is also implemented in the View objects to let them handle the events received from the model: for every Event, a specific implementation and a method in the EventHandler interface exist. As suggested, the EventHandler interface is implemented by the View. Here is an example scheme of the pattern:
+- <a name="Visitor"></a>**Visitor Pattern** to let ControllerProxy and ViewProxy manage, respectively, Response and Request objects and to enable View distinguish between Event received. The behavior of the proxy pattern implemented in the socket communication has already been explained. When a ViewProxy receives a Request, it recognizes and manages the specific Request object through a Visitor pattern: for every kind of request, a specific implementation and a method in the RequestHandler interface exist. The RequestHandler interface is implemented by the ViewProxy. In a similar way is implemented the visitor Pattern in the ControllerProxy: for every kind of Response, a specific implementation and a method in the ResponseHandler interface exist. The ResponseHandler interface is implemented by the ControllerProxy. As said at the beginning, the visitor Pattern is also implemented in the View objects to let them handle the events received from the model: for every Event, a specific implementation and a method in the EventHandler interface exist. As suggested, the EventHandler interface is implemented by the View. Here is an example scheme of the pattern:
 <div align=CENTER><img src="https://github.com/MattePalte/ing-soft-2018-paltenghi-parravicini-pellizzi/blob/master/UML/Visitor.png?raw=true" width=500/></div>
 
 - <a name="State"></a>**State Pattern** to distinguish the different states of some ToolCards: some of the ToolCards required more interaction with the player and, after every interaction, the behavior of the ToolCard changes. To implement this kind of ToolCards, we created a specific implementation for every single phase of the ToolCard itself. When the player asks to play it, the first phase is executed and the state changes, notifying the player that he must now play the second phase. The player can't abort the operation, after the first phase is played. The only things he can do are finish all the phases of the ToolCard he asked for or let its timer expires. In that case, the operation is truncated, and the player loses its turn. However, since the first phase has been played and some changes have been made on the model, the player will pay the cost of the ToolCard even if he didn't finish to apply the entire effect. The ToolCards implemented with a state pattern, which require at most 2 interactions, are: