i

UNIVERSIDAD PARA EL DESARROLLO ANDINO

Anti hatun yachay wasi, iskay simi yachachiypi umalliq
FACULTAD DE CIENCIAS E INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

TEMA

MODELADO DE LOS REQUERIMIENTOS:

ESCENARIOS, INFORMACIÓN Y CLASES DE ANÁLISIS

Curso
CALIDAD DE LOS SISTEMAS DE INFOMACIÓN

Cátedra
Mg. BENDEZÚ URETA, Rolando Yossef

Presentado por
ANDREO TAIPE LLANCARI

Ciclo: X

Lircay – Angaraes – Huancavelica – Perú

2019
 ii

DEDICATORIA

Dedico a Dios y a mis padres

gracias por todo cariño, compresión y
confianza que me dan día a día para
salir adelante con este proceso de mi
formación académica.
 iii

ÍNDICE
DEDICATORIA .................................................................................................................... ii

INTRODUCCIÓN ................................................................................................................. 4

MODELADO DE LOS REQUERIMIENTOS: ESCENARIOS, INFORMACIÓN Y

CLASES DE ANÁLISIS ........................................................................................................... 5

ENFOQUE GENERAL ......................................................................................................... 5

1. ANÁLISIS DE LOS REQUERIMIENTOS ............................................................ 6

1.1. Objetivos y Filosofía General ........................................................................... 7

1.2. Reglas Practicas del Análisis ............................................................................ 7

1.3. Análisis del Dominio ........................................................................................ 8

1.4. Enfoques del Modelado de Requerimientos ..................................................... 9

2. MODELO BASADOS EN ESCENARIOS ............................................................. 9

2.1. Creación de un Caso de Preliminar de Uso ...................................................... 9

2.2. Mejora de un Caso de uso Preliminar ............................................................. 12

2.3. Estructura de un Caso Formal ........................................................................ 12

3. MODELOS UML QUE PROPORCIONAN EL CASO DE USO ........................ 14

3.1. Desarrollo de un Diagrama de Actividades .................................................... 14

3.2. Diagramas de Canal (swimlane) ..................................................................... 14

4. CONCEPTOS DE MODELADO DE DATO........................................................ 14

4.1. Objetos de Datos ............................................................................................. 14

4.2. Atributos de los Datos .................................................................................... 14

4.3. Relaciones ....................................................................................................... 14

5. MODELADO BASADO EN CLASE ................................................................... 14

CONCLUSIONES ............................................................................................................... 16

REFERENCIAS BIBLIOGRÁFICAS ................................................................................ 17

 4

INTRODUCCIÓN
El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla
de formatos en texto y diagramas para representar los requisitos del software, las funciones y
el comportamiento. De esta manera se hace mucho más fácil de comprender dicha
representación, ya que es posible examinar los requisitos desde diferentes puntos de vista
aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se
descubran descuidos.

Además, el modelo de análisis se complementa de cuatro elementos fundamentales. Estos

elementos sirven para clasificar principalmente los diferentes diagramas y otros derivados
conocidos en plataformas como sistemas de información e ingeniería de software entre otros.
Además, estos con clasificados en elementos de escenario, elementos de flujo, elementos de
clases y elementos de comportamiento.
 5

MODELADO DE LOS REQUERIMIENTOS: ESCENARIOS, INFORMACIÓN Y

CLASES DE ANÁLISIS
En el nivel técnico, la ingeniería de software comienza con una serie de tareas de modelado
que conducen a la especificación de los requerimientos y a la representación de un diseño del
software que se va a elaborar. El modelo de requerimientos - un conjunto de modelos, en
realidad es la primera representación técnica de un sistema (Pressman, 2010).

ENFOQUE GENERAL
¿Qué es?

Es la forma relativamente fácil para entender y revisar los requerimientos del software para
corregir, completar y adecuarlo de manera cómo sea conveniente, utilizando una combinación
de texto y diagramas para ilustrarlos.

¿Quién lo hace?

Un ingeniero de software (a veces llamado “analista”) construye el modelo con el uso de los
requerimientos recabados del cliente.

¿Por qué es importante?

Para validar los requerimientos del software se necesita estudiarlos desde varios puntos de
vista diferentes, aumentado la probabilidad de detectar errores, de que afloren las
inconsistencias y de que se revelen las omisiones.

¿Cuáles son los pasos?

Una vez que se crean los modelos preliminares basado en escenarios, datos y orientados a
clases, se mejoran y analizan para evaluar si están claros, completos, y si son consistentes.

¿Cuál es el producto final?

Escoger una amplia variedad de representaciones basadas en texto y en diagramas, construir

adecuadamente el modelo de requerimientos.

¿Cómo me aseguro de que lo hice bien?

 Los productos del trabajo para modelar los requerimientos deben revisarse para saber
si son correctos, completos y consistentes.
 6

 Deben reflejar las necesidades de todos los participantes y establecer el fundamento

desde el que se realizará el diseño.

1. ANÁLISIS DE LOS REQUERIMIENTOS

El análisis de los requerimientos da como resultado:

 La especificación de las características operativas del software

 Indica la interfaz de éste y otros elementos del sistema.
 establece las restricciones que limitan al software.
 Permite al profesional a construir sobre los requerimientos básicos establecidos
durante las tareas de concepción, indagación y negociación, que son parte de la
ingeniería de los requerimientos.

Tarea de Análisis

 Reconocimiento del problema

 Evaluación y síntesis
 Modelado
 Especificación
 Revisión

Funciones y Habilidades del Analista

 Entrevista
 Talleres
 Observación
 Encuestas
 Revisión documental
 Uso de especificaciones formales para requerimientos (formatos entandar de
documentos, UML, etc.)

Tipos de Modelos

 Modelos basados en el escenario.

Es una representación del sistema desde el punto de vista del usuario.
 Modelos de datos
Ilustran el dominio de información del problema.
 7

 Modelos orientados a clases

Define objetos, atributos y relaciones.
 Modelos orientados al flujo
Representan la manera como transforman los datos a medida que se avanza a
través del sistema.
 Modelos de comportamiento
Se utilizan para describir el comportamiento del sistema en su totalidad ante
eventos externos.

1.1. Objetivos y Filosofía General

Filosofía

Durante el modelado de los requerimientos, la atención se centra en qué, no en cómo.

 ¿Qué objetivos manipulan el sistema?

 ¿Qué funciones debe realizar el sistema?
 ¿Qué comportamientos tiene el sistema?
 ¿Qué interfaces se definen?
 ¿Qué restricciones son aplicables?

Objetivos

El modelo de requerimientos debe lograr tres objetivos principales.

a. Describir lo que requiere el cliente.

b. Establecer una base para la creación de un diseño de software.
c. Definir un conjunto de requerimientos que puedan validarse una vez construido
el software.

1.2. Reglas Practicas del Análisis

 Arlow y Neustadt sugieren cierto número de reglas prácticas útiles que deben
seguirse cuando se crea el modelo del análisis:
 El modelo debe centrarse en los requerimientos que sean visibles dentro del
problema dentro del dominio del negocio.
 8

 Cada elemento del modelo de requerimientos debe agregarse al entendimiento

general de los requerimientos del software y dar una visión del dominio de la
información, de la función y del comportamiento del sistema.
 Hay que retrasar las consideraciones de la infraestructura y otros modelos no
funcionales hasta llegar a la etapa del diseño.
 Debe minimizarse el acoplamiento a través del sistema.
 Es seguro que el modelo de requerimientos agrega valor para todos los
participantes.
 Mantener el modelo tan sencillo como se pueda.

1.3. Análisis del Dominio

Durante el modelado de los requerimientos, la atención se centra en qué, no en
cómo.

Firesmith [Fir93] lo describe del siguiente modo:

“En si el análisis del dominio es la identificación, análisis y especificación de los

requerimientos comunes, a partir de un dominio de aplicación específica,
normalmente para usarlo varias veces en múltiples proyectos...”

La meta del análisis del dominio

Encontrar o crear aquellas clases o patrones de análisis que sean aplicables y

reutilizables en lo general, de modo que puedan volverse a usar.

Producto final

Si los patrones o clases se definen y clasifican en forma tal que puedan

reconocerse y aplicarse para resolver problemas comunes: la creación del modelo del
análisis será más eficiente y esto mejorará el tiempo para llegar al mercado y reduce
los costos de desarrollo.
 9

1.4. Enfoques del Modelado de Requerimientos

Enfoques

Análisis estructurado

Los objetos de datos se modelan de modo que se definan sus atributos y

relaciones.

Análisis orientado a objetos

Se centra en la definición de las clases y en la manera en la que colaboran uno con

el otro para cumplir los requerimientos. El UML y el proceso unificado están
orientados a objetos, sobre todo.

2. MODELO BASADOS EN ESCENARIOS

El modelado de los requerimientos con UML, comienza con la creación de escenarios en
forma de casos de uso, diagramas de actividades y diagramas de tipo carril.

2.1. Creación de un Caso de Preliminar de Uso

