UNIDAD V
FUNDAMENTOS DEL DISEÑO
·
Conceptos
generales de diseño.
El software no es el
único campo donde el diseño se encuentra inmiscuido. En general podemos ver el
diseño como una forma para resolución de problemas. El problema sin solución
definitiva es interesante en términos de comprensión del diseño. Un número de
otras nociones y conceptos son también de interés en la comprensión del diseño
en su sentido general, objetivos, limitaciones, alternativas, representaciones y
soluciones
·
Contexto del
diseño de software.
El diseño del software
se encuentra en el núcleo técnico de la respectiva ingeniería y se aplica de
manera independiente al modelo software que se utilice. Una vez que se
analizan y especifican los requisitos, el diseño del software es la última acción de la ingeniería correspondiente dentro
de la actividad del modelado, la cual establece una plataforma para la construcción (generación de código y prueba).
"El milagro
más común de la ingeniería de software es la transición del análisis al diseño y del diseño al código"
Richard Due
·
Proceso del
Diseño de Software.
·
Diseño Arquitectónico.
El diseño arquitectónico
puede representarse al usar uno o más de muchos modelos diferentes. Los modelos
estructurales representan la arquitectura como una colección organizada de
componentes del programa. Los modelos
del marco de trabajo repetible incrementan el grado de abstracción del diseño
al intentar identificar marcos de trabajo repetibles del diseño arquitectónico
que se encuentran en tipos de aplicaciones similares.
El diseño de la arquitectura de software se describe cómo se descompone y
como están organizados los componentes en el software.
Diseño Detallado.
El diseño detallado se
describe el comportamiento específico de
estos componentes.
·
Técnicas Permitidas.
·
Abstracción
Abstracción es el
proceso o el resultado de la generalización de la reducción del contenido de la
información de un concepto o un fenómeno
observable, por lo general, con el fin de conservar únicamente la información
que es relevante para un propósito en particular. Cuando se considera una
solución modular a cualquier problema se pueden exponer muchos grados de
abstracción. En un alto grado de abstracción una solución se establece en
términos generales con el lenguaje del
entorno del problema. En los grados de menor abstracción se proporciona una descripción más
detallada de la solución. En la medida en que se cambian los diferentes grados
de abstracción se trabaja para crear abstracciones procedimentales y de datos.
Abstracción
Procedimental: Se refiere a una secuencia de instrucciones
que tiene función específica y limitada.
Abstracción de Datos: Es una colección nombrada de datos que describe un objeto de datos.
·
Acoplamiento y Cohesión.
Dentro del modelo de diseño es necesario que las clases de diseño
colaboren con alguna otra. Es una medida de la interconexión entre los módulos
de la estructura de un programa. Depende de la complejidad de la
interfaz entre los módulos, el punto en el que se entra o se hace referencia al
módulo y qué datos pasan a través de la interfaz. Intentamos conseguir el menor
nivel posible de acoplamiento. Las conexiones sencillas entre los módulos hacen
que el software sea más fácil de entender y menos dado al efecto.
Acoplamiento: La fuerza de las relaciones entre
los módulos.
Acoplamiento de datos: está subordinado al módulo y se accede a él por medio de una lista
convencional de argumentos a través de la cual se pasan los datos.
Acoplamiento de marca: cuando en vez de argumentos simples se pasa una porción de la estructura
de datos se pasa por la interfaz del módulo.
Acoplamiento de control: se pasa un indicador de control (una variable que controla las decisiones
en el módulo subordinado).
Acoplamiento externo: cuando los módulos están atados a un entorno externo al software. Por
ejemplo, las I/O y los dispositivos.
Acoplamiento común: varios módulos hacen referencia a un área global de datos.
Acoplamiento de
contenido: un módulo hace uso de datos o de información de control mantenidos dentro de
los límites de otro módulo. Cuando se
realiza una bifurcación hacia la mitad de otro módulo.
Una clase de diseño cohesiva tiene un conjunto de
responsabilidades pequeño y enfocado, y aplica atributos y métodos de manera sencilla de implementar
dichas responsabilidades.
Cohesión: Como están relacionados los elementos que conforman un módulo.
Es una extensión natural
del concepto de ocultamiento de la
información. Un módulo con cohesión realiza una sola tarea dentro de un procedimiento de software, requiriendo poca
interacción con los procedimientos que se
realizan en otras partes del programa. Un módulo con cohesión debería hacer una
sola cosa. Siempre debemos buscar la cohesión más alta, aunque la parte media
del espectro es a menudo aceptable.
Coincidencialmente
cohesivo: un módulo que realiza un conjunto de
tareas poco relacionadas las unas con las otras.
Cohesión lógica: realiza tareas
relacionadas lógicamente (produce todas las salidas).
Cohesión temporal: contienen tareas relacionadas por el hecho de que todas deben hacerse en
el mismo intervalo de tiempo.
Cohesión procedimental: cuando los elementos de procesamiento están relacionados y deben
ejecutarse en un orden específico.
Cohesión de comunicación: todos los elementos de procesamiento se concentran en un área de la
estructura de datos.
·
La descomposición y la modularización.
Los patrones de arquitectura y diseño de software materializan
la modularidad; es decir, el software se divide en componentes con nombres
independientes y que es posible abordar en forma individual. Estos componentes
llamados módulos se integran para satisfacer los requisitos del problema.
Modularidad: Es el
atributo particular del software que permite que un programa sea manejable de
manera intelectual.
Se divide el software en
componentes identificables y tratables por separado, denominados módulos, que
están integrados para satisfacer los requisitos del programa.
Hay un número m de
módulos que resultarían en un costo de
desarrollo mínimo, pero no tenemos la sofisticación necesaria para predecir m
con seguridad
·
Encapsulación/Ocultar Información
Mediante la agrupación y
empaquetado de los elementos y los detalles internos de una abstracción,
haciendo que estos detalles sean inaccesibles.
·
Separación de la interfaz y la aplicación
La separación de la interfaz
y la aplicación implica la definición de un elemento especificando una interfaz
pública, conoce a los clientes, aparte
de los detalles de cómo se realiza el componente.
·
Suficiencia, integridad y primitivismo.
Los métodos asociados
con una clase de diseño deben enfocarse en el cumplimiento de un servicio para la clase.
·
Concurrencia:
La forma de descomponer
el software en los procesos, tareas e hilos tratar relacionarlos con la
eficiencia, la atomicidad, la sincronización, y demás cuestiones de
programación.
·
Control y manejo de Eventos
Cómo organizar los datos
y el controlar el flujo, manejo de reactivo y temporal de los acontecimientos a
través de diversos mecanismos, tales como la invocación implícita de llamadas y
sus intentos.
·
Distribución de Componentes
Cómo distribuir el
software en el hardware, cómo los componentes
se comunican, cómo se puede usar una plataforma al utilizarse para hacer frente
a software heterogéneos.
·
Error y gestión de Excepciones tolerancias a Fallos.
El análisis y la gestión del riesgo son una serie
de pasos que ayudan al equipo del software a comprender y a gestionar la
incertidumbre.
Un riesgo es un problema
potencial que puede ocurrir o no. Pero sin tener en cuenta el resultado,
realmente es una buena idea es
identificarlo, evaluar su probabilidad de aparición, estimar su impacto, y
establecer un plan de contingencia por si ocurre el problema. Después, el equipo de Software establece un
plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se
pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de
contingencia que le permita responder de una manera eficaz y controlada.
Estructura y Arquitectura de Software
En el sentido estricto,
una arquitectura de software es "Una descripción de los subsistemas y componentes
de un sistema de software y las relaciones que existen entre ellos". A mediados de 1990, la arquitectura empezó a
emerger como una disciplina más amplia
que implica el estudio de las estructuras y las arquitecturas de software en
una forma más genérica, dando ideas interesantes sobre diseño del software en
diferentes niveles de abstracción.
Algunos de estos
conceptos son muy útiles durante el diseño arquitectónico (estilo de
arquitectura), de software específico, así como en su diseño de detalle (nivel
inferior, patrones de diseño). Así también para el diseño de sistemas genéricos lo que lleva a la
concepción de las familias de los programas
(conocidas como líneas de productos ).
La mayoría de estos conceptos pueden verse como intentos de describir, por
tanto la reutilización del diseño genérico del conocimientos.
El desarrollo de un
sistema con gran cantidad de software requiere que este sea visto desde
diferentes perspectivas. Diferentes usuarios (usuario final, analistas,
desarrolladores, integradores, jefes de proyecto...) siguen diferentes actividades en
diferentes momentos del ciclo de vida del
proyecto, lo que da lugar a las diferentes vistas del proyecto, dependiendo de
qué interese más en cada instante de tiempo.
La arquitectura es el
conjunto de decisiones significativas sobre:
·
La organización del sistema.
·
Selección de elementos estructurales y sus
interfaces a través de los cuales se constituye el sistema.
·
El comportamiento, como se especifica las
colaboraciones entre esos componentes.
·
Composición de los elementos estructurales
y de comportamiento en subsistemas progresivamente más grandes.
·
El estilo arquitectónico que guía esta
organización: elementos estáticos y dinámicos y sus interfaces, sus
colaboraciones y su composición.
·
Estructuras Arquitectónicas y Puntos de
Vista.
Durante las diferentes
facetas o etapas del software deben ser descritos y documentados.
"Una vista
representa un aspecto parcial de la arquitectura de un software mostrando las
propiedades del sistema de software".
La arquitectura que no
debe centrarse únicamente en la estructura y en el comportamiento, sino que
abarque temas como el uso, funcionalidad, rendimiento, capacidad de adaptación,
reutilización, capacidad para ser comprendida, restricciones, compromisos entre
alternativas, así como aspectos estéticos. Para ello se sugiere una
arquitectura que permita describir mejor los sistemas desde diferentes vistas,
donde cada una de ellas es una proyección de la organización y la estructura
centrada en un aspecto particular del sistema.
La vista de casos de uso comprende la descripción del comportamiento del sistema tal y como es
percibido por los usuarios finales, analistas y encargados de las pruebas y se utilizan los diagramas de casos de uso para capturar los aspectos
estáticos mientras que los dinámicos son representados por diagramas de
interacción, estados y actividades.
La vista de diseño comprende las clases, interfaces y colaboraciones que forman el
vocabulario del problema y de la solución. Esta vista soporta principalmente
los requisitos funcionales del sistema, o sea, los servicios que el sistema debe proporcionar.
Los aspectos estáticos se representan mediante diagramas de clases y objetos y
los aspectos dinámicos con diagramas de interacción, estados y actividades.
La vista de procesos comprende los hilos y procesos que forman mecanismos de sincronización y
concurrencia del sistema cubriendo el funcionamiento, capacidad de crecimiento
y el rendimiento del sistema. Con UML, los aspectos estáticos y dinámicos se
representan igual que en la vista de diseño, pero con el énfasis que aportan
las clases activas, las cuales representan los procesos y los hilos.
La Vista de
implementación comprende los componentes y los archivos que
un sistema utiliza para ensamblar y hacer disponible el sistema físico. Se
ocupa principalmente de la gestión de configuraciones de las distintas
versiones del sistema. Los aspectos estáticos se capturan con los diagramas de
componentes y los aspectos dinámicos con los diagramas de interacción, estados
y actividades.
La vista de despliegue de un sistema contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema.
Se preocupa principalmente de la distribución, entrega e instalación de las
partes que constituyen el sistema. Los aspectos estáticos de esta vista se
representan mediante los diagramas de despliegue y los aspectos dinámicos con
diagramas de interacción, estados y actividades.
·
Patrones de Diseño (Patrones Micro
arquitectónicos).
Los patrones de diseño
hacen que sea más fácil reutilizar buenos diseños y arquitecturas. Al expresar
como patrones de diseño técnicas que ya han sido probadas, las estamos haciendo
más accesibles para los desarrolladores de nuevos sistemas. Los patrones de
diseño nos ayudan a elegir las alternativas del diseño que hacen que un sistema
sea reutilizable, y evitar aquellas que dificultan dicha reutilización.
Los patrones de creación
tienen que ver con el proceso de creación, estructural o de comportamiento.
Calidad en el análisis, diseño y evaluación del software
·
Calidad de atributos
Varios atributos son
generalmente considerados importantes que permiten obtener un diseño de
software con alta calidad, existen algunas características que son (
mantenible, portabilidad, probable) y (correctos, robusto). Cabe destacar que
existen diferencias entre calidad de atributos que son (rendimiento, seguridad,
funcionalidad y usabilidad), y los que son (portabilidad, reutilización,
integralidad y pruebas), y las características relacionadas con la arquitectura
(integridad conceptual, correcto, completo).
·
Calidad en análisis y evaluación de
técnicas
Varias técnicas y herramientas
pueden ayudar a mejorar la calidad de diseño de software:
Diseño de software: Para este tipo se puede aplicar al diseño de
software informal y semi informal tomando un grupo base, técnicas que permiten verificar la
calidad de diseño de los artefactos que pueden ser (vista de la arquitectura,
diseño -inspección, técnicas y requerimientos).
Análisis estático: Para
este tipo se puede aplicar al diseño de software informal y semi informal que
permite evaluar algo simple utilizando análisis automáticos de casos de
pruebas.
Simulación y prototipos:
Son técnicas dinámicas que permiten evaluar un diseño la característica de simulación, o la flexibilidad del prototipo.
Diseño de software
Muchas notaciones y
lenguajes existen para representar el diseño de artefactos de software. Algunos
describen un diseño estructural organizado, otros representan el inicio del
software. Estas notaciones son generalmente usadas durante un diseño natural y
se pueden usar durante ambos casos. Una representan notaciones que son usadas
en el contexto de específicos métodos en las estrategias de diseño y métodos de sub áreas,
pero estas categorías son categorizadas en notaciones para describir la estructura
estática y la dinámicas vistas.
Bibliografía
[1]
Swebok_Ironman_June_23_ 2004
[2] http://www.info-ab.uclm.es/asignaturas/42530/pdf/M1tema2.pdf
[3]
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
[4] http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml
[5] PRESSMAN Roger S.,
2005. Ingeniería de Software. Un enfoque práctico. Sexta edición. 2005, Estados Unidos.
Paginas a consultar:
