Tema 7 Clase 7 Proceso Unificado - Analisis

Vista previa del material en texto

CLASE 7
MODELO DE DESARROLLO DE PROGRAMAS Y PROGRAMACION 
CONCURRENTE – 2.019
FAC.DE INGENIERIA - UNJu
Proceso Unificado - Análisis
ANALISIS (UML)
• Conseguir 1 comprensión + precisa de los requisitos y 1 descripción de los mismos q sea fácil 
de mantener y q ayude a estructurar el sist.entero, incluyendo su arquitectura.
• Analizar los requis.usando el leng.de los desarrolladores y producir 1vista interna del sist. Es 1 
modelo conceptual, refina y estructura los requis.Facilita su comprensión, modif.y mantenim
Objetivos
En esta disciplina se analizan los requisitos q se describieron en la 
captura de requisitos, refinándolos y estructurándolos.
Importancia del Modelo de Análisis
• Ofrece 1especificación + precisa de los requisitos q la q tenemos como resultado de la 
captura de requisitos, incluyendo al modelo de CU.
• Se describe utilizando el leng.de los desarrolladores, y se puede x lo tanto introducir un 
mayor formalismo y ser utilizado p/razonar sobre los funcionamientos internos del sist.
• Estructura los requis.de modo q facilite comprensión/preparación/modificación/mantenim. 
• Es 1ra.aproximación al modelo de diseño (aunque es 1modelo por sí mismo), y es x lo tanto 
1entrada fundamental cuando se da forma al sist.en el diseño y en la implementación. 
DIFERENCIA ENTRE REQUISITOS Y ANÁLISIS DEL PROCESO UNIFICADO
Lenguaje del cliente
Vista externa del sistema
Estructurado x CU
Se usa como contrato entre cliente y 
desarrollad.sobre lo q debe o no hacer el Sist
Puede contener inconsist, redundancias, etc. 
entre los requis
Captura la funcionalidad del Sist
Define CU
Modelo de CU Modelo de Análisis
Lenguaje del desarrollador
Vista interna del sistema
Estructurado x Clases de Análisis
Se usa p/comprender como dar forma 
al sist. (diseñado e implementado)
No debe contener inconsist, 
redundancias, etc. entre los requis
Señala cómo incorporar esa 
funcionalidad en el sistema
Define realizaciones de CU, y c/u de 
ellas representa el análisis de un CU
ANALISIS (UML) - ETAPAS
2 Análisis
2.1 Analizar los CU
2.1.1 Identificar clases: Entidad, Interfaz y Control
2.1.2 Describir interacciones: Diagr.de Colaboraciones
2.2 Analizar c/Clase de Análisis 
2.2.1 Identificar responsabilidades
2.2.2 Identificar atributos
2.2.3 Identificar relaciones: asociaciones, agregaciones 
y generalizaciones
2.1 ANALIZAR LOS CU
2.1.1 IDENTIFICAR CLASES
• Modelan información de 
larga vida (persistente)
• Pueden ser pasivas o 
activas
• Encapsulan información 
y operaciones 
asociadas, x ej: 
repositorios de informac.
• Se pueden derivar de 1
clase de entidad del 
negocio o de 1clase de 
dominio
Identificar Clases Entidad
• Modelan la interacción entre 
el sist.y los actores
• Representan la interfaz del 
sist.(ventanas, formularios, 
interfaces de comunicac., 
interfaces de impresoras, 
sensores, terminales, ...)
• Con poco detalle
• Describe la información 
presentada al actor y las 
peticiones q hace el actor al 
sist.
Identificar Clases Interfaz
• Representan la coordinación 
entre objetos
• Encapsulan el flujo de control 
de un determinado CU
• Representan la lógica del 
negocio - cálculos
• Ni interacciones con el US. ni 
problemas de almacenar 
información (persistencia)
• Tiempo de vida: corto
Identificar Clases Control
2.1.2 DIAGRAMA DE COLABORACIONES
Muestra interacciones organizadas alrededor de roles de las clases entidad, interfaz y 
control, etiqueta con nros.de secuencia tanto la sec.de msjes. como los hilos concurrentes, 
mostrando cómo las instancias específicas de las clases trabajan juntas p/1objetivo común.
Ej.de Diagr.de
Colaboración
2.2 ANALIZAR CADA CLASE DE ANÁLISIS 
2.2.1 IDENTIFICAR RESPONSABILIDADES
Se describe brevemente las responsabilidades de las Clases Control. Tiene como objetivos:
• En c/realización de CU, se debe ver q rol/papel juega la clase de análisis
• Combinar roles/papeles y describirlos juntos
Se describen atributos de las clases Entidad, Interfaz y Control. Consideraciones:
• Se debe identificar el Nombre de los atrib.
• Los tipos de atrib.son conceptuales, no hay q restringidos x el entorno de implementación
• En las Clases Entidad se deben identificar los atrib.derivados del dominio
• En las Clases Interfaz q interactúan con actores humanos se deben reconocer los atrib.q
representan campos de texto, etiquetas, etc
• En las Clases Interfaz que interactúan con subsist.externos se identifican los atrib.q representan 
prop.de la interfaz de comunicación
• En las Clases ctrl.se distinguen los q representan estados de la sesión actual: valores 
calculados en el CU
2.2.2 IDENTIFICAR ATRIBUTOS
2.2ANALIZAR CADA CLASE DE ANÁLISIS 
2.2.2 IDENTIFICAR RELACIONES: ASOCIACIONES,
AGREGACIONES Y GENERALIZACIONES
Identifica relac. entre las clases encontradas, pueden ser Asoc., Agreg.o Generaliz.Aspectos:
• Describen Asociaciones o enlaces
• Disminuye el acoplamiento o el nro.de relaciones entre clases: las (inter)relaciones existen 
en respuesta a las demandas de las realizaciones de CU
• No optimizan los caminos de acceso
• Define multiplicidad y nombres de los roles
• Plantea agregación y composición es decir 1objeto q contiene físicamente a otros (x ej.1 
coche q contiene conductor+pasajeros), 1 objeto compuesto de otros (x ej.1 coche que 
consta de motor + ruedas) y 1obj.q es 1colección conceptual de objetos (x ej.1familia q 
consta de padre+madre+hijos)
• Identifica generalizaciones - especializaciones entre clases
2.2ANALIZAR CADA CLASE DE ANÁLISIS 
2.2.2 IDENTIFICAR RELACIONES: ASOCIACIONES,
AGREGACIONES Y GENERALIZACIONES
Asocia objetos q colaboran entre sí. Es 1conexión semánt.entre clases, 1conj.de enlaces entre 
instancias de clases. X ej. 1país q tiene 1ciudad como capital o 1alumno q estudia 1 o+asignat
ASOCIACION
Indica q 1objeto es 1parte de otro objeto (el agregado). El objeto agregado no tiene sentido 
sin q existan los objetos “parte” (o componentes) correspondientes. X ej.1cuadro q se divide 
en marco, cristal, lámina; o 1ventana de entorno gráfico q tiene: título, menú, contenido.
Hay 2 tipos de agregación: Débil cuando las partes pueden existir fuera del agregado o Fuerte 
(composición) cuando las partes sólo existen dentro del agregado.
P/modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: 
enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos q son 
instancias de clases definidas x el desarrollador de la aplicación, tenemos 2 posibilidades:
AGREGACION
2.2ANALIZAR CADA CLASE DE ANÁLISIS 
2.2.2 IDENTIFICAR RELACIONES: ASOCIACIONES,
AGREGACIONES Y GENERALIZACIONES
• Por Valor (rombo relleno): es 1tipo de relación estática, en donde el tiempo de vida del 
objeto incluido está condicionado x el tiempo de vida del que lo incluye. Este tipo de relación 
es comúnmente llamada Composición (el Objeto base se construye a partir del objeto 
incluido, es decir, es "parte/todo").
• Por Referencia (rombo transparente): es 1 tipo de relación dinámica, en donde el tiempo de 
vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es 
comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
Agregación (cont)
Ej. un Almacén posee Clientes y Cuentas (los 
rombos van en el objeto q posee las referencias). 
Cuando se destruye el Objeto Almacén también son 
destruidos los objetos Cuenta asociados, en cambio 
no son afectados los objetos Cliente asociados.
2.2ANALIZAR CADA CLASE DE ANÁLISIS 
2.2.2 IDENTIFICAR RELACIONES: ASOCIACIONES,
AGREGACIONES Y GENERALIZACIONES
Generalización (/Especialización)
Indica 1relación entre una clase y 1 o + versiones especializadas de la misma clase, en donde 
las subclases heredan atributos y operaciones. No relaciona objetos. Además pueden definir 
nuevos atributos y operaciones, pudiendo existir varios niveles de generalización o jerarquíade herencia.
Ejemplo de 
Generalización
• El Proceso Unificado de Desarrollo de Software. De Gustavo Torossi.
• El Proceso Unificado de Desarrollo de Software. 2000. De Ivar Jacobson, 
Grady Booch y James Rumbaugh. Capítulo 8. Pág.: 165:204
• Métrica 3. Técnicas y Prácticas. Ministerio de Administraciones Públicas. De 
Alarcos. Página 51-52
BIBLIOGRAFÍA RECOMENDADA