Universidad de Guayaquil

Facultad de Ciencias, Matemáticas y Física

Carrera de Ingeniera en Sistemas Computacionales

Tema
3.3 Interacción entre objetos: Diagrama de Secuencia
3.4 Documentos análisis de requerimientos

GRUPO #6
• Larriva Franco Guillermo Steven • Ochoa Bolaños Steven Joel
• Borbor Parrales Rommel Joel • Inga Zamora Darwin Rafael
• Contreras Sánchez Cristina Isabel • Coello Vera Anthony Felipe
• Redrobán Guamán Guilmar Isaac • Salinas Cruz Edison
Materia: Ingeniería de Software Orientada a Objetos
Curso: ISI-S-MA-5-1
2020-2021

Docente: ING. TANIA PERALTA G., MSc

 ¿Qué es un diagrama de secuencia?
El diagrama de secuencia UML representa los eventos en orden
cronológico, razón por la que a veces se le llama diagrama de eventos
o escenario de eventos. El orden (es decir, la secuencia exacta) es más
importante que los puntos específicos en el tiempo.

El diagrama de secuencia describe básicamente cómo los objetos (e

instancias) intercambian mensajes en un orden determinado.
 Características
 Muestra la secuencia de mensajes entre objetos durante un escenario concreto.
 Cada objeto viene dado por una barra vertical
 El tiempo transcurre de arriba abajo
 Las líneas de vida representan la existen de un objeto a lo largo de un periodo de
tiempo
 Los focos de control representan el periodo de tiempo durante el cual un objeto
ejecuta una acción.
Ventajas:

 Enfatiza el tiempo que indica el orden de los mensajes.

 Es útil para describir escenarios donde existe interacción con el

usuario.

Desventajas:

 El tiempo que se le da a cada mensaje no es el mismo al tiempo

real de ejecución.

 No muestra las relaciones que hay entre los objetos.

El diagrama de secuencia está construido a partir de dos dimensiones:

 Eje Horizontal: Representa los objetos que participan en la secuencia.

 Eje Vertical: Representa la línea de tiempo sobre la que los elementos

actúan.
Como identificar una clase, objeto y objeto de una clase.

 nombreObjeto: Un nombre seguido de un signo de dos puntos representa a

un objeto.
 :clase Un signo de dos puntos seguido de un nombre representa a una clase.
 nombreObjeto:clase Un nombre seguido de un signo de dos puntos y de
otro nombre, representa a un objeto en una clase.

NombreObjeto
:NombreClase NombreObjeto:Clase
:
 Mensaje
Se utiliza un mensaje en el diagrama de secuencia para
representar el paso de un mensaje entre dos objetos o entre un
objeto y sí mismo. Se representa utilizando una flecha que
incluye el nombre del mensaje y los argumentos que incluye y
que va desde el objeto que envía el mensaje hasta el objeto que lo
recibe.
Los mensajes se etiquetan mediante el uso de uno de los siguientes formatos:

1) El nombre del mensaje seguido de paréntesis vacíos: nombreMensaje().

2) El nombre del mensaje seguido de parámetros entre los paréntesis:
nombreMensaje(parámetro1, parámetro2 …).
3) El nombre del mensaje seguido del tipo de parámetro, nombre del parámetro y
cualquier valor predeterminado para el parámetro entre paréntesis:
nombreMensaje(tipoParámetro:nombreParámetro(valorPredeterminado).
Los tipos de los parámetros indican el tipo de datos, como cadena, número o fecha.
4) El mensaje puede ser un estereotipo tal como <<Crear>> para indicar que se va a
crear un nuevo objeto como resultado del mensaje.
Tipos de mensaje.
Mensaje Asincrónicos: Con los mensajes asincrónicos, el remitente
no espera una respuesta, sino que reanuda su comportamiento
inmediatamente.
Mensaje Síncrono: Los mensajes síncronos esperan una respuesta de la
operación antes de reanudar su comportamiento y se representan con una
flecha cuya punta está coloreada en negro.

Respuesta: Es aquella donde se esperar una respuesta de una determinada

acción, se representa por una flecha acotada con punta triangular negra.
 Foco de control

