semana8 soft ii
DESCRIPTION
Modelo de caso de uso de analisisTRANSCRIPT
![Page 1: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/1.jpg)
SEMANA 8
ANÁLISIS
![Page 2: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/2.jpg)
TEMARIOAnálisis Análisis EstructuradoAnálisis Orientado a ObjetosArtefactos de AnálisisTrabajadoresActividades del Análisis Orientado a Objetos Restricciones para un buen modelo de Análisis
![Page 3: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/3.jpg)
OBJETIVOSConocer que el Análisis ve el ¿Qué? hace el sistema respecto a sus funcionalidades
Identificar las Actividades que se realizan en el Análisis
Refinar los requerimientos capturados en la Fase de Inicio
Analizar la Arquitectura Base para el sistema
Realizar el Caso de Uso en base a las clases: Frontera, Control y Entidad.
![Page 4: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/4.jpg)
1. ¿QUÉ ES EL ANÁLISIS?• Es necesario una descripción del problema y de los
requerimientos.¿Qué problema vamos a resolver?¿Qué debe hacer el sistema?
• El análisis permite:Especificar la función y el rendimiento de un sistemaEspecificar la interface con otros elementosDefinir las restricciones a tener en cuenta
• Construir modelos útiles para:Analista: dominio de datos, funcional,
comportamientoDiseñador: diseño de datos, diseño arquitectónico,
diseño de interfaz, diseño procedimental.
![Page 5: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/5.jpg)
PAPEL DEL ANÁLISIS EN EL CVS
• Mantener la consistencia del modelo de análisis a lo largo de todo el ciclo de vida software.
• Considerar este modelo como una herramienta transitoria e intermedia.
• El proyecto usa el modelo de análisis, para refinar los requisitos en la Captura de Requisitos.
![Page 6: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/6.jpg)
El AOO enfatiza la búsqueda y descripción de objetos o conceptos del dominio del problema.
No olvidar => Análisis => ¿QUÉ?
2. ¿QUÉ ES EL ANÁLISIS ORIENTADO A OBJETOS?
![Page 7: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/7.jpg)
M.C.U. M.A.1. Descrito con el lenguaje del Cliente 1. Descrito con el lenguaje del desarrollador2. Estructurado por los Casos de Uso 2. Estructurado por clases y paquetes3. Vista Externa del sistema 3. Vista Interna del sistema4. Utilizado entre el cliente y el desarrollador 4. Utilizado por los desarrolladores (que debería y que no debería hacer el sistema) (como debe darse forma al sistema)5. Puede contener redundancias, inconsistencias, etc. 5. No debe contener redundancias, inconsistencias, etc.6. Captura la funcionalidad 6. Esboza como llevar a cabo la funcionalidad
(aproximación al diseño)7. Define CU que se analizaran en el MA 7. Define realizaciones de CU del MCU.
COMPARACION: MODELO DE CASOS DE USO vs MODELO DE ANALISIS
![Page 8: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/8.jpg)
![Page 9: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/9.jpg)
2.1. Modelo de Análisis
MODELO DE
ANALISISPAQUETE DEL
ANALISIS
CLASE DE ANALISIS REALIZACION DE CASO
DE USO - ANALISIS
SISTEMA DE
ANALISIS
![Page 10: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/10.jpg)
2.2. Clases de AnálisisRepresenta una abstracción de una o varias clases y/o subsistemas del diseño del sistemaCaracterísticas:• Se centra en los requisitos funcionales y deja los no
funcionales• Es más evidente en el contexto del dominio• El comportamiento se especifica mediante
responsabilidades de nivel más alto y menos formal• Tiene atributos de nivel de abstracción muy alto• Participa en relaciones del modelo conceptual.
![Page 11: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/11.jpg)
• Clase de interfaz• Clase de entidad• Clase de control
CuentaInterfaz de Cajero
Retiro de Efectivo Interfaz de Cajero
Clase del Análisis
Cuenta Retiro de Efectivo
ResponsabilidadesAtributosRelacionesRequisitos Especiales
![Page 12: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/12.jpg)
2.2.1 Clase Interfaz• Modelan la interacción entre el sistema y sus actores.• Representan ventanas, formularios, paneles,
interfaces de comunicación, etc. • Cada clase de interfaz debería asociarse con al menos
un actor, y viceversa.
Comprador Interface de Solicitud de Pago
![Page 13: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/13.jpg)
2.2.2. Clase Entidad• Modela información que posee una vida larga y que
es a menudo persistente.• Suelen sacarse de las clase entidad del negocio.• Diferencia entre clase entidad (objetos manejados por
el sistema) y clase entidad del negocio (contexto e información).
Comprador Interfase de Solicitud de Pago
Factura
muestra
![Page 14: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/14.jpg)
2.2.3. Clase Control• Representan coordinación, secuencia, transacciones y
control de otros objetos• Se usan con frecuencia para encapsular el control de
un caso de uso en concreto• Los aspectos dinámicos y delegaciones a otras clases
del sistema se modelan con estas clases.
Comprador
Interfase de Solicitud de Pago
Planificador de pagos
planifica factura
Factura
muestra
cambia estado
![Page 15: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/15.jpg)
2.3. Realización de un CU (Análisis)• 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 del análisis y de sus objetos del análisis en interacción.
Caso de Uso Realización de Casode Uso - Análisis
MODELO DE CASOS DE USO
MODELO DE ANALISIS
![Page 16: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/16.jpg)
• Diagrama de Clases de Análisis
• Diagrama de Interacción de Análisis
• Flujo de sucesos - Análisis• Requisitos especiales.
Clase de Análisis
Realización de Caso de UsoAnálisis
Participante
![Page 17: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/17.jpg)
Diagramade Colaboración
Diagramade Secuencia
Diagrama de Clases
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read() fill the code..
Casosde Uso
Caso de Uso Realización de Caso de Uso
Una RCU_A es una descripcion de como un CU es ejecutado en el modelo en términos de colaboración.
<<trace>>
![Page 18: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/18.jpg)
2.3.1. Diagrama de Clases (Análisis)
Comprador
Planificador de pagos Solicitud de pagos
Interface de Solicitud de Pago
Confirmación de Pedido
Gestor de Pedidos
Factura
![Page 19: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/19.jpg)
2.3.2. Diagrama de Interacción (Análisis)
: Comprador : Interface de Solicitud de Pago
: Confirmación de Pedido
: Factura
: Planificador de pagos : Solicitud de pagos
: Gestor de Pedidos
1: mostrar facturas6: planificar pago de factura
2: comprobar factura
5: mostrar
7: planificar pago
9: establecer estado (planificado)
8: nuevo
3: obtener
4: obtener
![Page 20: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/20.jpg)
2.3.3. Realización de Caso de Uso : Cuestionario
: Administrador de tablas : Asistente : Interfaz Principal del Asistente : Interfaz de la tabla Cuestionario
1: solicita mantener la tabla cuestionario
2: buscar estructura de la tabla cuestionario
3: leer estructura de la tabla cuestionario
4: guardar estructura
5: crear interfaz del cuestinario
6: solicitar agregar un nuevo registro
7: preparar un registro en blanco
8: solicita grabar informacion
9: grabar informacion
10: ejecuta una insercion
![Page 21: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/21.jpg)
Use Case A
Use Case ARealization
Iteration n
Use Case B
Use Case BRealization
Iteration n+1
Use Case C
Use Case CRealization
Iteration n+2
time
• Iterativamente los CU del sistema se desarrollan por tiempos
• Iteraciones tempranas
• CU arquitecturalmente significativos
• CU de altos riesgos• CU de prioridad alta
ITERACION
![Page 22: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/22.jpg)
3. TRABAJADORES
3.1. Arquitecto• Responsable de la integridad del modelo de análisis,
garantizando que éste correcto, consistente y legible como un todo
• Responsable de la arquitectura del modelo de análisis, es decir, de la existencia de sus partes significativas para la arquitectura tal y como se muestran en la vista de la arquitectura del modelo
• No es responsable del desarrollo y mantenimiento continuo de los diferentes artefactos del modelo de análisis (responsabilidad del ingenieros de Casos de Uso y de Componentes).
![Page 23: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/23.jpg)
3.2. Ingeniero de Casos de Uso• Es el responsable de la integridad una o más
realizaciones de CU, garantizando que cumplen los requisitos que recaen sobre ellos.
• También es responsable del diseño de las realizaciones de los CU, por lo tanto participa en el análisis como el diseño del caso de uso.
• No es responsable de las clases del análisis ni de las relaciones que se usan en la realización del CU.
![Page 24: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/24.jpg)
3.3. Ingeniero de Componentes• Define y mantiene las responsabilidades, atributos,
relaciones, y requisitos especiales de una o varias clases de análisis, asegurándose de que cada clase del análisis cumple los requisitos que se esperan de ella de acuerdo a las realizaciones de caso de uso en las que participan.
• Mantiene la integridad de uno o varios paquetes del análisis. Esto incluye garantizar que sus contenidos son correctos y que sus dependencias de otros paquetes del análisis son correctas y mínimas.
![Page 25: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/25.jpg)
4. ACTIVIDADES - ANALISIS
![Page 26: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/26.jpg)
![Page 27: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/27.jpg)
4.1. Análisis de la arquitectura• Su propósito es esbozar el modelo de análisis y la
arquitectura mediante la identificación de paquetes del análisis, clases del análisis evidentes, y requisitos especiales comunes.
![Page 28: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/28.jpg)
Logical View(Vista Logica)
EstructuraFuncional
Implementation View(vista de implementacion)Administration del software
Process View(Vista de Proceso)Realizacion, escala, rendimiento de procesamiento
Deployment View(Vista de Despliegue)Topologia del sistema,Envio, instalacion,comunicacion
Use Case View(vision del CU)
UnderstandabilityUsability
“4+1 vistas” Modelo de arquitectura de software
![Page 29: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/29.jpg)
4.1.1 Identificación de paquetes del análisis• Proporcionan un medio para organizar el modelo de
análisis en piezas mas pequeñas y mas manejables• Una identificación inicial de los paquetes del análisis se
hace de manera natural basándose en los requisitos funcionales y en el dominio del problema, es decir, en la aplicación o negocio que estamos considerando
• Una forma de identificar paquetes del análisis es asignar la mayor parte de un cierto número de casos de uso a un paquete concreto y después realizar las funcionalidades correspondiente dentro de ese paquete.
![Page 30: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/30.jpg)
• Entre las asignaciones adecuadas tenemos:Los casos de uso requeridos para dar soporte a un determinado proceso de negocios.
Los casos de uso requeridos para dar soporte a un determinado actor del sistema.
Los caso de uso que están relacionados mediante relaciones de generalización y de extensión.
![Page 31: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/31.jpg)
4.1.2 Identificación de clases de entidad obvias• Suele ser adecuado preparar una propuesta preliminar
de las clases de entidad mas importantes (10 ó 20) basado en las clases del dominio o las entidades del negocio que se identificaron durante la captura de requisitos.
• La mayoría de las clases se identificaran al crear las realizaciones de los casos de uso, es por eso que debemos tener cuidado de no identificar demasiadas clases en esta etapa y quedar atrapados en demasiados detalles.
![Page 32: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/32.jpg)
4.1.3 Identificación de requisitos especiales comunes• Requisito que aparece durante el Análisis y que es
importante anotar de forma que pueda ser tratado adecuadamente en el diseño e implementación
• El arquitecto es el responsable de identificar los requisitos especiales comunes de forma que los desarrolladores puedan referirse a ellos como requisitos especiales sobre realizaciones de CU y clases del análisis determinadas
• La característica de cada requisito especial se calificaran después para cada clase o realización de CU que haga referencia al requisito especial.
![Page 33: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/33.jpg)
4.2. Analizar un caso de uso
Analizamos un caso de uso para:• Identificar las clases del análisis cuyos objetos son
necesarios para llevar a cabo el flujo de sucesos del CU
• Distribuir el comportamiento del caso de uso entre los objetos del análisis que interactúan
• Capturar requisitos especiales sobre la realización del CU
• Otra forma de llamar al análisis de CU podría ser refinamiento de CU. Refinamos cada CU como colaboración de clases del análisis.
![Page 34: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/34.jpg)
4.2.1. Identificación de clases del análisis
• Identificamos las clases de control, entidad, e interfaz necesarias para realizar los CU y esbozamos sus nombres, responsabilidades, atributos y relaciones.
• Para identificar las clases de análisis puede que tengamos que refinar las descripciones de los CU en lo referente al interior del sistema. Este refinamiento debe recogerse en la descripción textual de flujos de sucesos-análisis de la realización de los CU.
![Page 35: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/35.jpg)
4.2.2 Descripción de interacciones entre objetos del análisis.
• Cuando tenemos un esbozo de las clases necesarias para realizar el CU, debemos describir como interactúan sus correspondientes objetos del análisis.
• Esto se hace mediante diagramas de colaboración que contienen las instancias de actores participantes, los objetos del análisis, y sus enlaces.
• Un diagrama de colaboración se crea comenzando por el principio del flujo del CU, y continuando el flujo paso a paso decidiendo que interacciones de objetos del análisis y de instancias de actor son necesarias para realizarlo.
![Page 36: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/36.jpg)
4.2.3 Captura de requisitos especiales• En este paso recogeremos todos los requisitos sobre
una realización de caso de uso que se identifican en el análisis pero deberían tratarse en el diseño y en la implementación, tales como los requisitos no funcionales
• Al capturarse estos requisitos, debemos hacer referencia si es posible a los requisitos especiales comunes que habían sido identificados por el arquitecto.
![Page 37: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/37.jpg)
4.3. Analizar una clase
Los objetivos de analizar una clase son:• Identificar y mantener las responsabilidades de una
clase del análisis, basadas en su papel en las realizaciones de CU.
• Identificar y mantener los atributos y relaciones de la clase del análisis.
• Capturar requisitos especiales sobre la realización de la clase del análisis.
![Page 38: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/38.jpg)
4.3.1 Identificar responsabilidades• Las responsabilidades de una clase pueden recopilarse
combinando todos los roles que cumple en diferentes realizaciones de CU.
• Podemos identificar todas las realizaciones de CU en las cuales participa la clase mediante el estudio de sus diagramas de clase y de interacción
• Otra manera de recopilar, es extrayendo las responsabilidades de cada rol uno detrás de otro; añadiendo responsabilidades adicionales o modificando las existentes basándose en una realización de CU tras otra.
![Page 39: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/39.jpg)
4.3.2 Identificación de atributos• Un atributo especifica una propiedad de una clase del
análisis (responsabilidades) • Tener en cuenta lo siguiente:
El nombre de un atributo debería ser un nombreEl tipo de los atributos debe ser conceptual en el
análisis, y, si es posible, no debería verse restringido por el entorno de implementación.
Al decidir un tipo de atributo, debemos intentar reutilizar tipos ya existentes.
Una determinada instancia de un atributo no puede compartirse por varios objetos. En este caso el atributo debe definirse en su propia clase.
![Page 40: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/40.jpg)
Los atributos de las clases de interfaz que interactúan con los actores, suelen representar propiedades de una interfaz de comunicación.
Si una clase de análisis se hace demasiado difícil de entender por culpa de sus atributos, algunos de esos atributos podrían separarse en clases independientes
Los atributos de las clases de interfaz que interactúan con los actores humanos suelen representar elementos de información manipulados por los actores, tales como campos de texto etiquetados.
![Page 41: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/41.jpg)
4.3.3 Identificación de asociaciones y agregaciones• Los objetos del análisis interactúan unos con otros
mediante enlaces en los diagramas de colaboración. Estos enlaces suelen ser instancias de asociaciones entres sus correspondientes clases
• Estudiar los enlaces empleados en los diagramas de colaboración para determinar que asociaciones son necesarias. Estas pueden implicar referencias y agregaciones entre objetos
• No son las relaciones del mundo real lo que debemos modelar como agregaciones o asociaciones, si no las relaciones que deben existir en repuesta a las demandas de las diferentes realizaciones de CU.
![Page 42: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/42.jpg)
4.3.4 Identificación de Generalizaciones• Las generalizaciones deberían utilizarse durante el
análisis para extraer comportamiento compartido y común entre varias clases del análisis diferentes
• Deberían mantener un nivel alto y conceptual, y su objetivo fundamental es hacer el modelo de análisis mas fácil de comprender
• Durante el diseño, ajustaremos las generalizaciones para que encajen mejor con el entorno de implementación elegido, es decir, con el lenguaje de programación
• Una generalización podría desaparecer y convertirse en su lugar en otra relación, como una asociación.
![Page 43: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/43.jpg)
4.4. Analizar un paquete
Los objetivos de analizar un paquete son:• Garantizar que el paquete del análisis sean tan
independientes de otros paquetes como sea posible• Cumpla su objetivo de realizar algunas clases ó CU• Describir las dependencias de forma que pueda estimarse
el efecto de los cambios futuros.
Normas generales para esta actividad:• Definir y mantener las dependencias del paquete con otros
paquetes cuyas clases contenidas estén asociadas con él• Asegurarnos de que el paquete contiene las clases
correctas. Intentar hacer cohesivo el paquete incluyendo sólo objetos relacionados funcionalmente.
![Page 44: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/44.jpg)
Desde - hasta(navegabilidad)
Interfaz Entidad Control
Interfaz X X X
Entidad X
Control X X X
5. Restricciones para un buen modelo
![Page 45: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/45.jpg)
5.1. Restricciones para las clases interfaz
La asociación de “communicate” entre dos clases frontera surge, por ejemplo, para describir como un objeto formulario se relaciona con otros objetos frontera.
Las asociaciones “communicate” o “subscribe” entre una clase frontera y las clases entidades surgen debido a que los objetos de la clase frontera pueden necesitar actualizar la información de los objetos entidad o ser informados de los cambios en los objetos entidad
La asociación de “communicate” entre una clase frontera y otra clase control, es necesaria debido que el objeto de la clase frontera puede disparar un comportamiento en particular del objeto control.
![Page 46: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/46.jpg)
5.2. Restricciones para las clases entidadLas clases entidad deben ser solamente fuente de asociaciones (communicate o subscribe) a otras clases entidades.
Las objetos entidades tienden a ser persistentes mientras que los objetos fronteras y control tienden a ser transigentes. Es recomendable desde el punto de vista de la arquitectura limitar la visibilidad de un objeto entidad para facilitar el mantenimiento.
![Page 47: Semana8 soft ii](https://reader035.vdocuments.net/reader035/viewer/2022081413/5480a74bb4af9f324f8b46f1/html5/thumbnails/47.jpg)
5.3. Restricciones para las clases controlLas asociaciones “communicate” o “subscribe”
entre una clase control y las clases entidades surgen debido a que los objetos de la clase control pueden necesitar actualizar la información de los objetos entidad o ser informados de los cambios en los objetos entidad.
La asociación “communicate” entre las clases control y las fronteras surge porque el resultado del comportamiento de un control invocado por una frontera puede ser comunicado al ambiente(otras fronteras)
Las asociaciones “communicate” entre las clases control permiten la construcción de comportamientos más complejos.