UML y Patrones – Craig Larman 2da. Ed.

Metodología Larman.

 ¿Qué es el análisis y el diseño?

El análisis pone énfasis en una investigación del problema y los requisitos en vez de ponerlo en
una solución. Se puede clasificar como análisis de requisitos (un estudio de los requisitos) o
análisis de objetos (un estudio del objeto del dominio).

El diseño pone énfasis en una solución conceptual que satisface los requisitos, en vez de
ponerlo en la implementación.

 ¿Qué son el análisis y el diseño orientado a objetos?

Durante el análisis orientado a objetos, se presta especial atención a encontrar y describir los los
objetos – o conceptos – en el dominio del problema.

Durante el diseño orientado a objetos, se presta especial atención a la definición de los objetos
de software y en como colaboran para satisfacer los requisitos.

 Desarrollo iterativo y proceso unificado.

El desarrollo iterativo es un enfoque para el desarrollo de software y juega un papel central en

el modo en que se presenta el A/DOO.

Un proceso de desarrollo de software describe un enfoque para la construcción, desarrollo y,

posiblemente mantenimiento del software.

El proceso unificado es un ejemplo de proceso iterativo para proyectos que utilizan el A/DOO,
y se ha convertido en un proceso de desarrollo de software de gran éxito para construcción de
sistemas orientados a objeto.

El UP combina las practicas comúnmente aceptadas, tales como el ciclo de vida iterativo y
desarrollo dirigido por el riesgo, es una descripción consistente y bien documentada;
proporciona una estructura organizada de ejemplo para discutir sobre hacer – y como aprender
– el A/DOO.

o La idea más importante del UP: el desarrollo iterativo.

El UP fomenta el desarrollo iterativo, en este enfoque, el desarrollo se organiza en una

serie de mini-proyectos cortos, de duración fija llamado iteraciones; el resultado de
cada uno es un sistema que puede ser probado, integrado y ejecutado. Cada iteración
incluye sus propias actividades de análisis de requisitos, diseño, implementación y
pruebas.

El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema

mediante múltiple iteraciones, con retroalimentación cíclica y adaptación como
elementos principales que dirigen para converger hacia un sistema adecuado. El sistema

Auad, Diego F. & Paez, Pablo E. Página 1

UML y Patrones – Craig Larman 2da. Ed.

crece incrementalmente a lo largo del tiempo, es por esto, que este enfoque también se
conoce como desarrollo iterativo e incremental.

o Las fases del UP y términos orientados a la planificación.

Un proyecto UP organiza el trabajo y las iteraciones en cuatro fases fundamentales:

 Inicio: visión aproximada, análisis del negocio, alcance, estimulaciones

imprecisas.
 Elaboración: visión refinada, implementación iterativa del núcleo central
de la arquitectura, resolución de los riesgos altos, identificación de más
requisitos y alcance, estimaciones más realistas.
 Construcción: implementación iterativa del resto de requisitos de menor
riesgo y elementos más fáciles, preparación para el despliegue.
 Transición: prueba beta, despliegue.

Esto no se corresponde con el antiguo ciclo de vida en “cascada” o secuencial, en el que

primero se definían todos los requisitos y, después, se realizaba todo, o la mayoría, del
diseño.

La fase de inicio no es una fase de requisitos; sino una especie de fase de viabilidad,
donde se lleva a cabo solo el estudio suficiente para decidir si continuar o no.

De igual modo, la fase de elaboración no es la fase de requisitos o de diseño, sino que

es una fase donde se implementa, de manera iterativa, la arquitectura que constituye el
núcleo central y se mitigan las cuestiones de alto riesgo.

o Las disciplinas del UP (eran flujos de trabajo).

El UP describe actividades de trabajo, como escribir casos de uso, en disciplina.

