Análisis y Diseño Estructurado Vs. Orientado a Objetos

Especialización en Gerencia de Sistemas de Información
Análisis y Diseño de Sistemas

Diferencias entre Análisis y Diseño Estructurado
y Orientado a Objetos

	Realizado Por:	Ing. Raicelys M. Gómez Camacho
		Ing. Yulaidys Ramírez

Tal y como lo definiera el autor, Senn J. (1992): “El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra en estudio” (p.35). De acuerdo a esta definición, la acción de adquirir información acerca del funcionamiento de algún sector de la organización, es obtener una investigación detallada del tema objeto de estudio. Esta información detallada y pormenorizada del entorno en estudio, conlleva a la determinación de ciertas condiciones o requerimientos propios de un sistema. Existen diversos métodos y técnicas que conducen a un modelo del sistema mucho más óptimo y eficiente, como es el caso del Análisis y Diseño Estructurado y el Orientado a Objetos, ambos con muchos puntos a favor y con el objetivo común de orientar al analista el la selección de acciones que representen un cambio positivo a la organización. A pesar de la aceptación que tienen ambas metodologías actualmente, el propósito de esta investigación es poder compararlas y evaluarlas a fin de determinar que realmente marca la diferencia cuando se analizan y diseñan sistemas de información con el uso de estas poderosas herramientas.

Enfoque Estructurado Vs. Enfoque Orientado a Objetos

En cuanto a la forma de desarrollar el análisis las metodologías son radicalmente diferentes desde su enfoque, la primera está orientada a procesos, tomando una visión donde los datos se consideran separadamente de los procesos que los transforman, dando más importancia a la descomposición funcional del sistema, y por tanto a los diagramas de procesos, esto puede parecer que lleva de manera más directa a la implementación del sistema, pero con frecuencia éste suele ser más frágil. Si cambian los requerimientos un sistema basado en descomposición funcional puede requerir una reestructuración masiva.

Por el contrario el enfoque orientado a objeto se centra en primer lugar en identificar los objetos del dominio de aplicación y después en establecer procedimientos que los manejen. Aunque esto pueda parecer más indirecto el software orientado a objeto se mantiene mejor ante los cambios de requerimientos porque se basa en la estructura subyacente del dominio de aplicación en vez de los requerimientos funcionales de un determinado problema.

Análisis y Diseño Estructurado (ADE)

— • El Análisis se refiere al "extremo inicial" de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados.

— • El Análisis estructurado introduce el uso de las herramientas de documentación gráficas para producir un tipo diferente de especificación funcional: "la especificación estructurada".

Conceptos que se relacionan con el Análisis Estructurado

— • Símbolos gráficos; iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.
—• Diccionario de datos; descripciones de todos los datos utilizados en el sistema.
—• Descripciones de procesos y procedimientos; declaraciones formales que emplean técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.
—• Reglas; estándares para describir y documentar el sistema en forma correcta y completa.

Fase de Diseño

En esta fase, el diseño esctructurado produce el modelo de diseño con los siguientes elementos:
— • Diseño de datos. Transforma el modelo de dominio de la información creado durante el análisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidad-relación y el contenido detallado de datos del diccionario de datos constituyen la base para el diseño de datos.
— •Diseño arquitectónico. Define la relación entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de análisis y de la interacción de subsistemas definidos dentro del modelo de análisis.
— •Diseño de interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la información necesaria para el diseño de la interfaz.
— •Diseño procedimental. Transforma elementos estructurales de la arquitectura del programa en una descripción procedimental de los componentes del software. Se obtiene a partir de la especificación del proceso, la especificación del control y el diagrama de transición de estados

Análisis y Diseño Orientado a Objetos (ADOO)

Es un método de análisis que examina los requerimientos desde la perspectiva de clase y objetos encontrada en el vocabulario original del problema. Se fundamenta en un conjunto de cinco principios básicos:
— • Modelar el dominio de la información.
— • Describir la función del módulo.
— • Representar el comportamiento del modelo.
— • Dividir el modelo para mostrar más detalles.
En este tipo de análisis los modelos iniciales representan la esencia del problema, mientras que los últimos aportan detalles de la implementación.

Características del Análisis Orientado a Objetos

— • Identidad: Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos. Estos pueden ser tangibles o intangibles.
— • Clasificación: Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupan para formar una misma clase, se dice que cada objeto es una instancia de su propia clase, y una clase es una abstracción que describe propiedades importantes para una aplicación y se olvida del resto.
— • Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases, una operación es una acción o transformación que se aplica a un objeto.
— • Herencia: Comparte atributos y operaciones entre clases tomando como base una relación jerárquica, es decir que se puede definir una clase que después producirá subclases, sabiendo que todas las subclases adquirirán todas y cada una de las propiedades de su super-clase y le agrega además sus propiedades exclusivas.

