Este documento describe el proceso de análisis en el desarrollo de software unificado (UP). Explica los flujos de trabajo de requisitos y análisis, y describe conceptos clave como las clases de análisis, la identificación de paquetes y la realización de casos de uso.

1. Parte 1.2.2
Proceso de Desarrollo Unificado
FLUJOS DE TRABAJO – UP
- Flujo de Requisitos
- Flujo de Análisis
Material académico preparado por:
Ph.D, Marta Silvia Tabares B.
Fecha última actualización 4-Sep-2011

2. Ingeniería de Software II
(mapa conceptual de tópicos de conocimiento)
Material Preparado por MARTA SILVIA TABARES B. UdeM

3. Bibliografía
• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.
• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and
Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John
Wiley & Sons © 2005.
• Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo
de Software. Adisson Wesley. 2001.
• Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented
Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.
• OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07-
04. 2005.
• Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos
del Sistema, Usando UML. McGraw-Hill, 2006.
Material Preparado por MARTA SILVIA TABARES B. UdeM

4. Clases de Análisis
• Debe presentar un conjunto de atributos de muy alto nivel.
• Las operaciones especifican, en un alto nivel, los servicios claves que la
clase debe ofrecer.
• La información mínima que una clase de análisis debe tener es:
– Nombre (obligatorio)
– Atributos (nombre: obligatorio, tipo: opcional)
– Operaciones (de muy alto nivel; parámetros y tipos de retorno solo se
muestran donde el analista considere importante para entender el modelo)
– Visibilidad (generalmente no se muestra)
– Estereotipos (se pueden mostrar si ellos mejoran el modelo)
– Tagged values (se pueden mostrar si ellos mejoran el modelo)
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

5. Clases de Análisis:
Reglas de Creación
• De tres a cinco responsabilidades por clase: las clases deben ser lo más simples que se
pueda es decir se deben limitar el número de responsabilidades que ellas pueden soportar
(una responsabilidad es un servicio (contrato) que una clase ofrece a otras).
• No hay clases solas: una clase colabora con otra para entregar beneficios al usuario.
• Cuidado con clases muy pequeñas.
• Cuidado con clases muy grandes.
• Cuidado con la funcionalititis
• Cuidado con las clases omnipotentes.
• Evitar profundidad en los árboles de herencia.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

6. Clases de Análisis:
Identificación por el Método CRC
• CRC: Clases, Responsabilidades, y
Colaboradores.
• Procedimiento CRC
– Fase I: Reunir la información Ejemplo:
– Fase II: Análisis de la Información Nombre de la Clase:
BankAccount
Responsabilidades: Colaboradores:
Mantener el balance Bank
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

7. Clases de Análisis
Estereotipo Ícono Semántica
<<boundary>> Clase que media la interacción entre el sistema y
su ambiente
<<control>> Clase que encapsula comportamiento del la
especificación del caso de uso
<<entity>> Clase que se usa para modelar la persistencia de
la información
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

8. Clases de Análisis
Ejemplo
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

9. <<boundary>> Class:
Clase de Interfaz
• Este tipo de clase se utiliza para modelar la interacción entre el
sistema y sus actores (usuarios y sistemas externos). La
interacción significa que recibe y presenta información, así como
peticiones hacia los actores.
• Esta clase modela las partes del sistema que dependen de sus
actores, lo cual implica que clarifican y reúnen los requisitos en
los límites del sistema. Así, un cambio en la interfaz de usuario o
en una interfaz de comunicaciones queda aislado en una o más
clases de interfaz.
• Cada comunicación entre un actor y un caso de uso en el modelo de
casos de uso, debe ser activado como un objeto en el sistema. Dichos
objetos son instancias de una clase <<boundary>>. Así es posible
definir que tipo de clase <<boundary>> es indicada para saber qué
actor representa.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

10. <<boundary>> Class:
Clase de Interfaz
• La clase existe en los límites del sistema y se comunica con actores
externos.
• Tipos de clases <<boundary>>
– Interfaces de usuario: clases que sirven como interfaz (punto de contacto) entre
el sistema y los humanos (Interfaces tipo GUI).
– Interfaces del sistema: clases que sirven de interfaz con otros sistemas.
– Interfaces con dispositivos: clases que sirven de interfaz con dispositivos externos
tales como un sensor.
La Clase Interfaz Solicitud de Productos (GUI)
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

