Diseño de Proyectos de

software en código abierto



José Manuel Godoy Giménez


email: josemanuel.godoy@hispalinux.es

  1. 1 Noviembre 2002


Integrado en el proyecto de Gestión Libre



Indice

1 Introducción


    1. Histórico

    2. Licencia de éste Cómo

    3. Copyrights y Marcas registradas

    4. Obtener 'Diseño software en código abierto'

    5. Motivaciones

    1. Sugerencias críticas y aportaciones

    2. Situación del documento

    3. Agradecimientos


      1. Proyectos software

    1. Comienzo de un proyecto software

    2. Métricas del software orientadas a la función

    3. Reusabilidad

    4. Plan del proyecto


      1. Análisis del proyecto

    1. ¿Dónde estamos?

    2. Análisis del sistema

      1. Identificación de necesidades

      2. Estudio de viabilidad

      3. Análisis técnico

    1. Especificaciones del sistema

      1. Esquema de especificación del sistema

      2. Diagrama de arquitectura


      1. Especificación de requisitos

    1. ¿Dónde estamos?

    2. Fundamentos

    3. Notación básica

      1. Diagrama de Flujo de Datos

      2. Diagrama de Flujo de Control

      3. Modelo Entidad - Relación

    1. Análisis orientado a los objetos.

      1. Identificación de los objetos

      2. Especificación de los atributos

      3. Definición de las operaciones

      4. Comunicación

      5. Especificación del objeto.


            1. Diseño del software

    1. ¿Dónde estamos?

    2. Procesos de diseño

    3. Fundamentos de diseño

      1. Abstracción

      2. Refinamiento

      3. Modularidad

      4. Diseño modular efectivo

      5. Jerarquía de control

      6. Estructura de datos


    1. Diseño de datos

    2. Diseño Arquitectonico

    3. Diseño procedimental


6 Modelos de documentos


    1. Documento de Requisitos del Software

    2. Documento de Diseño del Software


7 Un ejemplo, el proyecto Gedaco


    1. Introducción a Gedaco

    2. Documento de Conceptos del Sistema

    3. Documento de Especificación de Requisitos

    4. Documento de Diseño de Software

    5. Modelo de datos


  1. Modelado mediante UML

    1. Introducción

    2. Notación

      8.2.1 Diagramas de casos de uso

      8.2.2 Relaciones de los casos de uso

      8.2.3 Diagramas de clases

      8.2.4 Diagramas de secuencia

      8.2.5 Diagramas de gráfica de estado

      8.2.6 Diagramas de actividad

      8.2.7 Organización de los diagramas

      8.2.8 Extensiones al diagrama

    3. Diseño con UML

      8.3.1 Obtención de requerimientos

      8.3.2 Documentación de la obtención de requerimientos

    4. Análisis con UML

    5. Actividades de diseño en UML



  1. INTRODUCCIÓN

    1. Histórico


Este documento nace como consecuencia del proyecto de Gestión Libre bajo el auspicio de Hispalinux. El objetivo del mismo es dar unas reglas generales para el desarrollo de software en el mundo del código abierto (open-source).


Si te has bajado este documento de un lugar distinto de hispalinux sería conveniente que compruebes que se trata de la última versión.


Esta es la versión 1.1 de Noviembre del 2002.


Autor: José Manuel Godoy Giménez ( josemanuel.godoy@hispalinux.es)


    1. Licencia


Derechos de autor © José Manuel Godoy Giménez.

Este documento se distribuye con permiso de copia y/o modificación bajo los términos de la Licencia de Documentación Libre GNU, Versión 1.1 o cualquier otra posterior publicada por la Free Software Foundation. Puedes leer la licencia original en:


http://www.gnu.org/copyleft/copyleft.html


También puedes obtener una traducción de la misma no oficial en la web de hispalinux en la dirección:


http://www.hispalinux.es/Licencias/fdles/fdl-es.html


Se consideran como Secciones Invariantes la distribución de secciones de todo el documento incluyendo la portada y los ejemplos, así como los modelos de documentos e imágenes explicativas que se utilizan a lo largo del mismo.


    1. Marcas registradas


Linux y otras marcas comerciales que se utilizan en este Documento son registrados en copyrights y/o están reclamados como Marcas registradas de ciertas personas y/o compañias.


    1. Obtención de este documento


Se puede obtener el presente documento a través de Hispalinux,

http://www.hispalinux.es


o bien en la página personal del autor:

http://www.fut.es/~jgodoy


    1. Motivaciones

El presente documento intenta (no se si lo conseguirá), permitir al mundo del código abierto la posibilidad de embarcarse en proyectos de envergadura que requieran un estudio serio.


Debemos de tener en cuenta que el código abierto es extremadamente seguro y robusto, y que cuando aparece algún error (odio decir 'bug') se soluciona rápidamente, incluso en horas, sin embargo, tiene fama de poco serio. Es en estas ocasiones cuando se debe de tener en cuenta la validez de la frase "La mujer del Cesar no sólo debe ser honrada sino que tiene que parecerlo".

Con la mente puesta en esta frase, y dado la tendencia actual de valorarlo todo en base a la calidad debemos de tener en cuenta las etapas básicas en la planificación de la calidad, para poder aplicarlas a nuestra aplicación software:


Estas etapas son las que se tratará de definir e identificar a lo largo de este documento, el cual espero que no se os atragante .


    1. Sugerencias críticas y aportaciones


Las preguntas, comentarios correcciones y sugerencias serán siempre bien recibidas, sobre todo en las primeras versiones de este documento, estas pueden ser dirigidas a josemanuel.godoy@hispalinux.es


    1. Situación de este documento

La versión que estas leyendo es la versión 1.1 sin embargo no es el documento final. Le faltan por desarrollar los ejemplos de UML que ayudarán a comprender este lenguaje de modelado.

También es idea del autor realizar una serie de apéndices que permitan localizar rápidamente los documentos , gráficos y técnicas de modelado que se utilizan en este documento.


Si te animas puedes colaborar, no te cortes :-) .

Evolución del documento

  1. Versión 0.0 Análisis Estructural.

  2. Versión 1.0 Ejemplo de Análisis Estructural Gegaco

  3. Versión 1.1 Se incluye descripción teórica del lenguaje de modelado UML


    1. Agradecimientos

Agradezco los apoyos prestados por Fernando Acero, coordinador del proyecto Gestión Libre de Hispalinux, así como los comentarios y rollos que me ha prestado Carlos Moreno (Neurostar).

Así como a todos los que han colaborado con correcciones, sugerencias y enumeración de puntos oscuros de la primera versión de este documento.






  1. PROYECTOS SOFTWARE

    1. Comienzo de un proyecto software


Antes de poder empezar a planificar un proyecto, deben establecerse los ámbitos y los objetivos, considerar soluciones alternativas e identificar las restricciones técnicas y de gestión. Sin tener esta información clara, es imposible obtener un identificación realista de las tareas del proyecto o un plan de trabajo adecuado que proporcione una indicación significativa del progreso.


Los objetivos identificarán los fines globales sin considerar cómo se llegará a esos fines. El ámbito identificará las funciones primordiales que deben llevar a cabo el software, intentando limitarlas de forma cuantitativa, es decir, que debe hacer y que NO debe hacer el sistema software.


