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
Guía de especificación funcionalV.0.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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.2
Guía de especificación funcionalV.0.1
Í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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.3
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.4
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.5
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.6
Guía de especificación funcionalV.0.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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.7
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.8
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.9
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.10
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.11
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.12
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.13
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.14
Guía de especificación funcionalV.0.1
El diagrama de casos de uso debe quedar consignado en el documento de especificación
funcional.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.15
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.16
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.17
Guía de especificación funcionalV.0.1
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
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.18
Guía de especificación funcionalV.0.1
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.
Diseño, desarrollo e implantación del Sistema de Información Misional (SIM) de la Procuraduría General de la Nación Pág.19