Proceso de planificación de soluciones de software.
El diseño de software es el proceso de conceptualizar cómo funcionará un sistema de software antes de implementarlo o modificarlo. [1]
El diseño de software también se refiere al resultado directo del proceso de diseño: los conceptos de cómo funcionará el software, que consisten tanto en documentación de diseño como en conceptos no documentados.
El diseño de software generalmente está dirigido por objetivos para el sistema resultante e implica planificación y resolución de problemas, incluida tanto la arquitectura de software de alto nivel como el diseño de algoritmos y componentes de bajo nivel .
En términos del proceso de desarrollo en cascada , el diseño de software es la actividad que sigue la especificación de requisitos y antes de codificar . [2]
Proceso general
El proceso de diseño permite al diseñador modelar varios aspectos de un sistema de software antes de que exista.
La creatividad, la experiencia pasada, el sentido de lo que constituye un "buen" software y el compromiso con la calidad son factores de éxito para un diseño competente. Sin embargo, el proceso de diseño no siempre es un procedimiento sencillo.
El modelo de diseño de software se puede comparar con un plano arquitectónico de una casa. Los planos de alto nivel representan la totalidad de la casa (por ejemplo, una representación tridimensional de la casa). Los planos de nivel inferior brindan orientación para construir cada detalle (por ejemplo, la instalación de plomería). De manera similar, el modelo de diseño de software proporciona una variedad de vistas de la solución de software propuesta.
Valor
La documentación de diseño de software se puede revisar o presentar para permitir que se ajusten las restricciones, especificaciones e incluso requisitos antes de la codificación . 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 codificación, sin un plan o análisis de requisitos, [3] pero para proyectos más complejos esto es menos factible. Un diseño separado antes de la codificación permite a los diseñadores multidisciplinarios y expertos en la materia (PYME) colaborar con los programadores para producir software que sea útil y técnicamente sólido.
Análisis de requerimientos
Un componente del diseño de software es el análisis de requisitos de software (SRA). SRA es parte del proceso de desarrollo de software que enumera las especificaciones utilizadas en ingeniería de software .
El resultado del análisis son problemas más pequeños a resolver. Por el contrario, el diseño se centra en las capacidades y, por tanto, pueden existir múltiples diseños para el mismo problema. Dependiendo del 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 .
Artefactos
Un proceso de diseño puede incluir la producción de artefactos tales como diagramas de flujo , casos de uso , pseudocódigo , modelo de lenguaje de modelado unificado y otros conceptos fundamentales de modelado . Para el software centrado en el usuario , el diseño puede implicar un diseño de la experiencia del usuario que genere un guión gráfico para ayudar a determinar esas especificaciones.
A veces el resultado de un proceso de diseño es la documentación del diseño .
Criterios de diseño
Los principios básicos de diseño permiten a un ingeniero de software navegar por el proceso de diseño. Davis [4] 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 debería sufrir la "visión de túnel". Un buen diseñador debe considerar enfoques alternativos, juzgando cada uno de ellos en función de los requisitos del problema y los recursos disponibles para realizar el trabajo.
- El diseño debe ser trazable hasta el modelo de análisis. Debido a que un solo elemento del modelo de diseño a menudo se puede rastrear hasta múltiples requisitos, es necesario tener un medio para rastrear cómo el modelo de diseño ha satisfecho los requisitos.
- El diseño no debería reinventar la rueda. Los sistemas se construyen utilizando un conjunto de patrones de diseño, muchos de los cuales probablemente ya se hayan encontrado antes. Estos patrones siempre deben elegirse como una alternativa a la reinvención. El tiempo es corto y los recursos limitados; Se debe invertir tiempo de diseño en representar ideas (verdaderamente nuevas) mediante la integración de patrones que ya existen (cuando corresponda).
- El diseño debe "minimizar la distancia intelectual" entre el software y el problema tal como existe en el mundo real. Es decir, la estructura del diseño del software debe, siempre que sea posible, imitar la estructura del dominio del problema.
- El diseño debe exhibir uniformidad e integración. Un diseño es uniforme si parece totalmente coherente. Para lograr este resultado, se deben definir reglas de estilo y formato para un equipo de diseño antes de comenzar el trabajo de diseño. Un diseño está integrado si se tiene cuidado al definir las interfaces entre los componentes del diseño.
- El diseño debe estructurarse para adaptarse al cambio. Los conceptos de diseño discutidos en la siguiente sección permiten que un diseño logre este principio.
- El diseño debe estructurarse para degradarse suavemente, incluso cuando se encuentren datos, eventos o condiciones operativas aberrantes. El software bien diseñado nunca debería "bombardear"; debe estar diseñado para adaptarse a circunstancias inusuales y, si debe finalizar el procesamiento, debe hacerlo de manera elegante.
- Diseño no es codificación, codificación no es diseño. Incluso cuando se crean diseños de procedimientos detallados para los componentes del programa, el nivel de abstracción del modelo de diseño es mayor que el del código fuente. Las únicas decisiones de diseño tomadas a nivel de codificación deben abordar los pequeños detalles de implementación que permiten codificar el diseño del procedimiento.
- La calidad del diseño debe evaluarse mientras se crea, no después del hecho. Se encuentran disponibles una variedad de conceptos de diseño y medidas de diseño para ayudar al diseñador a evaluar la calidad durante todo el proceso de desarrollo.
- El diseño debe revisarse para minimizar los errores conceptuales (semánticos). A veces hay una tendencia a centrarse en las minucias cuando se revisa el diseño, omitiendo el bosque por 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 una base a partir de la cual se pueden aplicar métodos más sofisticados. Ha evolucionado un conjunto de conceptos de diseño que incluyen:
- Abstracción : la abstracción es el proceso o resultado de la generalización mediante la reducción del contenido de información de un concepto o un fenómeno observable, generalmente para retener solo información que sea relevante para un propósito particular. Es un acto de Representar características esenciales sin incluir detalles ni explicaciones de fondo.
- Refinamiento - Es el proceso de elaboración. Una jerarquía se desarrolla descomponiendo una declaración macroscópica de función paso a paso hasta llegar a las declaraciones del lenguaje de programación. En cada paso, una o varias instrucciones de un programa determinado se descomponen en instrucciones más detalladas. Abstracción y Refinamiento son conceptos complementarios.
- Modularidad : la arquitectura del software se divide en componentes llamados módulos.
- Arquitectura de software : se refiere a la estructura general del software y las formas en que esa estructura proporciona integridad conceptual a un sistema. Una buena arquitectura de software producirá un buen retorno de la inversión con respecto al resultado deseado del proyecto, por ejemplo en términos de rendimiento, calidad, cronograma y costo.
- Jerarquía de control: estructura de programa que representa la organización de un componente del programa e implica una jerarquía de control.
- Partición estructural: la estructura del programa se puede dividir horizontal y verticalmente. Las particiones horizontales definen ramas separadas de la jerarquía modular para cada función principal del programa. La partición vertical sugiere que el control y el trabajo deben distribuirse de arriba hacia abajo en la estructura del programa.
- Estructura de datos : es una representación de la relación lógica entre elementos individuales de datos.
- Procedimiento de software: se centra en el procesamiento de cada módulo individualmente.
- Ocultación de información : los módulos deben especificarse y diseñarse de manera que la información contenida en un módulo sea inaccesible para otros módulos que no la necesitan.
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. [5] El acrónimo PHAME (Principios de Jerarquía, Abstracción, Modularización y Encapsulación) se utiliza a veces para referirse a estos cuatro principios fundamentales. [6]
Consideraciones de diseño
Hay muchos aspectos a considerar en el diseño de un software. La importancia de cada consideración debe reflejar los objetivos y expectativas para los cuales se está creando el software. Algunos de estos aspectos son:
- Compatibilidad: el software puede funcionar con otros productos diseñados para la interoperabilidad con otro producto. Por ejemplo, una pieza de software puede ser compatible con una versión anterior de sí misma.
- Extensibilidad : se pueden agregar nuevas capacidades al software sin cambios importantes en la arquitectura subyacente.
- Modularidad : el software resultante comprende componentes independientes y bien definidos, lo que conduce a una mejor mantenibilidad. Luego, los componentes podrían implementarse y probarse de forma aislada antes de integrarse para formar el sistema de software deseado. Esto permite la división del trabajo en un proyecto de desarrollo de software.
- Tolerancia a fallos : el software es resistente y capaz de recuperarse de fallos de componentes.
- Mantenibilidad : una medida de la facilidad con la que se pueden lograr correcciones de errores o modificaciones funcionales. La alta mantenibilidad puede ser producto de la modularidad y la extensibilidad.
- Fiabilidad ( durabilidad del software ): el software es capaz de realizar una función requerida en las condiciones establecidas durante un período de tiempo específico.
- Reutilizabilidad : la capacidad de utilizar algunos o todos los aspectos del software preexistente en otros proyectos con poca o ninguna modificación.
- Robustez : el software es capaz de funcionar bajo estrés o tolerar entradas impredecibles o no válidas. Por ejemplo, se puede diseñar con resiliencia ante condiciones de poca memoria.
- Seguridad : el software es capaz de soportar y resistir actos e influencias hostiles.
- Usabilidad : la interfaz de usuario del software debe ser utilizable para el usuario/audiencia objetivo. Se deben elegir valores predeterminados para los parámetros de modo que sean una buena opción para la mayoría de los usuarios. [7]
- Rendimiento : el software realiza sus tareas dentro de un plazo aceptable para el usuario y no requiere demasiada memoria.
- Portabilidad : el software debe poder utilizarse en diversas condiciones y entornos diferentes.
- Escalabilidad : el software se adapta bien al aumento de datos, funciones adicionales o número de usuarios.
Lenguaje de modelado
Un lenguaje de modelado se puede utilizar para expresar información, conocimiento o sistemas en una estructura definida por un conjunto consistente 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 diseño de software incluyen:
Patrones de diseño
Un diseñador de software puede identificar un aspecto del diseño que otros han visitado y quizás incluso resuelto 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 aumentar la velocidad de desarrollo de software. [9]
Código como diseño
La dificultad de utilizar el término "diseño" en relación con el software es que, en cierto sentido, el código fuente de un programa es el diseño del programa que produce. En la medida en que esto sea cierto, "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 la programación informática, [10] y Donald Knuth utilizó su experiencia escribiendo TeX para describir la inutilidad de intentar diseñar un programa antes de implementarlo:
T E X habría sido un completo fracaso si simplemente lo hubiera especificado y no hubiera participado plenamente en su implementación inicial. El proceso de implementación me llevó constantemente a preguntas imprevistas y a nuevos conocimientos sobre cómo se podrían mejorar las especificaciones originales. [11]
Ver también
Wikimedia Commons tiene medios relacionados con el diseño de software .
Referencias
- ^ Ralph, P. y Wand, Y. (2009). Una propuesta para una definición formal del concepto de diseño. En Lyytinen, K., Loucopoulos, P., Mylopoulos, J. y Robinson, W., editores, Taller de requisitos de diseño (LNBIP 14), págs. Springer-Verlag, pág. 109 doi :10.1007/978-3-540-92966-6_6.
- ^ Hombre libre, Peter; David Hart (2004). "Una ciencia del diseño de sistemas intensivos en software". Comunicaciones de la ACM . 47 (8): 19-21 [20]. doi :10.1145/1012037.1012054. S2CID 14331332.
- ^ Ralph, P. y Wand, Y. Una propuesta para una definición formal del concepto de diseño. En Lyytinen, K., Loucopoulos, P., Mylopoulos, J. y Robinson, W., (eds.), Ingeniería de requisitos de diseño: una perspectiva de diez años: Springer-Verlag, 2009, págs. 103-136
- ^ Davis, A: "201 principios de desarrollo de software", McGraw Hill, 1995.
- ^ Booch, Grady; et al. (2004). Análisis y diseño orientado a objetos con aplicaciones (3ª ed.). MA, Estados Unidos: Addison Wesley. ISBN 0-201-89551-X. Consultado el 30 de enero de 2015 .
- ^ Suryanarayana, Girish (noviembre de 2014). "Refactorización para olores de diseño de software ". Morgan Kaufman. pag. 258.ISBN 978-0128013977.
- ^ Carroll, John, ed. (1995). Diseño basado en escenarios: visión del trabajo y la tecnología en el desarrollo de sistemas . Nueva York: John Wiley & Sons. ISBN 0471076597.
- ^ Campana, Michael (2008). "Introducción al modelado orientado a servicios". Modelado orientado a servicios: análisis, diseño y arquitectura de servicios . Wiley e hijos. ISBN 978-0-470-14111-3.
- ^ Judith Obispo. "Patrones de diseño de C# 3.0: utilice el poder de C# 3.0 para resolver problemas del mundo real". Libros de C# de O'Reilly Media . Consultado el 15 de mayo de 2012 .
Si desea acelerar el desarrollo de sus aplicaciones .NET, está preparado para los patrones de diseño de C#: formas elegantes, aceptadas y comprobadas de abordar problemas de programación comunes.
- ^ Dijkstra, EW (1988). "Sobre la crueldad de enseñar realmente ciencias de la computación" . Consultado el 10 de enero de 2014 .
- ^ Knuth, Donald E. (1989). "Notas sobre los errores de TeX" (PDF) .
^ Roger S. Pressman (2001). Ingeniería de software: el enfoque de un profesional . McGraw-Hill. ISBN 0-07-365578-3.
