Diseño I.- INTRODUCCION II.- EL DISEÑO EN GENERAL

Diseño I.- INTRODUCCION II.- EL DISEÑO EN GENERAL
1.- ANTECEDENTES 2.- ESTIMACIONES BRAINSTORMING III.- DISEÑO ESTRUCTURADO 1.- INTRODUCCION 2.- DIAGRAMAS DE ESTRUCTURA 3.- CONVERSIÓN DE DFD EN DIAGRAMA DE ESTRUCTURA 4.- MODULARIZACIÓN 5.- CRITERIOS DE DESCOMPOSICION MODULAR 5.1.- Clausura 5.2.- Independencia Acoplamiento Cohesión 6.- DISEÑO DE LA INTERFAZ ENTRE DOS MODULOS IV.- METRICAS DE DISEÑO V.- DISEÑO ORIENTADO A OBJETOS

INTRODUCCIÓN PRINCIPIOS DE DISEÑO
1. Los Datos y los algoritmos que los manipulan deben crearse como un conjunto de abstracciones interrelacionadas. 2. Los detalles internos del diseño de las estructuras de datos y los algoritmos deben ocultarse de otros componentes software que hacen uso de dichas estructuras de datos o algoritmos. 3. Los módulos deben exhibir independencia. 4. Los algoritmos deben diseñarse utilizando un conjunto restringido de constructores lógicos. 1. Creando abstracciones de datos y procedimientos, los modelos de los componentes software poseen características que tienden a una alta calidad. Una abstracción es autocontenida, generalmente implementa una estructura de datos o algoritmo bien acotado, puede ser accesado a través de una interfase simple, los detalles de su operación interna no necesitan ser conocida para ser utilizada en forma efectiva, y es inherentemente reusable. 2. El ocultamiento de la información sugiere que los módulos sean caracterizados por decisiones de diseño que cada uno oculta de todos los demás. El ocultamiento implica que se puede alcanzar la modularidad efectiva definiendo un conjunto de módulos independientes que se comunican unos con otros pasando sólo aquella información que es necesaria para el funcionamiento del software. 3. Los módulos deben estar muy poco acoplados con otros módulos y el ambiente externo, además deben poseer cohesión funcional. El software con modularidad efectiva es más fácil de desarrollar debido a que las funciones pueden ser divididas y las interfases simplificadas (considere las ramificaciones cuando el desarrollo es conducido por un equipo). Los módulos independientes son más fáciles de mantener y testear, debido a que los efectos secundarios causados por las modificaciones del diseño y la codificación son limitados; la propagación de errores se reduce y se hace posible la creación de los módulos reusables. 4. Este es un enfoque de diseño ampliamente conocido como programación estructurada, que fue propuesto para limitar el diseño procedural de software a un número pequeño de operaciones predecibles. El uso de los constructores de la programación estructurada (secuencia, bifurcación e iteración), reduce la complejidad del programa y aumenta la legibilidad, testeabilidad, y su mantenibilidad. El uso de un numero limitado de constructores lógicos también ayuda a la comprensión humana.

INTRODUCCIÓN Actividades del Diseño de Software

II EL DISEÑO EN GENERAL El diseño de los datos traduce el modelo de datos creado durante el análisis a estructuras de datos que satisfacen las necesidades del problema El diseño de la arquitectura va a depender del punto de vista o enfoque del diseñador: por ejemplo, en un diseño convencional se creará una arquitectura jerárquica, mientras que en un enfoque orientado al objeto, se creará una red de mensajes que permite la comunicación entre los objetos. El diseño de la interfaz crea un modelo de implementación para la interfaz humano-computador, las interfaces externas del sistema que le permiten interactuar con otras aplicaciones, y las interfaces internas que permiten a los datos ser comunicados a través de los componentes del software. El diseño procedural define algoritmos para implementar los requerimientos de procesamiento de los componentes del software.

II EL DISEÑO EN GENERAL 1.- ANTECEDENTES
El diseño es un proceso iterativo cuyo resultado es la especificación de un sistema físico que cumpla con los requerimientos Existen diversas técnicas básicas: DISEÑO ESTRUCTURADO DISEÑO INCREMENTAL O EVOLUTIVO DISEÑO ORIENTADO A OBJETOS y técnicas complementarias CONTROL DE CALIDAD DEL DISEÑO ESTIMACION DE COSTOS DE DISEÑO

III EL DISEÑO ESTRUCTURADO
1.- INTRODUCCIÓN La técnica consiste básicamente en la conversión sistemática de los DFD en Diagramas de estructura 2.- OBJETIVOS Reducir la complejidad de un sistema a través de la técnica de Modularización de sus funciones Abaratar los costos de construcción a través de la Reutilización de Módulos Disminuir los costos de construcción a través de: diseños simples de comprender Flexibles a cambios eficientes en su operación fáciles de construir

