You are on page 1of 22

_ Principios de diseño 1

GUÍA DE APRENDIZAJE

PRINCIPIOS DE DISEÑO
_ Principios de diseño 2

Dirección de Planificación y Desarrollo Online - INACAP Online


Universidad Tecnológica de Chile - INACAP
www.inacap.cl
Santiago de Chile

Equipo de Autoría

Experto Disciplinar: Ricardo Toloza


Diseñador Instruccional: Camila Escobar
Editor de Contenidos Camila Oróstica
Diseñador Gráfico: Sebastián Cifuentes

Febrero 2017. Propiedad de INACAP


Versión: 1.0 (02/2017)
Palabras claves: sistemas de información, unidad dos, diseño

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.

Entonces entramos en las disyuntivas:


¿Cuál escogemos?
¿Cuál es la correcta?
¿Con cuál obtengo más beneficios?

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.

Bibliografía asociada al tema:


 Cabot Sagrera, J. (2013). Ingeniería del software. Barcelona, España: Editorial UOC.
Ingeniería web: pp. 189-190.
Desarrollo por modelos: pp. 190-191.
Reutilización: pp. 191-192.
Verificación y validación: pp. 192-193.

Tema 1. Notaciones del diseño de software


Muchas notaciones y lenguajes existen para representar los artefactos del diseño de software. Algunos se utilizan
principalmente para describir un diseño de organización estructural, otros para representar el comportamiento del
software. Algunas notaciones se utilizan, sobre todo, en el diseño arquitectónico y otras, principalmente, durante el
diseño detallado: también pueden ser utilizadas en ambas etapas.

_Guía de aprendizaje
_ Principios de diseño 4

1.1 Descripción estructural (vista estática)


Describe y representa los aspectos estructurales del diseño de software, es decir, se describen los principales
componentes y la forma en que se interconectan.

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.

DIAGRAMAS DE COMPONENTES Se usa para representar un conjunto de componentes.

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.

Se utilizan para representar un conjunto de nodos (física) y sus interrelaciones,


DIAGRAMAS DE DESPLIEGUE
y, por tanto, para moldear los aspectos físicos de un sistema.

Se utilizan para representar los modelos conceptuales de los datos almacenados


DIAGRAMAS DE ENTIDAD - RELACIÓN
en sistemas de información.

Lenguajes de programación que se utilizan para definir las interfaces (nombres


LENGUAJES DESCRIPCIÓN DE INTERFAZ
y tipos de operaciones de exportación) de los componentes de software.

DIAGRAMAS ESTRUCTURALES DE Se utilizan para describir las estructuras de datos en términos de secuencia,
JACKSON selección e iteración.

Se utilizan para describir la estructura de llamada de los programas (en el cual


DIAGRAMAS DE ESTRUCTURA describe el llamado de los módulos, y el modo que un módulo es llamado por
otro módulo).

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, España: Editorial UOC.
Diagramas de clases: pp. 37 - 69.
Diagrama de componentes: pp. 102 -104.
Diagrama de despliegue: pp. 105 - 106.
Diagrama de colaboración: pp. 88 - 94.
Diagrama de despliegue: pp. 105 - 106.

1.2 Descripción del comportamiento (vista dinámica)


Las siguientes notaciones y los lenguajes gráficos y textuales se utilizan para describir el comportamiento dinámico del
software y sus componentes. Muchas de estas notaciones son útiles sobre todo durante el diseño detallado.

_Guía de aprendizaje
_ Principios de diseño 5

DIAGRAMAS DE ACTIVIDAD Se utilizan para mostrar el flujo de control de una actividad.

Se utilizan para mostrar el resultado de las interacciones que se producen entre


DIAGRAMAS DE COLABORACIÓN
un grupo de objetos, sus vínculos y los mensajes de intercambio en estos enlaces.

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

Se utilizan para mostrar el resultado de las interacciones entre un grupo de


DIAGRAMAS DE SECUENCIA
objetos, con énfasis en el tiempo-pedido de mensajes.

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.

Lenguajes textuales que utilizan conceptos básicos de las matemáticas (por


LENGUAJES DE ESPECIFICACIÓN ejemplo, lógica, ju, secuencia) de forma rigurosa y abstracta. Definen el software
FORMAL interfaces, componentes y comportamiento, a menudo en términos de pre y
poscondiciones.

Lenguajes estructurados, como los lenguajes de programación utilizados para


PSEUDOCÓDIGO Y LENGUAJES DE
describir el comportamiento de un procedimiento o método generalmente en la
PROGRAMACIÓN DE DISEÑO fase de proyecto.

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, España: Editorial UOC.
Diagrama de secuencia: pp. 95 a 99.
Diagrama de estados: pp. 71 a 83.
 Gutierrez, C. (2011). Casos prácticos de UML. Madrid, España: Editorial Complutense.
Modelo de los estados en UML: pp. 77 a 93.
 Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.
Diagrama de actividad: capítulo 3, pp. 47-80.
Diagrama de estados: capítulo 7, pp. 157-174.
 Acosta, R., Arellano, M. & Barrios, F. (2009). Flujograma. Caracas, Venezuela: Apuntes.

_Guía de aprendizaje
_ Principios de diseño 6

Tema 2. Estrategias y métodos de diseño del software


Las estrategias consisten en descripciones generales de un proceso y directrices, dando origen a métodos que pueden
ser usados como referencia por los ingenieros del software al momento de desarrollar un sistema de información.
Algunas estrategias generales útiles ocupadas para el proceso de diseño son:

 Dividir para lograr óptimos resultados.


 Realizar un refinamiento paso a paso.
 La estrategia de arriba hacia abajo versus las de abajo hacia arriba.
 La extracción de datos y ocultamiento de información.
 El uso de la heurística.
 El uso de patrones y patrones de lenguajes.
 El uso de un enfoque iterativo e incremental.

2.1 Diseño orientado a funciones (diseño estructurado)


Este es uno de los métodos clásicos de diseño de software, donde los centros de descomposición se realizan en la
identificación de las principales funciones del software y, a continuación, se procede con la elaboración y refinación
de arriba hacia abajo.

El diseño estructurado se utiliza generalmente después de un análisis estructurado, lo


que produce, entre otras cosas, los datos de diagramas de flujo y descripciones de
procesos asociados.

2.2 Diseño orientado a objetos


En el mundo de la informática se han propuesto numerosos métodos de diseño de software basados en objetos. Es así
como el campo del diseño ha evolucionado a partir del diseño de objetos desde mediados de 1980, avanzando cada
vez más hacia el diseño orientado a objetos, en el que la herencia y el polimorfismo desempeñan un papel clave.

Realizando un paralelo con la gramática, resulta:


 Sustantivo = objeto
 Verbo = método
 Adjetivo = atributo

2.3 Diseño centrado en datos


Es un diseño centrado en la estructura de dato, donde el ingeniero de software describe, en primer lugar, los datos de
entrada y salida de estructura (por ejemplo, usando diagramas de estructura de Jackson) y, a continuación, se
desarrolla la estructura del control de programa sobre la base de estos diagramas.

2.4 Diseño basado en componentes (CDB)


Un componente de software es una unidad independiente, que tiene bien definida interfaces y dependencias que se
pueden componer y desplegar en forma independiente. Aborda temas relacionados con la prestación, desarrollo y la
integración de dichos componentes con el fin de mejorar la reutilización.

_Guía de aprendizaje
_ Principios de diseño 7

Tema 3. Tipos de diseño


En el proceso previo al desarrollo de una solución de cualquier tipo, se realiza una fase de diseño en la cual se pueden
reusar componentes de diseño que han sido útiles en otras soluciones, esto permite agilizar y fortalecer el proceso de
desarrollo.

Tenemos dos tipos de diseño, cuya adopción va a depender de los factores que revisamos a continuación.

3.1 Diseño a la medida


El diseño a la medida se fundamenta en los resultados de los procesos de análisis de requisitos que se han efectuado
sobre necesidades específicas de los clientes, que no pueden ser cubiertas por un software genérico. También se lleva
adelante un proceso de diseño a la medida cuando los clientes buscan una solución novedosa, con requisitos propios.

3.2 Diseño genérico


El diseño genérico utiliza los resultados de diseños anteriores que, por sus características, pueden ser ajustados a un
desarrollo determinado, tal es el caso de los patrones de diseño, que pueden ser utilizados en diversos proyectos
informáticos cada vez que se requiera.

3.3 Estandarización del diseño


La forma de enfrentar el diseño puede ser tan variada como se imagine, por lo tanto, es necesario documentar y
establecer formas y mecanismos cuyo uso garantice que el diseño sea desarrollado desde perspectivas preestablecidas
de acuerdo al tipo de software que se quiera desarrollar.

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.

Es recomendable seguir las siguientes fases al momento de estandarizar:


 Determinar el área a estandarizar.
 Seleccionar los estándares aplicables.
 Documentar el procedimiento de implementación.
 Implementar, capacitar y difundir.
 Aplicar y controlar.

Tema 4. Modelo 4 + 1 - Vistas de Kruchten


Seguramente has visto diagramas que tratan de mostrar el diseño, arquitectura o composición de un Sistema de
Información, utilizando la misma notación. Todos ellos tienen un gran trabajo de fondo, pero finalmente no logran
expresar correctamente toda la definición de diseño que se requiere. El usuario final tiene puesto su interés en la

_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.

El profesor Philippe Kruchten planteó en 1994 un modelo que pretende ordenar


la forma de documentar el diseño en base a 4 vistas bien definidas y
diferenciadas, las cuales se relacionan por una quinta vista que representa la
situación a resolver y se conoce como Escenario.
Entenderemos que una vista es la representación del sistema bajo una determinada perspectiva, donde cada vista
muestra lo que es de su competencia, utilizando para ello diferentes notaciones o simbologías. Para entenderla,
debemos conocer el significado de la notación, bajo ese contexto.

Una misma notación o representación de un diagrama puede significar cosas


diferentes, dependiendo de la vista que está tratando de mostrar.
Entonces, la propuesta de Kruchten es documentar un sistema de software con 4 vistas bien diferenciadas y estas 4
vistas se han de relacionar entre sí con una vista más, que es la denominada vista +1.

La IEEE formalizó esta propuesta en el estándar IEEE 1471-2000.

4.1 Vista lógica


En esta vista se representa la funcionalidad que el sistema proporcionará a los usuarios finales. Debe representar lo
que el sistema ha de hacer, las funciones y servicios que ofrece, documentar el análisis y la especificación de los
requisitos funcionales, aquello que el sistema debería proporcionar en términos de servicios a sus usuarios,
descomponiéndolo en un conjunto de abstracciones tomadas del dominio del problema en forma de objetos o clases.

Aquí se aplican los principios de abstracción, encapsulamiento y herencia.


4.1.1 Diagramas
Esta vista se apoya en los diagramas UML de clases y secuencia. Los primeros muestran un conjunto de clases y sus
relaciones lógicas: asociaciones, uso, composición, herencia y similares. Los grupos de clases relacionadas pueden
agruparse en categorías de clases. Los templates de clases se centran en cada clase individual, enfatizan las
operaciones principales de la clase e identifican las principales características del objeto.

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

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, España: Editorial UOC.
Diagramas de clases: pp. 37 a 69.
Diagrama de secuencia: pp. 95 a 99.
Diagrama de estados: pp. 71 a 83.
 Gutierrez, C. (2011). Casos prácticos de UML. Madrid, España: Editorial Complutense.
Modelo de los estados en UML: pp. 77 a 93
 Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.
Diagrama de clases: capítulo 5, pp. 101 a 130.
Cómo se relacionan las clases: capítulo 6, pp. 131 a 155.

4.2 Vista de desarrollo


En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de la gestión del software. En
otras palabras, se va a mostrar cómo está dividido el sistema de software en componentes y las dependencias que hay
entre esos componentes. El software se empaqueta en partes pequeñas: bibliotecas de programas o subsistemas. Los
subsistemas se organizan en una jerarquía de capas, cada una de las cuales brinda una interfaz estrecha y bien definida
hacia las capas superiores.

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.

Esta vista es trazable con la vista lógica.


4.2.1 Diagramas
Esta vista se apoya en los diagramas UML de componentes y paquetes, es por esto que se recomienda definir de cuatro
a seis capas de subsistemas en la vista de desarrollo, donde una regla de diseño es que un subsistema puede solamente
depender de subsistemas en la misma capa o en las menores. Esto minimiza las dependencias entre módulos a favor
de una más simple.

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, ES: Editorial UOC.
Paquetes: pp. 40 a 43.
Componentes: pp. 102 a 105.
 Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.
Modelado de Componentes: capítulo 8, pp. 175 a 184.

_Guía de aprendizaje
_ Principios de diseño 10

4.3 Vista de procesos


En esta vista se tratan los aspectos dinámicos del sistema, explica los procesos y el modo que se comunican. Se
representa desde la perspectiva de un integrador de sistemas, el flujo de trabajo paso a paso de negocio y
operacionales de los componentes que conforman el sistema, enfocándose en el comportamiento del sistema en
tiempo de ejecución.

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.

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, ES: Editorial UOC.
Diagrama de Estados: pp. 71 a 83.
Diagrama de Secuencia: pp. 95 a 99.
Diagrama de Actividad: pp. 99 a 102.
 Gutierrez, C. (2011). Casos prácticos de UML. Madrid, ES: Editorial Complutense.
Modelo de los estados en UML: pp. 77 a 93.
 Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.
Diagrama de actividad: capítulo 3, pp. 47 a 79.
Diagrama de estados: capítulo 7, pp. 157 a 174.

4.4 Vista física


En esta vista se muestra, desde la perspectiva de un ingeniero de sistemas, todos los componentes físicos de un
sistema, así como las conexiones físicas entre esos componentes que conforman la solución, especialmente los
servicios. La vista física contiene los nodos que forman la topología de hardware sobre la que se ejecuta el sistema y
se preocupa principalmente de la distribución, entrega e instalación de las partes que constituyen el sistema.

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.

1 Un proceso es una agrupación de tareas que forman una unidad ejecutable.

_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.

La vista física es trazable con la vista de procesos


4.4.1 Diagramas
Esta vista se apoya en los diagramas UML de despliegue, interacción y actividad.

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, España: Editorial UOC.
Diagrama de despliegue: pp. 105 a 107.
Diagrama de interacción: pp. 88 a 99.
Diagrama de actividad: pp. 99 a 102.
 Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.
Diagrama de interacción: capítulo 4, pp. 81 a 99.
Diagrama de actividad: capítulo 3, pp. 47 a 79.

4.6 Vista de escenarios


Los escenarios describen secuencias de interacciones entre objetos, y entre procesos, por este motivo es utilizada para
identificar y validar el diseño de arquitectura. También sirven como punto de partida para pruebas de un prototipo de
arquitectura.

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

Bibliografía asociada al tema:


 Campderrich, B. (2003). Ingeniería del software. Barcelona, España: Editorial UOC.
Diagrama de Casos de Uso: pp. 83 a 87.
 Gutierrez, C. (2011). Casos prácticos de UML. Madrid, España: Editorial Complutense.
Modelo de casos de uso en UML: pp. 67 a 76
 Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.
Capítulo 2, pp. 17 a 46.

Tema 5. Patrones de Diseño


En el ámbito de la construcción de soluciones utilizando software, es habitual encontrar elementos que se repiten,
independiente del problema o la casuística, que son necesarios e incluso indispensables.

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.

Es un patrón que debe cumplir además con las siguientes características:


PATRÓN DE


DISEÑO

Haber comprobado su efectividad en solución de problemas afines.


 Capacidad de aplicar a diferentes problemas de diseño, bajo distintas circunstancias.
 La reutilización logra desarrollos robustos.
 Permiten ser modificados y ajustados, de acuerdo a los distintos escenarios.

6.1 Patrones GRASP


General Responsibility Assignment Software Patterns, cuyo acrónimo es GRASP, son patrones o buenas prácticas que
nos orientan en asignar responsabilidades para elegir las clases adecuadas y definir el modo interactuarán,
independiente de las metodologías.

_Guía de aprendizaje
_ Principios de diseño 13

GRASP Bajo acoplamiento2


Las clases deben tener la mayor independencia posible, para que las modificaciones que se requieran no
OBJETIVOS
afecten al resto o lo hagan con una mínima repercusión. El objetivo es lograr un bajo nivel de
acoplamiento entre las clases.
Al disminuir la dependencia entre clases (bajo acoplamiento), se obtienen los siguientes beneficios:
BENEFICIOS  Una clase no se afecta por los cambios de otra.
 La clase es más fácil de entender por separado.
 La clase es fácil de reutilizar.
SOLUCIÓN Asignar responsabilidades de tal manera que el acoplamiento sea el menor posible.

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 Alta cohesión3


Las clases deben mantener la mayor cohesión posible, porque con ello incrementa la claridad y facilita la
OBJETIVOS
comprensión, simplificando el mantenimiento. Esto permite casi siempre un bajo acoplamiento e
incrementar la reutilización.
Al aumentar la cohesión entre clases se obtienen los siguientes beneficios:
 Fácil de comprender.
BENEFICIOS
 Fácil de reutilizar.
 Fácil de mantener.
 No se ve afectada por los cambios en forma drástica.
SOLUCIÓN Asignar responsabilidades de manera que la cohesión se mantenga alta.
Ejemplos de una baja cohesión son clases que hacen demasiadas cosas.
IDENTIFICACIÓN
Una clase con baja cohesión hace demasiadas cosas, generalmente inconexas, y es difícil entender,
reutilizar y mantener.

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.

6.2 Patrones GoF


Gang Of Four (GoF) o “Pandilla de los Cuatro” está conformada por Erich Gamma, Richard Helm, Ralph Johnson y John
Vlisides, que en 1995 publicaron Design Patterns, libro en el cual establecen una serie de 23 patrones de diseño
agrupados en 3 categorías: creacional, estructural y comportancional.

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

Los objetivos de estos patrones son los mismos planteados anteriormente:


 Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
 Proporcionar soluciones a problemas ya conocidos y solucionados anteriormente.
 Formalizar un vocabulario común entre diseñadores.
 Estandarizar el modo en que se realiza el diseño.
 Facilitar el aprendizaje de las nuevas generaciones de diseñadores.

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

construye es tan sencillo como definir un nuevo tipo de constructor.


 La separación entre el proceso de construcción y la representación del producto fomenta la
reutilización, puesto que permite que diferentes directores construyan variantes de un producto a
partir del mismo conjunto de partes.
 Se favorece el encapsulamiento y el control, puesto que cada constructor concreto contiene todo el
código necesario para crear y ensamblar todas las partes de un producto y, además, el constructor
crea el producto paso a paso (parte a parte) bajo la supervisión del director, que al final recibe el
producto completo, de manos del constructor.
Se recomienda ocuparlo cuando:
 Cuando una clase no puede adelantar las clases de objetos que debe crear.
 Cuando una clase pretende que sus subclases especifiquen los objetos que ella crea.
 Cuando una clase delega su responsabilidad hacia una de entre varias subclases auxiliares y queremos
FACTORY METHOD

tener localizada a la subclase delegada.


Sus principales ventajas son:
 Crear los objetos dentro de una clase con un Factory Method es siempre más flexible que hacerlo
directamente, debido a que se elimina la necesidad de atar nuestra aplicación a unas clases de
productos concretos.
 Facilita futuras ampliaciones, porque las subclases ofrecen la posibilidad de proporcionar una versión
extendida de un objeto con solo aplicar en los productos la misma idea del Factory Method.
 Es natural la conexión entre jerarquías de clases paralelas, que son aquellas que se generan cuando
una clase delega algunas de sus responsabilidades en una clase aparte.
 Ambas jerarquías de clases paralelas son creadas por un mismo cliente y el Factory Method establece
