Luis Manuel Moreno García Diseño de Software

11-2-2020 Actividad 1
Resumen

Capitulo 2. “The Software Desing Process”

Autor: David Budgen.

Idea central:

• El capitulo nos habla de lo que es el “Software”, la

complejidad de los procesos de construcción de
modelos para sistemas de software, así como el
comportamiento dinámico del sistema eventual, la
influencia de la naturaleza invisible del software y la
necesidad del conocimiento del dominio por parte
del diseñador.

Facilitador: Ana Luz Polo Estrella

Experiencia Educativa: Diseño de Software

Referencia completa: David Budgen. (2003). The

Software Design Process. Software Design. (pp. 25-43).
Inglaterra: Pearson Education Limited.

Luis Manuel Moreno García

UNIVERSIDAD VERACRUZANA
 Resumen
The Software Design Process

¿Qué es el software?
A mediados de la década de 1970 se consideraba que el software abarcaba
todos los formularios relacionados con la generación de ‘código binario de
tabla' que estaba destinado a ejecutarse en una sola máquina. Después, en esta
misma década, la idea de que las tareas informáticas podrían distribuirse en
múltiples se había agregado a las computadoras, con la posibilidad adicional de
cambiar los enlaces entre estos en tiempo de ejecución. Si bien este desarrollo
podría considerarse en gran medida como una variación en los detalles de
implementación, por supuesto, influyó en el pensamiento de los diseñadores de
tales sistemas.

En la década de 1990 en particular, el desarrollo de Internet ha agregado

muchos nuevos parámetros. Al mismo tiempo, la adición de formularios
'scripting' como HTML y XML han ampliado aún más nuestras ideas sobre las
formas que podría tomar el "software".

De alguna manera, el efecto de estos desarrollos sobre el pensamiento de

