RESUMEN PARCIAL N°1

Diseño de Sistemas de Información 2023

Abril Conrero
RESUMEN PARCIAL N°1 ........................................................................................................................ 0
UML/PUD ............................................................................................................................................. 1
MODELO ........................................................................................................................................... 1
UML .................................................................................................................................................. 1
ELEMENTOS DE UML ........................................................................................................................ 3
ANÁLISIS VS DISEÑO......................................................................................................................... 3
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS.................................................................................... 4
DESARROLLO ITERATIVO E INCREMENTAL ...................................................................................... 4
PROCESO UNIFICADO ....................................................................................................................... 6
OBJETOS Y CLASES............................................................................................................................ 9
WORKFLOWS.................................................................................................................................. 10
MODELO DE REQUERIMIENTOS ..................................................................................................... 11
WORKFLOW DE ANÁLISIS ............................................................................................................... 13
DIAGRAMAS ....................................................................................................................................... 17
DIAGRAMAS EN UML 2.0 ............................................................................................................... 17
DESCRIPCIÓN DE DIAGRAMAS ....................................................................................................... 19
DIAGRAMA DE MÁQUINA DE ESTADOS ......................................................................................... 22
DIAGRAMAS DE INTERACCIÓN....................................................................................................... 26
DIAGRAMAS DE SECUENCIA........................................................................................................... 26
RESPONSABILIDADES Y MÉTODOS................................................................................................. 32
CLASES DEL ANÁLISIS ..................................................................................................................... 34
PATRONES .......................................................................................................................................... 36
PATRÓN .......................................................................................................................................... 36
PATRONES GRASP .......................................................................................................................... 36
EXPERTO EN INFORMACIÓN/EXPERTO .......................................................................................... 37
CREADOR ........................................................................................................................................ 38
BAJO ACOPLAMIENTO.................................................................................................................... 39
ALTA COHESIÓN ............................................................................................................................. 40
CONTROLADOR .............................................................................................................................. 41
PREGUNTAS DE PARCIALES VIEJOS .................................................................................................... 44

UML/PUD
MODELO
 MODELO
 Un modelo es una simplificación de la realidad
 Se construyen para poder comprender mejor el sistema que estamos desarrollando
 OBJETIVO DE MODELAR
 Ayuda a visualizar un sistema cómo es o cómo queremos que sea
 Permiten especificar la estructura y comportamiento de un sistema
 Da una plantilla que nos guía en la construcción del sistema
 Documentan las decisiones que hemos tomado

UML
 Lenguaje aceptado universalmente para planos de diseño de software
 Lenguaje de modelado de propósito general, usado para visualización, especificación,
construcción y documentación de sistemas orientados a objetos.
 Notación visual estándar para el modelado orientado a objetos

A/DOO

Análisis
Notación
de
UML
requisitos

Temas y
habilidades
Desarrollo
Principios
iterativo
y guías
con PU

Patrones

 A/DOO:

Página 1 de 47
 Una habilidad clave y fundamental en esta es la asignación cuidadosa de responsabilidades
a los componentes de software
 Actividad que debe efectuarse e influye fuertemente sobre la robustez, mantenimiento y
reutilización de los componentes de software
 ¿CÓMO TRABAJA UML?
A través de:
 Métodos y notaciones históricas
 Del desarrollo del ciclo de vida del sistema
 De dominios de aplicación
 De lenguajes y plataformas de implementación
 De procesos de desarrollo
 De conceptos internos
 ¿POR QUÉ ES UN LENGUAJE?
 Provee un vocabulario y reglas para combinar los elementos del vocabulario con el propósito
de comunicar
 En un lenguaje de modelado esos vocabularios y reglas se focalizan en representaciones
conceptuales y físicas de un sistema

 REGLAS
 UML tiene un numero de reglas vinculadas a un modelo “bien formado”
 Modelo bien formado: semánticamente autoconsistente y en armonía con sus modelos
relacionados
 UML tiene reglas semánticas para:
o Nombres: cómo llamar a los elementos, relaciones y diagramas
o Alcance: contexto que da un significado especifico al nombre
o Visibilidad: cómo se pueden ver y usar esos elementos por otros
Página 2 de 47
 o Integridad: como se relacionan apropiada y consistentemente unos elementos con
otros
o Ejecución: que significa ejecutar o simular un modelo dinámico
 UML permite también construir modelos que no sean “bien formados” dado que un
software va evolucionando y pueden ser vistos por diferentes involucrados en momentos
distintos
 UML permite también construir modelos:
o Abreviados: ciertos elementos se ocultan para simplificar la vista
o Incompletos: pueden estar ausentes ciertos elementos
o Inconsistentes: no se garantiza la integridad del modelo

ELEMENTOS DE UML
 ELEMENTOS ESTRUCTURALES
 Clases
 Interfaces
 Casos de uso
 Colaboraciones
 Componentes
 Nodos
 Clases activas
 ELEMENTOS COMPORTAMENTALES
 Interacciones
 Actividades
 Máquinas de estado
 ELEMENTOS DE NOTACION
 Notas
 ELEMENTOS DE AGRUPACION
 Paquetes
 Entornos
 Modelos
 Subsistemas

ANÁLISIS VS DISEÑO
 ANÁLISIS
 Pone énfasis en una investigación del problema y los requisitos, en vez de ponerlos en una
solución
 “Hacer lo correcto”
 Asume tecnología interna perfecta
Página 3 de 47
 DISEÑO
 Pone énfasis en una solución conceptual que satisface los requisitos en vez de ponerlo en la
implementación
 Los diseños pueden ser implementados
 “Hacerlo correcto”

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

 ANÁLISIS ORIENTADO A OBJETOS
 Se presta atención en encontrar y describir los objetos o conceptos en el dominio del
problema
 Su finalidad es crear una descripción del dominio desde la perspectiva de clasificación de
objetos
 Identificación de conceptos, atributos y asociaciones que se consideran significativas
 Resultado: puede expresarse en un modelo del dominio que se ilustra mediante un conjunto
de diagramas que muestran los objetos o conceptos del dominio (un modelo de dominio no
es una descripción de los objetos software, es una visualización de los conceptos en el
dominio del mundo real)
 DISEÑO ORIENTADO A OBJETOS
 Se presta atención a la definición de los objetos software y en cómo colaboran para
satisfacer los requisitos
 En última instancia, durante la implementación o programación orientada a objetos, los
objetos de diseño se implementan
 Los casos de uso NO son artefactos orientados a objetos

DESARROLLO ITERATIVO E INCREMENTAL

 ¿QUÉ ES?
 El desarrollo iterativo es un enfoque para el desarrollo de software
 ORGANIZACIÓN
 El desarrollo se organiza en una serie de mini proyectos de duración fija denominados
iteraciones
 ITERACIONES
 El resultado de cada iteración 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
 Iteración: pasada por todos los workflows de ejecución para obtener el incremento de un
producto.

Página 4 de 47
 Al terminar una iteración, se obtiene un incremento del producto
 Incremental porque va sumando versiones anteriores
 El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema
mediante múltiples iteraciones, con retroalimentación cíclica y adaptación para converger
hacia un sistema adecuado
 El sistema crece iteración tras iteración y por ello este enfoque también se conoce como
desarrollo iterativo e incremental
 Resultado de cada iteración:
o Sistema ejecutable pero incompleto, no está preparado para ser puesto en
producción. El sistema podría no estar listo para su puesta en producción hasta
después de muchas iteraciones
o La salida de una iteración NO es un prototipo experimental o desechable, y el
desarrollo iterativo no es prototipado
o La salida es un subconjunto con calidad de producción del sistema final
 Aunque generalmente una iteración aborda nuevos requisitos y amplia el sistema
incrementalmente, ocasionalmente puede que en una iteración se vuelva sobre el mismo
software ya existente y mejorarlo
 Longitud:
o Se recomienda la longitud de dos a seis semanas
o Iteraciones largas destruyen la motivación principal del desarrollo iterativo e
incrementan el riesgo del proyecto
o Una idea calve es que se fije la duración de las iteraciones. Si parece que será difícil
cumplir el plazo fijado, se recomienda eliminar tareas o requisitos e incluirlos en una
iteración posteriori, más que retrasar la fecha prevista

 RETROALIMENTACIÓN Y ADAPTACIÓN
 El desarrollo iterativo se basa en la aceptación del cambio y la adaptación como inevitables
y esenciales
 Cada iteración conlleva la elección de un pequeño conjunto de requisitos y rápidamente
diseñar, implementar y probar
 Rápida retroalimentación de los usuarios, desarrolladores y pruebas
 La retroalimentación temprana aporta un conocimiento práctico y crucial, y la oportunidad
de modificar o adaptar la comprensión de los requisitos o el diseño
 Además de clarificar los requerimientos, actividades como la prueba de carga probaran el
diseño y la implementación parcial están en el camino correcto o si en la siguiente iteración
se necesita un cambio en la arquitectura básica
 El trabajo se desarrolla a lo largo de una serie de ciclos estructurados: construir-
