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, sistemas de almacenamiento, etc.)  Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

 ¿Que es 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.

El diseño estructurado 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.

El diseño estructurado busca establecer la organización interna del software, produciendo sistemas que sean fáciles de entender (y por ende de construir y mantener).

• Las salidas del análisis estructurado son entradas (input) para el diseño estructurado.

• Las salidas (output) del diseño estructurado son:

• Diagrama Estructurado (estructura de software).

• Especificación de Módulos.

• Diccionario de Datos del Sistema.

El Análisis Estructurado.

 Dirigido a la primer etapa del proceso de desarrollo. Se basa en construir un modelo de las prácticas administrativas que deben ser realizadas por el nuevo sistema (desde el punto de vista lógico).

 Es crítica en esta fase la determinación y la definición de requerimientos ya que el fracaso de las especificaciones rompen todo el esfuerzo de desarrollo. Se busca conocer y especificar lo que se quiere. Si no se sabe lo que se desea no se puede esperar éxito. Las salidas (output) del análisis estructurado son (especificaciones estructuradas):

El análisis estructurado se basa en el modelo del flujo como primer elemento de la representación gráfica de un sistema basado en computadora. Usando como base diagramas de flujo de datos y de control, el analista separa las funciones que transforman el flujo. Después, crea un modelo de comportamiento usando el diagrama de transición de estados y un modelo de contenido de los datos con un diccionario de requisitos. Las especificaciones de los procesos y del control proporcionan una elaboración adicional de los detalles.

El análisis estructurado nos permite:

1. Intentar estructurar el proceso de determinación de los requerimientos.

2. Incluir todos los detalles relevantes que describen al sistema en uso.

3. Una fácil verificación cuando se han omitido detalles relevantes.

4. La identificación de los requerimientos.

5. Generar una documentación más eficiente.

Análisis y diseño orientado al objeto

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.

La habilidad más importante en el análisis y diseño orientado al objeto es asignar eficientemente las responsabilidades a los componentes de software.

El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactúan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseño debido a que los objetos funcionan basados en la manera en que funcionan otros objetos. La programación orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real.

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.

El Análisis Orientado a Objetos (AOO) se basa en conceptos sencillos, conocidos desde la infancia y que aplicamos continuamente: objetos y atributos, el todo y las partes, clases y miembros. Puede parecer llamativo que se haya tardado tanto tiempo en aplicar estos conceptos al desarrollo de software. Posiblemente, una de las razones es el éxito de los métodos de análisis estructurados, basados en el concepto de flujo de información, que monopolizaron el análisis de sistemas software durante los últimos veinte años.

El AOO ofrece un enfoque nuevo para el análisis de requisitos de sistemas software. En lugar de considerar el software desde una perspectiva clásica de entrada/proceso/salida, como los métodos estructurados clásicos, se basa en modelar el sistema mediante los objetos que forman parte de él y las relaciones estáticas (herencia y composición) o dinámicas (uso) entre estos objetos. Este enfoque pretende conseguir modelos que se ajusten mejor al problema real, a partir del conocimiento del llamado dominio del problema, evitando que influyan en el análisis consideraciones de que estamos analizando un sistema para implementarlo en un ordenador. Desde este punto de vista, el AOO consigue una abstracción mayor que el análisis estructurado, que modela los sistemas desde un punto de vista más próximo a su implementación en un ordenador (entrada/proceso/salida).

El uso de AOO puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un catálogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma, podemos obtener rápidamente un prototipo del sistema, que pueda ser evaluado por el cliente, a partir de objetos analizados, diseñados e implementados en aplicaciones anteriores. Y lo que es más importante, dada la facilidad de reutilización de estos objetos, el prototipo puede ir evolucionando hacia convertirse en el sistema final, según vamos refinando los objetos de acuerdo a un proceso de especificación incremental.

Deficiencias del análisis estructurado.

