Uno de los paradigmas más comúnmente usados en estos días es el de Orientado a Objetos, este es muy común debido a que en sí es el más nuevo y el que más se enseña, ya que este está hecho para que se facilite el mantenimiento de los sistemas de software al hacerlos modulares, permitiendo que se pueda cambiar un elemento del sistema sin tener que hacer ningún movimiento a los demás elementos, ya que estos están divididos y se mantiene una estructura común.

Una de las partes importantes de un proyecto de desarrollo de software es probar que todo funciona como debería y cuando debería, a esto comúnmente se le llama por su nombre en inglés testing, se hacen estas pruebas para poder cerciorarse de que el sistema cumpla con los requerimientos establecidos en la documentación, entre otras cosas.

Como se he dicho anteriormente, hay muchos tipos de sistemas de software y dependiendo del sistema es lo que se tiene que hacer en cada proceso, en este post me enfocaré solamente en Software Orientado a Objetos y específicamente en el proceso de testing de este. Este se puede dividir en tres niveles que son:

• Testing de unidad: este se refiere al testing de las clases individuales, que los atributos estén implementados conforme a la documentación, así como que los métodos no tengan errores, es el nivel más bajo de la jerarquía.

• Testing de subsistema: este se refiere al testing de módulos o subsistemas, los cuales están formados por grupos de unidades, también se tiene que probar la comunicación de este subsistema con otro.

• Testing de sistema: este se refiere al testing de la unión de todos los subsistemas, este ya va enfocado en la funcionalidad total de los requerimientos, este paso es el más tardado por lo que se hacen equipos especializados para este.

El punto de dividir este proceso es que en el primero se resuelvan todos los errores que se presentan, pero como esto rara vez pasa, el siguiente paso se encarga de esto, haciendo así un sistema de tres filtros para que los errores no lleguen al cliente y el producto pueda ser entregado de manera satisfactoria.

Si se quiere saber más del tema, ya que este es muy extenso, incluyo un libro que habla sobre esto, aunque hay más de uno en el que se puede encontrar información debido a la importancia de este. Libro

El proceso de desarrollo de software es muy variable, depende tanto del tamaño del proyecto como del enfoque de este mismo, por lo que el desarrollo no va a ser igual un proyecto que otro, pero hay varias cosas que definitivamente aplican para todos los proyectos, ya que estas no se enfocan en el tema del proyecto ni en algo muy concreto que se tiene que hacer, si no que manejan las partes generales del proyecto. Estas se deben de adaptar a cada proyecto, pero en sí el proceso va a ser muy parecido. Unas de estas cosas son la verificación y validación de software.

Para poder abordar este tema primero se tiene que definir lo que es verificación y validación, así como sus diferencias, ya que se suelen confundir. Primero se debe de declarar que estas dos forman parte de el testing de un sistema de software, por lo que se hacen pruebas de calidad, entendiendo esto podemos ir a las definiciones:

• Verificación: este se refiere a las pruebas que se le hacen a un sistema en el proceso del desarrollo para poder comprobar que pase los requerimientos de la fase de trabajo.
• Validación: este se refiere a las pruebas que se le hacen a un sistema cuando ya está terminado y listo para entregarlo, se prueba que se cumplan los requerimientos del cliente y no se haya hecho un proyecto que no cumpla a la totalidad lo que haya pedido al cliente o lo que se haya acordado en el contrato.

Después de definirlas nos podemos dar cuenta que ambas son completamente necesarias, ya que si son muy diferentes, pero se complementan, la verificación se necesita para darse cuenta que se va en la dirección correcta en el proceso y la validación se usa para comprobar si es que al final de todo el proceso en verdad se llegó a la meta esperada, si no se llegó se tendrán que hacer varios cambios en el proyecto hasta que esto se cumpla.

Por las diferencias en estos, se usan diferentes herramientas para evaluarlos:

• Verificación:
  • Revisiones
  • Inspecciones
  • Ir paso a paso
  • Reuniones

• Validación:
  • Testeo de caja negra
  • Testeo de caja blanca
  • Testeo de caja gris
  • Testeo de aceptación

Como se puede ver con el uso de las herramientas la verificación se puede hacer por las mismas personas que están desarrollando el sistema, mientras que la validación se tiene que hacer por un equipo especializado de testing, haciendo este proceso más largo y con mayor capacidad de detectar errores que se pudieron haber pasado por alto en la verificación.

