Flujo de Análisis Parte II

Lic. Espinoza Robles

Armando DavidFuente: El Proceso Unificado de Desarrollo de Software Cap:8

Ivar jacobson, grady booch, james rumbaugh

Artefacto: descripcion de la Arquitectura (vista del modelo de Analisis)

• La descripcion de la arquitectura contiene una vista de la arquitectura del modelo de analisis, que muentra sus artefactos significativos para la arquitectura los que son:– La descomposicion del modelo de analisis en paquetes y

sus dependencias

– Las clases fundamentales del analisis como las clase de entidad, las clases de interfaz, las clases de control y clases de analisis que encapsulan fenomenos significativos para la aquitectura.

– Realizaciones de casos de uso que describen funciones importantes y criticas.

Trabajadores• Trabajador Arquitecto:

– Es responsable de la integridad del modelo de análisis para que sea correcto, consistente y legible como un todo.

– En sistemas grandes y complejos cuando el trabajo de mantenimiento se hace rutinario se puede delegar este trabajo a un ingeniero de componentes de alto nivel.

– El modelo de análisis es correcto cuando realiza la funcionalidad descrita en el modelo de casos de uso.

Las responsabilidades del arquitecto en el analisis

Arquitecto

Responsable de

Vista de la Arquitectura

Modelo de Analisis Descripcion de la arquitectura

• Trabajador Arquitecto:– Es también responsable de la arquitectura del

modelo de análisis – El arquitecto no es responsable del desarrollo y

mantenimiento continuo de los diferentes artefactos del modelo de análisis. Estos son responsabilidad de los correspondientes ing. De CU, e ing. De componentes.

• Trabajador: Ingeniero de Casos de Uso.– Es responsable de la integridad de uno o mas

realizaciones de CU, garantizando que cumplan los requisitos que recaen sobre ellos.

Ing.,de CU

Responsable de

Realizacion de CU - Analisis

• Una realizacion de CU debe llevar a cabo correctamente el comportamiento de su correspondiente CU del modelo de casos de uso.

• El Ing. De CU es responsable tanto del analisis como del diseño del CU.

• El Ing, de CU no es responsable de las clases del analisis ni de las relaciones que se usan en la realizacion de casos de uso. Esta responsabilidad es del Ing de Componentes.

• Trabajador: Ing. De Componente– Define y mantiene las responsabilidades,

atributos, relaciones y requisitos especiales de una o varias clases del análisis, asegurándose de que cada clases del análisis cumple los requisitos que se esperan de ella.

– Mantiene la integridad de uno o varios paquetes del análisis. Garantiza que sus contenidos son correctos y que sus dependencias de otros paquetes del análisis son correctas y mínimas.

– es apropiado que sea también responsable de las clases de análisis contenidas en un paquete de análisis.

• Si existe una correspondencia directa entre un paquete de analisis y los subsistemas de diseño correspondientes el Ing. De componentes debera ser tambien responsablde de esos subsistemas.

Ing de Componentes

Responsable de

Clase de analisis Paquete de analisis

• Flujo de Trabajo– Los arquitectos comienzan la creación del

modelo de análisis identificando los paquetes de análisis principales, las clases de entidad evidentes y los requisitos comunes.

– Después los Ing de CU realizan cada CU en términos de las clases del análisis exponiendo los requisitos de comportamiento de cada clase.

– Los Ingenieros de Componentes especifican los requisitos y los integran dentro de cada clase creando responsabilidades, atributos y relaciones para cada clase.

Flujo de trabajo en el analisis

Arquitectura Analisis de la arquitectura

Ing de CUAnaliza un CU

Analiza una claseIng de Componentes

Analiza un Paquete

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

Identificación de Paquetes de Análisis : estos proporcionan un medio para organizar el modelo de análisis en piezas mas pequeñas y manejables. Que se hace de manera natural basándonos en los requisitos funcionales y en el dominio del problema. De forma directa se hace asignando la mayor parte de un numero de CU a un paquete concreto y después realizar la funcionalidad correspondiente dentro de paquete

– Entre las asignaciones adecuadas de CU a un paquete en concreto tenemos los siguintes:

• Los CU requeridos para dar soporte a un determinado proceso de negocio.

• Los CU requeridos para dar soporte a un determinado actor del sistema.

• Los CU que están relacionados mediante relaciones de generalización y de extensiones

– Ejemplo: Identificación de paquete de Análisis• Los CU pagar Factura, Enviar Aviso y Enviar Factura

al Comprador, están todos implicados en el mismo proceso de negocio: Ventas del Pedido a la entrega, por lo que pueden incluirse en un mismo paquete de análisis

• Sin embargo Interbank Software debe poner su sistema a disposicion de diferentes clientes compradores , vendedores y algunos como ambos, por lo que se separa la realizacion de CU para vendedor o para comprador.

