Los patrones de diseño de software se refieren a las mejores prácticas adoptadas por desarrolladores con mucha experiencia en el paradigma orientado a objetos y se hacen para que los demás podamos seguir su ejemplo para resolver problemas que se tengan en el proceso. Un patrón de diseño es una solución a los problemas más comunes en el diseño de software, no se refiere a código que se pueda implementar directamente, si no que es una descripción o una plantilla de cómo resolver un problema en diferentes situaciones, por lo que no van a ser tan precisos.

Por ser tan diverso el diseño de software, se han publicado muchos patrones de diseño, para poder adaptarse a las necesidades de los desarrolladores, por lo cual los patrones de diseño se dividen en 3 grandes categorías, estas no están en orden de importancia, aunque algunos autores si las clasifican por las más usadas, yo creo que todas son importantes ya que unas se adaptan bien para algunos casos mientras que otras para otros casos, haciendo que estas sean completamente necesarias.

1. Patrón de Diseño Creacional

Este patrón de diseño se implementa cuando se quiere tener control de los objetos que crean y cómo se crean, para poder reducir la complejidad e inestabilidad del proyecto. El operador “new” se considera peligroso ya que crea objetos por todo el proyecto, lo cual puede llevar a que diferentes clases sean dependientes, lo que dificultaría algún cambio futuro ya que se tendrían que cambiar las clases dependientes a la que se quiere cambiar o terminaría en errores cascada. Este patrón evita esto al controlar la creación de objetos desde el proceso de inicialización y no dejarlo en manos del cliente. Hay varias formas de implementar el patrón:

• Singleton
• Método fábrica
• Fábrica abstracta
• Constructor

2. Patrón de Diseño Estructural

Este patrón se centra en la composición de clases y objetos que se pueden adaptar para poder hacer estructuras más grandes juntando varios. Se trata de poder hacer las partes más pequeñas de los sistemas y que con varias partes se pueda crear el sistema completo para así poder tener una separación bien definida y que sea más fácil poder dar mantenimiento a cada parte en vez de a todo el sistema a la vez. Se puede lograr este patrón por medio de las siguientes técnicas:

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

3. Patrón de Diseño basado en Comportamiento

Este patrón se basa completamente en la comunicación entre los objetos, ya que se centra en cómo se dividen las responsabilidades entre objetos y cómo se resuelven los problemas, una forma de esto es que cada objeto tenga su propia responsabilidad y no se repita entre objetos, para así poder tener un control y una manera sencilla de agregar un paso entre dos objetos. Esta es solo una técnica de hacer más flexible un programa, pero hay más de este patrón:

• Cadena de responsabilidades
• Comando
• Interpretador
• Iterador
• Mediador
• Objeto Nulo
• Observador
• Visitante
• Plantilla

Gracias a estas herramientas se pueden aprender buenas prácticas para desarrollar proyectos en el paradigma más usado actualmente, orientado a objetos, con estas prácticas se logra que los proyectos puedan crecer y evolucionar de manera que no se tenga que crear un proyecto completamente nuevo cuando hay necesidad de más cosas, si no que se puede usar de base el que ya se tiene y agregarle más funcionalidades, pero de una manera que cualquier programador pueda hacerlo y no solo la persona que lo creó en un principio. Se debe hace uso de estos patrones para evitar casos como el del cómic de abajo.

Si se quiere aprender más de este tema este curso está disponible, o simplemente en línea se encuentran muchos cursos, o páginas con muchos ejemplos como esta que en verdad explica de una manera muy detallada.

El diseño de los sistemas de software puede llegar a ser tan complejo que se necesitan herramientas que lo faciliten y hagan más eficiente, por eso se cuenta con los lenguajes de modelación, ya que estos permiten que se pueda hacer la descripción del problema ya sea de manera gráfica o escrita para poder tener una descripción más completa de lo que se quiere hacer.

Hay tantos tipos de sistemas de software que hasta los lenguajes se tienen que dividir dependiendo de para que tipo de sistema de software se quiera modelar, esto puede llegar a ser confuso, pero sin estas categorías sería aún más confuso. Las categorías principales son las siguientes:

• Lenguajes de Modelado de Sistemas

Como su nombre lo dice, este lenguaje se centra en el modelado de sistemas, por lo que puede incluir hardware, software, información, personas involucradas, procedimientos e instalaciones, mientras que el modelado común no llega a entrar en detalles como las instalaciones. Este fue publicado por la empresa OMG (Object Management Group) en 2003.

• Lenguajes de Modelado de Objetos

Estos se basan en el paradigma Orientado a Objetos, donde se trata de hacer que los sistemas sean independientes entre si, haciendo que cada parte del programa sea representada por un objecto con atributos y acciones. El lenguaje es gráfico y se representan tantos los atributos como las acciones de cada objeto que se tiene, así como la interacciones entre un objeto y otro. La herramienta más conocida de este es UML, el cuál sugiere los parámetros para la realización de los esquemas.

• Lenguaje de Modelado de Datos

Debido a la gran cantidad de datos que se producen cada segundo en el mundo, se han desarrollado herramientas para el modelado de estos, podemos pensar en SQL, que ordena la información en tablas e indica las relaciones entre las entidades para hacer un mejor manejo de los datos y tener como buscarlos, ya que, como hay una gran cantidad de datos, si estos no están ordenados se pueden desaprovechar. UML también ofrece una herramienta para esto.

Thomas Frisendal, 2019. Page