Los objetos contienen el denominado foco de control

que no es más que el tiempo en el que tal objeto está
llevando a cabo algún trabajo. Se representa mediante
un rectángulo superpuesto a la línea de vida
 Fragmento de interacción

Incluye todas las líneas de vida y mensajes necesarios. Como se ejemplifica

en la imagen inferior, dicho marco está representado por un rectángulo con
una etiqueta en la esquina superior izquierda, en la que se incluye la
abreviatura sd, propia de un diagrama de secuencia, y normalmente
resaltada en negrita, y el nombre de la interacción.
Cada uno de los cuadros representa un fragmento de interacción. La etiqueta “ref”
representa un fragmento de ocurrencia de interacción. Se pueden combinar diferentes
fragmentos, que van a requerir una u otra etiqueta dependiendo del operador de
interacción. El fragmento inferior es un fragmento combinado con el operador de
interacción “Alternativa”.
Un fragmento combinado con el operador de interacción “loop” repite su
operando. La condición de guarda determina el número exacto de
ejecuciones.
EJEMPLO
 Documentos análisis de requerimientos

Estándar IEEE 830

IEEE significa (Institute of Electrical and Electronics Engineers, en español
significa Instituto de Ingenieros Eléctricos y Electrónicos pero también le llaman
comúnmente la I triple E).

El estándar IEEE 830 se conoce como el documento de especificación de

requerimientos de software y comprende un listado de los requerimientos y del
contexto de la solución, así como una descripción general del diseño por medio de
los casos de uso y los escenarios.
Quién la puede usar:

 Un cliente/usuario que vaya a definir requerimientos (características) de

un software que necesite
 Un desarrollador (interno/externo) que haga software “a la medida”
mediante proyecto
 Un desarrollador que haga software “de paquete” que se venda
masivamente
IEEE 830 sirve para que...

 Un cliente describa claramente lo que quiere

 Un proveedor entienda claramente lo que el cliente quiere
 Se establezcan bases para un contrato de desarrollo (o de compra-venta)
 Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-
trabajos)
 Se tenga una base o referencia para validar o probar el software solicitado
 Se facilite el traspaso del software a otros clientes/usuarios
 Se le puedan hacer mejoras (o innovaciones) a ese software
Partes que lo componen
1. Introducción
1.1. Propósitos: Se definirá el propósito del software, a quien va dirigido

1.2. Ámbito del sistema: Nombre del sistema y se explica lo que el sistema
hará, se describirá los objetivos, beneficios y metas, se referenciaran las
políticas que el cliente haya establecido

1.3. Personal involucrado: Nombres de las personas que se involucran en

el proyecto (Ya se hizo, solo se copia)

1.4. Definiciones, acrónimos y abreviaturas

1.5. Referencias: bibliografía

1.6. Visión general de documento o Resumen: Describir en que consiste

las secciones que siguen brevemente
 2. Descripción general

En esta sección se describe todos los factores que afectan al producto y a sus
requisitos por ejemplo clientes, usuarios, lenguaje de programación.

2.1. Perspectiva del producto: relación del producto con otros ya existentes, en
caso de que sea único describir generalmente lo que hará el sistema.

2.2. Funciones del producto: Se mostrará un resumen de las funciones del

sistema, se podrá realizar gráficos siempre y cuando este demuestre las
relaciones de sus funciones mas no el diseño del sistema.

2.3. Características de los usuarios: aquí se mostrará las características

generales de los usuarios del producto, incluyendo nivel educacional, experiencia
técnica. (En una tabla)
2.4. Restricciones: se describirá las limitaciones que se impone sobre los
desarrolladores del producto, tomar en cuenta políticas de la empresa,
limitaciones del hardware, interfaces con otras aplicaciones, lenguaje de
programación, requisitos de habilidad

2.5. Suposiciones y dependencias: factores que si cambian afectan a los

requisitos, por ejemplo: sistema operativo, velocidad de internet, cambio de
usuarios.

2.6. Futuros requisitos: Esta subsección esbozara futuras mejoras al sistema,

que podrán analizarse e implementarse en un futuro.
3. Requisitos específicos