Informalmente, una disciplina es un conjunto de actividades (y artefactos relacionados)
en un área determinada, como las actividades en el análisis de requisitos. En el UP, un
artefacto es el término general para cualquier producto del trabajo: código, gráficos
web, esquema de DD.BB.

Auad, Diego F. & Paez, Pablo E. Página 2

UML y Patrones – Craig Larman 2da. Ed.

Hay varias disciplinas en el UP:

 Modelado de negocio: cuando se desarrolla una aplicación, esto incluye el

modelado de los objetos del dominio. Cuando se está haciendo análisis del
negocio a gran escala o reingeniería de procesos de negocio, esto incluye el
modelado dinámico de los procesos del negocio de toda la empresa.
 Requisitos: análisis de los requisitos para una aplicación, como escritura de
casos de uso e identificación de requisitos no funcionales.
 Diseño: todos los aspectos de diseño, incluyendo la arquitectura global,
objetos, bases de datos, red y cosas parecidas.

Existen mayores disciplinas que no abordaremos. En el UP, implementación

significa programar y construir el sistema, no despliegue.

o Marco de desarrollo: la elección de los artefactos del UP – varían de acuerdo al

proyecto – podría recogerse en un documento breve denominado marco de
desarrollo.

o El UP ágil: los metodologías distinguen entre procesos pesados y ligeros, y

procesos predictivos y adaptables.
 Proceso pesado: es un término peyorativo, que pretende sugerir un proceso
con muchos artefactos creados en un ambiente burocrático, rigidez y
control, planificación detallada; y predictivo más que adaptable.
 Proceso predictivo: es aquel que intenta planificar y predecir en detalle las
actividades y asignación de recursos (personal) en un intervalo
relativamente largo de tiempo, tal como la totalidad de un proyecto;
normalmente siguen un ciclo de vida en “cascada” o secuencial.
 Proceso adaptable: es aquel que acepta el cambio como motor inevitable y
fomenta la adaptación flexible; normalmente siguen un ciclo de vida
iterativo.
 Proceso ágil: implica un proceso adaptable ligero, listo para responder
rápidamente a las necesidades cambiantes.

Auad, Diego F. & Paez, Pablo E. Página 3

UML y Patrones – Craig Larman 2da. Ed.

 UP Agil: optar por un conjunto pequeño de actividades y artefactos; se base

en retroalimentaciones debido a que el UP es iterativo; hay un plan de alto
nivel denominado – denominado el plan de fase – que estima la fecha de
terminación del proyecto y otros hitos importantes.

o El ciclo de vida en “cascada” secuencial: a diferencia del ciclo de vida iterativo

del UP, una antigua alternativa era el ciclo de vida “en cascada”, lineal o
secuencial. En su acepción habitual, definía los pasos más o menos de la siguiente
forma.
1. Determinar, registrar y acordar un conjunto de requisitos completo y
fijo.
2. Diseñar un sistema basado en estos requisitos.
3. Implementar en base al diseño.

 Fase de Inicio: su propósito es establecer una visión común inicial de los objetivos del
proyecto, determinar si es viable y decidir si merece la pena llevar a cabo algunas
investigaciones serias en la fase de elaboración. Si se ha decidido de antemano que el
proyecto se hará sin ninguna duda, y es claramente viable, entonces la fase de inicio será
especialmente breve. Podrá incluir los primeros talleres de requisitos, planificación de la
primera iteración y, entonces, rápidamente, cambiar a la elaboración.

o Artefactos que se pueden crear en la fase de inicio.

Auad, Diego F. & Paez, Pablo E. Página 4

UML y Patrones – Craig Larman 2da. Ed.

 Comprensión de los requisitos: son capacidades y funciones con las cuales debe ser
conforme el sistema –y más ampliamente, el proyecto –. El primer reto del trabajo de los
requisitos es encontrar, comunicar y recordar (que normalmente significa registrar) lo que
se necesita realmente, de manera que tenga un significado claro para el cliente y los
miembros del equipo de desarrollo.
o Tipos de requisitos: estos se clasifican de acuerdo con el modelo FURPS+.
 Funcional (Fuctional): características, capacidades y seguridad.
 Facilidad de uso (Usability): factores humanos, ayuda, documentación.
 Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperación de
