Análisis y Diseño Estructurado

Análisis y Diseño Orientado a Objetos

CONCEPTO

Actividad de construcción de modelos. Mediante una notación que es única de este método, se crean modelos que reflejan el flujo y el contenido de la información (datos y control); se parte el sistema funcionalmente y, según los distintos comportamientos, se establece la esencia de lo que se debe construir.

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se establece cómo se cumplirán los requerimientos o la forma en que implantará la aplicación. Más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.) Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

Los elementos esenciales son símbolos gráficos, diagramas de flujo de datos y diccionario centralizado de datos.

Una de las formas de describir un sistema es preparar un bosquejo que señale sus características, identifique la función para la que sirve e indique cómo éste interactúa con otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores ya que es fácil omitir algún detalle o dar una explicación que quizá los demás no entiendan.

En lugar de las palabras, el análisis estructurado utiliza símbolos, o íconos, para crear un modelo gráfico del sistema. Los modelos de este tipo muestran los detalles del sistema. Si se seleccionan los símbolos y notación correctos entonces casi cualquier persona puede seguir la forma en que los componentes se acomodarán entre si para formar el sistema.

El diagrama lógico de flujo de datos muestra las fuentes y destinos de los datos, identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que relacionan una función con otra y señala los almacenes de datos a los que se tiene acceso.

El modelo del sistema recibe el nombre de diagrama de flujo de datos (DFD). La descripción completa de un sistema está formada por un conjunto de diagramas de flujo de datos.

Para desarrollar una descripción del sistema por el método de análisis estructurado se sigue un proceso descendente (top-down). El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujo de datos cada vez más detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del sistema que se encuentra bajo investigación.

Todas las definiciones de los elementos en el sistema (flujo de datos, procesos y almacenes de datos) están descritos en forma detallada en el diccionario de datos. Si algún miembro del equipo encargado del proyecto desea saber alguna definición del nombre de un dato o el contenido particular de un flujo de datos, esta información debe encontrarse disponible en el diccionario de datos.

El Diseño Estructurado se enfoca en el desarrollo de especificaciones del software. La meta del diseño estructurado es crear programas formados por módulos independientes unos de otros desde el punto de vista funcional. Es una técnica específica para el diseño de programas y no un método de diseño de comprensión. Esta técnica conduce a la especificación de módulos de programa que son funcionalmente independientes. La herramienta fundamental del diseño estructurado es el diagrama estructurado, los cuales son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas. Los diagramas estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. Estas especificaciones funcionales para los módulos se proporcionan a los programadores antes que dé comienzo la fase de escritura de código.

Los métodos de diseño orientado a objetos han surgido para ayudar a los desarrolladores a explotar la potencia expresiva de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y los objetos como bloques básicos de construcción, la metodología orientado a objetos es un principio de desarrollo evolutivo, no revolucionario, es decir, que mas que revolucionario es evolucionario debido a que tal metodología no rompe con los avances del pasado, sino que los reestructura y los afianza de una forma que el desarrollo de aplicaciones o sistemas es mucho mas sencillo y su proceso de desarrollo mucho más dinámico que con otras metodologías estructuradas. Autores como Booch (1993) define al Análisis Orientado a Objetos (AOO) como "un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema", de los objetos Booch (1993) dice "son entidades tangibles que muestran un comportamiento bien definido". Todo esto quiere decir que el análisis orientado a objetos parte de entidades tangibles halladas en el problema, tales entidades varían dependiendo de los diversos casos prácticos, pero en todos los casos son elementos reales que toman parte del problema de forma directa. Para Booch (1993), el Diseño Orientado a Objetos (DOO) "es el método que lleva a una descomposición Orientado a Objetos. Aplicando DOO, se crea software resistente al cambio y escrito con economía de expresión. Se logra un mayor nivel de confianza en la corrección del software a través de la división inteligente de su espacio de estados. En última instancia, se reducen los riesgos inherentes al desarrollo de sistemas". Los modelos del diseño orientado a objetos reflejan la importancia de plasmar explícitamente las jerarquías de clases y objetos del sistema que se diseña. Estos modelos cubren también el espectro de las decisiones de diseño relevantes que hay que considerar en el desarrollo de un sistema complejo, y así animan a construir implantaciones que posean los atributos de los sistemas complejos bien formados. También se dice del DOO que es un método que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico, tal como aparecen en el anexo 1, del sistema que se diseña; el soporte para la descomposición orientada a objetos es lo que hace al diseño orientada a objetos diferente del diseño estructurado, el primero, utiliza abstracciones de clases y objetos para estructurar lógicamente los sistemas, y el segundo, utiliza abstracciones algorítmicas.

FUNCIÓN

La función del análisis de sistemas, conlleva más que sólo realizar análisis de requisitos, pero es en eso donde se focalizará la discusión. Una de las principales labores del analista es descubrir detalles y documentar la política de un negocio que pudiera existir sólo en forma implícita, "transmitidas de generación en generación" por los usuarios, nunca documentadas formalmente. El analista debe distinguir entre síntomas, problemas del usuario y causas. Con sus conocimientos de la tecnología de los computadores, el analista debe ayudar al usuario a explorar aplicaciones novedosas y más útiles de éstos así como nuevas formas de hacer negocios. Aunque muchos de los sistemas antiguos sólo se limitaban a perpetuar el negocio original del usuario, pero a velocidades electrónicas, hoy en día los analistas se enfrentan al desafío de ayudar al usuario a encontrar productos y mercados radicalmente innovadores, con la ayuda del computador.