• Descomposición funcional. El análisis estructurado se basa fundamentalmente en la descomposición funcional del sistema que queremos construir. Esta descomposición funcional 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. El problema es que no existe un mecanismo para comprobar si la especificación del sistema expresa con exactitud los requisitos del sistema.
• Flujo de datos. El análisis estructurado muestra cómo fluye la información a través del sistema. Aunque este enfoque se adapta bien al uso de sistemas informáticos para implementar el sistema, no es nuestra forma habitual de pensar. Sin embargo, la abstracción y la clasificación sí son conceptos que manejamos habitualmente, aunque sea de forma inconsciente.
• Modelo de datos. El análisis clásico daba muy poca importancia al almacenamiento de datos. El análisis estructurado moderno incorpora modelos de datos, además de modelos de procesos y de comportamiento. Sin embargo 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. Lo ideal sería que ambos modelos se complementasen, no por oposición sino de forma que el desarrollo de uno facilitase el desarrollo del otro.

Ventajas del AOO.

• Dominio del problema. El paradigma OO es más que una forma de programar. 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.
• Comunicación. 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).
• Consistencia. 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.
• Expresión de características comunes. El paradigma OO utiliza la herencia para expresar explícitamente las características comunes de una serie de objetos. Estas características comunes quedan escondidas en otros enfoques y llevan a duplicar entidades en el análisis y código en los programas. Sin embargo, el paradigma OO pone especial énfasis en la reutilización, y proporciona mecanismos efectivos que permiten reutilizar aquello que es común, sin impedir por ello describir las diferencias.
• Resistencia al cambio. Los cambios en los requisitos afectan notablemente a la funcionalidad de un sistema, por lo que afectan mucho al software desarrollado con métodos estructurados. Sin embargo, los cambios afectan en mucha menor medida a los objetos que componen o maneja el sistema, que son mucho más estables. Las modificaciones necesarias para adaptar una aplicación basada en objetos a un cambio de requisitos suelen estar mucho más localizadas.
• Reutilización. Aparte de la reutilización interna, basada en la expresión explícita de características comunes, el paradigma OO desarrolla modelos mucho más próximos al mundo real, con lo que aumentan las posibilidades de reutilización. Es probable que en futuras aplicaciones nos encontremos con objetos iguales o similares a los de la actual.

Diferencias

• El análisis, el diseño y la programación orientado a los objetos comprenden la ingeniería del software para la construcción de un sistema orientado a los objetos.
• El análisis de estructuras usa métodos de programación estructural, de los que deriva los elementos del modelo de objetos.

En las técnicas estructuradas las unidades fundamentales son los procedimientos (subrutinas o subprogramas), mientras que en la programación orientada a  objetos las unidades básicas se conocen como objetos los cuales contienen tanto datos (es decir, variables de estado que describen el objeto en un cierto instante) como métodos (es decir reglas dinámicas, reglas que explican la interacción del objeto con el mundo exterior). En la terminología OO, lo anterior quiere decir que el objeto encapsula sus datos y su comportamiento. Los objetos interactúan intercambiando mensajes para producir un comportamiento colectivo, que en principio debe resolver un problema.

Caso Práctico:

Tomando en cuenta  los conceptos antes estudiados, podríamos aplicar esta metodológia, al  Postgrado de Manejo de Fauna Silvestre de la   Universidad Nacional Experimental de los Llanos "Ezequiel Zamora" Unellez, diseñando un proyecto de entorno hipertextual aplicando las fases de estructura y orientación a objetos.

Diseño estructurado

El Postgrado está estructurado en 8 subproyectos y en cada subproyecto hay 4 unidades crédito.

La arquitectura de información de las 32 unidades es muy similar y existen las siguientes subdivisiones:

• Artículo central con el contenido general y/o esencial del subproyecto.

• Documentos que complementan el artículo principal.

• Referencias externas a documentos complementarios al artículo principal.

• Ejercicios de autoevaluación.

• Foros de temas sugeridos por el profesor.

• Cartelera informativa del profesor.

• Cartelera informativa de la coordinación del Postgrado.

• Información general sobre como se  debe utilizar el entorno hipertextual, consejos de como se debe organizar la forma de estudio, fechas claves para el  proceso de enseñanza.

Orientación a  Objeto

La materialización de  estos elementos en nodos y enlaces hipertextuales se debe realizar utilizando la orientación a objeto, que consiste en la identificación de las clases de objetos que corresponden a los tipos de nodos que estan implicados en el hiperdocumento, los cuales son los siguientes:

• Clase artículo.

• Clase complemento básico.

• Clase complemento avanzado.

• clase examén de autoevaluación.

• Clase foros sugeridos (Debates/Charlas).

• Clase Cartelera informativa.