Tanto la verificación como la validación son herramientas que no pueden faltar en el proyecto, ya sea grande o pequeño, ya que gracias a estas se comprueba que se haya hecho el trabajo como se debe y no que por un mal entendido se hiciera una cosa completamente diferente o que tenga detalles que pueden afectar al cliente y este no quede satisfecho con el trabajo.

Como lo he dicho anteriormente, se tienen buscar escribir código de la mejor manera posible por varias razones, para que este pueda ser escalable, para que se pueda aprender de tu código, o simplemente para que se ve “bien”, al final de cuentas estas razones se traducen en para que pueda entenderse por otras personas que no saben en lo que estás o estabas pensando. Se siguen patrones de diseño para que puedan ser legibles desde un principio.

Como a todos nos ha pasado, escribimos lo que pensamos en el instante para que no se nos vaya al “inspiración”, pero esta técnica nos hace dejar de pensar en los patrones de diseño o escribir las cosas de manera errónea con tal de hacerlo rápido y que no se nos vayan las ideas, esto pasa en todos los ámbitos, un ejemplo es como le pasa escritores famosos y su técnica es grabar lo que quieren escribir y después transcribir a papel sus ideas. Pero como a nosotros se nos podría llegar a dificultar el grabar nuestras ideas por el hecho de que la programación puede llegar a ser bastante abstracta, se tiene otra técnica de que después de que escribimos nuestro código, que sea revisado.

Como se dice, uno ve los errores de otro, pero nunca los propios. Por esto es conveniente que para poder buscar errores en código o una optimización de estos, lo haga otra persona que pueda ser crítica en cuanto a los errores, esto tiene muchas ventajas, una de ellas es que como la persona no está completamente metida en el tema, tiene que entender lo que se trata de hacer desde un principio y ver como lo maneja la persona que está programando.

Revisar el código después de escribirlo puede ser de gran ayuda, puede evitar que tengamos memoria desperdiciada, código muerto, que estemos usando una estructura que no es la más eficiente en nuestro código y por lo tanto que tenga errores que se pueden evitar con otras, así como otros errores que se pueden evitar fácilmente.

Como esta práctica se ha vuelto común se pueden encontrar estas prácticas para facilitar la tarea y hacerla más eficiente:

• Revisa aproximadamente 400 líneas de código.
  • Estudios han revelado que se deben de revisar entre 200 y 400 líneas de código en una sola vez, después de este punto el cerebro no puede analizar de manera correcta el código ya que no puede analizar tanta información a la vez y es posible que haya errores que no se vean.
• Haz rachas de 60 minutos máximo.
  • Después de este tiempo el cerebro no se puede enfocar en la misma cosa, es mejor levantarte y relajarte y después seguir.
• Da feedback que sirva, no que lastime.
  • Da un feedback constructivo, cómo se pueden mejorar las cosas, no solo apuntes los errores y digas que no funciona esa parte.
• Pregunta al autor
  • No siempre es fácil entender lo que se trata de hacer, a pesar de usar las mejores prácticas para esto, hay proyectos tan complejos que simplemente no permiten esto y se tiene que preguntar.

Para finalizar estas técnicas son para poder ayudar a los demás con el código que escriben, por lo que me gustaría dejar en claro que aunque no se quiera trabajar en equipo, este es muy importante y pocas veces es posible trabajar solo, lo que si es que en estos casos pueden criticar lo que haces, pero es para poder mejorar lo que cada quien hace, ya que se busca poder dar el mejor producto final y no humillar a otro por lo que hizo.

Se han hecho herramientas poder tener una imagen clara de lo que se quiere hacer antes de poder ponerse a programar. Ya que primero se debe de hacer un diagrama de lo que se pide en el proyecto para poder entender lo que pide el cliente y poder ver claramente como se debe de abordar la situación, cuales herramientas se van a utilizar y cómo se va a dividir el proyecto para poder trabajar de una manera más cómoda y conforme a los patrones de la programación.

Para poder leer de una manera correcta los diagramas se debe de tener claro lo que significa cada de las partes que lo conforman, por lo que analizaremos un caso y veremos que significa cada cosa.

En este caso primero tomaremos el recuadro superior, este está conformado por tres partes:

1. Parte superior: esta parte contiene el nombre de la clase y siempre es requerido, no puede llevar otros elementos.
2. Parte intermedia: esta parte contiene los atributos de la clase, donde primero va el nombre, dos puntos y el tipo de dato que es, se pueden inicializar haciendo uso de un signo de igual antes del valor.
3. Parte inferior: esta parte contiene los métodos de la clase, se pone uno de los modificadores de acceso y el nombre del método, puede seguir por dos puntos para especificar el tipo de dato que regresa, no se desarrolla nada sobre el método en esta parte.

• Modificadores de acceso:
  • ” + ” : público
  • ” – ” : privado
  • ” # ” : protegido
  • ” ~ ” : paquete
  • ” / ” : derivado
  • (subrayado) : estático

Aparte de lo que compone cada recuadro también es necesario saber qué significado tienen las flechas que juntan a los diferentes recuadros, ya que estas representan la relación que tiene cada recuadro, por consiguiente, cada clase.

• Herencia: este es el proceso de que una clase hija o sub-clase tome funcionalidad o datos de la clase padre o super-clase. En este ejemplo la clase carro hereda de la clase vehículo.

• Asociación: se refiere a que hay una conexión entre estas dos clases, donde también puede haber multiplicidad de la relación entre las clases.

• Composición: es la pertenencia de una clase a otra, con la obligación de que una no puede existir sin la otra, ya que son componentes completamente necesarios.

• Agregación: es la pertenencia de una clase a otra, pero sin la obligación de que una no puede existir sin la otra.

• Interfaces: estas son la implementación de las clases abstractas, una clase no puede implementar y heredar a la vez de otras, se tiene que elegir una.

A partir de ya como saber leer los diagramas de clase de UML se puede pasar de manera sencilla de un diagrama a ya el código, empezando con los recuadros a poner los elementos que se especifican como los atributos y los métodos, a partir de esto se puede hace el esqueleto de la clase, se continua con las relaciones entre las clases, para ya al final empezar a escribir el código en cada uno de los métodos.

Es muy importante empezar con los diagramas porque solo se piensa en objetos y en la relación que tienen, dejando al final la programación de las acciones de estos, por lo que al tener claro el diagrama de clases se puede saber qué métodos y atributos son necesarios, haciendo más claro este proceso.

Como hemos visto, es necesario hacer un diagrama con los requerimientos para un proyecto, o por lo menos eso se recomienda, por lo que para crear una base de datos no debe de dejarse a un lado la utilización de un diagrama para poder ordenar los datos que pide el cliente y aparte los que son necesarios para la creación de una base de datos funcional, UML también nos da la herramienta para crear los esquemas necesarios para una base de datos relacional como es SQL.

• Diagrama Entidad Relación UML

Este tipo de diagramas nos permite modelar la información que se tiene disponible para poder hacer tablas de una manera correcta y sin repetición de datos entre varias tablas, ya que esta es una de las más grandes ventajas que tiene la utilización de bases de datos, evitar la redundancia y malgasto de recursos. En este diagrama se especifican los datos que se van a incluir, la llave primaria, la llave foránea, las llaves secundarias si es que hay, la relación entre una tabla y otra así como la relación de cantidad que se tiene entre estas. Lucidchart ofrece una manera fácil de crear estos diagramas en su página.

• Proceso de diagrama a tablas

Ya que se tiene el diagrama de Entidad-Relación formado se puede empezar a hacer las tablas, se tiene que tomar en cuenta que el diagrama es solo eso y la tabla puede cambiar cuando se está haciendo, ya que se puede descubrir que hacen falta datos o por cambios en los requerimientos, pero estos cambios siempre se tienen que actualizar con el diagrama para poder llevar un seguimiento. Por lo versátil que es este tipo de diagrama se han puesto pasos para no perderse en el proceso:

1. Por cada entidad fuerte en el esquema, crear una tabla que incluya todos los atributos simples, incluir todos los atributos componentes de un atributo compuesto y escoger uno de los atributos como llave primaria.

2. Por cada entidad débil en el esquema, crear una tabla que incluya todos los atributos simples, incluir como atributos de la llave primaria la llave primaria de la entidad dueña y la llave parcial.