Los casos preliminares de uso se utilizan para:

 Identificar a los participantes,

 definir el alcance del problema,
 especificar los objetivos operativos generales,
 establecer prioridades,
 10

 delinear todos los requerimientos funcionales conocidos y

 describir las cosas (objetos) que serán manipuladas por el sistema.

Para comenzar a desarrollar los casos de uso, se enlistan las funciones que se obtienen
por medio de conversaciones con los participantes.

Ejemplo, desarrollo de un caso de uso preliminar. Sistema casa segura

La escena: Sala de juntas, durante la segunda reunión para recabar los requerimientos.

Participantes: Jamie Lazar, miembro del equipo del software; Ed Robbins, integrante del
equipo del software; Doug Miller, gerente de ingeniería de software; tres miembros de
mercadotecnia; un representante de ingeniería del producto, y un facilitador.

La conversación:

Facilitador: Es hora de que hablemos sobre la función de vigilancia de CasaSegura. Vamos

a desarrollar un escenario de usuario que accede a la función de vigilancia.

Jamie: ¿Quién juega el papel de la mercadotecnia ha estado trabajando en dicha

funcionalidad?

Meredith: Bueno, la razón de la vigilancia es permitir que el propietario de la casa la revise

cuando se encuentre fuera, así como poder grabar y reproducir el video.

Ed: ¿Usaremos compresión para guardar el video?

Facilitador: Buena pregunta, Ed, pero por ahora pospondremos los aspectos de la
implementación. ¿Meredith?

JaMeredith: Bien, me centraré en la función de vigilancia, quiero tener acceso a la función

de vigilancia, ya sea por PC o por internet y poder mostrar vistas de la cámara en una PC y
controlar el ángulo y acercamiento de una cámara en particular. Especificaría la cámara
seleccionándola en el plano de la casa. También quiero poder bloquear el acceso a una o más
cámaras con una clave determinada. Además, desearía tener la opción de ver pequeñas ventanas
con vistas de todas las cámaras y luego escoger una que desee agrandar.

Jamie: Ésas se llaman vistas reducidas.

 11

Meredith: Bien, entonces quiero vistas reducidas de todas las cámaras. También quisiera
que la interfaz de la función de vigilancia tuviera el mismo aspecto y sensación que todas las
demás del sistema CasaSegura. Quiero que sea intuitiva, lo que significa que no tenga que leer
un manual para usarla.

Facilitador: Buen trabajo. Ahora, veamos esta función con un poco más de detalle.

Listado de Funciones

 Seleccionar cámara para ver.

 Pedir vistas reducidas de todas las cámaras.
 Mostrar vistas de las cámaras en una ventana de PC.
 Controlar el ángulo y acercamiento de una cámara específica.
 Grabar la salida de cada cámara en forma selectiva.
 Reproducir la salida de una cámara.
 Acceder por internet a la vigilancia con cámaras.

Desarrollo de un caso preliminar

Caso de uso: acceder a la vigilancia con cámaras por internet, mostrar vistas de
cámaras (AVC-MVC)

Escenario principal

Actor: propietario

 El propietario accede al sitio web Productos CasaSegura.

 El propietario introduce su identificación de usuario.
 El propietario escribe dos claves (cada una de al menos ocho caracteres de
longitud).
 El sistema muestra los botones de todas las funciones principales.
 El propietario selecciona “vigilancia” de los botones de las funciones
principales.
 El propietario elige “seleccionar una cámara”.
 El sistema presenta el plano de la casa.
 El propietario escoge el ícono de una cámara en el plano de la casa.
 El propietario selecciona el botón “vista”.
 12

 El sistema presenta la ventana de vista identificada con la elección de la

cámara.
 El sistema muestra un video dentro de la ventana a velocidad de un cuadro
por segundo.

2.2. Mejora de un Caso de uso Preliminar

¿El actor puede emprender otra acción en este punto?

¿Es posible que el actor encuentre alguna condición de error en este punto?

En este punto, ¿es posible que el actor encuentre otro comportamiento (por ejemplo,
alguno que sea invocado por cierto evento fuera del control del actor)?

2.3. Estructura de un Caso Formal

Caso de uso: Acceder a la vigilancia con cámaras por internet, mostrar vistas de
cámaras (AVCMVC).

Iteración: 2, última modificación: 14 de enero por V. Raman.

Actor principal: Propietario.

Objetivo en contexto: Ver la salida de las cámaras colocadas en la casa desde

cualquier ubicación remota por medio de internet.

Precondiciones: El sistema debe estar configurado por completo; deben obtenerse

las identificaciones y claves de usuario apropiadas.

Disparador: El propietario decide ver dentro de la casa mientras está fuera.

Escenario:

Excepciones:

 La identificación o las claves son incorrectas o no se reconocen

 La función de vigilancia no está configurada para este sistema
 El propietario selecciona “Mirar vistas reducidas de todas las cámaras”
 No se dispone o no se ha configurado el plano de la casa
 Se encuentra una condición de alarma

Prioridad: Moderada, por implementarse después de las funciones básicas.

 13

Cuándo estará disponible: En el tercer incremento.

Frecuencia de uso: Frecuencia moderada.

Canal al actor: A través de un navegador con base en PC y conexión a internet.

Actores secundarios: Administrador del sistema, cámaras.

Canales a los actores secundarios:

 Administrador del sistema: sistema basado en PC.

 Cámaras: conectividad inalámbrica.

Asuntos pendientes:

¿Qué mecanismos protegen el uso no autorizado de esta capacidad por parte de los
empleados de Productos CasaSegura?

¿Es suficiente la seguridad?

¿Será aceptable la respuesta del sistema por internet dado el ancho de banda que
requieren las vistas de las cámaras?

Diagrama de caso de uso preliminar, para el producto CasaSegura

Cada caso de uso está representado por un óvalo. En esta sección sólo se estudia el caso
de uso AVC-MVC.
 14

3. MODELOS UML QUE PROPORCIONAN EL CASO DE USO

Un diagrama de actividades UML representa las acciones y decisión es que ocurren cuando
se realiza cierta función. Enriquece el caso de uso al proporcionar una representación gráfica
del flujo de interacción dentro de un escenario específico (coursehero, 2019).

3.1. Desarrollo de un Diagrama de Actividades

El diagrama de actividad UML enriquece el caso de uso al proporcionar una
representación gráfica del flujo de interacción dentro de un escenario específico.

3.2. Diagramas de Canal (swimlane)

Un diagrama de canal (swimlane) representa el flujo de acciones y decisiones e
indica qué actores efectúan cada una de ellas.

4. CONCEPTOS DE MODELADO DE DATO

El modelado de datos es el proceso de documentar un diseño de sistema de software
complejo como un diagrama de fácil comprensión, usando texto y símbolos para representar la
forma en que los datos necesitan fluir. El diagrama se puede utilizar como un mapa para la
construcción de un nuevo software o para la reingeniería de una aplicación antigua (techtarget,
2019).

4.1. Objetos de Datos

Un objeto de datos es una representación de información compuesta que debe
ser entendida por el software.

4.2. Atributos de los Datos

Los atributos de los datos definen las propiedades de un objeto de datos y tienen
una de tres diferentes características.

4.3. Relaciones
Los objetos de datos están conectados entre sí de diferentes maneras. Considere
dos objetos de datos, persona y auto.

5. MODELADO BASADO EN CLASE

Es una organización de objetos según las clases.

Las clases se manifiestan en las siguientes clases:

 15

 Entidades externas: que produce o consume información que usara un sistema basado
en computadora.
 Cosas: que son parte del dominio de la introducción para el problema.
 sucesos o eventos: que ocurren dentro del contexto de la operación del sistema.
 papeles: que desempeñan personas que interactúan con el sistema.
 unidades organizacionales: relevantes para alguna aplicación.
 sitios: establece el contexto de problemas y la función global del sistema.
 estructuras: define en clases de objetos o clases de objetos relacionales.

Coad y Yourdon [COA91] sugieren seis características de selección que se deben de usar
cuando un analista considera cada clase potencial para incluirlas en el modelo de análisis
(blogspot, 2019):

 información referida.
 servicios requeridos.
 atributos múltiples.
 atributos comunes.
 operaciones comunes.
 requisitos esenciales.
 16

CONCLUSIONES
 Toda notación de modelado tiene sus limitaciones, y la del caso de uso no es la
excepción.
 Un caso de uso es tan bueno como lo sea(n) su(s) autor(es). Si la descripción es poco
clara, el caso de uso será confuso o ambiguo.
 El modelado basado en escenarios es apropiado para la gran mayoría de todas las
situaciones que encontrará un ingeniero de software.
 Si se desarrolla bien, el caso de uso proporciona un beneficio sustancial como
herramienta de modelado.
 El caso de uso es el principal elemento del modelado y se obtiene durante la
indagación de los requerimientos.
 17

REFERENCIAS BIBLIOGRÁFICAS
blogspot. (18 de 10 de 2019). blogspot. Obtenido de
[Link]
[Link]

coursehero. (16 de 10 de 2019). coursehero. Obtenido de

[Link]
de-uso-Un-diagrama-de-actividades-UML/

Pressman, R. S. (2010). INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

México: McGRAW-HILL .

techtarget. (19 de 10 de 2019). techtarget. Obtenido de

[Link]