retroalimentar-adaptar
 BENEFICIOS DEL DESARROLLO ITERATIVO

Página 5 de 47
  Mitigación de riesgos altos
 Progreso visible en las primeras etapas
 Gestión de la complejidad (el equipo no se ve abrumado)
 El conocimiento adquirido en una iteración se puede utilizar metódicamente para mejorar
el propio proceso de desarrollo, iteración a iteración
El proceso unificado es un ejemplo de proceso iterativo para proyectos que utilizan el A/DOO

PROCESO UNIFICADO
 ¿QUÉ ES?
 Es un proceso de desarrollo de software (conjunto de actividades necesarias para
transformar los requisitos de un usuario en un sistema software)
 Está basado en componentes
 Utiliza UML para preparar todos los esquemas de un sistema software
 Lo utilizamos como un estructurador, como una ayuda para ir incorporando los artefactos y
saber en qué momento del desarrollo del producto podemos usar uno u otro diagrama
 Es un MARCO de trabajo
 Entorno genérico de proceso que se puede especializar (es decir, que podemos adaptarlo a
las necesidades reales de cada proyecto)
 El espíritu del PU es indicar, de forma genérica cuál es la salida que va a tener cada workflow
 El proceso hace la descripción de lo máximo que se necesita para hacer software, luego
nosotros debemos adaptarlo (necesitamos elegir qué actividades hacemos y cuáles no)
 CARACTERÍSTICAS
 Combina las practicas comúnmente aceptadas como buenas practicas, tales como ciclo de
vida iterativo y desarrollo dirigido por el riesgo, en una descripción consistente y bien
documentada.
 Los aspectos definitorios que hacen único al proceso unificado son:
 Dirigido por casos de uso: se basa en la orientación al usuario, la comunicación clara
de requisitos, la orientación al diseño y prueba, la flexibilidad y adaptabilidad, y la
influencia en la arquitectura del sistema. Utilizar casos de uso como guía ayuda a
garantizar que el software desarrollado cumpla con las necesidades del usuario final
y se alinee con los objetivos del negocio
 Centrado en la arquitectura: Se basa en reconocer la importancia de una arquitectura
sólida y bien diseñada para el éxito del proyecto de desarrollo de software. Al prestar
atención a la arquitectura desde las etapas iniciales del proyecto, se pueden mitigar
riesgos, mejorar la calidad y facilitar la comunicación y la colaboración entre los
miembros del equipo
 Iterativo e incremental
 CONCEPTOS Y BUENAS PRACTICAS

Página 6 de 47
 La idea fundamental para apreciar y utilizar el UP es el desarrollo iterativo, fijando
iteraciones cortas y adaptables
 Se recomienda el uso de las tecnologías de objetos, entre las que se encuentra el A/DOO y
la programación orientada a objetos
 Abordar cuestiones de alto riesgo y muy valiosas en las primeras iteraciones
 Involucrar continuamente a los usuarios para evaluación, retroalimentación y requisitos
 Construir en las primeras iteraciones una arquitectura que constituya un núcleo central
consistente
 Verificar continuamente la calidad
 Aplicar CU
 Modelar software visualmente con UML
 Gestionar los requisitos con cuidado
 Manejar peticiones de cambio y gestión de configuraciones
 FASES
Un proyecto UP organiza el trabajo y las iteraciones en cuatro fases fundamentales:
1. INICIO:
 Visión aproximada, análisis del negocio, alcance, estimaciones imprecisas.
 No es una fase de requisitos, es una fase de viabilidad donde se lleva a cabo el estudio
suficiente para decidir si continuar o no
2. 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.
 No es fase de requisitos o diseño, sino una fase donde se implementa de manera
iterativa la arquitectura que constituye el núcleo central y se mitigan las cuestiones
de alto riesgo
3. CONSTRUCCIÓN:
 Implementación iterativa del resto de requisitos de menor riesgo y elementos más
fáciles, preparación para el despliegue
4. TRANSICIÓN:
 Pruebas beta, despliegue
 CICLO DE DESARROLLO

Página 7 de 47
 Normalmente un ciclo de desarrollo (que termina con el lanzamiento de un sistema a
producción) se compone de muchas iteraciones

 FLUJOS DE TRABAJO
 Requisitos
 Análisis
 Diseño
 Implementación
 Prueba
 Los cinco flujos del trabajo tienen lugar sobre las cuatro fases (inicio, elaboración,
construcción y transición)
 Una iteración típica pasa por los cinco flujos del trabajo

 ARTEFACTOS OPCIONALES
Página 8 de 47
  Algunas prácticas y principios del UP deben seguirse siempre (desarrollo iterativo y dirigido
por el riesgo, verificación continua de la calidad)
 Todas las actividades y artefactos son opcionales
 En un proyecto UP, un equipo debería seleccionar un pequeño subconjunto de artefactos
que sirvan para tratar sus problemas y necesidades particulares
 MARCO DE DESARROLLO
 La elección de los artefactos para un proyecto podría recogerse en un documento
denominado marco de desarrollo.

OBJETOS Y CLASES
Unidad básica del POO: Clase
 QUÉ ES UN OBJETO
 Representa un elemento, unidad o entidad individual e identificable, ya sea real o abstracta,
con un rol bien definido en el dominio del problema
 COMPOSICIÓN DE OBJETOS
Un objeto está compuesto por:
 Estado: valor de los atributos en un momento de
tiempo (tomo el conjunto de atributos y le asigno
un valor). El cambio de estado les permite un Estado Identidad

comportamiento distinto del estado anterior

 Identidad: lo que distingue un objeto de otro, lugar
que ocupa en el tiempo y el espacio (dirección de Comportamiento
memoria donde se aloja). NO depende del valor de
los atributos
 Comportamiento: está especificado en la clase
para definir que hace
 CARACTERÍSTICAS DE LOS OBJETOS
 Los objetos están encapsulados (protege la fracción, oculta lo que hay dentro del objeto).
Por eso el ID no hace a la identidad, no podemos verlo desde afuera. Tiene que venir de
afuera
 Los objetos se crean, se asignan a un lugar de memoria y se los apunta con un puntero. Con
el puntero puedo recuperar el objeto en particular
 Lo que tiene el objeto es identidad, lo cual no se encuentra en la clase
 La clase se usa para definir características y comportamiento común de objetos, es un
CONCEPTO
 REPRESENTACIÓN DE OBJETOS
:nombre de la clase // si no tiene nada antes de : es anónimo, si no es nombrado
Página 9 de 47
 CLASES
 Describe un grupo de objetos que comparten una estructura y un comportamiento comunes
 A veces no es necesario un puntero a una clase estado, pueden ser atributos en la misma
clase (por ej. un préstamo)
 Las clases deben respetar los nombres que nos da el dominio
 Las clases NO tienen estados, los objetos sí.
 ATRIBUTOS
 PROPIOS: Son los que están adentro de la clase
 POR REFERENCIA: Los que relacionan (Estado: estado)
 ENCAPSULAMIENTO
 Permite el ocultamiento de la información (ocultamiento de estado + olcutamiento de
implementación)

WORKFLOWS

 Cada workflow tiene asociado un modelo resultante con un nombre genérico, que coincide
con del workflow.
 El de diseño tiene dos porque distingue entre software (modelo de diseño) y hardware
(modelo de despliegue)
 El workflow de despliegue es el workflow que entrega el producto o la versión producto al
cliente, por lo que ya no hay modelo. Por eso no se incluye en la tabla.
Página 10 de 47
 MODELO DE REQUERIMIENTOS

 WORKFLOW DE REQUISITOS
 El propósito fundamental es guiar el desarrollo hacia el sistema correcto mediante una
descripción de los requisitos del sistema que el sistema debe cumplir
 Debe ser una descripción suficientemente buena como para que pueda llegarse a un acuerdo
entre el cliente y los desarrolladores sobre lo que debe y no debe hacer el sistema
 El cliente debe ser capaz de leer y comprender el resultado de la captura de requisitos, por
lo que debemos utilizar el lenguaje del cliente para describirlos.
 Los resultados del flujo de trabajo de los requisitos también ayudan al jefe de proyecto a
planificar las iteraciones y versiones del cliente
 PASOS
 Enumerar los requisitos candidatos
 Comprender el contexto del sistema
 Capturar requisitos funcionales
 Capturar requisitos no funcionales
La técnica inmediata para identificar requisitos se basa en los CU. Estos capturan tanto requisitos
funcionales como no funcionales que son específicos de cada CU

Página 11 de 47
  PAPEL EN EL CICLO DE VIDA DEL SOFTWARE
