UNIVERSIDAD YACAMBU
ESPECIALIZACION EN GERENCIA
MENCION SISTEMAS DE INFORMACION

ANÁLISIS Y DISEÑO DE SISTEMAS
Prof.: Yaros Pérez                        Autor: Manuel Alvarez

C.I: 6.504.212

Trabajo No. 1
Análisis y Diseño Estructurado y Orientado a Objetos

Índice

1.1- Definición Análisis y Diseño Estructurado

1.2- Definición Análisis Orientado a Objetos

2- Diferencia

3- Caso Práctico

4- Infografía

1.1 - Definición Análisis y Diseño Estructurado

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de 1) la división del sistema en componentes y 2) la construcción de un modelo del sistema. El método incorpora elementos tanto de análisis como de diseño.

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.

Elementos del análisis estructurado

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

Descripción Gráfica

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 pero sin introducir procesos manuales o computarizados, archivos en cinta o disco magnético, o procedimientos operativos y de programas. 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 sí para formar el sistema.

Diagrama de Flujo de Datos (DFD)

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.

Diccionario de Datos

Todas las definiciones de los elementos en el sistema - flujos de datos, procesos y almacenajes 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.

Diseño Estructurado

El diseño estructurado, otro elemento del análisis estructurado que emplea la descripción gráfica, 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. Este enfoque no sólo conduce hacia mejores programas sino que facilita el mantenimiento de los mismos cuando surja necesidad de hacerlo. El diseño estructurado es una técnica específica para el diseño de comprensión. Es decir, no indica nada relacionado con el diseño de archivos o bases de datos, la presentación de entradas o salidas, la secuencia de procesamiento o el hardware que dará soporte a la aplicación. Esta técnica conduce a la especificación de módulos de programa que son funcionalmente independientes.

Diagramas de Entidad Relación

Es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.

Componentes: Tipos de Objetos, Relaciones, Relaciones Asociativas, Subtipos / Supertipos.

Diagramas de Transición de Estados

Enfatiza el comportamiento dependiente del tiempo. Describen que sucede cuando.

Componentes: Estados del Sistema, Cambios del Estado, Condiciones y Acciones.

1.2 - Definición Análisis y Diseño Orientado a Objetos

“La orientación a objetos será la más importante de las tecnologías que surjan en los años noventa….”

Con estas palabras muy acertadas de Bill Gates continuaremos con la definición.

La programación orientada a objetos como muchos saben, no es una programación nueva, ya lleva alrededor de 10 años por lo menos en el mercado. Pero los conceptos de orientación a objetos datan de los años cincuenta, pero dada a que la tecnología no estaba acorde con su implementación, se mantuvo como concepto hasta no hace poco.

Cuando hablamos del modelado y el diseño a objetos es un paradigma de integración, que enlazará todas las herramientas y las técnicas poderosas para la creación de software.

El análisis y diseño orientado a objeto es una forma general de ver el software, la que integrará todas las últimas tecnologías. Esta integración provocará una revolución industrial del software. Al ser así reconocida, la industria del software construirá las herramientas y los estándares que facilitarán dicha integración.

Mientras más pronta sea la difusión del análisis y del diseño orientado a objetos, más rápidamente pasará la creación del software de ser una industria de campo a una disciplina de la ingeniería.

Las personas tienen una idea clara de lo que es un objeto: conceptos adquiridos que nos permiten sentir y razonar acerca de las cosas del mundo. Un objeto podría ser real o abstracto, por ejemplo un bebé, una factura, una medida, una fecha, etc.

Dentro del software orientado a objeto, un objeto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos.

Un objeto puede estar compuesto por otros objetos. Estos últimos a su vez también pueden estar compuestos por otros objetos. Esta intrincada estructura es la que permite construir objetos muy complejos.

Los conceptos que poseemos se aplican a tipos determinados de objetos. Por ejemplo, empleado se aplica a los objetos que son personas empleadas por alguna organización. Algunas instancias de empleado podrían ser Juan Pérez, Ana Smith, etc. En el análisis orientado a objetos, estos conceptos se llaman tipos de objetos; las instancias se llaman objetos.

Así, un tipo de objeto es una categoría de objeto, mientras que un objeto es una instancia de un tipo de objeto.

Sin embargo, el término objeto tiene diferencias fundamentales con el término entidad, ya que la entidad sólo se refiere a los datos, mientras que objeto se refiere a los datos y a los métodos mediante los cuales se controlan a los propios datos. En OO, la estructura de datos y los métodos de cada tipo de objeto se manejan juntos. No se puede tener acceso o control de la estructura de datos excepto mediante los métodos que forman parte del tipo de objeto.

Los métodos especifican la forma en que se controlan los datos de un objeto. Los métodos en un tipo de objeto sólo hacen referencia a la estructura de datos de ese tipo de objeto. No deben tener acceso directo a las estructuras de datos de otros objetos. Para utilizar la estructura de datos de otro objeto, deben enviar un mensaje a éste. El tipo de objeto empaca juntos los tipos de datos y su comportamiento.

Un objeto entonces es una cosa cuyas propiedades están representadas por tipos de datos y su comportamiento por métodos.

Un método asociado con el tipo de objeto vehículo podría ser aquel que calcule la distancia a una señal determinado. Otro podría transmitir la señal de alto. Otro podría verificar de manera periódica la velocidad del vehículo.

El empaque conjunto de datos y métodos se llama encapsulado. El objeto esconde sus datos de los demás objetos y permite el acceso a los datos mediante sus propios métodos. Esto recibe el nombre de ocultamiento de información. El encapsulamiento evita la corrupción de los datos de un objeto. Si todos los programas pudieran tener acceso a los datos de cualquier forma que quisieran los usuarios, los datos se podrían corromper o utilizar de mala manera. El encapsulado protege los datos del uso arbitrario y no pretendido.