un fallo y grado de previsión.
 Rendimiento (Performance): tiempos de respuesta, productividad,
precisión, disponibilidad, uso de los recursos.
 Soporte (Supportability): adaptabilidad, facilidad de mantenimiento,
internacionalización, configurabilidad.
o El „+‟ en FURPS+ indica requisitos adicionales, tales como:
 Implementación: limitación de recursos, lenguajes y herramientas,
hardware…
 Interfaz: restricciones impuestas para la interacción con sistemas externos.
 Operaciones: gestión del sistema en su puesta en marcha.
 Empaquetamiento.
 Legales: licencias, etc.
Algunos de estos requisitos se denominan colectivamente atributos de calidad,
requisitos de calidad. Lo normal es dividir los requisitos en funcionales
(comportamiento) y no funcionales (todo lo demás).
Los requisitos funcionales se estudian y recogen en el modelo de casos de uso. El
glosario en el UP también comprende el concepto de diccionario de datos, que
reúne los requisitos relacionados con los datos, como reglas de validación, valores
aceptables, etc.

 Modelos de caso de uso: son utilizados para descubrir y registrar los requisitos
(especialmente los funcionales). La escritura de casos de uso – historias del uso de un
sistema – es una técnica excelente para entender y descubrir los requisitos. El UP define el
modelo de casos de uso en la disciplina requisitos. Básicamente, es el conjunto de todos los
casos de uso; es un modelo de la funcionalidad y entorno del sistema. Hay que recordar que
los casos de uso no son orientados a objeto, de este modo podemos utilizar esta herramienta
en análisis que no sean orientados a objeto.
o Casos de uso: es una colección de escenario con existo y fallo relacionados, que
describen a los actores utilizando un sistema para satisfacer un objetivo.
 Escenario: es una secuencia especifica de acciones e interacciones entre los
actores y el sistema, objeto de estudio; también se denomina instancia de
caso de uso.
 Actor: es algo con comportamiento, como una persona (identificada por un
roll), sistemas informatizados u organización.

Auad, Diego F. & Paez, Pablo E. Página 5

UML y Patrones – Craig Larman 2da. Ed.

o Casos de uso y requisitos funcionales: los casos de uso son requisitos (aunque no
todos los requisitos); en términos de los tipos de requisitos FURPS+, hacen
referencia a la “F”(funcional o de comportamiento). Los casos de uso son
documentos de texto, no diagramas, y el modelo de casos de uso es, sobre todo, un
acción de escribir texto, no dibujar. Sin embargo, UML define un diagrama de
casos de uso para ilustrar los nombres de casos de uso y actores, y sus relaciones.

o Tipos de caso de uso y formatos.

 Casos de uso de caja negra: son la clase más común y recomendada; no

describen el funcionamiento interno del sistema, sus componentes o diseño,
sino que se describe el sistema en base a la responsabilidades que tiene, que
es una metáfora común y unificadora en el pensamiento orientado a
objetos.
 Tipos de formalidad: los casos de uso se escriben con formatos diferentes,
dependiendo de la necesidad. Además del tipo de visibilidad, de caja negra
frente a caja blanca, los caso de uso se escriben con varios grados de
formalidad:
 Breve: resumen conciso de un párrafo, normalmente del escenario
principal con éxito.
 Informal: formato de párrafo en un estilo informal. Múltiples
párrafos que comprenden varios escenarios.
 Completo: se escriben con detalle todos los pasos y variaciones, y
hay secciones de apoyo como precondiciones y garantías de éxito
(post-condiciones).

o Términos claves en los casos de uso.

 Actor principal: es el que recurre a los servicios del sistemas para cumplir
