Unidad 4: Metodología  para el Análisis y el Planteamiento del Problema.

Identificación del Problema.

Para resolver un problema es necesario el entendimiento completo de que exactamente consiste el  problema y que tipo de solución se necesita. Es necesario comprender la naturaleza del problema ya que así se puede llegar a establecer un problema bien definido para obtener una solución satisfactoria.

Es de suma importancia analizar el problema, diagnosticar e identificar requerimientos y necesidades para así determinar las 3 etapas en la construcción de la solución; la entrada, el proceso y la salida.

Para esto, se requiere una metodología que defina cada uno de los pasos que nos llevara a obtener la solución, visto de otro modo, generar un plan de acción eficaz para alcanzar la meta.

Es necesario establecer especificaciones de entrada proceso y salida, en la primera etapa encontramos información de entrada o inicial, que servirá para el análisis del problema.

La segunda etapa o fase es analizar el problema, en esta etapa es conveniente dividir o segregar las tareas necesarias e identificadas que ayudaran a la solución del problema dado. De esta forma se simplificaran y serán más comprensibles para su desarrollo, es recomendable siempre ir de las tareas o actividades más simples a las más complejas. En esta fase se transforma la información de entrada recibida.

La tercera etapa en la programación de algoritmos, consiste en la implantación y puesta en desarrollo del mismo, aquí se obtiene la información y resultado final resultante de las etapas anteriores.

Es necesario seguir una serie de pasos sistemáticos para que el desarrollo posea una buena un óptimo y eficaz resultado. Estos pasos son brindados por los modelos de ciclo de vida, los cuales están constituidos por diferentes etapas:

Modelo de ciclo de vida

Para lograr esto, existen modelos de análisis estructurado que se puede detallar en el siguiente cuadro:

Modelo del análisis estructurado moderno.

La calidad del diseño debe ser una meta para el diseñador. El diseño estructurado ofrece guías para apoyar al diseñador a determinar módulos, y sus interconexiones, que mejor realizarán los requerimientos especificados por el analista. Las dos reglas más importantes son las referentes al acoplamiento y la cohesión.

Según Taylor S. Diseño es el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para permitir su realización física.

Se pueden considerar los objetivos del diseño estructurado de la siguiente forma:

·          Eficiencia

·         Mantenibilidad

·         Modificabilidad

·          Flexibilidad

·          Generalidad

·         Utilidad

Pudiéramos decir que el diseño es la capacidad de producir y aplicar un modelo que sirva como base para su implementación, todo esto bajo metodologías y estándares que gracias a estos se podrá desarrollar dicho modelo bajo criterios para solucionar un problema.

Los métodos de desarrollo de software pueden dividirse en dos grupos: función/dato y orientados a objetos

Orientado a función o dato

Son aquellos métodos en que las funciones o los datos son vistos como entidades independientes, tienen a ser sistemas difíciles de mantener y dependen de la estructura de los datos que usualmente producen programas difíciles de leer o modificar, pero tienen fuerte transformación de datos y usualmente son dependientes los programas de la estructura de los datos.

Orientado a objetos

Se consideran métodos orientados a objetos en donde los cuales, datos y funciones están relacionados, la abstracción de datos, son mapeados a entidades del mundo real, tienden a ser más fáciles de mantener y leer gracias a la construcción de subclases.

Desarrollo de la solución

Una vez que se obtenga la solución tomando en cuenta todas las posibles alternativas se escribe de forma clara y precisa para que pueda ser entendida y revisada. Consiste en definir cada uno de los pasos que nos permitirá llegar a la solución, en pocas palabras, explica claramente cuáles son las acciones para llegar a la meta. Esta serie de pasos se conocen como algoritmos.

Podemos hablar del modelo esencial  como la aplicación de la metodología de Análisis Estructurado Moderno de Yourdon. La idea fundamental con la que el modelo esencial es concebido es la de Tecnología Perfecta en la cual no hay restricciones de cantidad de memoria, tamaño del disco o velocidad del procesador. El modelo esencial del sistema indica lo que el sistema debe hacer para satisfacer los requisitos del usuario y debe mencionar el mínimo posible de como el sistema se llevará a cabo.

Dentro de este modelo se encuentra El Modelo del Ambiente: Declaración de los objetivos. Creación de un Diagrama de Contexto y de una Lista de Eventos, describe los estímulos que recibe el sistema y las respuestas generadas por los estímulos. Definición del Diccionario de Datos inicial. Tabla de Estímulo/Respuesta.

También se consigue dentro del modelo esencial al Modelo de Comportamiento: Creación de un diagrama de flujo de datos o DFD, y un ERD por cada uno de los eventos de la Lista de Eventos. Los DFDs por eventos se unen en un único DFD (el Modelo Funcional) y los ERDs por eventos se unen en un único ERD (el Modelo de Datos). Se acostumbra, también, modelar el comportamiento externo del sistema con DTE, árboles de pantallas o menús, etc. La creación simultánea del modelo de datos, modelo funcional y modelo de interfaz o comportamiento externo, ayuda en la validación y completitud del modelo esencial (descubriendo, por ejemplo, eventos no considerados).

Luego de establecer el modelo esencial, se debe considerar las imperfecciones de la tecnología y determinar: la cantidad de procesadores necesarios, las cualidades de estos procesadores, el tamaño de disco necesario de acuerdo al volumen de la información a ser almacenada, etc. Luego se diseña la solución sobre la base de esas restricciones tecnológicas, esto es el modelo de implementación, que se fundamenta en 3 modelos base, el modelo del usuario, modelo de distribución y modelo de programa.

IDENTIFICACIÓN DE LOS DATOS NECESARIOS (ENTRADAS) Y LOS DATOS A OBTENER (SALIDAS).

La entrada, se considera como todos los datos que hay que ingresar para la resolución del problema. Para diseñar un algoritmo o programa se debe comenzar por identificar las tareas más importantes para resolver el problema y disponerlas en el orden en el que han de ser ejecutadas. Los pasos en esta primera descripción pueden requerir una revisión adicional antes de que podamos obtener un algoritmo claro, preciso y completo.

Este método de diseño de algoritmos en etapas, yendo de los conceptos  generales a los de detalle, se conoce como método descendente (top-down).

En un algoritmo se deben de considerar tres partes:

·         Entrada: Información dada al algoritmo.

·         Proceso: Operaciones o cálculos necesarios para encontrar la solución del problema.

·         Salida: Respuestas dadas por el algoritmo o resultados finales de los procesos realizados.

Como ejemplo supongamos que desea desarrollar un algoritmo lo primero que debemos hacer es plantearnos las siguientes preguntas:

Especificaciones de entrada

                ¿Que datos son de entrada?

                ¿Cuántos datos se introducirán?

                ¿Cuántos son datos de entrada válidos?

Entendido el problema (que se desea obtener del computador), para resolverlo es preciso analizar:

                *Los datos o resultados que se esperan.

                *Los datos de entrada que nos suministran.

                *El proceso al que se requiere someter esos datos a fin de obtener los resultados esperados.

                *Áreas de trabajo, fórmulas y otros recursos necesarios.

Una recomendación muy práctica es el que nos pongamos en el lugar del computador, y analizar que es necesario que me ordenen y en que secuencia, para poder producir los resultados esperados. También da buenos resultados hacer similitudes con la labor de un empleado que hace el mismo trabajo que deseamos programarle al computador.

Especificaciones de salida

                ¿Cuáles son los datos de salida?

                ¿Cuántos datos de salida se producirán?

                ¿Qué formato y precisión tendrán los resultados?

Lista de Eventos

La lista de eventos es una lista narrativa de los estímulos que ocurren en el mundo externo, y al que el sistema debe responder. En pocas palabras al saber que datos de entrada obtendremos podemos hacer una correlación de estimulo respuesta en esta tabla.

La lista de eventos es una simple lista textual de eventos del ambiente a los cuales el sistema debe responder. Al construirla asegúrese de distinguir entre un evento y un flujo relacionado a un evento.

Gracias a esto se pueden establecer diferentes patrones de acción dependiendo de la entrada, se pueden destacar:

·         Evento de flujo

·         Se asocia a un flujo de datos; es decir, el sistema percibe la ocurrencia del evento cuando un grupo de datos llega.

·         Eventos Temporales

·         Se descargan en un cierto momento,  los eventos temporales no se descargan ni son representados por cualquier flujo de datos de entrada.

·         Eventos de control

·         Son estímulos externos que ocurren en momentos imprevistos.

·         Eventos de múltiple respuesta

·         Hay múltiples transacciones que son activadas por la condición temporal . Dichas transacciones son activadas por un Evento Temporal que precisa de múltiples respuestas.

Diagrama de Contexto

En el diagrama de contexto una única burbuja (proceso) representa el sistema. Los Agentes Externos (o Terminadores) por definición no son parte del sistema y están representados por un cuadro rectangular y se comunican directamente con el sistema a través de los Flujos de Datos o de Control.

Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente un terminador es una persona o un grupo, por ejemplo una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, el terminador puede ser otro sistema.

Como se está  interesado en el desarrollo del modelo esencial del sistema, es importante que se distinga entre fuentes y manipuladores cuando se dibuja a los agentes externos en el diagrama de contexto. Un manipulador es un mecanismo, dispositivo, o el medio físico para transportar datos dentro o fuera del sistema.

Los flujos mostrados en el diagrama de contexto modelan los datos que llegan y dejan el sistema. Estos serán incluidos en este diagrama si son necesarios para determinar un evento del ambiente al que el sistema debe contestar, o si son necesarios (como datos) para que se produzca una respuesta. También pueden mostrarse los flujos de datos en el diagrama del contexto cuando los datos son producidos por el sistema para responder a un evento.

Hay también una clase de flujos que no representan entrada o salida de datos del sistema sino que establecen la necesidad de ejecutar una función dada. Estos flujos se denominan flujos de control y son mostrados con una línea punteada.

Diagrama de Contexto

Se puede comenzar con la lista de eventos o con el diagrama de contexto. Realmente, esto no  importa, a medida que los componentes del modelo ambiental son generados se debe confirmar que haya consistencia entre ellos.

DESCRIPCIÓN DE LAS OPERACIONES A UTILIZAR (CÁLCULOS)

Dentro de este método de análisis y planteamiento del problema, se llega a obtener una estructura clara y eficaz por medio de una serie de pasos para alcanzar la solución del problema, esto también cuenta con operaciones dentro de los algoritmos que podemos llamar cálculos.

Estos cálculos son determinados durante el proceso de planificación y estructuración del sistema, de manera simple en DFD de nivel bajo y detallada en creación en sí de la escritura y codificación del sistema que contempla la meta planteada.

Estos cálculos están íntimamente conectados con el tipo de dato de entrada que se espera recibir y la salida que nos interesa obtener, todo previamente planificado según el caso, se formulan operaciones precisas ya sean lógicas o aritméticas representadas como instrucciones a seguir.

DESCRIPCIÓN DE LOS PASOS PARA LLEGAR A LA SOLUCIÓN (PROCESOS).

La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesidades del sistema. De nueva cuenta, herramientas y técnicas especiales auxilian al analista en la determinación de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma gráfica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, así como sus respectivas especificaciones.

Durante esta fase el analista de sistemas analiza también las decisiones estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden determinar las condiciones, las alternativas de condición, las acciones y las reglas de acción.

Existen tres métodos principales para el análisis de decisiones estructuradas: español estructurado, tablas y árboles de decisión.

En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. Si la administración de la empresa considera factible alguna de las recomendaciones, el analista sigue adelante. Cada problema de sistemas es único, y nunca existe sólo una solución correcta. La manera de formular una recomendación o solución depende de las cualidades y la preparación profesional de cada analista.

Creación de diagrama de flujo de datos

Para la creación del DFD básicamente existen dos enfoques: Partición en Eventos McMenam,  Yourdon y Enfoque de Análisis Estructurado Clásico DeMarco, Gane.

En el enfoque de partición por eventos para la construcción del DFD preliminar, se agrega una burbuja por cada evento definido en la lista de eventos. Por cada evento, se especifican los flujos (control y datos), agentes externos y depósitos de datos considerado por McMenam como partición de eventos y DeMarco lo llamo enfoque de análisis estructurado.

En el enfoque de análisis estructurado clásico  para la construcción del DFD de primer nivel (o nivel 0), el analista (o el grupo de analistas) estudia el diagrama de contexto y crea un DFD de nivel 0 sin una estrategia que lo asista. Sobre la base de su conocimiento del sistema, o del tipo de aplicación, divide en "Burbujas Importantes" (por ejemplo, que representen subsistemas).

El DFD preliminar puede ser representado como un único diseño o por un conjunto de Diagramas separados. Para la construcción del diagrama de flujo de datos preliminar, con un enfoque de partición por eventos, la metodología de análisis estructurado moderna propone la siguientes cuatro etapas:

1.      Se diseña una burbuja (proceso) para cada evento de la Lista de Eventos.

2.      La burbuja recibe un nombre de acuerdo con la respuesta que el sistema debe dar al evento asociado.

3.      Se diseñan los flujos de entrada y salida apropiados de modo que cada burbuja sea capaz de emitir una respuesta necesaria, y se diseñan los depósitos para la comunicación entre las burbujas.

4.      El DFD preliminar resultante es verificado en relación con el Diagrama de Contexto, la Lista de Eventos y el Modelo de Datos para confirmar si esta completo y consistente.

El DFD preliminar se compone de un solo nivel con una burbuja para cada uno de los eventos. Ahora, precisamos subdividirlo en niveles superiores (abstracción). Esto quiere decir que deseamos agrupar los procesos (o burbujas) relacionados en funciones de más alto nivel de abstracción, cada uno representando una burbuja en el diagrama de más alto nivel.

Existen tres reglas que nos ayudan en el proceso de abstracción:

1.      Cada agrupamiento de procesos debe involucrar respuestas estrictamente relacionadas (véase que cada burbuja en el DFD preliminar tiene un nombre relativo a la respuesta de un evento de la lista de eventos). Esto habitualmente significa que los procesos trabajan con datos estrechamente relacionados.

2.      Agrupar procesos que trabajen con los mismos almacenamientos. Así, si usted encontrara un grupo de procesos con flujos para el mismo depósito, sin que otros procesos (que no son del grupo) se refieran a este depósito, entonces puede crear una burbuja, en el nivel más alto, que  oculte el depósito.

3.      Se debe notar que la persona que examinara sus diagramas de flujo de datos, será un usuario o  un analista de sistemas o un diseñador, que quiere ver todo de una sola vez. Un buen criterio de agregación o agrupamiento no tiene más de siete más o menos dos (7 ± 2) fragmentos de información (considerando como fragmentos de información a los Procesos y los Depósitos  de Datos).

El diagrama de flujo de datos describe cómo los datos fluyen a través del sistema, pero no proveen información acerca de estructuras de control o de secuencias de ejecución. La única secuencia que puede ser reconocida en un DFD es la determinada por la necesidad de información. Podemos considerar al diagrama de flujo de datos como un lenguaje gráfico, útil para describir la funcionalidad de un sistema, en un cierto grado de detalle.

El Diccionario de Datos

El diccionario de datos es una herramienta fundamental en el modelamiento de sistemas. Las herramientas gráficas como los diagramas de flujo de datos, los diagramas de entidad-relación, los diagramas de transición de estados, etc., son de mucha importancia para el modelamiento estructural de los sistemas (estructuras funcionales, estructuras de información, estructuras de comportamiento, etc.) y permiten una adecuada interpretación general de las ideas modeladas pero, no son completos. Para contar con una especificación completa es preciso tener una descripción textual de los detalles que no pueden ser especificados en los diagramas.

El diccionario de datos es una lista organizada de todos los elementos de datos pertinentes al sistema (todos los nombres de las componentes de los diagramas), con definiciones precisas y rigurosas para que el usuario y el analista de sistemas puedan conocer todas las entradas, salidas, componentes de depósitos y cálculos intermedios.

Diagrama de flujo de datos

Un proceso representa una componente funcional del sistema. Un proceso transforma, distribuye o genera datos. Por ejemplo, los procesos pueden realizar operaciones aritméticas o lógicas sobre los datos que recibe para producir algún resultado. Respecto a esto, un DFD describe únicamente los nombres y los flujos de entrada y salida, sin aportar ninguna otra información sobre las actividades internas de los procesos. Para describir con mayor detalle, y especificar la funcionalidad por la que es responsable el proceso, se utilizan técnicas de especificación de procesos.

Un depósito de datos es incluido en un DFD para modelar la necesidad de almacenar datos, se utiliza para modelar un conjunto de paquetes de datos en reposo. Un depósito de datos puede representar un archivo en el disco de la computadora o un área de memoria global a los procesos. En la literatura es posible encontrar que este mismo concepto puede recibir otros nombres como por ejemplo: Archivo, Almacenamiento de Datos o Repositorio.

Diagrama de Almacenamiento de datos

Refinamiento y Descomposición de procesos

Un DFD es una herramienta comúnmente utilizada para análisis de arriba hasta abajo, es decir que permite realizar un análisis que va de lo general a lo particular del problema. Los DFDs son utilizados para modelar tanto vistas detalladas como de alto nivel de un sistema o programa por eso es útil el refinamiento de procesos en un DFD. La funcionalidad de un proceso puede llegar a ser tan compleja que para comprenderlo sea necesario detallar sus actividades de manera separada.

Los procesos del DFD pueden ser refinados en otra red de procesos conectados por flujos de datos, constituyendo un DFD de menor nivel de abstracción. Esta forma de especificar un proceso, por medio de otro DFD completo se denomina refinamiento, descomposición o explosión. El problema es definir cuál es el criterio más adecuado para hacer esto y, determinar hasta dónde bajar en la jerarquía de DFDs, es decir cuando parar de realizar explosiones.

na de las formas más sistemáticas de realizar el refinamiento de un proceso es el que propone Mike Adler, con el Álgebra de Descomposición de Procesos. Se aplica un álgebra, definida por un conjunto de operadores, a cada uno de los procesos del DFD por separado. En los procesos que generan dudas con relación a su funcionalidad sirve como una guía para su descomposición, mientras que para los procesos que generan muy pocas dudas con relación a su funcionalidad, puede ser utilizado como un método de validación. Los operadores son aplicados para producir una expresión mínima.

Al desarrollar un sistema, cualquiera fuere su tamaño, es necesario contar en primer término, con una narrativa textual y una declaración concisa de los objetivos del sistema (la funcionalidad que se requiere, es decir lo que se espera que el sistema haga), por supuesto validada con el usuario del sistema.