SEMANA 8

ANÁLISIS

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

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.

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.

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.

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?

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

2.1. Modelo de Análisis

MODELO DE

ANALISISPAQUETE DEL

ANALISIS

CLASE DE ANALISIS REALIZACION DE CASO

DE USO - ANALISIS

SISTEMA DE

ANALISIS

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.

• 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

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

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

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

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

• 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

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

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

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

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

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

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

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.

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.

4. ACTIVIDADES - ANALISIS

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Desde - hasta(navegabilidad)

Interfaz Entidad Control

Interfaz X X X

Entidad   X  

Control X X X

5. Restricciones para un buen modelo

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.

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.

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.