un objetivo.
 Personal involucrado y lista de intereses: son personas físicas o jurídicas,
también entidades gubernamentales, que tienen intereses puntuales en el
funcionamiento del sistema. Sugiere y delimita que es lo que debe hacer el
sistema.
 Precondiciones: establecen lo que siempre deben cumplirse antes de
comenzar un escenario en el caso de uso. Las precondiciones no se prueban
en el caso de uso, sino que son condiciones que se asumen que son verdad.
 Post-condiciones (garantías de éxito): establecen que debe cumplirse
cuando el caso de uso se completa con éxito – o bien el escenario principal
de éxito, o algún camino alternativo –. La garantía debería satisfacer las
necesidades de todo el personal involucrado.

Auad, Diego F. & Paez, Pablo E. Página 6

UML y Patrones – Craig Larman 2da. Ed.

 Escenario (flujo básico): describe el camino de éxito típico que satisface

los intereses del personal involucrado. El escenario recoge los pasos, que
pueden ser de tres tipos:
 Una interacción entre actores.
 Una validación (normalmente a cargo del sistema).
 Un cambio de estado realizado por el sistema (por ejemplo,
registrando o modificando algo).
 Extensiones: indican todos los otros escenarios o bifurcaciones, tanto de
éxito como de fracaso; posee dos partes: la condición y el manejo.
 Requisitos especiales: si un requisito no funcional, atributo de calidad, o
restricción se relaciona de manera específica con un caso de uso, se recoge
en el caso de uso. Esto incluye cualidades tales como rendimiento,
fiabilidad, factibilidad de uso, y restricciones de diseño que son obligados o
se consideran probables.
 Lista de tecnología y variaciones de datos: a menudo, encontramos
variaciones técnicas en cómo se debe hacer algo, pero no en que, y es
importante registrarlo en el caso de uso.

o Actores: es cualquier cosa con comportamiento, incluyendo el propio sistema que

se está estudiando, cuando solicita los servicios de otro sistema. Los actores no son
solamente roles que juegan personas, sino también organizaciones, software y
maquinas.
 Actor principal: tiene objetivos de usuario que se satisfacen mediante el
uso de los servicios del sistema que se está estudiando.
Se lo identifica para encontrar los objetivos de usuario, los cuales dirigen
los casos de uso.
 Actor de apoyo: proporciona un servicio (por ejemplo, información) al
sistema que se está estudiando. Normalmente se trata de un sistema
informático, pero podría ser una organización o una persona.
Se lo identifica para clasificar las interfaces externas y los protocolos.
 Actor pasivo: está interesado en el comportamiento del caso de uso, pero
no es principal ni de apoyo; por ejemplo, la agencia tributaria del gobierno.
Se lo identifica, para asegurar que todos los intereses necesarios sean
identificados y satisfechos.

o Diagramas de caso de uso: es una excelente representación del contexto del

sistema; conforma un buen diagrama de contexto, esto es, muestra los límites de un
sistema, lo que permanece fuera de él, y como se utiliza. Sirve como herramienta de
comunicación que resume el comportamiento de un sistema y sus actores.
El actor principal se coloca en la parte izquierda del diagrama de casos de uso,
mientras que los actores de apoyo se colocan en la parte derecha; si el actor es un
sistema informático se lo representa de la siguiente manera: dentro de un
rectángulo, se coloca <<actor >> y el nombre del sistema.

Auad, Diego F. & Paez, Pablo E. Página 7

UML y Patrones – Craig Larman 2da. Ed.

 De la fase de inicio, a la fase de elaboración: antes de empezar la fase de elaboración,

