2. A través de la historia de la ingeniería del software ha
evolucionado un conjunto de conceptos fundamentales
de diseño de software, aunque el grado deinterés en
cada concepto ha variado con los años, han pasado la
prueba del tiempo ofreciendo cada uno al ingeniero de
software fundamentos sobre el cual pueden
aplicarse métodos de diseño más elaborados.
El diseño de Software juega un papel importante en
el desarrollo de software lo cual permite al ingeniero de
software producir
varios modelos delsistema o producto de que se va a
construir el mismo que forman una especie de plan de
la solución de la aplicación.
DISEÑO DE SOFTWARE
3. DISEÑO DE SOFTWARE
Estos modelos puede evaluarse en relación con
su calidad y mejorarse antes de generar código, de
realizar pruebas y de que los usuarios finales se vean
involucrados a gran escala. El diseño es el sitio en el
que se establece la calidad del software.
El diseño del software se encuentra en el núcleo técnico
de la ingeniería del software y se aplica
independientemente del modelo de diseño de software
que se utilice.
Una vez que se analizan y especifican los requisitos del
software, el diseño del software es la primera de las tres
actividades técnicas - diseño, generación de código y
pruebas- que se requieren para construir y verificar el
software.
4. IMPORTANCIA DEL DISEÑO DE SOFTWARE
La importancia del diseño del software se puede
describir con una sola palabra -calidad-. El diseño es el
lugar en donde se fomentará la calidad en la ingeniería
del software. El diseño proporciona las
representaciones del software que se pueden evaluar
en cuanto a calidad. El diseño es la única forma de
convertir exactamente los requisitos de un cliente en un
producto o sistema de software finalizado. El dise- ño
del software sirve como fundamento para todos los
pasos siguientes del soporte del software y de la
ingeniería del software.
5. PERSISTENCIAS, ALMACENAMIENTO,
EXCEPCIONES ENTRE OTRAS
Persistencia es el "arte" de almacenar
y/o recuperar el estado de un objeto. No
todo campo de un objeto requiere
persistir, puede ser calculado, en tal
caso a ese campo se lo llama
trasciente. Por ejemplo si tengo una
clase que representa un triángulo
rectángulo entonces el estado a
almacenarse corresponderá a las
dimensión de los lados, mientras que la
hipotenusa es un campo trasciente ya
que resulta de aplicar la eterna
ecuación pitagórica.
6. PERSISTENCIAS, ALMACENAMIENTO,
EXCEPCIONES ENTRE OTRAS
Los almacenes de datos internos y externos dentro de
un sistema proporcionan puntos limpios de separación
entre subsistemas con interfaces bien definidas. En
general, todo almacén de datos puede
combinar estructuras de datos, archivos y bases de
datos implementados en memoria o bien en dispositivos
de almacenamiento secundario. Los distintos tipos de
almacenes de datos proporcionan diversas
compensaciones entre costo, tiempo de acceso,
capacidad y fiabilidad.
7. MÉTODOS PARA LA ACTIVIDAD DE DISEÑO
Resulta necesario establecer un enfoque sistemático y
disciplinado para llevar a cabo un desarrollo software.
Una metodología de ingeniería del software es un
proceso para producir software de forma organizada,
empleando una colección de técnicas y convenciones
de notación predefinidas.
Conjunto de procedimientos, técnicas, herramientas y
un soporte documental que ayuda a los desarrolladores
a realizar nuevo software.
8. MÉTODOS PARA LA ACTIVIDAD DE DISEÑO
Un conjunto estructurado de actividades y resultados
asociados que conducen a la creación de un producto
de software:
Especificación de requisitos: Definir la funcionalidad y
las restricciones en sus operaciones
Diseño e implementación: Producir software que cumple
la especificación
Validación: Asegurar que hace lo que el cliente desea.
Mantenimiento (o Evolución): Seguir cumpliendo los
cambios en las necesidades del usuario.
9. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
Un buen diseñador
debería considerar
enfoques alternativos
Se debería poder
seguir los pasos del
diseño hasta el modelo
del análisis
El diseñador no debe
inventar nada de lo
que ya esté inventado
Uniformidad e
integración
Debe estructurarse
para admitir cambios
Estructurarse para
degradarse poco a
poco
El diseño no es escribir
códigos y viceversa
Valorar el diseño
mientras se crea
Revisar el diseño para
minimizar errores
conceptuales
10. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
El diseño de interacción determina las posibilidades de
operación de un sistema tecnológico: las posibilidades
de acción de las personas que lo usarán, y las
reacciones del sistema ante estas acciones.
El diseño de interacción y el diseño de la interfaz son
mutuamente dependientes, muchas veces las
decisiones de un plano condicionarán las decisiones en
el otro plano.
Hasta el momento1, los sistemas electrónicos y
tecnológicos en general, no están dotados de
inteligencia propia. Todo sistema será tan inteligente
como su diseño permita.
11. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
El diseño de interacción comienza durante las etapas
estratégicas del diseño, con la definición de
requerimientos y funcionalidades, elementos claves que
dan forma a la estrategia del sistema. Al hablar de
diseño estratégico nos referimos a decisiones de
negocios que permiten elegir una estrategia a tomar con
un producto: estrategias de diferenciación de la
competencia, audiencia primaria a enfocar el producto.
12. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
El diseño de un producto tecnológico es un proceso
complejo con múltiples dimensiones, estas decisiones
estratégicas dan forma al producto, aunque muchas
veces se las considere fuera del proceso de diseño.
Para crear un diseño amigable es fundamental entender
a las personas que usarán el sistema, por esto parte
importante de este trabajo consiste en entrevistar
personas que representen al tipo de usuario final del
sistema. Empaparse del modo de pensar, las
necesidades y el lenguaje de los usuarios permitirá al
diseñador estar en mejor pie para anticipar sus
expectativas y reacciones, generando una interacción
natural para ellos.
13. DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
○ Los atributos de calidad son las cualidades o
propiedades de calidad que la aplicación debe
satisfacer.
o La calidad de una aplicación se mide en función de
sus atributos de calidad.
o Para facilitar su medición durante la verificación,
deben expresarse cuantitativa o cualitativamente.
14. DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
Del Software
Asociado a la Funcionalidad
Asociado a la Confiabilidad
Asociado a la Utilidad
Asociado a la Eficiencia
Calidad
Asociado a la Mantenibilidad
Asociado a la Portabilidad
15. DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
16. DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
17. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
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.
Una arquitectura de software se selecciona y diseña
con base en objetivos y restricciones. Los objetivos son
aquellos prefijados para el sistema de información, pero
no solamente los de tipo funcional, también otros
objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de
información.
18. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
Las restricciones son aquellas limitaciones derivadas de
las tecnologías disponibles para implementar sistemas
de información. Unas arquitecturas son más
recomendables de implementar con ciertas tecnologías
mientras que otras tecnologías no son aptas para
determinadas arquitecturas. Por ejemplo, no es viable
emplear una arquitectura de software de tres capas
para implementar sistemas en tiempo real.
19. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
En toda tarea humana, podemos encontrar una serie
de patrones que se repiten. Incluso en las bellas artes,
actividad representativa de la creatividad humana,
podemos hallar características comunes que nos
permiten clasificar las obras en distintos movimientos
artísticos. Y cómo no, en el arte de la programación no
iba a ser menos.
20. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
Era de esperar, por tanto, que alguien se animara tarde
o temprano a estudiar los distintos patrones que pueden
encontrarse en la inmensa mayoría del software, de
forma que los problemas solucionados por estos
quedasen perfectamente clasificados junto con su
solución, para que así no fuese necesario reinventar la
rueda cada vez que un programador se enfrentase a un
obstáculo similar al descrito en uno de estos patrones.
Nacieron así los patrones de diseño de sistemas
software.
21. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
Un patrón de diseño debe cumplir al menos dos
requisitos para considerarse como tal: Debe ser
efectivo, de modo que se haya podido comprobar su
éxito resolviendo problemas anteriores; y debe
ser reutilizable, es decir, podemos aplicarlo a problemas
que se hallan en circunstancias similares a las descritas
por el patrón.
22. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
Imagina cuán sencillo sería poder comentar un
problema de diseño con un compañero, y poder decirle
algo tan sencillo como: “Esto es un patrón adapter”;
siendo este breve comentario suficiente como para que
tu interlocutor te entendiese perfectamente y sepa cómo
hay que resolver el problema al que te enfrentas.
23. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
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.
24. ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
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.
25. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
DISEÑO ORIENTADO A FUNCIONES
(ESTRUCTURADO)
El diseño estructurado se utiliza generalmente
después de un análisis estructurado, cuyo
producto es el diagrama de flujo de datos y las
descripciones de procesos. Los investigadores
han propuesto diversas estrategias y heurísticas,
como por ejemplo fan-in/fan-out, para
transformar un DFD en una arquitectura de
software en general representada como una
estructura chart.
26. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
Como un método de diseño, ésta es realmente una
combinación de dos técnicas diferentes,
interrelacionadas. La primera es el Análisis de Sistemas
Estructurados(SSA), que se ocupa de la construcción
de un modelo del problema mediante el uso de
Diagramas de Flujo de Datos (DFD). La segunda es el
diseño estructurado (SD), que a su vez se orienta hacia
los aspectos relacionados con la búsqueda de
soluciones (diseño detallado) mediante el uso de la
estructura chart.
27. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
DISEÑO ORIENTADO A OBJETOS
Existen numerosos métodos de diseño
de software basado en objetos que han
sido propuestos desde la década de
1980. De manera informal, de acuerdo a
su elaboración, se los ubica en tres
generaciones (Budgen, 2003):
•Métodos de primera generación:
Desarrollados en la década de 1970 y
principios de 1980, estos métodos
tienen una tendencia evolutiva. Se
caracterizan por tener formas limitadas
de notación diagramática y procesos
débiles.
28. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
Este método no ofrece una forma eficaz para el uso de
la propiedad de herencia y el concepto de jerarquía de
clases. Sin embargo, se limita exclusivamente a las
características de objetos como: la modularidad, el
encapsulamiento y la abstracción.
29. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
•Métodos de segunda generación: Desarrollados a
mediados de la década de 1990, estos métodos son
considerados revolucionarios. El método Fusión
desarrollado en 1994 integra y amplia los elementos de
mayor éxito de las prácticas existentes hasta ese
entonces. Al igual que HOOD, Fusión emplea una
combinación de texto y diagramas, aunque la
proporción de diagramas es mucho mayor. Fusión
cuenta con un diagrama de clase (Denominado el
modelo de objetos) que trata de proporcionar un punto
de vista de la construcción de un sistema. Mientras que
el modelado del comportamiento de clase hace uso de
descripciones textuales.
30. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
El Proceso Unificado: Surgió en la década de 1990
como resultado de unir las ideas y enfoques empleados
por Booch, Jacobson y Rumbaugh. Se relaciona
estrechamente con el desarrollo en paralelo de UML.
31. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
DISEÑO BASADO EN COMPONENTES
Un componente de software es una unidad
independiente, que posee interfaces bien definidas y
dependencias que pueden ser construidas e
implementadas de forma separada. El diseño basado
en componentes busca proveer, desarrollar e integrar
dichos componentes (Budgen, 2003).
Una de las principales razones para optar por este
diseño es promover la reutilización, la misma que
permite reducir los costos de elaboración del producto
final (Budgen, 2003). Existen dos características que se
deben tomar en cuenta para la reutilización:
32. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
Funcionalidad bien definida, para facilitar la
identificación de los componentes útiles, que satisfagan
los requerimientos.
Los componentes deben tener interfaces bien definidas
que permitan su interrelación.
Sin embargo, existen varios problemas relacionados al
diseño utilizando componentes:
33. ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
Búsqueda del Componente: es una tarea complicada
encontrar un componente que satisfaga la funcionalidad
indicada para un sistema. Es necesario identificar
claramente las necesidades generales del problema,
para luego buscar un conjunto de componentes que
colectivamente resuelvan estas necesidades.
Integración de componentes: pueden darse casos en
los cuales el conjunto de componentes no logra
satisfacer la funcionalidad requerida. De igual forma,
existe la posibilidad de que dos o más componentes
brinden la misma funcionalidad. Incluso, existe la
posibilidad de una incompatibilidad arquitectónica entre
componentes.