Guia Especificacion Funcional v 0.1

Guía de especificación funcionalV.0.1

DISEÑO, DESARROLLO E IMPLANTACIÓN DEL SISTEMA DE INFORMACIÓN MISIONAL (SIM) DE LA

PROCURADURÍA GENERAL DE LA NACIÓN

GUÍA DE ESPECIFICACIÓN FUNCIONAL

Código: GEF 0.1

Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.1


CONTROL DEL DOCUMENTOCláusula de confidencialidad

La información contenida en este documento es generado en el marco del Contrato 054 celebrado entre LA PROCURADURÍA GENERAL DE LA NACIÓN y SYNAPSIS LTDA. Por razones de índole comercial ya que la misma describe procesos sensibles de naturaleza competitiva, puede resultar en perjuicio de SYNAPSIS que sea conocido por personas distintas a aquellas a las que está dirigida, por tales razones, no podrá ser reproducida, mostrada o divulgada sin el correspondiente permiso escrito de SYNAPSIS Ltda. y/o LA PROCURADURÍA GENERAL DE LA NACIÓN y SYNAPSIS LTDA.

Control de Versiones

Fecha de Actualización

Versión Revisado por Cambio / Comentarios

07/Mar/2007 0.1 Diana Cassas Creación del documento

Aprobación del Documento

Rol Nombre Firma Fecha

Gerente de Proyecto SIM – PGN

Evelin Julio Estrada

Supervisor del contrato SIM – PGN

Javier Salazar Cedeño

Asesor de calidad proyecto SIM - PGN

Rigoberto Rodríguez Peralta

Gerente Proyecto SIM – Synapsis

Germán Díaz Montoya



ÍNDICECONTROL DEL DOCUMENTO........................................................................................................21. INTRODUCCIÓN..........................................................................................................................4

1.1 OBJETIVO...............................................................................................................................41.2 ALCANCE...............................................................................................................................4

2. MODELADO DE ESPECIFICACIONES FUNCIONALES............................................................52.1 DIAGRAMAS DE CASOS DE USO........................................................................................52.2 ESPECIFICACIÓN DE CASOS DE USO.............................................................................162.3 DIAGRAMAS DE ACTIVIDAD..............................................................................................16

3. ERRORES COMUNES EN LA ESPECIFICACIÓN DE CASOS DE USO.................................18REFERENCIAS..............................................................................................................................19



1. INTRODUCCIÓN.

Dentro del proceso de desarrollo de software, la etapa de levantamiento de requerimientos juega

un papel importante para lograr la entrega de un producto desarrollado con calidad. Los

requerimientos nos indican como nuestro sistema debe comportarse y las características que

debe tener.

Para expresar el comportamiento del sistema, es decir, lo que el sistema debe hacer se definen

los requerimientos funcionales. Para expresar las características o cualidades del sistema se

definen los requerimientos no funcionales.

La manera en que se garantiza que los requerimientos funcionales sean especificados

correctamente es siguiendo el “PROCEDIMIENTO PARA EL LEVANTAMIENTO DE

INFORMACION”, en el cual se establecen la metodología y el lenguaje a utilizar para dichas

especificaciones. El lenguaje utilizado para la especificación de requerimientos funcionales es

UML.

1.1 OBJETIVO

El objetivo de esta guía es proveer a los consultores las directrices para utilizar de forma

apropiada el Lenguaje Unificado de Modelado (UML) dentro de sus proyectos.

1.2 ALCANCE

Esta guía proporciona una referencia del uso de características específicas de UML para ser

utilizadas en las especificaciones funcionales de los proyectos

Proporciona sugerencias y consejos, basados en las experiencias y lecciones aprendidas en

proyectos anteriores, sobre como utilizar UML.



2. MODELADO DE ESPECIFICACIONES FUNCIONALES

UML es un lenguaje grafico que permite especificar, visualizar, construir y documentar los

artefactos de sistemas de software.

UML esta compuesto por elementos, en su mayoría gráficos; estos componentes se relacionan

de una forma estructurada que permiten modelar la realidad. Estas estructuras están distribuidas

en diferentes tipos de gráficos :

a) Diagrama de casos de uso

b) Diagrama de clases

c) Diagrama de Objetos

d) Diagramas de comportamiento

a. Diagramas de estado

b. Diagramas de Actividad

c. Diagramas de Interacción

i. Diagramas de Secuencia

ii. Diagramas de Colaboración

e) Diagramas de implementación

a. Diagramas de componentes

b. Diagramas de Despliegue

En esta guía nos enfocaremos en el uso de los gráficos Diagramas de casos de uso y Diagramas

de actividad.