debemos revisar qué fue lo que sucedió en el inicio; tengamos en cuenta, que los artefactos
creados deberían ser breves e incompletos, una etapa rápida y de investigación ligera. Esta
etapa no es la fase de requisitos del proyecto, sino una etapa breve para determinar la
viabilidad, riesgo y alcances básicos, y decidir si merece la pena más investigación seria en
el proyecto, que tendrá lugar durante la fase de elaboración.
La elaboración es una fase de construcción del núcleo central de la arquitectura, resolución
de los elementos de alto riesgo, definición de la mayoría de los requisitos, y estimación de
la planificación y recursos globales. Es la seria inicial de las iteraciones.
o ¿Qué artefactos podrían crearse en la elaboración?
 Modelo de dominio: es una visualización de los conceptos del dominio; es
similar al modelo de información estático de las entidades del dominio.
 Modelo de diseño: es el conjunto que describen el diseño lógico.
Comprende los diagramas de clases software, diagramas de interacción,
diagramas de paquetes, etc.
 Documento de la arquitectura de software: una ayuda de aprendizaje que
resume las cuestiones claves de la arquitectura y como se resuelven en el
diseño. Es un resumen de las ideas destacadas del diseño y su motivación
en el sistema.
 Modelo de datos: incluye los esquemas de bases de datos, y las estrategias
de transformación entre representaciones de objetos y no objetuales.
 Modelo de pruebas: una descripción de lo que se probara y como.
 Modelo de implementación: se corresponde con la implementación real – el
código fuente, ejecutables, base de datos, etc. –.
 Guiones de caso de uso, prototipos UI: descripción de la interfaz de
usuario, caminos de navegación, modelos de facilidad de uso, etc.

 Modelo de casos de uso: representación de los Diagramas de Secuencia del Sistema: es un

dibujo que muestra, para un escenario especifico de un caso de uso, los eventos que generan
los actores externos, el orden y los eventos entre los sistemas. Todos los sistemas se tratan
como cajas negras; los diagramas destacan los eventos que cruzan los límites del sistema
desde los actores a los sistemas.
o Asignación de nombres a los eventos y operaciones: los eventos del sistema ( y sus
operaciones del sistema asociadas) deberían expresarse al nivel de intenciones en
lugar de en términos del medio de entrada físico o a nivel de elementos de la
interfaz de usuario.
También se mejora la calidad, el comenzar el nombre de un evento del sistema con
un verbo, puesto que resalta la orientación de orden de estos eventos.
De esto modo, “introducirArticulo” es mejor que “escanear” (esto es, escanear con
láser) porque captura la intención de la operación, al mismo tiempo que permanece
abstracta y sin compromiso respecto a las elecciones de diseño sobre que interfaz
utilizar para capturar el evento del sistema.

Auad, Diego F. & Paez, Pablo E. Página 8

UML y Patrones – Craig Larman 2da. Ed.

 Modelo de dominio: es una representación visual de las clases conceptuales u objetos del
mundo real en un dominio de interés. También se les denomina modelos conceptuales
(término utilizado en la primera edición de este libro), modelos de objetos del dominio y
modelos de objetos de análisis.

 Modelo de casos de uso: añadir detalles con los Contratos de las operaciones: describen el
comportamiento detallado del sistema en función de los cambios de estado de los objetos
del modelo del dominio, después de la ejecución de una operación del sistema.
o Secciones del contrato.

Operación: nombre de la operación y parámetros.

Referencias cruzadas: casos de uso en los que pueden tener lugar esta
operación (opcional).

Precondiciones: suposiciones relevantes sobre el estado del sistema o de

los objetos del modelo del dominio, antes de la ejecución de la operación.
No se comprobara en la lógica de esta operación, se asume que son verdad,
y son suposiciones no triviales que el lector debe saber que se hicieron.

Postcondiciones: describe cambios en el estado de los objetos del modelo

del dominio. Los cambios de estado del modelo del dominio comprenden la
creación de instancias, formación o rotura de asociaciones y cambio de los
atributos.

 Notación de los diagramas de interacción: es una generalización de dos tipos de diagramas