diseño probablemente ha sido menos de lo esperado. El único factor que estos
desarrollos han resaltado particularmente, y el único que las prácticas de diseño
existentes (incluidas muchas descritas en este libro) han sido menos exitoso en
abordar, es la continua demanda de una entrega más rápida de los sistemas.
Una característica del buen diseño es que, dado el debido cuidado para
preservar su estructura, un el sistema se puede ampliar y modificar sin dañar
otras características como tiempo de respuesta, fiabilidad y consistencia. Una
forma de lograr una entrega más rápida de los sistemas a sus usuarios es
emplear un nivel de abstracción en términos de lo que pensamos como
'software’. En la década de 1970, tal paso se logró al pasar de escribir programas
usando código de ensamblador específico de la máquina para escribirlos en
'idiomas de alto orden'. Esto los liberó de la dependencia de una marca y tipo
en particular de computadora y también permitió una producción más rápida
de código.
Modelos de construcción.
Las dificultades involucradas en la creación de sistemas basados en software han
sido reconocidas por mucho tiempo. En particular, Brooks cita las siguientes
propiedades del software como factores principales afectando su desarrollo.
• Complejidad. Esto se ve como una propiedad esencial del software, en el
que no dos partes son iguales y un sistema puede poseer muchos estados
durante la ejecución. Esta complejidad también es arbitraria, ya que
depende del diseñador en lugar del problema.
• Conformidad. Se espera que el software sea 'flexible' y se ajuste a los
estándares impuesto por otros componentes, como hardware, o por
cuerpos externos, o por existir software de ing.
• Cambiabilidad. El software sufre una necesidad constante de cambio, en
parte debido a la aparente facilidad para hacer cambios (y técnicas
relativamente pobres para costarlos).
• Invisibilidad. Debido a que el software es 'invisible', cualquier forma de
representación que sea usado para describirlo carecerá de cualquier
forma de enlace visual que pueda proporcionar una relación
comprendida entre la representación y el sistema, a diferencia de, por
ejemplo, un plan de construcción que se puede vincular fácilmente a las
características visibles del edificio. Esto no solo limita nuestra capacidad
de conceptualizar las características del software, También dificulta la
comunicación entre los involucrados en su desarrollo.
Por lo tanto, comenzamos este capítulo considerando como factor clave del
diseño a la construcción de modelos. La idea de usar alguna forma de 'modelo'
para ayudar a explorar ideas de diseño es apenas nuevo. Pero ¿qué es
exactamente un modelo? Una definición típica de diccionario lee algo como lo
siguiente:
'Una representación tridimensional, generalmente en miniatura, de una
cosa a ser considerada’ (Larousse)
En el desarrollo de software, necesitamos modelos que a menudo son menos
precisos que las matemáticas. La construcción de dichos modelos, para una
solución propuesta, permite al diseñador explorar las limitaciones potenciales
de la solución, así como para evaluar su comportamiento y estructura.
Transferencia del conocimiento de diseño.
El proceso de diseño general es bastante diferente al enfoque “científico” para
la resolución de problemas. El acto de diseñar no esta basado sobre una
estrategia analítica dirigida a identificar la única solución verdadera a un
problema como determinadas leyes de la física, si que, a diferencia, es un
proceso altamente creativo y, ciertamente muy poco probable que conduzca a
la identificación de una solución única para un problema determinado.
El estudio experimental de diseñadores de software y sus prácticas sugiere que,
como cabe esperar, existen algunas personas que son mejores diseñadores que
otras. Dado que la cantidad de grandes diseñadores es muy pequeña, debemos
buscar formas de proporcionar habilidades de diseño apropiadas a un grupo
más amplio de una manera tan efectiva como sea posible.
En Curtis et al. , (1988), se observó que los diseñadores excepcionales poseían
tres características significativas:
• Familiaridad con el dominio de la aplicación , lo que les permite mapear
entre problemas estructuras y estructuras de solución con facilidad. (Un
dominio en este sentido puede ser uno como procesamiento de datos,
en tiempo real, sistemas de telecomunicaciones, etc.)
• Habilidad para comunicar la visión técnica a otros miembros del
proyecto. Se observó que era un factor tan significativo que gran parte
del trabajo de diseño a menudo era logrado mientras se interactúa con
los demás.
• Identificación con el desempeño del proyecto , en la medida en que se
puedan encontrar asumir responsabilidades administrativas para
garantizar el progreso técnico.
Curiosamente, sin embargo, los diseñadores excepcionales estudiados a
menudo no poseían muy buenas habilidades de programación.
Cuando observamos cómo trabajan los diseñadores exitosos, hay otros factores
a considerar aparte de los que se detallaron en la sección anterior. Visser y Hoc
(1990) han usado el término 'oportunista' para describir observaciones del
diseño de software, incluso cuando los diseñadores pretenden seguir una
estrategia como 'de arriba hacia abajo' (sistemática-refinando la descripción de la
solución en acciones cada vez más pequeñas), pueden desviarse de este plan, ya
sea:
 • Posponer una decisión, si la información requerida no está aún
disponible en este diseño nivel.
• Procesar información que está a la mano y que puede usarse para definir
módulos en previsión de nuevos desarrollos en el diseño.
Tal actividad de diseño oportunista no está desestructurada; en cambio, es más
probable que reflejar la experiencia del diseñador y el conocimiento del
dominio.
El conocimiento del dominio se puede adquirir en parte a través de la
experiencia, y también, para algunos grados, a través del aprendizaje de un
conjunto de prácticas de diseño que pueden estar relacionadas con un
determinado dominio. Una forma de aprender tales prácticas es a través de uso
de métodos de diseño.
La idea de los métodos de diseño surgió en la década de 1970 para satisfacer
esta necesidad de transferencia de conocimiento, y de alguna manera sus
formas y uso parecen ser algo peculiar del desarrollo de software. Podemos,
por lo tanto, considerar que el propósito de un método de diseño de software
es proporcionar el marco que permitir a un diseñador desarrollar y elaborar un
diseño de manera sistemática.
Para nuestros propósitos, un método de diseño de software puede considerarse
como un marco de soporte que consta de dos componentes principales
1. La parte de representación proporciona un conjunto de formas
descriptivas que el diseñador puede utilizar para construir modelos de
caja negra y caja blanca del problema y sus ideas para su solución, y para
describir las características estructurales de la solución para los
implementadores eventuales.
2. La parte del proceso se refiere a describir cómo las transformaciones
necesarias entre las formas de representación deben organizarse, así
como con cualquier trabajo de sus detalles que podrían ser necesarios.
Se proporciona un componente adicional en la mayoría de los métodos de
diseño:
• Un conjunto de heurísticas que se pueden utilizar para proporcionar
pautas sobre las formas en que las actividades definidas en la parte del
proceso pueden organizarse para clases específicas de problemas. Estos
generalmente se basan en la experiencia del uso pasado del método
 dentro de un dominio particular o para una forma particular de
