Introducción

El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial. Esto implica que son necesarias técnicas y tecnología eficientes de Ingeniería de Software para resolver los múltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas software de gran tamaño.

La Ingeniería de Software implica seguir en cualquier proyecto de software una metodología de desarrollo y la utilización de distintas técnicas y herramientas. Los diferentes procedimientos a seguir en cualquier proyecto de Ingeniería de software son: Definición de requerimientos, Análisis, Diseño, Verificación y Validación (Pruebas de Calidad del Software), Pruebas y Mantenimiento. El presente documento intenta dar a conocer y describir los conceptos y aspectos fundamentales del análisis y diseño estructurado y orientado a objetos

Análisis y Diseño Estructurado y Orientado a Objetos:

1. Análisis Estructurado

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. Éste análisis permite al analista conocer un 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 pertinente.

Objetivo:

El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada.

Componentes:

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.

Etapas:

Investigación Preliminar
Determinación de requerimientos
Definir los casos esenciales de uso
Definir los procesos que intervienen
Crear y perfeccionar el modelo conceptual

2. Diseño Estructurado

Es el proceso de decidir que componentes, y la interconexión entre los mismos, para solucionar un problema bien especificado".

El diseño es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lógicos para un sistema, y finaliza cuando el diseñador ha especificado los componentes del sistema y las relaciones entre los mismos.

El Diseño Estructurado es una técnica específica para el diseño de programas.

Objetivo:

El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.

Componentes:

Análisis de flujo de datos: Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.
Herramientas: Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.
Diagrama de flujo de datos: Es el modelo del sistema. Es la herramienta mas importante y la base sobre la cual se desarrollan otros componentes. El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.
El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos.
El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas.

Etapas:

Definir los casos reales de uso.
Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.
Perfeccionar la arquitectura del sistema.
Definir los diagramas de interacción.
Definir los diagramas de diseño de clases.
Definir el esquema de la base de datos.

3. Análisis Orientado a Objetos:

Como su propio nombre indica, lo que nos importa en este análisis es distinguir cuáles serán los objetos que van a ser parte de la aplicación.

Es 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.

Características:

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.

Comunicación. El concepto OO es más simple y está menos relacionado con la informática que el concepto de flujo de datos.

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.

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.

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.

4. Diseño Orientado a Objetos:

Se define como un diseño de sistemas que utiliza objetos auto-contenidos y clases de objetos.

Características principales del Diseño Orientado a Objetos:

§ 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

Ventajas del Diseño Orientado a Objetos:

Fácil de mantener, los objetos representan entidades auto-contenidas
Los objetos son componentes reutilizables
Para algunos sistemas, puede haber un mapeo obvio entre las entidades del mundo real y los objetos del sistema

Componentes del Diseño Orientado a Objetos

La identificación de objetos, sus atributos y servicios
La organización de objetos dentro de una jerarquía
La construcción de descripciones dinámicas de objetos que muestran como se usan los servicios
La especificación de interfaces de objetos

5. Diferencias entre análisis y diseño estructurado y orientado a objetos:

1. 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

2. El concepto Orientado a Objeto 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).

3. El paradigma Orientado a Objeto utiliza la herencia para expresar explícitamente las características comunes de una serie de objetos. Estas características comunes quedan escondidas en el análisis y diseño estructurado y llevan a duplicar entidades en el análisis y código en los programas. Sin embargo, el paradigma Orientado a Objeto 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.

4. La programación orientada a objetos es mucho más fiable por diversas razones. En primer lugar por el desarrollo incremental y la programación por diferencia, al poder ir añadiendo funcionalidad vía herencia. El tamaño medio de una rutina en entornos orientados a objetos es de 4 o 5 líneas; y se ha de tener en cuenta que sólo se tienen rutinas, ya que no existe el concepto de programa principal. La utilización masiva de librerías de clases garantiza la fiabilidad, ya que los componentes sólo se añaden a la librería cuando se ha verificado la corrección de su funcionamiento.

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.

5. El paradigma orientado a objetos 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 Análisis Orientado a Objetos permite analizar mejor el dominio del problema, sin pensar en términos de implementar el sistema en un ordenador como el análisis y diseño estructural. El Análisis Orientado a Objetos permite pasar directamente el dominio del problema al modelo del sistema.

6. 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.

7. La transición entre las fases de análisis y diseño en la orientación al objeto es mucho más suave que en las metodologías estructuradas, no habiendo tanta diferencia entre las etapa.

6. Caso Práctico

Proyecto: Desarrollo Web de un sistema Helpdesk para Sistema Hidráulico Yacambu – Quibor C.A

Objetivo: La implementación de este sistema proveerá las siguientes ventajas:

El usuario puede registrar una solicitud de servicio al departamento de telemática. Al cual se le hará un seguimiento a los tiempos de respuesta para determinar los indicadores de gestión en la calidad de servicio.

El técnico responsable de dar respuesta a la solicitud podrá desde su estación de trabajo podrá capturar el equipo destino y brindar soporte remoto a través de la lan.

Se dispondrá de una base de datos de conocimientos en base a las solicitudes ya procesadas, disponible a los usuarios, para solventar problemas ocurridos con anterioridad. Para minimizar el número de soportes recurrentes.

Determinar las necesidades de capacitación del personal.

Se llevará el historial de fallas en los equipos.

Programar mantenimiento preventivo de los equipos

Requerimientos: Servidor: Se necesita un equipo con Linux, el mismo se elaborara en PHP con MYSQL

Cliente: navegador WEB (Internet Explorer, Mozilla FireFox)

6. InfografÍa