METODOLOGIAS PARA MODELAR SOFTWARE ANÁLISIS Y DISEÑO ESTRUCTURADO vs. ORIENTADO A OBJETO INTRODUCCIÓN El Analista de Sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen. El Analista de Sistemas también tiene dentro de sus actividades el Análisis y Diseño de sistemas el cual se refiere al "proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados." (Senn, 1992, p.11). Ésta actividad se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable. Todo análisis y diseño de sistemas líderizado o no por un analista de sistemas posee fases que pueden dividirse de forma lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. Es aquí donde pueden ser utilizadas diferentes metodologías entre las cuales se pueden mencionar: el Análisis y Diseño Estructurado y el Análisis y Diseño Orientado a Objeto. La investigación que se presenta a continuación define las dos metodologías mencionadas anteriormente así como también, las diferencias que existen entre ellas. Por último se presenta un Caso Practico donde se planeta un ejemplo de cómo se puede utilizar la metodología Orientada a Objeto en un proyecto Web que le sirva a la empresa donde laboro. 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 elemetos tanto de análisis como de diseño. ANÁLISIS ESTRUCTURADO 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 se implantará la aplicación. Más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separado 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 Descripción Grafica: Utiliza símbolos o iconos para crear un modelo grafico del sistema. Sin introducir procesos manuales o informatizados, archivos, entre otros.
Diagramas de Flujo de Datos: Tienen la misión de Mostrar las fuentes y destinos de los datos, Identificar y dar nombre a los procesos, Dar nombre a los grupos de datos que relacionan una funcion con otra, Señalar los almacenes de datos a los que se tiene acceso. Diccionario de Datos: Se definen flujo de datos, procesos y almacenes 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 la necesidad de hacerlo. 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 compresió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. La herramienta fundamental del diseño estructurado es el diagrama de flujo de datos, los diagramas estructurados son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los diagramas estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. Estas especificaciones funcionales para los módulos se porporcionan a los programadores antes que de comienzo la fase de escritura de código. EMPLEO DEL ANÁLISIS Y DISEÑO ESTRUCTURADO CON OTROS MÉTODOS Se combina, con bastante frecuencia, con el método de ciclo de vida clásico de desarrollo de sistemas. Por ejemplo los analistas pueden optar por desarrollar diagramas de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigación detallada de algún sistema existente. Asimismo, se pueden definir los archivos y datos en un diccinario centralizado de datos de acuerdo con las reglas del análisis estructurado. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de comportamiento específico. Los propios objetos se pueden construir a partir de otros, que a su vez pueden estar formados por otros objetos. El análisis de sistemas en el mundo orientado a objetos se realiza al estudiar los objetos en un ambiente, así como los eventos que interactúan con dichos objetos. El diseño del software se realiza al volver a utilizar clases de objetos ya existentes y, en caso necesario, al construir nuevas clases. Al modelar una empresa, los analistas deben identificar sus tipos de objetos y las operaciones que hagan que los objetos se comporten en determinada forma. Las técnicas orientadas a objetos se pueden utilizar como medios para el diseño sencillo de sistemas complejos. el sistema se puede ver como una colección de objetos, donde cada uno de ellos puede llegar a tener varias posibilidades. Las operaciones que modifican el estado son relativamente sencillas. Los objetos se construyen a partir de otros objetos. Los sistemas se construyen a partir de otros componentes probados con un formato definido para las solicitudes de las operaciones del componente.
El analista orientado a objetos ve el mundo como objetos (con estructuras de datos y métodos) y eventos que activan operaciones, las cuales modifican el estado de los objetos. Las operaciones aparecen como objetos que hacen solicitudes a otros objetos. El analista crea diagramas de la estructura de los objetos y de los eventos que los modifican. El modelo del diseñador es similar al modelo del analista, pero se toma con el detalle suficiente como para crear el código. El análisis y diseño orientado a objetos intenta lograr la reutilización masiva de las clases de objetos. Modela el mundo en términos de objetos que tienen propiedades y comportamientos, y eventos que activan operaciones que modifican el estado de los objetos. Los objetos interactúan de manera formal con otros objetos. PROGRAMACIÓN ORIENTADA A OBJETO La programación orientada a objetos no es un concepto nuevo, sus inicios y técnicas de programación se iniciaron a principios de los 70. Se puede definir programación orientada a objetos (OOPS) como una técnica de programación que utiliza objetos como bloque esencial de construcción. La OOPS, es un tipo de programación más cercana al razonamiento humano. La OOPS surge como una solución a la programación de grandes programas, y para solventar el mantenimiento de dichas aplicaciones, ya que en la programación estructura el más mínimo cambio supone la modificación de muchas funciones relacionadas, en cambio con la OOPS solo es cuestión de añadir o modificar métodos de una clase o mejor, crear una nueva clase a partir de otra (Herencia). OBJETO Los objetos son las cosas físicas y conceptuales que encontramos en el universo alrededor de nosotros. Hadware, software, documentos , seres humanos, los conceptos son todos los ejemplos de los objetos. CLASES Las Clases son como plantillas o modelos que describen como se construyen ciertos tipos de Objeto. Cada vez que se construye un Objeto de una Clase, se crea una instancia de esa Clase("instance"). Una Clase es una colección de Objetos similares y un Objeto es una instancia de una Clase. Se puede definir una Clase como un modelo que se utiliza para describir uno o más Objetos del mismo tipo. HERENCIA Una característica muy importante de los Objetos y las Clases es la Herencia, una propiedad que permite construir nuevos Objetos (Clases) a partir de unos ya existentes. Esto permite crear "Sub-Clases" denominadas Clases Derivadas que comparten las propiedades de la Clase de la cual derivan (Clase base). Las Clases derivadas heredan código y datos de la clase base, asimismo incorporan su propio código y datos especiales. Se puede decir que la herencia permite definir nuevas Clases a partir de las Clases ya existentes. POLIMORFISMO En un sentido literal, Polimorfismo significa la cualidad de tener más de una forma. En el contexto de POO, el Polimorfismo se refiere al hecho de que una simple operación puede tener diferente comportamiento en diferentes objetos. En otras palabras, diferentes objetos reaccionan al mismo mensaje de modo diferente. Los primeros lenguajes de POO fueron interpretados, de forma que el Polimorfismo se contemplaba en tiempo de ejecución. Por ejemplo, en C++, al ser un lenguaje compilado, el Polimorfismo se admite tanto en tiempo de ejecución como en tiempo de compilación. DIFERENCIAS. ANÁLISIS Y DISEÑO ESTRUCTURADO vs. ORIENTADO A OBJETO
- La metodología de análisis y diseño estructurado, examinan los sistemas desde el punto de vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas mas pequeñas y que forman los bloques o módulos de las aplicaciones. En la orientación a objeto, por su parte, cobra mucho más importancia el aspecto de "modelado" del sistema, examinando el dominio del problema como un conjunto de ojbetos que interactúan entre sí. - En la metodología de análisis y diseño estructurado se produce una división entre los dos elementos de un sistema: funciones que llevan a cabo los programas y datos que se almacenan en archivos o bases de datos. Y por otro lado, la orientación al objeto da un enfoque unificador de ambos aspectos, que se unen en los objetos. - En la metodología de análisis y diseño estructurado las herramientas que utilizan para el análisis son: Diagramas de Flujos de Datos, Diccionarios de Datos, Diagramas Entidad-Relación, Diagramas de Trancisión de Estado, Especificaciones de procesos. En las metodologías orientadas a objetos se emplean distintos modelos que depende de la metodología, entre los principales están Modelo de objetos, Modelo de Estado u Objeto-Estado, entre otros. Además, podemos agregar otras diferencias secundarias tales como: - Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto. - Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables. - Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica. CASO PRÁCTICO A continuación se describe el diseño de un sistema Web realizado por mi persona utilizando el Lenguaje de Modelado Unificado UML. Antes de comenzar con la descripción del caso práctico, veamos algunos conceptos: ¿QUÉ ES UML? "El Lenguaje de Modelado Unificado UML es un lenguaje estándar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra gran cantidad de software" El UML es el Lenguaje de Modelado Unificado Orientado a Objetos, UML no es un método porque no tiene noción de proceso el cual es una parte importante de un método. Ahora bien si UML no es método; entonces ¿Cuáles son las etapas a seguir en el desarrollo de sistemas con UML?, varios especialistas en desarrollo de sistemas de información arguyen de que existe la necesidad de adoptar un Proceso de Desarrollo de sistemas para enmarcar las fases importantes que sigue el UML, por ello los desarrolladores de proyectos de sistemas de información emplean el Procesos Unificado para dar soluciones adecuadas a las necesidades de los clientes. El desarrollo de sistemas con UML siguiendo el proceso unificado incluye actividades específicas, cada una de ellas a su vez contienen otras subactividades las cuales sirven como una guía de cómo deben ser las actividades desarrolladas y secuenciadas con el fin de obtener
sistemas exitosos; consecuentemente el desarrollo de los sistemas puede variar de desarrollador en desarrollador, de proyecto en proyecto, de empresa en empresa adoptando siempre un Proceso de Desarrollo.
DIAGRAMAS UML Los elementos de UML se muestran mediante diagramas que presentan múltiples vistas del sistema, ese conjunto de vistas son conocidos como modelos . UML presenta varios diagramas donde cada uno representa un aspecto del sistema. De ahí que varios investigadores según sus criterios y puntos de vista mencionan qué diagramas emplear en el desarrollo de los sistemas de información; sin mencionar cuáles son los diagramas más adecuados en las distintas etapas de desarrollo del Proceso Unificado, viendo esta necesidad, la autora del presente artículo propone un conjunto de diagramas necesarios para cada etapa según la complejidad del sistema de información a solucionar. Dado un sistema a desarrollar no es necesario emplear todos los diagramas; para sistemas sencillos un diagrama de clases junto con un par de diagramas de actividades e interacción sería suficiente, asimismo si los sistemas son complejos requieren de la utilización de más diagramas, debido a que requieren de etapas incrementales e iterativas(ciclos de desarrollo) en el análisis, diseño e implementación, por ello es que el conjunto actividades deberá especificar la etapa de desarrollo y los diagramas recomendados Luego de haber dado un breve marco teórico se procederá a la descripción del caso práctico. DESCRIPCIÓN DEL CASO PRÁCTICO IDENTIFICAR LOS CASOS DE USO En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solución que está buscando. Para lograr éste objetivo se plantean los siguientes puntos: 1. Actores o Usuarios - Representan usuarios y otros sistemas que interaccionan con el sistema. - Representan el tipo de usuario, no una instancia de usuario. - No son parte del sistema que se desarrolla. - Suministran y reciben información al sistema.
2. ¿Por qué se diseña el sistema? El sistema actual presenta varias limitantes entre las cuales destacan: - Es un sistema cuyo nivel de automatización del proceso es muy bajo. - Asignación manual de las acciones a tomar por parte del personal.
- Insuficiente información para el análisis. - No es óptimo el tiempo de respuesta para dar solución a los problemas. Los usuarios de la versión actual del sistema evaluaron la funcionalidad y eficiencia del mismo se llegó a la conclusión de que no satisface los requerimientos del momento para las organizaciones implicadas. 3. Roles y Funciones de los Usuarios - Usuarios 01: personas encargadas de interactuar directamente con el sistema. - Usuarios 02: operan otra aplicación, la cual tiene una interfaz que permite ejecutar el sistema en estudio. - Analista(s) Custodio(s): encargados de la supervisión y mantenimiento del sistema. 4. Otros Sistemas e Interfaces Existen dos aplicaciones con las cuáles interactúa la aplicación Una vez realizado éste análisis se procederá a modelar el diagrama de "Casos de Uso" de la aplicación. Luego de obtener el diagrama de "Casos de Uso", se obtendrán las clases, una vez obtenido el "Diagrama de Clases" se generará el "Modelo Lógico de Datos" y por último el "Modelo Físico de Datos". Todos estos diagramas serán realizados con la herramienta "Power Designer" v. 10 En resumen los pasos a realizar utilizando el Lenguaje de Modelado Unificado para éste caso práctico son los siguientes: - Identicar los Casos de Uso. - Identificar las Clases, tomando como base el diagrama de "Casos de Uso". - Generar el Modelo Lógico de Datos - Por último generar el Modelo Físico de Datos Una vez realizados los pasos anteriormente mencionados iniciar el diseño del prototipo de la aplicación.
