(Implementada en la ramamvp.pm-dao, serie de requisitos 4)
Enfoque
Esta es la primera soluci´on para la cuarta serie de requisitos, la cual a˜nade persistencia de partidas. Se incluye la posibilidad de guardar una partida, de cargar una partida guardada y de salir de la partida actual.
Dise˜no
La primera idea para incluir la persistencia es utilizar ficheros. La responsa- bilidad de guardar y cargar el juego desde fichero es asignada directamen- te a los modelos. Se incluyen los m´etodos save(FileWriterfileWriter) y
load(BufferedReaderbufferedReader) a varias clases del modelo [Figura 125] y al- gunos m´etodos adicionales a SessionImplementation.
Por otro lado se a˜naden dos nuevos controladores [Figura 124]: SaveController
y ExitController y dos nuevos men´us [Figura 121] en la vista: StartMenu y
Figura 117: Diagrama de clases de klondike.distributed (mvp.pm-dao)
Figura 120: Diagrama de clases de klondike.views (mvp.pm-dao)
Figura 126: Diagrama de clases de klondike.utils (mvp.pm-dao)
Problemas
Dependencia en modelos de las tecnolog´ıas de persistencia:
El c´odigo encargado de la persistencia en ficheros se encuentra en su totalidad en los modelos, perdiendo de nuevo la cohesi´on de los m´odulos y rompiendo el principio abierto/cerrado. La incorporaci´on de nuevas tecnolog´ıas de persistencia, como por ejemplo, persistencia en base de datos, supondr´ıa la modificaci´on del modelo y un aumento en tama˜no en sus clases.
13.
Soluci´on MVP-PM aplicando patr´on proxy
(Implementada en la ramamvp.pm+dao, serie de requisitos 4)
Enfoque
Esta ´ultima versi´on pretende solventar el problema mencionado en la soluci´on anterior.
Dise˜no
Con la finalidad de desacoplar los modelos de las tecnolog´ıas de persistencia, se crea un nuevo paquete klondike.models.DAO [Figura 137] en el que se separan los m´etodos encargados de dicha persistencia. Dando lugar a las clases GameDAO, CardStackDAO,
PileDAOyCardDAOque implementan la interfazDAO, la cual cuenta ´unicamente con los m´etodos save(FileWriterfileWriter) y load(BufferedReaderbufferedReader)y la clase SessionImplementationDAO como ´unico acceso externo a las funcionalidades de persistencia.
Figura 129: Diagrama de clases de klondike.distributed (mvp.pm+dao)
Figura 132: Diagrama de clases de klondike.views (mvp.pm+dao)
Figura 139: Diagrama de clases de klondike.utils (mvp.pm+dao)
Problemas
Dependencia en modelos de las tecnolog´ıas de persistencia
Se ha roto esta dependencia con el movimiento del c´odigo encargado de la per- sistencia al nuevo paquete DAO.
IV.
Comparativa
1.
Tama˜no
Como se puede observar en la tabla 1, el tama˜no de las soluciones aumenta tanto en n´umero de clases, de m´etodos y de lineas. Este aumento se debe en parte a la inclusi´on de nuevas funcionalidades en las diferentes series de requisitos, pero el aumento tam- bi´en se produce en las soluciones de una misma serie de requisitos. El motivo de este incremento es el desglose que se ha ido realizando de las clases para separar responsa- bilidades.
Requisitos RAMA #clases #metodos #lineas
domainModel 16 75 814 domainModel+command 28 96 1.019 documentView 39 115 1.186 mvp.pm 44 135 1.334 mvp.pm.+facade 45 150 1.396 mvp.pm.-doubleDispatching 47 130 1.387 1 mvp.pm.+doubleDispatching 48 142 1.410 mvp.pm.+composite 58 215 1.876 2 mvp.pm+reusability 60 215 1.899 mvp.pm-proxy 88 291 2.754 3 mvp.pm+proxy 98 323 3.013 mvp.pm-dao 117 399 3.708 4 mvp.pm+dao 123 416 3.864
Tabla 1: Tama˜no soluciones
Tama˜no de metodos y clases
Las clases y los m´etodos peque˜nos son generalmente m´as f´aciles de entender que m´odu- los de gran tama˜no. Cuando nos encontramos con clases o m´etodos grandes, es probable que est´en tratando de hacer demasiado. Una clase no deber´ıa tener m´as de 250-500 li- neas y un m´etodo no m´as de 10-15.
La tabla 2 muestra las lineas por clase y por m´etodo de media en cada soluci´on. El tama˜no medio de las clases disminuye considerablemente de la primera a la segunda versi´on con la separaci´on del men´u y luego se mantiene alrededor de las 30 lineas. De la misma forma, el tama˜no medio de los m´etodos se mantiene alrededor de las 10 lineas.
Requisitos RAMA #lineas/clase lineas/metodo domainModel 50,88 10,85 domainModel+command 36,39 10,61 documentView 30,41 10,31 mvp.pm 30,32 9,88 mvp.pm.+facade 31,02 9,31 mvp.pm.-doubleDispatching 29,51 10,67 1 mvp.pm.+doubleDispatching 29,38 9,93 mvp.pm.+composite 32,34 8,73 2 mvp.pm+reusability 31,65 8,83 mvp.pm-proxy 31,30 9,46 3 mvp.pm+proxy 30,74 9,33 mvp.pm-dao 31,69 9,29 4 mvp.pm+dao 31,41 9,29
Tabla 2: Media de lineas por clase y m´etodo
2.
Cohesion
“ La cohesi´on mide el grado de conectividad entre los elementos de un solo m´odulo. ”
(Grady Booch) Un m´odulo cohesivo debe tener significado propio por s´ı mismo agrupando abstraccio- nes l´ogicamente relacionadas. A mayor cohesi´on menor complejidad de los m´odulos, mayor reutilizaci´on y menor la cantidad de m´odulos afectados por los cambios l´ogicos. Una de de las m´etricas m´as aceptadas para medir la cohesi´on es LCOM (Lack of cohesi´on of methods), que calcula el conjunto de atributos comunes en los m´etodos de una clase. Un valor alto de LCOM implica falta de cohesi´on, por lo que es deseable conseguir valores bajos.
En la tabla 3 se muestran los valores medios obtenidos en las diferentes versiones, tambi´en reflejados en la figura 141 . Se obtienen valores de LCOM m´as altos en las primeras versiones, lo cual significa que la cohesi´on va aumentando en las soluciones posteriores.
Requisitos BRANCH LCOM
domainModel 8,38 domainModel+command 5,04 documentView 3,74 mvp.pm 3,93 mvp.pm.+facade 3,78 mvp.pm.-doubleDispatching 3,77 1 mvp.pm.+doubleDispatching 3,85 mvp.pm.+composite 3,55 2 mvp.pm+reusability 3,79 mvp.pm-proxy 3,71 3 mvp.pm+proxy 4,34 mvp.pm-dao 4,07 4 mvp.pm+dao 4,48 Tabla 3: LCOM
Figura 141: Gr´afica falta de cohesi´on
3.
Acoplamiento
“ El acoplamiento es la medida de fuerza de la asociaci´on establecida por
una conexi´on ente un m´odulo -elemento- y otro. El acoplamiento fuerte
complica un sistema porque los m´odulos son m´as dif´ıciles de comprender, cambiar o corregir por s´ı mismos si est´an muy interrelacionados con otros m´odulos. ”
(Grady Booch) El acoplamiento entre clases se produce cuando una clase utiliza a otra. La m´etrica que se ha utilizado para calcular el acoplamiento es el factor de acoplamiento. El factor de acoplamiento calcula el porcentaje del n´umero de acoplamientos existentes (no debidos a herencia) respecto al n´umero total de acoplamientos posibles. Un factor de acoplamiento del 100 % se producir´a cuando cada una de las clases utilice al resto, es decir, cuando tengamos un grafo dirigido completo. En el extremo opuesto, tendremos un factor de acoplamiento nulo cuando todas las clases sean totalmente independientes. En la tabla 4 se recogen los valores de esta m´etrica para cada una de las versiones, representados a su vez en el gr´afico de la figura 142. Estos valores indican claramente que el acoplamiento disminuye considerablemente y progresivamente a lo largo de las versiones, desde un factor del 44,12 % en la primera versi´on hasta un 6,49 % en la ´
Requisitos BRANCH coupling factor domainModel 44,17 domainModel+command 28,57 documentView 18,62 mvp.pm 16,7 mvp.pm.+facade 16,06 mvp.pm.-doubleDispatching 15,45 1 mvp.pm.+doubleDispatching 15,51 mvp.pm.+composite 13,19 2 mvp.pm+reusability 12,54 mvp.pm-proxy 9,01 3 mvp.pm+proxy 8,12 mvp.pm-dao 6,9 4 mvp.pm+dao 6,49
Tabla 4: Factor de acoplamiento
4.
Complejidad
La complejidad se define como la dificultad de comprensi´on, algo complejo requiere una gran cantidad de informaci´on, tiempo, y esfuerzo. Los problemas que tratamos de resolver en el software a menudo implican elementos de complejidad ineludible, en las que encontramos una gran variedad requisitos que compiten, incluso contradictorios.
“ Cada aplicaci´on tiene una cantidad de complejidad que no puede ser eli- minada u oculatada. ”
(Tesler, 87— Ley de Conservaci´on de la complejidad)
“ La complejidad del software es una propiedad esencial, no un accidente. Por esencial queremos decir que podemos dominar esta complejidad, pero
nunca podemos hacer que se vaya. [...] A menudo llamamos esta condici´on
la crisis del software, pero, francamente, una enfermedad que se ha llevado a los largo de este tiempo debe ser llamado normalidad. ”
(Broock) Para hacer frente a la complejidad debemos abstraernos de ella, descomponiendo el software en partes m´as peque˜nas y m´as peque˜nas, las cuales podemos refinar indepen- dientemente.
En 1976, McCabe propuso la complejidad ciclom´atica, una de las m´etricas de mayor aceptaci´on para cuantificar la complejidad de un software, independiente del lenguaje. La complejidad ciclom´atica define el n´umero de caminos independientes dentro de un fragmento de c´odigo. La complejidad ciclom´atica de los m´etodos mide la granuralidad en la que se ha dividido la complejidad del programa.
En la tabla 5 se muestra la complejidad ciclom´atica total y la complejidad ciclomatica media de los m´etodos para las diferentes soluciones. Se puede observar en el gr´afico de la figura 143 que la complejidad total del programa aumenta a lo largo de las versiones, mientras que en la figura 144 se aprecia que la complejidad media de los m´etodos disminuye. Esta contradicci´on indica que se ido descomponiendo mejor la complejidad del programa aunque esta haya aumentado.
Requisitos BRANCH CC total CC media de m´etodos domainModel 154 2,05 domainModel+command 172 1,79 documentView 191 1,66 mvp.pm 210 1,56 mvp.pm.+facade 225 1,50 mvp.pm.-doubleDispatching 219 1,58 1 mvp.pm.+doubleDispatching 220 1,55 mvp.pm.+composite 308 1,43 2 mvp.pm+reusability 308 1,43 mvp.pm-proxy 428 1,47 3 mvp.pm+proxy 436 1,35 mvp.pm-dao 539 1,35 4 mvp.pm+dao 557 1,34
Tabla 5: Complejidad ciclom´atica
V.
Conclusiones
Los resultados de la comparativa han demostrado que a lo largo de las soluciones, se ha conseguido un dise˜no menos acoplado, m´as cohesivo y que se ha gestionado bien la complejidad del problema. Se ha confirmado que el an´alisis realizado de cada versi´on ha sido correcto y que los cambios aplicados a lo largo de las soluciones han repercutido positivamente en la calidad del software.
El objetivo principal de la realizaci´on de este proyecto se ha visto cumplido. Se han afianzado los conocimientos adquiridos sobre la utilizaci´on de diferentes arquitecturas, principios y patrones del software y se ha comprendido su repercusi´on en la calidad del software.