Fase de Diseño

Para los sistemas orientados a objetos es posible definir un diseño en pirámide con las siguientes cuatro capas:
— • Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta.
— • Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. También contiene representaciones de diseño para cada objeto.
— • Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores. Establece las interfaces externas e internas para el sistema.
— • Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los atributos y operaciones de cada objeto.

Tabla de Diferencias

Análisis y Diseño Estructurado	Análisis y Diseño Orientado a Objetos
Se consideran los elementos o perspectivas básicas del análisis (Entrada-Proceso-Salida), en función del Software.	Se consideran los conceptos básicos como el Objeto y el Atributo, el todo y sus partes (software), clases y miembros. Modela los objetos que son parte de él.
Utiliza el diagrama estructurado como represetación gráfica del sistema.	Utiliza el diagrama orientado a objetos como representación gráfica del sistema.
Consta de 5 Fases (Análisis, Diseño, Codificación, Pruebas e Integración).	Consta de 4 Fases (Análisis, Diseño, Evolución y Modificación).
No enfoca apropiadamente el diseño de familias de programas. Asume una progresión relativa uniforme de pasos de elaboración.	Une a los usuarios y a los diseñadores. Permite proporcionar una descripción completa del problema, legible y revisable por las partes interesadas y verificable contra la realidad.
No acomoda el tipo de desarrollo evolutivo. No enfoca los posibles modos futuros de desarrollo de software.	Si están correctamente definidas las jerarquías de clase, hacer modificaciones no es tan costoso como en el caso de programación tradicional. Sólo hay que entrar en la parte de Evolución para hacer modificaciones.
El Diseño inicia una vez que ha culminado la fase de análsis de sistema.	El Diseño inicia aún antes de concluir con la etapa de análisis. Se recomienda analizar un poco y diseñar. Esta etapa debe concluir una vez que se establecieron claves y mecanismos importantes.
En este análisis se llega solo a la fase de integración y no toma en consideración los cambios que ocurren dentro del sistema en el proceso de análisis y diseño de sistemas.	Un programa que se usa en un ambiente real necesariamente debe cambiar. Los cambios difieren un poco de los requeridos en evolución, pues contemplan la introducción de nuevas funcionalidades no previstas en el problema original.
Las herramientas utilizadas son: Diagrama de Flujo de Datos, Diagramas de Entidad-Relación, Diagrama de Transición de Estados.	Las herramientas utilizadas son: Diagramas de Clases, Diagrama de Objetos, Diagramas de Módulos, Diagramas de Procesos, Diagramas de Transición de Estados, Diagramas de Tiempo.
El análisis está orientado a los Procesos del sistema.	El análisis está orientado a los Objetos.
Requiere traducir el dominio del problema en una serie de funciones y subfunciones. El analista debe comprender primero el dominio del problema y a continuación documentar las funciones y subfunciones que debe proporcionar el sistema. No existe un mecanismo para comprobar si la especificación del sistema expresa con exactitud los requisitos del sistema.	Es una forma de pensar acerca de un problema en términos del mundo real en vez de en términos de un ordenador. El AOO permite analizar mejor el dominio del problema, sin pensar en términos de implementar el sistema en un ordenador. El AOO permite pasar directamente el dominio del problema al modelo del sistema.
Este enfoque se adapta bien al uso de sistemas informáticos para implementar el sistema, pero no es nuestra forma habitual de pensar. La comunicación entre el analista y la Organización está limitada, por las fases.	El concepto OO es más simple y está menos relacionado con la informática que el concepto de flujo de datos. Esto permite una mejor comunicación entre el analista y el experto en el dominio del problema (es decir, el cliente).
La relación entre los modelos es muy débil, y hay muy poca influencia de un modelo en otro. En la práctica, los modelos de procesos y de datos de un mismo sistema se parecen muy poco. En muchos casos son visiones irreconciliables, no del mismo sistema, sino de dos puntos de vista totalmente diferentes de organizar la solución.	Los objetos encapsulan tanto atributos como operaciones. Debido a esto, el AOO reduce la distancia entre el punto de vista de los datos y el punto de vista del proceso, dejando menos lugar a inconsistencias o disparidades entre ambos modelos.

Caso Práctico. Aplicar ambos enfoques de análisis y diseño de sistemas para tratar de optimizar el proceso de generar Copias Certificadas en el Circuito Judicial Penal de Tucupita, Estado Delta Amacuro

