Cuadro comparativo Patrones Goft, Ejercicios de Ingeniería del Software

¡Descarga Cuadro comparativo Patrones Goft y más Ejercicios en PDF de Ingeniería del Software solo en Docsity!

Unidad de aprendizaje 2

Documento Orientador

Diseño detallado aplicando

patrones de diseño

Patrones de diseño GoF

La idea de patrón en el contexto del desarrollo se inspira en el arte arquitectónico, proporcionando un recurso conceptualmente próximo. Pese a no ser los inventores del término, los cuatro miembros del denominado Gang of Four (GoF), Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, fueron unos de sus primeros impulsores y probablemente sus mayores divulgadores.

Los patrones de diseño son técnicas para resolver problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Los autores del GoF proponen dos principios básicos:

Programar orientado a una interfaz y no a una implementación.

Este principio busca que el código se utilice como una herramienta que no revele su funcionamiento, como en la clásica metáfora de la “caja negra”, implementada a través del principio de la encapsulación. De este modo, los usuarios del código se centran en la forma abstracta, lo que puede hacer y no puede hacer el código, en vez de en el cómo lo hace. Se establece una separación fundamental entre el programador del código - la persona que lo crea y lo mantiene - y el usuario del código

• entendido como el desarrollador que utiliza la librería sin modificar su funcionamiento. Dicho de otro modo, los patrones GoF buscan proporcionarnos piezas con instrucciones claras sobre con qué se pueden conectar y qué hacen, aunque sin decir nada sobre su funcionamiento interno.

Favorecer la composición antes que la herencia.

En las arquitecturas orientadas a objetos, la composición y la herencia pueden ser muy próximas funcionalmente, pero conceptualmente son distintas. Ambas permiten la agregación de funcionalidades cuando diseñamos una clase y evitan la redundancia

● Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales

● Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles. ● Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente. ● Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos. ● Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad. ● Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar. ● Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente. ● Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento

● Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN sea tratada por algún objeto.

● Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.

Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.

● Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna. ● Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente. ● Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde. ● Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos. ● State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto. ● Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan. ● Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura. ● Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.

Tipos de estructura

En general, los frameworks se pueden dividir de la siguiente manera:

● Frameworks de aplicación: Estos frameworks forman una estructura básica de programador para ciertos tipos de aplicaciones. Proporcionan una función y una estructura que son importantes para todas las aplicaciones de ese tipo. ● Frameworks de dominio: Los marcos de dominio crean la estructura de programación para un área problemática particular y por lo tanto proporcionan funciones para resolver este problema. ● Frameworks de clase: Framework son una combinación de clases y métodos que se pueden utilizar para una amplia gama de aplicaciones. Apoyan la implementación de la aplicación del programador a un cierto nivel abstracto. ● Frameworks de componentes: Estos frameworks de trabajo proporcionan un entorno para el desarrollo e integración de componentes de software, que son un conjunto de clases y generalmente tienen una interfaz claramente definida. ● Frameworks de coordinación: Estos frameworks proporcionan la capacidad de configurar interacciones de dispositivos y sirven para garantizar una compatibilidad perfecta. ● Frameworks de prueba: Como su nombre lo indica, este framework se utiliza para probar software desarrollado. Ejemplos bien conocidos son JUnit para pruebas de módulos y Selenium para pruebas de aplicaciones web. ● Frameworks de web: Los frameworks web están diseñados para el desarrollo de webs dinámicas y aplicaciones web. En este sentido, proporcionan métodos y funciones para apoyar a los desarrolladores.

Puntos clave para escoger un framework

Disponibilidad y calidad de la documentación:

● Tamaño de la comunidad.

● Issues abiertos en GitHub. ● Problemas que puede solucionar. ● Flexibilidad. ● Complejidad. ● Compatibilidad con las otras herramientas que se usarán.

Frameworks para backend

Spring Framework

Escrito inicialmente por Rod Johnson, fue lanzado por primera vez en el mes de Junio del año 2003 bajo la licencia Apache 2.0 , siendo una plataforma Java de código abierto. Desde entonces, se convirtió en el framework más popular para Java empresarial, para crear código de alto rendimiento, liviano y reutilizable, ya que su finalidad es estandarizar, agilizar, manejar y resolver los problemas que puedan ir surgiendo en el trayecto de la programación.

Spring, ofrece como elemento clave el soporte de infraestructura a nivel de aplicación, brindando un completo modelo tanto para la configuración como para la programación de aplicaciones empresariales desarrolladas bajo Java, sin discriminación en cuanto al despliegue de la plataforma.