La programación orientada a objetos es una forma de diseño modular en la que con frecuencia el mundo se piensa en términos de objetos, operaciones, métodos y mensajes que se transfieren entre tales objetos. Un mensaje es una solicitud para que se lleve a cabo la operación indicada y se produzca el resultado.

El Análisis y Diseño Orientado a Objetos se puede considerar como la siguiente etapa en el desarrollo de sistemas, dado a que el concepto de objetos no es nuevo, pero ha tomado un tiempo y tecnología poder hacer la programación más amigable para entonces poder desarrollar un análisis cónsono con este desarrollo, y no una interpretación de lo que se hace cuando se emplea análisis estructurado.

El Análisis Orientado a Objetos y Desarrollo Orientado a Objetos permiten la unificación de criterios y de herramientas de desarrollo actuales y futuras.

2- Ventajas y Desventajas del Análisis y Diseño Estructurado Vs. Análisis Orientado a Objeto

Análisis y Diseño Estructurado

Trabajar con módulos manipulábles:

Ventajas:
No necesariamente se construye un sistema funcional entero como prototipo
Desventaja:
Las características del sistema que se considera poco importantes quedarán fuera del  prototipo.

Construir un prototipo con rapidez:

Ventajas:
1. Rápido para realizarse.
2. Permite al analista con excelente visión sobre la manera que deberá desarrollar el resto del proyecto.
3. Evita la asignación de recursos a un proyecto, que eventualmente podría descartarse.
Desventaja: Se debe contar con instrumentos especiales y el software adecuado para elaborar el prototipo con rapidez.

Modificar el prototipo en iteraciones sucesivas:

Ventajas: Se puede modificar en repetidas ocasiones, tantas veces hasta que los requerimientos sean cumplidos
Desventaja: Que el usuario debe de evaluar cada modificación que se le realice al prototipo, para la mejora del sistema.

Enfatizar la interfaz con el usuario:

Ventajas: Se tiene acceso directo a los requerimientos del usuario.
Desventaja: Si la interfaz con el usuario no esta bien desarrollada, no es posible que el usuario se involucre con el sistema con rapidez, el cual no ocasionaría problemas con la elaboración del prototipo.

Ventajas de la metodología orientada a objetos

En síntesis, algunas ventajas que presenta son:

• Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la reutilización masiva al construir el software.

• Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables.

• El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de utilizar.

• Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en bloques de construcción de software más complejo.

• Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces.

• Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes están construidos de modo que se pueden adaptar para un diseño particular.

• Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema.

• Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás.

• Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario gráfica de modo que el usuario apunte a iconos o elementos de un menú desplegado, relacionados con los objetos. En determinadas ocasiones, el usuario puede ver un objeto en la pantalla. Ver y apuntar es más fácil que recordar y escribir.

• Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estándar. Esto les permite ser utilizadas en múltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario gráficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que éste se especifique.

• Interacción. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros. Existe una forma estándar de localizar clases e interactuar con ellas. El software desarrollado de manera independiente en lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario.

• Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser utilizada por clientes diferentes. Estos clientes sólo pueden tener acceso a los datos del servidor a través de los métodos de la clase. Por lo tanto los datos están protegidos contra su corrupción.

• Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de software de objetos accesibles. El diseño orientado a objetos es la clave para la computación de distribución masiva. Las clases de una máquina interactúan con las de algún otro lugar sin saber donde residen tales clases. Ellas reciben y envían mensajes orientados a objetos en formato estándar.

• Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo acciones automáticas. Una base de datos OO tiene integrada una inteligencia, en forma de métodos, en tanto que una base de datos relacional básica carece de ello.

• Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden preservarse si se ajustan a un contenedor orientado a objetos, de modo que la comunicación con ella sea a través de mensajes estándar orientados a objetos.

• Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) utilizarán las técnicas gráficas para el diseño de las clases y de la interacción entre ellas, para el uso de los objetos existentes adaptados a nuevas aplicaciones. Las herramientas deben facilitar el modelado en términos de eventos, formas de activación, estados de objetos, etc. Las herramientas OO del CASE deben generar un código tan pronto se definan las clases y permitir al diseñador utilizar y probar los métodos recién creados. Las herramientas se deben diseñar de manera que apoyen el máximo de creatividad y una continua afinación del diseño durante la construcción.

Desventajas de la metodología orientada a objetos

En síntesis, algunas desventajas que presenta son:

· Alta curva de aprendizaje

· Costosa

· Requiere conocimientos adicionales

· No recomendable para proyectos pequeños

· Requiere personal especializado

3- Caso Práctico

Esta metodología es totalmente aplicable en la institución donde laboro, de hecho estamos finiquitando un proyecto de Análisis Orientado a Objeto para un entorno Web, donde crearemos una call center (Sala Situacional) en cada estado. Este recibirá todas las llamadas de la infraestructura técnica y procesara en este sistema. A continuación le muestro algunas diapositivas de la presentación del proyecto:

4.1 Infografias:

http://www.awprofessional.com/bookstore/product.asp?isbn=0201895420&rl=1

http://www.fce.unsw.edu.au/Colin/aad97/ooanalysis.html

http://www.awprofessional.com/titles/0-201-89542-0/class.htm

http://www.unsa.edu.ar/~japeralt/08YOU/ppframe.htm

http://www.fi-b.unam.mx/pp/profesores/carlos/aydoo/toc.html

4.2- Bibliografía:

Voss, Grez. Análisis y Diseño Orientado a Objetos. Prentice Hall

James A. Senn, Análisis y Diseño de Sistemas de Información (2da Edición), Mc Graw Hill