El modelo de CU se desarrolla a lo largo de varios incrementos del desarrollo, donde las iteraciones
añadirán nuevos CU o detalle a las descripciones de los CU existentes

 Durante la fase de inicio, los analistas identifican la mayoría de CU

 Durante la de elaboración, los analistas capturan la mayoría de requisitos restantes
 Los requisitos faltantes se capturan e implementan durante la construcción
 Casi no hay captura de requisitos en la transición, a menos que haya requisitos que cambien
 ARTEFACTOS:
 Modelo de CU
 Actor
 Descripción de la arquitectura
 Glosario
 Prototipo de interfaz de usuario
 HERRAMIENTAS ≠ ARTEFACTOS
 Los artefactos los creamos usando las herramientas
 Lo que construyo son modelos o vistas (son los artefactos que voy necesitando a medida que
desarrollo mi software)
 ¿QUÉ UTILIZAMOS DEL MODELO DE REQUERIMIENTOS PARA EL MODELO DE ANÁLISIS?
 Dejamos fuera los requerimientos no
funcionales, porque no tenemos en
cuenta la implementación
 El propósito del workflow del modelo
de análisis es construir y estructurar los
requerimientos funcionales,
independientemente de la tecnología
en la que trabajar, condiciones de
calidad, etc.
 Si son un artefacto que salen del
modelo de requerimientos, debemos
encontrarlos y después decidimos
cuando nos ocupamos de resolverlos
 Primero resolvemos lo funcional y luego lo no funcional
 VISTAS RESULTANTES

Página 12 de 47
 Vista de la estructura: diagrama de clase
 Vista de comportamiento: diagrama de CU (estática)
 Vista de comportamiento: en la máquina de estados (dinámica)

WORKFLOW DE ANÁLISIS
 ENTRADA
 Workflow de requerimientos
 SALIDA
 Artefacto genérico denominado modelo de análisis
 CARACTERÍSTICAS
 Se analizan los requerimientos capturados en el workflow de requerimientos, refinándolos
y estructurándolos
 Sirve como aproximación al diseño (esboza como llevar a cabo la funcionalidad dentro del
sistema, incluida la funcionalidad significativa para la arquitectura)
 No modela aspectos físicos, ya que es conceptual
 Su propósito es resolver los requerimientos analizándolos con mayor profundidad, pero con
la diferencia de que podemos utilizar el lenguaje de los desarrolladores para describir los
resultados (refinar requisitos)
 La estructura de los requisitos que proporciona el análisis sirve también como entrada
fundamental para dar forma al sistema en su totalidad (construir el sistema como un todo
mantenible, no solo describir sus requisitos)
 OBJETIVO:
 Conseguir una comprensión de los requerimientos más precisa y una descripción de los
mismos fácil de mantener y que ayude a estructura el sistema entero (incluyendo su
arquitectura)
 MODELO DE ANÁLISIS
 Ayuda a refinar y estructurar los requisitos (lo que facilita su compresión, preparación,
modificación y mantenimiento)
 Permite razonar sobre aspectos internos del sistema
 Ofrece mayor poder expresivo y formalización (gracias a que se hace en lenguaje de
desarrollador)
 Proporciona una estructura centrada en el mantenimiento, en aspectos tales como la
flexibilidad ante cambios y la reutilización
 Se usa como entrada a las actividades de diseño
 Se debería obtener un sistema mantenible como un todo, flexible ante cambios en los
requisitos e incluir elementos que podrán ser reutilizados al construir sistemas parecidos
 Hace abstracciones y evita algunos problemas que es mejor posponer para el diseño

Página 13 de 47
 Para empezar a diseñar deberíamos contar con una comprensión precisa y detallada de los
requisitos, lo cual conseguimos mediante el análisis
 PAPEL DEL ANÁLISIS EN EL CICLO DE VIDA DEL SOFTWARE
 Las iteraciones iniciales de la elaboración se centran en el análisis
 Al término de la fase de elaboración y durante la construcción, cuando la arquitectura es
estable y se comprenden los requisitos, el énfasis pasa al diseño y la implementación

 CUÁNDO HACER ANÁLISIS/BENEFICIOS

 Mediante la realización separada del análisis podemos analizar sin grandes costos una gran
parte del sistema y podemos usar después el resultado para planificar el trabajo de diseño e
implementación subsiguiente en varios incrementos sucesivos. Sin el análisis, la
identificación y planificación de estos incrementos puede ser mas difícil de realizar
 El análisis proporciona una visión general del sistema que puede ser más difícil de obtener
mediante el estudio de los resultados del diseño y la implementación, debido a que
contienen demasiados detalles. Una visión general como esta puede ser valiosa para
empleados recién incorporados (se los logra formar o capacitar en menos tiempo)
 El modelo de análisis proporciona una vista conceptual, precisa y unificadora de todas las
implementaciones alternativas que pueden existir
 El análisis también es útil cuando se construye un sistema utilizando un sistema heredado
complejo. La reingeniería de este sistema puede hacerse en términos del modelo de análisis
de manera que los desarrolladores pueden comprender el sistema heredado sin tener que
profundizar en detalles de diseño e implementación y construir el nuevo sistema utilizando
el heredado como un bloque de construcción reutilizable.
 VARIANTES DE USO
Podemos:
 No usarlo (se fusiona con el de requerimientos o el de diseño)
 Usarlo: El proyecto utiliza el modelo de análisis y mantiene la consistencia de este modelo
a lo largo de todo el ciclo de vida del software.
 Usarlo y no mantenerlo (al arrancar con el modelo de diseño). Si no lo mantenemos, su
evolución se corta en la fase de elaboración. El proyecto usa el modelo para describir los
resultados del análisis, pero lo considera como una herramienta intermedia y transitoria.
Más adelante, cuando está en marcha el diseño y la implementación en la fase de
construcción, se deja de actualizar el análisis. Cualquier tema de análisis que quede se
Página 14 de 47
 resuelve como parte integrada dentro del trabajo de diseño en el modelo de diseño
resultante.
Para definir entre la segunda y tercera opción, hay que hacer un análisis costo-beneficio y decidir si
conviene dejar de actualizar el modelo de análisis o si debe conservarse y mantenerlo durante el
resto de vida del sistema
En el primer caso, generalmente las ventajas de trabajar con un modelo de análisis al comienzo del
proyecto superan a los costos de emplearlo, por lo tanto, solo debería emplearse para casos
excesivamente simples.
 ARTEFACTOS DEL MODELO DE ANÁLISIS
1. REALIZACIONES DE CU DE ANÁLISIS:
 Más importante
 Es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo
y se ejecuta un CU determinado en términos de las clases de análisis y sus objetos
del análisis en interacción
 Proporciona una traza directa hacia un CU concreto del modelo de CU
 Posee una descripción textual del flujo de sucesos de diagramas de clases y
diagramas de interacción
 Se centra en requerimientos funcionales
 Usa diagrama de clases para la parte estática y diagrama de secuencia, comunicación
o de descripción de interacción para la dinámica.
2. CLASES DE ANÁLISIS (LINK)

3. PAQUETES DE ANÁLISIS
 Ayudan a la organización
 Son agrupamientos de subsistemas porque a lo mejor el sistema nos quedó muy
grande
 No modelamos, organizamos
 Un paquete puede contener clases de análisis, de realizaciones de CU y de otros
paquetes del análisis.
 En algunas vistas el paquete puede ser una caja negra y en otras no, depende de lo
que necesitemos
 Para determinar que colocamos dentro de un paquete tenemos que considerar la
cohesión y el acoplamiento (lo que esté dentro del paquete debe estar altamente
vinculado y el vínculo o dependencia entre paquetes debe ser lo más bajo posible)
 No podría poner dentro de un mismo paquete clases y CU. Si tengo que dividir clases
en paquetes, veo cuáles se relacionan más.
4. VISTA ARQUITECTÓNICA DEL ANÁLISIS
 Todos los modelos tienen sus vistas arquitectónicas
 Una vista es una proyección del sistema desde una perspectiva en particular, se usa
para manejar la complejidad en UML, ya que oculta ciertos aspectos
Página 15 de 47
  Muestra artefactos significativos para la arquitectura
 Puedo crear vistas con cada diagrama (vistas de CU, vistas de clases, etc.)
 Eligen mostrar aspectos significativos para la arquitectura
 Es una abstracción de lo anterior, elijo lo más relevante y lo muestro
 Son pequeñas, solo destacan lo que condiciona la arquitectura (ej. Tomo clases que
son significativas y las coloco en la vista, tomo las realizaciones más significativas y
las coloco en una vista).
 Es una porción de lo que más importa
 DIAGRAMAS DE UML QUE SE USAN EN EL ANÁLISIS
Para obtener los artefactos anteriores necesito de:
1. Diagrama de secuencia
2. Diagrama de comunicación
3. Diagrama de timming
4. Diagrama de descripción de interacción
5. Diagrama de máquina de estados
6. Diagrama de clases
7. Diagrama de paquetes
8. Diagrama de objetos
9. Diagrama de actividad

Página 16 de 47
 MODELO DE REQUERIMIENTOS VS DE ANÁLISIS

DIAGRAMAS
DIAGRAMAS EN UML 2.0
 Los diagramas son herramientas que usamos para construir modelos
 En UML 2.0 hay un total de 13 diagramas

 CLASIFICACIÓN DE DIAGRAMAS
 Primer gran clasificación es según la estructura (modelan comportamiento o estructura)