UML más especializados; ambos pueden utilizarse para representar de forma similar
interacciones de mensajes:
o Diagramas de colaboración: ilustran las interacciones entre objetos en un formato
de grafo o red, en el cual los objetos se pueden colocar en cualquier lugar del
diagrama.

 Fortalezas: economiza espacio, flexibilidad al añadir nuevos objetos en dos

dimensiones. Sirve para ilustrar bifurcaciones complejas, iteraciones y
comportamiento concurrente.
 Debilidades: resulta difícil ver las secuencia de mensajes; notación mas
compleja.

Auad, Diego F. & Paez, Pablo E. Página 9

UML y Patrones – Craig Larman 2da. Ed.

 Enlaces: es un camino de conexión entre dos objetos; indica que es posible

alguna forma de navegación y visibilidad entre los objetos. De manera mas
formal, un enlace es una instancia de una asociación. Recordemos que, a lo
largo de un mismo enlace, pueden influir multiples mensajes y mensajes en
ambas direcciones.
 Mensajes: cada mensaje entre objetos se representa con una expresión de
mensaje y una pequeña flecha que indica la dirección del mensaje. Pueden
fluir muchos mensajes a lo largo de este enlace. Se añade un numero de
secuencia, para mostrar el orden secuencial, de los mensajes en los hilos de
control actual (no se numera el primer mensaje). Se puede enviar un
mensaje a si mismo, esto se representa mediante un autolazo, con mensajes
que fluyen a lo largo de este enlace.

o Diagrama de secuencia: ilustran las interacciones en un tipo de formato con el

aspecto de una valla, en el que cada objeto nuevo se añade a la derecha.

 Fortalezas: muestra claramente la secuencia u ordenación en el tiempo de

los mensajes; notación simple.
 Debilidades: fuerza a extender por la derecha cuando se añaden nuevos
objetos; consume espacio horizontal.
 Enlaces: a diferencia de los diagramas de colaboración, los diagramas de
secuencia no muestran enlaces.
 Mensajes: cada mensaje entre objetos se representa con una expresión de
mensaje sobre una línea con punta de flecha entre los objetos. El orden en
el tiempo se organiza de arriba a abajo. Se pueden representar un auto
mensaje utilizando una caja de activación anidada.
 Focos de control y cajas de activación: los diagramas de secuencia podrían
también mostrar los focos de control (esto es, una llamada de rutina
ordinaria, la operación se encuentra en la pila de llamadas) utilizando caja
de activación. La caja es opcional, pero la utilizan habitualmente los
modeladores de UML.
 Representación de retornos: un diagrama de secuencia podría
opcionalmente mostrar el retorno de un mensaje mediante una línea
punteada con la punta de flecha abierta, al final de una caja de activación.
Lo normal es que se excluya por quienes utilizan UML. Algunos anotan la
línea de retorno para describir lo que se está devolviendo (si es el caso) a
partir del mensaje.

Auad, Diego F. & Paez, Pablo E. Página 10

UML y Patrones – Craig Larman 2da. Ed.

 GRASP: diseño de objetos con responsabilidad.

GRASP es un acrónimo de General Responsibility Assignment Software Patterns (Patrones

generales de software para asignar responsabilidades). El nombre se eligió para sugerir la
importancia de aprehender estos principios para diseñar con éxito el software orientado a
objeto.

o Responsabilidades y métodos.
UML define una responsabilidad como “un contrato y obligación de un clasificador”.
Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a
su comportamiento. Existen dos tipos:
 Hacer:
 Hacer algo él mismo, como crear un objeto o hacer un cálculo.
 Iniciar una acción en otros objetos.
 Controlar y coordinar actividades en otros objetos.
 Conocer:
 Conocer los datos privados encapsulados.
 Conocer los objetos relacionados.
 Conocer las cosas que puede derivar o calcular
