El diseño es definido como tanto “El proceso de definir la arquitectura, la componentes, interfaces, y las otras características de un sistema o componente” como “El resultado de [eso] se procesa.” Visto como un proceso, el diseño de software es la actividad de ciclo de vida de ingeniería de software en la que los requerimientos de software son analizados para causar una descripción de la estructura interna del software que servirá como base para su construcción. Más precisamente, un diseño de software (el resultado) debe describir la arquitectura de software – es decir cómo el software está en estado de descomposición y organizado en los componentes – y las interfaces entre esos componentes. También debe describir los componentes en un nivel del detalle que permiten su construcción. El diseño de software tiene un papel importante en el desarrollo de software, ya que permite que ingenieros de software produzcan modelos distintos que moldean una clase de plano de la solución a ser implementado. Podemos analizar y valorar a estos modelos para determinar cuál de estos permitirá o no, cumplir con una gama de requerimientos.

1. DISEÑO DE SOFTWARE
Republica Bolivariana de Venezuela
Ministerio del Poder popular para
La Educación Universitaria
Instituto universitario Politécnico
“Santiago Mariño”
Extensión San Cristóbal
Alumno: Jorge Jhoel Guerrero Rangel
C.i: 25.980.022

2. DISEÑO DE SOFTWARE
El diseño es definido como tanto “El proceso de definir la arquitectura, la componentes, interfaces, y las otras
características de un sistema o componente” como “El resultado de [eso] se procesa.” Visto como un proceso, el
diseño de software es la actividad de ciclo de vida de ingeniería de software en la que los requerimientos de
software son analizados para causar una descripción de la estructura interna del software que servirá como base
para su construcción. Más precisamente, un diseño de software (el resultado) debe describir la arquitectura de
software – es decir cómo el software está en estado de descomposición y organizado en los componentes – y
las interfaces entre esos componentes. También debe describir los componentes en un nivel del detalle que
permiten su construcción.
El diseño de software tiene un papel importante en el desarrollo de software, ya que permite que ingenieros de
software produzcan modelos distintos que moldean una clase de plano de la solución a ser implementado.
Podemos analizar y valorar a estos modelos para determinar cuál de estos permitirá o no, cumplir con una gama
de requerimientos.

3. IMPORTANCIA DEL DISEÑO DEL
SOFTWARE
Una fase muy importante en el ciclo de vida de un proyecto es el Diseño del Software. Se trata de una etapa
fundamental y en muchas ocasiones la más importante en el desarrollo de Software. Es el momento en que los
profesionales tienen que aportar sus conocimientos, experiencia y creatividad para llegar a una solución que
cumpla con los requerimientos funcionales y no funcionales establecidos en la fase de la toma de requisitos.
El diseño del Software tiene un impacto directo sobre la capacidad del sistema para cumplir o no el total de
requerimientos establecidos. Un error de diseño en esta fase puede acarrear problemas en todo el proyecto y
provocar que este caiga en una espiral de continuos cambios y de rehacer constantemente el trabajo.
Si tuviéramos que resumir en una sola palabra la importancia del diseño del Software esta sería
“Calidad”.
Para acometer la tarea de diseño de manera satisfactoria existen algunas técnicas que podemos (y muchas de
ellas debemos) seguir:

4. IMPORTANCIA DEL DISEÑO DEL
SOFTWARE
 Entendimiento de los requisitos:
Debemos tener claros todos los requerimientos que afectan al Diseño del Software. Estos pueden ser funcionales o no, pero deberán estar
completamente definidos, entendidos y documentados. Casi todos los problemas futuros comienzan por no tener claros los requisitos. Estos
deberán 100% claros y sin ambigüedades
 Patrones de diseño:
No deberíamos de inventar nada que ya esté inventado. Para ello debemos conocer y aplicar los patrones de diseño. Estos son soluciones
(ya probadas y documentadas) a problemas de desarrollo conocidos.
 Calidad:
La calidad del diseño deberá ir evaluándose mientras se va creando y no cuando ya esté terminado.
 Modularidad:
El diseño deberá ser modular dividiéndose en estructuras que realicen funciones específicas. Esto facilitará la reutilización. Además deberá
realizarse de manera que permita cambios y que permita la extensión de funcionalidades sin afectar a otras. Una muy buena práctica para
esto es exponer las funcionalidades a través de interfaces.
 Diseños ágiles:
No es necesario definir el diseño completo al inicio. Se puede partir de un diseño general e ir construyéndolo a medida que avanza el
desarrollo, de esta manera se adaptará a cambios y evoluciones. Separar completamente el diseño de la codificación tiene sus riesgos y
siempre es mejor contar con profesionales que puedan diseñar y codificar.

