Diseño de software

Ir a: navegación, búsqueda de
Proceso de desarrollo de software
Actividades básicas
  • Requisitos
  • Diseño
  • Construcción
  • Prueba
  • Depuración de
  • Implementación
  • Mantenimiento
Paradigmas y modelos
  • Ingeniería de software
  • Cascada
  • Creación de prototipos
  • Incremental
  • Modelo V
  • Modelo de la doble uve
  • Espiral
  • IID
  • Ágil
  • Lean
  • DevOps
Metodologías y marcos
  • Sala blanca
  • TSP
  • PSP
  • RAD
  • DSDM
  • MSF
  • Scrum
  • Kanban
  • UP
  • XP
  • TDD
  • ATDD
  • BDD
  • FDD
  • DDD
  • MDD
Disciplinas de apoyo
  • Gestión de la configuración
  • Infraestructura como código
  • Documentación
  • Aseguramiento de la calidad del software (SQA)
  • Gestión de proyectos
  • Experiencia de usuario
Herramientas
  • Compilador de
  • Depurador de
  • Generador de perfiles
  • Diseñador de GUI
  • Modelado
  • IDE
  • Construir la automatización
  • Automatización de liberación
  • Prueba
Normas y BOKs
  • CMMI
  • Estándares IEEE
  • ISO 9001
  • Normas ISO/IEC
  • SWEBOK
  • PMBOK
  • BABOK
  • v
  • t
  • e

Diseño de software es el proceso por el cual un agente crea una especificación de un artefacto de software, pretende lograr objetivos, utilizando un conjunto de componentes primitivos y sujeto a limitaciones de.[1] Diseño de software puede referirse a "todas las actividades involucradas en la conceptualización, estructura, implementación, puesta en marcha y, en definitiva, modificación de sistemas complejos" o "la actividad después de requisitos Especificación y antes de programación, como... [en] un proceso de ingeniería del software estilizado".[2]

Diseño de software generalmente implica la resolución de problemas y planificación de un software solución. Esto incluye tanto un componente de bajo nivel y diseño de algoritmos y un alto nivel, arquitectura diseño.

Contenido

  • 1 Resumen
    • 1.1 Conceptos de diseño
    • 1.2 Consideraciones de diseño
    • 1.3 Lenguaje de modelado
    • 1.4 Patrones de diseño
    • 1.5 Técnica
    • 1.6 Uso
  • 2 Véase también
  • 3 Referencias

Resumen

Diseño de software es el proceso de implementación de soluciones de software a uno o más conjuntos de problemas. Uno de los principales componentes de diseño de software es la Análisis de requerimientos del software (SRA). SRA es una parte de la proceso de desarrollo de software se enumeran Especificaciones utilizado en Ingeniería de software. Si el software es "semiautomático" o centrado en el usuario, diseño de software puede involucrar diseño de experiencia de usuario obtención de un guión gráfico para determinar dichas especificaciones. Si el software es completamente automatizado de (es decir, no usuario o interfaz de usuario), un diseño de software puede ser tan simple como una diagrama de flujo texto que describe una secuencia planeada de eventos o También hay métodos semi estándar como Unificado modelando lengua y Conceptos fundamentales del modelado. En cualquier caso, algunos documentación del plan es generalmente el producto del diseño. Además, puede ser un diseño de software independiente de la plataforma o específicas de la plataforma, dependiendo de la disponibilidad de la tecnología utilizada para el diseño.

La principal diferencia entre el software de análisis y diseño es que la salida de un software de análisis consiste en pequeños problemas a resolver. Además, el análisis debe no ser diseñado muy diferentemente a través de diferentes integrantes o grupos. En cambio, el diseño se centra en las capacidades, y así múltiples diseños para el mismo problema puede y va a existir. Dependiendo del entorno, el diseño a menudo varía, si se crea de confiable Marcos o implementadas con adecuado patrones de diseño. Ejemplos de diseño incluyen sistemas operativos, páginas web, dispositivos móviles o incluso el nueva nube paradigma de computación.