Página 17 de 47
 Segunda clasificación refiere al ámbito de modelado (clases u objetos)
1. MODELAN ESTRUCTURA (6, son todos estáticos)
Modelan clases
 De clases
 Para modelar dominio
 Para crear vistas de análisis
 Para crear vistas en el diseño
 De paquetes
 Se usa para organizar, no para modelar
 De estructura compuesta
 De componentes
 Para armar vistas arquitectónicas
 De despliegue
 Para armar vistas arquitectónicas
Modelan objetos
 De objetos

1. MODELAN COMPORTAMIENTO (7, son todos dinámicos menos los CU)

Modelan clases
 De casos de uso
 Excepción, es el único diagrama de comportamiento que es estático. El resto
son todos dinámicos (el tiempo se ve reflejado de alguna forma en el modelo)
 Un caso de uso es una descripción de comportamiento, es un tipo especial de
clase. Se instancia en escenarios. El actor también puede considerarse un tipo
especial de clase
 De actividad
 De máquina de estados
2. De interacción (modelan objetos) //se agrega en la versión 2.0, se agrupan diagramas con
modelados y características en común. Es una CLASIFICACION no es un diagrama.
 De comunicación
 De secuencia
 De timing
 De descripción e iteración

Página 18 de 47
 DESCRIPCIÓN DE DIAGRAMAS
GRANDES CLASIFICACIONES:
 DIAGRAMAS DE COMPORTAMIENTO
 Muestra aspectos de comportamiento de un sistema
 DIAGRAMAS DE INTERACCIÓN
 Subtipo de los de comportamiento que enfatiza la interacción entre objetos
 Tipo especial de diagrama de comportamiento, son todos a nivel de objeto, dinámicos y
lógicos.
 DIAGRAMAS DE ESTRUCTURA
 Muestra elementos de especificación, independientes del tiempo
CLASIFICACIONES MÁS PEQUEÑAS:
 DIAGRAMA DE CLASES
 Clasificación: de estructura, lógico y estático
 Muestra un conjunto de clases, interfaces y colaboraciones y sus relaciones
 Usos:
o Explicar conceptos del dominio
o Analizar requerimientos
o Mostrar el diseño detallado de software orientado a objetos.
 Contiene: clases, interfaces, relaciones
 Modela:
o Clases
o Atributos
o Métodos
o Relaciones
 DIAGRAMA DE COMPONENTES
 Clasificación: de estructura, estático, físico
 Uso: mostrar la definición, estructura interna y dependencia de tipos de componentes
 Muestra un conjunto de componentes y sus relaciones
 Contiene: componentes, relaciones, interfaces
representa la encapsulación de una clase, junto con sus interfaces, puertos y estructura interna, la
cual está formada por otros componentes anidados y conectores. Cubren la vista de
implementación estática del diseño de un sistema.
 DIAGRAMA DE DESPLIGUE

Página 19 de 47
  Clasificación: de estructura, estático, físico
 Uso:
o Examinar dependencias que tiene el sistema con otros del ambiente de producción
o Examinar aspectos involucrados en la instalación del sistema en producción
o Describir la configuración principal de una aplicación
o Diseñar la configuración de hardware y software en un sistema embebido
o Describir la infraestructura de hardware y redes
 Muestra un conjunto de nodos y sus relaciones
 Contiene: nodos, relaciones de asociación y/o dependencia

 DIAGRAMA DE ESTRUCTURA COMPUESTA

 Clasificación: de estructura, estático, lógico
 Uso:
o Examinar la estructura interna de un clasificador, incluyendo sus puntos de
interacción con otras partes del sistema
 Muestra la estructura interna de una clasificación o colaboración estructurada
 Contiene: conectores, interfaces, partes, puertos, roles.
 DIAGRAMA DE PAQUETES:
 Clasificación: De estructura, estático y lógico.
 Muestra un conjunto de paquetes y sus relaciones.
 Usos:
o descripción a alto nivel de requerimientos
o descripción a alto nivel del diseño
o modularizar diagramas complejos
o organizar código
 No modela, organiza
 DIAGRAMA DE OBJETOS
 Clasificación: de estructura, estático y lógico
 Uso:
o Representar el estado de un sistema en un momento de tiempo.
o Muestra un conjunto de objetos y sus relaciones
 Contiene comúnmente objetos y conexiones (links)
 Sirve para instanciar un diagrama de clases (donde se use el diagrama de clases, también se
usa el de objetos)
//de comportamiento
//modelan clases
 DIAGRAMA DE CASOS DE USO

Página 20 de 47
 Clasificación: de comportamiento, estático y lógico
 Uso:
o Comunicar el alcance
o Proveer descripción de todo o una parte de los requerimientos de un sistema u
organización.
o Muestra un conjunto de CU, actores y sus relaciones
 Contiene: CU, actores, relaciones (extensión, inclusión, generalización, dependencia),
paquetes
 DIAGRAMA DE ACTIVIDAD
 Clasificación: de comportamiento, dinámico, lógico
 Uso: mostrar una operación compleja, una regla de negocio compleja, un CU, algunos CU,
un proceso de negocio, procesos de software
 Muestra el conjunto de actividades y el flujo de secuencia o desglose de actividad en
actividad y los objetos que actúan y que son afectados
 Contiene: nodos, flujos, objetos
 DIAGRAMA DE MAQUINA DE ESTADOS (LINK PARA AMPLIAR)
//de interacción (modelan objetos)
 DIAGRAMA DE COMUNICACIÓN:
 Clasificación: de comportamiento, dinámico, lógico
 Uso:
o Proveer una vista de la colaboración de objetos en un ambiente de tiempo real
o Distribuir funcionalidad en las clases, explorando los aspectos comportamentales de
un sistema
o Modelar la implementación lógica de una operación compleja, particularmente la
que interactúa con muchos objetos.
 Contiene: objetos, links, mensajes
 DIAGRAMA DE SECUENCIA (LINK PARA AMPLIAR)
 Clasificación: de comportamiento, dinámico, lógico
 Uso: validar y describir la lógica de un escenario, explorar el diseño controlando la invocación
de las operaciones definidas en las clases, detectar cuellos de botella en un diseño orientado
a objetos, analizar qué clases son complejas en el sistema
 Enfatiza el orden de los mensajes en función del tiempo.
 Muestra un conjunto de objetos y los mensajes enviados y recibidos por estos objetos
 Contiene: objetos, links, mensaje.
 DIAGRAMA DE DESCRIPCIÓN DE INTERACCIÓN
 Clasificación: de comportamiento, lógico, dinámico
 Uso:

Página 21 de 47
 o variación del diagrama de actividad con descripción de flujos de control,
o conectar una colección de diagramas detallados para unirlos
o Describe el flujo de control de un sistema o proceso de negocio. Cada nodo/actividad
en el diagrama puede representar otro diagrama de interacción
 Contiene:
o elementos del diagrama de actividad,
o ocurrencias de interacción,
o elementos de interacción
 “engancha” escenarios
 DIAGRAMA DE TIMING
 Clasificación: de comportamiento, dinámico, lógico
 Uso: forma alternativa de mostrar un diagrama de secuencia que muestra explícitamente
cambios de estado en una línea de vida y métricas de tiempo
 Útil para aplicaciones en tiempo real
 Muestra cambios de estado o condiciones de uno o más elementos a través del tiempo
 Muestra la interacción entre eventos dependientes del tiempo y las restricciones de tiempo
y duración que los gobiernan
 Contiene: objetos (línea de vida), estados, cambios de estado, unidades de tiempo
 Permite ver que provoca en otras clases el cambio de estado de una (en el diagrama de
máquina de estados no podemos ver esto)
 DIAGRAMAS ESTÁTICOS VS DINÁMICOS
 Estático:
o No se muestra el paso del tiempo en el diagrama.
o NO es que el modelo no vaya a cambiar, solo no lo refleja.
o No reflejan la evolución del paso del tiempo.
 Dinámico:
o Si reflejan el paso del tiempo
o El cambio del tiempo puede mostrarse como paso de mensajes, cambio de estados,
con como impactan cambios de estados en objetos de otra clase (depende del
modelo)

DIAGRAMA DE MÁQUINA DE ESTADOS

 USO:
 Explorar el comportamiento de una clase, actor, subsistema o componente
 Modelar sistemas de tiempo real
 HERRAMIENTA:
 Diagrama de máquina de estados
 ARTEFACTO:
Página 22 de 47
 Máquina de estados de cierta clase
 CLASIFICACION:
 De comportamiento
 Dinámico (refleja el paso del tiempo mediante las transiciones)
 Lógico: lo que modelamos con DME son conceptos, no modelamos elementos de existencia
física (11 de los 13 diagramas de UML son lógicos, menos el de despliegue y el diagrama de
componentes, son físicos, representan elementos físicos)
 CONTIENE:
 Estados
 Transiciones
 Eventos
 ELEMENTOS PARA MODELAR:
 Pseudoestado:
o estado falso que indica alguna información respecto del estado que tiene asociado.
o Las máquinas de estado deben tener por lo menos un estado final y por lo menos
uno final. La situación más frecuente es que haya un estado inicial y dos o más
estados finales
 Condiciones de control o de guarda:
o Se utilizan cuando es necesario aclarar alguna información relacionada a una
transición
 Relaciones de generalización:
o Siempre tienen la misma multiplicidad, por eso no lo colocamos, ya se sobreentiende
 CARACTERÍSTICAS
 Muestra todos los estados posibles y las transiciones permitidas
 Ayuda a modelar reglas de negocio
 Las clases que interesa analizar en este diagrama son aquellas cuyos objetos se comportan
de manera diferente de acuerdo al estado en el que están
 Cuando el estado de los objetos condiciona la ejecución de ciertos comportamientos es
cuando nos interesa modelar
 Sobre la transición indicamos método que da lugar a la transición y el caso de uso
 Al constructor de las clases concretas le llamamos new ()
 La máquina de estados se la hacemos a una clase
 CONSIDERACIONES:
 ¿Todas las clases en un modelo de dominio van a necesitar una máquina de estados?
o NO, yo tengo un modelo de dominio y solo ALGUNAS clases van a necesitarla (las que
se comportan diferente de acuerdo al estado en el que están). Son las clases que

Página 23 de 47
 tienen asociada la clase estado. Un ejemplo que pueden necesitarla serían los
alumnos
o Las transacciones generalmente la necesitan
o Puede haber objetos que tengan atributos propios, como por ejemplo las fechas, que
de acuerdo al valor que tomen las fechas definen el estado del objeto y no hace falta
un atributo estado.
o El atributo estado se agrega en la estructura de la clase cuando no hay atributos
propios suficientes para reflejar todos los estados que quiero reflejar
 CONSIDERACIONES A LA HORA DE MODELAR MAQUINAS DE ESTADO
 En esta máquina modelamos reglas de negocio (condicionante de una determinada manera
en la que tiene que funcionar el negocio, es una restricción a requerimientos funcionales).
 Regla de negocio= funcionamiento
 Algunas reglas de negocio nos van a servir para modelar y otras no.
 Si no respeto las reglas, mi software no le va a servir al cliente
 Respetar siempre los nombres de los estados ya escritos
 Cuando el objeto llega a su estado final NO se mueve más
 El diagrama de máquina de estados modela a nivel de clase porque tengo que graficar todos
los estados posibles y transiciones permitidas para todos los objetos de la clase, lo que no
significa que cada objeto de la clase va a pasar por todos los estados. Representa la lógica
permitida para todos los objetos de la clase, luego cada objeto particular asume su ciclo de
vida correspondiente
 HISTORIA/MEMORIA
 El estado suspendido se tiene que acordar del estado anterior, de donde vino,
cual fue la transición que hizo que llegara ese objeto al estado suspendido
para que cuando lo restaure sepamos a donde lo vamos a reponer
 Cuando esto sucede utilizamos el Pseudoestado de historia

Página 24 de 47
 ESTADOS COMPUESTOS
 Queremos saber más de la caja negra que es el estado
 Estado que tiene estados internos (tiene una máquina de
estados dentro)
 Se indica con el símbolo de infinito
 Las transiciones a los Pseudoestado no tienen nada, solo indican
 Si los estados internos son suspendibles
(tienen memoria) el estado va a tener una
transición hacia la h
 Entramos por la transición que permite
cambiar al estado compuesto y salimos por
la misma que sale del estado compuesto

 EXITPOINT
 Si algún estado interno no cumple con cierta regla (por ejemplo, uno de ellos no es
cancelable) podemos usar un exit-point
 Pseudoestado que permite realizar una salida anticipada del estado
compuesto
 Su transición debe ir hacia el estado en que vamos a salir

Página 25 de 47
 El exitpoint va hacia cancelada
porque indica a qué estado
vamos a salir
En este caso se indica con el
exitpoint todos los estados que
pueden cancelarse (todos
menos el despliegue)

DIAGRAMAS DE INTERACCIÓN
 El lenguaje utilizado para ilustrar los diseños, es principalmente, los diagramas de interacción
 Se debería dedicar tiempo y esfuerzo no trivial a la creación de diagramas de interacción. El
diseño que se represente en los diagramas será imperfecto y especulativo, y se modificará
durante la programación, pero proporcionara un punto de partida serio, consistente y
común, que sirve de inspiración durante la programación

DIAGRAMAS DE SECUENCIA
 CLASIFICACIÓN
 Modela comportamiento, de interacción (modela objetos) DINÁMICO

Página 26 de 47
 Muestran claramente la secuencia de mensajes.

 ¿QUÉ ES?
 Es un artefacto creado de manera rápida que muestra los eventos de entrada y salida
relacionados con el sistema que se está estudiando
 UML incluye la notación de los diagramas de secuencia para representar los eventos que
parten de los actores externos hacia el sistema
 Es un dibujo que muestra, para un escenario especifico de un CU, 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
 Debería hacerse un DSS para el escenario principal de éxito del CU y los escenarios
alternativos complejos o frecuentes
 También pueden utilizarse para ilustrar colaboraciones entre sistemas
 Simula la ejecución de un sistema
 Entra en juego a variable tiempo
 COMPORTAMIENTO DEL SISTEMA
 El comportamiento del sistema es una descripción de qué hace el sistema, sin explicar cómo
lo hace
 Una parte de esta descripción es un diagrama de secuencia del sistema (otras partes
comprenden los CU y los contratos del sistema)
 DIAGRAMAS DE SECUENCIA DEL SISTEMA
 Los CU describen cómo interactúan los actores externos con el sistema software que
estamos interesados en crear. Durante esta interacción, un actor genera eventos sobre un
sistema, normalmente solicitando alguna operación como respuesta
 Es deseable aislar e ilustrar las operaciones que un actor externo solicita a un sistema,
porque constituyen una parte importante de la comprensión del comportamiento del
sistema
 UML incluye los diagramas de secuencia como notación que puede representar las
interacciones de los actores y las operaciones que inician
 MENSAJES
 Los mensajes son invocaciones a métodos de la clase que pertenecen a la clase en la que se
encuentra el objeto
Página 27 de 47
 Nosotros vamos a modelar invocaciones de mensajes, no respuestas
 Hay dos tipos:
o Sincrónicos: el objeto se queda esperando la respuesta
o Asincrónicos
 EJEMPLO
 Un DSS muestra, para un curso de eventos especifico en un CU, los actores EXTERNOS que
interaccionan DIRECTAMENTE con el sistema el sistema (como una caja negra) y los eventos
del sistema que genera el actor
 El tiempo avanza hacia abajo, y la ordenación de los eventos debería seguir su orden en el
CU

Forma gráfica de
representar objetos

 DSS Y LOS CASOS DE USO

 Un DSS muestra los eventos del sistema para un escenario de un caso de uso, por tanto, se
genera para el estudio de un caso de uso

Página 28 de 47
 EVENTOS DEL SISTEMA Y LIMITES DEL SISTEMA
 Para identificar los eventos del sistema, es necesario tener claro los límites del sistema
 El límite del sistema normalmente se elige para que sea el propio sistema software, en este
contexto, un evento del sistema es un evento externo que lanza un estímulo directamente
al software

 ASIGNAR NOMBRES A LOS EVENTOS Y OPERACIONES

 Los eventos y operaciones del sistema deberían expresar al nivel de intenciones en lugar de
en términos del medio de entrada fisco o a nivel de elementos de la interfaz de usuario
Página 29 de 47
 Se mejora la claridad al comenzar el nombre de un evento del sistema con un verbo puesto
que resalta la orientación de orden de estos eventos

(introducirArticulo es mejor que

escanear, ya que se captura la
intención de la operación y
permanece abstracta respecto a
las elecciones de diseño sobre qué
interfaz utilizar para capturar el
evento del sistema)

 MOSTRAR EL TEXTO DEL CU

 A veces es deseable mostrar al menos fragmentos del texto de CU del escenario, con el fin
de aclarar.
 El texto proporciona los detalles y e contexto, el diagrama resume visualmente la interacción
 DSS Y EL GLOSARIO
 Los términos representados en los DSS podrían necesitar una explicación más adecuada
 Si no se explicó en los CU podría utilizarse un glosario
 Con los datos del glosario debería hacerse algún uso o decisión realmente significativa, de lo
contrario es innecesario
 DSS EN EL UP
 Los DSS forman parte del modelo de casos de uso
 Son un ejemplo de los muchos posibles artefactos o actividades de análisis y diseño de
utilidad que los documentos UP o RUP no mencionan
 LOS DSS EN LAS FASES
1. Inicio:
 Los DSS normalmente no se incentivan en la fase de inicio
2. Elaboración:
 La mayoría de DSS se crean durante la elaboración, cuando es útil identificar los