• Distintas clases de información general. (Calendarios, lista de participantes, guía didáctica, ayuda etc.)

La definición de clases se deben realizar de acuerdo a  estos criterios:

• Las referencias externas no formarán un objeto, sino una relación entre un objeto del hiperdocumento y un objeto externo de internet.

• Los distintos tipos de ejercicios deben ser modelados con las clases de  evaluación y autoevaluación. Todas las clases que esten relacionadas con la evaluación tienen una relación de agregación con la clase "menu de evaluación" y estas constituiran una unidad de navegación.

• El contenido de las unidades pueden ser de tres tipos: seminario, taller o artículo.

• Los foros, las charlas, cartelera del profesor y cartelera de la coordinación formarán un grupo de nodos especializados en gestionar la comunicación entre la  coordinación del postgrado, los profesores y los participantes. Estos nodos serán modelados con las clases, charlas, cartelera profesores y cartelera de coordinación. Todas las clases realcionadas relacionadas con la comunicación tienen una relación de agregación con la clase "menu de comunicación" y esta tambien constituirá unidad independiente de navegación.

El siguiente paso del diseño es identificar las asociaciones entre los objetos o sea, enlaces hipertextuales unidireccionales entre tipos de nodos, para así poder representar un diagrama de clases.

Finalmente, en función de la tecnología a utilizar aplicaremos el diseño tecnológico para adaptar a cada elemento a implementaciones concretas que se  generaran por la tecnología elegida.

INFOGRAFIA

http://www.elguille.info/colabora/NET2005/Percynet_Conceptosyprincipiosorientadoaobjetos.htm

Hacia mediados de los 80, los beneficios de la programación orientada a objetos empezaron a obtener reconocimiento, y el diseño de objetos pareció ser un enfoque sensato para la gente que deseaba utilizar el lenguaje de programación orientada a objetos. Un enfoque orientado a objetos para programar ofrece muchos beneficios sobre un enfoque estructurado.

El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactúan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseño debido a que los objetos funcionan basados en la manera en que funcionan otros objetos. La programación orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real.

http://www.isi.unanleon.edu.ni/gbai/Ing_Soft_PII/Capitulo_11.htm

Actualmente, los investigadores nos se han puesto de acuerdo al respecto de sí es posible la integración de estas dos estrategias de análisis y diseño en un solo método único. Algunos piensan que las dos estrategias son muy diferentes, mientras que otros creen que se pueden utilizar elementos de ambos métodos para desarrollar un modelo completo del problema. Primero, se tratara el área donde ambos métodos tienen alguna similitud y convergencia conceptual, o sea situaciones en las que pueden coexistir pacíficamente ambas técnicas.

Los elementos claves de AE/DE son:  

• El modelo de flujo.  

• Diccionario de datos.  

• La especificación del control.  

• La especificación de procesos.  

• Un diagrama de entidad-relación ( E- R ), para la modelización de datos.

La orientación a los objetos crea una representación  del campo del problema  del mundo real  y la hace corresponder  con el ámbito de la  solución  que es el software.  Por esta razón, las representaciones de AE/DE  que reflejan los elementos del mundo real relativos al problema proporcionarían un mejor puente con el  AOO/DOO. Las entidades externas (cuadros)  que representan a  los productores y consumidores  del flujo de datos será posible candidato a objetos. Los objetos de datos definidos como parte del diagrama E-R también son candidatos a objetos. Es cierto  que los DFDs  de menor nivel podrían proporcionar una indicación de los atributos  de algunos objetos y que los procesos indicados a esos diagramas podrían ser  operaciones aplicadas  a los objetos. Pero un DFD no refleja un sistema desde el punto de vista orientado a los objetos.  

http://www.monografias.com/trabajos/anaydisesis/anaydisesis.shtml

La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales:

·        Software, que son Programas de computadora, con estructuras de datos y su documentación que hacen efectiva la logística metodología o controles de requerimientos del Programa.

·        Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas.

·        Personal, son los operadores o usuarios directos de las herramientas del Sistema.

·        Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software.

·        Documentación, Manuales, formularios, y otra información descriptiva que detalla o da instrucciones sobre el empleo y operación del Programa.

·        Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento.

 http://www.monografias.com/trabajos28/programacion-objetos/programacion-objetos.shtml