UNDAD III.

Un modelo de requisitos le ayuda a:

Centrarse en el comportamiento
independencia de su diseo interno.

Describir las necesidades de los usuarios y las partes interesadas

con mucha menos ambigedad que con el lenguaje natural.

Definir un glosario de trminos coherente que los usuarios,

desarrolladores y evaluadores puedan utilizar.

externo

del

sistema,

con

Reducir las desviaciones e inconsistencias de los requisitos.

Reducir el trabajo necesario para dar respuesta a los cambios que
se producen en los requisitos.
Planear el orden en el que se desarrollarn las caractersticas.
Usar los modelos como base de las pruebas del sistema,
estableciendo una relacin inequvoca entre las pruebas y los
requisitos. Cuando se modifican los requisitos, esta relacin le
ayuda a actualizar las pruebas correctamente. De este modo, tiene
la seguridad de que el sistema satisface los nuevos requisitos.

Un modelo de requisitos brinda su mximo partido si se utiliza para

centrar las conversaciones con los usuarios o sus representantes y si se
consulta de nuevo al comienzo de cada iteracin. No es necesario que lo
complete exhaustivamente antes de escribir el cdigo. Una aplicacin
parcialmente operativa, aunque est muy simplificada, normalmente
constituye el punto de partida ms estimulante para debatir los
requisitos con los usuarios. El modelo resulta un mecanismo eficaz para
resumir los resultados de estas conversaciones.
Puede crear varias vistas diferentes de los requisitos de los
usuarios. Cada
vista
proporciona
un
tipo
determinado
de
informacin. Cuando cree estas vistas, lo ms conveniente es pasar con
frecuencia de una a otra. Puede comenzar en cualquier vista.

Describir el uso del sistema

Crear diagramas de casos de uso para describir quin utiliza el sistema y
para qu lo utiliza. Un caso de uso representa un objetivo de un usuario
del sistema y el procedimiento que realiza para lograr dicho objetivo.
Por ejemplo, un sistema de venta de comida en lnea debe permitir que
los clientes elijan elementos de un men y que los restaurantes que
prestan sus servicios actualicen el men. Puede resumir esto en un
diagrama de casos de uso:

Tambin puede mostrar cmo un caso de uso se compone de casos ms

pequeos. Por ejemplo, pedir un men forma parte de la compra de
comida, que tambin incluye el pago y el envo:

Tambin puede mostrar qu casos de uso estn incluidos en el mbito

del sistema que se est desarrollando. Por ejemplo, el sistema de la
ilustracin no se ocupa del caso de uso Enviar men. De este modo,
resulta ms fcil establecer el contexto del trabajo de desarrollo. (En un
diagrama de casos de uso, se pueden utilizar los contenedores del
subsistema para representar al sistema o sus componentes).
Tambin ayuda al equipo a deliberar lo que se incluir en versiones
posteriores. Por ejemplo, puede discutir si, en la versin inicial del
sistema, Pagar men se situar directamente entre el restaurante y el
cliente en lugar de a travs del sistema. En ese caso, en la versin
inicial, podra sacar Pagar men del rectngulo del sistema Cenar ahora.
Un diagrama de casos de uso solo contiene un resumen de los casos de
uso. Para proporcionar descripciones ms detalladas, puede vincular los
casos de uso del diagrama a otros documentos y otros diagramas. Para
obtener informacin acerca de cmo hacerlo.
La creacin de un diagrama de casos de uso ayuda al equipo a:

Concentrarse en lo que los usuarios esperan hacer con el sistema

sin necesidad de detenerse en los detalles de la implementacin.

Analizar el mbito del sistema o de versiones especficas del

sistema.

Definir los trminos que se usan para describir los requisitos

Los diagramas de clases de UML pueden ayudarle a desarrollar un

vocabulario coherente de los conceptos del negocio que se utilizan para
los siguientes propsitos:

Que utilizan los propios usuarios para analizar el negocio en que el

sistema trabaja.

Para describir las necesidades de los usuarios, por ejemplo en las

descripciones de los casos de uso, las reglas de negocio y los casos
de usuario.

Los tipos de informacin que se intercambian en la API del sistema

o a travs de la interfaz de usuario.

Las descripciones del sistema o pruebas de aceptacin.

Cuando se utilizan con este propsito, el contenido de un diagrama de

clases de UML se denomina diagrama de clases conceptuales. (Tambin
se conoce como modelo de dominio o modelo de clases de anlisis).
En un diagrama de clases conceptuales, solamente se muestran las
clases que son necesarias para las descripciones de los requisitos, pero
no se muestra ningn detalle del diseo interno del sistema. En el
diagrama, no aparecen los detalles del diseo interno del sistema. Por lo
general, tampoco se mostrarn las operaciones o interfaces de las
clases conceptuales.
por ejemplo, estas clases conceptuales para el sistema Cenar
ahora:

Un diagrama de clases conceptuales proporciona el vocabulario de

trminos que se utilizan a lo largo del modelo de requisitos. Por ejemplo,
en la descripcin detallada del caso de uso Pedir men, podra escribir:
El cliente elige un Men a partir del cual crea un Pedido y, a
continuacin,
crea Elementos
del
pedido en
el Pedido seleccionando Elementos del men en el Men.
Observe que los trminos que se utilizan en esta descripcin son los
nombres de las clases del modelo. En el diagrama, desaparecen las
ambigedades de las relaciones entre esas clases. Por ejemplo, se
muestra claramente que cada Pedido est asociado a un nico Men.
Las equivocaciones relacionadas con los requisitos de los usuarios
suelen derivarse de los malentendidos relativos al significado exacto de
las palabras. Por ejemplo, la mayora de los restaurantes compartirn la
definicin de los trminos Men y Pedido, pero la diferencia entre un
elemento de un pedido y un elemento de un men puede no ser tan
clara. Es importante exponer estas diferencias cuando se discutan los
requisitos con las partes interesadas del negocio. El diagrama de clases
es una herramienta til que le ayuda a aclarar los trminos y sus
relaciones.
El modelo de clases conceptuales puede conformar el vocabulario bsico
mediante el que puede describirse la lgica del negocio del sistema. Sin
embargo, en el software, las clases sern normalmente mucho ms
complejas que en el modelo conceptual, ya que en su implementacin
deben tenerse en cuenta aspectos como el rendimiento, la distribucin,
la flexibilidad y otros factores. Es frecuente encontrar en un nico
sistema varias implementaciones diferentes de una clase conceptual.
Por ejemplo, Pedidos puede representarse en XML, SQL, HTML y C# en
diferentes componentes del sistema y en diferentes interfaces entre los
componentes. La asociacin entre un Pedido y un Men puede
representarse de muchas maneras distintas, como referencias en el
cdigo de C#, como relaciones en una base de datos o como
identificadores de referencia cruzada en XML. No obstante, a pesar de
estas variaciones, el modelo conceptual proporciona informacin
importante que es verdadera en todos los componentes del software. El
diagrama de clases del ejemplo nos indica que en cada implementacin,
habr un nico Men asociado a cada Pedido.
La creacin de un diagrama de clases de requisitos ayuda a su equipo a:

Definir y normalizar los trminos bsicos que se utilizan en el

anlisis de las necesidades de los usuarios.

Aclarar las relaciones entre estos trminos.

En un diagrama de clases conceptual, no suele ser til colocar las

flechas en las asociaciones para representar la navegabilidad. Esto se
debe a que el diagrama no representa una implementacin. Las
asociaciones representan las relaciones entre los objetos reales.

Mostrar reglas de negocios

