Ingeniería del diseño

El término diseño admite varias significados. Así, el “diseño” puede ser una actividad, la “actividad de diseñar”, puede ser un producto, el “resultado de la actividad de diseñar”, o puede ser un calificativo, y en este sentido es muy común referirse a algo como “de diseño”, cuando aporta una geometría, una forma o unas cualidades diferenciadoras que implican un aire de calidad y distinción.^{[cita requerida]}

El término “diseño” viene de “diseñar”, que a su vez tiene su origen en el latín, designare, que en origen significa en trazar (un surco en la tierra) y también dibujar, marcar o designar. De hecho, la primera acepción del término diseño, en español, es “traza o delineación de una figura o un edificio”.^{[cita requerida]}

Pero el término admite también un significado amplio: “ordenación de los elementos básicos, tangibles e intangibles, de un objeto o estructura con el fin de aumentar su belleza o utilidad”.^{[cita requerida]}

De acuerdo con esta significación, el diseño aborda los “elementos básicos”, esto es, los más relevantes o fundamentales. La ordenación de los detalles correspondería a una parte del “diseño”, que sería el “diseño detallado”. También se debe apuntar que el diseño no conlleva necesariamente unas tareas de “cálculo” o de “dimensionamiento preciso”, tareas que sí formarían parte de un diseño detallado o de las propias de una ingeniería.^{[cita requerida]}

Por otro lado, el término “ingeniería”, del latín ingenium, se define como: “el arte de aplicar los conocimientos científicos a la invención, utilización o perfeccionamiento de la técnica en todas sus determinaciones”.^{[cita requerida]}

El diseño del software es un proceso interactivo mediante el cual los requerimientos se traducen en un “plano” para construir el software. Para lograr que un diseño sea presentable se deben seguir ciertas pautas.^{[cita requerida]}

• Implementar todos los requisitos explícitos contenidos en el modelo de análisis, y ajustarse a todos los requisitos del cliente.
• Debe ser una guía legible y comprensible para quienes generan el código y quienes realizan pruebas, es decir, dan soporte al software.
• Debe proporcionar una imagen completa del software desde una perspectiva de implementación.^{[cita requerida]}

• Un diseño debe presentar una estructura arquitectónica que se haya creado mediante patrones de diseño reconocibles, la integren componentes que exhiban buenas características de diseño y que pueda implementarse de manera evolutiva para que de estar forma facilite la implementación y las pruebas.
• Un diseño debe ser modular.
• Un diseño debe contener distintas representaciones de los datos, la arquitectura, las interfaces y los componentes.
• Un diseño debe conducir a estructuras de datos que sean apropiadas para las clases que habrán de implementarse y que procedan de patrones de datos reconocibles.
• Un diseño debe conducir a componentes que representan características funcionales independientes.
• Un diseño debe conducir a interfases que reduzcan la complejidad de las conexiones entre los componentes y el ambiente externo.
• Un diseño debe obtenerse por medio de un método repetible que se base en la información obtenida durante el análisis de requisitos del software.
• Un diseño debe representarse por medio de una notación que comunique de manera eficaz su significado.^{[cita requerida]}

• La funcionalidad
• La facilidad
• La confiabilidad
• El desempeño
• La soportabilidad, la adaptabilidad y la servicialidad^{[cita requerida]}

• La abstracción es una de las formas fundamentales en las que los humanos se enfrentan a la complejidad. La arquitectura es la estructura u organización de los componentes del programa módulos, la manera en que estos componentes interactúan, y la estructura de datos que utilizan los componentes.
• Los patrones describen una estructura de diseño que resuelve un problema de diseño particular dentro de un contexto específico y en medio de “fuerzas” que pueden tener un impacto en la manera en la que se aplica y utiliza el patrón, de manera tal que el diseñador pueda decidir si este es el necesario o el que puede usar para su trabajo actual.
• La modularidad, el software se divide en componentes con nombres independientes y que es posible maniobrar de forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del problema.
• La ocultación de la información sugiere que los módulos se caracterizan por las decisiones de diseño que oculta a los otros. En otras palabras el módulo debe diseñarse de forma que la información sea inaccesible para otro módulo que no necesite esta información.
• La independencia funcional surge como resultado de la suma directa de la modularidad y de los conceptos de abstracción y ocultación de información pues cada módulo del software debe ser capaz de funcionar por sí solo.^{[cita requerida]}

Refinamiento es un proceso de elaboración.

• Se inicia con el enunciado de una función o descripción de los datos que se define como un alto grado de abstracción.
• Este describe los datos o función de manera conceptual pero no proporciona información acerca de los trabajos internos de la función o estructura interna de los datos.
• El refinamiento hace que el diseñador trabaje sobre el enunciado original y que proporcione más y más detalles conforme se realiza cada refinamiento sucesivo.^{[cita requerida]}

Refabricación técnica de reorganización que simplifica el diseño (o código) de un componente sin cambiar su función o comportamiento, dicho de otra manera, "es el proceso de cambiar un sistema de software de tal forma que no altere el comportamiento externo de su código (diseño) y aun así se mejore su estructura interna".^{[cita requerida]}

• Arquitectónicos definen la estructura general del software, relaciones entre los subsistemas y los componentes de software, y las reglas para especificar las relaciones entre los elementos de la arquitectura.
• De diseño agregado de componentes que se aplica a un elemento específico para resolver problemas de diseño, relaciones.
• Idiomas (patrones de código) patrones específicos de lenguajes por lo general implementan un algoritmo, un protocolo de interfaz entre los componentes.^{[cita requerida]}

• Las clases de interfaz con el usuario definen las abstracciones necesarias para la interacción humano-computadora.
• Las clases del dominio de negocios proceso de refinamiento de las clases anteriores, donde se identifican los atributos y servicios necesarios para implementar algún elemento del dominio de negocios.
• Las clases del proceso implementan abstracciones del negocio en un nivel más bajo, las cuales se requieren para el manejo de las clases del dominio de negocio.
• Las clases persistentes representan almacenamientos de datos que persistirán más allá de la ejecución el software.
• Las clases de sistema implementan las funciones que permite que el sistema opere y se comunique dentro de su entorno de computación y con el mundo exterior.^{[cita requerida]}

• Completa y suficiente una clase de diseño debe ser la encapsulación completa de todos los atributos y métodos que se pueden esperar, en forma razonable, que existan para la clase, es decir, que debe contener los métodos aquellos que sean suficientes para lograr el objetivo ni más ni menos.
• Primitivismo, los métodos asociados a una clase de diseño deben enfocarse en el cumplimiento de un servicio para la clase. Una vez que el servicio ha sido implementado con un método, la clase no debe proporcionar otra forma de complementar la misma.
• Cohesión alta, una clase de diseño cohesiva tiene un conjunto de responsabilidades pequeño y enfocado, y aplica atributos y métodos de manera sencilla para implementar dichas responsabilidades.
• Acoplamiento bajo dentro del modelo de diseño es necesario que las clases de diseño colaboren con alguna otra. Sin embargo, la colaboración se debe mantener en un mínimo aceptable. Si un modelo de diseño tiene un acoplamiento alto, el sistema es difícil de implementar, probar y mantener a través del tiempo. En general las clases de diseño dentro de un subsistema deben tener solo un conocimiento limitado de las clases en otros subsistemas. Esta restricción, llamada la Ley de Deméter, sugiere que un método solo debe enviar mensajes a métodos de clases vecinas.^{[cita requerida]}

Indican cómo se ubicarán las funcionalidad y los subsistemas dentro del entorno computacional físico que soportará al software.^{[cita requerida]}