Tema III. Análisis.

En la etapa de captura de requisitos, se generan casos de uso que
permiten representar las funciones del sistema desde la perspectiva
del usuario.
Sin embargo, se ignoran detalles del software, por la necesidad de
simplificar el modelo de casos de uso.
La fase de análisis consiste en detallar los requerimientos desde la
perspectiva de los desarrolladores y ataca la estructura interna del
sistema. Es decir, se refinan los requisitos.

1. Análisis de los requerimientos detallados
Esta fase, propuesta por el Proceso Unificado de Desarrollo de
Software, tiene las siguientes características:
Descrito con el lenguaje del desarrollador
Provee la vista interna del sistema
Estructurado por clases y paquetes
Es utilizado por los desarrolladores como base para diseñar e
implantar
No debe contener redundancias, inconsistencias entre requisitos
Esboza la funcionalidad del sistema, incluyendo la arquitectura
Define realizaciones de casos de uso

2. Artefactos
2.1 Modelo de análisis
Un modelo que describe la realización de casos de uso, clases de
análisis y paquetes de análisis y sirve como una abstracción.
Tambien es conocido como el modelo conceptual.
Figura 1

2.2 Clase de análisis
Representa un concepto o entidad que tiene responsabilidades y
comportamiento dentro del sistema.
Una clase de análisis queda definida a partir del dominio del problema.
Una clase de análisis. puede ser de tres tipos o estereotipos
2.2.1 Clase de Interfaz
Las clases de interfaz se utilizan para modelar la interacción entre
el sistema y sus actores, que consiste en recibir y presentar
información.
Una clase de interfaz interactua con un usuario o un programa externo,
ya sea un GUI o un API.
Figura 2
2.2.2 Clase de Entidad.
Es una clase que es usada para modelar información y comportamiento
asociado que debe tener una vida larga y a menudo persistente.
Figura 3
2.2.3 Clase de Control.
Modela la coordinación, secuencia, transacciones y control de otros
objetos y representa el flujo de uno o mas casos de uso.
Figura 4

2.3 Realización de caso de uso-análisis.

Describe como se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis , objetos e interacciones.

La realización de un casos posee una descripción textul del flujo de sucesos, diagramas de clase de análisis y diagramas de interacción

Un diagrama de clases muestra las relaciones entra las diferentes clases de análisis,

Un diagrama de interacción indica la secuencia de acciones que sigue un caso de uso, desde que interviene el actor y los mensajes que fluyen entre los distintos objetos de
análisis. Siempre se recomienda poner una descripcion que explique el diagrama de interacción
Figura 5


2.4 Paquete de análisis.

Permiten organizar los artefactos del modelo de análisis en partes modulares.
Consta de cero o mas clases de análisis, realizaciones de caso de uso y de otros paquetes.

Un sistema puede ofrecer servicios. Un servicio es un conjunto de clases relacionadas
funcionalmente que se utilizan en varios casos de uso. Tipicamente un servicio queda
provisto por varias clases de interfaz, de entidad y de control.

Figura 6

2.5 Vista del model de análisis.

Al organizar cada uno de los artefactos de análisis, las clases y paquetes empiezan a tomar una estructura modular y con piezas bien definidas.

Una arquitectura muestra la manera de construir el sistema para que pueda cumplir sus objetivos.

Un enfoque que permita utilizar patrones de análisis, permite obtener una arquitectura flexible y modular.

El artefacto resultante es la descripción de la arquitectura

3. Trabajadores

El arquitecto es responsable de llevar la coherencia del model de análisis y de entregar la descripción de la arquitectura

El ingeniero de casos de uso se encarga de analizar los casos de uso y realizarlos.

El ingeniero de componentes define las clases de análisis y las separa en paquetes

Figura 7

4. Flujo de Trabajo

Figura 8

4.1 Análisis de la arquitectura.
Los paquetes de análisis permite organizar el modelo de análisis en piezas pequeñas y
manejables.
Tomando los casos de uso, se puede asignar la mayor parte de los casos de uso a un
conjunto de paquetes.
Teniendo un conjunto de paquetes, es posible definir dependencias entre ellos.
Al establecer una estructura entre los paquetes identificados, es posible encontrar una
arquitectura del sistema.
Al establecer la arquitectura, se pueden identificar algunas clases de entidad obvias.
Tipicamente, existen varias maneras de atacar la descripción de la arquitectura.
+ Trabajando con una lista de categorias de conceptos, que son obtenidos de la lectura
de los requerimientos, casos de uso y diccionario de datos
+ Un análisis de palabras presentes en los casos de uso, diccionario de datos y obtener
conceptos
+ Patrones de análisis, que son catálogos de modelos conceptuales en dominios de problemas
ya existentes.