Diseño de software es un proceso y 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, la experiencia, un sentido de lo que hace el software "buena", y un compromiso total con la calidad son ejemplos de factores críticos de éxito para un diseño competente. Es importante señalar, sin embargo, que el proceso de diseño no siempre es un procedimiento sencillo; el modelo de diseño puede compararse a los planes del arquitecto para una casa. Comienza por la representación de la totalidad de lo que debe ser construido (por ejemplo, una representación tridimensional de la casa); poco a poco, la cosa es refined a servir de guía para la construcción de cada detalle (por ejemplo, el diseño de plomería). Del mismo modo, el modelo de diseño que se crea para el software ofrece una variedad de diferentes puntos de vista de los programas informáticos. Principios de diseño básicos permiten que el ingeniero de software navegar el proceso de diseño. Davis [DAV95][completo cita requerida] sugiere un conjunto de principios para el diseño de software, que se han adaptado y extendido en la siguiente lista:

  • El proceso de diseño no debe sufrir de "visión de túnel". Un buen diseñador debe considerar enfoques alternativos, juzgar a que cada uno según los requerimientos del problema, los recursos disponibles para hacer el trabajo.
  • El diseño debe ser rastreable en el modelo de análisis. Porque un solo elemento del modelo de diseño a menudo se remonta a múltiples requerimientos, es necesario tener un medio para el seguimiento de 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, es probable que muchos de los cuales se han encontrado antes. Estos patrones siempre deben ser elegidos como alternativa a la reinvención. El tiempo apremia y los recursos son limitados; tiempo de diseño debe invertirse en representación realmente nuevas ideas y la integración de patrones que ya existen en su caso.
  • El diseño debe "minimizar la distancia intelectual" entre el software y el problema que existe en el mundo real. Es decir, la estructura del diseño de software debería, en la medida de lo 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, reglas de estilo y formato deben ser definido por un equipo de diseño antes de comenzar el trabajo de diseño. Un diseño se integra si se tiene cuidado en la definición de interfaces entre los componentes de diseño.
  • El diseño debe ser estructurado para acomodar el cambio. Los conceptos de diseño en la siguiente sección permiten un diseño alcanzar este principio.
  • El diseño debe ser estructurado para degradar suavemente, incluso cuando aberrante datos, eventos, o condiciones de funcionamiento se encuentran. Software bien diseñado no debe nunca "bomba"; debe ser diseñado para acomodar circunstancias inusuales, y si debe terminar proceso, deben hacerlo de una manera elegante.
  • Diseño no es de codificación, la codificación no es diseño. Incluso cuando se crean diseños procesales detallados para los componentes del programa, el nivel de abstracción del modelo de diseño es mayor que el código fuente. Las decisiones de diseño único en el nivel de codificación deben abordar los detalles de implementación pequeños que permiten el diseño procesal que se cifrarán.
  • El diseño debe evaluarse para la calidad que se está creando, no después del hecho. Una variedad de conceptos de diseño y medidas del diseño está disponible para ayudar al diseñador en la evaluación de la calidad durante el proceso de desarrollo.
  • El diseño debe revisarse para minimizar los errores conceptuales de (semánticas). A veces hay una tendencia a centrarse en minucias cuando se repasa el diseño, falta el bosque por los árboles. Un equipo de diseño debe asegurar que los principales elementos conceptuales del diseño (omisión, ambigüedad, inconsistencia) han sido abordados antes de preocuparse por la sintaxis del modelo de diseño.

Conceptos de diseño

Los conceptos de diseño proporcionan el diseñador de software con una base de la cual pueden aplicarse métodos más sofisticados. Se ha desarrollado un conjunto de conceptos de diseño fundamentales. Son los siguientes:

  1. Abstracción -La abstracción es el proceso o el resultado de la generalización reduciendo el contenido de la información de un concepto o un fenómeno observable, por lo general para retener solamente la información que es relevante para un propósito en particular.
  2. Refinamiento -Es el proceso de elaboración. Se desarrolla una jerarquía descomponiendo una declaración macroscópica de la función en un método escalonado hasta llegar 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 refinamiento son conceptos complementarios.
  3. Modularidad -Arquitectura el software se divide en componentes llamados módulos.
  4. Arquitectura de software -Se refiere a la estructura global del software y de las formas en que esa estructura proporciona la integridad conceptual para un sistema de. Arquitectura de software buena dará un buen retorno de la inversión en relación con el resultado deseado del proyecto, por ejemplo, en términos de rendimiento, calidad, horario y costo.
  5. Jerarquía de controles -Una estructura de programa que representa la organización de un componente e implica una jerarquía de control.
  6. Compartimentación estructural -La estructura del programa se puede dividir tanto horizontal como verticalmente. Particiones horizontales definen distintas ramas de la jerarquía modular para cada función importante programa. Partición vertical sugiere que control y trabajo deben ser distribuido más abajo 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. Ocultamiento de información -Módulos deben ser especificados y diseñados para que la información contenida dentro de un módulo sea inaccesible a otros módulos que no tienen necesidad de dicha información.