Las responsabilidades se asignan a las clases de los objetos durante el diseño de
objetos. Las responsabilidades relevantes relacionadas con “conocer” a menudo se
pueden inferir a partir del modelo del dominio, debido a los atributos y
asociaciones que describe. Una responsabilidad, no es lo mismo que un método,
pero los métodos se implementan para llevar a cabo responsabilidades. Las
responsabilidades se implementan utilizando métodos que actúan solos, o colaboran
con otros métodos u objetos.

o Responsabilidades y los diagramas de interacción: los diagramas de interacción

muestran elecciones en la asignación de responsabilidades a los objetos. Cuando se
crean, se han tomado las decisiones acerca de la asignación de responsabilidades, lo
que se refleja en los mensajes que se envían a diferentes clases de objeto. Estas
elecciones se reflejan en los diagramas de interacción.

o ¿Qué son los patrones GRASP?: describen los principios fundamentales del diseño
de objetos y la asignación de responsabilidades, expresados como patrones.

o Patrones: un patrón es un par problema/solución con nombre que se puede aplicar

en nuevos contextos, con consejos acerca de cómo aplicarlo en nuevos situaciones
y discusiones sobre sus compromisos.

Auad, Diego F. & Paez, Pablo E. Página 11

UML y Patrones – Craig Larman 2da. Ed.

o Experto en Información (Experto): se comienza asignando responsabilidades,

establecimiento claramente la responsabilidad. El experto en información se utiliza
con frecuencia en la asignación de responsabilidades; es un principio de guía básico
que se utiliza continuamente en el diseño de objetos. El experto no pretende ser una
idea oscura o extravagante, expresa la “intuición” común de que los objetos hacen
las cosas relacionadas con la información que tienen.
 Beneficios:
 Se mantiene el encapsulamiento de la información, puesto que los
objetos utilizan su propia información para llevar a cabo las tareas.
Normalmente esto conllevan un bajo acoplamiento, lo que da lugar
a sistemas más robustos y más fáciles de mantener.
 Se distribuye el comportamiento entre las clases que contiene la
información requerida, por tanto, se estimula las definiciones de
clases más cohesivas y “ligeras” que son más fáciles de entender y
mantener. Se soporta normalmente una alta cohesión.
 Patrones relaciones: bajo acoplamiento y alta cohesión.

o Creador: guía la asignación de responsabilidades relacionadas con la creación de

objetos, una tarea muy común. La intención básica del patrón creador, es encontrar
un creador que necesite conectarse al objeto creado en alguna situación.
Eligiéndolo como el creador se favorece el bajo acoplamiento. Algunas veces se
encuentra un creador buscando las clases que tienen los datos de iniciación que se
pasaran durante la creación. Se trata, en realidad, de un ejemplo del patrón experto.
Los datos de inicialización se pasan durante la creación por medio de algún tipo de
método de inicialización.
 Beneficios: se soporta bajo acoplamiento, lo que implica menos
dependencias de mantenimiento y mayores oportunidades para reutilizar.
Probablemente no se incremente el acoplamiento porque la clase creada es
presumible que ya sea visible a la clase creadora, debido a las asociaciones
existentes que motivaron su elección como creador.
 Patrones relacionados: bajo acoplamiento, factoría y todo-parte.

o Bajo acoplamiento: el acoplamiento es una medida de la fuerza con que un

elemento está conectado a otros elementos. Un elemento con bajo acoplamiento no
depende demasiado de otros elementos. Estos elementos pueden ser clases,
subsistemas, sistemas, etc.
Una clase con alto acoplamiento confía en muchas otras clases. Tales clases
podrían no ser deseables; ya que algunas padecen el siguiente problema: no
presentan el concepto de encapsulamiento.
En la práctica, el nivel de acoplamiento no se puede considerar de manera aislada a
otros principios como experto o alta cohesión. Sin embargo, es un factor a tener en
cuenta para mejorar el diseño.
El patrón de bajo acoplamiento es un principio a tener en mente en todas las
decisiones de diseño; es un objetivo subyacente a tener en cuenta continuamente.