Esta sección contiene los requisitos a un nivel de detalle suficiente

como para permitir a los diseñadores diseñar un sistema que
satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema
satisface, o no, los requisitos. Todo requisito aquí especificado
describirá comportamientos externos del sistema, perceptibles por
parte de los usuarios, operadores y otros sistemas.
3.1. Interfaces Externas
Se describirán los requisitos que afecten a la interfaz de usuario,
interfaz con otros sistemas (hardware y software) e interfaces de
comunicaciones.
• 3.1.1 interfaz con el usuario
• 3.1.2 interfaz con el hardware
• 3.1.3 interfaz con el software
• 3.1.4 interfaces de comunicaciones
3.2. Funciones
Esta subsección (quizá la mas larga del documento) deberá
especificar todas aquellas acciones (funciones) que deberá llevar a
cabo el software.

3.2.1 Requerimientos funcionales: se expresa el funcionamiento del sistema,

es decir como interactúa el sistema con su entorno y cuál será su estado, deben
de estar redactados de manera comprensibles para los usuarios, sin ningún dato
técnico.
3.2.2. Requerimientos no funcionales: Representan características generales y
restricciones de la aplicación o sistema que se este desarrollando es decir definen
como debe ser el sistema. Por ejemplo: un requerimiento funcional de un sistema
de ventas sería el rendimiento ya que este debe contar con una alta fiabilidad y un
rápido tiempo de respuesta.
3.3. Requisitos de Rendimiento
Se detallaran los requisitos relacionados con la carga que se espera tenga que soportar el
sistema. Por ejemplo, el numero de terminales, el numero esperado de usuarios
simultáneamente conectados, numero de transacciones por segundo que deberá soportar el
sistema, etc.

3.4. Restricciones de Diseño

Todo aquello que restrinja las decisiones relativas al diseño de la aplicación:
Restricciones de otros estándares, limitaciones del hardware, etc.
3.5. Atributos del Sistema
Se detallaran los atributos de calidad del sistema: Fiabilidad, mantenibilidad,
portabilidad, y, muy importante, la seguridad. Deberá especificarse que tipos
de usuario están autorizados, o no, a realizar ciertas tareas, y como se
implementaran los mecanismos de seguridad (por ejemplo, por medio de un
login y una password).

3.6. Otros Requisitos

Cualquier otro requisito que no encaje en otra sección.
4. Apéndices
Pueden contener todo tipo de información relevante para la
ERS(especificación de requisitos de software) pero que, propiamente, no
forme parte de la ERS. Por ejemplo:
1. Formatos de entrada/salida de datos, por pantalla o en listados.
2. Resultados de análisis de costes.
3. Restricciones acerca del lenguaje de programación.
Bibliografía
• IONOS. (04 de 03 de 2019). Obtenido de https://www.ionos.es/digitalguide/paginas-
web/desarrollo-web/diagramas-de-secuencia/
• manuel.cillero.es. (s.f.). Obtenido de
https://manuel.cillero.es/doc/metrica-3/tecnicas/diagrama-de-interaccion/diagrama-
de-secuencia/
• Santos, L. (s.f.). slideplayer. Obtenido de https://slideplayer.es/slide/16940919/
• Gomez, M. d. (2011). Obtenido de
http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf
Cual de los siguientes es un mensaje Síncrono
Cual de los siguientes es un mensaje Síncrono

RESPUESTA
Los diagramas de secuencias
esta compuesto por dos
dimensión, cuales son y defina
uno de ellos?
Los diagramas de secuencias esta
compuesto por dos dimensión, cuales
son y defina uno de ellos?
 Eje Horizontal: Representa los objetos que
participan en la secuencia.

 Eje Vertical: Representa la línea de tiempo

sobre la que los elementos actúan.
Como se domina al rectángulo superpuesto en la línea de vida?
 Como se domina al rectángulo superpuesto en la línea de vida?

RESPUESTA: FOCO DE CONTROL

Que significa IEEE en español?
 Que significa IEEE en español?

Respuesta: Instituto de Ingenieros Eléctricos y Electrónicos

GRACIAS 