11. <<entity>> class:
Clase de Entidad
• Modelan la INFORMACIÓN que posee una vida larga.
• Modelan la información y el comportamiento asociado de algún fenómeno o
concepto, como una Persona, un Objeto del mundo real, o un Suceso del
mundo real.
• Características:
– Cruzan muchos casos de uso
– Proporcionan y Aceptan Información de las clases <<boundary>>
– Representan cosas claves gestionadas por el sistema (p.ej. Cliente).
• Son PERSISTENTES.
• Las clases <<entity>> expresan la estructura de datos lógica del sistema.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

12. <<entity>> class:
Clase de Entidad
• En el siguiente ejemplo, la clase de entidad, Producto, se
utiliza para representar los productos que el vendedor
gestiona. La clase de entidad se asocia con la clase de
interfaz, Solicitud de Productos, por medio de la cual el
usuario administra los productos.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

13. <<control>> Class:
Clase de Control
• Este tipo de clase representa Coordinación, Secuencia,
Transacción, y Control de otros objetos y se usa con
frecuencia para encapsular de un caso de uso.
• Las instancias de las Clases Controladoras controlan el
sistema que corresponde a uno o más casos de uso.
• Los aspectos dinámicos del sistema se modelan en clases
de control ya que ellos coordinan las acciones y los flujos
de control básicos (CU) y delegan trabajo a otros
(interfaces, entidades).
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

14. <<control>> Class:
Clase de Control
• En el siguiente ejemplo, Controlador de Inventario,
acepta una Solicitud de Productos, para crear el
inventario de los Productos a una fecha determinada.
Más adelante, el controlador de inventario lleva a cabo
actualizaciones del producto cuando se realice una venta.
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

15. Realización de Casos de Uso (Análisis)
• Una Realización de Casos de Uso es una colaboración dentro del
modelo de análisis que describe cómo se lleva a cabo y se ejecuta un
caso de uso determinado en términos de las clases del análisis y de
sus objetos del análisis en interacción [3].
Modelo de Casos de Uso Modelo de Análisis
• Una Realización de Casos de Uso implica la identificación de un
posible conjunto de clases, junto con un conocimiento de cómo
podrían interactuar esas clases para ofrecer una funcionalidad del
caso de uso [5].
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

16. Realización de Casos de Uso (Análisis)
El desarrollo de un modelo o elemento
abstracto para pasar a otro modelo
que esté más cerca de la ejecución se
conoce como Realización.
El conjunto de clases que participan
en una realización se conoce como
una Colaboración.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

17. Realización de Casos de Uso:
Colaboraciones
• La colaboración Hacer Préstamo muestra los elementos
que interactuarán cuando se ejecuten como software, de tal forma
que consigan el resultado descrito en el caso de uso Hacer
Préstamo.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

18. Interacción del Análisis:
DIAGRAMA DE COMUNICACIONES
• Un diagrama de comunicaciones constituye una vista del
detalle interno de una colaboración ya que muestra la
interacción entre los objetos
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

19. Interacción del Análisis:
DIAGRAMA DE SECUENCIA (1)
Envía Mensaje Recibe Mensaje
Inicio de Ocurrencia de Ejecución
Ocurrencia de Ejecución
Una línea de Vida
representa la forma
como un objeto Fin de Ocurrencia de Ejecución
interactúa con otros
objetos del sistema.
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

20. Interacción del Análisis:
DIAGRAMA DE SECUENCIA (2)
Fragmentos de operatividad de una interacción
El fragmento Alternative (denotado “alt”)
modela estructuras if…then…else.
El fragmento Loop incluye una serie de
mensajes que están repetidos.
El fragmento Option (denotado “opt”) modela
estructuras switch.
Una ocurrencia de interacción es una referencia a otro diagrama que tiene
la palabra “ref” en la esquina izquierda arriba del marco, y tiene el nombre
del diagrama referenciado que se muestra en el medio del marco
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

21. Interacción del Análisis:
DIAGRAMA DE SECUENCIA (3)
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

22. Realización de Casos de Uso (Análisis):
Relación entre diferentes diagramas
<<trace>>
Estructura:
Diagrama de Clases
Interacción:
Material Preparado por MARTA SILVIA TABARES B. UdeM
Flujo de Análisis UP Diagrama de Comunicación

23. Análisis de la Arquitectura
• Qué es una arquitectura de Software?
– Es una forma coherente de establecer los patrones y abstracciones para
que los analistas y desarrolladores trabajen en una línea común hacia la
implementación del sistema de información.
– Una arquitectura sigue un patrón o un conjunto de patrones que
proporcionan un marco de referencia para lograr la funcional requerida
por el cliente, y otros objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de información.
• El análisis de la arquitectura se hace por medio de la identificación de
paquetes del análisis, clases representativas, y requisitos no
funcionales.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

24. Análisis de la Arquitectura:
Identificación de paquetes (1)
• Los paquetes del análisis proporcionan un medio para
organizar el modelo de análisis de acuerdo a los objetivos del
sistema a desarrollar (descomposición por objetivos o
subobjetivos funcionales del sistema).
• Paquetes de Análisis:
– Comúnmente, se agrupan los casos de uso o elementos de modelo
(clases del dominio) que cumplen con un objetivo específico del
sistema, o dan soporte a determinado proceso del negocio, o dan
soporte a determinado actor del sistema.
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

25. Análisis de la Arquitectura:
Identificación de paquetes (2)
• En el sistema de Biblioteca se han identificado tres paquetes de acuerdo a
los objetivos del sistema:
– Gestión de Compra de Material Bibliográfico.
– Gestión de Catalogación del Material Bibliográfico.
– Gestión de Préstamo del Material Bibliográfico
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

26. Análisis de la Arquitectura:
Identificación de paquetes (3)
• Paquetes de Servicios:
– Están constituidos por clases de análisis que contribuyen a un servicio determinado del
sistema (clases relacionadas funcionalmente). Cada paquete de servicio podría ser
identificado por cada uno de los servicios proporcionados clases relacionadas funcionalmente
(responsabilidades CRC).
– Por ejemplo, en el paquete de Gestionar Préstamos de Material Bibliográfico, podemos
encontrar dos servicios: Préstamos y Multas.
Flujo de Análisis UP
Material Preparado por MARTA SILVIA TABARES B. UdeM

27. Análisis de la Arquitectura:
Identificación de paquetes (4)
• Paquetes por capas del sistema:
– Orientados hacia una arquitectura por capas operativas del
sistema, es posible identificar tres tipos generales de
paquetes (para análisis bajo el patrón Modelo-Vista-
Control):
• Paquetes de Presentación: Agrupa todas las clases tipo interfaz.
• Paquetes de Control: Agrupa todas las clase de control o paquetes
de servicio.
• Paquetes de Almacenamiento o Base de Datos: Agrupa todos las
clases tipo entidad como un modelo de clases para la
implementación en bases de datos.
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

28. Análisis de la Arquitectura:
Identificación de paquetes (5)
Capa de Presentación (Vista)
Dependencia entre
Paquetes
Capa de Control (Control)
Capa de Almacenamiento (Modelo)
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

29. Paquetes: Visibilidad
Material Preparado por MARTA SILVIA
Flujo de Análisis UP
TABARES B. UdeM

30. Relaciones entre Paquetes
Un elemento en el paquete Cliente usa un elemento
público del paquete Proveedor de alguna forma. El
cliente depende del proveedor.
Elementos públicos del espacio nombrado del
Proveedor son adicionados como elementos públicos
al espacio nombrado del Cliente.
Elementos públicos del espacio nombrado del
Proveedor son adicionados como elementos privados
al espacio nombrado del Cliente.
Elementos públicos del paquete Proveedor son
combinados con elementos paquete Cliente.
<<trace>> normalmente representa el desarrollo
histórico de un elemento en otro en una versión más
desarrollada. Esto se da más en relaciones entre
MODELOS que en relaciones entre elementos de
modelo.
Símbolo que identifica un MODELO
Material Preparado por MARTA SILVIA
TABARES B. UdeM

31. Análisis de la Arquitectura:
Dependencia entre paquetes
• A partir de paquetes relativamente independientes,
débilmente acoplados y con una cohesión internamente
alta (como los paquetes por capas del sistema), el objetivo
de hacer relaciones entre los paquetes es mantener la
relación funcional entre los diferentes elementos de
modelo y facilitar la mantenibilidad del sistema.
• La dependencia se formaliza por medio de las relaciones
de dependencia entre paquetes: <<use>>, <<import>>,
<<access>>, y <<merge>>.
Material Preparado por MARTA SILVIA
TABARES B. UdeM

32. Arquitecturas de Software
• Continuar el estudio de este capítulo con la presentación:
ARQUITECTURAS DE SOFTWARE
Material Preparado por MARTA SILVIA
TABARES B. UdeM