Auad, Diego F. & Paez, Pablo E. Página 12

UML y Patrones – Craig Larman 2da. Ed.

Es un principio evaluativo que aplica un diseñador mientras evalúa todas las

decisiones de diseño. Impulsa la asignación de responsabilidades de manera que su
localización no incremente el acoplamiento hasta un nivel que nos lleven a
resultados negativos que puede producir un acoplamiento alto.
 Beneficios: no afectan los cambios en otros componentes; fácil de entender
de manera aislada; conveniente para reutilizar.
 Patrones relacionados: variaciones protegidas.

o Alta cohesión: en cuanto al diseño de objeto, la cohesión es una medida de la fuerza

con la que se relacionan y de grado de focalización de las responsabilidades de un
elemento. Un elemento con responsabilidades altamente relacionadas, y que no
hace una gran cantidad de trabajo, tienen alta cohesión. Estos elementos pueden ser
clases, subsistemas, etc.
Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado
trabajo. Tales clases no son convenientes, ya que padecen dificultades de
entendimiento, de reutilización, mantenimiento, y son muy delicadas, pues
constantemente son afectadas por los cambios.
En la práctica, el nivel de cohesión no se puede considerar de manera aislada a
otras responsabilidades y otros principios como los patrones experto y bajo
acoplamiento.
Al igual que el bajo acoplamiento, el patrón de alta cohesión es un principio a tener
en mente durante todas las decisiones de diseño; es un objetivo subyacente a tener
en cuenta continuamente. Es un principio evaluativo que aplica un diseñador
mientras evalúa todas las decisiones de diseño.
Diferentes grados de cohesión:
 Muy baja cohesión: una única clase es responsable de muchas cosas en
áreas funcionales muy diferentes.
 Baja cohesión: una única clase tiene la responsabilidad de una tarea
compleja en un área funcional.
 Alta cohesión: una clase tiene una responsabilidad moderada en un área
funcional y colabora con otras clases para llevar a cabo las tareas.
 Moderada cohesión: una clase tiene responsabilidades ligeras y únicas
en unas pocas áreas diferentes que están lógicamente relacionadas con
el concepto de la clase, pero no entre ellas.
 Beneficios: se incrementan la claridad y facilitan la comprensión del
diseño; se simplifican el mantenimiento y las mejorar; se soportan a
menudo bajo acoplamiento; el grado fino de funcionalidad altamente
relacionada incrementa la reutilización porque una clase cohesiva se puede
utilizar para un propósito muy específico.

Auad, Diego F. & Paez, Pablo E. Página 13

UML y Patrones – Craig Larman 2da. Ed.

o Controlador: un evento del sistema de entrada es un evento generado por un actor

externo, se asocian con operaciones del sistema, tal como se relacionan los
mensajes y los métodos. Un controlador es un objeto que no pertenece a la interfaz
de usuario, responsables de recibir o manejar un evento del sistema. Un controlador
define el método para la operación del sistema.
Normalmente, un controlador debería delegar en otros objetos el trabajo que se
necesita hacer; coordina o controla la actividad. No realiza mucho trabajo por si
mismo.
El patrón controlador proporciona guías acerca de las opciones generalmente
aceptadas y adecuadas. El controlador es una especie de fachada en la capa del
dominio para la capa de la interfaz. A menudo, es conveniente utilizar la misma
clase controlador para todos los eventos del sistema de un caso de uso, de manera
que es posible mantener la información acerca del estado del caso de uso en el
controlador. Un error típico del diseño de los controladores es otorgarles demasiada
responsabilidad.
 Beneficios: aumenta el potencial para reutilizar y las interfaces
conectables; razonamiento sobre el estado de casos de uso.

Auad, Diego F. & Paez, Pablo E. Página 14