detalles de los eventos del sistema para poner en claro cuáles son las operaciones
que se deben diseñar que gestione el sistema, escribir los contratos de las
operaciones del sistema y posiblemente dar soporte a la estimación
 No es necesario crear DSS por todos los CU, sino solo aquellos escenarios
seleccionados de la iteración actual

Página 30 de 47
Página 31 de 47
 RESPONSABILIDADES Y MÉTODOS
 INTRODUCCIÓN
 Después de la identificación de requisitos y la creación de un modelo del dominio, hay que
añadir métodos a las clases del software, y definir el paso de mensajes entre objetos para
satisfacer los requisitos
 Existen profundos principios y cuestiones involucrados en estas etapas. La decisión de qué
métodos, dónde colocarlos y cómo deberían interactuar los objetos es muy importante.
 RESPONSABILIDADES Y MÉTODOS
 Responsabilidad ≠Método
o Los métodos se implementan para llevar a cabo las responsabilidades
o Las responsabilidades se implementan utilizando métodos que o actúan solos o
colaboran con otros métodos u objetos (ej. La clase venta podría definir uno o más
métodos para conocer su total, digamos un método getTotal. Para realizar la
responsabilidad la venta podría colaborar con otros objetos, por ejemplo, enviando
el mensaje getSubtotal a cada objeto de LineaDeVenta solicitando su subtotal)
Otro ej. De colaboración: Si tenemos un sistema de gestión de venta de pasajes de
colectivo, podríamos tener 4 clases:
 Reserva
 Colectivo
 Asiento
 Cliente
Si un cliente decide adquirir boletos, creará una instancia de una reserva. La clase
reserva deberá interactuar con la clase colectivo que a su vez interactuará con asiento
para verificar la disponibilidad y el estado de los mismos y poder mostrar información
al cliente, permitiéndole seleccionar uno o varios asientos.
 RESPONSABILIDAD
 UML la define como “contrato u obligación de un clasificador”
 Lo más importante que tiene una clase
 Las responsabilidades se asignan a las clases de los objetos durante el diseño de objetos (ej.
Una venta es responsable de la creación de una LineaDeVenta o una venta es responsable
de conocer su total)
 Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su
comportamiento. Básicamente, estas responsabilidades son de los siguientes tipos:
o CONOCER (a menudo pueden inferirse a partir del modelo del dominio, debido a los
atributos y asociaciones que describe, relacionado al estado del objeto)
 conocer los datos privados encapsulados
 conocer los objetos relacionados (a través de punteros, que permite tener
visibilidad a otra clase)
 conocer las cosas que puede derivar o calcular
Página 32 de 47
  EJEMPLO: Imaginemos una clase llamada 'Entrenamiento' que tiene dos
atributos: 'horaInicio' y 'horaFin'. La responsabilidad de la clase
'Entrenamiento' es conocer ambas horas (los recupera mediante un get()) y,
por lo tanto, calcular la duración total del entrenamiento realizando la
diferencia entre 'horaFin' y 'horaInicio'. De esta manera, el 'Entrenamiento'
es responsable de proporcionar la duración exacta del entrenamiento.
Además, el 'Entrenamiento' está relacionado con la clase 'TipoActividad' a
través de un puntero, lo que le permite conocer en todo momento el tipo de
actividad al que pertenece. Esto proporciona visibilidad al 'Entrenamiento' sobre la
información relevante del 'TipoActividad' al que está asociado."

o HACER
 hacer algo él mismo, como crear un objeto o hacer un cálculo (un método
puede invocarse a sí mismo, por ejemplo, setEstado)
 iniciar una acción en otros objetos (para que un objeto haga algo otro se lo
tiene que pedir. Las responsabilidades en los objetos aparecen de a pares. El
objeto emisor tiene un método que invoca un método en otra clase)
 controlar y coordinar actividades en otros objetos (los gestores
fundamentalmente tienen esta responsabilidad)
o
 RESPONSABILIDADES Y MÉTODOS EN LOS DIAGRAMAS DE INTERACCIÓN
 La decisión acerca de la asignación de responsabilidades a menudo tiene lugar durante la
creación de diagramas de interacción y con seguridad durante la programación.
 La asignación habilidosa de responsabilidades es muy importante en el diseño de objetos
 Los diagramas de interacción muestran elecciones en la asignación de responsabilidades a
los objetos

Página 33 de 47
 Los patrones GRASP describen los principios fundamentales para guiar las elecciones sobre
donde asignar responsabilidades. Estas elecciones se reflejan en los diagramas de
interacción

CLASES DEL ANÁLISIS

 CARACTERÍSTICAS
 Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del
diseño del sistema
 Se centran en el tratamiento de los requisitos funcionales y pospone los no funcionales hasta
llegar a las actividades de diseño e implementación.
 Su comportamiento se define mediante responsabilidades en nivel alto y menos formal
 Definen atributos de nivel bastante alto
 Las clases de fabricación pura se relacionan entre sí con dependencia
 TIPOS
 Clases de entidad
 Clases frontera
Clases de fabricación pura
 Clases de control
 CLASES DE ENTIDAD:
 Clase que identificamos en el modelo de dominio del problema
 Se utilizan para modelar información que posee una vida larga y es a
menudo persistente
 Contribuyen a entender qué información depende del sistema
 Representan conceptos del negocio que nos interesan representar en el software a construir
Página 34 de 47
 objetos software del dominio independiente de la aplicación (y normalmente persistentes)
 Modelan información que podría ser persistente y sobrevive a una ejecución del sistema
 Normalmente no es particular de una realización de CU. Suele tener vida larga y participa en
varias realizaciones antes de su destrucción.
 CLASE LÍMITE O FRONTERA (BOUNDARY):
 Su propósito es vincular nuestro sistema con el ambiente/actores (implica
generalmente recibir y presentar información y peticiones de y hacia los
usuarios y sistemas externos)
 Dependiendo de la categoría del actor vamos a necesitar determinado tipo de clases limite
 abstracciones de las interfaces
 Modela el comportamiento e información que es dependiente de la frontera del sistema con
el ambiente
 Modela todo lo que concierne a cualquier vínculo sistema-actor
 Categoría de actores:
o Persona
o Software
o Hardware
 Algunos atributos: labels, calender, combos,
 La pantalla siempre toma y pasa, no se queda con nada
 A menudo se crean y finalizan dentro de una sola realización de caso de uso
 CLASE DE CONTROL:
 Hace de intermediario entre clases de entidad y boundary
 Representan coordinación, secuencia, transacciones y control de otros objetos
y se usan frecuentemente para encapsular el control de un CU concreto
 los manejadores de los CU tal y como se describen en el patrón controlador.
 Es el responsable de controlar que las cosas en un CU se ejecuten en la forma descripta en
el escenario (secuenciamiento)
 Manejan lógica de negocio complejas (cosas que no puedo atribuir a una sola clase de
entidad porque no alcanza) definida en un CU
 En el gestor no hacen falta labels, si no los datos que pasaran a ser atributos (todo lo que el
gestor guarda)
 Modela funcionalidad que operar sobre varios objetos diferentes de entidad, haciendo
cálculos y retornando el resultado al objeto de boundary
 Tiene responsabilidades de coordinación de la ejecución de un CU
 Suelen encapsular el control asociado con un CU concreto, lo que implica que debería
crearse un objeto de control cuando el CU comienza y ese objeto debería destruirse cuando
el CU termina. Sin embargo, hay excepciones:
o Cuando un objeto de control participa en más de una realización de CU
o Cuando varios objetos de control participan en una misma realización de CU

Página 35 de 47
 o Cuando una realización no requiere ningún objeto de control.

PATRONES
PATRÓN
 ¿QUÉ ES?
 Es un par problema/solución con nombre que se puede aplicar en nuevos contextos, con
consejos acerca de cómo aplicarlo en nuevas situaciones y discusiones sobre sus
compromisos
 Solución probada a un problema
 Es una descripción de un problema y su solución, a la que se da un nombre y que se puede
aplicar a nuevos contextos
 Proporciona consejos sobre el modo de aplicarlo en varias circunstancias y considera los
puntos fuertes y compromisos
 Tiene la intención de sugerir algo repetitivo
 Lo importante de los patrones no es expresar nuevas ideas de diseño, si no que pretenden
codificar conocimiento y principios ya existentes y que se han probado que son válidos
(cuanto más trillados y extendidos mejor)
 COMPONENTES:
 Nombre: debe ser sugerente, aporta ventajas tales como: apoyar la identificación e
incorporación de ese concepto en nuestro conocimiento y memoria, facilitar la
comunicación
 Descripción del problema a resolver
 Descripción de la solución propuesta
 Se recomienda un alias
 Consecuencias de usarlo (no siempre son positivas)
 Ejemplos de uso (para que sea un patrón al menos debe poder aplicarse en 3 casos distintos)

PATRONES GRASP
 ¿QUÉ SON?
 Describen los principios fundamentales del diseño de objetos y la asignación de