Una regla de negocio es un requisito que no est asociado a un caso de
uso determinado y debe cumplirse en todo el sistema.
Muchas reglas de negocios son las restricciones de las relaciones entre
las
clases
conceptuales. Puede
escribir
estas reglas
de
negociosestticas como comentarios asociados a las clases pertinentes
de un diagrama de clases conceptuales. Por ejemplo:

Las reglas de negocios dinmicas restringen las secuencias de eventos

admisibles. Por ejemplo, puede utilizarse un diagrama de secuencia o

actividades para mostrar que un usuario debe iniciar sesin antes de

realizar otras operaciones en el sistema.
Sin embargo, muchas reglas dinmicas pueden formularse de forma ms
eficaz y general si se sustituyen por reglas estticas. Por ejemplo, puede
agregar el atributo booleano 'Conectado' a una clase del modelo de
clases conceptuales. 'Conectado' se agregara como condicin posterior
del caso de uso de inicio de sesin y como condicin previa de la mayor
parte de los dems casos de uso. Este enfoque le permite evitar definir
todas las combinaciones de secuencias de eventos posibles. Tambin
resulta ms flexible cuando necesita agregar nuevos casos de uso al
modelo.
Tenga en cuenta que las opciones giran en torno a cmo define los
requisitos y que esto es independiente del modo en que se implementan
los requisitos en el cdigo del programa.
Describir los requisitos de calidad del servicio
Hay varias categoras de requisitos de calidad del servicio. Algunas de
ellas son:

Rendimiento

Seguridad

Facilidad de uso

Confiabilidad

Solidez

Puede incluir algunos de estos requisitos en las descripciones de casos

de uso concretos. Otros requisitos no son especficos de los casos de uso
y resulta ms eficaz incluirlos en un documento independiente. Siempre
que pueda, le resultar til ajustarse al vocabulario definido en el
modelo de requisitos. En el ejemplo siguiente, observe que las
principales palabras que se utilizan en el requisito son los nombres de
los actores, casos de uso y clases de las ilustraciones anteriores:
Si un Restaurante elimina un Elemento del men mientras que un
Cliente est Pidiendo un men, cualquier Elemento del pedido que haga
referencia a ese Elemento del men aparecer en rojo.

Mostrar el flujo de trabajo entre los usuarios y el sistema

Puede utilizar un diagrama de actividades para mostrar el flujo de
trabajo entre los diferentes casos de uso. Normalmente, resulta til
comenzar un modelo de requisitos dibujando un diagrama de
actividades en el que se muestren las principales tareas que realizan los
usuarios (tanto dentro del sistema como fuera de l).
Por ejemplo:

Puede dibujar diagramas de casos de uso y diagramas de actividades

para mostrar vistas diferentes de la misma informacin. El diagrama de
casos de uso resulta ms eficaz para mostrar el anidamiento de las
acciones menores dentro de una actividad mayor, pero no para mostrar
el flujo de trabajo. Por ejemplo:

Tomar en cuenta que tambin puede utilizar diagramas de actividades

para describir los algoritmos en el software, aunque cuando utilice los

diagramas para el proceso de negocio, se concentrar en las acciones

que estn visibles fuera del sistema.

Mostrar las interacciones entre los usuarios y el sistema

Puede utilizar un diagrama de secuencia para mostrar el
intercambio de mensajes entre los actores del sistema y los actores
externos o entre componentes del sistema. De este modo, obtendr una
vista de los pasos de un caso de uso en el que se mostrar con total
claridad la secuencia de interacciones. Los diagramas de secuencia
resultan especialmente tiles cuando hay diferentes componentes que
interactan en un caso de uso y tambin cuando el sistema tiene una
API.

Por ejemplo:

Una ventaja de los diagramas de secuencia es que resulta fcil ver qu

mensajes entran en el sistema que se est desarrollando. Para disear el
sistema, puede reemplazar la nica lnea de vida Sistema por una lnea
de vida diferente para cada uno de sus componentes y mostrar despus
las interacciones que se producen entre ellos en respuesta a cada
mensaje entrante.