Todo esto trae consigo una gran ventaja, ya que permite que los equipos de desarrollo puedan enfocarse directamente en la lógica empresarial que requiere la aplicación, haciendo el proceso más corto, rápido y eficaz, ahorrando líneas de código y evitando tareas repetitivas.

Características

Entre las características de Spring, tenemos las siguientes que ofrecen una cantidad considerable de servicios:

● Facilidad de mantenimiento. ● Facilidad para realizar testeo unitario automatizado y desarrollo orientado a pruebas (TDD). ● URLs limpias, fáciles de recordar y adecuadas para buscadores. ● Control absoluto sobre el HTML resultante generado, con la posibilidad de crear webs "responsive" usando plantillas del framework Bootstrap de forma nativa. ● Potente integración con jQuery y otras bibliotecas JavaScript. ● Magnífico rendimiento y escalabilidad. ● Gran extensibilidad y flexibilidad.

Laravel

Laravel es un framework PHP. Es uno de los frameworks más utilizados y de mayor comunidad en el mundo de Internet.

Como framework resulta bastante moderno y ofrece muchas utilidades potentes a los desarrolladores, que permiten agilizar el desarrollo de las aplicaciones web. Laravel pone énfasis en la calidad del código, la facilidad de mantenimiento y escalabilidad, lo que permite realizar proyectos desde pequeños a grandes o muy grandes. Además permite y facilita el trabajo en equipo y promueve las mejores prácticas.

Características de Laravel

El framework Laravel trabaja con una arquitectura de carpetas avanzada, de modo que promueve la separación de los archivos con un orden correcto y definido, que guiará a todos los integrantes del equipo de trabajo y será un estándar a lo largo de los distintos proyectos. Por supuesto, dispone también de una arquitectura de clases también muy adecuada, que promueve la separación del código por responsabilidades. Su estilo arquitectónico es MVC.

Contiene además, un amplio conjunto de características, que sirven para realizar la mayoría de las aplicaciones web. Entre ellas podemos encontrar:

● Un sistema de rutas, mediante las cuales es fácil crear y mantener todo tipo de URLs amistosas a usuarios y buscadores, rutas de API, etc. ● Un sistema de abstracción de base de datos, con un ORM potente pero sencillo de manejar, mediante el que podemos tratar los datos de la base de datos como si fueran simples objetos. ● Un sistema para creación de colas de trabajo, de modo que es posible enviar tareas para ejecución en background y aumentar el rendimiento de las aplicaciones. Varias configuraciones para envío de email, con proveedores diversos. ● Un sistema de notificaciones a usuarios, mediante email, base de datos y otros canales ● Una abstracción del sistema de archivos, mediante el cual podemos escribir datos en proveedores cloud, y por supuesto en el disco del servidor, con el mismo código. ● Gestión de sesiones. ● Sistema de autenticación, con todo lo necesario como recordatorios de clave, confirmación de cuentas, recordar un usuario logueado, etc. ● La posibilidad de acceder a datos en realtime y recibir notificaciones cuando éstos se alteran en la base de datos.

Django

Django es un framework de desarrollo web de código abierto, escrito en Python, que cumple en cierta medida el paradigma del Modelo Vista Controlador.

Este framework, nombrado así en alusión al guitarrista de jazz gitano Django Reinhardt, se abrió al público bajo una licencia BSD en julio de 2005, desarrollado inicialmente

(incluyendo una asignación detallada de permisos).

La distribución principal de Django también aglutina aplicaciones que proporcionan un sistema de comentarios, herramientas para sindicar contenido via RSS y/o Atom, "páginas planas" que permiten gestionar páginas de contenido sin necesidad de escribir controladores o vistas para esas páginas, y un sistema de redirección de URLs.

Otras características de Django son:

● Un mapeador objeto-relacional. ● Aplicaciones "enchufables" que pueden instalarse en cualquier página gestionada con Django. ● Una API de base de datos robusta. ● Un sistema incorporado de "vistas genéricas" que ahorra tener que escribir la lógica de ciertas tareas comunes. ● Un sistema extensible de plantillas basado en etiquetas, con herencia de plantillas. ● Un despachador de URLs basado en expresiones regula ● Un sistema "middleware" para desarrollar características adicionales; por ejemplo, la distribución principal de Django incluye componentes middleware que proporcionan cacheo, compresión de la salida, normalización de URLs, protección CSRF y soporte de sesiones. ● Soporte de internacionalización, incluyendo traducciones incorporadas de la interfaz de administración. ● Documentación incorporada accesible a través de la aplicación administrativa (incluyendo documentación generada automáticamente de los modelos y las bibliotecas de plantillas añadidas por las aplicaciones).

Ruby on Rails

Rails es un framework de desarrollo de aplicaciones web escrito en el lenguaje de