Gestion de facturas de comprador

Gestion de facturas de Vendedor

Pagar factura Enviar Factura al comprador

Enviar Aviso

– Gestion de los aspectos comunes entre paquetes de Analisis

• Cuando dos o mas paquetes de análisis necesitan compartir la misma clase de análisis, una manera adecuada de tratarlo es extraer la clase compartida y colocarlo dentro de su propio paquete o fuera de cualquier paquete y hacer que los otros paquetes sean dependientes de este paquete o clase general.

• Las clase compartidas de este tipo son a menudo clase de entidad de las cuales se puede hacer trazas hasta clases de dominio o clases de entidad de negocio.

• Ejemplo: identificacion de paquetes del analisis generales– Cada una de las clase de domino Cliente de Banco y

Cuenta son entidades importantes y complejas. Las cuales requieren un soporte sofisticado del sistema y están compartidas por otros paquetes del análisis, por lo que se crea un paquete aparte para cada clase: Gestión de Cuenta y Gestión de Cliente de Banco

– Los paquetes Gestión de Cuentas y Gestión de Clientes de Banco contendrán muchas clases de análisis tales como clases de control y de interfaz relacionadas con Cuenta y con Gestión de Clientes de Banco.

Identificacion de paquetes de analisis generales a partir de clases de dominio

Gestion De Cuentas

Gestion de Clientes de pago

cuenta Cliente de pago

Del Modelo de dominio

Paquete del Analisis

tracetrace

Identificación de Paquetes de Servicios

• Se hace cuando el trabajo de analisis esta avanzado

• Cuando los requisitos funcionales se comprenden bien y existen la mayoria de clases de analisis

• Para identificar servicos debemos hacer los siguiente:– Identificar un paquete de servicio por cada

servicio.– Identificar un paquete de servicio que podría

hacerse opcional.

• Ejempo: Paquetes de servicos opcionales:– La mayoría de los vendedores que utilizan el

sistema de Inter Banck quieren un servicio para enviar avisos.

– Algunos vendedores quieren que los avisos se envíen automáticamente, mientras que otros prefieren que se les avise cuando haya una factura atrasada.

Paquete de servicios Avisos automaticos y manueles ubicados dentro del paquete Gestion de Facturas de Vendedor

Gestion de Factura De Vendedor

Avisosautomaticos

Service package

Avisos manuales

Service package

Enviar Aviso

tracetrace

• Definicion de Dependencias entre paquetes de analisis.– Se definen si sus contenidos están relacionados.

La dirección de la dependencia debería ser la misma dirección de la relación.

– El objetivo es conseguir paquetes relativamente independientes y débilmente acoplados, pero con cohesión interna alta.

– Para hacer mas clara la dependencia, los paquetes específicos de la aplicación quedan en una capa de nivel suprior y los paquetes generales en una capa inferior.

Dependencia y capas de paquete de analisis

Gestion de facturasDe comprador

Gestion de facturas De vendedor

Gestion deCuentas

Capa especifica de la aplicacion

Capa general de la aplicacion

• Identificacion de clases de entidad Obvias.– Se propone una lista preliminar de clases de

entidad basado en las clase de dominio o las entidades del negocio.

– La mayoría de las clases se identificaran al crear la realización de los CU. Una clase de entidad que no participa en una realización de CU no es necesaria.

– El esbozo inicial de clases de entidad significativas servirá para la arquitectura.

• Ejemplo: una clase de entidad identificada a partir de una clase de dominio– Factura es una clase de dominio, usamos esta

clase del dominio para proponer una de las clases de entidad iniciales con los mismos atributos de la clase factura: cantidad, fecha de envió, fecha limite de pago.

• Identificacion de requisitos especiales comunes:– Es un requisito que aparece durante el análisis

que puede ser tratado adecuadamente en la siguientes actividades de diseño e implementación

– Como por ejemplo las limitaciones o restricciones sobre:

• Persistencia• Distribución y concurrencia• Características de seguridad• Tolerancia de fallos• Gestión de transacciones

– El Arquitecto es responsable de identificar los requisitos especiales comunues de forma que los desarroladoreas puedan referirse a ellos como requisitos especiales sobre realizacion de CU.

– Ejemplo:un requisito de persistencia tiene las siguientes carateristicas:

• Rango de tamaño• Volumen• Periodo de persistencia• Frecuencia de actualización• Fiabilidad

Actividad: Analizar CU• Analizamos un CU para :

– Identificar las clase de análisis cuyos objetos son necesarios para llevar a cabo el flujo de suceso de CU

– Distribuir el comportamiento del CU entre los objetos del análisis que interactúan.

– Capturar requisitos especiales sobre la realización de CU.

• Otra forma de llamar al análisis de CU podría ser Refinamiento de CU.

Las entradas y los resultados del análisis de un CU