5. IMPORTANCIA DEL DISEÑO DEL
SOFTWARE
 Documentación:
Es fundamental poder comunicar el diseño a otras personas involucradas
en el desarrollo. La documentación se realiza por medio de distintas
vistas de más alto o bajo nivel. Estas vistas contienen normalmente
diagramas además de información que apoyan a su compresión.
 Como resumen podemos decir que para que el desarrollo de
software se realice con calidad, merece la pena esforzarse en un
buen Diseño del Software.
El diseño es importante y deberá realizarse todos los días, esto nos
permitirá tener una visión general antes de lanzarse a la codificación y
construcción.

6. PRINCIPIOS BASADOS EN DISEÑO DE
ATRIBUTOS DE CALIDAD
“El comienzo de la sabiduría para un ingeniero de software es reconocer la diferencia entre hacer que un programa funcione y conseguir que lo
haga del modo correcto”.
El diseño de la arquitectura de software es una fase muy importante en el ciclo de vida del software. Es absolutamente necesario desempeñar
ésta tarea con demasiada cautela, ya que un error en ésta fase del desarrollo puede lastrar todo un proyecto y llevarlo a caer en una espiral
de constantes cambios.
Existen algunas reglas las que podríamos considerar a la hora de diseñar la arquitectura del sistema.
 3.1- Funcionalidad – Cada fragmento de software debe hacer la vida más fácil al usuario, la regla 80-20 debe encajar aquí (por lo menos un
80 % del tiempo…).
Cuando desarrollas software, asegúrate que cada parte del software hace lo que se necesita que haga, y no lo que no se necesita que haga.
Parece obvio, pero no lo es.
Cuando piensas donde situar cada método del software que implementa algunas de las funcionalidades requeridas, intenta agrupar los métodos
que se encuentren relacionados en funcionalidad. Intenta evitar funcionalidades duplicadas, simplemente por pequeñas diferencias. Si tienes que
hacerlo, hazlo de la forma más inteligente, reduciendo la duplicidad de código a lo mínimo necesario. Utiliza clases de soporte, o métodos de
soporte lo más que puedas, y hazlos estáticos, así reducirás el costo y optimizarás los recursos del sistema.
La funcionalidad expuesta, deberá encajar con las necesidades del usuario. El código reutilizable, no debe cubrir el 100% de los casos. Al menos
el 10% de los casos son tan extraños, que nunca habrás pensado en ellos.
Realiza una búsqueda exhaustiva y encuentra el 80% de los casos que son relevantes para ti. No mires lo que no se encuentre relacionado con
el negocio. Esos casos hacen las cosas de una manera diferente, y tienen un ámbito diferente. Mira implícitamente en tu negocio. Incluso en tu
negocio, hay mucha información al respecto y deberás encontrarla. Si no la encuentras, simplemente significa que quizás esa funcionalidad no
necesites hacerla reutilizable. Simplemente hazla de forma aplicativa.
No utilices tecnología intrusiva en tu código, si lo haces, documenta porque lo has hecho.

7. PRINCIPIOS BASADOS EN DISEÑO DE
ATRIBUTOS DE CALIDAD
 Orden – Cada pieza de software debe estar organizada para encontrar fácilmente cada fragmento de código, y estructurado de forma
fácil para poder añadir un nuevo fragmento.
 Trazabilidad – Cada fragmento de software deberá registrar sus acciones en detalle, preferentemente en diferentes niveles de detalles.
Utilizar librerías de logging facilitará tu trabajo.
El software debe registrar las acciones y los errores, estos registros serán luego utilizados para analizar el uso de la aplicación tanto para
evaluar el performance, los errores, los comportamientos inesperados, etc.
Utiliza un método común para registrar todas las partes de la aplicación. Un método altamente configurable y extensible en lo posible,
porque en el caso inesperado de que una tercera persona desee extender ésta funcionalidad, deberá poder hacerlo.
 Seguridad – Cada pieza de software no debe revelar sus debilidades de seguridad, esto permitiría que se abusara maliciosamente del
sistema, como inyección de código, modificación de privilegios no autorizados, denegación de servicios del sistema, etc.
La seguridad es una cuestión muy importante en las aplicaciones, especialmente cuando el software es expuesto a una larga lista de
usuarios, y realmente no puedes saber a ciencia cierta quien desea hacer daño a tu empresa o a tus clientes.
Cuando se crean consultas de base de datos, asegúrate de limpiar las consultas para prevenir inyecciones SQL, éstas pueden hacerte
perder muchísima información.
Cuando tienes parámetros de entrada de cualquier tipo, asegúrate de que tienes suficiente espacio para almacenarlo, limitar lo que debes
limitar y evita la inyección de código.