estructura.
Al describir el software, uno normalmente usa formas de diseño detalladas que
describen las estructuras del subprograma del programa, las relaciones que
estos tienen entre sí y las relaciones que tienen con las otras entidades en el
sistema.
Un componente importante de la parte del proceso de un método de diseño es
la estructuración de transformaciones de diseño.
Si exploramos más los pasos de transformación, encontramos que para cada
paso podemos identificar una estructura general. Cada transformación implica:
• Un modelo de entrada que puede describirse utilizando una
'representación' adecuada (que puede ser gráfico, textual o matemático).
• Un modelo de salida que, nuevamente, puede tener cualquiera de estas
formas.
• Entradas de diseño a través de las cuales el diseñador agrega información
al modelo.
Además, podemos identificar dos formas principales de transformación de
diseño, que implican respectivamente:
• El refinamiento (o elaboración) de estructuras, en las que se forman las
entradas y salidas del modelo son iguales, pero se agregan detalles
adicionales.
• La transformación del punto de vista , que puede implicar un cambio de
representación, formar o introducir una interpretación diferente de la
forma de representación.
Restricciones sobre el proceso de diseño y el producto
En la práctica, hay muy pocas oportunidades para diseñar un sistema con una
mano totalmente libre, ya que cada tarea de diseño se lleva a cabo dentro de un
contexto particular, y esto proporcionará limitaciones particulares sobre la
forma del diseño en sí y posiblemente sobre la forma en que se produce.
Para el caso del diseño de software, podemos identificar fácilmente muchas de
las cepas impuestas sobre la forma del producto. Algunos pueden estar
determinados por el entorno de tiempo de ejecución total (organización de las
estructuras de archivos; la 'apariencia' del usuario
interfaz), mientras que otros pueden relacionarse con la necesidad de cumplir
con las convenciones requeridas por un estilo arquitectónico elegido
(JavaBeans; formas de acceso remoto; elección entre procesos u objetos; etc.).
Quizás una de las limitaciones más importantes en la tarea de diseño y la forma
del diseño en sí es el de la eventual forma de implementación.
Las restricciones en el proceso de diseño son más difíciles de identificar.
Pueden ser por las habilidades y el conocimiento del diseñador (experiencia
con un método particular), o con la necesidad de ajustarse a un "estilo
arquitectónico" particular de diseño, para ayudar al mantenimiento futuro. En
algunos casos, una restricción sobre el producto conduce a una restricción en el
proceso, donde, por ejemplo, el formulario de salida debe ser coherente con
ese producido a partir de una estrategia de diseño particular.
Conclusiones:
Como mencionó el autor en este capítulo, la definición de lo que es el software
ha cambiado a lo largo de los años, lo que ha llevado que también cambie lo
que es el diseño en sí, porque antes realmente no era completamente necesario
diseñar un software si en sí era solo una código binario en tabla, como lo llama
el autor, ahora los sistemas de software son un tanto más complejos, dado que
se han implementado nuevas tecnologías como lo es el internet, se cambió la
forma de programar a diferentes paradigmas, en el cual predomina el orientado
a objetos. Todo esto vino a influenciar los cambios en el diseño del software, yq
ya que se necesitaba una forma de poder, valga la redundancia, diseñar algo que
no vemos, lo cual es una principal desventaja en el desarrollo del software,
además de que, aunque no todos “nacen” para diseñar, bien se puede intentar
encontrar el modo de hacerlo de una manera más eficiente, encontrando ese
pensar de diseñador. Aunque el libro es del 2003 en su segunda edición, ya nos
dejaba ver que conforme se iban creando nuevas tecnologías, nuevas formas de
hacer software y nuevo software como tal, el diseño fue “evolucionando” a
como hoy lo conocemos. Hoy en día, como en esos años, sigue siendo una
manera eficiente de diseñar el uso de modelos.