IMPORTANCIA DEL DISEÑO

En el diseño se busca la eficiencia, no solo la eficacia, es decir, desarrollar software que funcionen bien y además el diseño nos sirve para mantener la calidad. Aspectos funcionales: los aspectos funcionales se centran en la eficacia, que el código funcione. Aspectos no funcionales: son aspectos de calidad, se centran en la eficiencia, preocupándose de que el software funcione bien. Dependiendo del contexto en el que estemos, habrá que primar un aspecto u otro: Rendimiento: rapidez, eficiencia. Seguridad: que sea seguro, difícil de atacar/hackear. Disponibilidad: que no se bloquee al ser accedido por muchos usuarios. Mantenibilidad: que sea fácilmente ampliable. Las empresas están cambiando continuamente sus procesos de negocio, por eso el software tiene que ser fácil de mantener Facilidad: que al usuario no le cueste mucho trabajo usarlo. Entre otros. La importancia de estos puntos dependerá del tipo de software a desarrollar, o de los requisitos del problema. Por ejemplo, si el software se aplicará en una central nuclear, es lógico que antepongan los puntos de seguridad y rendimiento al de Mantenibilidad. El diseño es la etapa en la que se tienen en cuenta esas necesidades del sistema que se está implementando y se van añadiendo una a una.

OBJETIVOS
El objetivo más importante es: Entregar las funciones requeridas por el usuario (Satisfaga una especificación funcional dada). Pero además para lograr esto deben considerarse los aspectos de: Rendimiento: cuán rápido permitirá el diseño realizar el trabajo dado un recurso particular de hardware. Es decir que contemple las limitaciones del medio donde será implementado el sistema, y alcance los requerimientos de performance y uso de recursos. Control: protección contra errores humanos, máquinas defectuosas, o daños intencionales. Cambiabilidad: facilidad con la cual el diseño permite modificar el sistema. Generalmente estos tres factores trabajan unos contra otros : un sistema con muchos controles tenderá a degradar su rendimiento, un sistema diseñado para un alto rendimiento solo podrá ser cambiado con dificultad, etc... Además deberá satisfacer criterios de diseño sobre la forma interna y externa del producto obtenido.