En mi opinión las herramientas para el desarrollo de software son 100% necesarias, ya que con la complejidad de estos proyectos se pueden pasar por alto detalles muy importantes para el proyecto así quedando mal con el cliente, por lo que se deben de hacer eso de estas. De estas herramientas las más conocidas son de UML, ya que tiene diagramas para varios tipos y son fáciles de usar, así como muy completos que te permiten declarar todos los pasos antes de la implementación del proyecto.

Cuando se quiere desarrollar un Sistema de Software la mayoría de los problemas que se encuentran en el camino son sobre los requerimientos, que el desarrollador no entendió bien lo que el cliente quiere que se haga, el cliente no explicó bien lo que el desarrollador debe de hacer o simplemente el cliente no tiene idea de todo lo necesario para que se pueda hacer el producto que quiere. No es necesario que el cliente lo sepa, ya que este usualmente no tiene el conocimiento suficiente.

Por estos problemas y otros se han necesitado herramientas para que los requerimientos queden claros por las dos partes, desarrollador y cliente, para que no haya malentendidos, una de estas herramientas son los Casos de Uso.

Estos hacen que se tenga que profundizar en los requerimientos y definir de manera concisa ciertos elementos:

• Cuáles serán los usuarios del sistema, u otros sistemas que interactuarán con este.
• Cuáles serán las acciones que cada usuario, o sistema, tendrá con el sistema a desarrollar, los posibles escenarios.
• Los pasos a seguir dentro de cada posible escenario, esto ayudando a poder ver pasos que podrían fallar conforme a los usuarios, y también definiendo pasos alternativos si sucede algún caso excepcional.
• La relación que tendrá este Caso de Uso con los otros y cómo se hará, ya que se debe de hacer un Caso de Uso por cada acción por cada usuario con el sistema.

Se recomienda tanto el utilización de los Casos de Uso que hasta ya se han creado plantillas para poder generalizarlos y que se hagan de la manera correcta, aquí se presenta un buena plantilla detallando cada elemento de esta.

Se han desarrollado diagramas que nos pueden ayudar a acomodar nuestros casos de uso para tenerlos más ordenados y facilitar la utilización de estos de una manera más visual.

• Elipse horizontal: representan los Casos de Uso
• Figuras de palitos: representan las personas, organizaciones o sistemas externos
• Lineas: representan las asociaciones entre los Casos de Uso y las personas

El Proceso Unificado se trata de tomar las mejores partes de los demás procesos de desarrollo de software y hacer uno solo, por lo que este toma diferentes aspectos de cada uno, así llegando a una herramienta con suficientes aspectos que se hace un análisis más completo. Estas herramientas, a pesar de ser tediosas, son necesarias para poder tener un conocimiento completo de los requerimientos del proyecto y así poder proseguir de manera correcta a la fase de implementación y valoración.

• Casos de Uso

Los casos de uso son herramientas para saber qué es lo que quiere el cliente del proyecto, ya que estos especifican una parte del proyecto, al dar ejemplos de lo que se quiere hacer, como por ejemplo, tener una página de inicio de sesión para los empleados, con este caso de uso ya el desarrollador tiene una idea de lo que quiere el cliente y puede implementarlo de las maneras que sabe. Este punto me parece uno de los más importantes porque define claramente el trabajo que se tiene que hacer en cuanto al proyecto. Con estos casos de uso se hacen prototipos, lo que nos lleva al siguiente punto.

• Enfoque Iterativo e Incremental

Al hacer los prototipos de los Casos de Uso se puede ir entregando parte del trabajo hecho al cliente, para así poder trabajar de manera conjunta con este y poder tener la comunicación fácil y eficaz para pedir alguna modificación esta se haga al momento que se está implementando y no al final del proyecto, haciendo estos más eficientes. Este enfoque ayuda a poder ir implementando una cosa sobre otra y poder dividir el trabajo que se tiene por áreas como el siguiente enfoque.

• Enfoque centrado en la arquitectura

Al hacer el proyecto por partes se puede tener una idea de la dimensión de este, ya que se unen los casos de uso y las partes que se llevan trabajadas y se puede hacer un esquema de la totalidad del proyecto para así poder tener una idea bastante certera de las tecnologías que se van a usar así como de los recursos necesarios para esta.

Todos estos enfoques nos llevan a lo que es este proceso y sus partes más importantes para su desarrollo tomando en cuenta lo anteriormente dicho y teniendo en cuenta lo necesario que son seguir estos pasos para la utilización ideal de esta herramienta.

• Inicio

Se toman los requerimientos y el diagrama del proyecto para tomar la decisión de si se lleva a cabo este proyecto o no, tomando en cuenta las factores como costo, riesgo, beneficio, factibilidad.

• Elaboración

Se elaboran los Casos de Uso y se detalla la arquitectura del proyecto, para así poder tener claro lo que se a construir.

• Construcción

En esta fase es donde se implementan los Casos de Uso, se escribe el código y se implementa en el sistema para poder estar listo para enseñárselo al cliente.

• Transición

La última fase es para enseñar al cliente el producto ya implementado y poder conseguir feed back de este, así yendo a la tercera fase de nuevo para implementar los cambios y nuevos Casos de Uso, repitiendo este proceso hasta que se termine el proyecto.

Para concluir esta estrategia de desarrollo de software en mi opinión debería de tener un gran uso en la industria, ya que hace que el desarrollo sea más eficiente y mantiene al cliente muy metido en el proyecto por lo que puede dar su opinión en todo momento y se pueden hacer cambios sin que sean tan costosos o difíciles de hacer. Un proceso muy parecido a este es el que usa la empresa Rational de IBM, conocido como RUP.