Diseño de software

Diseño de software es el proceso mediante el cual un agente crea una especificación de un artefacto de software destinado a lograr objetivos, utilizando un conjunto de componentes primitivos y sujeto a restricciones. El término a veces se usa ampliamente para referirse a "toda la actividad involucrada en conceptualizar, enmarcar, implementar, encargar y, en última instancia, modificar" el software, o más específicamente "la actividad que sigue a la especificación de requisitos y antes de la programación, como... [en] un proceso estilizado de ingeniería de software."

El diseño de software suele implicar la resolución de problemas y la planificación de una solución de software. Esto incluye un diseño de componentes y algoritmos de bajo nivel y un diseño de arquitectura de alto nivel.

Resumen

El diseño de software es el proceso de visualizar y definir soluciones de software para uno o más conjuntos de problemas. Uno de los principales componentes del diseño de software es el análisis de requisitos de software (SRA). SRA es una parte del proceso de desarrollo de software que enumera las especificaciones utilizadas en la ingeniería de software.

Si el software es "semiautomático" o centrado en el usuario, el diseño de software puede implicar el diseño de la experiencia del usuario que produce un guión gráfico para ayudar a determinar esas especificaciones. Si el software está completamente automatizado (es decir, sin usuario o interfaz de usuario), el diseño de un software puede ser tan simple como un diagrama de flujo o un texto que describe una secuencia planificada de eventos. También hay métodos semiestándar como el lenguaje de modelado unificado y los conceptos de modelado fundamental. En cualquier caso, parte de la documentación del plan suele ser el producto del diseño. Además, un diseño de software puede ser independiente de la plataforma o específico de la plataforma, según la disponibilidad de la tecnología utilizada para el diseño.

La principal diferencia entre el análisis y el diseño de software es que el resultado de un análisis de software consiste en problemas más pequeños para resolver. Además, el análisis no debe diseñarse de manera muy diferente entre los diferentes miembros o grupos del equipo. Por el contrario, el diseño se centra en las capacidades y, por lo tanto, pueden existir y existirán múltiples diseños para el mismo problema. Según el entorno, el diseño a menudo varía, ya sea que se cree a partir de marcos confiables o se implemente con patrones de diseño adecuados. Los ejemplos de diseño incluyen sistemas operativos, páginas web, dispositivos móviles o incluso el nuevo paradigma de computación en la nube.

El diseño de software es tanto un proceso como un modelo. El proceso de diseño es una secuencia de pasos que permite al diseñador describir todos los aspectos del software para la construcción. Habilidad creativa, experiencia pasada, un sentido de lo que hace "bueno" software y un compromiso general con la calidad son ejemplos de factores críticos de éxito para un diseño competente. Sin embargo, es importante señalar que el proceso de diseño no siempre es un procedimiento sencillo; el modelo de diseño se puede comparar con los planos de un arquitecto para una casa. Comienza representando la totalidad de lo que se va a construir (por ejemplo, una representación tridimensional de la casa); lentamente, la cosa se refina para proporcionar una guía para construir cada detalle (por ejemplo, la instalación de plomería). De manera similar, el modelo de diseño que se crea para el software proporciona una variedad de vistas diferentes del software de la computadora. Los principios básicos de diseño permiten al ingeniero de software navegar por el proceso de diseño. Davis sugiere un conjunto de principios para el diseño de software, que se han adaptado y ampliado en la siguiente lista:

• El proceso de diseño no debe sufrir de "visión de túneles". Un buen diseñador debe considerar enfoques alternativos, a juzgar cada uno basado en los requisitos del problema, los recursos disponibles para hacer el trabajo.
• El diseño debe ser rastreable al modelo de análisis. Debido a que un único elemento del modelo de diseño se puede rastrear a menudo a múltiples requisitos, es necesario tener un medio para rastrear cómo los requisitos han sido satisfechos por el modelo de diseño.
• El diseño no debe reinventar la rueda. Los sistemas se construyen utilizando un conjunto de patrones de diseño, muchos de los cuales probablemente se han encontrado antes. Estos patrones siempre deben ser elegidos como una alternativa a la reinvención. El tiempo es corto y los recursos son limitados; el tiempo de diseño debe invertirse en representar (realmente nuevas) ideas mediante la integración de patrones que ya existen (cuando se aplica).
• El diseño debe "minimizar la distancia intelectual" entre el software y el problema como existe en el mundo real. Es decir, la estructura del diseño de software debe, siempre que sea posible, imitar la estructura del dominio del problema.
• El diseño debe mostrar uniformidad e integración. Un diseño es uniforme si parece totalmente coherente. Para lograr este resultado, las reglas de estilo y formato deben definirse para un equipo de diseño antes de comenzar el trabajo de diseño. Un diseño se integra si el cuidado se toma en la definición de interfaces entre componentes de diseño.
• El diseño debe estructurarse para adaptarse al cambio. Los conceptos de diseño discutidos en la siguiente sección permiten un diseño para lograr este principio.
• El diseño debe estructurarse para degradar suavemente, incluso cuando se encuentran datos, eventos o condiciones de funcionamiento aberrantes. El software bien diseñado nunca debe "bomb"; debe ser diseñado para dar cabida a circunstancias inusuales, y si debe terminar el procesamiento, debe hacerlo de manera graciosa.
• El diseño no es codificación, codificación no es diseño. Incluso cuando se crean diseños de procedimiento detallados para los componentes del programa, el nivel de abstracción del modelo de diseño es más alto que el código fuente. Las únicas decisiones de diseño adoptadas a nivel de codificación deben abordar los pequeños detalles de la aplicación que permitan codificar el diseño de procedimiento.
• El diseño debe ser evaluado para la calidad como se está creando, no después del hecho. Existen diversos conceptos de diseño y medidas de diseño para ayudar al diseñador a evaluar la calidad a lo largo del proceso de desarrollo.
• El diseño debe ser revisado para minimizar errores conceptuales (semánticos). A veces hay tendencia a centrarse en las minutiae cuando se revisa el diseño, faltando el bosque para los árboles. Un equipo de diseño debe asegurarse de que se hayan abordado los principales elementos conceptuales del diseño (omisiones, ambigüedad, inconsistencia) 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 a partir de la cual se pueden aplicar métodos más sofisticados. Ha evolucionado un conjunto de conceptos de diseño fundamentales. Son los siguientes:

1. 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 con el fin de retener solamente información relevante para un propósito particular. Es un acto de Representar características esenciales sin incluir los detalles de fondo o explicaciones.
2. Refinement - Es el proceso de elaboración. Una jerarquía se desarrolla descomponiendo una declaración macroscópica de función de manera gradual hasta que se alcancen las declaraciones de lenguaje de programación. En cada paso, una o varias instrucciones de un programa dado se descomponen en instrucciones más detalladas. Abstracción y Refinement son conceptos complementarios.
3. Modularidad - La arquitectura del software se divide en componentes llamados módulos.
4. Arquitectura de software - Se refiere a la estructura general del software y las formas en que esa estructura proporciona integridad conceptual para un sistema. La buena arquitectura de software dará un buen rendimiento en la inversión con respecto al resultado deseado del proyecto, por ejemplo en términos de rendimiento, calidad, calendario y costo.
5. Hierarquía de control - Una estructura de programa que representa la organización de un componente de programa e implica una jerarquía de control.
6. Partición estructural - La estructura del programa puede dividirse tanto horizontal como verticalmente. Las particiones horizontales definen ramas separadas de jerarquía modular para cada función principal del programa. La partición vertical sugiere que el control y el trabajo deben ser distribuidos en la estructura del programa.
7. Estructura de datos - Es una representación de la relación lógica entre elementos individuales de datos.
8. Procedimiento de Software - Se centra en el procesamiento de cada módulo individualmente.
9. Información Contratación - Los módulos deben ser especificados y diseñados para que la información contenida en un módulo sea inaccesible a otros módulos que no tengan necesidad de dicha información.

En su modelo de objetos, Grady Booch menciona la abstracción, la encapsulación, la modularización y la jerarquía como principios fundamentales del diseño de software. El acrónimo PHAME (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 debe reflejar los objetivos y expectativas para los que se crea el software. Algunos de estos aspectos son:

• Compatibilidad - El software es capaz de operar con otros productos diseñados para la interoperabilidad con otro producto. Por ejemplo, un pedazo de software puede ser compatible con una versión anterior de sí mismo.
• Extensibilidad - Se pueden añadir nuevas capacidades al software sin cambios importantes en la arquitectura subyacente.
• Modularidad - el software resultante comprende componentes bien definidos e independientes que conducen a una mejor sostenibilidad. Los componentes podrían ser implementados y probados en forma aislada antes de ser integrados para formar un sistema de software deseado. Esto permite la división del trabajo en un proyecto de desarrollo de software.
• Fault-tolerance - El software es resistente y capaz de recuperarse de la falla del componente.
• Sostenibilidad - Una medida de cuán fácilmente se pueden realizar correcciones de errores o modificaciones funcionales. Alta mantenibilidad puede ser el producto de modularidad y extensibilidad.
• Confiabilidad (La durabilidad del software) - El software es capaz de realizar una función requerida en condiciones establecidas durante un período de tiempo determinado.
• Reutilización - La capacidad de utilizar algunos o todos los aspectos del software preexistente en otros proyectos con poca o ninguna modificación.
• Robustitud - El software es capaz de operar bajo estrés o tolerar entrada impredecible o inválida. Por ejemplo, puede diseñarse con resiliencia a condiciones de memoria bajas.
• Seguridad - El software es capaz de soportar y resistir actos hostiles e influencias.
• Usabilidad - La interfaz de usuario del software debe ser usable para su usuario/audiencia objetivo. Los valores predeterminados de los parámetros deben ser elegidos para que sean una buena elección para la mayoría de los usuarios.
• Ejecución - El software realiza sus tareas dentro de un marco de tiempo aceptable para el usuario, y no requiere demasiada memoria.
• Portabilidad - El software debe ser usable en varias condiciones y entornos diferentes.
• Escalabilidad - El software se adapta bien al aumento de datos o características adicionales o número de usuarios.

Lenguaje de modelado

Un lenguaje de modelado es cualquier lenguaje artificial que se puede utilizar para expresar información, conocimientos o sistemas en una estructura definida por un conjunto coherente de reglas. Estas reglas se utilizan para la interpretación de los componentes dentro de la estructura. Un lenguaje de modelado puede ser gráfico o textual. Ejemplos de lenguajes de modelado gráfico para el diseño de software son:

• El lenguaje de descripción de la arquitectura (ADL) es un lenguaje utilizado para describir y representar la arquitectura de software de un sistema de software.
• La notación de modelado de procesos empresariales (BPMN) es un ejemplo de un lenguaje de modelado de procesos.
• EXPRESS y EXPRESS-G (ISO 10303-11) es un lenguaje de modelado de datos estándar internacional.
• Extended Enterprise Modeling Language (EEML) es comúnmente utilizado para el modelado de procesos empresariales en varias capas.
• Los diagramas de flujo son representaciones esquemáticas de algoritmos u otros procesos escalonados.
• Conceptos fundamentales de modelado (FMC) es el lenguaje de modelado para sistemas intensivos en software.
• IDEF es una familia de idiomas de modelado, los más notables de los cuales incluyen IDEF0 para modelado funcional, IDEF1X para modelado de información, y IDEF5 para modelar ontologías.
• Jackson Structured Programming (JSP) es un método de programación estructurada basado en correspondencias entre la estructura de flujo de datos y la estructura del programa.
• LePUS3 es un diseño visual orientado a objetos Descripción Idioma y un lenguaje de especificación formal que es adecuado principalmente para modelar grandes programas orientados a objetos (Java, C++, C#) y patrones de diseño.
• Unified Modeling Language (UML) es un lenguaje de modelado general para describir el software tanto estructural como conductual. Tiene una notación gráfica y permite la extensión con un perfil (UML).
• La aleación (lengua específica) es un lenguaje de especificación de propósito general para expresar complejas limitaciones estructurales y comportamiento en un sistema de software. Proporciona una base de lenguaje concisa en la lógica relacional de primer orden.
• System Modeling Language (SysML) es un nuevo lenguaje de modelado de uso general para ingeniería de sistemas.
• Marco de modelado orientado al servicio (SOMF)

Patrones de diseño

Un diseñador o arquitecto de software puede identificar un problema de diseño que ha sido visitado y quizás incluso resuelto por otros en el pasado. Una plantilla o patrón que describe una solución a un problema común se conoce como patrón de diseño. La reutilización de dichos patrones puede ayudar a acelerar el proceso de desarrollo de software.

Técnica

La dificultad de usar el término "diseño" en relación con el software es que, en algunos sentidos, el código fuente de un programa es el diseño del programa que produce. En la medida en que esto sea cierto, el "diseño de software" se refiere al diseño del diseño. Edsger W. Dijkstra se refirió a esta superposición de niveles semánticos como la "novedad radical" de programación de computadoras, y Donald Knuth usó su experiencia escribiendo TeX para describir la inutilidad de intentar diseñar un programa antes de implementarlo:

T_EX habría sido un fracaso completo si lo hubiera especificado y no hubiera participado plenamente en su aplicación inicial. El proceso de aplicación me llevó constantemente a preguntas no anticipadas y a nuevas ideas sobre cómo podrían mejorarse las especificaciones originales.

Uso

La documentación de diseño de software puede revisarse o presentarse para permitir el ajuste de restricciones, especificaciones e incluso requisitos antes de la programación informática. El rediseño puede ocurrir después de la revisión de una simulación o prototipo programado. Es posible diseñar software en el proceso de programación, sin un plan o análisis de requisitos, pero para proyectos más complejos esto no se consideraría factible. Un diseño separado antes de la programación permite que diseñadores multidisciplinarios y expertos en la materia (SME) colaboren con programadores altamente calificados para un software que sea útil y técnicamente sólido.