pautas-para-documentar-desarrollos-de-sistemas

Pautas para documentar desarrollos de sistemas
Para agilizar el seguimiento de los proyectos de desarrollo de software, así como
para minimizar el impacto del futuro mantenimiento que estos sistemas puedan requerir, se
han fijado pautas para su documentación, de modo que haya un aceptable grado de
uniformidad en todo el ámbito de la Administración Pública Provincial.
La documentación de un desarrollo de sistemas no se puede concebir como una
actividad aislada, sino como el resultado esperado de una metodología de trabajo, de un
proceso con sus etapas y tareas en cada etapa. Por lo tanto, habrá distintos documentos que
se irán generando en cada etapa.
Atentos a los desarrollos actuales en materia de Tecnología de la Información y a
las tendencias del mercado, se permitirá abordar la documentación desde las dos estrategias
de desarrollo más usuales, las denominadas Ciclo de vida Estructurado y Orientación a
Objetos. Esta elección no supone negar que existan otros enfoques para el desarrollo de
sistemas que estamos dejando de lado, y que se podrán analizar en cada caso.
Más allá de que existen diversas metodologías, recomendamos la adopción de la
Orientación a Objetos, ya que este tipo de metodología, además de estar imponiéndose en
todos los desarrollos de un par de años a esta parte, incorpora la idea del desarrollo
incremental con alta participación de usuarios.
Lo que sigue es, entonces, una guía para la documentación, confeccionada con el
objetivo de reunir, compatibilizar y sintetizar los planteos más usuales de ambas metodologías
utilizando la terminología más habitual para cada una.
A continuación, describimos:
•
La documentación que, al fin de cada etapa, deberá entregarse según la
metodología de Ciclo de Vida Estructurado.
•
La documentación que, al fin de cada etapa, deberá entregarse según la
metodología de Orientación a Objetos.
•
Algunas consideraciones sobre la actualización de la documentación en relación a
las tareas de mantenimiento de la aplicación, luego de su puesta en producción.
En todos los casos, la Dirección General de Gobierno Digital puede determinar que
cierta documentación es optativa en un determinado proyecto, basándose en el tamaño y
grado de complejidad del mismo.
Pág. 1 de 23
a.- Ciclo de vida estructurado
ETAPA
DOCUMENTACION
TAREAS
Definición de
Requerimientos
Diagnóstico de la situación y necesidad del sistema
Detección de objetivos y
límites del sistema y su
interacción con el
ambiente
Modelo del Ambiente:
• Declaración de Propósitos
• Diagrama de Contexto
• Lista de Eventos o Catálogo de Requerimientos
En base a entrevistas con
usuarios
Glosario
Diagrama de Gantt del proyecto (preliminar)
Análisis
Modelo de Comportamiento
• Diagrama de Flujo de Datos
• Especificación de procesos
• Diagrama Entidad Relación
• Diccionario de Datos
• Diagrama de Transición de Estados
Diagrama de Gantt del proyecto (actualización)
Diseño
Modelo del usuario
Formalización de objetivos,
independiente de la
naturaleza de la tecnología
a aplicar y de cualquier
cuestión de implantación
Determinación de
entidades, con atributos e
interrelaciones
Determinación de procesos
Elección del entorno
tecnológico
• Modelo del Procesador
O Diagrama de hardware
O Justificación del entorno tecnológico
• Modelo de Tareas: Diagrama de Fronteras
Establecimiento de la
arquitectura de la
aplicación
Diseño de Interfaces de
usuarios y procesos
• Modelo de implantación de programas: Diagrama estructurado
• Interfaces de usuario: Prototipos de pantallas y reportes
• Base de datos: estructura
Diagrama de Gantt del proyecto (actualización)
Desarrollo
Normas de programación y estándares de nomenclatura
Implementación
Esquema definitivo de la Base de Datos
Creación base de datos
Código fuente (con documentación incorporada)
Codificación e integración
de módulos
Diagrama de Gantt del proyecto (definitivo)
Testeo e instalación
Código fuente definitivo (con documentación incorporada)
Pruebas unitarias
Documentación sobre las pruebas realizadas
Pruebas de Integración
Manual de Usuario
Carga de tablas de
configuración
Pautas para migración de datos
Manual de administración y soporte técnico
Descripción general para el funcionario no informático
Pág. 2 de 23
Migración de Datos e
instalación
Capacitación si
corresponde
NOTA 1: Código fuente incluye no sólo las líneas codificadas en el lenguaje en que
se decida desarrollar la aplicación, sino los posibles stored procedures, el código que pudiera
estar embebido en formularios y cualquier pieza de software, local a la aplicación y necesaria
para que ésta funcione. También se incluye el código HTML, XML, ASP, JSP, PHP, o cualquier
otro usado en el desarrollo web.
NOTA 2: Todos los diagramas especificados se refieren a la notación de Yourdon,
que se puede consultar en “Análisis estructurado moderno”, de Edward Yourdon, Editorial
Prentice Hall, 1993, ISBN 9688803030. También se puede ver en la web, en el sitio de
Yourdon, http://www.yourdon.com/strucanalysis/index.html (en inglés).
Pág. 3 de 23
b.- Breve descripción de los documentos y diagramas
1. Diagnóstico de la situación y necesidad del sistema (Objetivos):
Tiene que ser una descripción somera de la situación actual y las mejoras que
traerá la implementación del sistema. Como a veces en esta etapa se decide que no es
necesario hacer un desarrollo, o que se va a reutilizar uno existente, hay que explicar por qué
es necesario el desarrollo en cuestión. Si se trata de un mantenimiento de un sistema
existente, se deberá explicar por qué es necesario y cuáles son las contras de no hacerlo.
Por ejemplo:
“Actualmente, la Secretaría de Educación no cuenta con una forma confiable de obtener
estadísticas de alumnos de las escuelas de la ciudad. Una de las causas que hace que las
estadísticas no sean confiables proviene del hecho de que numerosos alumnos se inscriben
en más de una escuela y no hay una base de datos única que permita detectar esta
situación. Por otro lado, los métodos manuales utilizados impiden saber si los criterios
utilizados en todos los relevamientos son los mismos. Además, la obtención de datos actual
es muy costosa en términos económicos y de tiempo. Por todas estas consideraciones, se ha
decidido desarrollar la Base Única de Datos de Alumnos, que va a permitir uniformizar
criterios y mantener la información centralizada”.
2. Modelo ambiental:
Este modelo define la frontera del sistema describiendo sus límites y alcances.
Definido qué queda en el interior y qué en el exterior del sistema, se deben definir
los estímulos (mensajes, acciones de usuarios u otros sistemas, etc.) del exterior a los que el
sistema responde, así como las interfaces de ese intercambio. Utiliza:
2.1 Declaración de propósitos: Es una descripción textual, breve y concisa del
propósito del sistema, de no más de un párrafo. Debe incluirse la enumeración de los
beneficios tangibles y cuantificables que se lograrán con el nuevo sistema. Si se trata de un
sistema existente que se va a modificar, debe quedar claro en este documento. El empleo de
términos que hacen a la especificidad del negocio puede requerir que se le asocien notas
explicativas.
Por ejemplo:
“La Base Única de Datos de Alumnos deberá permitir el almacenamiento de los todos los
datos de alumnos que hoy manejan las escuelas de la ciudad, tanto de gestión
gubernamental como privada, incluyendo las calificaciones e información de presentismo.
Este sistema permitirá obtener estadísticas que hacen a la gestión de la Secretaría de
Educación, que hoy deben realizarse con métodos manuales, a la vez costosos e imprecisos,
además de centralizar en una única base de datos la información de alumnos de toda la
ciudad.”
2.2 Diagrama de contexto: Muestra en forma detallada las distintas interfaces
con el ambiente; grafica las personas, organizaciones, máquinas o sistemas con los que el
nuevo sistema se comunica, así como los datos que recibe y produce. Debe recordarse que es
una herramienta que debe permitir una comprensión con un golpe de vista.
A continuación, se muestra un diagrama de contexto (algunos lo llaman DFD de
nivel 0):
Pág. 4 de 23
En el mismo, el sistema se representa como un círculo en el centro, y las entidades
externas son rectángulos que lo rodean, con las interacciones entre ambos representadas por
flechas. Debe recordarse que debe ser entendido por el usuario, por lo que los términos deben
ser afines a su vocabulario.
2.3 Listado de eventos: Es especialmente importante en sistemas interactivos, no
justificándose su aplicación en desarrollos batch. Es un listado de estímulos que ocurren en el
ambiente a los cuales el sistema debe responder; debe incluir situaciones de fallo o error de
los agentes que estimulan al sistema. Puede reemplazarse con el catálogo de requerimientos.
2.4 Catálogo de requerimientos: Incluye los requerimientos, tanto funcionales
como de cualquier otro tipo, que pudieran haberse detectado en las entrevistas con usuarios.
Este documento suele ser un texto escrito en los términos de los usuarios, con posibles
aclaraciones que hagan al lenguaje de los desarrolladores. Dicho en forma coloquial, es como
el pasaje en limpio y en forma organizada de las entrevistas con los usuarios. Puede
reemplazarse por el listado de eventos recién descripto.
3. Glosario:
Es una descripción de términos que hacen al negocio, cuya comprensión es
necesaria por parte de diseñadores y programadores, y tiene la forma de un diccionario,
poniendo los términos y sus significados. Esto a veces no es necesario, ya sea porque los
términos son lo suficientemente corrientes o porque ya hubieran sido explicados en otros
documentos.
4. Diagrama de Gantt del proyecto:
Debe hacerse el plan de trabajo del proyecto en forma de Diagrama de Gantt o
similar, que luego se irá actualizando al final de cada etapa.
5. Modelo de comportamiento:
Define el comportamiento del sistema para manejarse con éxito en el ambiente.
Ese comportamiento se establece tomando como unidad cada una de los estímulos de la Lista
de Eventos ya comentada.
Incluye el contenido de los datos que el sistema almacena y que se mueven a
través de él.
Se traduce en:
Pág. 5 de 23
5.1 Diagrama de Flujo de Datos (DFD):
Es un diagrama que muestra los procesos y los flujos de datos entre los mismos. Se
lo llama también diagrama de burbujas. Es fundamental cuando las funciones o procesos son
más importantes que los datos.
Debe caber en una página y no tener más de 6 burbujas. Si no, hay que nivelarlo
en más diagramas.
En esta etapa se trata de un diagrama preliminar, que se irá actualizando.
A continuación hay un DFD de ejemplo:
Las burbujas son los procesos, los rectángulos almacenamientos de datos y las
flechas representan los flujos de información. Éste es otro diagrama para interactuar con
usuarios, por lo que también deben usarse términos de su dominio.
5.2 Especificación de procesos:
Es la especificación de los procesos que se diagraman en el DFD. De todas
maneras, sólo tiene sentido realizarlo cuando los procesos tengan cierta complejidad.
En una versión preliminar, la especificación se puede hacer con tablas de decisión,
de modo de no condicionar el diseño futuro. Los refinamientos sucesivos llevarán esta
especificación a lenguaje estructurado o pseudocódigo.
Una tabla de decisión es una tabla de doble entrada como la que sigue, que
muestra 5 casos distintos en función de valores de diferentes variables:
Emisor responsable inscripto
Emisor responsable no inscripto
Emisor exento
Receptor responsable inscripto
Receptor responsable no inscripto
Receptor consumidor final
Receptor exento
21% en fact A
Pág. 6 de 23
IVA a aplicar
1
2
3
X
X
X
4
5
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
31,5% en fact A
21% en fact B
0% en fact C
X
X
X
X
El pseudocódigo equivalente sería algo así:
Si emisor es responsable inscripto
Si receptor es responsable inscripto
Factura A
IVA <- 21%
Si receptor es responsable no inscripto
Factura A
IVA <- 31.5%
Si receptor es consumidor final
Factura B
IVA <- 21%
Si emisor es responsable no inscripto o exento
Factura C
IVA <- 0%
Fin
5.3 Diagrama de Entidad – Relación (DER):
Describe la distribución de datos en un sistema. Es fundamental en sistemas
centrados en datos. No es necesario si el sistema tiene poco o ningún acceso a bases de datos,
como algunos sitios web.
Lo que sigue es un DER simple, a modo de ejemplo:
En un DER, los rectángulos son tipos de objetos y los rombos relaciones.
5.4 Diccionario de datos:
Define de manera formal los datos del sistema.
Pág. 7 de 23
Como con los diagramas, es importante seguir una notación, como la de Yourdon,
de modo que la documentación sea comprensible por cualquier potencial lector.
A continuación se muestra un diccionario de datos elemental (la primera línea
muestra una composición e iteración, la segunda sólo una composición, la tercera una
especificación de rango y la cuarta una selección entre dos posibilidades):
Factura = cliente + dirección + { ítem de factura }
Cliente = nombre + DNI
DNI = rango 0 a 30.000.000
Dirección = [domicilio laboral | domicilio particular]
5.5 Diagrama de Transición de Estados (DTE):
Muestra los cambios de estado de los datos del sistema o de una parte del mismo.
Es importante en sistemas reactivos (los que suelen estar inactivos mientras no reciban
estímulos externos), con eventos, o para mostrar la vida de un objeto o cómo es afectado un
objeto en un determinado escenario. Hay casos de sistemas o procesos en los cuales los DTE
no aportan información.
A continuación se muestra un DTE simple de un contestador telefónico:
Inactivo
Esperando llamada
Grabando mensaje
Rebobinando
Reproduciendo
mensaje
Contestando
llamada
En un DTE, las elipses son estados y las flechas transiciones entre los mismos.
6. Modelo del procesador:
Es lo que permite pasar del modelo de análisis a los distintos componentes de
hardware, con sus comunicaciones. Habrá que incluir un diagrama de hardware, en el cual se
muestre el hardware sobre el que se implementará el sistema, y una justificación de la elección
del entorno tecnológico, en la cual se explican las consideraciones que se hicieron para elegir
dicho hardware.
A continuación se muestra un diagrama de hardware, en el cual se detallan qué
procesos se realizan en cada procesador:
Pág. 8 de 23
7. Modelo de tareas:
Se puede resumir en un Diagrama de Fronteras, que indique en forma gráfica los
componentes del hardware y las tareas que se hacen en cada uno de ellos. Es importante para
dar una idea general con un simple vistazo. En general, este es un diagrama importante en
sistemas distribuidos, de arquitectura de varias capas o aquéllos en los cuales haya que
mostrar claramente la frontera con otros sistemas de información. De no ser así, se podría
omitir, quedando el diagrama de contexto, el diagrama de hardware y los DFDs como
sucedáneos.
Véanse el siguiente diagrama de fronteras de ejemplo:
8. Modelo de implantación de programas
Organización jerárquica de módulos en una tarea. Se realiza con un Diagrama
estructurado.
Pág. 9 de 23
A continuación, hay un diagrama estructurado de ejemplo:
El diagrama estructurado no es apto para mostrar el comportamiento de sistemas
basados en eventos o reactivos. En estos casos conviene pasar directamente a diagramas en
UML u otra notación OO.
9. Interfaces de usuario
Se especifican con prototipos de las interfaces de usuario y reportes. Éstas pueden
consistir en dibujos o bocetos que muestren cómo van a ser las interfaces, aun cuando luego
estos sean modificados luego.
A continuación hay un prototipo de pantalla:
Pág. 10 de 23
10. Esquema de la Base de Datos
A continuación se muestra uno:
1) Listado de proyectos disponibles
2) Datos del proyecto seleccionado
3) Obras pertenecientes al proyecto seleccionado
...
11. Código fuente con documentación incorporada
La documentación incorporada se refiere a la documentación embebida en el código.
También deben documentarse las configuraciones que se deban hacer en la máquina
de desarrollo para que esas fuentes corran, como directorios especiales, variables
de entorno, DLLs y demás.
12. Documentación sobre las pruebas realizadas
Debe incluir una descripción de la metodología de pruebas (centradas en verificación
o en validación, de caja blanca o de caja negra, lotes de prueba, revisiones de
código, pruebas unitarias, de integración, de sistema y de aceptación).
13. Manuales
▪ Manual de procedimientos del usuario:
información sobre tutoriales y ayudas en línea.
▪
puede
reemplazarse
por
Pautas para la migración de datos, si la hubiese
▪ Manual de administración y soporte técnico: Es necesario que tenga una
descripción de los errores posibles del sistema, así como los procedimientos de
recuperación ante fallas y una guía de los problemas más comunes que se pueden
plantear.
▪ Descripción general para el funcionario no informático: puede ser un
simple diagrama que indique la funcionalidad general del sistema y su despliegue en
los distintos componentes de hardware, pero escrito en términos lo más corrientes
que sea posible.
Pág. 11 de 23
c.- Orientación a objetos
Debe tenerse especialmente en cuenta que las metodologías de orientación a
objetos no se basan en un enfoque algorítmico tradicional. Son metodologías dirigidas por
casos de uso, centradas en la arquitectura, iterativas e incrementales.
Todas las etapas se entienden como consecutivas, pero parcialmente superpuestas
(por ejemplo, se comienza el testeo antes del fin de toda la programación) y con
realimentación a etapas anteriores (por ejemplo, durante el diseño y la programación se
producen reajustes en la especificación de funcionalidades).
Por lo tanto, las pautas para documentar se han fijado en función de las fases,
utilizando la división en fases del Proceso Unificado de Desarrollo de Software.
FASE
DOCUMENTACIÓN
TAREAS
Inicio
Diagnóstico de la situación y necesidad del sistema
Detección de objetivos y límites del
sistema y su interacción con el
ambiente
Aspectos funcionales:
•
Declaración de propósitos
Despliegue tentativo
•
Diagrama de Contexto
•
Listas de casos de uso y actores, con
diagramas de casos de uso
Planificación de las iteraciones en
que se irá construyendo el sistema
•
Glosario
Aspectos Tecnológicos:
Elaboración
•
Diagrama de despliegue tentativo
•
Diagrama de Gantt del proyecto
Aspectos funcionales
•
Diagrama de la base de datos
•
Modelo de casos de uso para los más
importantes: lista y descripción de casos de
uso, con sus diagramas de actividades, de
interacción o de estado, si corresponde
•
Diagrama de clases conceptual (parcial),
esquemático y con responsabilidades
Aspectos no funcionales:
Construcción
•
Justificación del entorno tecnológico
•
Prototipos de pantallas y reportes
•
Diagrama de componentes mostrando la
arquitectura
•
Prioridades de los casos de uso descriptos
•
Normas de programación y estándares de
nomenclatura
Aspectos funcionales
Formalización de requisitos de
escalabilidad, disponibilidad,
seguridad, mantenimiento y
desempeño.
Descripción detallada de los casos
de uso más importantes.
Priorización de los mismos.
Determinación de las clases de
análisis (parcial), a partir de los
participantes de los casos de uso
descriptos. Descripción de su
comportamiento.
Determinación de las interfaces de
usuario para cada caso de uso
descripto.
Establecimiento de la arquitectura
de la aplicación. Determinación de
las clases de arquitectura más
importantes.
Diseño de la base de datos.
Determinación de las normas de
programación y estándares de
nomenclatura.
Descripción detallada de los casos
de uso restantes. Priorización de
los mismos.
•
Modelo de casos de uso para los restantes:
lista y descripción de casos de uso, con sus
diagramas de actividades, de interacción o
de estado, si corresponde
•
Diagrama de clases completo
•
Diagramas de comportamiento en los casos
necesarios: de estados y de interacción
Determinación de las clases de
análisis restantes, a partir de los
participantes de los casos de uso
descriptos. Descripción de su
comportamiento.
•
Código fuente (con documentación
Determinación del resto de las
Pág. 12 de 23
incorporada)
•
Documentación sobre pruebas realizadas
•
Esquema definitivo de la base de datos
Aspectos no funcionales:
Transición
clases de arquitectura y
descripción del comportamiento.
Diseño de las interfaces de
usuario.
Creación de la base de datos.
•
Prioridades de los casos de uso restantes
Codificación.
•
Prototipos de las interfaces de usuario
•
Diagrama de despliegue y componentes
definitivo
Realización de pruebas parciales y
de integración.
•
Manual de Usuario
•
Pautas para migración de datos
•
Manual de administración y soporte técnico
•
Descripción general para el funcionario no
informático
•
Actualización de toda la documentación que
sea necesario actualizar
Pruebas de sistema y de
aceptación
Cargas de tablas de configuración
Migración de Datos
Afinación
NOTA 1: Código fuente incluye no sólo las líneas codificadas en el lenguaje en que
se decida desarrollar la aplicación, sino los posibles stored procedures, el código que pudiera
estar embebido en formularios y cualquier pieza de software, local a la aplicación y necesaria
para que ésta funcione. También se incluye el código HTML, XML, ASP, JSP, PHP, o cualquier
otro usado en el desarrollo web.
NOTA 2: Todos los diagramas especificados se refieren a la notación UML, que se
puede consultar en “UML gota a gota”, Martin Fowler, Editorial Addison Wesley, 1999, ISBN
9684443641. También se recomiendan los libros sobre UML (“El lenguaje unificado de
modelado”) escritos en conjunto por Booch, Rumbaugh y Jacobson.
NOTA 3: El Proceso Unificado de Desarrollo de Software, que no necesariamente se
recomienda, pero del cual se ha extraído la división en fases, puede consultarse en “El Proceso
Unificado de Desarrollo de Software”, Ivar Jacobson, Grady Booch, James Rumbaugh, Editorial
Addison Wesley, 2000, ISBN 8478290362.
NOTA 4: Un buen curso de UML puede obtenerse en la Web, en castellano, en
http://www.dsic.upv.es/~uml/, tanto como presentación PowerPoint como en formato PDF.
Pág. 13 de 23
d.- Breve descripción de los documentos y diagramas
1. Documentos similares a los de la metodología estructurada
Hay algunos elementos que no cambian por utilizar una metodología OO. Por lo
tanto, su descripción puede encontrarse más arriba, en la metodología estructurada. Éstos
son:
•
Declaración de propósitos.
• Diagrama de contexto (aunque puede hacerse con un diagrama de casos de uso,
que veremos luego).
•
Glosario.
• Especificación de procesos con tablas de decisión (aunque también puede hacerse
con diagramas de interacción, los que veremos luego).
•
Diagrama de Gantt o similar.
•
Justificación del entorno tecnológico.
•
Prototipos de pantallas y reportes.
•
Normas de programación y estándares de nomenclatura.
•
Documentación sobre las pruebas.
•
Manual del usuario.
•
Manual de administración y soporte técnico.
•
Descripción general para el funcionario no informático.
2. Modelo de casos de uso:
Es una lista de los casos de uso, con sus descripciones, incluyendo flujos
alternativos, requisitos funcionales y no funcionales, pre y postcondiciones, algún diagrama de
actividades o de interacción si fuera necesario para aclarar el flujo de control y los
participantes (que se utilizarán para encontrar las clases de análisis).
A continuación, se muestra una ficha típica de un caso de uso:
Nombre de Caso de Uso:
Actualizaciones:
AUTENTICACIÓN DE USUARIO
Original Juan Pérez 17/6/2003
Actores:
Prioridad: Alta.
Todos
Descripción:
El usuario se conecta al sistema. Ingresa su nombre de usuario y contraseña. El sistema lo identifica e ingresa a
su entorno.
Flujos alternativos:
El nombre de usuario no es válido, se informa al usuario y se blanquean los campos.
La contraseña no es válida, se informa al usuario y se blanquean los campos.
El usuario ya se encuentra usando el sistema, se informa al usuario y se blanquean los campos.
Requisitos no funcionales:
El sistema no puede tardar más de 30 segundos en autenticar a un usuario.
Pág. 14 de 23
Precondiciones:
Ninguna
Postcondiciones:
El usuario tiene una sesión abierta en el sistema.
Se rechaza la solicitud.
Diagrama de Actividades:
No es necesario.
Participantes:
Usuario, Base de datos de usuarios autenticados.
Clases de análisis, responsabilidades, atributos:
A rellenar luego.
Prototipos de IU y reportes:
No es necesario especificarlos en este caso.
3. Diagramas de casos de uso:
Se usan para modelar:
•
especificaciones de servicios
•
contexto del sistema
•
capturan requerimientos funcionales
•
útiles en la interacción con el usuario
El que sigue es un diagrama de casos de uso:
Pág. 15 de 23
En el diagrama, los actores se representan como un esquema de persona, los casos
de uso como elipses y las comunicaciones con líneas. Los actores pueden ser cualquier entidad
externa, incluyendo otros sistemas.
4. Diagramas de actividades:
Se usan para modelar:
•
flujos de procesos
•
especificación de comportamiento de alto nivel
•
especificación de algoritmos
•
mostrar actividades concurrentes
•
mostrar distintos agentes u objetos en un flujo
•
generar casos de prueba
Véase el diagrama de actividades presentado en la próxima página.
Pág. 16 de 23
Cliente
Cajero
Inserta
tarjeta
Pide clave
Ingresa
clave
Chequea
clave
Banco
[clave incorrecta]
[clave correcta]
Pide monto
Chequea
saldo
Procesa
transacción
Retira dinero
Entrega
dinero
[saldo >=
monto]
Debita
cuenta
[saldo <
monto]
Muestra
saldo
Retira tarjeta
Expulsa
tarjeta
Los objetos se representan por “calles” en sentido vertical (sólo en el segundo de
los diagramas), y cada estado por el que van pasando por rectángulos redondeados. Las
flechas representan transiciones de estados. Hay nodos especiales para representar el
comienzo y fin de la actividad, así como rombos que representan ramificaciones, con el mismo
significado que tenían en los antiguos diagramas de flujo.
Pág. 17 de 23
5. Diagramas de interacción:
Se usan para modelar:
•
cómo un escenario puede ser realizado a través de un conjunto de
mensajes entre objetos
•
ayudan a encontrar las operaciones (métodos) de las clases
•
distintos objetos trabajando en conjunto
•
mensajes asíncronos
Para ello existen:
•
Diagrama de colaboración: enfatiza relaciones estructurales entre objetos
•
Diagrama de secuencia: enfatiza el paso del tiempo o el ciclo de vida de los
objetos
Pág. 18 de 23
Ambos diagramas son semánticamente equivalentes, es decir, se puede reemplazar
uno por el otro sin pérdida de información. En el de colaboración, el paso del tiempo está
representado por números asociados a los mensajes. Los mensajes, en ambos casos, se
representan con flechas, y los objetos con rectángulos, cuyo nombre se subraya. El diagrama
de secuencia muestra el ordenamiento temporal mediante un eje vertical, representando la
línea de vida de los objetos. En ambos es factible representar iteraciones, concurrencia,
mensajes síncronos y asíncronos, así como la muerte de un objeto.
6. Diagramas de estado:
Se usan para modelar:
•
comportamiento complejo de los objetos
•
estados concurrentes
•
pruebas de caja blanca
A continuación hay un diagrama de estados que muestra el juego del ajedrez:
/ Juegan las blancas
Turno de las blancas
Turno de las negras
/ Juegan las negras
/ Jaque mate
/ Tablas
/ Jaque mate
/ Tablas
Ganan las negras
Ganan las blancas
Un diagrama de estados está compuesto por nodos y los arcos, más un nodo
especial para indicar el comienzo y otro para indicar la finalización. En los nodos y los arcos se
pone una descripción del estado o evento que corresponda.
Dentro del nodo que corresponde a cada estado se puede poner un texto adicional
que especifique si el objeto se encuentra realizando alguna acción. Asimismo, en la descripción
de las transiciones se puede poner una condición que se deba satisfacer, entre corchetes, o
incluso parámetros que acompañen al evento.
7. Diagramas de clases:
Se usan para modelar:
•
la visión estática de todo el sistema
•
vocabulario de dominio del problema (sin operaciones)
•
clases de análisis con responsabilidades
•
clases de diseño (con atributos y operaciones)
•
estructura de la base de datos
•
analizar acoplamiento entre clases y paquetes
Pág. 19 de 23
Lo que sigue es un diagrama de clases de ejemplo:
1
cSistemaInscripcion
cPersona
*
*
cCurso
+ChequearCorrelativas()
+InscribirAlumno()
*
*
1
1
cAspirante
cDocente
+NotificarAlumno()
+ConsultarOpinion()
+PantallaInscripcion()
+ElegirCurso()
*
1
*
1
cProfesor
cCoordinador
+ConsultarOpinion()
+ConsultarOpinion()
1
1
cCurriculaAlumno
+ConsultarCurricula()
1
Las clases son rectángulos, con divisiones para el nombre de la clase, los atributos
y los métodos. Las asociaciones entre clases se representan con líneas, mientras las jerarquías
de herencia con flechas dirigidas hacia la clase ancestro. Se pueden especificar roles,
multiplicidad y grados de visibilidad.
De todas maneras, es importante recordar que un diagrama de clases debe ser
simple y orientado a mostrar no más de un tipo de relación (herencia, asociación o
colaboración). Por lo tanto, lo ideal va a ser separar los diagramas que muestren las jerarquías
de las clases de los que muestren las asociaciones.
Un diagrama de clases se puede hacer también en forma más esquemática en las
primeras etapas del desarrollo. A continuación se muestra un diagrama de clases conceptual,
en el que no se indican atributos, métodos ni relaciones de herencia:
cPedido
cCliente
*
1
1
*
+Artículos de línea
cLineaDePedido
8. Diagramas de componentes y despliegue
Se usan para modelar el despliegue de los distintos componentes de software sobre
el hardware.
A continuación, se muestra un diagrama de despliegue con sus componentes:
Pág. 20 de 23
Cada cubo representa un nodo de hardware, y las líneas que los unen son
conexiones. Dentro de cada nodo se han representado componentes software, que son
rectángulos con bisagras, que a menudo implementan una interfaz, representada con círculo
pequeño. Las dependencias se representan con flechas discontinuas.
Pág. 21 de 23
e.- Sobre el mantenimiento de la aplicación luego de su puesta en
producción
Denominamos mantenimiento a las tareas de corrección de errores, evolución por
cambio de requerimientos y preservación para mantener operable un sistema, una vez que se
encuentra en producción.
El mantenimiento debe incluir siempre la actualización de la documentación
asociada, amén de mantener la documentación de versiones anteriores.
Los procesos de modificación pueden variar en su grado de complejidad, desde
correcciones de errores pequeños hasta cambios funcionales que impliquen la inclusión de
nuevos procedimientos o funciones; a continuación se presenta una lista de eventos que
derivan en procesos de modificación:
•
Identificación de errores (“bugs”) de programas.
•
Necesidad de adicionar nuevas características o capacidades.
•
Cambios de requerimientos funcionales.
•
Aumento / disminución en el ámbito de aplicación del sistema.
•
Adaptaciones por cambios en el entorno operativo del mismo.
Más allá del tipo de cambio (correctivo ante errores, adaptativo a cambios en el
entorno del funcionamiento de la aplicación o perfectivo, ya sea en funcionalidad o afinación),
importa su grado de impacto. Y ello determinará el nivel de documentación de respaldo
necesario.
Para la resolución de errores que no afecten la estructura modular de las
aplicaciones y para cambios estéticos en las interfaces de usuario (tipo de letras, color), como
ejemplo, será suficiente habilitar un Anexo a la Documentación, el Registro de Modificaciones.
El Registro contendrá, para cada modificación, fecha del pedido, solicitante, descripción del
cambio, fecha de concreción y versión en la que es incluido.
Los cambios funcionales (agregado de nueva funcionalidad o modificación en las
características de la que el sistema ya provee) implican, para su concreción, un volver a
recorrer las etapas de desarrollo de la aplicación; por consiguiente, y en forma paralela a su
realización, esos cambios impactarán en la documentación, desde la que refleja el análisis de
requerimientos hasta el Manual del Usuario. Por ello nuevas versiones de la documentación
acompañarán las nuevas versiones de la aplicación.
Es factible que estos cambios impliquen también cambios estructurales. Los
cambios estructurales darán lugar a nuevas versiones de los modelos que reflejan las
estructuras de datos, desde el Diccionario de Datos o Diagrama de Clases al Esquema
definitivo de la Base de Datos. Si impactasen en el diseño de pantallas o la funcionalidad, el
cambio se reflejará también en el Manual del Usuario. No se reflejará en la documentación
para el usuario todo aquello que no impacte en su forma de uso del sistema, como, por
ejemplo, optimizaciones.
Los cambios en el entorno tecnológico se reflejarán en la documentación que alude
al entorno tecnológico.
En cualquier caso se deberá generar una nueva versión del código fuente, con el
respectivo número de versión, que también forma parte de la documentación.
Pág. 22 de 23
f.- Forma de entregar la documentación
Cuando deba entregarse, la documentación se presentará en CD.
Los formatos de los archivos a entregar deberán ser alguno de los siguientes:
•
Texto puro: extensión .TXT, o la extensión que corresponda en el caso de ser código
fuente.
•
Documentación textual: preferentemente en PDF, de otra manera Microsoft Word
(.DOC) u OpenOffice (.ODT).
•
Planillas de cálculo y tablas: Microsoft Excel (.XLS) u OpenOffice (.ODS)
•
Presentaciones: Microsoft Powerpoint (.PPT) u OpenOffice (.ODP)
•
Diagramas: Microsoft Visio Drawing (.VSD), Dia (.DIA), OpenOffice (.ODG) u otro
formato vectorial, pero preferentemente enviándolo también en PDF.
•
Si se envían archivos compactados, se utilizará un formato estándar, como zip o
tar.gz.
El código fuente debe entregarse también en CD, con la estructura de directorios o
carpetas con que está implementado, de modo de garantizar que se pueda chequear antes de
dar la aprobación. También deben documentarse las configuraciones que se deban hacer en la
máquina de desarrollo para que esas fuentes corran, como directorios especiales, variables de
entorno, DLLs y demás.
Pág. 23 de 23