Modelo de CU

Requisitos adicionales

Modelo del Negocio o modelo del dominio

Descripción de la arquitectura

Ingeniero de CU

Análisis de un CU

Realización de CU - análisis

Clases del análisis (esbozo)

• Identificacion de clase de Analisis:– En este paso identificamos las clases de control,

entidad e interfaz necesarias para realizar los casos de uso, esbozamos sus nombres, responsabilidades, atributos y relaciones.

– Podemos usar las siguientes normas generales para identificar las clases del análisis:

• Identificar las clases de entidad mediante el estudio en detalle de la descripción del CU y del modelo del Dominio que se tenga.

• Identificar una clase de interfaz central para cada actor humano y dejar que esta clase represente la ventana principal de interfaz de usuario con el cual interactua el actor.

• Identificar una clase de interfaz primitva para cada clase de entidad que hayamos encontrado anteriormente.

• Identificar una clase de interfaz entral para cada actor que sea un sistema externo, y dejar que esta clase represente la interfaz de comunicación.

• Identificar una clase decontrol responsable del tratamiento de control y de la coodinacion de la realizacion del CU. Y luego refinar esta clase de control.

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

– Podemos observar lo siguiente sobre estos diagramas de colaboración:

• El CU se invoca mediante un mensaje proveniente de una instancia de un actor sobre un objeto de interfaz.

• Cada clase identificada debería tener al menos un objeto que participa en un diagrama de colaboración. Si no lo tiene la clase de análisis es superflua.

• Los mensajes no se asocian a operaciones. En cambio un mensaje debería reflejar el propósito del objeto invocante en la interacción con el objeto invocado.

• Los enlaces en el diagrama deben ser instancias de asociaciones entre clases de análisis.

• La secuencia en el diagrama no deberá ser nuestro objetivo principal y puede eliminarse si es difícil de mantener o crea confusión en el diagrama.

• El objetivo principal debería estar en las relaciones entre objetos y en los requisitos sobre cada objeto en particular.

• El diagrama de colaboración debería tratar todas las relaciones del CU que se esta realizando.

– En algunos casos es apropiado complementar el diagrama de colaboración con descripciones textuales. Estas descripciones textuales deberán recogerse en el artefacto flujo de suceso análisis de la realización del CU.

• Captura de Requisitos especiales:– Es este paso se recogen todos los requisitos

sobre una realización de casos de uso que se identifican en el análisis. Pero deben tratarse en el diseño y en la implementación.

– Ejemplo: los requisitos especiales planteados por la realización del CU Pagar Factura incluyen los siguientes:

• La clase de factura debe ser persistente.

• La clase gestor de pedidos deberá ser capaz de tratar 10,000 transacciones por hora.

• Actividad : analizar una clase.– Los objetivos de analizar una clase son:

• Identificar y mantener las responsabilidades de una clase del análisis, basados en su papel en la realización 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 de análisis.

Las entradas y los resultados del análisis de una clase

Ingeniero de componentes

Analizar una clase

Realización de CU - análisis

Clases del análisis (esbozo)

Clases de análisis (terminado)

• Identificar Responsabilidades:– Las responsabilidades de una clase pueden

recopilarse combinando todos los roles que cumple en diferentes realizaciones de CU

– Ejemplo: roles de clase• Los objetos Factura se crean durante el CU enviar

Factura al Comprador. El vendedor lleva a cabo este CU para solicitar al comprador que pague un pedido.

• El pago se lleva a cabo en el CU Pagar factura donde el objeto Planificar de Pagos planifica el pago de un objeto factura. Mas adelante la factura se cierra.

• Hay varias maneras de recopilar las responsabilidades de una clase, una de ellas es extraer las responsabilidades de cada rol una detrás de otra.

• Ejemplo: responsabilidades de clase:

– El Planificador de pagos tiene las siguientes responsabilidades:

• Crear una solicitud de pago

• Hacer el seguimiento de los pagos que se han planificado y enviar una notificación cuando se ha efectuado o cancelado el pago.

• Iniciar la transferencia del dinero en la fecha debida.

• Notificar una factura cuando se ha planificado para su pago y cuando se ha pagado.

• Identificación de atributos:– Un atributo especifica una propiedad de una

clase del análisis y es necesaria para las responsabilidades de su clase, se debe tener las siguientes normas generales cuando identificamos atributos:

• El atributo deberá tener un nombre• El tipo de atributo debería ser conceptual en el

análisis y si es posible no debería verse restringido por el entorno de implementación

• Al decidir el tipo de un atributo debemos intentar reutilizar tipos ya existentes.

• Una determinada instancia de un atributo no puede compartirse por varios objetos del análisis

• 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 entidad suelen ser bastante evidentes.

• Los atributos de la clase de interfaz que interactúan con los actores humanos suelen representar elementos de información manipulados por actores.