En su modelo de objetos, Booch Grady menciona abstracción, encapsulación, modularización y jerarquía como principios fundamentales de diseño.[3] El acrónimo PHAME (principios de jerarquía, abstracción, modularización y encapsulado) se utiliza a veces para referirse a estos cuatro principios fundamentales.[4]

Consideraciones de diseño

Hay muchos aspectos a considerar en el diseño de una pieza de software. La importancia de cada cuenta debe reflejar los objetivos y las expectativas de que el software está creado para satisfacer. Algunos de estos aspectos son:

  • Compatibilidad -El software es capaz de operar con otros productos que están diseñados para la interoperabilidad con otro producto. Por ejemplo, una pieza de software puede ser compatible hacia atrás con una más vieja versión de sí mismo.
  • Extensibilidad de -Nuevas capacidades se pueden agregar al software sin cambios importantes en la arquitectura subyacente.
  • Modularidad -el software resultante comprende componentes bien definidos, independientes, que conduce a mejor mantenibilidad. Los componentes podrían ser implementados y probados en el aislamiento antes de integrarse para formar un sistema de software deseado. Esto permite la división del trabajo en un proyecto de desarrollo de software.
  • Tolerancia a fallos -El software es capaz de recuperarse de fallas de los componentes y resistente a la.
  • Capacidad de mantenimiento -Una medida de cuán fácilmente pueden realizar correcciones o modificaciones funcionales. Alta mantenibilidad puede ser el producto de modularidad y extensibilidad.
  • Fiabilidad (Durabilidad de software)-El software es capaz de realizar una función requerida bajo condiciones indicadas por un período especificado de tiempo.
  • Reutilización -La habilidad de usar algunos o todos los aspectos del software preexistente en otros proyectos con poca o ninguna modificación.
  • Robustez -El software es capaz de operar bajo estrés o tolerar la entrada impredecible o no es válida. Por ejemplo, puede ser diseñado con una resistencia a las condiciones de memoria baja.
  • Seguridad -El software es capaz de soportar y resistir influencias y actos hostiles.
  • Facilidad de uso -El software interfaz de usuario debe ser usable para su usuario de público. Valores predeterminados para los parámetros deben ser elegidos para que sean una buena opción para la mayoría de los usuarios.[5]
  • Rendimiento -El software realiza sus tareas dentro de un marco de tiempo aceptable para el usuario, y no requiere demasiada memoria.
  • Portabilidad -El software debería ser utilizable a través de un número de diferentes condiciones y ambientes.
  • Escalabilidad -El software se adapta bien al creciente número de usuarios o datos.

Lenguaje de modelado