responsabilidades, expresados como patrones
 Proporcionan guías sobre el modo en el que deberían asignarse las responsabilidades a los
objetos, dada una categoría especifica del problema
 Ayudan a entender el diseño de objetos esencial y aplica el razonamiento para el diseño de
una forma sistemática, racional y explicable
 Es importante entender y ser capaces de aplicar estos principios durante la creación de los
diagramas de interacción porque constituyen la base de cómo se diseñará el sistema

Página 36 de 47
 GRASP: Acrónimo de General Responsability Assigment Software Patterns (patrones
generales de software para asignar responsabilidades)
 ¿CUÁLES SON?
 Experto en información
 Creador
 Alta Cohesión
 Bajo acoplamiento
 Controlador

EXPERTO EN INFORMACIÓN/EXPERTO
 SOLUCIÓN:
 Asignar una responsabilidad al experto en información (la clase que contiene la información
necesaria para realizar la responsabilidad)
 PROBLEMA:
 ¿Cuál es un principio para asignar responsabilidades a los objetos?
 Especificar donde asignar un determinado conocimiento
 CARACTERÍSTICAS:
 Se utiliza frecuentemente en la asignación de responsabilidades
 Es un principio de guía básico que se utiliza continuamente en el diseño de objetos
 Expresa la “intuición” común de que los objetos hacen las cosas relacionadas con la
información que tienen
 El cumplimiento de la responsabilidad a menudo requiere información que se encuentra
dispersa por diferentes clases de objetos. Esto implica que hay muchos expertos en
información “parcial” que colaboraran en la tarea (puede que la información se encuentre
esparcida por objetos diferentes, por lo que necesitaran interactuar mediante el paso de
mensajes para compartir el trabajo)
 Recomienda ubicar el comportamiento lo más cerca posible de la información
 “lo hace quien conoce”
 CONTRAINDICACIONES:
 En algunos casos, la solución que sugiere el experto no es deseable, normalmente debido a
problemas de acoplamiento y cohesión
 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 conlleva un bajo acoplamiento
lo que da lugar a sistemas más robustos y más fáciles de mantener

Página 37 de 47
 Se distribuye el comportamiento entre las clases que contienen 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 y un bajo acoplamiento
 EJEMPLO
Si tenemos un sistema de entrenamientos en el cual la clase entrenamiento es quien posee su
hora y fecha de inicio y fin y queremos saber su duración, el responsable de calcularla será el
Entrenamiento ya que es quien posee los datos para realizar el cálculo. Sería erróneo, por
ejemplo, asignarle la responsabilidad al gestor.

CREADOR
 SOLUCIÓN:
Asignar a la clase B la responsabilidad de crear una instancia de clase A si se cumple uno o
más de los casos siguientes:
o B agrega objetos de A
o B contiene objetos de A
o B registra instancias de objetos de A
o B utiliza más estrechamente objetos de A
o B tiene los datos de inicialización que se pasarán de un objeto de A cuando sea creado
(por tanto, B es un experto con respecto a la creación de A)
 PROBLEMA:
¿Quién debería ser responsable de la creación de una nueva instancia de alguna clase?
 CARACTERÍSTICAS:
 Guía la asignación de responsabilidades relacionadas con la creación de objetos.
 Tipo especial de patrón experto
 No nos referimos al constructor (crear objetos de otra clase). Cada clase concreta tiene su
new, lo que discute el patrón es quien lo invoca
 Si no creamos objetos, no lo usamos
 Su intención básica es encontrar un creador que necesite conectarse al objeto creado en
alguna situación
 Favorece el bajo acoplamiento
 Sugiere que la clase contenedor o registro es una buena candidata para asignarle la
responsabilidad de crear lo que contiene o registra
 BENEFICIOS:
 Se soporta bajo acoplamiento lo que implica menos dependencias de mantenimiento y
mayores oportunidades para reutilizar.

Página 38 de 47
 Probablemente no se incrementa 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.

BAJO ACOPLAMIENTO
 ACOPLAMIENTO
 El acoplamiento es una medida de la fuerza con que un elemento está conectado a, tiene
conocimiento de, confía en, otros elementos.
 Grado de interrelación entre clases
 Medida de relacionamiento eterna
 Un elemento con bajo o débil acoplamiento no depende de demasiados otros elementos
(mejor localización de defectos, los cambios afectan a la menor cantidad de clases posibles)
 Una clase con alto o fuerte acoplamiento confía en muchas otras clases. Esto podría no ser
deseable:
o Los cambios en las clases relacionadas fueran cambios locales
o Son difíciles de entender de manera aislada
o Son difíciles de reutilizar puesto que su uso requiere la presencia adicional de las
clases de las que depende
 No existe una medida absoluta de cuando el acoplamiento es demasiado alto
 En general, las clases que son inherentemente muy genéricas y con alta probabilidad de
reutilización, debería tener un acoplamiento especialmente bajo
 El caso extremo de bajo acoplamiento es cuando no existe acoplamiento. No es deseable
porque producirá un diseño pobre que dará lugar a unos pocos objetos inconexos, saturados
y con actividad compleja que hacen todo el trabajo, con muchos objetos muy pasivos, sin
acoplamiento que actúan como simples repositorios de datos
 El alto acoplamiento en sí no es un problema, si lo es el alto acoplamiento entre elementos
que no son estables en alguna dimensión. Si nos esforzamos en disminuir el acoplamiento
en algunos puntos donde de hecho no hay motivos realistas, el tiempo se está
desperdiciando
 SOLUCIÓN:
Asignar una responsabilidad de manera que el acoplamiento permanezca bajo
 PROBLEMA:
¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización?
 BENEFICIOS:
Disminuir el acoplamiento permite:
o No afectar los cambios en otros componentes
o Entender fácilmente de manera aislada

Página 39 de 47
 o Reutilizar

ALTA COHESIÓN
 COHESIÓN:
 Cohesión es una medida de la fuerza con la que se relacionan y del grado de focalización de
las responsabilidades de un elemento.
 Que cada clase haga lo que tiene que hacer
 Medida de relacionamiento interna
 Cada clase tiene que modelar UN concepto (una clase compra y venta estaría mal, ya que
son dos conceptos diferentes)
 Los métodos y atributos deben relacionarse con la clase, no puedo colocar métodos y
responsabilidades de una compra dentro de la clase venta
 Un elemento con alta cohesión/cohesión funcional tiene responsabilidades altamente
relacionadas y no hace una gran cantidad de trabajo
 Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado trabajo.
Tales clases no son convenientes porque:
o Son difíciles de entender
o Difíciles de reutilizar
o Difíciles de mantener
o Delicadas, constantemente afectadas por los cambios
 Grados de cohesión funcional:
o Muy baja cohesión:
 Una única clase es responsable de muchas cosas en áreas funcionales muy
diferentes
o Baja cohesión:
 Una única clase tiene la responsabilidad de una tarea compleja en un área
funcional
o 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.
o Alta cohesión:
 Una clase tiene una responsabilidad moderada en un área funcional y
colabora con otras clases para llevar a cabo las tareas.
 Tiene un número relativamente pequeño de métodos, con funcionalidad
altamente relacionada y no realiza mucho trabajo.
 Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa.
 Ventajosa porque es fácil de mantener, entender y reutilizar. Simplifica el
mantenimiento y las mejoras. Aumenta el potencial de reutilización.
(analogía: si una persona tiene muchas responsabilidades no relacionadas, no
es efectiva)
Página 40 de 47
 SOLUCIÓN:
Asignar una responsabilidad de manera que la cohesión permanezca alta
 PROBLEMA:
¿Cómo mantener la complejidad manejable? (las clases con baja cohesión a menudo
representan un grado de abstracción alto o han asumido responsabilidades que deberían
haber delegado a otros objetos)
 DISCUSIÓN:
 Booch establece que existe alta cohesión funcional cuando los elementos de un
componente (como una clase) “trabajan todos juntos para proporcionar algún
comportamiento bien delimitado”
 Una clase de alta cohesión tiene un número relativamente pequeño de operaciones
con funcionalidad relacionada y poco trabajo por hacer
 Colabora con otros objetos para compartir esfuerzo si la tarea es grande
 BENEFICIOS
 Mejoran la claridad y facilidad de comprensión
 Simplifican la evolución
 A menudo se genera bajo acoplamiento
 Soporta una mayor capacidad de reutilización, porque una clase cohesiva puede
destinarse a un propósito muy especifico
 RELACIÓN CON EL DISEÑO MODULAR
 Fomentamos el diseño modular creando métodos y clases con alta cohesión. Al nivel básico
de objetos, la modularidad se alcanza diseñando cada método con un único y claro objetivo,
y agrupando un conjunto de aspectos relacionados en una clase
 RELACIÓN ENTRE COHESIÓN Y ACOPLAMIENTO:
 Una mala cohesión normalmente causa un mal acoplamiento y viceversa
 Existen pocos casos en que se justifique la aceptación de baja cohesión
 Cohesión+ acoplamiento= independencia de componentes