2.1 DIAGRAMAS DE CASOS DE USO

Los casos de uso nacen como alternativa para la documentación de requerimientos funcionales,

son una forma de representar funcionalidad al cliente y guiar el proceso de desarrollo del

software.

El cliente entrega especificaciones de requerimientos algunas veces vagas, ambiguas o

contradictorias. La idea de la etapa de levantamiento de requerimientos es obtener la



información de lo que quiere el cliente que haga el sistema, plasmarlo en casos de uso y

convertir los requerimientos en completos, correctos, realizables, no ambiguos, trazables y

consistentes.

Los casos de uso son hechos en lenguaje natural, lo que lo convierte en comprensible por el

cliente independiente de su profesión. No se necesita ser ingeniero de sistemas para

comprender un caso de uso.

Los casos de uso responden al Qué hace el sistema y no al Cómo lo hace. El Cómo se hace es

propio de los diseñadores y desarrolladores del producto de software.

Los casos de uso comprenden dos partes:

o Diagrama de casos de uso

o Especificación del caso de uso

Los diagramas de casos de uso modelan aspectos dinámicos del sistema. A través de los

diagramas de casos de uso se visualiza, especifica y documenta el comportamiento de un

sistema.

El diagrama de casos de uso se puede usar como modelo funcional del sistema, ya que con el

se puede representar toda la funcionalidad del sistema, incluyendo quienes usan esas

funcionalidades.

El diagrama de casos de uso muestra un conjunto de Casos de Uso (representados por las

elipses), actores (representados por las figuras humanas) y las relaciones entre casos de uso y

actores; como se aprecia en la Figura 1.



Figura 1

2.1.1 ACTORES

Un actor es una entidad externa del sistema que participa en el caso de uso.

Los actores pueden ser:

Roles que desempeñan las personas o usuarios frente al sistema

Otros Sistemas (Cuando estos disparan o dan inicio a un caso de uso).

Eventos externos (Una fecha o una hora específica que provoca el inicio de un caso de

uso).

Los actores estimulan al sistema con entradas, de las cuales esperan una respuesta.

Generalmente los actores inician los casos de uso, aunque un caso de uso se puede iniciar por

otro caso de uso. Algunos ejemplos de actores se pueden apreciar en la Figura 2.



Figura 2

Se pueden declarar relaciones de Generalización (Herencia) entre actores. Esta relación indica

que un actor puede realizar todas las funcionalidades que otro actor realiza.

2.1.2 CASOS DE USO

Un caso de uso es una operación, tarea o función específica que realiza el sistema y que inicia

con la petición de un actor o desde otro caso de uso.

Para nombrar los casos de uso se empieza por un verbo en infinitivo que indica la operación,

tarea o función a realizar y el resto de la oración refleja el propósito del caso de uso, un ejemplo

de caso de uso se observa en la Figura 3.

Figura 3



Relaciones

Entre los casos de uso se pueden establecer varios tipos de relaciones: relaciones de

comunicación, relaciones de inclusión, relaciones de extensión y en menor medida relaciones de

generalización o herencia.

Relación de comunicación

Esta es la relación más común en el diagrama de casos de uso, representa una comunicación

entre 2 casos de uso, entre un actor y un caso de uso. Se representa por una línea continua; tal

como vemos en la Figura 4.

Figura 4

En el ejemplo vemos como el Actor se comunica con el Caso de Uso 1 dando inicio a este; a su

vez el Caso de Uso 1 se comunica y da inicio al Caso de Uso 2; es decir que el actor podrá

comunicarse y dar inicio al Caso de uso 2 solo a través del Caso de Uso 1.

Relación de Inclusión (<<<include>>)

La inclusión representa como un caso de uso incluye el comportamiento de otro; sin embargo

esta relación permite modificar u omitir algunos comportamientos del caso de uso incluido en el

caso de uso incluyente; esta relación era conocida como USES en la versión anterior de UML.

Esta relación es representada por una flecha continua que va desde el caso de uso que incluye

hasta el caso de uso incluido y etiquetado con la palabra <<include>>; como vemos en la Figura

5 y en la Figura 6.



Figura 5

Figura 6

Vemos como el caso de uso “Reintegrar cuenta corriente” incluye el comportamiento del caso de

uso “Verificar operación” pero “reintegrar cuenta corriente” puede cambiar u omitir algunas partes

del comportamiento de “Verificar Operación”.

Relación de Extensión (<<Extend>>)

La relación de extensión se da cuando un caso de uso extiende o amplía la funcionalidad de otro

caso de uso. El caso de uso que es extendido es independiente del caso de uso que lo extiende

pero el caso de uso que extiende debe implementar todo el comportamiento del caso de uso