Tras comprender los objetivos y el ámbito del proyecto, se han de considerar las soluciones alternativas, ya que ésto permitirá al desarrollador seleccionar el 'mejor' enfoque, dadas las restricciones de fechas, presupuestos (recordar que software libre # gratis), colaboradores que programan, etc.



    1. Métrica del software orientada a la función


El diseño de una aplicación software es un desafio técnico, y como tal, el hecho de medir sus características y funcionalidades ayudará a la comprensión del proceso que se utiliza para desarrollar un producto.


Dado que frecuentemente la medición conlleva controversia y discusión, en este documento se adoptará una métrica orientada a la función. Las métricas de software orientadas a la función son medidas indirectas del software y del proceso por el cual se desarrolla y se centran en la funcionalidad o utilidad del programa.


Para conseguir evaluar la productividad del programa se utilizan puntos de función, que son una serie de valoraciones subjetivas de la complejidad del software.

Los valores de la información se definen:


Un documento tipo que recoja este estudio sería:

Parámetro de medida

Valor

Factor de peso

Total

Simple

Medio

Complejo


Entradas de usuario


3

4

6


Salidas usuario


4

5

7


Peticiones al usuario


3

4

6


Nº de archivos


7

10

15


Nº de interfaces


5

7

10


Total


    1. Reusabilidad

No hay un estudio de recursos software si no se considera la reusabilidad, que es la creación y reutilización de bloques constructivos de software. Esto es especialmente cierto centrándonos en el caso del código abierto (open source o Free software). Estos bloques constructivos deberían catalogarse para una fácil referencia, estandarizados para una fácil aplicación y validados para facilitar la integración. Esto nos da dos máximas que debemos seguir todos los desarrolladores de código abierto:

  1. Si el software existente satisface los requisitos lo usaremos.

  2. Si el software existente requiere alguna modificación para su integración en el sistema, esta se hará con un estudio previo ya que puede ser más económico desarrollar un software nuevo.

    1. Plan del proyecto


En todo proyecto software debe existir documentación que permita evaluar y trabajar de forma paralela al mismo, y que pueda servir de base para los pasos posteriores. El plan de proyecto de software es la culminación de la etapa de planificación. Proporciona una línea de base con información de costes y de agenda.

El plan de proyecto de software es un documento relativamente breve, dirigido a una audiencia diversa y contendrá los siguientes puntos:



  1. ANÁLISIS DEL PROYECTO

    1. ¿Dónde estamos?






    1. Análisis del sistema


En un sistema por computadora se distinguen los siguientes elementos:


      1. Identificación de necesidades


Es el primer paso en el análisis del sistema y el punto de partida; la información que se debe manejar en éste punto es:


Toda esta información se recoge en un documento de conceptos del sistema


      1. Estudio de viabilidad


Todo proyecto es realizable, siempre y cuando los recursos sean ilimitados y el tiempo infinito. Como estas circunstancias difícilmente se dan en la vida real se debe (con prudencia) evaluar la viabilidad del proyecto, éste estudio se centra en cuatro áreas:



El documento de viabilidad debería tener un esquema como el siguiente:


  1. Introducción

  1. Recomendaciones de gestión e impacto

  2. Alternativas

  3. Descripción del problema

  1. Análisis de costes

  2. Evaluación del riesgo técnico.

  3. Consideraciones legales

  4. Otros aspectos específicos del sistema


      1. Análisis técnico


En este periodo se analizan los méritos técnicos del concepto de sistema, a la vez que se recoge información adicional sobre el rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de producción. Normalmente incluyen una capacidad limitada de investigación y de diseño.

El análisis técnico comienza con la definición de la viabilidad técnica del sistema propuesto:


Como conjunto de criterios para el uso de modelos durante el análisis técnico de sistemas tenemos (Blanckard y Fabrycky):

  1. El modelo debe ser simple de comprender y manipular, pero debe estar cerca de la realidad operativa

  2. El modelo debe realzar los factores relevantes del problema y suprimir los que no lo sean. Debe ser fiable en cuanto a repetición de resultados.

  3. El diseño debe permitir modificarlo y/o expandirlo fácilmente y permitir la evaluación de factores adicionales si se requieren.


Las herramientas CASE de simulación y creación de prototipos pueden ayudar en el análisis técnico. Los resultados del análisis técnico son la base de la decisión de seguir o no con el sistema o con el planteamiento sobre el mismo.


    1. Especificaciones del sistema


La especificación del sistema es un documento que sirve como base para el desarrollo de cualquier sistema software, incluyendo el hardware y la necesidad de bases de datos, describe la función y el rendimiento de un sistema basado en la computadora y las restricciones que gobiernan su desarrollo. También describe la información (control y datos) que sirve de entrada y salida del sistema


      1. Esquema de especificación del sistema


Un esquema recomendado para la especificación sería:


  1. Introducción

A- Ambito

B- Visión general

    1. Objetivos

    2. Restricciones


  1. Descripción funcional y de datos

A- Arquitectura del sistema

I Diagrama de contexto de arquitectura (DCA)

II Descripción del DCA

  1. Descripción de los subsistemas

A- Especificación del diagrama de estructura

B- Diccionario de datos

C- Diagramas y descripción de la interconexión de la arquitectura

  1. Resultados de la modelización y simulación del sistema (si hay lugar).

A- Modelo del sistema usado para la simulación

B- Resultados de la simulación

C- Aspectos especiales del rendimiento

  1. Aspectos del proyecto

A- Costes del proyecto

B- Agenda

  1. Apéndices


      1. Diagrama de arquitectura


Como todas las técnicas de modelización utilizadas en la ingeniería del software y de sistemas, la plantilla de arquitectura permite crear una jerarquía de detalles. En el nivel superior está el diagrama de contexto de la arquitectura (DCA).

El DCA establece los límites de información entre los que se está implementando el sistema y el entorno en que va a funcionar el sistema, es decir, productos y consumidores de información del sistema y todas las entidades que se comunican a través de la interfaz.


  1. ESPECIFICACIÓN DE REQUISITOS

    1. ¿Dónde estamos?



    1. Fundamentos

La especificación de requisitos es la tarea que establece un puente entre la asignación de software a nivel de sistema y el diseño software. Los princios de toda especificación son:


    1. Notación básica


Cuando se trabaja con un sistema basado en computadora, la información fluye y se transforma. El sistema admite entradas, aplica los elementos software y humanos para transformar la entrada en salida. Por ello puede considerarse como natural especificar un sistema como un flujo de información, mediante los diagramas de flujo de datos.


      1. Diagrama de Flujo de Datos (DFD).


El DFD es una técnica gráfica que representa el flujo de información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida, también se conoce como diagrama de burbujas.

El DFD comienza por el nivel 0, modelo fundamental del sistema o modelo de contexto, y representa el elemento de software completo como una sola burbuja con los datos de entrada y salida representados por flechas de e/s.

Notación básica:

En un DFD un rectángulo representa una entidad externa, es decir, un elemento del sistema, u otro sistema que produce información. Un circulo representa un proceso o transformación que se aplica a los datos y los cambia. Las flechas indican el flujo de información y deben estar etiquetadas. La línea doble representa un almacén de información.



Utilización

Partiendo de una definición de la función genérica del sistema software, nivel 0, se van expandiendo las distintas burbujas en distintos niveles para mostrar un mayor detalle, hasta llegar a niveles de función. Es importante mantener la continuidad del flujo de información, es decir, que la entrada y la salida de cada refinamiento debe ser la misma.

Así por ejemplo en un diagrama de flujo de datos de un cajero, que indique la impresión de un resguardo si tenemos un DFD de nivel 0 cuya entrada es Cajero y la salida es Impresión cuando hagamos la explosión al nivel 1 se debe de mantener la correspondencia.


El DFD de nivel 1 que sería la explosión del proceso de impresión sería:


Como se puede observar el DFD de nivel 0, tiene una entrada de petición de cuenta y una salida en forma de impresión. Cuando eclosionamos el proceso imprimir saldo en el DFD de nivel 1 mantenemos el mismo flujo de entradas y salidas.

Para crear un DFD se pueden seguir estas directrices:

  1. El DFD de nivel 0 debe reflejar el software/sistema como una sola burbuja.

  2. Se deben de anotar cuidadosamente la entrada y salida principal.

  3. Comenzar el refinamiento aislando los procesos, los objetos de datos y los almacenes de datos que sean candidatos a ser representados en el siguiente nivel.

  4. Todas las flechas y burbujas se rotularán con nombres significativos.

  5. Entre sucesivos niveles se debe mantener la continuidad del flujo de información.

  6. Refinar las burbujas de una en una.


      1. Diagrama de Flujo de Control


Toda aplicación está 'conducida' además de por los datos, por sucesos que complementan la visualización de la información. Los diagramas de flujo no premiten que se representen expecíficamente los flujos de control, esta exclusión es muy restrictiva (sobre todo para sistemas en tiempo real), por este motivo se ha desarrollado una notación especializada para la representación del flujo de sucesos y del procesamiento de control, esta notación y su funcionamiento es muy similar a los DFD.




Así por ejemplo, una estación de ajuste de temperatura tendría el siguiente DFC:



      1. Modelo Entidad-Relación


La técnica que se expone a continuación se centra únicamente en los datos, no en las acciones que se realizan en ellos, representando una 'red de datos', esta modelización es imprescindible para las aplicaciones en las que los datos y las relaciones que gobiernan los datos son complejos, y útil en cualquier caso. Esta modelización se usa ampliamente en aplicaciones de bases de datos (en consecuencia en el 99'99% de las aplicaciones de gestión), proporcionando una amplia visión de los datos y las relaciones que gobiernan los datos.

La notación principal de la modelización de los datos es el diagrama entidad relación (E-R), estos diagramas están compuestos de objetos de datos, atributos, relaciones e indicadores de tipo, y su principal propósito es representar los objetos de datos y sus relaciones.


        1. Diagramas entidad relación


La estructura lógica global de una base de datos puede representarse gráficamente por medio de un Diagrama Entidad-Relación en cual consta de los siguientes elementos:


Asignatura



Alumnos








Y las tablas serían:

ALUMNOS (Dni, Nombre)

ASIGNATURA (Nombre, Curso)

ALUM_ASIG (Dni,NomAsig, nota)

En subrayado la clave primaria de cada tabla.


        1. Formas normales


Almacenar los datos no es tan sencillo como parece, y cuando trabajamos con decenas de miles de datos debemos protegernos de inconsistencias entre los datos, redundancia de algún dato y debemos optimizar las busquedas de los datos. Esto se consigue mediante un diseño E-R basado en tercera forma normal (3NF), que consta del siguiente análisis.


Primera forma normal: Una relación se encuentra en primera forma normal (1NF) si y sólo si los valores en los dominios son atómicos, que en cristiano quiere decir que dentro de cada fila-columna de una relación siempre hay un y sólo un valor, nunca un conjunto de múltiples valores.

Por ejemplo en una tabla que almacenemos clientes con el DNI, nombre, primer apellido y segundo apellido, es incorrecto y poco eficiente hacer un campo que contenga el primero y el segundo apellido.

Segunda forma normal: Una relación se encuentra en segunda forma normal (2FN) si y sólo sí está en primera forma normal y los atributos no clave dependen por completo de la clave primaria. La clave primaria es aquella que identifica inequívocamente un datos (en el ejemplo anterior el DNI). Es decir, que todas las filas se deben de poder recuperar de forma única por la clave primaria (que evidentemente será única)

Como se ve estas dos formas normales son de cajón.

Tercera forma normal: Una relación está en tercera forma normal (3FN) si está en segunda forma normal y todos sus atributos no clave dependen de forma no transitiva de la clave primaria. Esto es un poco más difícil de ver, pero con un ejemplo no supone problema.

Para la representación del nombre y dirección del individuo podíamos tener la tentación de definir la tabla como sigue:

Tabla Individuo (Dni, nombre, apellido, Sapellido, Codigo_Postal, Provincia)

Bien si estudiamos gráficamente esta definición y prestamos un poco de antención vemos que tiene la siguiente forma:



Es decir, el código postal identifica inequívocamente la provincia de residencia y no es algo que depende del idenficador del individuo. Esto implica que una definición así supone un aumento indecesario del tamaño de la base de datos y una fuente de inconsistencias de la misma. La solución en estos casos es siempre la descomposición de la tabla que sufre el problema en varias tablas, tantas como haga falta para solucionarlo.

En este caso sólo es necesario una descomposición de la tabla individuos en dos tablas:

Tabla Individuo (Dni, nombre, apellido, Sapellido, Codigo_Postal)

Tabla Provincia (Codigo_postal, Provincia)

Además el código postal lo consideraremos en la tabla Individuo como una clave ajena de la tabla Provincias, de forma que aseguraremos que los valores introducidos para los individuos existan realmente como provincias.

Para más información os remito a cualquier libro de diseño de bases de datos, ya que este tema se escapa del ámbito del documento, aquí nos quedamos con que para presentar un diseño necesitamos que las tablas estén en tercera forma normal y la forma de representación.

    1. Análisis orientado a los objetos


El análisis de los flujos de datos es inútil cuando lo que pretendemos es abordar la implementación del sistema a partir de un lenguaje que maneje objetos (C++, Pyton ... etc) y deseemos explotar estas características, debemos entonces de orientar el análisis hacia los objetos.

      1. Identificación de objetos


Para identificar los objetos se estudia la narrativa de procesamiento del sistema a construir (descripción del programa), seleccionando los nombres o claúsulas nominales. Serán los posibles objetos, que pueden ser:

También es importante determinar lo que no son objetos con el fin de evitar errores en el análisis del sistema.

En este momento tenemos una serie de objetos potenciales, se deben de estudiar cada uno de ellos para poder tenerlos como objetos reales. Se pueden ver seis características selectivas para incluir o no un objeto potencial en el modelo de análisis (Coad y Yourdon).

            1. Información retenida: La información sobre el objeto debe ser recordada para que el sistema pueda funcionar.

            2. Servicios necesarios: El objeto debe de tener un conjunto de operaciones identificables que puedan cambiar de alguna forma el valor de sus atributos.

            3. Múltiples atributos: En el análisis, los objetos con un sólo atributo pueden presentar problemas de representación (se debe generalizar)

            4. Atributos comunes: Se pueden definir un conjunto de atributos para los objetos.

            5. Operaciones comunes: Se pueden definir un conjunto de operaciones para los objetos.

            6. Registros esenciales: Las entidades externas que consumen o producen información casi siempre se definen como objetos.


      1. Especificación de atributos

Los atributos de un objeto son evidentemente dependientes de la aplicación, así un objeto persona tiene atributos si hacemos una aplicación fiscal, si la aplicación es del padrón tendrá unos atributos comunes con la otra aplicación pero tendrá otros totalmente distintos. Por ello es importante revisar la narrativa de la aplicación y contestar a la siguiente pregunta: ¿Qué elementos de datos definen completamente al objeto en el contexto del problema actual?.

      1. Definición de las operaciones


Una operación cambia un objeto en alguna forma, por ello las operaciones deben ser implementadas de forma que puedan manipular las estructuras de datos que se hayan derivado de los atributos.


Las operaciones se pueden dividir en tres grandes categorías, las que manipulan los datos de alguna forma, las que realizan algún cálculo y las que monitorizan un objeto frente a la ocurrencia de algún suceso de control.


Para obtener el conjunto de operaciones de los objetos se debe de estudiar la narrativa del problema y seleccionar las operaciones que se correspondan, para ello sirve de guía realizar un estudio sobre los verbos, ya que indican las operaciones legítimas y permite una conexión directa con un objeto específico. Además del análisis de los verbos, otra forma de comprender mejor las operaciones es considerando la comunicación entre objetos.


      1. Comunicación


La definición de los objetos sirve de base para el diseño, sin embargo se debe de añadir algo más para que se pueda construir el sistema, se debe de establecer un mecanismo para la comunicación entre los objetos. Este mecanismo se denomina mensaje, tiene la forma siguiente:

mensaje : (destino, operación, argumentos)

Donde destino define el objeto que recibe el mensaje, operación se refiere a la operación que va a recibir el mensaje y argumentos proporciona información para llevar a cabo la operación. Por ejemplo el objeto A puede enviar un mensaje el objeto C de la forma

mensaje : (C, op_8, <datos>)

Entonces C busca 'op_8', la realiza con los datos y le devuelve el control a A.


      1. Especificación de objetos


Finalmente se reune toda la información sobre los objetos en un documento de Especificación de objetos cuyo formato será el siguiente:

      1. Nombre del objeto

      2. Descripción de atributos

        A. Nombre del atributo

        B. Contenido del atributo

        C: Tipo/estructura de datos del atributo

      3. Entrada externa al objeto

      4. Salida externa del objeto

      5. Operaciones

        A. Nombre de la operación

        B. Descripción de la interfaz de la operación

        C. Descripción del procesamiento de la operación

        D. Aspectos de rendimiento

        E. Restricciones y limitaciones.

      6. Conexiones de mensaje









  1. DISEÑO DEL SOFTWARE

    1. ¿Dónde estamos?


Tras analizar los requisitos del sistema, y habiendo implementado los modelos de información, funcional y de comportamiento estamos preparados para abordar el diseño.

La etapa de diseño, previa a la codificación (por fin código...) está dividida en tres tipos, diseño de datos, arquitectónico y procedimental.

Aunque parezca lo contrario, por todo el rollo que llevamos expuesto, la fase de diseño, codificación y prueba absorben el 75% del desarrollo del software (excluyendo el mantenimiento). La importancia del diseño (para frenar las ganas de crear código rápidamente) se resumen en una palabra: calidad.





El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software, que incicialmente da una visión del mismo y tras posteriores refinamientos nos conducirá a una representación de diseño muy cercana al código fuente. Actualmente además del diseño de datos, arquitectónico y procedimental se debe de prestar especial atención al diseño de la interfaz.


    1. Fundamentos de diseño


'El comienzo de la sabiduría de un programador está en reconocer la diferencia entre obtener un programa que funcione y uno que funcione correctamente' (M.A. Jackson megagurú de programación). Ante esta afirmación lo más que se puede decir, quizás, es que los conceptos fundamentales del diseño de software nos darán la base necesaria para que 'funcione correctamente'.


        5.2.1 Abstracción


Mediante la abstracción nos podemos concentrar en un problema con indepencia de lo que haya en niveles más bajos, en los niveles superiores de abstracción utilizaremos el lenguaje del problema para establecer la solución en términos amplios; en niveles inferiores toma una orientación más procedimental.

En palabras llanas, y fuera del ámbito de la programación y la informática, sí estamos buscando una solución para colocar nuestra televisión en el comedor de casa, en un primer lugar nos planteamos el lugar físico, obviamos el mueble y la forma de construirlo. Cuando tenemos elegido el lugar, procedemos a diseñar nuestro mueble (nos da lo mismo como lo vamos a hacer y en principio los materiales que usaremos), estamos en un nivel inferior de abstracción.


Finalmente entramos en el nivel de abstracción procedimental, elegimos los materiales y la forma de construcción (sólo cómo encajaremos la piezas, el diseño ya está hecho). Si lo miramos sin complejos, es una forma natural de proceder, se trata simplemente, de no empezar la casa por el tejado, algo que a los programadores nos gusta mucho, lanzarnos en plancha a realizar código del programa al alcanzar un mínimo de diseño del sistema.

Dejando de lado el martillo y el taladro, volviendo al mundo del software, conforme nos movemos por diferentes niveles de abstracción, crearemos abstracciones de datos y de procedimientos. Una abstracción de datos es una colección de información que describe un objeto, un ejemplo sería un documento de empadronamiento, en realidad está formado por varios trozos de información, pero nos podemos referir a todos mediante su nombre. Una abstracción procedimental es una determinada secuencia de instrucciones que tienen una función limitada y específica. Una tercera forma de abstraccion sería la abstracción de control, que implica un mecanismo de control del programa sin especificar los detalles internos.

En la abstracción, definimos a grandes rasgos lo que hace el programa, los datos que utiliza y como los controlamos, aquí aparecen los primeros términos orientados al software como 'repetir hasta'.

5.2.2 Refinamiento


El refinamiento sucesivo nos permite, como estrategia de diseño, partir de una declaración generalista de una función hasta llegar a las sentencias del lenguaje (Nirklaus Wirth). En cada paso del refinamiento, una o varias instrucciones del programa se descomponen en instrucciones más detalladas, esta descomposición termina cuando todas las instrucciones están expresadas en términos de la computadora usada.

Por fin llegamos al código, ya que el refinamiento es realmente un proceso de elaboración, comenzamos con la declaración de una función, que hemos definido en el nivel superior de abstracción (que no proporciona información sobre su funcionamiento y/o estructura), el refinamiento permite ampliar la declaración dando cada vez más detalles.


5.2.3 Modularidad

El concepto de modularidad para el software se tiene en cuenta practicamente desde los años 50, el software se divide en componentes con nombres y ubicaciones determinados, que se denominan módulos y que se integran para satisfacer los requisitos del problema.

El software monolítico, un programa compuesto por un único módulo, es inabarcable y prácticamente irrealizable dado que el número de caminos de control, expansión de las referencias, número de variables y complejidad global, pueden hacer imposible su correcta comprensión.

La solución, como muchos problemas en el mundo de la programación, se encuentra por el axioma de 'divide y vencerás', es más fácil resolver un problema complejo cuando se divide en trozos manejables.

El esfuerzo de desarrollo de un módulo individual disminuye conforme aumenta el número total de módulos; sin embargo, al crecer el número de módulos, el esfuerzo de realizar las interfaces de conexión entre los módulos también crece. Esto quiere decir que debemos evitar tanto una excesiva modularización como una muy pobre.


5.3.4 Diseño modular efectivo

Un diseño modular reduce la complejidad, facilita los cambios (aspecto crítico en la facilidad del mantenimiento) y produce como resultado una implementación más sencilla, permitiendo el desarrollo paralelo de las diferentes partes de un sistema; vamos que es ideal para el mundo del código abierto donde trabajan varias personas en un proyecto.


Un principio que ayuda en el proceso de descomposición modular es el de ocultamiento de la información, el cual sugiere que los módulos se han de 'caracterizar por decisiones de diseño que los oculten unos a otros'; es decir, los módulos deben especificarse y diseñarse de forma que la información (procedimientos y datos) contenida dentro de un módulo sea inaccesible a otros módulos que no necesitan tal información. El beneficio de la ocultación se nota sobre todo a la hora de hacer modificaciones durante las pruebas o el mantenimiento del software; cómo la mayoría de datos y procedimientos estarán ocultos a otras partes del software, será menos probable que los errores introducidos (evidentemente sin querer) durante la modificación se propagen a otros lugares del software.


Un diseño modular efectivo debe asegurar la indepencia funcional de los mismos, la indepencia funcional nace directamente de la modularidad, de la abstracción y ocultamiento de la información, esto se puede afirmar que se adquiere desarrollando módulos con una clara función y una adversión a la excesiva interacción con otros módulos, se trata pues de diseñar software de forma que cada módulo se centre en una subfunción específica de los requisitos y tenga una interfaz sencilla, cuando se ve desde otras partes de la estructura software.

El software con indepencia funcional es fácil de desarrollar porque su función puede ser partida y se simplifican las interfaces (con las implicaciones que conlleva cuando el desarrollo es realizado por un equipo, como es nuestro caso). Los módulos independientes son fáciles de mantener y de probar ya que limitan los efectos secundarios, reduce la propagación de errores y fomenta la reutilización de código. Prácticamente la indepencia funcional se mide con dos parámetros: la cohesión y el acoplamiento.

Cohesión


Se puede definir como una medida de la fortaleza funcional relativa de un módulo; es una extensión del concepto de ocultamiento de información. Un módulo sólo debe hacer (idealmente) una cosa, siendo deseable una gran cohesión, lo normal es situarse en la parte media del espectro, básicamente se trata de evitar que los módulos sean una agrupación de líneas de código y debe de tender a que los elementos de procedimientos del módulo se concentren en el mismo momento, sobre el área de una estructura de datos y una función.

Como criterios para establecer el grado de cohesión tenemos (Stevens):

Escribir una frase que describa el propósito del módulo y examinarlo; si la frase no contiene un objeto específico sencillo a continuación del verbo lo más normal es que estemos en la banda baja de cohesión(p. Ejemplo editar todos los datos).

Acoplamiento

Se puede definir como una medida de la interdependencia relativa entre módulos, depende de la complejidad de las interfaces entre los módulos, del punto en el que se hace una entrada o referencia a un módulo y de los datos que pasan a través del interfaz. Nuestro objetivo es una interconectividad sencilla, es decir, acoplamiento bajo, más fácil de comprender y menos propenso a un efecto avalancha de los errores a lo largo del sistema.

Lo normal es conseguir un acoplamiento de control, es decir, un módulo le pasa un 'indicador' sobre el que se toman decisiones en un módulo subordinado. Se debe de evitar que se modifiquen los datos de un módulo en otro, es decir, limitar al máximo el uso de variables globales.


        5.2.5 Jerarquía de control.

La jerarquía de control, también denominada estructura del programa, representa la organización de las componentes del programa. Una notación común es un diagrama en forma de árbol, donde cada hoja o nodo es un módulo y representa gráficamente dos características importantes la visibilidad y la conectividad.

La visibilidad indica el conjunto de componentes del programa que pueden ser invocados o utilizados (sus datos) por un componente dado. La conectividad indica el conjunto de componentes a los que directamente se invoca o se utilizan sus datos en un determinado módulo (por ejemplo un módulo que puede provocar la ejecución de otro módulo.


    1. Diseño de datos

El impacto de los datos sobre la estructura del programa y la complejidad procedimental, hace que el diseño de datos tenga una gran influencia en la calidad del software. Los conceptos de ocultamiento de la información y de abstracción de datos conforman la base de los métodos de diseño de datos.

Se consideran los siguientes principios para la especificación de datos:


    1. Diseño arquitectónico


El objetivo del diseño arquitectonico es desarrollar una estructura de programa modular y representar las relaciones de control entre módulos. El diseño arquitectónico mezcla la estructura de programas y la de datos definiendo las interfaces que facilitan el flujo de los datos a lo largo del programa.


    1. Diseño procedimental


Tras establecer la estructura del programa (diseño arquitectónico) y de datos (diseño de datos) se realiza el diseño procedimental que, define los detalles algorítmicos. Esta especificación no puede ser ambigua por ello se realizará mediante una notación de programación estructurada, que tiene tres construcciones básicas: la secuencia, la condición y la repetición.

Cualquier programa con indepencia del área de aplicación y de la complejidad técnica, puede diseñarse e implementarse usando sólo estas tres construcciones a nivel de diseño.

El apoyo en una notación gráfica también es muy importante, siendo el más adecuado el diagrama de flujo, cuyos símbolos son:





6 MODELOS DE DOCUMENTACIÓN

    1. Introducción

Existen numerosas propuestas sobre la organización de la documentación para el diseño software y recoger los requisitos, esta documentación debe ser revisada con frecuencia a lo largo del desarrollo de la aplicación, por lo que es muy conveniente que se redacte de una forma fácil de modificar. Por otro lado también debe facilitar la labor de verificación del cumplimiento de las especificaciones. Esto hace que la mejor manera de redactar este documento sea en forma de un contrato con distintas cláusulas organizadas y agrupadas según el caracter de los requisitos.

En este documento se seguirán dos modelos distintos el de la Agencia Especial Europea, que está orientado al diseño procedimental y el de UML. En cualquier caso ambos son utilizables si estamos interesados en diseñar productos de gestión o para la la Admisnistración pública ya que su trasvase a un modelo de Métrica 3 es directo.

    1. Documento de Requisitos del Software

Este documento tiene un caracter general y en algunos casos no será necesario cumplimentar todos sus apartados. El índice de este documento es el siguiente:

            1. Introducción

              1.1 Objetivo

              1.2 Ambito

              1.3 Definiciones, siglas y abreviaturas

              1.4 Referencias

            2. Descripción general

            3. Requisitos específicos

              3.1 Requisitos funcionales

              3.2 Requisitos de capacidad

              3.3 Requisitos de interface

              3.4 Requisitos de operación

              3.5 Requisitos de recursos

              3.6 Requisitos de verificación

              3.7 Requisitos de pruebas de aceptación

              3.8 Requisitos de documentación

              3.9 Requisitos de seguridad

              3.10 Requisitos de transportabilidad

              3.11 Requisitos de calidad

              3.12 Requisitos de fiabilidad

              3.13 Requisitos de mantenibilidad

              3.14 Requisitos de salvaguarda

            4. Apéndices

    1. Documento de Diseño del Software

Tambien tiene un caracter general y en algunos casos no será necesario cumplimentar todos sus apartados. El índice de este documento es el siguiente:

  1. Introducción

    1.1 Objetivo

    1.2 Ámbito

    1.3 Definiciones, siglas y abreviaturas

  2. Panorámica del sistema

  3. Contexto del sistema

  4. Diseño del sistema

    4.1 Metodología de diseño de alto nivel

    4.2 Descomposición del sistema

  5. Descripción de componentes

  6. Viabilidad y recursos estimados

  7. Matriz Requisitos/Componentes

    7 JUNTÁNDOLO TODO (EJEMPLOS).

7.1 Gegaco

Introducción

La empresa 'Gestransa' dedicada a los servicios decide contratar un producto software que le permita realizar una serie de operaciones sobre sus cuentas y presupuestos. Al conocer el proyecto de Hispalinux denominado 'Gestión Libre' decide apostar por este modelo de desarrollo de software para realizar la aplicación en la cual está interesada.

Puesta en contacto con un grupo de desarrollo de código abierto mantiene una reunión para determinar la forma de funcionamiento de la aplicación y los conceptos que cree que debe de cumplir la misma, de esta reunión nace el “Documento de Conceptos del Sistema”.


Documento de Conceptos del Sistema

'Gestransa' como empresa de servicios tiene dos tipos diferenciados de clientes, los constituidos como empresa y aquellos que acuden de forma `particular'. El servicio que presta la empresa es el de conseguir productos compuestos de las aportaciones de distintas empresas que contrata directamente 'Gestransa'. Es pues un producto personalizado a las necesidades del cliente.

El sistema informático que pretende poner en marcha Gestransa consiste en un programa que debe ser capaz de llevar a cabo el presupuesto de abonos de la empresa a 30 días vista, para ello tendrá en cuenta que se conocen perfectamente una serie de gastos, así como su periodicidad.

El sistema tendrá los datos de los clientes de Gestransa así como de los proveedores habituales con una relación de los productos que cada uno de ellos suministra.

Se desea además que se puedan desarrollar estudios gráficos de la repercusión económica de cada uno de los clientes, proveedores y productos con los que trabaja Gestransa. Así mismo se debe de tener controlado en cada momento el estado contable de la empresa, esto es el activo disponible, así mismo dado el mercado variable en el que se mueve el negocio de la empresa, se desea que sea capaz de realizar presupuestos de compra de los productos que se especifíquen a cada uno de los proveedores, para el cálculo de coste de los distintos productos, tendrá en cuenta la fluctuabilidad del mercado.



Documento de Requisitos del Software


Proyecto: Sistema de Gestión de Gastos y Control Económico.


Autores: Gruceca


Fecha : Julio 2002


Documento : Gegaco- SRD -2002

____________________________


Contenido:

            1. Introducción

              1.1 Objetivo

              1.2 Ambito

              1.3 Definiciones, siglas y abreviaturas

              1.4 Referencias

            2. Descripción general

            3. Requisitos específicos

              3.1 Requisitos funcionales

              3.2 Requisitos de capacidad

              3.3 Requisitos de interface

              3.4 Requisitos de operación

              3.5 Requisitos de recursos

              3.6 Requisitos de verificación

              3.7 Requisitos de pruebas de aceptación

              3.8 Requisitos de documentación

              3.9 Requisitos de seguridad

              3.10 Requisitos de transportabilidad

              3.11 Requisitos de calidad

              3.12 Requisitos de fiabilidad

              3.13 Requisitos de mantenibilidad

              3.14 Requisitos de salvaguarda


              Introducción


Objetivo

El objetivo del sistema es facilitar la gestión de la empresa Gestransa en lo referente a los diversos abonos e ingresos que se le presentan en el siguiente mes vista tanto de abonos como de recaudación, de forma que pueda presupuestar ambos conceptos teniendo siempre en cuenta los activos reales de los que dispone la empresa.


Ambito

El sistema a desarrollar se denominará GEGACO-1.0 y consistirá en un conjunto de funciones que actuarán sobre una base de datos. En particular, deberá facilitar las siguientes:


El sistema no ha de soportar sin embargo la gestión económica y documental de la propia empresa, aunque si se figurarán dichos conceptos en la gestión y previsión de abonos.

Tampoco supondrá una herramienta que controle de forma alguna la calidad del servicio que reciben los clientes, ya que para ello Gestransa está en periodo de certificación ISO 9004.

El sistema tampoco debe de soportar la emisión de facturas.


Definiciones, siglas y abreviaturas


Ninguna


Referencias


Ninguna


Panorámica del documento


El resto del documento contiene una descripción del modelo del sistema, en la Sección 2, y la lista de requisitos específicos en la Sección 3.

Para confeccionar el modelo se ha aplicado la metodología de ANALISIS ESTRUCTURADO. Los diagramas de flujo de datos se han incluido en la sección 2, así como el diccionario de datos y el diagrama Entidad-Relación correspondiente al modelo de datos. Las especificaciones de procesos se incluyen en el apartado 3.1 Requisitos Funcionales

Descripción General

Relación con otros proyectos

Se incluye dentro del proyecto Gestión Libre de Hispalinux, por ello toda la documentación del sistema deberá ser editada bajo licencia GPLF. El código resultante del presente documento de Requisitos del Software deberá ser liberdado bajo licencia GPL.


Relación con proyectos anteriores y posteriores

Si el sistema llega a ser totalmente operativo en plazo y forma, este proyecto podría ser ampliado con la gestión de nóminas de los empleados de Gestransa así como con la elaboración de documentación de la Seguridad Social (modelos Tc1 y Tc2 de la tesorería de la Seguridad Social) y de los cálculos pertinentes del IVA trimestral y su posterior declaración impositiva. A pesar de que estos apartados están en negociación se tendrá en cuenta esta posible ampliación.

Relación con proyectos anteriores y posteriores


Ninguna


Objetivo y funciones

La empresa Gestransa recibe sus ingresos a partir de los distintos servicios que contrata con sus clientes, el caracter de dichos servicios es variable y los subcontrata a distintas empresas proveedoras de los productos necesarios. El sistema debe pues tener un control sobre los clientes y productos o servicios contratados, el periodo de pago de los mismos, los proveedores que tiene en un momento dado y los productos que cada uno de ellos suministra, así como el precio que tiene cada uno de ellos. Un determinado producto puede ser proporcionado por uno o varios proveedores, por lo que el sistema debe de tener capacidad para distinguirlos.

El sistema debe de tener control sobre el estado contable de la empresa, conociendo en todo momento el saldo corriente, así como capacidad de realizar presupuestos de ingresos y de los abonos que debe de soportar la empresa en un plazo de 30 días. También debe ser capaz de estimar el precio para la compra de productos basándose en los precios anteriores. El sistema permitirá realizar una serie de estudios estadísticos en forma de gráficos. El objetivo del sistema es pues el control económico sobre la actividad económica de Gestransa y sus clientes, para ello debe de proporcionar las funciones más directamente relacionadas con la gestión de clientes y proveedores. Así mismo proporcionará las funciones necesarias para el desarrollo de los estudios gráficos. Las funciones principales serán:



Como complemento serán necesarias otras funciones, en concreto:



Consideraciones de entorno

Ninguna

Relación con otros sistemas

Este sistema se incluye dentro del proyecto Gestión Libre de Hispalinux que en un intento de unificar las herramientas de programación, aboga por el uso de PostgreSQL como SGBD (opcionalmente se puede utilizar otro como MySql).

Restricciones generales

Descripción del modelo.

El sistema de Gestión será utilizado por una única persona, que dispondrá de un terminal con pantalla y teclado. También existirá una impresora por la que podrán obtenerse los listados y fichas de los clientes, proveedores y los gráficos pertinentes. Esta organización se refleja en el Diagrama de Contexto DC.



La operación del sistema se hará mediante un sistema de menús para seleccionar la operación deseada, y con formularios en pantalla para la entrada y presentación de datos. Las funciones a realizar se pueden organizar en varios grupos principales tal y como se indica en el diagrama de flujo de datos DFD.0 de la figura. Estos grupos de funciones se describen a continuación. La descripción precisa de cada función se incluye en la Sección 3: Requisitos Específicos.



Gestión

Esta función es la encargada de realizar el mantenimiento de los datos de los clientes, proveedores, productos y previsiones del sistema.

Los clientes se identificarán con su NIF o CIF según el caso (Particulares o Empresas respectivamente), nombre y apellidos, dirección. Los proveedores se identificarán con el CIF, dirección y productos que suministran. Los productos se identificarán con un identificador del producto, una descripción del mismo y el precio según proveedor.

Las funciones que realizan estas operaciones se pueden ver en el DFD1 Gestión de la figura siguiente:



Las funciones de Gestión son las siguientes:

Movimientos

La función de movimientos se encarga de actualizar los estados de la cuenta, de los servicios, previsiones y compras que realiza Gestransa.

Las funciones que realizan estas operaciones se pueden ver en el DFD2 Movimientos de la figura siguiente:



Las funciones de Movimientos son:

Informes


La función Informes se encarga de realizar los informes impresos en tres formatos especificados barras, sectores y tabulares.

Las funciones de Informes son:


Modelo de datos


Entidades:

Proveedor: Datos de los proveedores de productos a Gestransa.

Clientes : Datos de los clientes.

Cuenta: Datos del estado contable de Gestransa, incluye la fecha de los movimientos.

Servicio: Identificación de los distintos servicios contratados por los clientes.

Producto: Identificación y descripción de los productos

Relaciones:

Ingresa: Movimientos que suponen un incremento del saldo, incluyen fecha, motivo y cuantia.

Extrae: Movimientos que suponen un decremento del saldo, incluyen fecha, motivo y cuantia.

Contrata: Identificación de los servicios contratados por un determinado cliente, incluye los productos, una descripción del servicio y la cantidad.

Proporciona: Identificación de los servicios que puede proporcionar un proveedor

Sirve: Listado de productos que puede proporcionar un proveedor.

Diccionario de Datos:


PROVEEDOR {FICHA-PROVEEDOR}

CLIENTE {FICHA-CLIENTE}

PRODUCTO {FICHA-PRODUCTO}

CUENTA {MOVIMIENTO-CUENTA}

SERVICIO {FICHA-SERVICIO}

PREVISIÓN {FICHA-PREVISION}

FICHA-PROVEEDOR idproveedor + FICHA + DIRECCION

FICHA-CLIENTE idcliente + FICHA + DIRECCION

FICHA-PRODUCTO idproducto + descripción + precio

DIRECCION idcliente | idproveedor + calle + número + localidad + municipio + codigo_postal

FICHA Nombre + apellidos

FICHA-SERVICIO idservicio + idcliente + DESCRIPCION

DESCRIPCION descripcion + cantidad

MOVIMIENTO-CUENTA cantidad + fecha + motivo + saldo

FICHA-PREVISIÓN cantidad + periodo + motivo + identificación

Requisitos específicos


Requisitos funcionales.

Almacenamiento de datos.

R.1.1 El sistema mantendrá almacenados en forma permanente los datos indicados en PROVEEDORES, CLIENTES, PRODUCTOS, CUENTA y SERVICIOS, del diccionario de datos de la sección anterior.


Funciones principales

R.1.2 El sistema realizará al menos las siguientes funciones a petición del operador


1. Gestión

Función 1.1 Alta de productos: da de alta un nuevo producto

Entrada: PRODUCTO

Salida: FICHA-PRODUCTO

Actualiza: PRODUCTOS

Usa: PROVEEDOR

Efecto: Da de alta un nuevo producto que estará disponible para ser contratado en algún servicio. Todo producto ha de ser proporcionado por un Proveedor

Excepciones: Si existe un producto con ese identificador dará un aviso.

Si se intenta dar de alta un producto sin tener un proveedor asociado se dará un aviso


Función 1.2 Alta de clientes: Alta de nuevos clientes

Entrada: CLIENTE

Salida: FICHA-CLIENTE

Actualiza: CLIENTES

Usa:

Efecto: Da de alta un nuevo cliente, es un paso previo a la contratación de servicios

Excepciones: Si existe un cliente con ese NIF, CIF dará un aviso.



Función 1.3 Alta de proveedores: Da de alta un nuevo proveedor

Entrada: PROVEEDORES

Salida: FICHA-PROVEEDORES

Actualiza: PROVEEDOR

Usa:

Efecto: Da de alta un nuevo proveedor, paso previo a dar de alta algún producto

Excepciones: Si existe un proveedor con ese CIF dará un aviso.


Función 1.4 Alta de previsiones

Entrada: PREVISIÓN

Salida: FICHA-PREVISIÓN

Actualiza: PREVISIÓN

Usa: CLIENTES, PROVEEDORES, SERVICIO

Efecto: Da de alta un abono o ingreso, que tendrá una preriodicidad.

Excepciones:


Función 1.5 Alta de servicios:

Entrada: SERVICIO

Salida: FICHA-SERVICIO

Actualiza: SERVICIO

Usa: PRODUCTO-CLIENTES

Efecto: Da de alta un servicio contratado por un cliente

Excepciones


Función 1.6 Baja de productos: Da de baja un producto existente de un proveedor determinado

Entrada: FICHA-PRODUCTO

Salida:

Actualiza: PRODUCTO

Usa: PROVEEDORES

Efecto: Lee la identificación entrada por teclado o ratón y da de baja el producto especificado

Excepciones: Si el producto no existe dará un aviso


Función 1.7 Baja de clientes:

Entrada: FICHA_CLIENTES

Salida:

Actualiza: CLIENTES

Usa: SERVICIOS

Efecto: Da de baja un cliente

Excepciones: Si el cliente no existe dará un aviso, si tiene contratado un servicio no causará baja.

Función 1.8 Baja de proveedores:

Entrada: FICHA-PROVEEDOR

Salida

Actualiza: PROVEEDORES

Usa: PRODUCTOS

Efecto: Da de baja uno de los proveedores de productos, dará de baja los productos que sirva dicho proveedor, marcará los servicios que se vean afectados por dicha baja para su modificación.

Excepciones: Si el proveedor no existe se dará un aviso

Función 1.9 Baja de previsiones:

Entrada: FICHA-PREVISION

Salida

Actualiza: PREVISIONES

Usa

Efecto: Da de baja uno de los movimientos de las previsiones

Excepciones


Función 1.10 Baja de servicios:

Entrada: FICHA-SERVICIO

Salida:

Actualiza: SERVICIO

Usa:

Efecto: Da de baja un determinado servicio

Excepciones: Si el servicio no existe dará un mesaje de error


Función 1.11 Modificación de productos:

Entrada: PRODUCTO

Salida: FICHA-PRODUCTO

Actualiza: PRODUCTO

Usa: PROVEEDOR

Efecto: Modifica alguna de las características de un producto determinado

Excepciones Si el producto no existe dará un mensaje de error


Función 1.12 Modificación de clientes:

Entrada: CLIENTE

Salida: FICHA-CLIENTE

Actualiza: CLIENTES

Usa

Efecto: Modifica alguna de los datos del cliente

Excepciones: Si el cliente no existe dará un mensaje de error.


Función 1.13 Modificación de previsiones:

Entrada: PREVISION

Salida: FICHA-PREVISION

Actualiza: PREVISION

Usa

Efecto: modificación de los datos de una previsión

Excepciones: La previsión debe existir


Función 1.14 Modificación de proveedores:

Entrada: PROVEEDOR

Salida: FICHA-PROVEEDOR

Actualiza: PROVEEDORES

Usa:

Efecto: modificación de los datos de un proveedor

Excepciones: El proveedor deberá existir



Función 1.15 Modificación de servicios:

Entrada: SERVICIO

Salida: FICHA-SERVICIO

Actualiza: SERVICIO

Usa: PRODUCTO, CLIENTES

Efecto: modificación de los datos de un servicio contratado por un cliente

Excepciones: El servicio deberá existir


Función 1.16 Listado productos:

Entrada:

Salida: Listado de productos

Actualiza:

Usa: PRODUCTOS

Efecto: Imprime un listado con los datos de todos los productos que estén dados de alta

Excepciones

Función 1.17 Listado productos-proveedor:

Entrada:

Salida: Listado de productos

Actualiza

Usa: PRODUCTOS, PROVEEDORES

Efecto: Imprime un listado con los datos de los productos que suministra cada proveedor

Excepciones


Función 1.18 Listado clientes:

Entrada:

Salida: Listado de clientes

Actualiza

Usa: CLIENTES

Efecto: Imprime un listado de los clientes

Excepciones


Función 1. 19 Listado de servicios:

Entrada:

Salida: Listado de servicios por clientes

Actualiza:

Usa: SERVICIOS, CLIENTES

Efecto: Imprime un listado de los distintos servicios contratados por cada uno de los clientes

Excepciones


Función 1.20 Listado de compras

Entrada:

Salida: Listado de compra

Actualiza:

Usa: PRODUCTOS, PREVISION

Efecto:Realiza el cálculo de la compra de una serie de productos según el cálculo acumulado.

Excepciones


    2. Movimientos

    Función 2.1 Ingreso:

Entrada: MOVIMIENTO-CUENTA

Salida:

Actualiza: CUENTA

Usa: CLIENTE

Efecto: Refleja el ingreso realizado por un cliente en cuenta

Excepciones: El cliente debe existir y tener un servicio contratado


Función 2.2 Abono:

Entrada:MOVIMIENTO-CUENTA

Salida

Actualiza: CUENTA

Usa: PROVEEDOR

Efecto: refleja un abono realizado a un proveedor

Excepciones: El proveedor debe existir, y suministrar productos


Función 2.3 Ultimos movimientos:

Entrada:

Salida: Listado con los movimientos de cuenta

Actualiza

Usa: CUENTA

Efecto: Imprime los n últimos movimientos indicados

Excepciones


Función 2.4 Ultimos días:

Entrada:

Salida: Listado con los movimientos de cuenta

Actualiza

Usa: CUENTA

Efecto: Listado con los movimientos de los n días indicados

Excepciones


Función 2.5 Previsión:

Entrada:

Salida

Actualiza

Usa: PREVISION

Efecto: Listado con la previsión para los próximos 30 días

Excepciones

Función 2.6 Compras:

Entrada:

Salida

Actualiza

Usa: PROVEEDOR, PRODUCTO

Efecto: Listado del precio de una compra de una serie de productos a un determinado proveedor

Excepciones: Si el proveedor no existe, o bien si existe y no suministra de producto selecionado se indicará con un mensaje de error, diferenciado para cada uno de los casos.


3. Informes

Función 3.1 Informe tabular:

Entrada: PROVEEDOR

Salida: Informe tabular

Actualiza

Usa

Efecto: Genera en pantalla un informe tabular de los proveedores

Excepciones


Función 3.2 Sectores:

Entrada: SERVICIO

Salida: Gráfico de Sectores

Actualiza

Usa: CUENTA

Efecto: Gráfico de sectores por pantalla de los ingresos diferenciados por clientes

Excepciones


Función 3.3 Barras:

Entrada: PREVISION, CUENTA

Salida: Gráfico de barras

Actualiza

Usa: CUENTA, PREVISION

Efecto: Gráfico de barras por pantalla de los gastos reales con respecto a los presupuestados

Excepciones

Función 3.4 Impresion:

Entrada:

Salida: Impresión de gráfico

Actualiza

Usa: Gráfico

Efecto: Impresión del último gráfico generado

Excepciones: Sólo se imprime el último gráfico generado.


Requisitos de capacidad

R.2.1 El software deberá soportar por lo menos 10.000 clientes, 10.000 proveedores, 1.000.000 de productos y 15.000 movimientos en cuenta

R.2.2 La ejecución de las funciones principales a excepción de los listados y la generación de gráficas deberá durar como máximo 2 segundos, en un PC con procesador P-III a 1 Ghz.

R.2.3 El tiempo de los listados dependerá de la impresora que se instale

R.2.4 El tiempo de ejecución de los gráficos será inferior a 30 segundos en una máquina con las caracteristicas indicadas en R.2.2


Requisitos de interfase

No aplicable

Requisitos de operación

R.4.1 La selección de una función se hará mediante un sistema de menús en un entorno de ventanas del tipo Xwindows.

R.4.2 Existirá la posibilidad de realizar y restablecer copias de seguridad.


Requisitos de recursos

R.5.1 El sistema se ejecutará en un PC de gama media, con una configuración mínima de:

Requisitos de verificación

R.6.1 (Deseable) Deberá disponer de un sistema de acceso a los registros de clientes, proveedores y productos de forma independiente a la aplicación, y que permita examinar el contenido de los mismos, preferiblemente obteniendo un listado del mismo, para comprobar que la información almacenada es correcta.

R.6.2 Se deberá comprobar el ajuste del sistema de simulación de precios

Requisitos de pruebas de aceptación

R.7.1 Se deberá probar al menos una vez todas y cada una de las funciones tanto con datos correctos como incorrectos.

R.7.2 (Deseable) Función de autoajuste de modificación de precios

Requisitos de documentación

R.8.1 Manual informatizado de operación que describirá el uso del sistema imprimible por temas.

R.8.2 (Deseable) Resumen del manual de operación disponible como ayuda en línea

Requisitos de seguridad

No aplicable

Requisitos de transportabilidad

No aplicable

Requisitos de calidad

No aplicable

Requisitos de fiabilidad

No aplicable

Requisitos de mantenibilidad

No aplicable

Requisitos de salvaguarda

No aplicable


Documento de Diseño del Software

Proyecto: Sistema de Gestión de Gastos y Control Económico.

Autores: Gruceca

Fecha : Julio 2002

Documento : Gegaco- ADD -2002


____________________________


Contenido:


  1. Introducción

    1.1 Objetivo

    1.2 Ámbito

    1.3 Definiciones, siglas y abreviaturas

  2. Panorámica del sistema

  3. Contexto del sistema

  4. Diseño del sistema

    4.1 Metodología de diseño de alto nivel

    4.2 Descomposición del sistema

  5. Descripción de componentes

  6. Viabilidad y recursos estimados

  7. Matriz Requisitos/Componentes





      1. INTRODUCCION


    1. Objetivo

El objetivo del sistema es facilitar la gestión de la empresa Gestransa en lo referente a los diversos abonos e ingresos que se le presentan en el siguiente mes vista, de forma que pueda presupuestar ambos conceptos teniendo siempre en cuenta los activos reales de los que dispone.

    1. Ambito

El sistema a desarrollar se denominará GEGACO-1.0 y consistirá en un conjunto de funciones que actuarán sobre una base de datos. En particular, deberá facilitar las siguientes:

El sistema no ha de soportar sin embargo la gestión económica y documental de la propia empresa, aunque si se figurarán dichos conceptos en la gestión y previsión de abonos.

Tampoco supondrá una herramienta que controle de forma alguna la calidad del servicio que reciben los clientes, ya que para ello Gestransa está en periodo de certificación ISO 9004.

El sistema tampoco debe de soportar la emisión de facturas.

    1. Definiciones, siglas y abreviaturas

Ninguna

    1. Referencias

Gegaco-SRC-2002: Documento de Requisitos del Software del Sistema de Gestión de Gastros y Control Económico

      1. PANORÁMICA DEL SISTEMA

Se recoge aquí un resúmen de la descripción del sistema ya incluida en el documento de especificación de requisitos Gegaco-SRD-2002.

    1. Objetivo y funciones


La empresa Gestransa recibe sus ingresos a partir de los distintos servicios que contrata con sus clientes, el caracter de dichos servicios es variable y los subcontrata a distintas empresas proveedoras de los productos necesarios. El sistema debe pues tener un control sobre los clientes y productos o servicios contratados, el periodo de pago de los mismos, los proveedores que tiene en un momento dado y los productos que cada uno de ellos suministra, así como el precio que tiene cada uno de ellos.

Un determinado producto puede ser proporcionado por uno o varios proveedores, por lo que el sistema debe de tener capacidad para distinguirlos.

El sistema debe de tener control sobre el estado contable de la empresa, conociendo en todo momento el saldo corriente, así como capacidad de realizar presupuestos de compras y de los gastos que debe de soportar la empresa en un plazo de 30 días.

El sistema permitirá realizar una serie de estudios estadísticos en forma de gráficos.

El objetivo del sistema es pues el control económico sobre la actividad económica de Gestransa y sus clientes, para ello debe de proporcionar las funciones más directamente relacionadas con la gestión de clientes y proveedores. Así mismo proporcionará las funciones necesarias para el desarrollo de los estudios gráficos. Las funciones principales serán:


Como complemento serán necesarias otras funciones, en concreto:

    1. Descripción funcional.

El sistema de Gestión Económico está operado por una sóla persona, que dispondrá de un terminal con pantalla y teclado. También existirá una impresora por la que podrán obtenerse listados, fichas y gráficos de los datos especificados en las funciones.

      2.2.1 Gestión

Las funciones de gestión son las que proporcionan los datos al sistema para que pueda realizar su función, en ellas se dan de alta clientes, proveedores, etc.

Función 1.1 Alta de productos

Función 1.2 Alta de clientes

Función 1.3 Alta de proveedores

Función 1.4 Alta de previsiones

Función 1.5 Alta de servicios

Función 1.6 Baja de productos

Función 1.7 Baja de clientes

Función 1.8 Baja de proveedores

Función 1.9 Baja de previsiones

Función 1.10 Baja de servicios

Función 1.11 Modificación de productos

Función 1.12 Modificación de clientes

Función 1.13 Modificación de proveedores

Función 1.14 Modificación de previsiones

Función 1.15 Modificación de servicios

Función 1.16 Listado productos

Función 1.17 Listado productos-proveedor

Función 1.18 Listado clientes

Función 1.19 Listado de servicios

Función 1.20 Listado de compras

      2.2.2 Movimientos

Las funciones de movimiento son aquellas que actualizan el estado contable de Gestransa y de los datos de previsión.

Función 2.1 Ingresos

Función 2.2 Abonos

Función 2.3 Ultimos movimientos

Función 2.4 Ultimos días

Función 2.5 Previsión

Función 2.6 Compras

      2.2.3 Informes

Las funciones de informes son las encargadas de generar los gráficos deseados para estudiar los movimientos.


Función 3.1 Informe tabular

Función 3.2 Sectores

Función 3.3 Barras

Función 3.4 Impresión


    1. Modelo de datos

El modelo conceptual se describe en el diagrama entidad relación, revisado, que aparece en la siguiente figura. Este modelo amplía el descrito en el documento de requisitos GEDACO-SRD-2002.



Las entidades de datos y las relaciones entre ellas son las siguientes:

ENTIDADES:

RELACIONES

      1. Vive_en

      2. Pertenece

      3. Movimiento-previsto

      4. Movimiento

      5. Servicio

      6. Aproximación

Se debe de tener en cuenta que FICHA-CLIENTE, FICHA-PRODUCTO, FICHA-PROVEEDOR, etc que se hacen referencia en el documento de especificación de requisitos corresponde a una vista externa para ser presentada en pantalla o impresa como ficha.

Los esquemas físicos correspondientes a este modelo conceptual se describen en el apartado 5.1 Módulo: Base de datos.

        3 CONTEXTO DEL SISTEMA

No existe conexión con otros sistemas.

        4. DISEÑO DEL SISTEMA

    1. Metodología de diseño de alto nivel

Se utiliza la metodología de Diseño Estructurado, basada en la descomposición funcional del sistema.

    1. Descomposición del sistema

La estructura modular del sistema aparece representada en la figura siguiente.



Los módulos identificados son los siguientes:

El módulo base de datos está realizado físicamente por el SGBD de código abierto que se utiliza.

        5. DESCRIPCION DE COMPONENTES

    1. Módulo: Base de Datos.

      1. Tipo: Base de datos relacional

      2. Objetivo: Este módulo contiene la base de datos relacional que almacena la información persistente del sistema.

      3. Función: Almacenar los datos que se indican

      4. Subordinados: Ninguno

      5. Dependencias: Gestión, Movimientos, Informes.

      6. Interfaces: El modelo fisico de datos es el siguiente:

CLIENTES

Campo

Tipo

Long

Indice

Descripción

Idcliente

Char

9

SI

NIF del cliente

Nombre

Char

15

No

Nombre del cliente

Apellido

Char

15

No

Primer apellido del cliente

Seg_apellido

Char

15

No

Segundo apellido del cliente


PROVEEDOR

Campo

Tipo

Long

Indice

Descripción

Idproveedor

Char

9

SI

CIF del proveedor

Nombre

Char

50

No

Nombre comercial del proveedor



PRODUCTOS

Campo

Tipo

Long

Indice

Descripción

Idproducto

Numero

4

SI

Código de referencia del producto

Descripción

Char

50

No

Breve descripción del producto

Precio

Número

10

No

Precio en € del producto



DIRECCION

Campo

Tipo

Long

Indice

Descripción

Ident

Char

9

SI

NIF o CIF de identificación

Calle

Char

30

No

Calle del domicilio

Número

Número

5

No

Número de la calle

Piso

Char

5

No

Piso del edificio

Localidad

Char

30

No

Localidad de la dirección



MUNICIPIO

Campo

Tipo

Long

Indice

Descripción

Código

Número

5

Si

Código postal de la localidad

Localidad

Char

30

No

Localidad de residencia

Municipio

Char

30

No

Municipio de la localidad

Provincia

Char

30

No

Provincia que pertenece el municipio



PERIODO

Campo

Tipo

Long

Indice

Descripción

Dias

Número

4

Si

Número de dias que componen el periodo

Tipo

Char

20

No

Identificación de un tipo de periodo


CUENTA

Campo

Tipo

Long

Indice

Descripción

Saldo

Número

12

Si

Saldo total de la cuenta

Fecha

Tiempo

8

No

Fecha de realización del movimiento

Descripción

Char

50

No

Descripción del movimiento

Cantidad

Número

12

No

Cantidad del abono o ingreso en cuenta

SERVICIO

Campo

Tipo

Long

Indice

Descripción

Idservicio

Número

6

Si

Número de referencia de un servicio

Idcliente

Char

9

Si

NIF del cliente que contrata el servicio

Idproveedor

Char

9

Si

CIF del proveedor del servicio

Descripción

Char

50

No

Descripción del servicio



DESCRIPCION

Campo

Tipo

Long

Indice

Descripción

Idservicio

Número

6

Si

Número de referencia del servicio

Idproducto

Número

4

Si

Número de referencia del producto

Cantidad

Número

6

No

Unidades del producto en el servicio



PREVISION

Campo

Tipo

Long

Indice

Descripción

Idproducto

Número

4

Si

Número de referencia del producto

Idproveedor

Número

9

Si

CIF del proveedor

Fecha

Tiempo

8

Si

Fecha de consulta de precios

Precio

Número

12

No

Precio del producto en la fecha



APROXIMACION

Campo

Tipo

Long

Indice

Descripción

Idproducto

Número

4

Si

Número de referencia del producto

Idproveedor

Número

9

Si

CIF del proveedor

Precio_Estimado

Número

12

No

Precio estimado del producto


MOVIMIENTO

Campo

Tipo

Long

Indice

Descripción

IdMovimiento

Número

6

Si

Número de referencia del movimiento

Descripción

Char

50

No

Descripción

Fecha_base

Tiempo

8

No

Inicio del movimiento



MOVIMIENTO-PREVISTO

Campo

Tipo

Long

Indice

Descripción

IdMovimiento

Número

6

Si

Número de referencia de movimiento

Periodo

Char

20

No

Identificación de periodicidad

Actor

Numero

9

No

Identificación del cliente o proveedor

Importe

Numero

12

No

Importe del movimiento


      1. Recursos: Ninguno.

      2. Referencias: Ninguna

      3. Proceso: Ninguno

      4. Datos: Ver interfaces

    1. Módulo : Gedaco

      1. Tipo: Abstracción funcional (programa principal).

      2. Objetivo: Es el programa principal de la aplicación

      3. Función: Este módulo se encarga de realizar el diálogo con el usuario en lo referente a la seleción de la función deseada en cada momento. También realizará las funciones oportunas al comienzo y final de la sesión de trabajo.

      4. Subordinados: Gestión, Movimientos, Informes.

      5. Dependencias: Ninguna

      6. Interfaces: No aplicable

      7. Recursos: Ninguno

      8. Referencias: Ninguna

      9. Proceso:

      1. Datos: Ver base de datos

    1. Módulo: Gestión


      1. Tipo: Abstracción funcional (colección de funciones)

      2. Objetivo: Realizar las distintas operaciones de mantenimiento del sistema Gestransa correspondientes al registro de clientes, productos, proveedores, servicios y generar listados de los mismos.

      3. Función:

Alta de productos: Da de alta un nuevo producto.

Entrada:

Salida:

Usa: Proveedores

Actualiza: Productos, Previsiones

Efecto: Compone una nueva ficha de producto, se le asignará un proveedor de un listado.

Excepciones: Si el código del producto existe se mostrará un mensaje de error y se saldrá.

Proceso:

Editar la ficha del producto mediante un formulario en pantalla.

El proveedor del producto se selecciona de la lista de proveedores, si éste no existe se deberá salir de la función y darlo de alta como proveedor.

Pedir conformidad con los datos

SI se confirma ENTONCES

Registrar el nuevo producto en las tablas Productos y Previsión

SI NO

Anular la asignación de nuevo número de referencia

FIN SI

Alta de clientes: Da de alta un nuevo cliente.

Entrada:

Salida:

Usa: Clientes, Municipio

Actualiza: Clientes, Dirección

Efecto: Compone una nueva ficha de cliente, la localidad de residencia debe de existir en el listado de municipios y códigos postales.

Excepciones: Si existe un cliente con el mismo NIF que se introduce se mostrará un mensaje de error y se saldrá de la función.

Proceso:

Editar la ficha del cliente mediante un formulario en pantalla.

La localidad de residencia se elige de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registrar el nuevo cliente en las tablas Clientes y Dirección

SI NO

Anular la asignación de datos del cliente dejando el formulario vacío

FIN SI


Alta de proveedores: Da de alta un nuevo proveedor.

Entrada:

Salida:

Usa: Proveedor, Municipio

Actualiza: Proveedor, Dirección

Efecto: Compone una nueva ficha de proveedor, la localidad de residencia debe de existir en el listado de municipios y códigos postales.

Excepciones: Si existe un proveedor con el mismo CIF que se introduce se mostrará un mensaje de error y se saldrá de la función.

Proceso:

Editar la ficha del proveedor mediante un formulario en pantalla.

La localidad de residencia se elige de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registrar el nuevo proveedor en las tablas Proveedor y Dirección

SI NO

Anular la asignación de datos del proveedor dejando el formulario vacío

FIN SI


Alta de previsiones: Da de alta una nueva previsión .

Entrada:

Salida:

Usa: Clientes, Proveedores, perdiodo, movimiento

Actualiza: Movimiento-previsto

Efecto: Crea una nueva ficha de previsiones de abonos o ingresos

Excepciones:

Proceso:

Editar la ficha de previsión mediante un formulario en pantalla.

Los clientes o proveedores se elegiran de una lista desplegable.

Los productos o servicios causantes del movimiento previsto deben existir

Pedir confirmación

SI se confirma ENTONCES

Registrar la nueva previsión en la tabla de movimientos-previstos

SI NO

Anular asignación de previsión

FIN SI


Alta de servicios: Da de alta un nuevo servicio.

Entrada:

Salida:

Usa: Cliente, Proveedor, Producto

Actualiza: Descripción

Efecto: Crea un nuevo servicio contratado por un cliente que consta de una serie de productos.

Un cliente sólo puede contratar un producto en un determinado servicio

El cliente deberá existir como tal.

El proveedor debe estar dado de alta y como distribuidor del producto

Excepciones: Si el cliente ya tiene contratado un servicio con estos productos se indicará mediante un mensaje de error.

Proceso:

Editar la ficha de servicio mediante un formulario en pantalla.

Los clientes, proveedores y productos se eligiran de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registrar el nuevo servicio en las tablas de servicio y la descripción del mismo en la tabla descripción

SI NO

Anular asignación de servicio

FIN SI


Baja de productos: Da de baja un producto.

Entrada:

Salida:

Usa: Servicio, Proveedores, Previsión

Actualiza: Productos, Proveedores

Efecto: Da de baja un producto servido por un determinado proveedor.

Excepciones: Si el producto está asignado a un determinado servicio se enviará un mensaje indicando si la modificación supone la supresión de dicho servicio, caso de que sea el único producto de ese tipo, o bien si se debe de modificar las condiciones del servicio, en ambos casos se pedirá confirmación.

Proceso:

Mostrar listado de productos

Buscar las relaciones del producto seleccionado

SI el producto está asignado a un servicio ENTONCES

CASO último producto

Abrir dialogo de dar de baja servicios

Pedir conformidad

CASO modificar condiciones servicio

Abrir dálogo modificar servicio

Pedir conformidad

FIN CASO

SI NO

Pedir conformidad

SI se confima ENTONCES

Dar de baja el producto y previsiones sobre él

SI NO

Anular selección y volver a pantalla de baja de producto

FIN SI

FIN SI


Baja de clientes: Da de baja un cliente.

Entrada:

Salida:

Usa: Movimiento, Vive_en, Servicio

Actualiza: Cliente, Direccion, Servicio

Efecto: Da de baja un cliente seleccionado de una lista desplegable, dará también de baja los servicios que tuviera contratados así como los datos de dirección y movimientos que tuviera asignados.

Excepciones: Si el cliente no tiene puesto al día los pagos se indicará esta circunstancia y no se realizará la acción.

Proceso:

Mostrar listado de clientes

Buscar las relaciones del cliente seleccionado

SI el cliente tiene contratado un servicio ENTONCES

CASO pagos al día

Pedir conformidad

CASO pagos pendientes

Mostrar mensaje

Salir de la función

FIN CASO

SI NO

Pedir conformidad

FIN SI

SI se confima ENTONCES

Dar de baja el cliente, su dirección y servicios contratados

SI NO

Anular selección y volver a pantalla de baja de cliente

FIN SI

Baja de proveedores: Da de baja un proveedor.

Entrada:

Salida:

Usa: Vive_en, movimiento, servicio, aproximación

Actualiza: Proveedor, Dirección

Efecto: Da de baja un proveedor seleccionado de una lista desplegable, se dan también de baja los servicios que distribuye, así como los datos de dirección y movimientos que tuviera asignados.

Excepciones: Si el proveedor no tiene puesto al día los pagos se indicará esta circunstancia y no se realizará la acción. Si el proveedor prest un servicio, se indicará con un mensaje y se permitirá deshacer la acción.

Proceso:

Mostrar listado de proveedores

Buscar las relaciones del proveedor seleccionado

SI el proveedor distribuye un producto de un sevicio ENTONCES

CASO el producto es reemplazable

abrir diálogo de modificar servicio

CASO el producto sólo es servido por éste distribuidor

Mostrar mensaje

Pedir conformidad de eliminación

SI no se confima

Salir de la función

FIN SI

FIN CASO

FIN SI

SI el proveedor tiene los pagos puestos al día

Pedir conformidad

FIN SI

SI se confima ENTONCES

Dar de baja el proveedor, su dirección y servicios contratados

SI NO

Anular selección y volver a pantalla de baja de proveedor

FIN SI

Baja de prevision: Da de baja una previsión.

Entrada:

Salida:

Usa: Clientes, proveedores, periodo, movimiento

Actualiza: Movimiento-previstos

Efecto: Da de baja una determinada previsión.

Excepciones:

Proceso:

Mostrar listado de previsiones

Pedir conformidad

SI se confima ENTONCES

Dar de baja la previsión seleccionada

SI NO

volver menú de baja de previsión

FIN SI

Baja de servicios: Da de baja un servicio .

Entrada:

Salida:

Usa: Cliente, producto, proveedor

Actualiza: Descripción.

Efecto: Da de baja (borra) un determinado servicio

Excepciones:

Proceso:

Mostrar listado de servicios

Pedir conformidad

SI se confirma ENTONCES

dar de baja el servicio seleccionado

dar de baja la relación con los productos que lo componian

SI NO

volver al menú de baja de servicios

FIN SI

Modificación de productos: Modifica los datos de un determinado producto.

Entrada:

Salida:

Usa: Proveedores

Actualiza: Productos, Previsiones, Servicio

Efecto: Modifica la ficha del producto seleccionado.

Excepciones:

Proceso:

Seleccionar un determinado producto

Editar la ficha del producto mediante un formulario en pantalla.

Modificación por parte del usuario de los datos del producto (a excepción de identificación)

Pedir conformidad con los datos

SI se confirma ENTONCES

Registrar el producto en las tablas Productos

Registar los cambios en servicio

Sumar el valor del producto en la tabla de previsión, y calcular el valor a guardar

SI NO

Volver al menu de modificar producto

FIN SI

Modificación de clientes: Modifica los datos del cliente.

Entrada:

Salida:

Usa: Clientes, Municipio

Actualiza: Clientes, Dirección

Efecto: Modifica la ficha de cliente, la localidad de residencia debe de existir en el listado de municipios y códigos postales.

Excepciones: Si existe un cliente con el mismo NIF que se introduce se mostrará un mensaje de error y se saldrá de la función.

Proceso:

Seleccionar un determinado cliente

Editar la ficha del cliente mediante un formulario en pantalla.

La localidad de residencia se elige de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registrar los cambios en las tablas afectadas

SI NO

Anular la asignación de datos del cliente dejando los datos anteriores

FIN SI

Modificación de proveedores: Modifica los datos de un proveedor.

Entrada:

Salida:

Usa: Proveedor, Municipio

Actualiza: Proveedor, Dirección

Efecto: Modifica la ficha de proveedor, la localidad de residencia debe de existir en el listado de municipios y códigos postales.

Excepciones: Si existe un proveedor con el mismo CIF que se introduce se mostrará un mensaje de error y se saldrá de la función.



Proceso:

Seleccionar un determinado proveedor

Editar la ficha del proveedor mediante un formulario en pantalla.

La localidad de residencia se elige de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registrar los cambios en las tablas afectadas

SI NO

Anular la asignación de datos del proveedor dejando los datos anteriores

FIN SI

Modificación de previsiones: Modifica los datos de una previsión .

Entrada:

Salida:

Usa: Clientes, Proveedores, periodo, movimiento

Actualiza: Movimiento-Previsto

Efecto: Modifica una ficha de previsiones de abonos o ingresos

Excepciones:

Proceso:

Seleccionar una determinada previsión

Editar la ficha de previsión mediante un formulario en pantalla.

Los clientes o proveedores se eligiran de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registrar los cambios en las tablas afectadas

SI NO

Anular la asignación de datos de la previsión dejando los datos anteriores

FIN SI

Modificación de servicios: Modifica los datos de un servicio.

Entrada:

Salida:

Usa: Cliente, Proveedor, Producto

Actualiza: Descripción

Efecto: Modifica un servicio contratado por un cliente que consta de una serie de productos.

Un cliente sólo puede contratar un producto en un determinado servicio

El cliente deberá existir como tal.

El proveedor debe estar dado de alta y como distribuidor del producto

Excepciones: Si el cliente ya tiene contratado un servicio con estos productos se indicará mediante un mensaje de error.

Proceso:

Seleccionar un determinado servicio

Editar la ficha de servicio mediante un formulario en pantalla.

Los clientes, proveedores y productos se eligiran de una lista desplegable.

Pedir confirmación

SI se confirma ENTONCES

Registar los cambios en las tablas afectadas

SI NO

Anular la asignación de datos del cliente dejando los datos anteriores

FIN SI


Listado de productos: Muestra un listado de productos.

Entrada:

Salida:

Usa: Producto

Actualiza:

Efecto: Muestra un listado por pantalla de todos lo productos que están registrados en la base de datos

Excepciones:

Proceso:

Mostrar listado


Listado de productos-proveedor: Muestra un listado de productos.

Entrada:

Salida:

Usa: Producto, proveedor

Actualiza:

Efecto: Muestra un listado por pantalla de todos lo productos que están registrados en la base de datos ordenado por proveedores o productos según voluntad del usuario.

Excepciones:

Proceso:

Seleccionar orden

CASO por productos

Mostrar listado ordenado por productos

CASO por proveedores

Mostrar listado ordenado por proveedores

Listado de clientes: Muestra un listado de clientes.

Entrada:

Salida:

Usa: Clientes, vive_en

Actualiza:

Efecto: Muestra un listado por pantalla de todos lo clientes que están registrados en la base de datos

Excepciones:

Proceso:

Mostrar listado

Listado de servicios: Muestra un listado de servicios.

Entrada:

Salida:

Usa: Cliente, Proveedor, Descripción, Producto, Servicio

Actualiza:

Efecto: Muestra un listado por pantalla de todos lo productos que están registrados en la base de datos

Excepciones:

Proceso:

Mostrar listado


      1. Subordinados: Base de Datos

      2. Dependencias: Gegaco

      3. Interfaces: Ver función

      4. Recursos: Ninguno

      5. Referencias: Ninguna

      6. Proceso: Ver función

      7. Datos: Ver módulo Base de Datos

    1. Módulo: Movimientos

      1. Tipo: Abstracción funcional (colección de funciones)

      2. Objetivo: Realiza las distintas operaciones sobre el estado contable de Gestransa.

      3. Función:

Ingresos: Realiza las actualizaciones correspondientes a un ingreso.

Entrada:

Salida:

Usa: Cliente, Proveedor, Movimiento

Actualiza: Cuenta

Efecto: Realiza el apunte de un ingreso en cuenta

Excepciones:

Proceso:

Leer el importe del ingreso y su descripción.

Leer fecha del sistema

Operar con el saldo e importe del ingreso

Perdir conformidad

SI se confirma ENTONCES

Actualizar movimiento en tabla cuenta

SI NO

Anular la asignación de datos volver al menú de movimientos.

FIN SI

Abonos: Realiza las actualizaciones correspondientes a un abono.

Entrada:

Salida:

Usa: Cliente, Proveedor, Movimiento

Actualiza: Cuenta

Efecto: Realiza el apunte de un abono en cuenta

Excepciones:

Proceso:

Leer el importe del abono y su descripción.

Leer fecha del sistema

Operar con el saldo e importe del abono

Perdir conformidad

SI se confirma ENTONCES

Actualizar movimiento en tabla cuenta

SI NO

Anular la asignación de datos volver al menú de movimientos.

FIN SI


Ultimos movimientos: Listado de los movimientos indicados por el operador.

Entrada:

Salida:

Usa: Cuenta

Actualiza:

Efecto: Muestra por pantalla un listado de los últimos movimientos de la cuenta

Excepciones:

Proceso:

Leer en número de movimientos a mostrar

Mostrar listado de cuenta

Ultimos días: Listado de los movimientos realizados en los dias indicados por el operador.

Entrada:

Salida:

Usa: Cuenta

Actualiza:

Efecto: Muestra por pantalla un listado de los movimientos de la cuenta en los n dias indicados

Excepciones:

Proceso:

Leer en número de dias a mostrar

Mostrar listado de cuenta


Previsión: Listado de la previsión de movimientos de los 30 próximos dias.

Entrada:

Salida:

Usa: Movimiento-previsto, cuenta

Actualiza:

Efecto: Muestra por pantalla un listado de la previsión de movimientos en la cuenta

Excepciones:

Proceso:

Leer fecha actual

Calcular movimientos de los 30 próximos días según periodicidad.

Mostrar listado de cuenta


Compras: Muestra una previsión sobre la compra de una serie de artículos

Entrada:

Salida:

Usa: Proveedor, Previsión, Producto

Actualiza

Efecto: A partir de los datos acumulados sobre el precio de los productos, calcula el importe apróximado de una compra indicada por el operador.

Excepciones:

Proceso:

Mostar lista de productos

Recoger selección de productos

Estimar precios

Mostrar listado por pantalla


      1. Subordinados: Base de Datos

      2. Dependencias:Gegaco

      3. Interfaces: Ver función

      4. Recursos: Ninguno

      5. Referencias: Ninguna

      6. Proceso: Ver función

      7. Datos: Ver módulo Base de Datos

    1. Módulo: Informes

      1. Tipo:Abstracción funcional (colección de funciones)

      2. Objetivo: Realiza las distintas operaciones sobre el estado contable de Gestransa.

      3. Función:

Informe tabular: Genera un informe de los proveedores.

Entrada:

Salida:

Actualiza:

Usa: Proveedores, Servicio

Efecto: Muestra en pantalla un gráfico tabular de los proveedores

Excepciones:

Proceso

Realizar gráfico


Sectores: Genera un informe de los ingresos.

Entrada:

Salida:

Actualiza:

Usa: Clientes, Servicio

Efecto: Muestra en pantalla un gráfico de sectores de los ingresos agrupados por clientes

Excepciones:

Proceso

Cálculos de los ingresos

Realizar gráfico

Barras: Genera un informe de los gastos reales con respecto a los presupuestados.

Entrada:

Salida:

Actualiza:

Usa: Cuenta, Movimiento-previsto

Efecto: Muestra en pantalla un gráfico de barras indicando las diferencias encontradas entre lo presupuestado y lo real

Excepciones:

Proceso

Calcular valores

Realizar gráfico

Impresión: Impresión de un gráfico

Entrada: Gráfico a imprimir

Salida:

Actualiza:

Usa:

Efecto: Realiza la impresión en la impresora determinada del último gráfico generado.

Excepciones: Si no hay ningún gráfico generado no será accesible desde el menú

Proceso

Imprimir gráfico


      1. Subordinados: Base de Datos

      2. Dependencias:Gegaco

      3. Interfaces: Ver función

      4. Recursos: Ninguno

      5. Referencias: Ninguna

      6. Proceso: Ver función

      7. Datos: Ver módulo Base de Datos

        6. VIABILIDAD Y RECURSOS ESTIMADOS


Esta aplicación puede ejecutarse en una máquina tipo PC de gama media o superior. Los recursos mínimos estimados son los siguientes:





        7. MATRIZ REQUISITOS COMPONENTES



Base de datos

Gegaco

Gestión

Movimiento

Informe

R 1.1

X


-

-

-

R 1.2

-

X

-

-

-

Función 1.1

-

-

X

-

-

Función 1.2

-

-

X

-

-

Función 1.3

-

-

X

-

-

Función 1.4

-

-

X

-

-

Función 1.5

-

-

X

-

-

Función 1.6

-

-

X

-

-

Función 1.7

-

-

X

-

-

Función 1.8

-

-

X

-

-

Función 1.9

-

-

X

-

-

Función 1.10

-

-

X

-

-

Función 1.11

-

-

X

-

-

Función 1.12

-

-

X

-

-

Función 1.13

-

-

X

-

-

Función 1.14

-

-

X

-

-

Función 1.15

-

-

X

-

-

Función 1.16

-

-

X

-

-

Función 1.17

-

-

X

-

-

Función 1.18

-

-

X

-

-

Función 1.19

-

-

X

-

-

Función 1.20

-

-

X

-

-

Función 2.1

-

-

-

X

-

Función 2.2

-

-

-

X

-

Función 2.3

-

-

-

X

-

Función 2.4

-

-

-

X

-

Función 2.5

-

-

-

X

-

Función 2.6

-

-

-

X

-

Función 3.1

-

-

-

-

X

Función 3.2

-

-

-

-

X

Función 3.3

-

-

-

-

X

Función 3.4

-

-

-

-

X

R 2.1

X

-

-

-

-

* R 2.2

-

*

*

*

-

R 2.3

-

-

-

-

X

R 2.4

-

-

-

-

*

R 4.1

-

R

-

-

-

**R 4.2

-

-

-

-

-

R 5.1

-

-

-

-

-

R 6.1

X

-

-

-

-

R 6.2

-

-

-

-

-

R 7.1

-

-

-

-

-

R 7.2

-

-

-

-

-

**R 8.1

-

-

-

-

-

**R 8.2

-

-

-

-

-

NOTA 1: Los requisitos marcados con (*) se deberán comprobar

NOTA 2: Los requisitos marcados con (**) no se cumplen



    8. UML

      8.1 Introducción

UML es una notación que se produjo como resultado de la unificación de la técnica de modelados de objetos; ha sido diseñado para un amplio rango de aplicaciones, proporcionando construcciones para un amplio rango de sistemas y actividades. El desarrollo de sistemas se enfoca en tres modelos diferentes del sistema:


      8.2 Notación

      1. Diagramas de caso de uso

Los casos de uso se utilizan durante la obtención de requerimientos y el análisis para representar la funcionalidad del sistema; se enfocan en el comportamiento del sistema desde el punto de vista externo, describiendo una función proporcionada por el sistema que produce un resultado visible para un actor. Un actor describe cualquier entidad que interactúa con el sistema (un usuario, otro sistema, un ambiente físico del sistema,...): La identificación de los actores y los casos de uso da como resultado la definición de la frontera del sistema. Cuando los actores y los casos de uso intercambian información, se dice que se comunican.

La descripción de un caso de uso se hace mediante una plantilla de seis campos:


Los casos de uso se describen en lenguaje natural. Cuando nos referimos a un caso de uso en particular, es decir, una descripción del conjunto de acciones concretas, hablamos de un escenario, esto es una instacia de un caso de uso; para referirnos a un escenario se usa una plantilla de tres campos:



8.2.2.1 Relaciones de los casos de uso

Los diagramas de clase se usan para describir la estructura de un sistema, formalizan el conocimento del dominio de la aplicación. Las clases son abstracciones que especifican los atributos y comportamientos de un conjunto de objetos. Los objetos son entidades que encapsulan estado y comportamiento. Cada objeto tiene una identidad: se puede hacer referencia a él de manera individual y es distinguible con respecto a otros objetos.

En UML las clases y objetos se represetan en cuadrados, con el nombre, atributos y operaciones (estas dos se pueden omitir, por claridad). Los nombres de objetos estarán subrayados para indicar que son instancias. Los nombres de clase comienzan con mayúscula.

La conexión entre objetos se llaman vínculos, las conexiones entre clases asociaciones (que serán grupos de vínculos), con el fin de aclarar el propósito de la asociación, se pueden etiquetar con papeles.

Cada extremo de una asociación puede ser etiquetado con números para indicar la cantidad de vínculos que se pueden originar a partir de una instancia de la clase.

Cuando una asociación tiene atributos y operaciones se denomina clase asociación y se conecta a la asociación mediante una línea de guiones.

Cuando una asociación tiene atributos y operaciones se denomina clase asociación y se conecta a la asociación mediante una línea de guiones. Cuando se quiere representar la composición (estado,región, pueblo) en UML se utiliza la agregación, una línea con un rombo en el estremo del contenedor de la asociación. La agregación enfatiza los aspectos jerarquicos de la relación.

La generalización es la aplicación típica de objetos, con la superclase, subclases y relaciones de herencia. La clase abstracta se nombra en cursiva.


8.2.3 Diagramas de secuencia

Los diagramas de secuencia se usan para formalizar el comportamiento del sistema y para visualizar la comunicación entre objetos. Son útiles para la identificación de objetos adicionales que participen en los casos de uso.

Un objeto interactúa con otro objeto enviando mensajes. La recepción de un mensaje por parte de un objeto activa la ejecución de una operación, la cual, a su vez puede enviar mensajes a otros objetos

En los diagramas de secuencia cada columna representa un objeto que participa en la interacción. El eje vertical representa el tiempo de arriba a abajo. Los mensajes se indican con flechas, cuyos rótulos son el nombre del mensaje y pueden contener argumentos.

Mediante los diagramas de secuencia se pueden indicar situaciones con un nivel de detalle variable, cuando la secuencia es abstracta (es decir, describe todas las interacciones posibles) los diagramas de secuencia también proporcionan notaciones para condiciones e interadores. Una condición en un mensaje se indica por una expresión entre corchetes de forma que si la condición es cierta se envía en mensaje. La repetición se indica mediante un asterisco '*'.


8.2.4 Diagramas de gráfica de estado

Los diagramas de gráfica de estado describen el comportamiento de un objeto individual como varios estados y transiciones entre esos estados, es decir, es una notación para la descripción de la secuencia de estados por los que pasa un objeto en respuesta a eventos externos. Un estado es una condición que satisface un objeto, una abstracción de los valores de atributo de una clase. Una transición representa cambios de estado activados por eventos, condiciones o tiempo. Para reducir la complejidad se pueden utilizar transiciones internas o gráficas de estado aisladas. Las transiciones internas son transiciones que permanecen dentro de un sólo estado.


8.2.5 Diagramas de actividad

Un diagrama de actividad describe un sistema desde el punto de vista de las actividades. Una actividad se puede definir como estados que representan la ejecución de un conjunto de operaciones, cuya terminación dispara una transición hacia otra actividad (se pueden asimilar al DFD y al DFC).

Los diagramas de actividad pueden representar decisiones (ramificaciones del flujo de control) como un rombo con una o más flechas entrantes y dos o más flechas salientes, rotuladas con las condiciones que permiten seleccionar la rama.

La sincronización de varias actividades o la división del flujo de control en varios hilos se indican con transiciones complejas, que son acciones que pueden suceder en paralelo. Estas acciones se pueden separar en carriles si interesa indicar el objeto o subsistema que realiza las acciones.



8.2.6 Organización de los diagramas

Los modelos crecen en complejidad conforme se van refinando, esta complejidad puede manejarse agrupando en paquetes los elementos relacionados. Un paquete es un agrupamiento de elementos del modelo (similar a una organización de ficheros y directorios). Los paquetes no son necesariamente jerarquicos, es decir, la misma clase puede aparecer en más de un paquete. Se debe de tener en cuenta que un paquete es una forma de organización por ello no tiene los comportamientos asociados a un objeto (mensajes ...) Se puede asociar una nota a un diagrama con el fin de agregar información a los modelos y a los elementos de los modelos.


8.2.7 Extensiones al diagrama.

Si algo se ha aprendido en la historia del modelado de sistemas software, es que difícilmente se consigue modelar una amplia clase de sistemas mediante una notación fija. Por esta razón UML proporciona varios mecanismos de extensión del lenguaje.

Un estereotipo es un texto encerrado entre parentesis angulares <<texto>>, que se añade a un elemento UML, como una clase o una asociación, se usa para crear nuevos tipos de bloque de construcción que se necesitan en el dominio.

Una restricción es una regla que se añade a un bloque de construcción UML, permite representar fenómenos. La notación es un texto entre corchetes.

8.3 Diseñando con UML.

8.3.1 Obtención de requerimientos

8.3.1.1 Identificación de los actores

Es el primer paso de la obtención de requerimientos; sirve para definir las fronteras del sistema y para encontrar todas las perspectivas desde las cuales los desarrolladores necesitan considerarlo. En una compañia, por lo general, ya existen la mayoría de los actores correspondiéndose a los papeles dentro de la organización. Como se dijo los actores representan entidades externas que interactúan con el sistema, son abstracciones de los papeles y no necesariamente tienen una correspondencia directa con personas.

Para tratar de identificar a los actores se pueden hacer las siguientes preguntas:

El siguiente paso es determinar la funcionalidad a la que tiene acceso cada actor, información que se puede extraer usando escenarios y formalizando el uso de casos de uso.

En una aplicación de gestión de una biblioteca comarcal los actores que podríamos identificar son: socios, lectores , el bibliotecario y bibliotecas ajenas (prestamo interbibliotectario).


8.3.1.2 Identificación de escenarios

Un escenario es una descripción concreta e informal de una sola característica del sistema desde el punto de vista de un sólo actor. Los escenarios pueden tener muchos usos diferentes durante la obtención de requerimientos y durante otras actividades del ciclo de vida, algunas características son:

En la obtenión de requerimientos, los desarrolladores y usuarios escriben y refinan una serie de escenarios para obtener una comprensión compartida de lo que debe ser el sistema. Se suelen utilizar las siguientes preguntas para identificar escenarios:

Normalmente estas preguntas se responden con los documentos existentes sobre el dominio de la aplicación. Los desarrolladores deben redactar los escenarios usando términos del dominio de la aplicación. El paso siguiente es formalizar los escenarios hacia los casos de uso.

Nombre del escenario : Petición_interbiblioteca


Instancias de actores: Roberto: bibliotecario


participantes: Pepe: Socio

Juana: Bibliotecario externo


Flujo de eventos: 1. Pepe está buscando un libro en el sistema. El volumen en cuestión no está disponible en la biblioteca de su pueblo, pero el mismo sí que aparece en una de la comarca perteneciente a la red interbibliotecaria.

2. Pepe captura los datos y rellena una ficha de solicitud de prestamo interbibliotecario.

3. Roberto recibe la petición, comprueba su corrección y realiza la petición a la biblioteca externa.

4. Juana recibe la petición de Roberto, gestiona la viabilidad del prestamo, registra los datos y procede al envío del libro solicitado.

5. Roberto tras recibir la aceptación del prestamo interbibliotecario hace saber a Juan que su petición ha sido aceptada y cursada.


8.3.1.3 Identificación de casos de uso

Las relaciones entre actores y casos de uso permiten que los desarrolladores y usuarios reduzcan la complejidad del modelo e incrementen su comprensibilidad. Las relaciones de comunicación entre actores y casos de uso representan el flujo de información durante el caso de uso. Se debe distinguir entre el actor que inicia el caso de uso y los demás actores con los que se comunica el caso de uso. Un caso de uso extiende otro caso de uso si puede incluir el comportamiento de la extensión bajo determinadas condiciones. Mediante la extensión separamos el flujo común de eventos del excepcional. Podemos evitar redundancias en los casos de uso mediante las relaciones de inclusión.


Relación de comunicación.







Relación extendida Crédito interbibliotecario



Relación de inclusión



8.3.2 Documentación de la obtención de requerimientos

UML no es una notación exclusivamente gráfica, los resultados de la actividad de obtención de requerimientos se documenta en el Documento de Análisis de Requerimientos (RAD), que describirá por completo al sistema desde el punto de vista de los requerimientos funcionales y no funcionales, y sirve de base contractual entre el cliente y los desarrolladores (no hay que olvidar que el software de código abierto también puede [y debería] tener clientes). Una plantilla para un RAD puede ser la siguiente:

          1. Introducción

            1.1 Propósito del sistema

            1.2 Alcance del sistema

            1.3 Objetivos y criterios de éxito del proyecto

            1.4 Definiciones, siglas y abreviaturas

            1.5 Referencias

            1.6 Panorama

          2. Sistema actual

          3. Sistema propuesto

            3.1 Panorama

            3.2 Requerimientos funcionales

            3.3 Requerimientos no funcionales

              3.3.1 Interfaz de usuario

              3.3.2 Documentación

              3.3.3 Consideraciones Hardware

              3.3.4 Características de desempeño

              3.3.5 Manejo de errores y condiciones extremas

              3.3.6 Cuestiones de calidad

              3.3.7 Modificaciones al sistema

              3.3.8 Ambiente físico

              3.3.9 Cuestiones de seguridad

              3.3.10 Cuestiones de recursos

            3.4 Pseudorequerimientos (restricciones de diseño e implementación impuestas)

            3.5 Modelos del sistema

              3.5.1 Escenarios

              3.5.2 Modelo de casos de uso

              3.5.3 Modelo de objetos

                3.5.3.1 Diccionario de datos

                3.5.3.2 Diagramas de clase

              3.5.4 Modelos dinámicos

              3.5.5 Interfaz de usuario: Rutas de navegación y maquetas de pantallas


            8.4 Análisis y UML

            8.4.1 Panorama de análisis

El modelo de análisis utilizando UML está compuesto por tres modelos individuales: el modelo funcional (casos de uso y escenarios), el modelo de objetos de análisis (diagramas de clase y objetos), y el modelo dinámico (gráficas de estado y diagramas de secuencia). Tras obtener los requerimientos de los usuarios, descritos como casos de uso y escenarios, se debe refinar el modelo funcional y derivar el modelo de objetos y el dinámico, con el fin de obtener una descripción más precisa y completa conforme se añaden detalles al modelado de análisis.

Productos de obtención de requerimientos y análisis.

Diagrama de actividad UML.





Composición del modelo de análisis:




8.4.2 Conceptos de análisis

8.4.2.1 Objetos entidad, frontera y control

El modelo de objetos de análisis consiste en identificar los objetos de entidad, frontera y control:

Objetos de entidad: Representan la información persistente rastreada por el sistema.

Objetos frontera: representan la interacción entre los actores y el sistema.

Objetos control: representan las tareas realizadas por el usuario y soportadas por el sistema.


Modelar de esta forma proporciona una forma simple para distinguir conceptos diferentes pero relacionados. Da como resultado objetos más pequeños y especializados y se producen modelos más adaptables. Para distinguir estos objetos utilizamos estereotipos para introducir esta metainformación a los elementos de modelo. Por ejemplo:




8.4.2.2 Revisión de la multiplicidad de asociación.

La multiplicidad indica la cantidad de vínculos que pueden originiarse desde una instancia de la clase conectada al extremo de la asociación. En UML, un entremo de una asociación puede tener como multiplicidad un conjunto de enteros arbitrarios, sin embargo las más normal son los siguientes tipos:



La adición de multiplicidad a las asociaciones incrementa la cantidad de información que capturamos del dominio de la aplicación o del dominio de la solución, por ello la especificación de la multiplicidad de una asociación puede ser crítica para determinar los casos de uso que se necesitan para manipular objetos del dominio de la aplicación.


8.4.2.3 Asociaciones calificadas


Un calificador permite reducir las asociaciones de uno a muchos o de muchos a muchos, de forma que el modelo sea más claro y se tengan que tomar en cuenta menos casos. Un ejemplo claro es una estructura de archivos donde un archivo pertenece a un directorio, muchos archivos pueden tener el mismo nombre en el contexto del sistema de archivos, pero sólo puede existir uno en un directorio. La representación con calificación es la siguiente:





8.4.3 Actividades de análisis: desde los casos de uso hasta los objetos

8.4.3.1 Identificación de objetos de entidad.

Tras tener identificados los objetos participantes en la obtención de requerimientos, debemos obtener los objetos entidad, una heurística comúnmente aceptada para su identificación es la siguiente:

Como ya se ha comentado los objetos de frontera representan la interfaz del sistema con los actores. En cada caso de uso, cada actor interactúa con al menos, un objeto de frontera, el cuál, recopila la información del actor y la traduce a una forma neutral de interfaz que puede ser utilizada por los objetos de entidad y también por los objetos de control. A pesar de que los objetos de frontera modelan la interfaz de usuario a un nivel burdo, no describen con detalle los aspectos visuales de la interfaz de usuario, por ello no hay que llegar a detalles como botón o elemento de menú, ya que dada la evolución del interfaz a lo largo del diseño e incluso en versiones funcionales estables, la actualización del modelo de análisis cada vez que se hace un cambio visual a la interfaz consume tiempo y no produce ningún beneficio sustancial.


Como método de identificación para los objetos frontera tenemos:

8.4.3.3 Identificación de objetos de control.

Los objetos de control son responsables de la coordinación entre objetos de frontera y de entidad, normalmente no tienen una contraparte concreta en el mundo real. Por lo general se crean al inicio de un caso de uso y desaparecen cuando termina. Son los responsables de recopilar información de los objetos de frontera y enviarla a los objetos de entidad. Por ejemplo describe el comportamiento asociado a la secuencia de formularios.


Una heurística aceptada para su identificación es:

8.4.3.4 Modelado de interacción entre objetos: diagramas de secuencia.

Un diagrama de secuencia une los casos de uso con los objetos. Muestra cómo se distribuye el comportamiento de un caso de uso (o escenario) entre sus objetos participantes. Para su trazado podemos utilizar el siguiente método:




Mediante la construcción de diagramas de secuencia no sólo modelamos el orden de la interacción entre objetos sino que también distribuimos el comportamiento del caso de uso, es decir, se asignan responsabilidades a cada objeto en forma de un conjunto de operaciones. Durante el análisis permiten identificar nuevos objetos participantes y comportamiento faltantes.

8.4.3.5 Identificación de asociaciones

Los diagramas de clase permiten que los desarrolladores describan la conectividad especial de los objetos, una asociación muestra una relación entre dos o más clases. Las asociaciones tienen varias propiedades:

En un principio, las asociaciones entre objetos de entidad son lo más importante, ya que se revela más información acerca del dominio de la aplicación., cada asociación debe tener un nombre y papeles asignados a cada extremo.

Heurística para la identificación de asociaciones:

Los atributos son propiedades de objetos individuales, cuando éstas se identifican, sólo deben considerarse los atributos relevantes para el sistema. Las propiedades que están representadas por objetos no son atributos. Por esto es importante indentificar la mayor cantidad de asociaciones posibles antes de identificar los atributos para no confundirlos con objetos. Los atributos tienen:

Los atributos representan la parte menos estable del modelo de objetos. Con mucha frecuencia se descubren o añaden más adelante en el desarrollo. A menos que estos atributos añadidos estén asociados con funcionalidad adicional, no implican cambios importantes en la estructura del objeto (ni del sistema).

Un modelo que permite identificar los objetos (Rumbaugh):

8.4.3.7 Modelado del comportamiento no trivial

Los diagramas de secuencia se usan para distribuir un comportamiento entre objetos y para identificar operaciones. Los diagramas de secuencia representan el comportamiento del sistema desde la perspectiva de un solo caso de uso. Los diagramas de gráfica de estado representan el comportamiento desde la perspectiva de un solo objeto. La visión del comportamiento desde la perspectiva de cada objeto permite que el desarrollador identifique casos de uso faltantes y que construya una descripción más forma del comportamiento del objeto. No es necesario construir gráficas de estado para cada clase del sistema, sólo es necesario para los objetos que tienen una vida extendida y un comportamiento no trivial.

8.4.3.8 Modelado de las relaciones de generalización entre objetos

La generalización se usa para eliminar redundancias en el modelo de análisis. Si dos o más clases comparten atributos o comportamientos, la similitudes se consolidan en una super clase.

8.4.3.9 Resumen del análisis

La actividad de requerimientos es muy iterativa e incremental, conforme crece la descripción del sistema y los requerimientos se hacen más concretos, los desarrolladores necesitan extender y modificar el modelo de análisis de forma ordenada para administrar la complejidad de la información.

La siguiente figura indica la secuencia típica de las actividades de análisis mediante un diagrama de actividades UML:



8.5 Actividades de diseño en UML

8.5.1 Panorama de diseño

Tras la especificación de requerimientos y la fase de análisis que hemos realizado tenemos los siguientes productos:

Nos falta, pues, la manera en la que se debe realizar el sistema. El primer paso del diseño se da en esta dirección, y nos dará como resultado:

8.5.2 Conceptos del diseño de sistemas

Para reducir la complejidad del dominio de la aplicación identificamos partes más pequeñas, llamadas clases, y las organizamos en paquetes. Igualmente, para reducir la complejidad del dominio de solución descomponemos un sistema en partes más simples, llamadas subsistemas, compuestas de varias clases del dominio de solución.

Un subsistema se caracteriza por los servicios que proporciona a otros subsistemas. Un servicio es un conjunto de operaciones relacionadas que comparten un propósito común. El conjunto de operaciones de un subsistema que está disponible para otros subsistemas, forma la interfaz del subsistema, que incluye el nombre de las operaciones, sus parámetros, sus tipos y sus valores de retorno. El diseño de sistemas se enfoca a la definición de los servicios proporcionados por cada subsistema, el diseño de objetos se enfocará a la definición de las interfaces de los subsistemas (tipo de parámetros y valor de retorno). Esto no es gratuito ya que una buena definición de la interfaz, con el mínimo de información sobre su implementación, minimiza el impacto de los cambios. Para el desarrollo de subsistemas debe de tenerse en cuenta los aspectos de coherencia y acoplamiento indicados en este documento (punto 5.2.4 Diseño Modular Efectivo).

8.5.3 Actividades del diseño de sistemas.

Las principales actividades a realizar son las siguientes:

8.5.4 Documentación del diseño del sistema

El diseño del sistema se plasma en el Documento de Diseño del Sistema (SDD), qué describe los objetivos del diseño propuestos para el proyecto, la descomposición en subsistemas (Diagramas de Clase en UML), correspondencia entre hardware y software (Diagramas de Despliegue UML), y demás datos obtenidos. Un modelo de plantilla puede ser el siguiente:

  1. Introducción

    1. Propósito del sistema

    2. Objetivos del diseño

    3. Definiciones, siglas y abreviaturas.

    4. Referencias

    5. Panorama

  2. Arquitectura del software actual (si procede).

  3. Arquitectura del software propuesto.

    1. Panorama

    2. Descomposición en subsistemas

    3. Correspondencia entre hardware y software

    4. Administración de datos persistentes

    5. Control de acceso y seguridad

    6. Control de software global

    7. Condiciones de frontera

  4. Servicios de subsistema

  5. Glosario


De todos estos apartados, el único que no ha sido tratado es la tercera sección, Arquitectura del software propuesto, que está dividida en siete subsecciones:





1Un diccionario de datos representa las relaciones entre los datos y las restricciones sobre los elementos de una estructura de datos; su uso simplifica la definición de algorítmos.

69