3. Por cada relación binaria 1:1 escoge una de las relaciones e incluye la llave primaria como llave foránea en la otra, incluye todos los atributos simples.

4. Por cada tipo de relación binaria 1:N identifica la relación con del lado N e incluye como llave foránea la llave primaria de la relación con el lado 1.

5. Para cada relación M:N se crea una tabla aparte y la llave primaria se crea a partir de las llaves primarias de las dos entidades y se agregan los atributos de la relación.

6. Para cada atributo multivaluado, crear una nueva tabla donde su llave primaria es la composición de la llave primaria de la entidad correspondiente y el atributo.

A pesar de tener estos pasos que son claros de entender, se pueden tener situaciones que no estén contempladas por estos y se tendrá que ver la manera de poder pasar del diagrama a la tabla, lo que se debe de hacer es juntar los pasos y así poder conseguirlo.

En las bases de datos no relacionales no se tiene un proceso como tal para poder conseguir las tablas, ya que estas bases de datos no son todas iguales, está Cassandra que se parece a las relacionales, está MongoDB que es completamente diferente, por lo que este proceso va a depender de la base de datos que se vaya a utilizar y del diagrama que se esté utilizando, ya que unos serán mejores para la base de datos elegida.

Este post es la continuación sobre lo que es UML, para qué nos sirve y la manera de utilizar los modelos más usados que tiene esta herramienta para organizar las partes de un proyecto en cuanto a sus requerimientos así como la estructura del código que se tiene planeado implementar, por lo que se pueden ver una explicación más detallada así como los otros modelos en mi post anterior.

Ya al dejar en claro que esta es la segunda parte de un post, pasamos a los demás diagramas que se quedaron pendientes, también incluiré una liga a la herramienta Lucidchart para una explicación más completa y la misma herramienta donde se pueden crear estos esquemas.

• Diagramas de Estado

Este tipo de diagramas se puede relacionar con las máquinas de Moore, estas se refieren a la parte de electrónica de dependiendo de la entrada y del estado donde se esté es la salida que se va a tener y el estado al que va a llegar, se podría ver como en una máquina expendedora, que depende de la cantidad de monedas que hayas insertado se pueden hacer disponibles ciertos productos para comprar y ya dependiendo del dinero disponible y del cambio que haya en la máquina se ve la cantidad de monedas que la máquina va a dar al usuario, si se quiere aprender más de las máquinas de Moore puede ir a esta página.

En UML estos diagramas presentan la interacción del usuario u otro sistema con el sistema a desarrollar y se tomar en cuenta tanto las entradas al sistema como la parte de ejecución de donde se encuentra el sistema, llamando a estos los estados. De esta manera se puede saber cada paso que tendría el usuario al interactuar con el sistema y qué implica cada uno, para así poder anticipar errores que pueden llegar a suceder. Otro aspecto muy importante es que se tiene un estado inicial y un estado final, los cuales siempre tienen que suceder para poder concluir como exitosa la ejecución. Página de Lucidchart.

• Diagramas de Paquetes

Estos diagramas se usan para poder organizar los diagramas de clases, de casos de uso, de estado, entre otros en paquetes, para así poder tener un mejor manejo de un proyecto muy grande, ya que se puede ver como tener separado los proyectos en carpetas como separamos nuestros archivos en nuestras computadores, además de permitir la separación de proyectos muy grandes, puede ayudar a que se tengan claros los límites del proyecto y a tener una separación entre clases para que puedan ser lo más independientes posible entre ellas. Página de Lucidchart.

• Diagramas de Componentes

Estos diagramas son como los anteriores, donde se hace la separación de las partes del proyecto para que sea más fácil de entender, pero este se centra en los proyectos que están orientados a componentes, los cuales se refieren a la forma de organizar el proyecto donde se hace por componentes que unidos hacen el sistema completo, se hace de esta manera para facilitar un cambio de algún componente y que el sistema no sea afectado por completo ya que se ponen entradas y salidas estándar que cada componente debe de seguir. En conclusión estos diagramas organizan los sistemas en componentes y se establecen las entradas y salidas de cada componente a otro. Página de Lucidchart.

Al haber presentado esta pequeña cantidad de diagramas se puede ver que hay más de uno para cada enfoque para un proyecto, pero existen más diagramas, ya sea unos más especializados para una situación que otros, así como hay diagramas que usan de manera más general y aplican en muchos escenarios. El punto de esto es que en verdad se tienen que usar diagramas para la planeación de un proyecto, y no se pueden poner pretextos de que los que existen no son los indicados para el proyecto, ya que hay una gran cantidad de estos y aún más, hay herramientas que te ayudan a entenderlos y a saber cómo hacerlos de manera correcta.

Como he comentado en posts anteriores, en el proceso del desarrollo de software el diseño es una parte muy importante y completamente necesaria sin importar el tamaño del proyecto que se tenga que hacer, ya que este ayuda con el manejo de la complejidad de proyectos extensos, pero a su vez es necesario para proyectos pequeños. Se ha hablado de la gran cantidad de herramientas que existen que facilitan este proceso, pero la más importante, con mayor alcance y la más predominante en el área es UML (Lenguaje Unificado de Modelado por sus siglas en inglés).

Al haber tantas herramientas que se pueden usar se llega a la discusión entre las personas que quieren usar uno y las otra que quieren usar otro, por lo que la utilización de UML ha hecho que esto sea cosa del pasado, se ha llegado a este acuerdo debido a las siguientes razones:

Se ha adoptado de manera positiva y general el uso de UML ya que este incluye diagramas los cuales modelan la información más importante para el desarrollo de un proyecto, por esto mismo se puede pensar que son diagramas complejos y difíciles de entender, pero por lo contrario, son fáciles de entender y de plasmar la información en ellos, la cual es otra razón por la que son tan usados. Y la ultima razón es el gran alcance que tiene UML, al tener una gran cantidad de diagramas para el modelado de los proyectos.

Este tema se va a dividir en dos partes debido a la gran cantidad de diagramas que ofrece UML y el uso de cada uno, por lo que presentaré 3 diagramas en este post y otros cuantos en el siguiente.

La página Lucidchart es una gran página para la creación de diagramas UML, ya que ofrece la plantilla así como la explicación de cada diagrama, por lo que después de cada tipo incluiré una liga por si se quiere conocer más sobre el diagrama y la herramienta para hacerlos.

• Diagramas Secuenciales

Con estos diagramas se describen las acciones entre los objetos de un sistema, se describe el orden que siguen esta acciones para poder tener una idea clara de lo que se tiene que hacer, así no saltar pasos y tener de una manera ordenada y clara lo que cada objeto produce, recibe, de quien recibe y a quien pasa su producto. Con esto se logra un análisis más eficiente si es que una parte del programa falla o si se quiere hacer un cambio aún después de la implementación de todas las partes del sistema, ya que se puede ver “con lupa” el proceso cuál es el punto donde se debe de hacer el cambio. Página de Lucidchart.

• Diagramas de Clase

Debido a que el diseño de un sistema de software puede llegar a ser muy grande en un principio, he incluso crecer aún más con el tiempo, el diseño de este se debe de dividir para que sea entendido por el personal que está desarrollando el proyecto, ya sea solo por el completo entendimiento o también para poder organizar el proyecto en partes y así poder dividir el trabajo entre varias personas, ya que es poco probable que un proyecto sea hecho por una sola persona. Los diagramas de clase nos ayudan en esta parte al poder modelar las clases necesarias para el proyecto, cuáles son atributos que tiene cada uno, los métodos, así como la comunicación con otras clases, permitiéndonos tener las especificaciones necesarias antes de empezar a programar. Página de Lucidchart.

• Diagrama de Objetos

Estos diagramas pueden llegar a confundirse con los diagramas de clase, pero son diferentes, ya que estos modelan al objeto cuando ya fue creado y ya tiene datos que lo pueden diferenciar de otros, así como la relación que tiene con otros objetos que pueden ser del mismo tipo u otro, mientra que el diagrama de clases solo modela la clase de donde viene al objeto, por lo que este diagrama se puede ver como la instancia de la clase, donde puede haber varios objetos del mismo tipo. Página de Lucidchart.

En esta imagen se muestra la diferencia entre el diagrama de clase la clase BankAccount y el diagrama de objeto del objeto Account1, donde se muestra que el objeto tiene los mismos tipos de datos que la clase, ya que este sale de la clase, pero ya tiene valores para cada atributo. Así dejando en claro que es una instancia de la clase, de la cual podría haber varias.