programación Ruby. Está diseñado para hacer que la programación de aplicaciones web sea más fácil, haciendo supuestos sobre lo que cada desarrollador necesita para comenzar. Permite escribir menos código realizando más que muchos otros lenguajes y frameworks. Además, expertos desarrolladores en Rails reportan que hace que el desarrollo de aplicaciones web sea más divertido.

Rails es un software dogmático. Éste asume que existe una forma "mejor" de hacer las cosas, por lo que está diseñado para fomentar esa forma (y en algunos casos para desalentar alternativas), ya que Rails es un compuesto de muchas ideas diferentes e incluso paradigmas que muchos que normalmente se verían en conflicto, si se contrastan solos y uno por uno.

Si aprendes "El Modo Rails" probablemente descubrirás un tremendo incremento en tu productividad. Si persistes trayendo viejos hábitos de otros lenguajes a tu desarrollo en Rails, e intentas usar patrones aprendidos en otros lugares, podrías tener una experiencia menos agradable.

La filosofía de Rails se basa en estos dos principios:

● DRY (del inglés, "Don't Repeat Yourself"): Sugiere que escribir el mismo código una y otra vez es una mala práctica. ● "Convención sobre Configuración": Significa que Rails hace algunas suposiciones sobre lo que quieres hacer y cómo vas a hacerlo, en lugar de requerir que especifiques cada pequeña cosa a través de un sin fin de archivos de configuración. Tecnología de Rails Rails tiene una serie de conceptos filosóficos. En términos de estructura arquitectónica, Rails se basa en el patrón Modelo-Vista-Controlador (MVC), por lo que es uno de los más conocidos, ya que es muy utilizado. El concepto de este patrón implica la separación lógica de las partes de nuestra aplicación. Para realizar el funcionamiento del sistema, se divide en distintas piezas que pueden ser modelos, vistas o controladores.

● Inyección de dependencias, un patrón de diseño que se basa en pasar las dependencias directamente a los objetos en lugar de crearlas localmente. ● Programación reactiva, la vista se actualiza automáticamente a los cambios. ● Dispone de asistente por línea de comandos para crear proyectos base (Angular cli). ● Se integra bien con herramientas de testing. ● Se integra bien con Ionic, para adaptar aplicaciones web a dispositivos móviles. Arquitectura Una de las grandes diferencias entre un framework y una biblioteca, es que el framework es un montón de funcionalidades “genéricas” preparadas para que nosotros hagamos funcionalidad específica. En cambio, una biblioteca es una única función genérica. Basados en esta definición podemos decir que un framework consiste de varias bibliotecas escritas para manejarse todas juntas. Bajo este pensamiento, podemos decir que Angular preparó todo para que nuestra aplicación solo utilice los módulos (o bibliotecas) que vamos a necesitar en nuestra WebApp. Con este pensamiento, cuando iniciamos a construir nuestra aplicación con Angular, solo vamos a tener el módulo principal llamado “core”; con él vamos a poder ejecutar nuestra aplicación y escribir cada uno de nuestros componentes. Si nuestra aplicación necesita generar rutas tenemos que agregar el módulo de ruteo, que Angular ya nos provee, y si necesitaramos agregar formularios, Angular también tiene un módulo P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN increíble para eso.

Angular tiene bastantes módulos/bibliotecas internamente, pero la mayoría son independientes entre sí por lo que la webapp solo necesita importar los módulos necesarios para poder trabajar.

Para construir aplicaciones Angular creamos:

● Templates HTML que contienen etiquetas especiales de Angular. ● Componentes de clase que gestionan dichos templates.

● Servicios que encapsulan lógica de la aplicación. ● Módulos que organizan los componentes y servicios. Vue Es un Framework progresivo , es decir, es un Framework que sirve para consumir interfaz del usuario. Fue creado por Evan You, quien trabajó en Google realizando prototipos y en el core del Framework de Meteor, hasta que pensó en otra forma de hacer una opción más fácil que abarcara las necesidades a la hora de hacer prototipos. Así surgió Vue en el 2014; desde entonces ha tenido una gran evolución y sigue creciendo en su versión 2 más y más.

Características:

● Accesible. ● Versátil: Su núcleo es bastante pequeño y se escala a través de plugins, con lo cual escucharás mucho que Vue es una librería muy parecida a React, una librería que cumple un propósito. ● Escalable por el mismo tema de la versatilidad. ● Reactivo. ● Optimizado: Su core ocupa 74KB, como ves es bastante liviano. ● Comunidad: Va creciendo a un ritmo importante con más 66500 estrellas en P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN GitHub y 130 personas contribuyendo al core cada día. ● Licencia MIT: se publicó bajo el amparo de esta licencia.