La técnica utiliza criterios de evaluación de la calidad del diseño respecto del problema que se desea resolver. La técnica se apoya en notaciones gráficas - los diagramas de estructura - y en pseudocódigo.

3.- DIAGRAMAS DE ESTRUCTURA B A MODULO A MODULO PREDEFINIDO B El modulo B hace referencia a Datos en el A A X,Y Z El modulo A llama al modulo B y pasa los parámetros X;Y de A a B. El modulo B remite el parámetro Z al modulo B B A El modulo A llama a los módulos B y C. Los módulos se colocan de izquierda a derecha en orden de invocación. B B

4.- MODULARIZACIÓN El MODULO es el componente básico de un sistema estructurado Se puede concebir como un subprograma con una interfaz a través de la cual se comunica con otros subprogramas Ejemplos Un programa compilado separadamente Una rutina fortran Un subprograma en C o C++ Un subprograma o unidad en PASCAL

4.1.- TECNICA DE DISEÑO ESTRUCTURADO Se particiona el sistema en una jerarquía de módulos o subsistemas que pueden concebirse y construirse en forma independiente (pueden verse como cajas negras La idea es que otros módulos sólo necesiten saber QUE hace un determinado módulo - su función- y no COMO lo hace. Ventajas Simplifica la construcción, ya que las decisiones internas son propias al módulo y no dependen de otros módulos simplifica las pruebas como unidad independiente, ya que se han reducido los efectos laterales y es más fácil identificar la fuente de error. Simplifica la mantención, especialmente si hay suficiente independencia de otros módulos.

5.- CRITERIOS DE DESCOMPOSICIÓN MODULAR Las propiedades que deben preservarse al descomponer un sistema en módulos son: un módulo es una unidad auto contenida puede probarse en forma separada puede conectarse con otros módulos sólo a través de su interfaz 5.1.- Clausura Cada módulo debiera realizar una tarea que constituya una unidad lógica, debiera ser lo más conciso posible, englobando un solo concepto.

5.2.- Independencia Se busca maximizar la independencia inter módulos en base a un bajo acoplamiento y una Alta cohesión El ACOPLAMIENTO es una medida de qué tan estrecha es la conexión o interrelación entre 2 módulos. La COHESIÓN es una medida de la interrelación entre las funciones que contienen un módulo

Acoplamiento una conexión es una referencia a un objeto o proceso definido en otro módulo: al minimizar las conexiones entre módulos, también se minimizan las trayectorias a lo largo de las cuales se propagan los errores y os cambios. La propagación de un error o de un cambio, a través de una conexión, provoca efectos de amplificación, propiciando la aparición de nuevos errores. Con conexiones simples es más fácil entender módulos sin hacer referencia a otros

Un alto grado de acoplamiento complica la mantención de un módulo ya que debe ser corregido y probado con referencia a los módulos conectados Ejemplo: si saca el módulo X del sistema para hacerle mantención ¿qué otras partes del sistema podrán seguir funcionando? Factores que afectan el grado de acoplamiento El grado de acoplamiento de mide en tres dimensiones 1.- tamaño de la conexión 2.- Tipo de conexión 3.- qué es lo une se envía y recibe

1.- tamaño de la conexión Entre menos datos se pasen entre módulos, menor será el grado de acoplamiento La medida es la cantidad de datos pasados cada vez que se usa la interfaz Se recomienda NO pasar los datos armados dentro de una estructura, sino que pasarlos individualmente como parámetros, para así aumentar la claridad. Típicamente, una interfaz debiera tener parámetros

2.- Tipo de conexión Si un módulo hace referencia a una variable que está definida en otro módulo, entonces el contenido de ese otro módulo deberá tomarse en cuenta al hacer un cambio o corregir un error. Un sistema es más simple si sus módulos pueden usarse sin necesidad de conocer su interior. 3.- Qué es lo que se comunica Los módulos por lo menos deberán pasarse datos entre sí para que formen parte de un mismo sistema Cuando se pasa información de control de un módulo a otro (switch, flags, etc.) se agrega complejidad al sistema (Siempre existirá una estructura alterna que elimine esa complejidad)

Caracterización de las comunicaciones. En orden creciente de fuente de problemas Acoplamiento por datos Es inevitable pero controlable si se da a través de un número mínimo de parámetros en que se pasan tipos de datos básicos y no estructuras complejas o registros Ejemplo CALCULO DE LA FACTURA Monto Valor Plazo CALCULO DEL CREDITO

Acoplamiento por registros Se da cuando dos o más comparten registros de datos entre si. Puede darse conexiones entre módulos que de otra forma no tendrían relación entre sí. Ej. A través de los campos de un registro compartido La mantención del registro debe hacerse en consideración a todos los módulos que lo comparten. Además, este acoplamiento puede exponer más datos que los necesarios a un módulo, con posibles consecuencias negativas.

Acoplamiento por control Se da cuando un módulo intenta alterar el control de la lógica de otro módulo es un tipo de acoplamiento potencialmente problemático Suele darse a través de switches o flags de control En estos casos, el módulo llamado no es visto como una caja negra sino que parte de su funcionamiento interno se hace visible y modificable COBOL : Perform A through B Varying ...until (ALTER: excomulgado y proscrito)

Acoplamiento por áreas de datos comunes Se da cuando dos módulos hacen referencia a una misma zona de datos Problemas los datos no se aislan en torno a la función que los utiliza sino que son susceptibles de ser alterados por todas las partes que los visualizan Las áreas de datos comunes son susceptibles de ser mal utilizadas durante la programación. Ejemplo: definir variables globales de propósito múltiple como switch-1 o Flag-1 para almacenar datos intermedios de funciones totalmente ajenas entre sí. Los programas con grandes áreas de datos comunes son más difíciles de mantener, ya que es necesario distinguir que dato se utiliza porqué módulo

cohesión Medida de la interrelación entre las funciones que contiene un módulo, o bien la medida de la fuerza de la asociación funcional entre los elementos de un módulo (instrucción, grupo de instrucciones o llamadas a otros módulos) Se desea que los módulos tengan ALTA cohesión. La cohesión es complementaria al acoplamiento y también determina la manera en que se particionan los módulos y su nivel de interdependencia

Escala de cohesión, de peor a mejor o de menor a mayor Cohesión Coincidental Los elementos del módulo contribuyen a actividades que no están relacionadas entre sí. Se da cuando se pregunta por qué un grupo de instrucciones están en un programa y la respuesta es: “por que tenían que estar en algún lugar” Ejemplo Modulo DeTodoUnPoco Listar errores Llenar formularios Listar cambios Ordenar resultados Cambiar Fecha Para realizar alguna de estas funciones, típicamente se utiliza algún flag o switch, es decir, se provoca acoplamiento por control

Cohesión Temporal Estos módulos se caracterizan porque sus elementos se relacionan con actividades relacionadas en el tiempo Normalmente, todos sus elementos se ejecutan en cada llamada al módulo. Ejemplo Modulo TodoDeUnViaje Abrir Archivo Maestro Poner contador-maestro en cero Abrir archivo Cambios Poner Contador-maestro en cero Abrir archivo Errores

También se utilizan flags de control para ocupar alguna de estas funciones, especialmente si alguna o varias de ellas se deben reutilizar en otro momento del proceso Los siguientes tipos de cohesión son considerablemente mas fuertes que las anteriores.

Cohesión Procedural Los elementos participan de actividades diferentes y posiblemente no relacionadas, en las cuales el control fluye de una actividad a la siguiente. Lo que relaciona los componentes es el orden de ejecución y no el hecho de ser elementos funcionalmente relacionados Ejemplo Modulo UnoTrasOtro Mientras existan datos Leer orden procesar orden

Cohesión Por Comunicación Los elementos del módulo se refieren a los mismos datos de entrada y salida. Ejemplo Producción de gráficos o de informes a partir de los mismos datos de entrada y salida Cohesión secuencial Ocurre cuando la salida de un elemento es usada como entrada para el siguiente elemento Ejemplo leer y editar datos, crear y almacenar registros, resumir e imprimir resultados Modulo Secuencia leer datos cliente; validar datos del cliente; Imprimir errores

Cohesión Funcional Una función describe la transformación de datos de entrada en datos de salida Si todos los elementos de un módulo contribuyen a un mismo objetivo posiblemente el módulo está ligado funcionalmente Todos los elementos del módulo son esenciales para realizar la función del módulo Una técnica útil para saber si un módulo tiene cohesión funcional es describir su función y examinar la oración resultante Si la oración resultante contiene más de un verbo probablemente el módulo desempeñe más de una función

Si tiene palabras que tengan que ver con tiempo (primero, siguiente, cuando, inicio, etc) probablemente el módulo tenga cohesión secuencial o temporal Si el predicado no contiene un solo objeto específico, probablemente hay cohesión lógica. Palabras como inicializar, limpiar, etc. Implican cohesión temporal Los módulos con cohesión funcional siempre pueden describirse en términos de sus elementos utilizando una oración

6.- DISEÑO DE LA INTERFAZ ENTRE MÓDULOS 1.- Minimalidad en la Interfaz La interfaz entre 2 módulos es el conjunto de supuestos que cada uno puede hacer del otro Ej.: supuestos acerca de los datos que se usan Las interfaces debieran ser lo más simples posibles, con un mínimo de parámetros

2.- Independencia de la interfaz Un módulo debiera poder reemplazarse por otro ofrezca la misma definición de la interfaz, sin producir efectos nuevos en el resto del sistema. 3.- Número de Parámetros El número de otros módulos que debe importar un cierto módulo debe ser considerado. Un número grande de parámetros puede indicar que el módulo debe realizar muchas actividades de coordinación y decisión Si los parámetros son pocos, es posible que se requiera una mayor descomposición del problema

IV METRICAS DE DISEÑO 1.- INTRODUCCIÓN Durante el diseño se registra.
Módulos : cantidad Defectos : Número y tipo durante inspecciones; costo de repararlos Fuerza de trabajo : número y tipo de personas requeridas en cada módulo; tiempo requerido PRIMERA APROXIMACIÓN, en general, cada módulo tiene entre 2 y 7 módulos subordinados Si un módulo tiene 1 solo subordinado es posible que se haya extraído una función (importante o larga) del módulo => baja cohesión Si un módulo tiene muchos subordinados, es posible que, en esa etapa, el diseño haya sido efectuado hasta un nivel muy bajo

IV METRICAS DE DISEÑO 2.- ENFOQUE CUANTITATIVO
Utilización de herramientas para analizar diseños: Premisa: en un buen diseño las unidades individuales están aisladas unas de otras Por lo tanto: Se considera la modularidad y el acoplamiento como bases de un sistema de métricas de complejidad de diseño

V.- DISEÑO ORIENTADO A OBJETOS
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.

Tipo de Objeto 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, José Martínez, 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.

Métodos 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.

Encapsulado El encapsulado oculta los detalles de su implantación interna a los usuarios de un objeto. Los usuarios se dan cuenta de las operaciones que puede solicitar del objeto, pero desconocen los detalles de cómo se lleva a cabo la operación. Todos los detalles específicos de los datos del objeto y la codificación de sus operaciones están fuera del alcance del usuario. Así, encapsulado es el resultado (o acto) de ocultar los detalles de implantación de un objeto respecto de su usuario. El encapsulado, al separar el comportamiento del objeto de su implantación, permite la modificación de ésta sin que se tengan que modificar las aplicaciones que lo utilizan.

Mensajes Para que un objeto haga algo, le enviamos una solicitud. Esta hace que se produzca una operación. La operación ejecuta el método apropiado y, de manera opcional, produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del objeto, el nombre de una operación y, a veces, un grupo de parámetros. Los objetos pueden ser muy complejos, puesto que pueden contener muchos subobjetos, éstos a su vez pueden contener otros, etc. La persona que utilice el objeto no tiene que conocer su complejidad interna, sino la forma de comunicarse con él y la forma en que responde.

Clase El término clase se refiere a la implantación en software de un tipo de objeto. El tipo de objeto es una noción de concepto. Especifica una familia de objetos sin estipular la forma en que se implanten. Los tipos de objetos se especifican durante el análisis OO. Así, una clase es una implantación de un tipo de objeto. Especifica una estructura de datos y los métodos operativos permisibles que se aplican a cada uno de sus objetos. Mensajes 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.

Herencia Un tipo de objeto de alto nivel puede especializarse en tipos de objeto de bajo nivel. Un tipo de objeto puede tener subtipos. Por ejemplo, el tipo de objeto persona puede tener subtipos estudiante y empleado. A su vez, el tipo de objeto estudiante puede tener como subtipo estudiante de pregrado y estudiante de postgrado, mientras que empleado puede tener como subtipo a académico y administrativo. Existe de este modo una jerarquía de tipos, subtipos, subsubtipos, etc. Una clase implanta el tipo de objeto. Una subclase hereda propiedades de su clase padre; una sub-subclase hereda propiedades de las subclases; etc. Una subclase puede heredar la estructura de datos y los métodos, o algunos de los métodos, de su superclase. También tiene sus métodos e incluso tipos de datos propios.

Diseño I.- INTRODUCCION II.- EL DISEÑO EN GENERAL

Presentaciones similares

Presentación del tema: "Diseño I.- INTRODUCCION II.- EL DISEÑO EN GENERAL"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Diseño I.- INTRODUCCION II.- EL DISEÑO EN GENERAL

Presentaciones similares

Presentación del tema: "Diseño I.- INTRODUCCION II.- EL DISEÑO EN GENERAL"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback