1. Fundamentos del diseño software
1.1. Conceptos generales de diseño
1.2. Contexto del diseño del software
1.3. Proceso del diseño del software
1.3.1. El diseño del software generalmente se considera un proceso de dos etapas:
1.3.1.1. Diseño arquitectónico:El diseño arquitectónico describe cómo el software se descompone y se organiza en los componentes (la arquitectura) del software [lEEEPl47l-00]
1.3.1.2. Diseño detallado: El diseño detallado describe el comportamiento específico de estos componentes. La salida de este proceso es un sistema demodelos y los artefactos que registran las decisiones principales que se han tomado. [Bud04: c2; IEE1016-98', LisOl: cl3', Pre04: c9]
1.4. Permitir técnicas
1.4.1. Abstraccion
1.4.1.1. En el contexto del diseño del sofiware, dos mecanismos dominantes de la abstracción son parametrización y especificación. La abstracción por la especificación conduce a tres clases importantes de abstracción: abstracciónprocesal, abstracción de los datos, y abstracción del control
1.4.2. Aooplador y cohesión
1.4.3. Descompocision y modularizacion
1.4.4. Encapsulacion/el ocultar la informacion
1.4.5. Separación del interfaz y de la puesta en práctica
1.4.6. Desahogo, lo completo y deshacie'ndose de lo primitivo
2. Cuestiones claves en diseño del software
2.1. Se tiene que tener en cuenta a la hora de diseñar software una serie de principios claves. Algunos son preocupaciones que todo el software debe tratar -por ejemplo, funcionamiento de la calidad. Otra edición importante es cómo se descomponer, se organiza, y constituyen los paquetes de software.
2.1.1. Concurrencia
2.1.2. Control y dirección de acontecimientos
2.2. Distribución de componentes
2.3. Dirección del error y de excepción y tolerancia de fallos
2.4. Interacción y presentación
2.4.1. Cómo estructurar y organizar las interacciones con los usuarios y la presentación de la información (por ejemplo, separación de la presentación y de la lógica del negocio usando el acercamiento del Modelo-Vista- Regulador).
2.4.1.1. Debe ser observado que este asunto no está sobre especificar los detalles del interfaz utilizador, que es la tarea del diseño del interfaz utilizador (una parte de ergonómica del software)
2.5. Persistencia de los datos
3. Estructura y arquitectura del soflware
3.1. Estructuras y puntos de vista arquitectonicos
3.1.1. un diseño del software es un artefacto múltiple producido por el proceso del diseño e integrado generalmente por visiones relativamente independientes y ortogonal
3.1.2. Un estilo arquitectónico es un sistema de apremios en una arquitectura que define un sistema o una familia de arquitecturas que las satisfagan
3.1.2.1. Estructura general (por ejemplo, capas, pipas, y filtros, pizarra)
3.1.2.2. Sistemas distribuidos (por ejemplo, servidor de cliente, tres gradas, corredor)
3.1.2.3. Sistemas interactivos (por ejemplo, regulador de la Modelo-Vista, Presemación-Abstracción-Control)
3.1.2.4. Sistemas adaptables (por ejemplo, micro-núcleo, reflexión)
3.1.2.5. Otros (por ejemplo, homada, intérpretes, control, basados en las reglas de proceso).
3.2. Patrones del diseño (patrones arquitectónicos micro)
3.2.1. una solución común a un problema común en un contexto dado
3.2.1.1. Mientras que los estilos arquitectónicos se pueden ver como patrones que describen la organización de un nivel alto del soflware (su arquitectura macro); otros patrones del diseño se pueden utilizar para describir los detalles en un nivel mas bajo,más local (su arquitectura micro).
3.2.1.2. Patrones de creación (por ejemplo, builder, factory,prototipo, y Singleton)
3.2.1.3. Patrones estructurales (por ejemplo, adapter,bridge, composite, decorator, facade, flyweíght,and proxy)
3.2.1.4. Patrones del comportamiento (por ejemplo,command, interpreter, ítemtor, medíator, memento, Observer, state, strategy, template, visitor)
3.3. Familias de programas y de marcos
3.3.1. Una posible opcion para permitir la reutilización de los diseños y de los componentes del software es diseñar las familias del software, también conocidas como lineas del producto de software
3.3.1.1. Estas pueden ser hecha identificando la conoordancias entre los miembros de tales familias y por los componentes reutilizables y adaptables entre miembros de la familia.
3.3.2. En programación orientada a objetos, una clave relacionada es la del marco: un subsistema parcialmente completo del software que puede ser ampliado apropiadamente instalando los plugins especificos (también conocidos como puntos calimmes).
4. Análisis y evaluación de la calidad del diseño del software
4.1. Cualidades de los atributos
4.1.1. Varias atributos son generalmente importantes para obtener un diseño del sofiware de buenos calidad - varios “ilities” (capacidad de mantenimiento, portabilidad, testeo, trazabilidad), los varios “nesses” (corrección, robusta), incluyendo la aptitud del propósito. )
4.1.2. Una distinción interesante es la que esta entre las cualidades de la calidad discernible en el tiempo de ejecución (funcionamiento, seguridad, disponibilidad, funcionalidad, utilidad), ésas no discernibles en el tiempo de ejecución (modificabilidad, portabilidad, reutilidad, integridad, y testeabilidad), y esas relacionadas con las calidades intrínsecas de la arquitectura (integridad, corrección, y lo completo,capacidad conceptuales de la estructura)
4.2. Técnicas de evaluación y calidad del análisis.
4.2.1. Revisiones de diseño del software: informal o semiformal, a menudo basado en grupo, las tecnicas para verificar y para asegurar la calidad de los artefactos del diseño revisiones de diseño, e inspecciones.
4.2.2. Análisis estático: analisis estático formal o semiformal (ningún ejecutable) que se puede utilizar para evaluar un diseño (por ejemplo, el análisis o el cross-checking automatizado)
4.2.3. Simulación y prototipado: técnicas dinamicaspara evaluar un diseño (por ejemplo, simulación o prototipo de la viabilidad [Bas98 del funcionamiento: clO', BosOO: c5; Bud04: c4; PfiOl: c5]
4.3. Medidas
4.3.1. Las medidas se pueden utilizar para determinar o para estimar cuantitativamente varios aspectos del tamaño, de la estructura, o de la calidad de un diseño del software.
4.3.2. La mayoría de las medidas se han propuesto que dependen generalmente del acercamiento usado para producir el diseño. Estas medidas se clasifican en dos amplias categorias
4.3.2.1. Diseño de medidas orientada a función (estructuradas): Estructura del diseño, obtenida sobre todo con la descomposición funcional; representado generalmente como una carta de estructura (a veces llamada un diagrama jerárquico) en la cual varias medidas pueden ser coomputadas [Jal97: c5, c7, Pre04: ]
4.3.2.2. Diseño de medidas orientada a objetos: La estructura total del diseño se representa a menudo como diagrama de la clase, en el cual varias medidas pueden ser computadas. Las medidas en las caracteristicas del contenido intero de cada clase pueden también ser computadas [Jal97: c6, c7; Pre04: clS]
5. Notaciones del diseño del soflware
5.1. Muchas notaciones e idiomas existen para representar los artefactos del diseño del sofiware.
5.1.1. Ciertas notaciones se utilizan sobre todo durante el diseño arquitectónico y anos principalmente durante el diseño detallado,aunque algunas notaciones se pueden utilizar en ambos pasos.
5.1.2. algunas notaciones se utilizan sobre todo en el contexto de métodos específicos.se categorizan en las notaciones para describir la opinión (estática) estructural contra la visión (dinámica) del comportamiento.
5.2. Descripción estructural (vista estática)
5.2.1. Las siguientes notaciones, sobre todo (pero no siempre) graficas, describen y representan los aspectos estructurales del diseño de sofiware - las cuales, describen los componentes principales y cómo se interconectan (visión estática)
5.2.1.1. Lenguajes descriptivos de la arquitectura: textuales, a menudo formal, los lenguajes describian una arquitectura del software en terminos de componentes y conectadores
5.2.1.2. Diagramas de la clase y objeto: usados para representar un sistema de clms (y de objetos) y de sus correlaciones.
5.2.1.3. Diagramas de componentes: usados para representar un sistema de componentes (parte fisica y reemplazable de un sistema al cual conforma y proporciona la realización de un sistema de interfaces”) y de suscorrelaciones
5.2.1.4. Tarjetas del colaborador de la responsabilidad de la clase (CRC): denotan los nombres de los componentes (clases), de sus responsabilidades, y nombres de sus componentes de colaboración
5.2.1.5. Diagramas de despliegue: representar un sistema de nodos (fisico) y de sus correlaciones, y, mi, modelaban los aspectos fisicos de un sistema
5.2.1.6. Diagramas de la Entidad-relación (ERDs): representan modelos conceptuales de los datos almacenados en los sistemas de información
5.2.1.7. Lenguaje descriptivo de la interfaz (IDLS): programacion como lenguajes usados para definir los interfaces (nombres y tipos deoperaciones exportadas) de los componentes de soflware
5.2.1.8. Diagramas de la estructura de Jackson: Usados para describir las estructuras de datos en términos de secuencia, selección, e iteración
5.2.1.9. Estructura de canas: Usados para describir la estructura que llamaba de los programas (el módulo llama, y es llamado por otro módulo)
5.3. Descripciones del comportamiento (visión dinámica)
5.3.1. Las siguientes notaciones y lenguajes, algunos graficos y otros textuales, se utilizan para describir el comportamiento dinamico del sofiware y de los componentes
5.3.1.1. Muchas de estas notaciones son útiles sobre todo, pero no exclusivamente, durante el diseño detallado.
5.3.1.1.1. Diagramas de actividad: Muestran el flujo del control de la actividad (“ejecución no-atómica en curso dentro de una maquina del estado”) a la actividad
5.3.1.1.2. Diagramas de colaboración: Muestran las interacciones que ocurren entre un grupo de objetos, donde esta el énfasis en los objetos, sus acoplamientos, y los mensajes que intercambian en estos acoplamientos
5.3.1.1.3. Organigramas de datos: Muestran los flujos de datos entre un sistema y los procesos
5.3.1.1.4. Tablas y diagramas de decisión: representan combinaciones complejas de las condiciones y de las acciones
5.3.1.1.5. Organigramas y organigramas estructurados: Representan el control de flujo y de las acciones asociadas que se realizaran
5.3.1.1.6. Diagramas de secuencia: Muestran las interacciones entre un grupo de objetos, con énfasis sobre el tiempo de ordenación de mensajes
5.3.1.1.7. Transición de estado y diagramas de carta de estado: demostraban el control de flujo de estado a estado en um maquina de estados
5.3.1.1.8. Lenguajes formales de especificaciones: Lenguajes textuales que utilizan nociones bésicas dc mateméticas (por ejemplo, Iogica,sistema, secuencia), para obtener de forma rigurosa y abstracta, definir interfaces y comportamientos del componente de sofiware, a menudo en términos dc pre y post- condiciones )
5.3.1.1.9. Lenguajes del diseño de pseudo codigo del programa (PDLS): Programa estructurado como los lenguajes usados para describir,generalmente en la etapa detallada del diseño, el comportamiento de un procedimiento o el de un método
6. Estrategias y métodos del diseño de software
6.1. las estrategias generales, los métodos son más específicos, sugieren y proporcionan generalmente un sistema de notaciones que se utilizarán con el método, una descripción del proceso que se utilizará después del método y un sistema de pautas al usar el método.
6.2. Estrategias general
6.2.1. Algunos de los ejemplos citados de las estrategias generales útiles en el proceso del diseño son dividir y conquistar y el refinamiento
6.2.2. arriba hacia abajo contra las estrategias bottom-up
6.2.3. abstracción de los datos y el ocultar de la información
6.2.4. uso de la heurística uso de patrones y lenguajes de patrones , uso de un acercamiento iterativo e incremental.
6.3. Diseño (estructurado) orientado a función
6.3.1. Esto es uno de los métodos clásicos del diseño de software, donde los centros de descomposición identifican las funciones del sofiware y después elaboran y refinan de una manera de arriba hacia abajo.
6.3.2. El diseño estructurado se utiliza generalmente después de analisis estructurado, produciendo así, entre otras cosas, organigramas de datos y de descripciones de proceso asociados
6.3.3. Los investigadores han propuesto varias estrategias (por ejemplo, análisis de la transformación, análisis de la transacción) y la heurística (por ejemplo, fan-in/fan-out, alcance del efecto contra el alcance del control) para transformar un DFD en una arquitectura del software representada generalmente como carta de estructura.
6.4. Diseño orientado a objeto
6.4.1. El campo se ha desarrollado basado en el diseño objeto de los mediados de los años ochenta (sustantivo = objeto; verbo =metodo; adjetivo = cualidad) con el diseño orientado a objetos, donde la herencia y el polimorfismo desempeñan un papel importante, el campo del diseño del componente-basado, donde la meta información puede ser definida y ser alcanzada
6.4.2. Aunque las raíces del diseño Orientado a Objetos provienen del concepto de la abstracción de los datos, el diseño responsabilidad-conducido también se ha propuesto como alternativo al diseño Orientado a Objetos.
6.5. Diseño Dato-Estructurado-Centrado
6.5.1. El diseño Dato-estructura-centrado (por ejemplo, Jackson, Warnier-Orr) comienza desde las estructuras de datos que un programa manipula más bien que desde las funciones que realiza
6.5.2. La Ingeniería de software primero describe las estructuras de datos de entrada y de salida (que usan los diagramas de la estructura de Jackson, por ejemplo) y en seguida desarrolla la estructura de control del programa basada en estos diagramas de estructura de datos
6.5.3. La varia heuristica se ha propuesto para tratar como caso especial, cuando hay una unión mal hecha entre la entrada y las estructuras de la salida.
6.6. Diseño basado en componente (CBD)
6.6.1. Un componente de software es una unidad independiente, teniendo bien definidos los interfaces y dependencias que se pueden componer y desplegar independientemente.
6.6.2. El diseño basado en componente trata las ediciones relacionadas con el abastecimiento
6.7. Otros métodos
6.7.1. Otros interesantes pero menos aprovechados también existen: métodos formales y rigurosos y métodos transformacionales.