ANTIPATRONES

Los anti-patrones son ejemplos bien documentados de malas soluciones para problemas. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente al investigar sistemas disfuncionales durante una

terminar o reemplazar. 5. Y claro, cuando se deja un código sin uso, abandonado; interfaces o componentes obsoletos en el cuerpo del sistema. Los resultados son predecibles: conforme los flujos se endurecen y solidifican (se escribe código y pasa el tiempo), rápidamente se vuelve imposible documentar el código o entender su arquitectura lo suficientemente bien como para hacer mejoras.

2. The God. Un programa omnipresente y desconocido. Aquel sistema donde una sola clase ó módulo (la función main o equivalente) hace todo. Así que el programa es un solitario y único archivo de muchísimas líneas. En consecuencia, tenemos un código desorganizado y fuertemente interdependendiente.
3. Golden Hammer. También conocida como la técnica de la varita mágica. Es un vicio relacionado con aferrarse a un paradigma, para solucionar todos los problemas que se nos presentan al desarrollar sistemas, como por ejemplo, siempre querer usar el mismo lenguaje de programación para todos los desarrollos, sea o no conveniente. Es el caso de querer utilizar lenguajes como .Net, de Java, de PHP para todas las situaciones cuando podrían existir otros lenguajes que podrían aportar valor ante ciertas situaciones como el caso de Javascript para el Frontend. Es importante comprender que cada uno tiene capacidades y limitaciones en aplicaciones particulares. En consecuencia se trata de, uno, el uso obsesivo de una herramienta, y dos, de una terquedad de los desarrolladores para usar un paradigma de solución en todos los programas, lo que conlleva ocasionalmente a consumir mucho más esfuerzo para resolver un problema.
4. Spaghetti Code. Se dice de una pieza de código fuente no documentado, donde cualquier pequeño movimiento convulsiona la estructura completa del sistema. En expresión coloquial: codificar con las... los “pies”. A diferencia del estilo volcán, donde la crítica es a la forma en que el sistema crece (se anexan módulos), aquí la crítica es a la forma en que se escribe cada una de las líneas, desde la indentación hasta el lenguaje P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN o lenguajes utilizados y su interacción. Ya en el contexto spaghetti, si mezclamos más de un lenguaje de programación en el mismo archivo, el spaghetti es más sabroso. La receta clásica con lenguajes scripts del tipo PHP con HTML y sazonado con JavaScript, ¡es delicioso! (entiéndase un enorme problema). El origen del spaghetti es regularmente un programa creado para hacer una pequeña demostración, que termina, en un dos

por tres, trabajando como producto final. ¿Dónde está el problema?, bien podemos citar lo siguiente como ejemplos: 1. 50% del tiempo de mantenimiento se invierte en entender al sistema original. 2. El spaghetti es causa directa del síndrome del programador desesperado: ¡mejor reescribimos todo el programa! 3. Y, obviamente, el reuso es imposible. Pero para colmo tenemos sólo un chef, o en el contexto un “Programador Solitario”. ¿Quién era ese hombre tras el monitor que no está disponible para explicarnos su receta? Simplemente se tienen problemas, muchos problemas.

5. Fantasmas. Demasiadas clases en un programa o tablas en una base de datos. Varias clases o tablas con mínimas responsabilidades. Muchas veces se utiliza para disfrazar la presencia del anti-patrón The God. Se colocan clases inútiles, que disfrazan el hecho que todo el sistema se encuentra construido en uno, o unos cuantos archivos, módulos o clases. Este anti-patrón sugiere un modelo de análisis y/o diseño inestable: el diseño no coincide con la implementación, y por ello es imposible hacer extensiones al sistema, porque entre tanto “fantasma”, encontrar los elementos relevantes es imposible. Anti-patrones de Arquitectura Ahora consideremos las malas técnicas para definir componentes y relaciones en el sistema, es decir, su arquitectura. Si los desarrolladores tienen una colección de malas costumbres de codificación (anti-patrones) a su alcance, los arquitectos no se quedan atrás. Veamos:
6. Reinventar la rueda. Se refiere a reimplementar componentes que se pueden conseguir prefabricados de antemano, y hacer poco reuso en el código. En breves palabras: querer hacer todo uno mismo. Y hablaríamos de:
7. Poco nivel de reuso en el código, reuso de un proyecto a otro, con lo cual cada proyecto está comenzando desde cero.
8. Constantemente se reescriben fragmentos de código con la misma P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN funcionalidad.
9. Con el consecuente gasto inútil de mano de obra y tiempo en reimplementar cosas, que ya estaban hechas. 4. El software se vuelve innecesariamente más denso.