La revisión de código es una parte muy importante al momento de realizar un proyecto, porque es cuando se tiene qué pulir el código para que se vea de una manera más limpia, así como cuando se tienen que hacer todas las correcciones, o el «debug».

Este proceso consiste en la detección temprana de errores de un programa, para así mejorar su funcionamiento y se utilizan alternativas más eficientes a la implementación inicial. También se hace para mejorar las cualidades de los desarrolladores. Generalmente se lleva a cabo en equipos.

A continuación explicaré un poco los tipos de revisión de código:

Formal Code Review (FCD)

En esta forma de código, los equipos crean un plan de desarrollo donde se lleva a cabo la parte de crear el proyecto, desde la planeación previa, la creación, y al final, se tiene una junta para revisar qué fue lo que se realizó, paso a paso y finalmente se definen los cambios a realizar.

Lightweight Code Review

En este tipo de programación se pueden destacar estos siguientes métodos:

• Pair programming: Este tipo de review se lleva a cabo en parejas utilizando una computadora, mientras uno está escribiendo el código, el otro está checando línea por línea, y se van rotando constantemente.

• Over the shoulder inspection: En este método una persona está trabajando mientras un equipo está detrás de él viendo y se le indica cuando hay un error, y se resuelve juntos. Esta práctica es muy eficiente cuando los trabajadores están juntos en la misma oficina y pueden trabajar en equipo, pero si están separados no funciona.

• Email pass-around inspection: En este caso, los miembros del equipo se envían por e-mail el código, a todos los demás miembros, y así, se van enviando retroalimentaciones y el desarrollador principal es el encargado de recolectar todos los feedbacks y aplicarlos al código.

• Tool-assisted code review: Este método es el más utilizado hoy en día por los desarrolladores, ya que no se interrumpen las demás tareas. Existen muchas herramientas que nos ayudan a hacer esta revisión, y también algunas ayudas como son:
  • Discusión del código
  • Múltiples iteraciones de revisión del código
  • Reportes y estadísticas

En mi opinión, la parte de la revisión de código es una parte fundamental para el proyecto. Hoy en día es muy importante el tener un código limpio y funcional, y me parece que tenemos muchas herramientas para poder hacer nuestro review en tiempo real. Ya no es necesario establecer un horario y un lugar entre muchísimas personas para juntarse y poder tener el review. Ahora con la tecnología es mucho más fácil y es muy importante para poder terminar de manera excelente el proyecto.

Como vimos en mis post anteriores, es bastante importante el tener una buena organización para poder desarrollar un producto. Las herramientas que nos ayudan a conocer los requerimientos que utilizaremos son los diagramas.

Estos diagramas no solo se aplican para desarrollar software, también son muy utilizados en la creación de bases de datos funcional. Los diagramas nos van a ayudar a organizar la información de lo que el cliente pide y cómo la vamos a diseñar, de hecho, UML cuenta con un modelo llamado entidad-relación que es el principal al momento de desarrollar las bases de datos.

¿Qué es un modelo Entidad-Relación?

El modelo entidad-relación es un diagrama que representa cómo las entidades se relacionan entre sí dentro de un sistema. Se usan principalmente para diseñar bases de datos.

Los modelos emplean una serie de símbolos para representar la estructura que tendrá la base. Estos símbolos pueden ser rectángulos, círculos, líneas de conexión, entre otros, y muestran la relación que tiene cada entidad.

Creación de tablas

Una vez que se ha creado el Modelo ER, ya podemos diseñar las tablas que tendrá nuestra base de datos. Hay que mencionar que el diseño puede cambiar conforme el proceso vaya avanzando, y no necesariamente quedará igual al modelo original, esto porque se pueden encontrar algunas situaciones o el cliente cambiar de idea o casos no previstos, sin embargo es muy importante ir actualizando el modelo con cada cambio que se le hace a las tablas.

Paso 1

Para cada entidad fuerte que exista en el modelo, se tiene que crear una tabla con todos los atributos. También es importante escoger uno de los atributos, generalmente un atributo único, para que sea la llave primaria de la tabla.

Paso 2

Para cada entidad débil se crea otra tabla relacionan donde se incluyen los atributos de la llave primaria de la tabla padre y se agregan las llaves primarias y llave parcial de la nueva tabla

Paso 3

Por cada relación de tipo 1 a 1 se identifican las relaciones de las entidades participantes y se escoge una de las relaciones que contienen las llave primaria de una tabla con la llave foránea de otra.

Paso 4

Por cada relación binaria de 1 a muchos, se identifica la relación del lado de muchos y se incluye como llave primaria la llave foránea del lado 1.

Paso 5

Para cada relación que sea de muchos a muchos, se debe crear una nueva tabla para representar la relación. Se crea las llaves primarias a partir de las originales y esto genera las llaves foráneas de las relaciones 1 a muchos, del lado de muchos.

Paso 6

Para cada atributo multivaluado se crea una nueva tabla donde la llave primaria es la composición de la llave primaria y el atributo correspondientes.

Paso 7

Para cada relación n-aria se crea una nueva tabla para representar esta relación y se deben de incluir como atributos secundarios las llaves primarias de las relaciones participantes. Por lo general las llaves primarias son las combinación de todas las llaves foráneas de las relaciones participantes.

Es importante recalcar, que aunque estos son los pasos generales, no quiere decir que cada que se crea un modelo Entidad-Relación se debe elaborar tal cuál dice este proceso, se puede cambiar en algunas ocasiones dependiendo de las situaciones que se presentan a lo largo de la elaboración, sin embargo, sí nos dan una gran ayuda conocer estos pasos y son muy sencillos de entender y de llevar a cabo.

También es bueno tener en consideración que cada tipo de base de datos es diferente, ya que hay algunas que trabajan con una estructura que nada que ver a este tipo de diagramas, pero aún así para la mayoría de los casos, como es SQL sí se aplica de este modo.

Como se vio en mi post anterior, UML es un lenguaje gráfico que nos permite crear un software de manera más sencilla, ya que cuenta con varias herramientas que son muy sencillas de utilizar y muy prácticas, porque nos permite ver el diseño desde otra perspectiva.

En el mismo post, se habló sobre tres diagramas diferentes:

• Diagramas secuenciales
• Diagramas de clase
• Diagramas de objetos

En esta segunda parte del blog de UML, continuaré con ciertos diagramas que faltaron en el pasado, que son el diagrama de estado, diagramas de paquetes y diagramas de componentes.

Diagramas de Estado

Este diagrama muestra transiciones entre varios objetos., y están relacionados con las máquinas de estado. Estados se refiere a las diferentes combinaciones de información que un objeto puede mantener, es decir, para ver todas las posibles formas que puede tener un objeto y como llegar a ese estado se aplica un diagrama de estados.

Los diagramas de estado representan principalmente estados y transiciones. Los estados se representan con rectángulos de esquinas redondeadas que se etiquetan con el nombre del estado. Las transiciones se marcan con flechas que fluyen de un estado a otro, mostrando cómo cambian los estados.

Diagramas de paquetes

Estos diagramas nos permiten separar y organizar nuestros otros diagramas (clase, estado, casos de uso, etc). Ya que al tener un proyecto se tiene que contar con varias acciones y muchas veces se pueden perder entre tantas cosas que tenemos que hacer. Entonces, se crea un diagramas de paquetes que nos ayuda a «acomodar» por separado cada proyecto y nos permite verlos de uno por uno y también saber quién o quiénes van a ser los encargados de llevarlo a cabo. Estos diagramas tienen la finalidad de hacer que cada proyecto sea lo más independiente posible.

Diagramas de componentes

El diagrama de componentes es muy parecido al diagrama de paquetes. Estos también separan el proyecto pero en componentes, en lugar de paquetes.

El objetivo de estos diagramas es mostrar la relación que existe entre los componentes de un sistema. Un componente se refiere a un sistema o subsistema independiente que puede interactuar con el resto.

Estos diagramas pudieran parecer difíciles de comprender al principio, sin embargo, no es así, además que son una parte demasiado importante a la hora de desarrollar el sistema, ya que nos pueden ayudar a:

• Imaginar cómo va a ser la estructura del sistema
• Visualizar los componentes del sistema y cómo se relacionan
• Enfocarnos en el comportamiento del sistema y su relación con la interfaz.

Para finalizar, después de haber conocido estos tipos de diagramas, nos podemos dar cuenta que existen diferentes tipos de modelos en UML, y cada uno es diferente y tiene un objetivo distinto, dependiendo de qué es lo que se busca con nuestro software o en la etapa que nos encontremos.

Esto nos deja ver muy en claro que es fundamental el utilizar diagramas a la hora de planear un nuevo proyecto, ya que sin estos nos será muy difícil lograr desarrollar un producto que cumpla con todas las características. Actualmente existen muchas herramientas que nos ayudan a comprender cómo funcionan y que nos ayudan a crear estos diagramas.

Como he mencionado en post anteriores, la parte del diseño de software es muy importante para poder crear un proyecto correctamente. Existen muchísimas herramientas que nos ayudan a desarrollar correctamente nuestra planeación de software, hay de varios tipos dependiendo de qué es lo que queramos crear. Sin embargo, la herramienta más popular actualmente y la más utilizada es sin duda alguna el UML.

El Lenguaje unificado de Modelado (Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema, para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

UML ha hecho que se «unifique» el proceso de elegir herramientas para diseñar software, ya que al existir tantas opciones, lo que pasaba es que cada desarrollador elegía el que más le parecía y a veces causaba problemas para compartir los programas.

Esta unificación se debe a los beneficios que incluye UML, como pueden ser los diagramas para poder definir los proyectos y las acciones que se van a realizar. Además, estos diagramas son bastante sencillos de crear y de entender, por lo que esto ha hecho que tengan aún más impacto, además de la ventaja de que se pueden crear varios diagramas para un solo proyecto.

A continuación se presentarán tres diagramas muy populares en el proceso de UML:

Diagramas Secuenciales

Estos diagramas se centran en la relación y la acción de cada objeto de los sistemas, siguiendo un orden para explicar la funcionalidad y el proceso que sigue un sistema. Esto facilita el entendimiento del programa y hace más entendible leerlo por si se requiere hacer alguna modificación a futuro, esto debido a que es muy fácil de ver detalladamente el proceso.

Diagramas de Clase

Los diagramas de clase son de los más útiles al utilizar UML, esto porque traza claramente la estructura del sistema, con sus clases y atributos, además de las relaciones que existen entre los objetos. Los diagramas deben ser entendibles por todos los desarrolladores del proyecto y así poder garantizar que se divida en partes.

Algunos beneficios de utilizar estos modelos son:

• Ilustrar los modelos de datos de información.
• Comprender la visión general de los esquemas.
• Crear diagramas detallados.
• Ofrecer una descripción independiente de la implementación del sistema.

Diagramas de objetos

Estos diagramas representan una parte específica de un modelo de clase, de hecho es un poco común que se puedan llegar a confundir. Aunque cada uno es diferente ya que el modelo de clase representa solo la clase del objeto, y en estos diagramas ya se pueden ver más a fondo todos los detalles de cada uno de estos, y es de esta manera cómo se diferencian. Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo esos objetos se relacionan entre sí.

El modelo UML es sumamente importante y amplio de explicar, es por eso que este tema se divide en dos post, para poder explicar todo de una manera más específica. Es el modelo más importante para representar información y su utilidad de diagramas lo vuelve el más utilizado hoy en día en el medio de desarrollo de software.

En la vida estamos rodeados de patrones. No hay lugar al que vayamos que no observemos algún patrón de la naturaleza, o algún patrón que se utilizó para cierta construcción. En nuestras vidas los patrones nos rodean, y en el desarrollo de software no es la excepción.

Cuando se está desarrollando un software y se tiene un problema, seguramente ese problema o alguno similar ya lo han sufrido muchos desarrolladores antes. Es por eso es que se han creado los patrones de diseño.

Estos se refieren a la estructura de las clases de un problema, son soluciones comunes que se pueden extraer y utilizar para resolver problemas similares.

Las ventajas de utilizar patrones de diseño son:

• Ahorrar tiempo
• Seguro en la validez del código
• Lenguaje común

A continuación explicaré los patrones de diseño más comunes.

Patrones de diseño creacionales

Estos son los que facilitan la creación de objetos nuevos, de manera que se desacoplen de la implementación del resto del programa.
Se basa en dos conceptos:

1. Trabajar con interfaces, por lo que la implementación concreta que utilicemos queda aislada.
2. Ocultar cómo estas implementaciones concretas necesitan ser creadas y cómo se combinan entre sí.

Los patrones creacionales más conocidos son:

• Abstract factory
• Factory Method
• Builder
• Singleton
• Prototype

Patrones estructurales

Son patrones que nos facilitan la modelización de nuestros software especificando la forma en la que unas clases se relacionan con otras. Trata de crear partes pequeñas de un sistema y que con estas se pueda ir creando un sistema más completo al final.

Los patrones estructurales más conocidos son:

• Adaptador
• Puente
• Composición
• Decorador
• Fachada
• Proxy

Patrones de comportamiento

Se usan para gestionar algoritmos, relaciones y responsabilidades entre objetos. Una forma de esto es que cada objeto tenga su propia responsabilidad y no se repita entre objetos, para así poder agregar un paso entre dos de estos

Los patrones de comportamiento más comunes son:

• Comando
• Cadena de responsabilidades
• Interpretador
• Iterador
• Mediador
• Observador
• Visitante
• Estrategia

En conclusión, estos patrones de diseño nos facilitan la manera en que creamos nuestro software, simplificando así el trabajo con estructuras ya creadas y que nos ayudan a darnos una idea de cómo solucionar los problemas que se nos presentan. Estos también evitan que se tengan que crear los proyectos desde cero, lo más difícil de todo es saber cuándo usarlos y saber cuál usar.

El desarrollo de software es un proceso muy importante para poder crear un proyecto bien elaborado. Pero este es muy complejo que no es posible realizarlo todo como nosotros lo queramos. Es por eso, que han creado herramientas o lenguajes para poder facilitar su entendimiento y mejorar la calidad del producto final.

El que existan distintos lenguajes de modelado facilita la creación y desarrollo del software, pero es que existen tantos tipos de proyectos y sistemas con diferentes propósitos que se han tenido que dividir en muchas categorías. Aquí hablaré de algunas de ellas.

• Modelado de Objetos

Como su nombre lo dice, este se basa en el desarrollo de software orientado a objetos. Se trata de que cada parte del programa sea representado por un objeto independiente con sus atributos y métodos. El ejemplo más conocido es el modelo UML, que te permite visualizar la relación que hay entre los objetos con sus acciones aplicadas.

• Modelado de Datos

Estos modelos surgieron debido a que la tecnología incrementó de manera muy rápida y así se iban creando más y más datos en todo el mundo, que eran prácticamente imposibles de organizar. Es por esto que se crea este modelo y así se facilitó el trabajo para poder buscar, ordenar, y trabajar con estos datos, de acuerdo a ciertos criterios que el usuario puede decidir. Un ejemplo de esto es CQL que te permite crear bases de datos con diferentes tablas para así tener la información de manera más organizada.

Así, yo creo que estas herramientas son indispensables para poder crear un buen software con todo lo requerido. Nos ayudan a tener una mejor planeación, y a ver desde otra perspectiva más simple el cómo funcionaría nuestro proyecto y por ende, nos facilita un poco el trabajo. Yo por lo general en la que más pienso es en UML ya que es el más conocido, sin embargo, hay muchas otras herramientas y lenguajes que nos pueden ayudar a mejorar nuestro software de acuerdo a qué sea lo que necesitamos.

La mayoría de las veces cuando se está desarrollando un sistema y hay problemas se debe a que no hubo una buena comunicación entre el cliente y el desarrollador. Esto debido a que el cliente no se explicó bien, o el desarrollador entendió algo muy diferente, o porque muchas veces los clientes no saben con exactitud qué es lo que ellos quieren para su producto. Es por eso que se implementó la utilización de los casos de uso.

Los casos de uso ayudan a identificar, clarificar y organizar los requerimientos de un sistemas. Esto hace que se puedan profundizar algunos aspectos como pueden ser los usuarios que interactúan con el sistema, las acciones que cada usuario tendrá que desarrollar y la relación que tiene cada caso de usuario con las anteriores.

Los casos de usuario son tan utilizados que se implementaron diagramas que explican cómo funcionan estos. Tienen su significado y es fácil ver la relación que van a tener con los demás y qué es lo que cada quién va a realizar.