INGENIERIA DE SOFTWARE

1
INGENIERIA DE SOFTWARE
UNT INGENIERIA INDUSTRIAL
Ing. Francisco Rodríguez Novoa
2
Tema 7 Modelo de Análisis y Diseño (I)

• Ing. Francisco Rodríguez

3
Rational Unified Process (RUP)
3
4

• AGENDA
• Análisis
• Artefactos de Análisis
• Trabajadores
• Actividades del Análisis

5

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

6

• 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
  sistema
• Especificar la interface con otros elementos
• Definir las restricciones a tener en cuenta
• Construir modelos útiles para
• Analista dominio de datos, funcional,
  comportamiento
• Diseñador diseño de datos, diseño
  arquitectónico, diseño de interfaz, diseño
  procedimental.

7

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

8
COMPARACION MODELO DE CASOS DE USO vs MODELO DE
ANALISIS
9
2.1. Modelo de Análisis
10

• 2.2. Clases de Análisis
• Representa una abstracción de una o varias clases
  y/o subsistemas del diseño del sistema
• Caracterí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.

11

• Clase de interfaz
• Clase de entidad
• Clase de control

12

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

13

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

14

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

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

16
(No Transcript)
17
Realización de un caso de uso-análisis

• Es una colaboración dentro del modelo de análisis
  que describe como se realiza un determinado caso
  de uso en términos de clases de análisis
  (control, entidad e interfaz) y sus objetos de
  análisis.
• Esta formado por
• Descripción textual de flujo de sucesos -
  análisis
• Diagrama de clases
• Diagramas de interacción

18
Realización de un caso de uso-análisis
Especificación del Caso de Uso del
Negocio Solicitar Servicio 1.Actores 1.1Artista 2
.Propósito Solicitar los servicios de la galería
para realizar una exposición de arte. 3.Breve
Descripción El caso de uso comienza cuando el
Artista se dirige a la galería para solicitar los
servicios para una exposición de arte. Se
entrevista con el Anfitrión quien le pide los
datos necesarios y llena la solicitud de servicio
de la galería. El caso de uso termina cuando el
Artista recibe una copia de la Solicitud de
Servicio o del Documento de Rechazo de
Pedido. 4.Flujo Básico de Eventos Acción del
Actor Respuesta del Proceso del Negocio 1.El
Artista solicita el servicio de para una
exposición 2.El Anfitrión solicita los datos
personales del Artista 3.El Artista entrega sus
datos personales al Anfitrión 4.El Anfitrión
busca si los datos del Artista están registrados
previamente en la galería 5.El Anfitrión solicita
información de las obras de arte al
Artista. 6.El Artista entrega la información de
las obras al Anfitrión 7.El Anfitrión registra la
información de las obras de arte. 8.El Anfitrión
busca la información sobre las técnicas que
maneja la galería en el sistema LogiSis 9.El
sistema LogiSis entrega la información sobre las
técnicas que maneja la galería. 10.El Anfitrión
recibe la información sobre las técnicas y
determina si la galería maneja las técnicas de
las obras de arte. 11.El Anfitrión llena la
solicitud de servicio. 12.El Anfitrión archiva
la Solicitud de Servicio y entrega una copia al
Artista 13.El artista recibe la copia de la
Solicitud de Servicio
19

• Diagramas de Interacción
• Los Diagramas de Interacción describen la
  interacción o intercambio de mensajes entre los
  objetos que participan en cada caso de uso.
• Existen dos tipos de Diagramas de Interacción.

Diagrama de Secuencia
Diagrama de Colaboración
20
Diagrama de Secuencia
Diagrama de Colaboración

• Describe el intercambio de mensajes ordenado en
  el tiempo.

Describe el intercambio de mensajes organizado
por los objetos participantes.
21
Diagrama de Colaboración

• Muestra la interacción de mensajes entre los
  objetos que participan en un caso de uso.
• Ordenados por los objetos participantes.
• Vista gráfica de la mecánica de interacción de
  los objetos a través del intercambio de mensajes
  de las clases a que pertenecen en un determinado
  escenario.

• Describe el intercambio de mensajes organizado
  por los objetos participantes.

22
Diagrama de Colaboración

• Está formado por.
• Objetos.
• Líneas de vida.
• Barra de tiempo.
• Mensaje.

• Describe el intercambio de mensajes organizado
  por los objetos participantes.

23
Ejemplo...
Confirmación de pedido
Gestor de Pedidos
Factura
IU Solicitud de Pago
Comprador
Solicitud de pago
Planificador de pagos
Diagrama de Clases de una realización del caso de
uso PAGAR FACTURA
24
...Ejemplo...
5 Obtener
4 Obtener
Confirmación de
pedido
Gestor de Pedidos
3 Comprobar facturas
2 Mostrar
1 Mostrar Facturas
Factura
6 Planificar pago de factura
9 establecer Estado(planificado)
7 Planificar pago
IU Solicitud de Pago
Comprador
8 Nuevo
Diagrama de Colaboración
Planificador de pagos
Solicitud de pago
25
Diagrama de Secuencia
26
Flujo de Trabajo del análisis
Análisis de la Arquitectura
Arquitecto
Analizar un caso de uso
Ingeniero de casos de uso
Ingeniero de componentes
Analizar un paquete
Analizar una clase
27
Análisis de la arquitectura
Modelo de casos de uso
Paquete del análisis (esbozo)
Arquitecto
Requisitos adicionales

• Identificación de paquetes de análisis
• Identificación de clases de entidad
• Identificación de requisitos especiales comunes

Clase del análisis (esbozo)
Modelo del Negocio (o modelo del dominio)
Descripci6n de la arquitectura (vista del
modelo de análisis)
Descripci6n de la arquitectura (vista del modelo
de casos de uso)
28
Analizar un caso de uso
Modelo de casos de uso
Ingeniero de casos de uso
Realización de caso de uso - análisis
Requisitos adicionales

• Identificación de clases del análisis
• Descripción de interacciones entre objetos del
  análisis
• Captura de requisitos especiales

Modelo del Negocio (o modelo del dominio)
Clase del análisis (esbozo)
Descripci6n de la arquitectura (vista del modelo
de casos de uso)
29
Analizar una clase
Ingeniero de componentes
Realización de caso de uso - análisis

• Identificar responsabilidades
• Identificación de atributos
• Identificación de asociaciones y agregaciones
• Identificaci6n de generalizaciones
• Captura de requisitos especiales

Clase del análisis (terminado)
Clase del análisis (esbozo)
30
(No Transcript)
31

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

32
41 vistas Modelo de arquitectura de software
33

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

34

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

35

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

36

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

37

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

38

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

39

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

40

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

41

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

42

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

43

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

44

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

45
DIAGRAMA DE CLASES
46
FIN