Professional Documents
Culture Documents
GUÍA DE APRENDIZAJE
PRINCIPIOS DE DISEÑO
_ Principios de diseño 2
Equipo de Autoría
FOLIO: INT-P2016-TIDS05-GA
_Guía de aprendizaje
_ Principios de diseño 3
Presentación de la unidad 2
La etapa más compleja en la construcción de sistemas es el Diseño, ya que son muchos factores los que inciden en esta
aseveración, siendo el más gravitante la capacidad de obtener una misma solución con diferentes alternativas de
implementación.
Muchas otras preguntas de esta índole se aprecian cuando debemos decidir una solución de entre varias alternativas
y siempre estamos en la duda de saber escoger la “correcta”, pero ¿cuál es la correcta? Nos centramos en buscar
modelos, ejemplos de soluciones que se han obtenido para otros requerimientos similares y que han sido exitosos en
sus resultados. Paradigmas que nos garantizan un resultado satisfactorio, basado en experiencias previas. Experiencias
de otros, que nos pueden servir para garantizar el éxito de nuestro proyecto.
Estos modelos, paradigmas o patrones son los que algunos profesionales del área han podido definir y documentar
como mejores prácticas, que nos han de servir para realizar diseños de soluciones a requerimientos conocidos. Su
implementación viene de la observación de otras ciencias de la ingeniería que, tras años de experiencia y repetición
de soluciones conocidas, lograron documentar correctamente los procesos y procedimientos que les garantizaban
buenos resultados.
El objetivo de esta unidad es conocer algunos de estos modelos, y bajo qué ámbito los podemos aplicar y desarrollar
para entregar solución sistémica a un problema.
_Guía de aprendizaje
_ Principios de diseño 4
LENGUAJES DE DESCRIPCIÓN DE Son textuales, tienden a ser formales, son lenguajes usados para describir una
ARQUITECTURAS arquitectura de software en términos de componentes y conectores.
DIAGRAMAS DE CLASES Y DE OBJETOS Se utiliza para representar un conjunto de clases (y objetos) y sus interrelaciones.
TARJETAS DE CLASE RESPONSABILIDAD Se usan para indicar los nombres de los componentes (clase), sus
Y COLABORACIÓN responsabilidades, y los nombres de los componentes que colaboran.
DIAGRAMAS ESTRUCTURALES DE Se utilizan para describir las estructuras de datos en términos de secuencia,
JACKSON selección e iteración.
_Guía de aprendizaje
_ Principios de diseño 5
DIAGRAMAS DE FLUJO DE DATOS Se utilizan para mostrar el flujo de datos entre un conjunto de procesos.
DIAGRAMAS Y TABLAS DE DECISIÓN Se utilizan para representar combinaciones complejas de condiciones y acciones.
DIAGRAMAS DE FLUJO Y DIAGRAMAS Se utilizan para representar combinaciones complejas de condiciones y acciones.
DE FLUJO ESTRUCTURADO
DIAGRAMAS DE ESTADOS Y Se utilizan para mostrar el flujo de control de estado a estado, en una máquina
TRANSICIÓN DE ESTADOS de estados.
_Guía de aprendizaje
_ Principios de diseño 6
_Guía de aprendizaje
_ Principios de diseño 7
Tenemos dos tipos de diseño, cuya adopción va a depender de los factores que revisamos a continuación.
La estandarización proporciona marcos comunes de trabajo que pueden ser utilizados por los especialistas para
garantizar niveles adecuados de calidad, los cuales pueden ser verificados por otros procesos normados, garantizando
que los procesos serán conducidos por parámetros de desarrollo definidos con anterioridad y, por lo tanto, la
experiencia asociada a estos procesos se verá fortalecida con cada nuevo proyecto y se realizarán los ajustes necesarios
para lograr productos de calidad.
_Guía de aprendizaje
_ Principios de diseño 8
función y su usabilidad, en tanto el programador está orientado a obtener código eficiente de las herramientas
disponibles, la globalidad nos indica que las integraciones requeridas son cada vez de mayor complejidad-eficiencia y
la topología varía cada vez con mayor celeridad debido a la evolución tecnológica.
Para integrar todos estos elementos y otros más, no es posible pensar en utilizar una sola herramienta que nos permita
dar respuesta a todos los requerimientos.
Si es necesario definir el comportamiento interno de un objeto, esto se realiza con un diagrama de transición de
estados o diagrama de estados, mientras que los mecanismos y servicios comunes se definen como utilities de la clase.
_Guía de aprendizaje
_ Principios de diseño 9
Esta vista debe atender los requisitos internos relativos a la facilidad de desarrollo, administración del software,
reutilización, elementos comunes y restricciones impuestas por los lenguajes de programación que se usen, apoyar la
asignación de requisitos y trabajo al equipo de desarrollo, la evaluación de costos, la planificación y el monitoreo de
progreso del proyecto.
La arquitectura de desarrollo completa solo puede describirse totalmente cuando todos los elementos del software
han sido identificados.
_Guía de aprendizaje
_ Principios de diseño 10
Esta vista también especifica qué hilo de control ejecuta cada operación,
identificada en cada clase de la vista lógica, por lo cual es trazable con ella.
La vista se centra, por tanto, en la concurrencia, distribución de procesos, escalabilidad, integridad y tolerancia a fallas,
donde la arquitectura de procesos1 se describe en varios niveles de abstracción, donde cada nivel se refiere a distintos
intereses y pueden replicarse para aumentar la distribución de la carga de procesamiento o para mejorar la
disponibilidad.
4.3.1 Diagramas
Esta vista se apoya en los diagramas UML de actividad, de estados y de secuencia.
La arquitectura física toma en cuenta los requisitos no funcionales del sistema: disponibilidad, tolerancia a fallas,
performance y escalabilidad, donde el software se ejecuta sobre una red de computadores o nodos de procesamiento.
Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre el
código fuente en sí. Se pueden utilizar varias configuraciones físicas, lo importante es la correspondencia del software
a los nodos, ya que debe ser altamente flexible y tener el mínimo impacto en el código fuente.
_Guía de aprendizaje
_ Principios de diseño 11
Las buenas prácticas señalan utilizar cuatro ambientes para desarrollar, probar y poner en producción los
sistemas:
DEV: Development (Desarrollo). En este ambiente se desarrollan los programas y configuraciones
de software necesarios para el sistema.
IST: Integration System Testing (Test). En este ambiente se ejecutan las pruebas integradas. Todos
los módulos y nodos del sistema se prueban en conjunto.
UAT: User Acceptance Testing (Pre-productivo). En este ambiente se prueba la liberación de los
módulos en un ambiente que simula las características de productivo.
PRD: Production (Productivo). Este es el ambiente de producción en que el sistema opera de cara a
los usuarios finales e integrando a todos los sistemas de la organización.
Esta vista va a ser representada por los casos de uso del software y va a tener la
función de unir y relacionar las otras 4 vistas.
El escenario es representado por diagramas de casos de uso, siendo optativo que nuestra primera mirada sea la de un
diagrama de caso de uso de negocios que nos permita analizar de una mirada más alta los distintos escenarios. Desde
el escenario se debe poder hacer una trazabilidad a los distintos artefactos de la arquitectura, tanto a una clase, un
componente, un proceso, etc.
4.6.1 Diagramas
La vista de escenarios corresponde a instancias de casos de uso que unifican todas las vistas, donde, desde los casos
de uso, se debería poder hacer una trazabilidad a todos los componentes del sistema software. Por ejemplo, revisar
qué máquinas, clases, componentes o procesos son los responsables de que el sistema cubra una cierta funcionalidad.
_Guía de aprendizaje
_ Principios de diseño 12
La orientación a objetos permite definir modelos de diseño, que han evolucionado en base a buenas prácticas y
permiten establecer soluciones probadas, que aportan eficiencia y principalmente confiabilidad. A estas propuestas
de solución las vamos a identificar como patrones.
Lo definiremos como un modelo o paradigma de diseño que sugiere una solución a un problema o requerimiento
conocido, cuyas principales características son:
PATRÓN
Capturar conocimiento.
Crear un vocabulario técnico.
Diseño flexible.
Reusable.
Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el
desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
DISEÑO
_Guía de aprendizaje
_ Principios de diseño 13
Para identificar el nivel de acoplamiento, revise las siguientes situaciones dada una clase X y otra Y:
IDENTIFICACIÓN X tiene un miembro o declara una variable de clase Y.
X tiene un método que toma como parámetro un objeto de clase Y.
X es un descendiente de Y.
GRASP Experto4
Las clases con responsabilidad experto deben poseer toda la información para ejecutar algo, así se
OBJETIVOS
logrará mayor cohesión y la información se mantiene encapsulada, disminuyendo el acoplamiento.
El objetivo es asignar la responsabilidad al experto en información.
Los beneficios que se obtienen al establecer las responsabilidades son:
BENEFICIOS Los objetos utilizan su propia información para ejecutar su función (encapsulamiento).
Se distribuye el comportamiento entre las clases que tienen la información (cohesión).
Facilitan el entendimiento y mantención.
SOLUCIÓN Asignar la responsabilidad al experto en información.
IDENTIFICACIÓN Las clases deben hacer las cosas relacionadas con la información que poseen.
Identificar la clase que posea la información necesaria para desempeñar la función.
2 Acoplamiento es la medida en que una clase depende de otra, a menor dependencia, menor acoplamiento y viceversa.
3 Cohesión es la medida en que están relacionadas las responsabilidades de una clase.
4 Es la responsabilidad basal que deben tener las clases que poseen toda la información necesaria para ejecutar una función.
_Guía de aprendizaje
_ Principios de diseño 14
GRASP Creador5
OBJETIVOS Asignar la responsabilidad a las clases u objetos que agreguen, contengan, registren, utilicen más o
posean los datos de inicialización de las instancias.
BENEFICIOS Soporta el bajo acoplamiento, es decir, este no se incrementa.
La clase creadora debe ser capaz de alguna de las siguientes funciones:
Tener la información necesaria para realizar la creación del objeto.
SOLUCIÓN
Usar directamente las instancias creadas del objeto.
Almacenar o administrar varias instancias de la clase.
Contener o agregar la clase.
Dada una clase X e Y, Y es responsable de crear una instancia de X si:
Y agrega objetos de X.
IDENTIFICACIÓN Y contiene referencias a objetos de X.
Y almacena instancias de X.
Y utiliza estrechamente objetos de X.
Y tiene la información de inicialización que se necesita para crear un objeto de clase X.
GRASP Controlador6
Separar la lógica de negocio de la capa de presentación, para aumentar la reutilización de código y tener
OBJETIVOS
un mayor control.
Recibe la solicitud de servicio y coordina su realización delegando a otros objetos.
BENEFICIOS Al dividir los eventos del sistema en el mayor número de controladores posible, permite aumentar la
cohesión y disminuir el acoplamiento.
Asignar la responsabilidad de controlar el flujo de eventos del sistema a clases específicas.
Esto facilita la centralización de actividades (validaciones, seguridad, etc.).
SOLUCIÓN
Elegir un controlador de fachada, o de caso de uso, o de sesión.
En el diseño de clases de negocio, cuando no tenemos claro a qué clase pertenece la responsabilidad de
realizar una determinada tarea, crear una clase controlador que se llame igual a la tarea a desempeñar.
El controlador no realiza las actividades, las delega en otras clases con las que mantiene un modelo de
IDENTIFICACIÓN alta cohesión.
En aplicaciones web, se tiende a separar la lógica de presentación de la lógica de negocio.
Patrones bien conocidos como MVC o Fachada, son de amplia utilización.
5 Es la responsabilidad que deben tener las clases que deben ser el responsable de la creación (o instanciación) de nuevos objetos o clases.
6 Es la responsabilidad de administrar un evento del sistema, recibiendo los datos y enviándolos a las distintas clases, según el método
utilizado.
_Guía de aprendizaje
_ Principios de diseño 15
GoF Creación
Se recomienda ocuparlo cuando:
El sistema debe ser independiente de cómo sus productos se crean, componen y representan.
ABSTRACT FACTORY
El sistema debe configurarse con una familia de productos, de entre varios posibles.
Se quiere dar énfasis a la restricción de que una familia de productos ha sido diseñada para que
actúen todos juntos.
Se quiere proporcionar una librería de clases de productos, de los que solo se desea revelar su interfaz,
no su implementación.
Sus principales ventajas son:
Potencia el encapsulamiento, puesto que se aísla a los clientes de las implementaciones.
Incrementa la flexibilidad del diseño, resultando fácil cambiar de familia de productos.
Refuerza la consistencia, puesto que se restringe el uso a productos de una sola familia cada vez.
Se recomienda ocuparlo cuando:
El algoritmo de creación del objeto complejo debe ser independiente de sus partes y el modo que lo
componen.
El proceso de construcción debe soportar diferentes representaciones para el objeto que se construye.
Sus principales ventajas son:
El diseño gana en flexibilidad, dado que cambiar la representación interna del producto que se
BUILDER
_Guía de aprendizaje
_ Principios de diseño 16
GoF Creación
Se recomienda ocuparlo cuando:
El sistema debe ser independiente del modo que se crean, componen y representan sus productos.
Las clases a instanciar se especifican en tiempo real.
Se quiere evitar construir una jerarquía de fábricas paralela a la de productos.
Las instancias de una clase pueden tomar una de entre pocas combinaciones distintas de estado.
Sus principales ventajas son:
PROTOTYPE
Potencia el encapsulamiento, porque al igual que Abstract Factory y Builder, oculta al cliente las
clases de productos concretos con los que trabaja.
Dota al sistema de una mayor flexibilidad, pues se pueden añadir/eliminar productos concretos
dinámicamente.
Se pueden definir nuevos tipos de objetos instanciando clases ya existentes y registrando estas
instancias como nuevos prototipos para el cliente.
Se reduce drásticamente la especialización mediante herencia, lo cual siempre ayuda a la
reutilización.
Permite configurar una aplicación en tiempo de ejecución: añadir/eliminar clases dinámicamente.
Se recomienda ocuparlo cuando:
Debe haber solo una instancia de una clase y debe ser claro su acceso para los clientes.
La instancia debe ser especializada mediante herencia y los clientes deben poder usar la instancia
SINGLETON
GoF Estructurales
Se recomienda ocuparlo cuando:
Se necesita usar una clase, cuya interfaz no corresponde con la que se va a conectar.
Para crear una clase reutilizable, que va a cooperar con otras clases con interfaces
incompatibles.
ADAPTER
Para usar varias subclases existentes, pero no es práctico adaptarlas por herencia, conviene
adaptar la interfaz de la clase de la que todas heredan.
Sus principales ventajas son:
Facilidad para redefinir el comportamiento de la clase adaptada.
Simplicidad, porque hay un solo objeto, no hay punteros ni direcciones adicionales.
Flexibilidad para que un solo adaptador trabaje con muchas clases.
Extensibilidad, porque se pueden añadir funcionalidades a todas las clases adaptadas a la vez.
_Guía de aprendizaje
_ Principios de diseño 17
GoF Estructurales
Se recomienda ocuparlo cuando:
Para evitar una unión permanente entre abstracción e implementación.
Para extender tanto abstracción como implementación por herencia.
Para evitar que posibles cambios en la implementación de una abstracción afecten a los clientes.
Para ocultar la implementación de la vista de los clientes.
Para hacer frente a una proliferación de clases, tal que el uso de la herencia no es recomendable
por su inflexibilidad.
Para tener muchos objetos compartiendo una misma implementación de manera transparente
BRIDGE
y número.
Sus principales ventajas son:
Aporta mayor flexibilidad que la herencia estática, al poder añadir una funcionalidad varias
veces.
Evita concentrar en lo alto de la jerarquía clases que pretenden satisfacer todas las posibilidades.
Las nuevas funcionalidades se componen de piezas simples, que se crean y combinan con
facilidad.
Se recomienda ocuparlo cuando:
Se pretende proporcionar una interfaz simple para un subsistema complejo.
Proporcionar al subsistema independencia y portabilidad, cuando existen muchas dependencias
entre los clientes y las clases que implementan una abstracción.
Se pretende estructurar en capas el subsistema y cada capa tendrá su propia interfaz.
FACADE
_Guía de aprendizaje
_ Principios de diseño 18
GoF Estructurales
Se recomienda ocuparlo cuando:
La aplicación usa un gran número de objetos.
Los costes de almacenamiento son muy altos, como consecuencia de lo anterior.
La mayor parte del estado del objeto puede considerarse extrínseco.
Muchos grupos de objetos pueden reemplazarse por unos pocos objetos compartidos una vez
FLYWEIGHT
GoF Comportamiento
Se recomienda ocuparlo cuando:
Una petición puede ser atendida por más de un objeto, sin necesidad de conocer antes quién
RESPONSIBILITY
resolverá.
Para trasladar una petición a un objeto de entre varios, sin especificar el receptor final.
CHAIN OF
Para modificar dinámicamente el objeto que atenderá una petición, de entre varias alternativas.
Sus principales ventajas son:
Reduce el acoplamiento, porque libera al objeto que hace la petición de saber la persona que
responde.
Otorga flexibilidad al añadir o modificar la capacidad de atender una petición, al cambiar en
forma dinámica la cadena de responsabilidad.
_Guía de aprendizaje
_ Principios de diseño 19
GoF Comportamiento
Se recomienda ocuparlo cuando:
Permite implementar menús desplegables, barras de botones y temas similares.
Sus principales ventajas son:
Permite que diferentes objetos puedan ejecutar la misma acción, sin necesidad de repetir su
COMMAND
declaración e implementación. Basta con que compartan una clase, a través de instancias
distintas de la misma.
Cambiar con facilidad (incluso dinámicamente) la acción que realiza o está asociada a un objeto.
Añadir nuevas acciones sin tocar las clases ya existentes.
Especificar, encolar y ejecutar una acción en momentos diferentes.
Contemplar la posibilidad de deshacer una operación.
Ensamblar acciones, para formar una acción compuesta (macroacción). Esto puede resultar
interesante en sistemas de información que dan soporte a transacciones.
Se recomienda ocuparlo cuando:
Cuando haya un lenguaje que interpretar y sus diferentes construcciones puedan representarse
mediante árboles sintácticos abstractos.
No debe utilizarse en gramáticas complejas, porque la jerarquía de clases se torna inmanejable.
INTERPRETER
_Guía de aprendizaje
_ Principios de diseño 20
GoF Comportamiento
Se recomienda ocuparlo cuando:
Existe un conjunto de objetos cuya comunicación está bien definida, pero es compleja, con lo que
las interdependencias que surgen están poco estructuradas y son difíciles de entender.
Reutilizar un objeto se ve dificultado por la cantidad de referencias que tiene a otros objetos.
Un comportamiento distribuido entre varias clases debe ser adaptable a las circunstancias, sin
tener que abusar de la especialización por herencia.
Sus principales ventajas son:
MEDIATOR
Si existe riesgo de que una interfaz directa, abierta sobre el propio objeto, pueda exponer
detalles de implementación del mismo, rompiendo así el encapsulamiento.
Sus principales ventajas son:
Salvaguarda el encapsulamiento, impidiendo la exposición pública de información que solo el
originador debe manejar.
Simplifica al objeto originador. Otros diseños que también preservan el encapsulamiento,
tendrían que hacerse cargo del mantenimiento de todas las versiones.
Se recomienda ocuparlo cuando:
Una abstracción presenta dos aspectos, uno dependiente del otro.
Un cambio en un objeto requiere cambiar otros objetos y no sabemos cuántos exactamente lo
necesitarán.
Un objeto debe poder notificar sus cambios a otros objetos, sin necesidad de saber nada acerca
OBSERVER
_Guía de aprendizaje
_ Principios de diseño 21
GoF Comportamiento
Se recomienda ocuparlo cuando:
El comportamiento de un objeto depende de su estado y debe poder cambiar dinámicamente
dicho comportamiento en tiempo de ejecución.
Cuando las operaciones tienen definiciones largas y con múltiples condiciones, dependientes del
estado del objeto, siendo lo más adecuado separar en objetos independientes cada condición
atómica, para poder así combinarlas y modificarlas en estados ya existentes o en otros nuevos
que se formen combinándolos.
Sus principales ventajas son:
Dado que el comportamiento específico de cada estado está autocontenido en cada estado
STATE
concreto, existe una gran flexibilidad para añadir nuevos estados y transiciones mediante la
definición de nuevas subclases.
A pesar de que la distribución del comportamiento ante diferentes situaciones entre diferentes
objetos incrementa el Nº de clases y reduce la compacidad, es la mejor solución cuando hay
muchos estados, pues evita las definiciones multicondicionales y grandes, tan indeseables como
los procedimientos gigantes lo son en el estilo imperativo.
Se hacen más explícitas las transiciones entre estados, impidiendo los estados internos
inconsistentes. Si todo estuviera concentrado en una sola clase, esto no sería posible.
Si los objetos que representan los estados no tienen variables de instancia, entonces diferentes
contextos pueden compartir estados.
Se recomienda ocuparlo cuando:
Implementar una sola vez las partes invariantes de un algoritmo, permitiendo a las subclases
implementar el comportamiento que puede variar.
Sacar factor común del comportamiento compartido por varias clases, para localizarlo en un
TEMPLATE METHOD
_Guía de aprendizaje
_ Principios de diseño 22
GoF Comportamiento
Se recomienda ocuparlo cuando:
Muchas clases relacionadas solo se diferencian en su comportamiento.
Se necesitan diferentes variantes de un algoritmo.
Un algoritmo usa datos que los clientes no tienen por qué conocer.
Una clase define muchos comportamientos, los cuales se manifiestan como definiciones
condicionales múltiples de sus operaciones.
STRATEGY
Referencias bibliográficas
Gutierrez, C. (2011). Casos prácticos de UML. Madrid, España: Editorial Complutense.
Acosta, R., Arellano, M. & Barrios, F. (2009). Flujograma. Caracas, Venenzuela: Apuntes.
García, F. J. (1998). Patrones. De Alexander a la Tecnología de Objetos. Revista Profesional para Programadores (RPP),
Editorial América-Ibérica, 45, 44-52. Recuperado el 15 de marzo de 2017 desde:
https://gredos.usal.es/jspui/bitstream/10366/121937/3/DIA_GarciaPenalvo_Patrones.pdf
_Guía de aprendizaje