extendido sin modificarlo.

Esta relación se representa mediante una flecha continua desde el caso de uso extensor hasta el

caso de uso extendido y con la etiqueta <<extend>>; tal como vemos en la Figura 7 y en la

Figura 8.

Figura 7



Figura 8

En el ejemplo vemos como el caso de uso “Realizar llamada de conferencia” extiende el

comportamiento del caso de uso “Realizar llamada” ya que para que se de el primero debe

seguirse el comportamiento del segundo, sin cambios, y adicionar otros comportamientos otros

comportamientos.

Relación de herencia (<<Hereda>> o <<Inherits>>)

Esta relación representa una herencia de un caso de uso padre a un caso de uso hijo, en este

tipo de relación el caso de uso hijo hereda la especificación del caso de uso padre y

posiblemente la modifica o amplia. La diferencia entre esta relación y las relaciones de inclusión

<<include>> y extensión <<Extend>> radica en:

Herencia Inclusión Extensión

El caso de uso hijo puede

modificar comportamientos

del caso de uso padre pero

no omitirlos.

El caso de uso que incluye

puede omitir o modificar

comportamientos del caso de

uso incluido.

No puede modificar ni omitir

comportamientos del caso de

uso extendido.

La relación de herencia se representa mediante una flecha continua que va desde el caso de uso

hijo al caso de uso padre y etiquetado como <<Hereda>>; tal como vemos en la Figura 9 y en la

Figura 10.



Figura 9

Este tipo de relación es más común entre actores así:

Figura 10

2.1.3 DIAGRAMA DE CASOS DE USO

Todos los actores, casos de uso y relaciones se unen para conformar el diagrama de casos de

uso; el cual está compuesto por los elementos enumerados anteriormente más el “limite del

sistema”. El límite del sistema es importante pues este nos muestra que elementos están dentro

del sistema y cuales están fuera; en el caso de un proyecto software nos muestra que partes del

sistema están sujetas a desarrollo y cuales no.

Es importante que este diagrama se haga antes de la especificación de cada caso de uso ya que

de este se generan las relaciones que se plasmarán en el formato enunciado en el punto .

Al momento de hacer el análisis del todo el sistema puede hacerse 2 tipos de modelado con

casos de uso, un modelado de contexto y un modelado de requisitos.



Modelado de contexto:

El modelado de contexto es opcional aunque brinda una visión amplia del negocio pues en él se

aprecian elementos que, aunque no hacen parte del software, si son importantes para las

actividades del negocio; de este puede también desprenderse el modelado de requisitos.

Otra utilidad de este modelado es la verificación de la compresión de los requerimientos del

cliente y la identificación del límite del problema o alcance de la solución. Un ejemplo de este tipo

de modelado la podemos apreciar en la Figura 11.

Figura 11

Como podemos ver en el ejemplo existen elementos que son parte del negocio pero que no

tendrán una incidencia en el software; es decir, los actores banco y comercio son actores que no

realizaran ninguna tarea dentro del software, aunque si tienen relación con el negocio que

estamos modelando.

Modelado de requisitos:

La función principal, o la más conocida del diagrama de casos de uso es documentar los

requisitos del sistema, o de una parte de el.

Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se espera que

realice el sistema, sin definir su funcionamiento interno. Es el paso siguiente al modelado del

contexto, en caso de haberse hecho, no indica relaciones entre actores, tan solo indica cuales



deben ser las funcionalidades (requisitos) del sistema. Se incorporan los casos de uso necesarios

que no son visibles desde los usuarios del sistema.

Para modelar los requisitos es recomendable:

a. Establecer su contexto.

b. Identificar las necesidades de los elementos del contexto (Actores).

c. Nombrar esas necesidades, y darles forma de caso de uso.

d. Identificar que casos de uso pueden ser especializaciones de otros, o buscar

especializaciones comunes para los casos de uso ya encontrados.

A continuación en la Figura 12 se puede observar un diagrama de casos de uso para modelado

de requisitos.

Figura 12



El diagrama de casos de uso debe quedar consignado en el documento de especificación

funcional.



2.2 ESPECIFICACIÓN DE CASOS DE USO

Ver plantilla ( Enterprise Architect)

2.3 DIAGRAMAS DE ACTIVIDAD

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para

modelar el comportamiento del sistema, la principal diferencia con los diagramas de flujo es que

el diagrama de actividad permite representar operaciones paralelas. Los diagramas de actividad

se pueden usar para modelar un Caso de Uso, una clase, un método complicado,

comportamientos dinámicos del sistema. Los diagramas de actividad se utilizan normalmente

para:

a. Describir la función de los casos de uso: Este diagrama es un flujo que deberá mostrar la