Figura 9

4.2 Analizar un caso de uso.
De los casos de uso disponibles en el modelo de casos de uso, por cada uno de ellos se debe:

4.2.1 Identificar las clases del análisis cuyos objetos son necesarios para llevar a cabo
el flujo de sucesos del caso de uso.
Las clases de entidad se identifican al estudiar a detalle la descripción del caso de uso
y de cualquier modelo del dominio que se tenga.
Por cada actor humano se identifica una clase de interfaz, que representa la interfaz
de usuario.
Por cada clase de entidad tratar de establecer su análogo en clase de interfaz, para
permitir que los usuarios tengan manera de interactuar con las clases de entidad.
Si existen actores externos (no humanos), que pueden ser sistemas externos; se pueden
plantear clases de interfaz que están integradas con protocolos de comunicación.
Se asigna a una o mas clases de control la capacidad de llevar el flujo de sucesos del
caso de uso.
4.2.2 Descripción de interacciones entre objetos del análisis.
Dadas las clases que permiten realizar el caso de uso, se debe dar una descripción de como
interactuan entre sí.
Para este tipo de descripción, se utiliza un diagrama de colaboración de UML.
Un diagrama de colaboración muestra los enlaces que existen entre los objetos de
análisis y los mensajes que fluyen entre ellos.
Figura 10

Con la descripción de interacciones, es posible dar una realización de un caso de uso desde
el punto de vista de análisis, lo que permite completar un análisis de los requerimientos.

Figura 11

4.3 Analizar una clase.
En los pasos anteriores se obtuvieron esbozos de clases de análisis. Sin embargo, es necesario
entenderlas por completo y dejar una descripción clara de las mismas
4.3.1 Identificar responsabilidades.
Una clase de análisis cumple con varios papeles en diferentes realizaciones de caso de uso.
La asignación de cada responsabilidad se debe dar en este paso.
4.3.2 Identificar atributos.
Un atributo es valor lógico de un dato que contiene un objeto.
A este nivel, los atributos asignados deben tener un tipo de dato a nivel de análisis
(en lugar de decir que es de tipo flotante o entero, indicarlo como numero o cantidad)
Las clases de tipo entidad tienen atributos que muestran la información que se necesita
guardar. Las clases de tipo interfaz tienen atributos que indican las entradas básicas
de la interfaz de usuario con el actor humano,
4.3.3 Identificar asociaciones y agregaciones.
Una asociación permite modelar conceptos que deben establecer una actividad entre ambos y
por ende necesitan conocerse para poder colaborar. Tipicamente una asociación tienen
multiplicidad
Una agregación sirve para modelar conceptos que se contienen fisicamente uno al otro,
o que están compuestos uno de otro o que forman una colección conceptual de objetos.
4.3.4 Identificar generalizaciones.
Si varias clases, desde la perspectiva del concepto coinciden, deben factorizarse en una
clase que tenga los atributos y comportamientos comunes.

Figura 12

4.4 Analizar un paquete.
Al obtener un detalle de las clases, los paquetes quedan mejor definidos dentro del modelo
de análisis.
Con esto se debe garantizar que un paquete realiza uno o mas casos de uso y que los
paquetes son independientes entre sí y describir las dependencias para estimar el efecto
de los cambios futuros.
El análisis de un paquete consiste en definir y mantener las dependencias con otros paquetes,
checar que los paquetes contienen las clases correctas.

Figura 13

5. Patrones de Análisis.
Un patrón es una organización general de conceptos que se puede adaptar a solucionar
distintos problemas.
En el caso de patrones de análisis, estamos hablando de un conjunto de modelos de Análisis
o Conceptuales reconocidos y generales, que pueden ser utilizados para atacar cualquier tipo
de sistemas.

Los patrones de Análisis o Conceptuales reconocidos son:
(segun Martin Fowler en su libro de Analysis Patterns):
5.1 Modelos de responsabilidad
El concepto de responsabilidad aplica cuando una persona u organización es responsable de otra. Se pueden modelar estructuras organizacionales, contractos y empleos.
5.1.1 Parte.
Problema: Personas y unidades organizaciones tienen responsabilidades similares.
Motivación:
Sea el siguiente diagrama de clases, que muestra un libro de direcciones.
Fig. 14
El problema es que la clase Persona y Empresa tienen el mismo tipo de relaciones con las otras clases, es factible encontrar una generalización
Solución: Se crea un supertipo, que se denomina Parte, del cual toman características las clases Persona y Organización. Dicha clase se relaciona con las demas clases, y por consecuencia, los descendientes adquieren dichas relaciones.
Fig. 15
Ejemplo:
En la Universidad La Salle, las siguientes entidades son partes: Prof. Gustavo De la Cruz Tovar, Secretaria
de Ingeniería, Escuela de Ingeniería, Director de Ingeniería, Rector
5.1.2 Jerarquías de organización.
Problema: Representar una estructura de jerarquía de organización
Motivación:
Considerando una organización empresarial multinacional. America Online tiene unidades operacionales, la cuales
están divididas en regiones, la cuales se dividen en divisiones las cuales se dividen en oficinas de ventas.
El siguiente diagrama muestra este concepto.
Fig. 16
En caso de que las Regiones salieran de este modelo, este queda alterado completamente.
Solución:
Crear una asociación recursiva sobre un supertipo denominado Organización. Dicho supertipo es un subsidiario que tiene una jerarquía con un pariente, de tipo Organización también.
Los conceptos Region, Division, Unidad Operativa y Oficina de Ventas son subtipos de Organización
y tienen restricciones sobre la relación que tienen con el pariente. En caso de que sufra un
cambio en un componente de la jerarquía, se cambia la restricción en el componente afectado y
no en todo el modelo.
Fig. 17
Ejemplo:
Existe el concepto de Universidad La Salle, la cual tiene en varios Paises, que a su vez tiene Regiones,
Campus y Escuelas. Si se tuviera que desaparecer el concepto de Regiones, se cambia la restricción, de tal
manera que Campus tiene como pariente directo a Paises.
5.1.3 Responsabilidad.
Problema: Representar estructuras organizacionales, empleos, administración y contratos con estructuras
similares.
Motivación:
Como es posible modelar la relación de una organización que tiene relación con otra por un periodo de tiempo y acorde a una regla definida ?
Solución:
Crear responsabilidades como un relación directa entre dos Partes. Dar un tipo de responsabilidad para
representar una clase de relación
Fig. 18
Ejemplo:
Juan Perez trabaja para IBM. Esto se puede modelar como una responsabilidad cuya comisión es IBM, la parte responsable es Juan Perez y el tipo de responsabilidad es empleado.
5.2 Modelos de observación y medidas
Los sistemas de cómputo registran información acerca de objetos del mundo real. La manera como se representan las observaciones y medidas para lograr un modelo de análisis flexible, es atacada por esta familia de patrones
5.2.1 Cantidad.
Problema: Representar valores tales como 6 metros o 5 pesos.
Motivación: Como representar la altura o edad de una persona ? Algunos dirian que como un entero, otros un
flotante, otros hasta cadenas de caracteres. Muchas veces se introducen los valores y unidades, mezclados. Se puede perder información del mundo con esta aproximación.
Fig. 19
Solución:
Usar un tipo de dato o clase que incluya cantidad y unidad. Definir los atributos de información a partir de estos nuevos tipos de datos. Indicar operaciones sobre la cantidad
Fig. 20
Ejemplo: 80 pesos se pueden representar como cantidades, con un valor de 80 y unidad de pesos mexicanos 5.2.2 Cociente de conversión.
Problema: Convertir entre cantidades de diferentes unidades
Solución: Definir Cociente de conversión entre unidades, de la siguiente manera:
Fig. 21
5.2.3 Unidades Compuestas.
Problema: Representar unidades tales como m/s.
Motivación: Las unidades compuestas son definidas tipicamente en una cadena de caracteres. Cuando se necesita operar entre unidades compuestas que tienen conversión, se debe aplicar un análisis a la cadena para poder aplicar la operación.
Solución: Usar una unidad que es combinación de otras unidades
+ Modelos para identificar objetos
+ Modelos para inventarios y contabilidad
+ Modelos para planeación
+ Modelos de intercambios de bienes
+ Modelos de arquitecturas en capas

6. Especificaciones matemáticas formales