java para diseño). MODELO O METODOS PARA LA ACTIVIDAD DE DISEÑO En el modelo de diseño vamos a destacar 5 mapas o planos. nos centramos en un subsistema y vemos cómo están implementadas las clases. Cuando se está en una fase. Diseño de la arquitectura: se hace una pequeña descomposición del sistema. servidor de aplicaciones. La mayoría de las veces esto se traduce como la base de datos a usar.. se especifica sistema operativo necesario.información de clientes. MODELO DE ANÁLISIS VS. etc. pedidos. sino que son parte de la solución al problema (P. Empleado para análisis y la clase empleado. plataforma. son dos cosas muy diferentes: en el modelo de análisis las clases representan a los elementos de la realidad que forman parte del problema. Diseño del despliegue: se refiere a la parte de la instalación. ficheros de configuración. etc. ANALISIS VS. tales como su tiempo o costo. relaciones. es decir. ej. Se ve sobre qué maquinas va a funcionar el sistema.Satisfacer restricciones sobre el proceso de diseño en sí mismo. las fases del proceso de diseño se suelen ejecutar de forma lineal. etc. MODELO DE DISEÑO Aunque en ambos modelos se usan las mismas herramientas (UML)..) en clases.jpg ANALISIS VS. suelen aparecer nuevos problemas que nos hacen volver atrás en el modelo (P. ej. El diseño es un proceso interactivo.el Sr.nos damos cuenta en la fase de diseño de la microarquitectura que el módulo en el que hemos dividido es muy grande. etc. pero cíclicamente.). etc. DISEÑO. mientras que en el modelo de diseño. que se suelen seguir por orden: Diseño de datos: Aquí se guardaŕan los datos de la aplicación (P. o las herramientas disponibles para hacer el diseño. los atributos. Diseño de interfaz: existen tres tipos de interfaces que se pueden diseñar: Interfaz de usuario Interfaz de conexión con sistemas externos Interfaz entre los bloques Diseño de la microarquitectura: consiste en coger un bloque y mirar por dentro.. DISEÑO . ya se empieza a hablar de elementos software que no se identifican con la realidad. atributos. con lo que hay que volver a dividir y crear nuevas interfaces. dividiéndolo en bloques y estableciendo sus relaciones. etc. Respecto al modelo de análisis podemos decir que en el diseño de datos hablamos de tipos de datos concretos. ej.

jpg COSTE DE DISEÑO En la gráfica podemos observar el coste de dividir en módulos frente al coste de unir esos módulos. Esta técnica se puede aplicar a distintas escalas. Consiste en dividir un sistema en varios subsistemas. *Punto de variación: es un requisito del sistema que tiene características variables y puede cambiar. también se utiliza en los microdiseños. cada uno de estos resuelve un problema pequeñito y luego se vuelven a unir. primero se hace una abstracción del problema y una vez que tenemos un esquema abstracto usamos la técnica del refinamiento para centrarnos en detalles concretos. En el desarrollo del software todo lo que sea cambios es un problema. La táctica del refinamiento es justamente lo contrario. De esta manera tenemos una visión general de todo. además todos estos principios se relacionan entre sí. Esto nos plantea una pregunta: ¿Cómo lo divido? Pues no hay una forma exacta para hacer la división sino que depende de cada problema en particular. por tanto tengo que soportarlo en mi aplicación. sino hacer un esquema visual a alto nivel. pero aumenta la integración de los módulos. que consiste un dividir el problema en varios problemas más pequeños para que el coste de resolverlos sea menor. COSTE DE DISEÑO. Hay que buscar la justa medida que está comprendida en la región de costes mínimos. es decir no centrarse en detalles concretos del diseño. MODULARIDAD: se basa en el principio de "Divide y Vencerás". es decir. desde la arquitectura a la microarquitectura. La técnica de abstracción y refinamiento se complementa con la de refinamiento. la idea es proteger al sistema de los cambios en los puntos de variación y en los puntos de evolución. Los principios de diseño son los siguientes: ABSTRACCIÓN Y REFINAMIENTO: se trata de ocultar los detalles. VARIACIONES PROTEGIDAS: hay que tener claros dos conceptos: punto de variación y punto de evolución. *Punto de evolución: es cuando nosotros prevemos que se puede convertir en un punto de variación. . es decir.PRINCIPIOS DE DISEÑO Los principios de diseño son aplicables a todos los niveles del diseño del software. hay que prestar atención a estos puntos que cambian. Si dividimos en muchos módulos el coste disminuye. centrarse en los detalles del modelo abstracto dado anteriormente.

se trata de conseguir módulos muy cohesivos y que estén poco acoplados. -Datos externos: tener datos de configuración fuera de el sistema (ficheros de configuración. Para mejorar la cohesión lo mejor es dividir en subsistemas. su cambio afecta lo menos posible al resto de sistema. para ello están los interfaces internas. no hay que intentar disminuir el acoplamiento a toda costa. sino que hay que evaluar cómo hacerlo. ocultan los atributos y solo muestran los métodos... -Interfaces: por ejemplo lo que es una interfaz en Java. la cohesión debe ser alta en cada módulo. hay que ir evaluando a la vez que se diseña para aumentar la cohesión. David Parnas (1972) dijo: "...Cuando detecte un punto de variación y/o punto de evolución tengo que diseñarlo de forma que los cambios que se produzcan en el sistema afectan a lo mínimo posible. Nunca se puede dar el acoplamiento. La cohesión al igual que el acoplamiento es evolutiva. una misma interfaz puede tener distintas implementaciones.proponemos en lugar de eso (dividir en módulos) que uno comience con una lista de decisiones de diseño difíciles o con altas probabilidades de cambio. El acoplamiento hay que mantenerlos bajo para que cada módulo sea lo más independiente posible. ." Para hacer estos se puede usar alguno de los siguientes métodos: -Encapsulación: por ejemplo lo que hacen las clases en Java.. El acoplamiento es un principio evolutivo.). Un módulo hace cosas muy parecidas. COHESIÓN: es la medida cualitativa del grado en el que un módulo se enfoca a una sola cosa. De esta forma si un módulo cambia. No hay que usar la sobre ingeniería. Cada módulo se diseña entonces para ocultar dichas decisiones a otros (módulos).. -Ocultación de la estructura: un sistema no tiene necesidad de conocer los otros subsistemas. "Un elemento es altamente cohesivo si todos sus elementos trabajar juntos para proporcionar algún comportamiento bien determinado" A la cohesión y al acoplamiento se les denomina el Ying y el Yang del diseño software. ¡CUIDADO! El coste de diseñar la protección de un punto de variación o de evolución es superior que resolver un diseño simple. ACOPLAMIENTO: medida cualitativa del grado en el que un módulo está conectado a otros y el mundo exterior. Las clases con muchos métodos son poco cohesivas y habrá que dividir. tenemos que ir controlándolo a medida que se diseña hay que estar evaluando el grado de acoplamiento para conseguir que sea lo más bajo posible Hay que ser cautelar. es decir.

son solo algunos de los componentes que se aglomeran para conformar la ingeniería de software (IS) como disciplina para la creación y mantenimiento de software. lo hago cuando ya tengo un poco de código hecho. etc USABILIDAD: Capacidad de un software de ser comprendido. aprendido. se puede decir que la calidad de software ha sido usada desde un simple argumento de venta. REUTILIZACIÓN: no hay que reinventar la rueda. hasta verdaderos estudios formales y usos de métricas para el desarrollo de software. Una idea general sobre un software de calidad es aquel que debiera cumplir con los requerimientos funcionales y de performance además de ser mantenible. CONFIABILIDAD: El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida incluye varias características como la seguridad. confiable y aceptable. consiste en utilizar código que se sabe que funciona bien. usado y ser atractivo para el usuario. análisis y diseño. DISEÑO DE ATRIBUTOS DE CALIDAD La Calidad del software. . Para resumir de alguna manera la amplitud de este concepto. en vez de hacerlo nosotros de nuevo. La funcionalidad sigue siendo la misma pero mejora la estructura interna del código. Buscar que hay que resuelva mi problema y adaptarlo a mi caso. en condiciones específicas de uso. mejorando la cohesión y disminuyendo el acoplamiento. En lugar de aplicar la evaluación de la cohesión y el acoplamiento al principio. gestión de proyectos. Dentro de sus principales características tenemos: FUNCIONABILIDAD: es la capacidad que tendrá el producto de satisfacer los requisitos funcionales prescriptos y las necesidades implícitas de los usuarios. me concentraré solo en las diversas características que permiten describirla y en los elementos que importan específicamente al diseñador de software. pero siempre hay que tener en cuenta que la funcionalidad no puede cambiar. El proceso de desarrollo. Dentro de ésta. la calidad del software es muy complicada de definir y de enmarcar en un simple concepto teórico.REFACTORIZACIÓN: según Martin Fowler (1999) "Es el proceso de cambiar un sistema de software de tal forma que no se altere el comportamiento externo de su código (diseño) y aún así se mejora su estructura interna". existe un subconjunto de teorías. especificación de requerimientos. herramientas y métodos orientados a lo que se denomina la calidad del software. control de fallos. Existen catálogos de refactorización que nos puede ayudar a llevar a cabo una refactorización. es decir. arquitectura. por lo que en esta nota. Extrañamente dentro de la IS. es el desarrollo de software basado en estándares con la funcionalidad y rendimiento total que satisfacen los requerimientos del cliente.

le falta algo de la aplicación. se reducen los costes de producción porque ya está hecho. Cambiabilidad: que indica la cantidad de esfuerzo requerido para una modificación o borrado de un defecto Estabilidad: que indica volumen de riesgos de efectos inesperados tras una modificación.-Inconvenientes: encontrar el frameworks apropiado para nuestro caso. Se divide en: Capacidad de ser analizado:que indica la cantidad de esfuerzo requerido para diagnosticar la causa de un fallo. un Frameworks no tiene un ejecutable. SERVICIOS Y BIBLIOTECAS: tienen una funcionalidad empaquetada y diseñada para ser reutilizada. Tienes una interfaz bajo/local en el diseño de la aplicación cliente. -Ventajas del framework: reutilización de diseño y código. Una cuestión clave en el diseño de estos elementos reside en conseguir facilidad de uso para el máximo número de escenas sin complicar la interfaz ni reducir el rendimiento. Junit es un frameworks. Utilización de recursos: que indica las características del software que influyen en el número de recursos usados. Se divide en las subcaracteríticas: Comportamiento temporal: que indica las características del software que influyen en el tiempo de respuesta y procesado y productividad cuando se ejecuta su función. son difíciles de construir y de aprender a usar. *COMPONENTES. Los frameworks tienen una gran influencia en el diseño de la aplicación del cliente. por ejemplo. we'll call you!" que significa "No nos llames. gráficos. bajo ciertas condiciones dadas. MATENIBILIDAD:Esfuerzo requerido para implementar cambios. es algo cuya funcionalidad no está definida. gestión de documentos XML tienen funcionalidad lista para ser utilizada a través de una interfaz bien definida.  FRAMEWORKS: conjunto de clases parcialmente funcional (no es una aplicación) para un dominio de aplicación. usar más de un frameworks al mismo tiempo (temas de incompatibilidad entre los frameworks usados). y la duración de su uso. Facilidad de prueba: que indica la capacidad del software para permitir que sea validado tras ser modificado. cuando se lleva a cabo su función. nosotros te llamaremos". hay que tener en cuenta la experiencia del diseñador del framework. TRANSPORTABILIDAD:El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo. .EFICIENCIA: cuyo Conjunto de características determinan la relación entre el nivel de rendimiento del software y el número de recursos usados. Está basado en el principio de Hollywood "Don't call us. el manejo de periféricos.

• Objetos: Un objeto es un elemento de información sobre el que el usuario tiene algún control. indican las relaciones entre los subsistemas y los componentes del software y definen las reglas para especificar las relaciones entre los elementos de la arquitectura. es especifico de un Lenguaje de Programación. patrón de bajo nivel. deberemos guiar el diseño para obtener una implementación correcta. Una estructura típica del modelo conceptual es un conjunto de objetos capaces de realizar una serie de acciones (modelo objeto–acción). ya que el sistema está formado por componentes de naturaleza manipuladora (interactiva) con representación gráfica y en la que existe una gran vinculación (mediante herencia) de unos componentes con otros. de forma que puede utilizar un millón de veces sin hacer dos veces lo mismo". *PATRONES ARQUITECTÓNICOS: definen la estructura general del software. • Acciones: Una acción es una operación que el usuario puede realizar con un objeto. Dicho conjunto es una visión abstracta de la información gestionada por el sistema (modelo). pero en la mayoría de los casos. Estas acciones serán las tareas que debe realizar el usuario para manipular los objetos del dominio de la aplicación. . Nos centraremos en los mecanismos básicos de interacción y el diálogo con la aplicación y la capa de presentación. También describe el núcleo de la solución al problema. nos dan recetas de cosas que no hay que hacer. DISEÑO ORIENTADO A OBJETOS Los interfaces de usuario son muy adecuados para un desarrollo basado en el paradigma de objetos [COX93]. *ANTIPATRONES: se aprende de los errores más que de los aciertos. ESTRATEGIAS DE DISEÑO: Con los modelos que se disponen de las tareas y de la arquitectura del sistema.*IDIOMAS: una forma de utilizar un Lenguaje de Programación. *PATRONES DE DISEÑO: "Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno. El conjunto de objetos posee usualmente alguna estructura. El conjunto de acciones no tiene que ser necesariamente ortogonal al de los objetos. El conjunto de acciones define la capacidad funcional del sistema. Describen soluciones a problemas de implementación de un determinado Lenguaje de Programación por ejemplo la gestión de memorias en C++. requerirá de un profundo reconocimiento de los aspectos más delicados del proceso de diseño y que está directamente relacionado con el diálogo con la máquina y la presentación de la información. Este proceso en algunos casos puede ser automático.

Uno de los más importantes es su representación gráfica. Los objetos se describen identificando sus atributos más relevantes. Siempre puede . todos tienen algunas características en común: 1) todos asisten al analista en la identificación de los objetos de información clave (también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos). 4) todos dan un conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa.) mientras que el registro de una persona es un objeto de control susceptible de aplicarle acciones del dominio de la aplicación (insertar. Para la descripción de los objetos y de las acciones podemos usar metáforas que ayuden a comprender su significado y utilización (ver capítulo ‘Metáforas. redimensionar. una regla o una ventana son objetos intrínsecos con acciones propias (mover. Un flexo dispone de una bombilla. Como los métodos orientados al flujo de datos. etc. 3) todos requiere que la estructura de datos se represente usando la secuencia.Ejemplo: Flexo. la bombilla se ilumina. ver DNI. la clavija se puede conectar y desconectar a una base de enchufe. mientras que el diagrama de estado indicaría cómo cambia el estado de los objetos con las modificaciones (cómo implementarlo). estilos y paradigmas’). Los métodos de análisis orientados a la estructura de datos representan los requerimientos del software enfocándose hacia la estructura de datos en vez de al flujo de datos. modificar.). Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta. una barra de iconos. ocultar. Cuando la clavija está conectada a una base en buen estado y el interruptor esta en la posición de encendido. El lenguaje de órdenes nos daría información necesaria acerca del protocolo (qué acción se realiza). el contenido de datos y la estructura de datos. Por ejemplo. etc. Podemos identificar dos tipos de objetos: a) aquellos que aparecen en la comunicación entre el usuario y el sistema y que típicamente pertenecen a la interfaz (objetos de control). y b) los que son propios de la aplicación (objetos intrínsecos). 2) todos suponen que la estructura de la información es jerárquica. los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. Para la especificación del sistema deberemos identificar tanto a los objetos como a sus acciones asociadas. un interruptor y una clavija de enchufe. Para describir las acciones se puede utilizar una notación de diálogo basada en diagramas de estado y lenguaje de órdenes (secuencia). selección y repetición. ESTRATEGIAS DE DISEÑO ORIENTADO A ESTRUCTURA DE DATOS El dominio de la información para un problema de software comprende el flujo de datos. El interruptor puede estar en una de dos posiciones (encendido o apagado).

o las relaciones entre ellos.extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software. sin llegar a la implementación. pero sí sobre la de un subsistema (Buschman et al. 1996). que resuelve un problema general de diseño en un contexto particular (Buschman et al. el comportamiento de los componentes del subsistema. y tienden a ser independientes de los lenguajes y paradigmas de programación.. Su aplicación no tiene efectos en la estructura fundamental del sistema.. 1996). debido a que especifica a un mayor nivel de detalle. . Son menores en escala que los patrones arquitectónicos. Describe la estructura comúnmente recurrente de los componentes en comunicación. Patrón de Diseño Un patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema de software.

Sign up to vote on this title
UsefulNot useful