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

Ensayo # 3 – Diferencias entre Análisis y Diseño Estructurado y Orientado a Objetos
Vicente Mejia / 14-SISP-1-008
Diferencias entre Análisis y Diseño Estructurado y Orientado a Objetos
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 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.
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"
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.
Tabla de Diferencias
Análisis y Diseño Estructurado
Análisis y Diseño Orientado a Objetos
Se consideran los conceptos básicos como el Objeto y el
Se consideran los elementos o perspectivas básicas del
Atributo, el todo y sus partes (software), clases y miembros.
análisis (Entrada-Proceso-Salida), en función del Software.
Modela los objetos que son parte de él.
Utiliza el diagrama estructurado como representació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 Consta de 4 Fases (Análisis, Diseño, Evolución y
e Integración).
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 verificables contra la realidad.
Si están correctamente definidas las jerarquías de clase,
No acomoda el tipo de desarrollo evolutivo. No enfoca los hacer modificaciones no es tan costoso como en el caso de
posibles modos futuros de desarrollo de software.
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.
Un programa que se usa en un ambiente real
En este análisis se llega solo a la fase de integración y no necesariamente debe cambiar. Los cambios difieren un poco
toma en consideración los cambios que ocurren dentro de los requeridos en evolución, pues contemplan la
del sistema en el proceso de análisis y diseño de sistemas. 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
Es una forma de pensar acerca de un problema en términos
funciones y sub-funciones. El analista debe comprender
del mundo real en vez de en términos de un ordenador. El
primero el dominio del problema y a continuación
AOO permite analizar mejor el dominio del problema, sin
documentar las funciones y sub-funciones que debe
pensar en términos de implementar el sistema en un
proporcionar el sistema. No existe un mecanismo para
ordenador. El AOO permite pasar directamente el dominio
comprobar si la especificación del sistema expresa con
del problema al modelo del sistema.
exactitud los requisitos 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
Los objetos encapsulan tanto atributos como operaciones.
poca influencia de un modelo en otro. En la práctica, los
Debido a esto, el AOO reduce la distancia entre el punto de
modelos de procesos y de datos de un mismo sistema se
vista de los datos y el punto de vista del proceso, dejando
parecen muy poco. En muchos casos son visiones
menos lugar a inconsistencias o disparidades entre ambos
irreconciliables, no del mismo sistema, sino de dos puntos
modelos.
de vista totalmente diferentes de organizar la solución.
Bibliografía: http://www.oocities.org/es/raicelysgomez/analisis/t1.html