Software de Diseño

----Software de Diseño

 El diseño de software es el proceso de visionado y definición de soluciones software a uno o más conjuntos de problemas. Uno de los componentes principales del diseño de software es el análisis de requisitos del software (ARS, del inglés SRA). Se trata de una parte del proceso de desarrollo de software que enumera especificaciones empleadas en ingeniería de software. Si el software está "automatizado" o centrado en el usuario, el diseño de software puede implicar también el diseño de experiencia de usuario que utiliza un storyboard o guion gráfico para ayudar determinar esas especificaciones. Si el software es completamente automatizado (es decir, sin usuario o interfaz de usuario), un diseño de software puede ser tan sencillo como un diagrama de flujo o un texto describiendo una secuencia planeada de acontecimientos. También hay métodos semiestándares como el Lenguaje Unificado de Modelado (UML) y conceptos fundamentales de modelado. En cualquier caso, normalmente alguna documentación del plan resulta como producto del diseño. Además, un diseño de software puede ser independiente de la plataforma o específico de la plataforma, dependiendo de la disponibilidad de la tecnología utilizada para el diseño.

La diferencia principal entre análisis y el diseño de software es que la producción de un análisis de software se compone de problemas más pequeños para solucionar. Además, el análisis no tendría que ser diseñado de manera muy distinta por miembros de equipo diferente. En contraste, el diseño se enfoca a capacidades y, por tanto, múltiples diseños existen y existirán para el mismo problema. Según el entorno, el diseño también varía en función de si se está creando a partir de frameworks fiables o implementando con patrones de diseño adecuados. Ejemplos de diseño incluyen sistemas de operaciones, páginas web, dispositivos móviles o incluso el nuevo paradigma de computación en la nube.

Es importante tener en cuenta aun así que el proceso de diseño no es siempre un procedimiento sencillo; el modelo de diseño puede ser comparado con los planos de una casa para un arquitecto. Se empieza representando la totalidad de la cosa que se va a construir (p. ej., un renderizado tridimensional de la casa); la cosa se va refinando lentamente para sevir como guía a la hora de construir cada detalle (p. ej., la parte de fontanería). Del mismo modo, el modelo de diseño que se crea para el software proporciona una variedad de visiones distintas del software. Los principios básicos de diseño ayudan al ingeniero de software a navegar por el proceso de diseño. 

Davis sugiere un conjunto de principios de diseño de software que han sido adaptados y extendidos en la siguiente lista:

 ○ El proceso de diseño no tendría que sufrir "visión de túnel." Un buen diseñador tendría que considerar enfoques alternativos, juzgando cada uno basándose en los requisitos del problema, en los recursos disponibles para hacer el trabajo.

 ○ El diseño tendría que ser rastreable por el modelo de análisis. Ya que un único elemento del modelo de diseño a menudo puede remontarse a múltiples requisitos, es necesario tener un medio para observar cómo los requisitos han sido satisfechos por el modelo de diseño.

 ○ El diseño no tendría que reinventar la rueda. Los sistemas se  construyen utilizando un conjunto de patrones de diseño, muchos de los cuales probablemente han sido utilizados anteriormente. Estos patrones deberían ser escogidos como alternativa a la reinvención. Se dispone de poco tiempo y recursos limitados; tiempo de diseño tendría que invertirse en representar ideas verdaderamente nuevas integrando patrones que ya existan (siempre y cuándo esto sea posible).

 ○ El diseño debe "minimizar la distancia intelectual" entre el software y el problema tal y como existe en el mundo real. Esto es, la estructura del diseño de software debe, siempre que sea posible, imitar la estructura del dominio del problema.

 ○ El diseño tiene que exhibir uniformidad e integración. Un diseño es uniforme si resulta plenamente coherente. Para conseguir esto, las reglas de estilo y formato han de ser definidas para el equipo de diseño antes de que comience el trabajo de diseño. Un diseño está integrado si se ha tomado la molestia en definir interfaces entre componentes de diseño.

 ○ El diseño tendría que ser estructurado para adaptarse al cambio. Los conceptos de diseño que se exponen en la próxima sección, habilitan al diseño para conseguir este principio.

 ○ El diseño tendría que estar estructurado para degradarse suavemente, incluso cuándo los datos, los acontecimientos o las condiciones operativas son irregulares. El software bien diseñado nunca debería "explotar"; debe ser diseñado para adaptarse a circunstancias inusuales, y si tuviera que terminar su ejecución, habrá de hacerlo de la manera más grácil posible.

 ○ El diseño no es codificación, la codificación no es diseño. Incluso cuándo los diseños detallados de procesos están creados para componentes del programa, el nivel de abstracción del modelo de diseño es más alto que el del código fuente. Las únicas decisiones de diseño del nivel de codificación tendrían que referirse a pequeños detalles de implementación para habilitar la codificación del diseño de procesos.

 ○ La calidad del diseño tendría que ser evaluado cuando se está creando, no después. Una variedad de conceptos y medidas de diseño están disponibles para asistir al diseñador en la evaluación de la calidad durante el proceso de desarrollo.

 ○ El diseño tendría que ser revisado para minimizar los errores conceptuales (semánticos). A veces hay una tendencia a centrarse en minucias cuándo se revisa el diseño. El equipo de diseño tendría que asegurarse de que los elementos conceptuales importantes del diseño (omisiones, ambigüedad, incongruencias) han sido tratados antes de preocuparse por la sintaxis del modelo de diseño.

----Conceptos de Diseño

Los conceptos de diseño proporcionan al diseñador de software una base sobre la que se pueden aplicar métodos más sofisticados. El conjunto de conceptos fundamentales del diseño ha evolucionado. Son los siguientes:

 ○ Abstracción - la abstracción es el proceso o resultado de la generalización reduciendo el contenido de información de un concepto o un fenómeno observable, típicamente para retener información única que es pertinente para un propósito particular. Es el acto de Representar características esenciales sin incluir los detalles de fondo o explicaciones.

 ○ Refinamiento - es el proceso de elaboración. Una jerarquía se desarrolla descomponiendo una declaración macroscópica de función de un modo sensato hasta que se logre obtener declaraciones del lenguaje de programación. En cada paso, una o varias instrucciones de un programa dado se descomponen en instrucciones más detalladas. La abstracción y El Refinamiento son conceptos complementarios .

 ○ Modularidad - La arquitectura de software está dividida en componentes llamados módulos.

 ○ Arquitectura de software - se refiere a la estructura global del software y las maneras en que esa estructura proporciona integridad conceptual al sistema. Una buena arquitectura de software amortizará la inversión en cuanto al resultado deseado del proyecto, p. ej. en el rendimiento, la calidad, el programa y el coste.

 ○ Jerarquía de control - Un estructura de programa  que representa la organización de un componente e implica una jerarquía de control.

 ○ Estructural Partitioning - La estructura de programa puede ser dividida horizontal y verticalmente. Las particiones horizontales definen ramas separadas de jerarquía modular para cada función importante. Las particiones verticales sugiere que el control y el trabajo tendrían que ser distribuidos de arriba a abajo en la estructura de programa.

 ○ Estructura de datos - es una representación de la relación lógica entre los elementos individuales de los datos.

 ○ Procedimiento de software - centra en el procesamiento de cada módulo individualmente.

 ○ Ocultar Información- los módulos tendrían que ser especificados y diseñados de modo que la información contenida dentro de un módulo es inaccesible a otros módulos, que no tienen ninguna necesidad de conocer esa información.

En su modelo de objeto, Grady Booch menciona Abstracción, Encapsulación, Modularización y Jerarquía como principios fundamentales del diseño de software4​. El acrónimo PHAME (del inglés: Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation) se utiliza a veces para referirse a estos cuatro principios fundamentales

----Consideraciones de Diseño

Hay muchos aspectos a considerar en el diseño de una pieza de software. La importancia de cada consideración tendría que reflejar los objetivos y expectativas para los que el software está siendo creado. Algunos de estos aspectos son:

 ○ Compatibilidad

 ○ Extensibilidad

 ○ Modularidad

 ○ Tolerancia a fallos

 ○ Mantenibilidad

 ○ Fiabilidad

 ○ Reusabilidad

 ○ Robustez

 ○ Seguridad

 ○ Usabilidad

 ○ Rendimiento

 ○ Portabilidad

 ○ Escalabilidad