Las funciones del sistema son lo que éste deberá de hacer. Hay que identificar estas funciones y listarlas en grupos lógicos. Para verificar que X es en verdad una función del sistema, la siguiente frase deberá tener sentido: "El sistema deberá hacer X". Por ejemplo: "el sistema deberá autorizar pagos a crédito".

Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras funciones.

DIFERENCIA

Este se basa en la descomposición funcional del sistema que se va a construir mostrando como fluir la información a través del sistema, manejando conceptos de  abstracción y clasificación. Incorpora modelos de datos y modelos de procesos y comportamiento.

Este viene hacer algo más que una forma de programar es también una forma de pensar sobre el problema en término del mundo real en vez del término de un ordenador. Los objetos encapsulan atributos como operaciones y reduce los puntos de vista entre datos y procesos,

VENTAJAS

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se establece cómo se cumplirán los requerimientos o la forma en que implantará la aplicación. Más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.) Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

Es una técnica específica para el diseño de programas y no un método de diseño de comprensión. Esta técnica conduce a la especificación de módulos de programa que son funcionalmente independientes. La herramienta funda-mental del diseño estructurado es el diagrama estructurado, los cuales son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas. Los diagramas estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. Estas especificaciones funcionales para los módulos se proporcionan a los programadores antes que dé comienzo la fase de escritura de código.

·           Fomenta la reutilización y extensión del código

·           Estabilidad

·           Comportamiento de objetos

·           Permite la construcción de sistemas más complejas

·           Confiabilidad

·           Nuevos mercados de software.

·           Rápido diseño

·           Mayor calidad de diseño.

·           Integridad

·           Programación más sencilla.

·           Mantenimiento más sencillo.

·           Permite relacionar el sistema al mundo real.

·           Facilita la creación de programas visuales

DESVENTAJAS

La mayoría de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposición (divide y vencerás). La estrategia es dividir el problema en unidades más pequeñas que sean manejables. Aquí se trata de descomponer el problema en funciones o procesos. Este método origina una división jerárquica de procesos constituidos por sub-procesos

·           Alta curva de aprendizaje

·           Costosa

·           Requiere conocimientos adicionales.

·           No es recomendable para pequeños proyectos.

·           Requiere personal especializado.

·           El diseño orientado a objetos es un diseño con ocultamiento de información. La representación puede cambiarse sin cambios muy extensos.

·           Un objeto tiene un estado privado con un constructor asociado y operaciones de acceso. Los objetos proveen servicios (operaciones) a otros objetos.

·           La identificación de objetos es un proceso difícil. La identificación de sustantivos y verbos en lenguaje natural es útil para identificar objetos

·           Las interfaces de objetos deben ser precisamente definidas. Un lenguaje de programación como Ada, C++ o JAVA puede usarse para esto

·        Documentación útil para el diseño orientado a objetos incluyen, gráficas de jerarquía de objetos y diagramas de interacción de objetos. Los objetos puede implementarse como entidades secuenciales o concurrentes.

DISEÑO

El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de desarrollo del software, a la que denominan diseño físico.

Los analistas de sistemas comienzan el proceso de diseño identificando los reportes y demás salidas que debe producir el sistema. Luego determinar los datos específicos para cada reporte y salida. Es común que los diseñadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema esté terminado. Lo anterior se efectúa en papel o en la pantalla de una Terminal utilizando para ello algunas de las herramientas disponibles para el desarrollo de sistemas.

El diseño de un sistema también indica los datos de entrada, aquellos que serán calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los procedimientos de cálculo y los datos individuales. Los diseñadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnéticas o incluso archivos en papel. Los procedimientos que se escriben indican cómo procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseño representan a éste de muchas maneras. La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software.

Los diseñadores son los responsables de contestar preguntas, aclarar dudas y manejar los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseño.

Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos. También se necesitará realizar un análisis y diseño orientado a objetos. El modelamiento visual es la clave para realizar el análisis OO. Desde los inicios del desarrollo de software OO han existido diferentes metodologías para hacer esto del modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de metodologías. Según los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier tipo de sistemas (no solamente de software) usando los conceptos de la orientación a objetos. Y además, este lenguaje debe ser entendible para los humanos y máquinas. Actualmente en la industria del desarrollo de software tenemos al UML como un estándar para el modelamiento de sistemas OO. Fue la empresa Racional que creó estas definiciones y especificaciones del estándar UML, y lo abrió al mercado. La misma empresa creó uno de los programas más conocidos hoy en día para este fin; el Racional Rose, pero también existen otros programas como el Poseidon que trae licencias del tipo community edition que permiten su uso libremente. El UML consta de todos los elementos y diagramas que permiten modelar los sistemas en base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se construyen en forma correcta, son fáciles de comunicar, cambiar, expandir, validar y verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes plenamente reutilizables.

• Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas
• Los objetos son independientes y encapsulan el estado y la representación de información
• La funcionalidad del sistema se expresa en términos de servicios de los objetos
• Las áreas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parámetros
• Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en paralelo

DESARROLLO

Es para grandes sistemas.

1.− Misión del sistema en componentes.

2.− La construcción de un modelo del sistema.

3.- Permite que las personas observen los elementos lógicos separados de los físicos. Se divide en :

·        Descripción Grafica.

·        Diagramas de Flujo de Datos.

·        Diccionario de Datos.

El análisis, diseño y programación orientada a objetos están relacionados pero son diferentes. El análisis orientado a objetos concierne al desarrollo del modelo de objetos del dominio de la aplicación. El Diseño Orientado a Objetos trata del desarrollo del modelo del sistema orientado a objetos para implementar los requerimientos. La programación orientada a objetos trata de la realización del Diseño Orientado a objetos utilizando algún lenguaje de programación orientada a objetos como C++