8. PRINCIPIOS BASADOS EN DISEÑO DE
ATRIBUTOS DE CALIDAD
 Portabilidad.
Un software portable es mucho mejor que un software que necesitas instalar. Copiar ficheros a un lugar es mucho más fácil que seguir un procedimiento de instalación.
Cada fragmento de software debe ser lo más portable posible. No necesariamente entre diferentes sistemas operativos, pero generalmente entre diferentes ordenadores.
 Reusabilidad:
Cada fragmento de software debe ser lo más reutilizable posible (a menos que sea aplicativo), y reutilizar otros componentes lo mayor posible.
Cuando desarrollas software, el factor de reusabilidad es crucial, especialmente cuanto tienes plazos que cumplir. Divide tu código en varias librerías bien definidas, que te
permita utilizar en otros proyectos, por lo general te costará menos en conceptos de tiempos, esfuerzo y dinero cuando varios proyectos están involucrados.
Si solamente tienes un proyecto, aún así deberías reutilizar. Deberías separar código reutilizable en una librería lo que te permitirá simplificar aún más el código a mantener.
 Cuando no Reutilizar
Un caso donde no es bienvenida la reutilización es en un proceso muy específico.
Otro caso donde no se recomienda reutilizar, es la falta de entendimiento para encontrar la forma correcta de construir código reutilizable. Por lo general, el código en
cuestión se escribió sólo una o dos veces.
Por ejemplo: escribes un fragmento de software que hace una determinada tarea, y crees que esta tarea podría repetirse en el futuro, lo exportas a una biblioteca. Entonces,
después de un tiempo, deseas volver a utilizarlo, en otro lugar, pero ya ves que no es lo suficiente extensible, lo suficientemente portátil, no responde a sus requisitos de
funcionalidad, etc.
Todavía tienes que escribir tu propio código. O tienes que fijar la biblioteca para adaptarse a los dos proyectos, y luego ir y arreglar el viejo proyecto que ya lo utiliza. La
fijación de la biblioteca en este momento sería difícil, ya que las necesidades del nuevo proyecto no se tuvieron en cuenta en el diseño original. Cuando un proyecto de
tercera que lo necesita, esto podría repetirse de nuevo.
Por lo general, una buena idea esperar hasta que haya requisitos de al menos tres proyectos diferentes antes de decidirse a hacer una pieza de código de una biblioteca
reutilizable.

9. PRINCIPIOS BASADOS EN DISEÑO DE
ATRIBUTOS DE CALIDAD
 Extensibilidad
Cada fragmento de software deberá ser lo más extensible posible, es decir, tener todos los lugares posibles para añadir más funcionalidad.
La extensibilidad te permite añadir nuevas funcionalidades en el futuro. Existen muchos tipos de extensibilidad, tanto internas como externas.
Extensibilidades externas son las más importantes. El desarrollador de software reutilizable deberá tener en cuenta la necesidad de otro desarrollador para añadir funcionalidad o
hacer las cosas un poco diferentes de su propio punto de vista.
Por ejemplo, supongamos que tienes una clase que contiene un control de usuario, y ese control de usuario es visible para el usuario final. Puedes agrupar por completo,
solamente la funcionalidad que consideres útil. Pero en algunos casos un desarrollador puede querer ajustar este determinado control, y puede ser que no le han dado la opción de
hacer su pequeña modificación.
 Mejores Prácticas de Extensibilidad.
Una regla de oro de extensibilidad sería exponer la funcionalidad de siempre a través de interfaces, y si desea que el usuario sea capaz de llevarlas a la introducción de los objetos
creados a tu librería, utilice el patrón de fábrica, y permitir al usuario el registro de sus propios tipos. Esto le permite reemplazar el código detrás de la interfaz como todo lo que
quieras sin que el usuario tiene que desconfiar de él, y también permite al usuario introducir sus propios tipos.
Por lo general, prefieren introducir interfaces en lugar de las clases base. Si el usuario necesita integrar en su proyecto en curso un código, una clase de base puede que le impida
hacer lo que necesite, puede ser que quiera agregar funcionalidad a una clase actual que ya tiene, que hereda de otra clase base. Con interfaces, esto siempre es posible.
Si tienes un método que devuelve un resultado, prefieres crear una clase que de resultado especializado y llenarla con los datos pertinentes. Si deseas añadir datos en el futuro, esto
sería tan fácil como agregar campos a la clase ya existente. Crea un método con un parámetro extensible (Array de String…) de entrada aunque se encuentre vacío, probablemente
se utilice en un futuro.
 Orden y Estructura.
Cuando desarrollas la estructura de tu proyecto, hazla significativamente separada por la lógica, no en términos físicos. Piense en alguien que no conoce el proyecto y necesita un
fichero determinado, si no puede encontrarlo es que la estructura no sigue una lógica determinada.
De la misma manera se pueden utilizar directivas de región. Si veo miles y miles de métodos públicos, como podré encontrar lo que necesito realmente. Sería óptimo separar las
funcionalidades por región, considérese por el tipo de interacción con el usuario, diseño de lógica, construcción e inicialización.

10. ESTRATEGIAS DE DISEÑO DE
SOFTWARE
Aquí se traducen los requisitos en una representación del software realizándose en dos etapas:
Diseño preliminar: es la transformación de los requisitos en los datos y arquitectura del software
Diseño detallado: se ocupa del refinamiento y de la representación arquitectónica que lleva una estructura de
datos refinada y a las representaciones algorítmicas del software

11.  Estructura de datos
Es una representación de la relación lógica existente entre los elementos individuales de datos. Establece la organización, métodos de acceso,
grado de asociatividad y las alternativas de procedimiento para la información
 4.2 Procedimiento del software
Se centra sobre los detalles de procesamiento de cada módulo individual. Debe proporcionar una especificación precisa del procesamiento,
incluyendo la secuencia de sucesos, los puntos concretos de decisiones. Debe incluir referencias a todos los módulos subordinados del
que describe.
 4.3 Ocultamiento de la información
Capacidad que obtienen los módulos de transmitir información contenida en ellas pero solamente información necesaria. Implica que hay
definir un conjunto de módulos independientes, que se comuniquen con los otros mediante la información que sea necesaria para realizar la
función del software.
Todos los fundamentos del diseño anteriores sirven para incentivar los diseños modulares. Un diseño modular: reduce la complejidad, facilitar
los cambios, implementación más sencilla y permite el desarrollo paralelo de parte diferente de un sistema. Para la definición de módulos en
arquitectura de software se utiliza la abstracción y el ocultamiento de información es por eso que a continuación se detalla los tipos de
módulos.
 Módulo secuenciales: ejecutan secuencialmente una tarea
 Módulos incrementales: puede ser interrumpido antes de que terminen por el software de la aplicación y restablece posteriormente su
ejecución en el punto que se interrumpió.
 Módulo paralelo: se ejecuta a la vez que otro módulo en entorno multiprocesadores
 Algunas descripciones estructurales (vista estática).
ESTRATEGIAS DE DISEÑO DE
SOFTWARE

12. ESTRATEGIAS DE DISEÑO DE
SOFTWARE
 Diagramas de clase y objeto: se usan para representar un conjunto de clase (y objetos) y sus relaciones. Una
notación antigua relacionada son los diagramas entidad-relación usados para representar modelos
conceptuales de datos almacenados en sistemas de información. UML tiene esta notación
 Diagramas de componentes: se usan para modelar la vista de implementación estáticas de un sistema, es decir,
cosas físicas (y sus relaciones) como ejecutables, librerías, tablas, archivos y documentos. A pesar que si uso
principal es durante la construcción, estos diagramas pueden ser usados durante diseño, por ejemplo, para
documentar la estructura de un módulo. UML tiene esta notación
 Cartas de estructuras o Diagrama de Estructura: se usan para describir la estructura de llamado de un programa, es
decir, cuál módulo es invocado por otro módulo. Estos diagramas son inherentes de la aproximación de diseño
orientado a la función.
 Algunas descripciones conductuales (vista dinámica)
 Diagramas de actividad: se usan para mostrar el flujo de control de actividad (ejecución continua no-atómica dentro
de una máquina de estado) a otra actividad. UML tiene esta notación.
 Diagramas de interacción: se usan para mostrar las interacciones entre un grupo de objetos. Estos diagramas vienen
en dos tipos: diagramas de secuencia ponen el énfasis en el ordenamiento temporal de los mensajes, mientras que
los diagramas de colaboración ponen el énfasis en los objetos, sus enlaces y los mensajes que intercambian en estos
enlaces. UML tiene esta notación.
 Diagramas de flujo de datos: se usan para mostrar el flujo de datos entre un conjunto de procesos.