serie de actividades que deben ser realizadas en un uso-caso, así como las distintas rutas

que pueden irse desencadenando en el caso de uso.

b. Como modelo de dominio: Normalmente el modelo de dominio es realizado con un

diagrama de clases; sin embargo se utiliza un diagrama de actividad cuyos elementos son

los casos de uso del sistema; esto dado que este tipo de diagrama es más fácil de

comprender por parte del cliente, quien normalmente no esta familiarizado con UML.

2.3.1 ELEMENTOS

Los diagramas de actividad están conformados por los siguientes elementos:

a. Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro

sólido.

b. Actividad: Una actividad representa la acción que será realizada por el sistema la cual

es representada dentro de un ovalo.



c. Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a

otra, la transición es representada simplemente por una línea con una flecha en su

terminación para indicar dirección.

d. Ramificación o condición: Una ramificación ocurre cuando existe la posibilidad que

ocurra más de una transición (resultado) al terminar determinada actividad. Este

elemento es representado a través de un rombo.

e. Bifurcación o Fork: Un fork o bifurcación representa una necesidad de ramificar una

transición en más de una posibilidad. Aunque similar a una ramificación o condición la

diferencia radica en que una bifurcación representa más de una ramificación obligada,

esto es, la actividad debe proceder por ambos o más caminos a la vez, mientras que

una ramificación o condición representa una transición u otra para la actividad. Una

bifurcación es representado por una línea negra sólida, perpendicular a las líneas de

transición.

f. Combinación o Join: Una combinación ocurre al fusionar dos o más transiciones

provenientes de una bifurcación, y es empleado para unir dichas transiciones en una

sola, tal y como ocurría antes de una bifurcación solo que de forma inversa. Una

combinación es representado por una línea negra sólida, perpendicular a las líneas de

transición.

g. Fin: El fin de un diagrama de actividad es representado por un círculo, con otro círculo

concéntrico de color negro sólido.

h. Calles: En determinadas ocasiones ocurre que un diagrama de actividad se expanda a

lo largo de más de una entidad o actor, cuando esto ocurre el diagrama de actividad es

particionado en calles, donde cada calle representa la entidad o actor que esta llevando

acabo la actividad. Para el “Flujo de trabajo” en la descripción de un caso de uso este



diagrama deberá llevar dos calles: una para el actor del caso de uso y otra para el

sistema así:

3. ERRORES COMUNES EN LA ESPECIFICACIÓN DE CASOS DE USO

Es un error usar términos propios de la interfaz gráfica de usuario, tales como botón,

hacer click, combo, pantalla. Un caso de uso describe funcionalidad por lo tanto un

evento como “el usuario hace click en el botón guardar” se expresa en el caso de uso

como “el actor elige la opción guardar”.

Definición abstracta de datos de entrada y de salida. Ejemplo: obligación, proyecto. Para

corregir el error se debe expresar exactamente el dato que se ingresa o que retorna el

sistema por ejemplo: número de obligación, nombre de proyecto o código de proyecto

Usar lenguaje de implementación: base de datos, tabla. El caso de uso esta interesado

en las acciones que realiza el sistema y no como las hace. Para ejemplo un evento del

caso de uso puede ser “El sistema almacena los datos ingresados por el actor” y seria un

error indicar “El sistema almacena los datos ingresados por el actor en la tabla x de la

base de datos”

La redacción de los eventos no es clara. Para mejorar esto se recomienda:

o Utilizar oraciones simples



o Usar verbos conjugados como por ejemplo: introduce, elige, verifica, actualiza,

informa, registra, guarda,… Que reflejen la acción que el actor o el sistema

realiza.

Referirse a la misma cosa empleando términos diferentes. Ejemplo: valor solicitado con

monto solicitado. Para corregir el error se debe mantener los mismos términos al referirse

a lo mismo para todo el caso de uso y evitar usar sinónimos que puedan confundir al

lector del caso de uso. Cabe aclarar que se pueden usar sinónimos que estén claramente

expresado en el glosario del sistema.

Definir en las precondiciones, condiciones que se deben evaluar en el caso de uso y no

previas a su ejecución.

REFERENCIAS

Booch, Jacobson y Rumbaugh. El lenguaje Unificado de Modelado. Addison Wesley.1999

Larman, G. Applying UML and Patterns: An Introduction To Object-Oriented Analysis and

Design. Prentice-Hall, 1998.

Fowler,M. UML Distille –Applying the Standard Object Modeling Languaje. Addison-

Wesley,1997.


Guia Especificacion Funcional v 0.1

Documents

Transcript of Guia Especificacion Funcional v 0.1