la relación entre parejas de subclases.

_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

extendida sin modificar su código.


Sus principales ventajas son:
 Reducir el espacio de nombres (frente al uso de variables globales).
 Permitir refinamientos en las operaciones y en la representación, mediante la especialización por
herencia de singleton.
 Fácil de modificar para permitir más de una instancia y para controlar el número de las mismas,
incluso si es variable.

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

al cliente (se usan mecanismos de cuenta de referencias).


Sus principales ventajas son:
 La separación entre interfaz e implementación permite configurar esta relación dinámicamente
en tiempo de ejecución y no de compilación.
 La independencia entre interfaz e implementación favorece una mejor estructuración en niveles
del sistema.
 Esta independencia permite una mayor extensibilidad.
 Se favorece el encapsulamiento al ocultarse a los clientes detalles referentes a la
implementación.
Se recomienda ocuparlo cuando:
 Para añadir responsabilidades a un objeto de manera dinámica y transparente, independiente de
otros objetos.
 Cuando es imposible la extensión de funcionalidad por herencia, por ser ella imprevisible en tipo
DECORATOR

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

Sus principales ventajas son:


 Al separar al cliente de los componentes del subsistema, se reduce el número de objetos con los
que el cliente trata, facilitando el uso del subsistema.
 Se promueve un acoplamiento débil entre el subsistema y sus clientes, eliminándose o
reduciéndose las dependencias.
 No existen obstáculos para que las aplicaciones usen las clases del subsistema que necesiten. De
esta forma podemos elegir entre facilidad de uso y generalidad.

_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

que se ha prescindido del estado extrínseco.


 La aplicación no depende de la identidad de los objetos.
Sus principales ventajas son:
 Mejora en la eficiencia, sobre todo en relación con el ahorro en el almacenamiento, que
aumenta paralelamente con la compartición de objetos y es función de:
o Reducción en el número total de instancias.
o La cantidad de estado intrínseco por objeto.
o Si el estado extrínseco es calculado o almacenado.
Se recomienda ocuparlo cuando:
 Un apoderado remoto proporciona un representante local para un objeto.
 Un apoderado virtual crea por demanda objetos costosos.
 Un apoderado de protección restringe, por motivos de seguridad, el acceso a un objeto.
Sus principales ventajas son:
PROXY

 Introducir un nivel de indirección en el acceso al objeto, que permite:


o Al apoderado remoto, ocultar el hecho de que el objeto reside en un espacio de
direcciones distinto.
o Al apoderado virtual, realizar optimizaciones como la creación de objetos por demanda.
o Al apoderado de protección y a las referencias, realizar tareas adicionales de vigilancia
sobre el objeto al que se accede.
 Facilita la creación de objetos bajo demanda.

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

En estos casos se recomienda utilizar máquinas de estado finitas.


Sus principales ventajas son:
 Facilidad para cambiar o extender la gramática, mediante herencia, dado que las diferentes
reglas de la gramática se representan con clases.
 Facilidad para implementar la gramática, dado que las implementaciones de las clases nodo del
árbol sintáctico son similares, pudiendo usarse para ello generadores automáticos de código.
 Facilidad para introducir nuevas formas de interpretar las expresiones en la gramática.
Se recomienda ocuparlo cuando:
 Requiere acceder a los elementos de un objeto agregado, sin mostrar su representación interna.
 Para permitir recorridos múltiples en objetos agregados.
 Requiere proporcionar una interfaz uniforme, para recorrer diferentes estructuras de
agregación.
ITERATOR

Sus principales ventajas son:


 Incrementa la flexibilidad, dado que para permitir nuevas formas de recorrer una estructura,
basta con modificar el iterador en uso.
 Enfatiza la distribución de responsabilidades, dado que la interfaz del agregado se ve libre de
una serie de operaciones que son propias de la interfaz del iterador.
 Facilitan el paralelismo y la concurrencia. Como cada iterador tiene consciencia de su estado en
cada momento, es posible que dos o más iteradores recorran una misma estructura al mismo
tiempo.

_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

 Limita el uso de la herencia, al concentrar un comportamiento que estaría distribuido entre