CONTROLADOR
 CONTROLADOR
 Un controlador es un objeto que no pertenece a la interfaz de usuario, responsable de recibir
o manejar un evento del sistema.
 Define el método para la operación del sistema.
 Normalmente el controlador no hace el trabajo, sino que lo delega a otros objetos (coordina
o controla la actividad)

Página 41 de 47
 El controlador es una especie de fachada sobre la capa del dominio para la capa de interfaz
 Durante el diseño se asignan una o más clases controlador las operaciones del sistema que
se identificaron durante el análisis del comportamiento del sistema
 Podrían utilizarse diferentes controladores para CU distintos.
 Un error típico del diseño de los controladores es otorgarles demasiada responsabilidad
 SOLUCIÓN
 Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una
clase controladora de esos eventos
 PROBLEMA:
 ¿Quién debe ser el responsable de gestionar un evento de entrada al sistema?
(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.)

 DISCUSIÓN:
 Los sistemas reciben eventos de entrada externos, normalmente a través de una GUI
manejada por una persona
 En todos los casos, si se utiliza un diseño de objetos, se debe escoger algún manejador para
estos eventos. El patrón controlador proporciona guías acerca de las opciones
generalmente aceptadas y adecuadas.
 A menudo, es conveniente utilizar la misma clase controlador para todos los eventos del
sistema de un CU de manera que es posible mantener la información acerca del estado del
CU en el controlador.
 Establece que separemos, aislamos la lógica de negocio de la capa de presentación (los
objetos interfaz y la capa de presentación no deberían ser responsables de llevar a cabo los
eventos del sistema. En otras palabras, las operaciones del sistema se deberían manejar en
la lógica de la aplicación o capas del dominio en lugar de en la capa de interfaz del sistema)
 Es buena alternativa cuando hay muchos eventos del sistema entre varios procesos: asigna
su manejo a clases individuales controlables.
 BENEFICIOS:
 Aumenta el potencial para reutilizar y las interfaces conectables.
 Asegura que la lógica de la aplicación o procesos del dominio sean manejados por la capa
del dominio y no en la capa de interfaz.
 Un diseño de una interfaz como controlador reduce la oportunidad de reutilizar la lógica en
futuras aplicaciones, puesto que está ligada a una interfaz particular que es raramente
aplicable en otras aplicaciones. Delegando la responsabilidad de una operación del sistema
a un controlador ayuda a la reutilización de la lógica en aplicaciones futuras. Y puesto que la
lógica no está ligada a la capa de interfaz, puede sustituirse por una interfaz nueva
 Razonamiento sobre el estado de los CU: A veces es necesario asegurar que las operaciones
del sistema tienen lugar en una secuencia valida, o ser capaces de razonar sobre el estado
Página 42 de 47
 actual de la actividad y operaciones del CU que está en marcha. Si es así, es necesario
capturar en algún sitio esta información de estado, el controlador es una opción razonable,
especialmente si el mismo controlador se utiliza en todo el CU
 CUESTIONES Y SOLUCIONES:
 Controlador saturado
Una clase controlador pobremente diseñada tendrá baja cohesión (no centrada en algo
concreto y que gestiona demasiadas áreas de responsabilidad). Esto se denomina como
controlador saturado. Signos de que existe un controlador saturado
o Existe una única clase controlador que recibe TODOS los eventos del sistema en el
sistema, y hay muchos. Esto suele ocurrir si se elige un controlador de fachada
o El propio controlador realiza mucha de las tareas necesarias para llevar a cabo los
eventos del sistema, sin delegar trabajo (violación de los patrones experto y alta
cohesión)
o Un controlador tiene muchos atributos y mantiene información significativa sobre el
sistema o el dominio, que debería haberse distribuido a otros objetos, o duplica
información que se encuentra en otros sitios
 Soluciones:
o Añadir más controladores (suele suceder si el CU es muy complejo)
o En lugar de controlador de fachada, elegir un controlador de CU
o Diseñar el controlador de manera que, ante todo, delegue el cumplimiento de cada
responsabilidad de una operación del sistema a otros objetos.

Página 43 de 47
 PREGUNTAS DE PARCIALES VIEJOS
1. Las responsabilidades que asignamos a un objeto, que están definidas en las clases a la que
ese objeto pertenece, pertenecen básicamente a dos categorías: el conocer y el hacer.
Desarrolle un caso práctico PROPIO en el que ejemplifique responsabilidades relacionadas
con el hacer aplicando el patrón Controlador
2. Hacer algo en uno mismo.
3. Iniciar una acción en otros objetos.
4. Controlar y coordinar actividades en otros objetos.
5. Realice un mapa cognitivo de aspectos comunes comparando 3 diagramas de UML,
clasificados como diagramas de interacción
6. Explique cómo afecta en el ciclo de vida iterativo e incremental cada una de las opciones
respecto al workflow de Análisis
7. Las responsabilidades que asignamos a un objeto, que están definidas en las clases a la que
ese objeto pertenece, pertenecen básicamente a dos categorías: el conocer y el hacer.
Desarrolle un caso práctico PROPIO en el que ejemplifique responsabilidades relacionadas
con el conocer aplicando el patrón Bajo Acoplamiento
a. Estar enterado de los datos privados encapsulados.
b. Estar enterado de la existencia de objetos conexos.
c. Estar enterado de cosas que se pueden derivar o calcular
8. Explique cómo afecta en el ciclo de vida iterativo e incremental cada una de las opciones
respecto al workflow de análisis

Página 44 de 47
9. Describir la relación existente entre diagramas y modelos y describa el propósito de cada
uno de los diagramas que integran la categoría de diagramas de comportamiento y
mencione en qué workflows del proceso unificado se los puede usar
10. Explique los tres tipos de clases que se utilizan para modelar en el análisis y ejemplifique
11. ¿Cuál es la utilidad de los patrones GRASP? Explique su propósito y desarrolle un ejemplo
propio en el que use el patrón alta cohesión y uno en el que no
12. Elija un tema contenido en la unidad nro. 1 que no se haya tratado de las preguntas
anteriores y desarrolle

13. ¿Por qué es importante mantener la consistencia entre todas las vistas en la construcción
del modelo de análisis? Dado el contexto de plantear un modelo de análisis elabore un
ejemplo propio y mencione concretamente dónde se evidencia esa consistencia entre la
viste de máquina de estados, la vista de comportamiento dinámico y la vista de estructura
de clases utilizando el o los modelos de UML que considere adecuados.
14. ¿Cuáles de los diagramas de UML 2.0 pueden utilizarse para construir artefactos del modelo
de análisis? Explique para qué los utilizaría
15. ¿Qué significan los conceptos dominio del problema y dominio de la solución? Relaciónelos
con las diferencias entre los modelos resultantes del análisis y los requerimientos.
16. Las responsabilidades que asignamos a un objeto, que están definidas en las clases a las que
ese objeto pertenece, pertenecen básicamente a dos categorías: hacer y conocer. Desarrolle

Página 45 de 47
 un caso propio en el que ejemplifique para una clase las responsabilidades relacionadas con
el hacer.
a. Hacer algo en uno mismo
b. Iniciar una acción en otros objetos
c. Controlar y coordinar actividades entre objetos
17. Explicar la siguiente afirmación: el modelo de análisis se genera en el espacio de la solución
y tiene por objetivo esbozar una solución genérica centrada en los requisitos funcionales del
cliente (requerimientos funcionales)
18. ¿Cuáles son los diagramas que UML 2?0 propone para crear modelos durante el workflow
de análisis? Explique qué modela cada uno y cuál es la trazabilidad entre ellos (controles de
consistencia a considerar)
19. Explique cómo se expresa la característica del PU “conducido por casos de uso” en el
workflow de análisis.
20. Explique cómo se aplica el principio de bajo acoplamiento al aplicar el patrón controlador.
Presentar ejemplo propio.
21. Realice un cuadro comparativo con los patrones alta cohesión, bajo acoplamiento,
controlador analizando al menos cuatro aspectos.
22. ¿Cuáles de los diagramas de UML 2.0 no se utilizan para construir artefactos del modelo de
análisis. Justifique el motivo.
23. Dadas las características del PUD: iterativo e incremental y centrado en la arquitectura.
Explique cómo se aplican en el workflow de análisis.
24. Relacionar patrón creador con las responsabilidades del hacer
25. Análisis del ciclo de vida en el proceso iterativo e incremental
26. Qué es dominio de la solución y qué es dominio del problema. Establecer una relación entre
ambos haciendo una comparativa entre el modelo de requerimientos y de análisis.
27. Explicar patrón experto y bajo acoplamiento, dar un ejemplo propio donde se apliquen
ambos.
28. Diferencia entre modelo, vista y diagrama
29. Desarrollar ejemplo de aplicación de creador y bajo acoplamiento
30. Desarrollar ejemplo propio que use patrón bajo acoplamiento y otro que no lo use.

Página 46 de 47