|
UNIVERSIDAD DE YACAMBU |
|
VICERRECTORADO DE ESTUDIOS VIRTUALES |
|
MATERIA: ANÁLISIS Y DISEÑO DE SISTEMAS |
|
TRABAJO 1 TEMA: Diferencia entre Análisis y Diseño Estructurado y Orientado a Objetos |
|
1. Definición: Análisis y Diseño Estructurado 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 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. Para poder utilizar eficientemente las notaciones básicas en el análisis de requisitos del Software, se ha de combinar esa notación con un conjunto de heurística que permitan al Ingeniero del Software derivar un buen modelo de análisis. El análisis estructurado nos permite: Intentar estructurar el proceso de determinación de los requerimientos. Incluir todos los detalles relevantes que describen al sistema en uso. Una fácil verificación cuando se han omitido detalles relevantes. La identificación de los requerimientos. Generar una documentación más eficiente. A continuación se examina cada uno de los pasos que se deben seguir para desarrollar modelos completos y precisos mediante el análisis estructurado. Creación de un modelo de Flujo de Datos A medida que se refina el DFD en mayores niveles de detalle, el analista lleva a cabo implícitamente una descomposición funcional del sistema. Al mismo tiempo, el refinamiento del DFD produce un refinamiento de los datos a medida que se mueven a través de los procesos que componen la aplicación. Unas pocas directrices sencillas pueden ayudar de forma considerable durante la derivación de un diagrama de flujo de datos: El diagrama de flujo de datos de nivel 0 debe reflejar el software / sistema como una sola burbuja. Se deben anotar cuidadosamente la entrada y la salida principales. El refinamiento debe comenzar aislando los procesos, los elementos de datos y los almacenes de datos que sean candidatos a ser representados en el siguiente nivel. Todas las flechas y las burbujas deben ser etiquetadas con nombres significativos. Entre sucesivos niveles se debe mantener la continuidad del flujo de información. Se deben refinar las burbujas de una en una. Creación de un modelo de flujo de control Para muchos tipos de aplicaciones de procesamiento de datos, todo lo que se necesita para obtener una representación significativa de los requisitos del Software es el modelo de flujo de datos. Sin embargo existe una clase de numerosas aplicaciones que están “conducidas” por sucesos en lugar de por los datos, que producen información de control mas que informes, que procesan información con fuertes limitaciones de tiempo y rendimiento. Tales aplicaciones requieren una modelización del flujo de control además de la modelización del flujo de la información. La especificación de control Esta representa el comportamiento del sistema de dos formas diferentes. La especificación de control contiene un diagrama de transición de estados (DTE) que es una especificación secuencial del comportamiento. También puede contener una tabla de activación de procesos (una especificación combinatoria del comportamiento). La especificación de procesamiento Se usa para describir todos los procesos del modelo de flujo que aparece en el nivel final del refinamiento. El contenido de la especificación de procesamiento puede incluir una narrativa textual, una descripción en lenguaje de descripción de programa del algoritmo del proceso, tablas, diagramas o gráficos. El diccionario de requisitos El diccionario de requisitos también denominado diccionario de datos, es una gramática casi formal para describir el contenido de los objetos definidos durante el análisis estructurado. El diccionario de datos es una listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma comprensión de las entradas, las salidas, de las componentes de los almacenes y de los cálculos intermedios. Un diccionario de datos contiene la siguiente información: Nombre Alias Dónde se usa / como se usa Descripción del contenido Información adicional El análisis estructurado es el método más utilizado en la modelización de requisitos, se basa en el modelo de flujo como primer elemento de representación gráfica de un sistema basado en computadoras. 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 Diseño Estructurado. El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseño Estructurado es 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. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es 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. 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. Notaciones: son cuatro símbolos, que fueron desarrollados y promovidos la mismo tiempo por dos organizaciones: Yourdon y Gane y Sarson. Flujo de datos: son movimientos de datos en una determinada dirección, desde un origen hasta un destino. Es un paquete de datos. Yourdon Gane y Sarson Proceso: son personas, procedimientos o dispositivos que utilizan o producen datos. No identifica el componente físico Fuente o destino de los datos: pueden ser personas, programas, organizaciones u otras entidades que interactúan con el sistema pero que se encuentre fuera. Almacenamiento de datos: es un lugar donde se guardan los datos. El almacenamiento de datos puede representar dispositivos tanto computarizados como no computarizados. Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre descriptivo. Los nombres de los procesos reciben un numero para poder identificarlos, este numero tiene un valor adicional cuando se estudian los componentes que integran un proceso especifico Análisis y Diseño Orientado a Objetos A inicio de los años 80 el tema orientado a los objetos comienza a surgir en la ingeniería del software con un enfoque de desarrollo de software. Se empezó a diseñar e implementar aplicaciones usando la forma de pensar orientada a objetos. Actualmente el análisis orientado a los objetos va progresando poco a poco como método de análisis de requisitos y como complemento de otros métodos de análisis. En lugar de examinar un problema mediante el método clásico entrada – salida o mediante un modelo derivado, el AOO introduce conceptos nuevos. Conceptos orientados a los objetos Clase: Es una descripción para producir objetos de esa clase o tipo. Una clase esta formada por los métodos y los atributos, que definen las características comunes a todos los objetos de esa clase. Una clase se puede considerar como una plantilla para crear objetos de esa clase o tipo. Objetos: Es una encapsulación genérica de datos y de los procedimientos para manipularlos. Dicho de otra forma un objeto es una entidad que tiene unos atributos particulares (los datos) y una forma de operar sobre ellos (los métodos y los procedimientos). Mensajes: Cuando se utiliza el AOO, los objetos están recibiendo, interpretando y respondiendo a mensajes de otros objetos. El conjunto de mensajes a los que un objeto puede responder se le llama protocolo. Métodos: Un método determina cómo tiene que actuar el objeto cuando recibe un mensaje. Un método también puede enviar mensajes a otros objetos solicitando una acción o información. La descripción de un método se denomina operación. Herencia: Es el mecanismo para compartir automáticamente métodos y datos entre clases y subclases. Encapsulamiento: Se refiere a la práctica de incluir dentro de un objeto todo lo que necesita, de tal forma que ningún otro objeto necesite conocer nunca su estructura interna. Polimorfismo: Es una característica que permite implementar múltiples formas de un mismo método, dependiendo de cada una de ellas de la case sobre la que se realice la implementación. Identificación de objetos. Cuando observamos el espacio del problema de una aplicación de software resulta complicado encontrar, a simple vista, los objetos. Podemos empezar a identificar objetos examinando la descripción del problema. Si un objeto es necesario para implementar una solución, entonces es parte del espacio de la solución; en caso contrario cuando el objeto solo es necesario para describir la solución, entonces es parte del espacio del problema. Los tipos de objetos pueden ser: Entidades externas: Son los que producen o consumen información a ser utilizadas en el sistema, por ejemplo otros sistemas, dispositivos, gente, etc. Cosas: Son parte del dominio de información del problema, por ejemplo, informes, visualizaciones, cartas, etc. Ocurrencias o sucesos: Es lo que ocurre en le contexto de operación del sistema, por ejemplo, cerrar una ventana en Windows, movimiento de un robot, etc. Papeles: Documento que juegan las personas que interactúan con el sistema, por ejemplo, Ingenieros, Vendedores, etc. Unidades organizativas: Las áreas que son relevantes para la aplicación, por ejemplo, división, grupo, equipo, departamento, etc. Lugares: Es el lugar que establece el contexto del problema y del funcionamiento general del sistema, por ejemplo, sala de facturación, muelle de descarga, etc. Estructuras: Aquellas que definen clases de objetos o en casos extremos clases de objetos relacionados, por ejemplo, sensores, computadoras, etc. Especificación de atributos Los atributos describen un objeto que haya sido seleccionado para ser incluido en el modelo de análisis. Esencialmente son estos los que definen un objeto; son los que aclaran el significado del objeto en el contexto del espacio del problema. Para desarrollar un conjunto significativo de atributos para un objeto, el analista debe estudiar de nuevo la narrativa de procesamiento (o descripción del alcance) para el problema concreto y seleccionar aquello que pertenezca de forma razonable al objeto. Además se debe responder a la siguiente pregunta para cada objeto ¿Qué elementos de datos (elementales y/o compuesto) definen completamente ese objeto en el contexto del problema actual? Operaciones básicas con objetos Una operación cambia un objeto de alguna forma, correctamente cambia valores de uno o más atributos que están contenidos en el objeto. Por tanto una operación debe tener “conocimiento” de la naturaleza de los atributos del objeto y deben ser implementados de forma que se les permita manipular la estructura de datos que hayan sido derivados de los atributos. Las operaciones generalmente se pueden dividir entre grandes categorías: Operaciones que manipulan los datos de alguna forma, por ejemplo adiciones, eliminaciones, cambio de formatos, selecciones, etc. Operaciones que realizan algún calculo. Operaciones que monitorizan un objeto frente ocurrencia de algún suceso de control. Comunicación entre objetos La definición de los objetos del contexto del modelo de análisis puede ser suficiente para establecer una base para el diseño, pero se debe añadir algo más (durante el análisis o durante el diseño) para que se pueda construir el sistema se debe establecer un mecanismo para la comunicación entre los objetos; a este mecanismo se denomina mensaje. La mensajería es importante para la implementación de un sistema orientado a los objetos; pero no es necesario considerarla detalladamente durante el análisis de requisitos. De hecho, en esta etapa nuestro único objetivo es usar el concepto como ayuda para la determinación de operaciones candidatas para un objeto concreto. Fin de la definición del objeto La definición de las operaciones es el último paso para tener la especificación de un objeto completo. Se puede determinar operaciones adicionales considerando el historial de un objeto y los mensajes que se pasan entre objetos definidos en le sistema. El historial genérico de un objeto puede ser definido reconociendo que se debe crear, modificar, manipular o leer en otras formas y posiblemente eliminar una vez que se han definido los atributos y las operaciones para cada uno de los objetos hasta este nivel, se puede crear un modelo de AOO inicial. Modelo de análisis orientado a los objetos Se han sugerido varios esquemas de modelización para el AOO. Todos hacen uso de la definición de objeto, pero cada uno introduce sus propias notaciones, heurísticas y filosofía. El enfoque de AOO propuesto por Coad y Yourdon consiste en cinco pasos: identificación de los objetos identificación de las estructuras definición de temas definición de conexiones entre atributos e instancias definición de conexiones entre operaciones y mensajes Estructuras de clasificación y ensamblaje Una vez que se han identificado los objetos, el analista pasa a centrarse en la estructura de clasificación donde se considera cada objeto como una generalización y luego como una especialización, es decir, se definen y se nombran las instancias de un objeto. En otros casos, puede que un objeto representado en el modelo inicial este realmente compuesto por varias partes constitutivas que pueden ser definidas en si misma como objetos, a este tipo de estructura se denomina estructura de ensamblaje. Definición de temas Un tema no es más que una referencia o puntero a mayores detalles del modelo de análisis. Al nivel más abstracto, el modelo de AOO contendrá sólo referencias temáticas. Conexiones de instancias y caminos de mensajes Una conexión de instancia es una notación de monetización que define una relación especifica entre las instancias de un objeto Pasos para la creación de conexiones de instancias: La creación de líneas sencillas entre los objetos indicando que existe alguna relación importante. Una vez establecidas las líneas se evalúa cada extremo para determinar si lo que existe es una conexión simple (1:1) o una conexión múltiple (1:muchos). Para una conexión 1:1 la línea lleva una barra y para una conexión 1:muchos aparece con el símbolo de triple bifurcación. Finalmente se añade otra barra vertical si la conexión es obligada y un circulo si la conexión es opcional Al representar las conexiones de instancias el analista añade otra dimensión al modelo AOO. No sólo se han identificado las relaciones entre objetos sino que se han definido los caminos de mensajes importantes; en la figura que hace referencia a la definición de tema, las flechas punteadas que conectaban los símbolos temáticos se trataban de caminos de mensajes, cada flecha implica un intercambio de mensajes entre objetos del modelo. Los mensajes se moverán a través de los caminos de conexión de instancias, por tanto las conexiones de mensajes se derivan directamente de las conexiones de instancias. AOO y Prototipos El uso de AOO puede llevar a una creación de prototipos muy efectivos como a “técnicas de ingeniería del software evolutiva”. Cuando se aplica AOO a nuevos proyectos, el analista puede trabajar en su especificación de sistema utilizando objetos existentes (implementados) que están contenidos en la biblioteca de objetos en lugar de inventar objetos nuevos. Usando objetos existentes durante el análisis, el tiempo de especificación se reduce substancialmente, pudiéndose crear rápidamente un prototipo de sistema especificado que pueda ser revisado por el cliente. |