• Los atributos de la clase interfaz que interactúan con actores – sistemas suelen representar propiedades de un interfaz de comunicación

• Los atributos de la clase de control son poco frecuentes debido a su corto tiempo de vida.

• Si una clase tiene muchos atributos o atributos complejos podremos mostrarlos en un diagrama de clase aparte con solo la sección atributos.

• 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 entre sus correspondientes clases. los enlaces pueden implicar la necesidad de referencias y agregaciones entre objetos.

– Para modelar las agregaciones o asociaciones se beben observar las relaciones que existen en respuesta a las demandas de las diferentes realizaciones de CU.

– El ingeniero de componentes define la multiplicidad de la asociaciones, los nombres de los roles, clases de asociación, roles ordenados, roles cualificados y asociaciones n-arias

Ejemplo: una asociación entre clases del análisis• Una factura es una solicitud de pago de uno o mas

pedidos. Esto se representa mediante una asociación con multiplicidad “1” (siempre hay al menos un pedido asociado con una factura) y mediante el Rol pedido a pagar.

Pedido

Factura

1 .. * Pedidos a pagar

– Las agregaciones deberán utilizase cuando los objetos representa:

• Conceptos que se contienen físicamente uno al otro como coche que contiene al conductor y pasajeros.

• Conceptos que están compuestos uno de otro. Un coche consta de motor y ruedas.

• Conceptos que forman una colección conceptual de objetos. Una familia consta de padre, madre, hijos.

– Identificación de Generalizaciones: • Las generalizaciones deben usarse durante el análisis

para extraer comportamiento compartido y común entre varias clases del análisis diferentes. Las generalizaciones deberían mantenerse en un nivel alto y conceptual y ayudar a comprender el modelo de análisis.

– Ejemplo: identificación de generalizaciones• Facturas y Pedidos tienen responsabilidades

similares. Ambas son especializaciones de un objeto mas general Objeto de Comercio.

Pedido Factura

Objeto de comercio

• Captura de requisitos especiales– En este paso recogeremos todos los requisitos de

una clase del análisis que se han identificado en el análisis pero que deberían tratarse en el diseño y en la implementación.

– Ejemplo: captura de requisitos especiales sobre una clase de análisis:

• Las características del requisito de persistencia de la clase Factura podrían definirse de la siguiente manera:

– Rango de tamaño 2 a 24 kb por objeto– Volumen hasta 100,000– Frecuencia de actualización

» Creación: 1,000 al día» Actualización: 30 actualizaciones a la hora» Lectura: 1 acceso a la hora

• Actividad: Analizar un paquete– Los objetivos de analizar un paquete son:

• Garantizar que el paquete del análisis es tan independiente de otros paquetes como sea posible

• Garantizar que el paquete del análisis cumple sus objetivos de realizar algunas clases del dominio o casos de uso.

• Describir las dependencias de forma que pueda estimarse el efecto de los cambios futuros

– Algunas normas para esta actividad• Definir y mantener las dependencias del paquete con

otros paquetes cuyas clases estén asociadas.• Asegurarse de que el paquete contiene las clases

correctas. Incluir los objetos relacionados funcionalmente.

Las entradas y los resultados del análisis de un paquete

Descripción de la arquitectura

Paquete del Análisis (esbozo)

Ingeniero de Componentes

Analizar un paquete Paquete del Análisis (terminado)

– Ejemplo: dependencia entre paquetes• El paquete Gestión de Factura de vendedor contiene

una clase Procesamiento de Factura asociado a la clase Cuenta del paquete Gestión de Cuentas.

Gestion de Facturas de Vendedor

Gestión de Cuentas

Gestión de Facturas de Vendedor

Gestión de Cuentas

Procesamiento de la Factura

Cuenta

Procesamiento de la Factura

Cuenta

• Resumen del Análisis– El resultado del análisis es el modelo de análisis

que es un modelo de objetos conceptual que analiza los requisitos mediante su refinamiento y estructuración. Incluye los siguientes elementos.

• Paquete de análisis y paquete de servicios sus dependencias y contenidos.

• Clases de análisis sus atributos relaciones y requisitos especiales.

• Realizaciones de CU análisis que describen como se refinan los CU

• La vista de arquitectura del modelo de análisis.

– El modelo de análisis se considera la entrada fundamental para las actividades de diseño. El modelo de análisis influirá en el modelo de diseño de la siguiente manera

• Los paquete de análisis y servicios influirán en los subsistemas del diseño y servicio.

• Las clases del análisis servirán como especificaciones al diseñar las clases.

• La realización de CU análisis tienen dos objetivos:– Ayudar a crear especificaciones mas precisas para el CU

– Como entrada al diseño de los CU

• La vista de la arquitectura del modelo de análisis se utiliza como entrada en la creación de la vista de la arquitectura del modelo de diseño.