diversos objetos.
 Al reducir el acoplamiento entre los objetos que interactúan, es más fácil variar o reutilizar
dichos objetos.
 Se simplifican los protocolos de comunicación entre los objetos, al sustituir las relaciones muchos
a muchos, por relaciones uno a muchos, que son más sencillas de entender, mantener y
extender.
 Al hacer de la mediación un concepto independiente, encapsulado en un objeto aparte, se
favorece el centrar la atención en la interacción entre objetos, al margen del comportamiento
individual de cada uno.
Se recomienda ocuparlo cuando:
 Sea necesario registrar el estado interno de un objeto, para permitir posteriores restauraciones
de dicho estado.
MEMENTO

 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

de su identidad (acoplamiento débil).


Sus principales ventajas son:
 Encapsular estos aspectos en objetos separados, nos permite variar y reutilizarlos
independientemente.
 El acoplamiento que existe es mínimo y abstracto, permitiendo a los objetos evolucionar en
diferentes niveles de detalle, en forma independiente.
 Facilita y simplifica las notificaciones.

_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

única clase, que evita la duplicación de código, bajo el siguiente esquema:


o Identificar las diferencias en el código ya existente.
o Separarlas, convirtiéndolas en operaciones nuevas.
o Reemplazar las diferencias en el código existente por un método que invoque a las
operaciones que necesite.
 Cuando se quieren controlar las extensiones de las subclases.
Sus principales ventajas son:
 Técnica fundamental para reutilizar código, especialmente en las librerías de clases, donde son
la razón de ser de la factorización de comportamiento común.
 Llevan a una estructura de control invertido, donde la clase padre invoca la implementación que
tiene la clase hija.
Se recomienda ocuparlo cuando:
 Una estructura de objetos contiene muchas clases con diferentes interfaces y se quieren añadir
operaciones a dichos objetos en función de la interfaz.
 Se quiere añadir a los objetos de una estructura, operaciones muy diferentes y sin relación
alguna entre ellas, sin necesidad de hacerlo a nivel individual.
 Las clases que definen la estructura de objetos casi nunca cambian, pero frecuentemente
queremos añadir nuevas operaciones a ciertos objetos de la estructura.
VISITOR

Sus principales ventajas son:


 Es fácil añadir nuevas operaciones a la estructura de objetos, solo hay que crear un nuevo
visitante, en vez de cambiar todas las clases a las que queremos que afecte.
 Se juntan las operaciones relacionadas entre sí, separándose las que nada tienen que ver. Esto
simplifica tanto las clases de los elementos, como los algoritmos definidos.
 Se pueden recorrer jerarquías formadas por objetos de distintos tipos, mientras que un iterador
no puede hacer esto.
 Se puede ir acumulando el estado a medida que se recorre la estructura, en vez de tener que
pasarlo como parámetro o guardarlo en variables globales.

_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

Sus principales ventajas son:


 Las familias jerárquicas de estrategias definen algoritmos y comportamientos que enfatizan la
reutilización. La herencia puede ayudar a sacar factor común a la funcionalidad de los
algoritmos.
 El encapsulamiento de algoritmos en clases separadas, ofrece una alternativa a la
especialización por herencia, para obtener un comportamiento diferente que promueve la
independencia, la facilidad de entender el diseño y la posibilidad de futuras extensiones.
 Se eliminan las costosas definiciones de comportamiento multicondicionales.
 Se posibilita ofrecer diferentes implementaciones del mismo comportamiento, en función de
restricciones como el espacio en memoria o el tiempo de respuesta.

Bibliografía asociada al tema:


 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

Referencias bibliográficas
Gutierrez, C. (2011). Casos prácticos de UML. Madrid, España: Editorial Complutense.

Campderrich, B. (2003). Ingeniería del software. Barcelona, España: Editorial UOC.

Kimmel, P. (2008). Manual de UML. Santa Fe, México: McGraw-Hill Interamericana.

Cabot, J. (2013). Ingeniería del software. Barcelona, España: Editorial UOC.

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

You might also like