Grupo :1

integrantes de equipo:Ricardo Lara Ramírez

Ángel Alberto Torres PérezJuan Daniel Martínez Flores

Daniel Vite VictorLuz María Huerta Solís

Carlos Alberto Linares Díaz

• El Análisis Orientado a Objetos (AOO) es parte de la disciplina Análisis y Diseño de RUP; esta disciplina tiene como propósito:

• Transformar los requisitos en un diseño del sistema a crear.• Definir una arquitectura robusta para el sistema.• Adaptar el diseño para que funcione en el ambiente

de implementación, diseñándolo para un desempeño esperado.

Análisis y diseño.

• Toma los casos de uso documentados del flujo de trabajo de la Captura de Requisitos y los traslada a elementos de diseño que serán usados para construir el sistema. Por medio de varias actividades y modelos, el flujo de trabajo de Análisis y Diseño busca transformar la información obtenida de los stakeholders en información que los programadores podrán usar.

El flujo de trabajo de Análisis y Diseño

Flujo de Trabajo de la disciplina Análisis y Diseño.

• En la fase de Inicio, la disciplina de Análisis y Diseño se preocupa por establecer si la visión del sistema es factible, y en determinar las tecnologías potenciales para la solución de software (dentro de la actividad Perform Architectural

• Synthesis). Si se considera que pocos riesgos se asocian al desarrollo (porque el dominio se entiende muy bien, el sistema no es novedoso o cualquier otra razón parecida),

entonces, éste aspecto se omite del flujo de trabajo.

• En la parte inicial de la fase de Elaboración, se enfoca el esfuerzo en crear una arquitectura inicial del sistema (en la actividad Define a Candidate Architecture). La cual proporcionará un punto inicial para todo el trabajo de análisis. Si la arquitectura ya existe, porque fue creada en iteraciones anteriores o en proyectos anteriores, el trabajo se enfoca en cambios para refinar la arquitectura (actividad Refine the Architecture) y en analizar el comportamiento, y crear un conjunto

• inicial de elementos los cuales

• proporcionarán un comportamiento apropiado (en la actividad Analyze Behavior).

• Después de que los elementos iniciales son identificados, se refinan en iteraciones futuras. a actividad Design Components produce un conjunto de componentes los cuales proveen un comportamiento adecuado para satisfacer los requisitos del sistema. Si el sistema incluye una base de datos, entonces, la actividad de Design the Database se ejecuta en paralelo.

• se ejecuta en paralelo. El resultado es un conjunto inicial de componentes los cuales en un futuro son refinados dentro de la Implementación.

• Con el fin de entender el flujo de trabajo realizado en esta disciplina en forma más detallada se ha dividido su descripción en dos partes: Análisis orientado a objetos y Diseño orientado a objetos. A continuación, se empezará a estudiar el AOO.

• Es comprender el problema y comenzar a desarrollar un modelo visual de lo que se está tratando de construir, independiente de la tecnología a utilizar en la aplicación, como el lenguaje de programación. El análisis se centra en la traducción de los requisitos funcionales en conceptos de software. La idea es identificar los objetos que conforman el sistema, centrándose en el comportamiento

Objetivo del análisis

• Una identificación inicial se hace de manera natural basándonos en los requisitos funcionales y en el dominio de problema, agrupando un cierto número de casos de uso en un paquete concreto, y realizando la funcionalidad correspondiente dentro de dicho paquete. Algunos criterios para agrupar casos de uso son:

Identificación de paquetes de análisis

Casos de uso para dar soporte a un determinado proceso de negocio.Casos de uso para dar soporte a un determinado actor del sistema.Casos de uso relacionados mediante relaciones de generalización y de extensión.

• La identificación de paquetes de servicio se suele hacer cuando el trabajo de análisis está avanzado, cuando se comprenden bien los requisitos funcionales, y existen la mayoría de las clases del análisis.

Para identificar paquetes de servicio debemos:

Identificación de paquetes de servicio

Identificar un paquete de servicio por cada servicio opcional. El paquete de servicio será una unidad de compra (por ejemplo, enviar avisos a clientes).Identificar un paquete de servicio por cada servicio que podría hacerse opcional, incluso aunque todos los clientes siempre lo quieran.

• La arquitectura de un es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

• En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.

En general la arquitectura es:

• Descrito en el lenguaje del desarrollador.• Vista interna del sistema.• Estructurado por clases y paquetes

estereotipados; proporciona la estructura a la vista interna.

• Utilizado fundamentalmente por los desarrolladores para comprender cómo deberá darse forma al sistema, es decir, cómo debería ser diseñado e implementado.

Analizar comportamiento

• No debería contener redundancias ni inconsistencias entre requisitos.

• Esboza cómo llevar a cabo la funcionalidad dentro del sistema, incluida la funcionalidad significativa para la arquitectura; sirve como una primera aproximación al diseño.

• Define realizaciones de caso de uso, y cada una de ellas representa el análisis de un caso de uso del modelo de casos de uso.

• Modelo físico (implementación).• Específico para una implementación.• Cualquier número de estereotipos físicos.• Más formal.• Más caro.• Más capas.• Dinámico (muy centrado en la secuencia).• Creado fundamentalmente como “programación visual” en

ingeniería de ida y de vuelta.• Debe ser mantenido todo el ciclo de vida.

Diseñar componentes

• Durante esta actividad se construye un esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellos.

Diseñar la base de datos

• El objetivo de esta tarea es definir el entorno tecnológico propio de los procesos de migración y carga inicial, adecuando al mismo las necesidades en el plan de migración y carga inicial de datos. En la descripción del entorno tecnológico, hay que tener en cuenta las utilidades software específicas de estos procesos. Se realiza una estimación de capacidades (capacity planning) para este entorno que permita evaluar las necesidades de infraestructura, principalmente relacionadas con el espacio de almacenamiento y las comunicaciones.

Especificación del Entorno de Migración

• De entrada• Plan de Migración y Carga Inicial de Datos (ASI 6.4) (en orientación

a objetos DSI 4.7)• Diseño de la Arquitectura del Sistema (DSI 7.2)• Entorno Tecnológico del Sistema (DSI 7.2)• Modelo Físico de Datos Optimizado (DSI 7.2)• Esquemas Físicos de Datos (DSI 7.2)• De salida• Plan de Migración y Carga Inicial de Datos

– Especificación del Entorno de Migración y Carga Inicial

Productos

Anexos

• La disciplina Análisis y Diseño de RUP tiene como propósito:

• Transformar los requisitos en un diseño del sistema a crear.

• Definir una arquitectura robusta para el sistema.

• Adaptar el diseño para que funcione en el ambiente de implementación, diseñándolo para un desempeño

esperado.

Conclusión