P. 1
IMPORTANCIA DEL DISEÑO

IMPORTANCIA DEL DISEÑO

|Views: 5|Likes:
Publicado porduquevc

More info:

Published by: duquevc on May 06, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

05/06/2013

pdf

text

original

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.

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

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

El acoplamiento es un principio evolutivo. ¡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. ..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. David Parnas (1972) dijo: ".). no hay que intentar disminuir el acoplamiento a toda costa." Para hacer estos se puede usar alguno de los siguientes métodos: -Encapsulación: por ejemplo lo que hacen las clases en Java. De esta forma si un módulo cambia. ACOPLAMIENTO: medida cualitativa del grado en el que un módulo está conectado a otros y el mundo exterior. ocultan los atributos y solo muestran los métodos.. para ello están los interfaces internas. la cohesión debe ser alta en cada módulo. -Interfaces: por ejemplo lo que es una interfaz en Java. Un módulo hace cosas muy parecidas.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. Para mejorar la cohesión lo mejor es dividir en subsistemas. se trata de conseguir módulos muy cohesivos y que estén poco acoplados. La cohesión al igual que el acoplamiento es evolutiva. Cada módulo se diseña entonces para ocultar dichas decisiones a otros (módulos).. sino que hay que evaluar cómo hacerlo. -Ocultación de la estructura: un sistema no tiene necesidad de conocer los otros subsistemas. Nunca se puede dar el acoplamiento. 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. Las clases con muchos métodos son poco cohesivas y habrá que dividir.. su cambio afecta lo menos posible al resto de sistema. COHESIÓN: es la medida cualitativa del grado en el que un módulo se enfoca a una sola cosa... una misma interfaz puede tener distintas implementaciones. El acoplamiento hay que mantenerlos bajo para que cada módulo sea lo más independiente posible. "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. hay que ir evaluando a la vez que se diseña para aumentar la cohesión. -Datos externos: tener datos de configuración fuera de el sistema (ficheros de configuración. es decir. No hay que usar la sobre ingeniería.

gestión de proyectos. usado y ser atractivo para el usuario. control de fallos. Existen catálogos de refactorización que nos puede ayudar a llevar a cabo una refactorización. En lugar de aplicar la evaluación de la cohesión y el acoplamiento al principio. es decir. confiable y aceptable. herramientas y métodos orientados a lo que se denomina la calidad del software. la calidad del software es muy complicada de definir y de enmarcar en un simple concepto teórico. La funcionalidad sigue siendo la misma pero mejora la estructura interna del código. en condiciones específicas de uso. 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. Buscar que hay que resuelva mi problema y adaptarlo a mi caso. . arquitectura. 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. por lo que en esta nota. etc USABILIDAD: Capacidad de un software de ser comprendido. existe un subconjunto de teorías. análisis y diseño. El proceso de desarrollo. 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. Dentro de ésta. aprendido. consiste en utilizar código que se sabe que funciona bien. REUTILIZACIÓN: no hay que reinventar la rueda. DISEÑO DE ATRIBUTOS DE CALIDAD La Calidad del software. lo hago cuando ya tengo un poco de código hecho. hasta verdaderos estudios formales y usos de métricas para el desarrollo de software. Para resumir de alguna manera la amplitud de este concepto. pero siempre hay que tener en cuenta que la funcionalidad no puede cambiar. 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.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". en vez de hacerlo nosotros de nuevo. especificación de requerimientos. se puede decir que la calidad de software ha sido usada desde un simple argumento de venta. me concentraré solo en las diversas características que permiten describirla y en los elementos que importan específicamente al diseñador de software. mejorando la cohesión y disminuyendo el acoplamiento. 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.

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

El conjunto de objetos posee usualmente alguna estructura. deberemos guiar el diseño para obtener una implementación correcta. Estas acciones serán las tareas que debe realizar el usuario para manipular los objetos del dominio de la aplicación. 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. Nos centraremos en los mecanismos básicos de interacción y el diálogo con la aplicación y la capa de presentació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. nos dan recetas de cosas que no hay que hacer. de forma que puede utilizar un millón de veces sin hacer dos veces lo mismo". *PATRONES DE DISEÑO: "Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno. Describen soluciones a problemas de implementación de un determinado Lenguaje de Programación por ejemplo la gestión de memorias en C++. Dicho conjunto es una visión abstracta de la información gestionada por el sistema (modelo). 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. . El conjunto de acciones define la capacidad funcional del sistema. • Objetos: Un objeto es un elemento de información sobre el que el usuario tiene algún control. DISEÑO ORIENTADO A OBJETOS Los interfaces de usuario son muy adecuados para un desarrollo basado en el paradigma de objetos [COX93]. Una estructura típica del modelo conceptual es un conjunto de objetos capaces de realizar una serie de acciones (modelo objeto–acción). También describe el núcleo de la solución al problema. patrón de bajo nivel. 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. • Acciones: Una acción es una operación que el usuario puede realizar con un objeto. *PATRONES ARQUITECTÓNICOS: definen la estructura general del software. pero en la mayoría de los casos. *ANTIPATRONES: se aprende de los errores más que de los aciertos. Este proceso en algunos casos puede ser automático. El conjunto de acciones no tiene que ser necesariamente ortogonal al de los objetos.

el contenido de datos y la estructura de datos. Los objetos se describen identificando sus atributos más relevantes. 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). Por ejemplo. un interruptor y una clavija de enchufe.) mientras que el registro de una persona es un objeto de control susceptible de aplicarle acciones del dominio de la aplicación (insertar. 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. Uno de los más importantes es su representación gráfica. Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta. la clavija se puede conectar y desconectar a una base de enchufe. ocultar. El lenguaje de órdenes nos daría información necesaria acerca del protocolo (qué acción se realiza). ver DNI. 2) todos suponen que la estructura de la información es jerárquica. una barra de iconos. los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. 3) todos requiere que la estructura de datos se represente usando la secuencia. 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). y b) los que son propios de la aplicación (objetos intrínsecos). mientras que el diagrama de estado indicaría cómo cambia el estado de los objetos con las modificaciones (cómo implementarlo). El interruptor puede estar en una de dos posiciones (encendido o apagado). Siempre puede . la bombilla se ilumina. etc. una regla o una ventana son objetos intrínsecos con acciones propias (mover. redimensionar.). 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. Un flexo dispone de una bombilla. estilos y paradigmas’). modificar. selección y repetición.Ejemplo: Flexo. Cuando la clavija está conectada a una base en buen estado y el interruptor esta en la posición de encendido. Para describir las acciones se puede utilizar una notación de diálogo basada en diagramas de estado y lenguaje de órdenes (secuencia). etc. Para la especificación del sistema deberemos identificar tanto a los objetos como a sus acciones asociadas. 4) todos dan un conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa. 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. Como los métodos orientados al flujo de datos.

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->