El caso en estudio consiste en elaborar una propuesta para optimizar especificamente el proceso de emisión de Copias Certificadas solicitadas a diario por la comunidad ante este despacho jurídico, cabe mencionar que en la actualidad esta actividad se efectúa de manera exclusivamente manual, utilizando herramientas bastante obsoletas, como las máquinas de escribir y basandose en informaciones contenidas en los registros de libros de actas que se encuentran archivados en conjunto con otro elevado número de libros que representan todas las competencias del ente judicial. Este procedimiento ambiguo por demás, genera pérdidas de tiempo en respuesta al público y búsqueda y tratamiento de la información por parte de los funcionarios que allí laboran, inclusive fatiga al tener que transcribir grandes volúmenes de datos de acuerdo a lo solicitado y más aún excesivos pasos y procedimientos para completar las actividades.

Según el Modelo Estructurado

El Análisis Estructurado, fue seleccionado como técnica de investigación de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lógica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle. Este es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a través de un sistema, la representación gráfica de los procesos del sistema estará a cargo de los Diagramas de Flujos de Datos (DFD).

Diagrama de Flujos de Datos del Proceso Actual

Diseño del Sistema

El uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que permite mostrar gráficamente y de manera general, el funcionamiento del sistema y los procesos necesarios para su desarrollo. Los DFDs se pueden dibujar con sólo cuatro notaciones sencillas, en este caso, la notación utilizada está basada en el enfoque de Gane y Sarson.
Origen/Destino de Datos: Representan entidades externas al sistema que se comunican con él y que están fuera de su control. Las relaciones existentes entre las entidades no se representan en el DFD, ya que no son parte del sistema bajo estudio. Para este diseño forman parte de las entidades los Justiciables, la cual incluye a todas aquellas personas que tienen relación directa con el proceso. Las entidades Secretaria, Juez y Asistente, quienes conforman al órgano jurídico y son los garantes de llevar a cabo el proceso judicial.
Procesos: Muestran la parte del sistema que transforma las entradas de datos en salida; en tal sentido, el diagrama (DFD Propuesto) muestra cinco (5) procesos considerados vitales para el funcionamiento y operatividad de la aplicación:
—Solicitar Copias Certificadas; en el cual se supervisa que las solicitudes a procesar estén conforme a los requisitos establecidos por el Código de Procedimiento Civil, o alguna otra Ley que condicione la puesta en marcha de éstas.
—Verificar Existencia de Actas en el Sistema; en el se constata que el acta que tiene relación con la copia certificada solicitada esté o no en los archivos del circuito y de ese modo se tenga acceso directo a el.
—Generar Copias Certificadas; encargado de procesar los reportes generados por el sistema, en este caso la emisión directa de las Copias Certificadas solicitadas
—Registro Automático de Libros; en el se almacena una serie de datos proveniente del procesamiento de las solicitudes.
—Firmar y Sellar Actas: Proceso manual que se limita a autenticar las Copias Certificadas previa su entrega al solicitante
Flujo de Datos: El flujo describe el movimiento de paquetes de datos que viajan desde una parte del sistema a otra. Están representados por una flecha para mostrar su origen y su destino.
Almacén: Representa una colección de paquetes de datos que permanecen en estado de reposo. No está referido exclusivamente a medios de almacenamiento electrónico como bases de datos en discos duros, sino también a archiveros metálicos o cualquier otro medio que permita guardar datos en carpetas u hojas de papel.

Diagrama de Flujos de Datos del Proceso Propuesto

Según el Modelo Orientado a Objetos

James Martín, en su libro “Análisis y diseño de un sistema, Orientado a Objetos”, señala que en el mundo orientado a objetos, el analisis se realiza al estudiar los objetos en un ambiente y los eventos que interactuan con dichos objetos. Por tal razon, hace referencia que una herramienta util para la descripcion de tales eventos son los Diagramas de flujo de Objetos (DFO), porque permiten mostrar las actividades que interactuan con otras en un sistema cualquiera. Los DFO a diferencia de los DFD permiten mostrar no solo la transferencia de datos, si no tambien representar cualquier cosa que se transfiera de una actividad a otra; es decir, indicar los objetos que se producen y las actividades que producen e intercambian.

Diagrama de Flujos de Objetos del Proceso Actual

Diseño del Sistema

Los Diagramas de Flujo de objetos, en general describen los objetos y como se producen y se consumen. Por ello para representar los procesos de nuestro caso se emplearon las simbologias descritas por James Martin y James Odell; graficadas por medio de cuatro notaciones:

Agentes Externos: Cajas sombreadas que representan en nuestro caso al Justiciable, Asistente y Secretaria.
Actividades: Visualizan las actividades llevadas a cabo por los agentes externos; desde que se solicita hasta que se obtiene una Copia Certificada.
Producto: Es el resultado final que satisface el propósito de la actividad
Direccion de flujo de lineas: Flechas que señalan el inicio y final del flujo de Objetos o Actividades

Diagrama de Flujos de Objetos del Proceso Propuesto

Inicio