A lenguaje de modelado es cualquier lenguaje artificial que puede utilizarse para expresar información, conocimiento o sistemas en una estructura que se define 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 diseño de software son:

  • Lenguaje de descripción de arquitectura (ADL) es un lenguaje utilizado para describir y representar la arquitectura de software de una sistema de software.
  • Notación de modelado de proceso empresarial (BPMN) es un ejemplo de un Modelado de procesos lengua.
  • EXPRESS y EXPRESS-G (ISO 10303-11) es un estándar internacional de uso general modelado de datos lengua.
  • Lenguaje de modelado de empresa extendida (EEML) se utiliza comúnmente para procesos de negocio a través de una serie de capas.
  • Diagrama de flujo es una representación esquemática de un algoritmo o proceso paso a paso.
  • Conceptos fundamentales del modelado (FMC) es lenguaje de sistemas intensivos en software de modelado.
  • IDEF es una familia de lenguajes, son las más notables de modelado IDEF0 para el modelado funcional, IDEF1X para el modelado de información, y IDEF5 para el modelado ontologías.
  • Programación estructurada de Jackson (JSP) es un método de programación estructurada basada en correspondencias entre estructura de flujo de datos y estructura del programa.
  • LePUS3 es un orientado a objetos Lenguaje de descripción de diseño visual y un Especificación formal lenguaje que es conveniente sobre todo para el modelado de grandes (orientado a objetosJava, C++, C#) los programas y patrones de diseño.
  • Unificado modelando lengua (UML) es un lenguaje de modelamiento general para describir software tanto estructural como de comportamiento. Tiene una notación gráfica y permite la extensión con una Perfil (UML).
  • Aleación (lenguaje de especificación) es un lenguaje de especificación de propósito general para expresar complejas limitaciones estructurales y comportamiento en un sistema de software. Proporciona un lenguaje conciso base lógica relacional de primer orden.
  • Lenguaje de modelado de sistemas (SysML) es un nuevo modelado de propósito general lenguaje para ingeniería de sistemas.
  • Modelar servicio-orientado marco (SOMF)[6]

Patrones de diseño

Un diseñador de software o un arquitecto puede identificar un problema de diseño que ha sido visitado y tal vez 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 un patrón de diseño. La reutilización de estos patrones puede ayudar a acelerar el proceso de desarrollo de software.[7]

Técnica

La dificultad de usar el término "diseño" en relación con software es en algunos sentidos, el código fuente de un programa is el diseño del programa que produce. En la medida en que esto es cierto, "diseño de software" se refiere al diseño del diseño. Edsger W. Dijkstra que se refiere a esta estratificación de niveles semánticos como la "novedad radical" de programación,[8] y Donald Knuth utiliza su experiencia de escritura TeX para describir la inutilidad de tratar de diseñar un programa antes de aplicarlo:

TEX habría sido un completo fracaso si había simplemente lo especificado y no participó plenamente en su implementación inicial. El proceso de ejecución constantemente me llevó a preguntas imprevistas y nuevas ideas sobre cómo mejorar las especificaciones originales.[9]

Uso

Documentación del software de diseño puede ser revisado o presentado para permitir que las limitaciones, especificaciones y requisitos incluso para ajustarse antes programación informática. Rediseño puede ocurrir después de la revisión de un programado simulación o prototipo. Es posible para el software de diseño en el proceso de programación, sin un plan o requisito de análisis,[10] pero para proyectos más complejos esto no se consideraría factible. Permite un diseño antes de la programación multidisciplinario diseñadores y Expertos en materia (PYMES) para colaborar con los programadores altamente cualificados para el software que es útil y técnico de sonido.

Véase también

  • Desarrollo de software orientado a aspectos
  • Licenciatura en tecnología de la información
  • Fundamentos de diseño
  • Diseño de interacción
  • Diseño de icono
  • Ingeniería de software basada en búsqueda
  • Descripción de software de diseño (IEEE 1016)
  • Desarrollo de software
  • Experiencia de usuario
  • Diseño de interfaz de usuario
  • Cero uno infinito

Referencias

  1. ^ Ralph, P. y vara, 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 diseño de requisitos (LNBIP 14), pp. 103-136. Springer-Verlag, p. 109 doi:10.1007/978-3-540-92966-6_6.
  2. ^ Freeman, Peter; David Hart (2004). "Una ciencia de diseño para sistemas intensivos en software". Comunicaciones del ACM. 47 (8): 19 – 21 [20]. doi:10.1145/1012037.1012054. 
  3. ^ Booch, Grady; et al (2004). Análisis orientado a objetos y diseño con aplicaciones (3ª Ed.). MA, Estados UNIDOS: Addison Wesley. ISBN 0-201-89551-X. 30 de enero 2015. 
  4. ^ Suryanarayana, Girish (noviembre de 2014). Huele a refactorización para diseño de Software. Morgan Kaufmann. p. 258. ISBN 978-0128013977. 31 de enero 2015. 
  5. ^ Carroll, ed., John (1995). Diseño basado en escenarios: Visualización trabajo y tecnología en el desarrollo del sistema. Nueva York: John Wiley & Sons. ISBN 0471076597. 
  6. ^ Bell, Michael (2008). "Introducción a la modelación orientada a servicios". Modelado orientada a servicios: Servicio de análisis, diseño y arquitectura. Wiley & Sons. ISBN 978-0-470-14111-3. 
  7. ^ Judith de Bishop. "C# 3.0 Design Patterns: usar el poder de C# 3.0 para solucionar problemas del mundo Real". C# libros de o ' Reilly Media. 2012-05-15. Si usted quiere acelerar el desarrollo de sus aplicaciones. net, usted está listo para C# patrones de diseño, elegante, aceptados y probadas formas de afrontar problemas comunes de programación. 
  8. ^ Dijkstra, E. W. (1988). "sobre la crueldad de verdaderamente enseñar ciencias de la computación". 2014-01-10. 
  9. ^ Knuth, Donald E. (1989). "Notas sobre los errores de TeX" (PDF). 
  10. ^ Ralph, P. y varilla, Y. Una propuesta para una definición Formal del concepto de diseño. En Lyytinen, K., Loucopoulos, P., Mylopoulos, J., y Robinson, w el., (eds.), requisitos de diseño Ingeniería: una perspectiva de diez años: Springer-Verlag, 2009, pp. 103-136

^Roger S. Pressman. Ingeniería de software: enfoque del practicante. McGraw-Hill. ISBN 0-07-365578-3. 

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Software_design&oldid=745320891"