La fase de diseño (y los modelos de UML resultantes) expande y detalla
los modelos de análisis tomando en cuenta todas las implicaciones y
restricciones. El propósito del diseño es especificar una solución que trabaje
y pueda fácilmente se convierta en código fuente y construir una arquitectura
simple y fácilmente entendibles. Las clases definidas en el análisis fueron
detalladas y se añaden nuevas clases para manejar áreas técnicas como base de
datos, interfaces del usuario.
4.1 ESTRATEGIA DE DISEÑO
ABSTRACION: Para un problema determinado se pueden considerar muchos grados de
abstracción. En un alto grado de abstracción una solución se establece en
términos generales con el lenguaje de entorno del problema en los grados de menor
abstracción. En un alto grado de abstracción una solución se establece en términos generales con
el lenguaje de entorno del problema.
ARQUITECTURA: La arquitectura
del software alude a la estructura general del software y las formas en
las que la estructura proporciona una integridad conceptual para un sistema. 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.
PATRONES: Un
patrón de diseño describe una estructura de diseño que resuelve un problema
recurrente de diseño particular dentro de un contexto específico y en medio de
fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el
patrón.
MODULARIDAD:
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. La modularidad se basa en
la estrategia divide y vencerás (es más fácil resolver un problema complejo
cuando éste se divide en piezas más manejables).
OCULTACION DE
INFORMACION: Sugiere que los módulos se caracterizan por las
decisiones de diseño que cada uno oculta a los otros. Los módulos deben
especificarse y diseñarse de manera que la información (procedimientos y datos)
que está dentro del módulo sea inaccesible para otros módulos que no necesiten
esta información.
4.2 DISEÑO DE OBJETOS
Un sistema orientado a objetos está compuesto de objetos que
interactúan, los cuales mantienen ellos mismos su estado local y proveen
operaciones sobre su estado. La representación del estado es privada y no se
puede acceder a ella directamente desde fuera del objeto. El proceso de diseño
de objetos comprende el diseño de clases de objetos y las relaciones entre
estas clases. El diseño orientado a objetos comprende el desarrollo de un
modelo orientado a objetos de un sistema de software para implementar los
requerimientos
identificados. Los objetos en un diseño orientado a objetos están relacionados con el problema a resolver.
identificados. Los objetos en un diseño orientado a objetos están relacionados con el problema a resolver.
Un proceso general para el diseño orientado a objetos puede contener
las siguientes etapas:
•Comprender y definir el contexto y los modos de
utilización del sistema
•Diseñar la arquitectura del sistema
•Identificar los objetos principales del sistema
•Desarrollar los modelos de diseño
•Especificar las interfaces de los objetos. Todas
estas actividades se pueden ver como actividades entrelazadas que influyen
entre sí. Los objetos se identifican y las interfaces se especifican completa o
parcialmente en el momento de definir la arquitectura del sistema.
4.3 DISEÑOS DE SISTEMAS
El diseño de sistemas se ocupa de desarrollar
las directrices propuestas durante el análisis en términos de aquella
configuración que tenga más posibilidades de satisfacer los objetivos
planteados tanto desde el punto de vista funcional como del no funcional (lo
que antes hemos denominado constricciones).
El proceso de diseño de un sistema complejo se
suele de forma descendente:
· Diseño de alto nivel (o
descomposición del sistema a diseñar en subsistemas menos complejos).
· Diseño e implementación
de cada uno de los subsistemas
o Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis.
o Desarrollo según la especificación.
o Prueba.
· Integración de todos los subsistemas.
· Validación del diseño
Dentro del proceso de diseño de sistemas hay
que tener en cuenta los efectos que pueda producir la introducción del nuevo
sistema sobre el entorno en el que deba funcionar, adecuando los criterios de
diseño a las características del mismo.
En este contexto está adquiriendo una
importancia creciente la adaptación de todo sistema-producto a las capacidades
de las personas que van a utilizarlo, de forma que su operación sea sencilla,
cómoda, efectiva y eficiente.
De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento).
De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento).
Así, con respecto al diseño de herramientas
software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la
disposición de informaciones en pantalla, profundidad de menús, formato de
iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo
de errores, estructuras de datos, utilización de lenguaje natural.
4.4 REVISION DEL DISEÑO
Según la
IEEE 61012 una revisión es un proceso o reunión durante la cual un producto de
trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de
un proceso se presenta al equipo de proyecto, a los administradores, usuarios,
clientes u otra parte interesada para su comentario o aprobación.
La
revisión del diseño de los productos de software se realiza por demanda con el
objetivo de detectar e identificar no conformidades en el diseño antes de pasar
a la codificación, así como también identificar aspectos de mejoramiento. Una
recisión es una forma de aprovechar la diversidad de un grupo de personas.
·
Señalar las necesidades de mejoras en el producto de
una sola persona o equipo
·
Confirmar las partes del producto en las que no es
necesario o no es deseable una mejora
·
Conseguir un trabajo de mayor calidad maximizando los
criterios de correctitud y completitud.
El
objetivo primario de las revisiones técnicas formales (inspección) es encontrar
errores durante el proceso para evitar que se conviertan en defectos después de
la entrega del software. El beneficio de estas inspecciones el descubrimiento
de errores al principio para que no se propaguen al paso siguiente del proceso
de desarrollo del software.
4.5 DIAGRAMAS DE SECUENCIA DE DISEÑO
El
diagrama de secuencia de un sistema muestra gráficamente los eventos que fluyen
de los actores de sistema. Su creación forma parte de la investigación para
conocer el sistema, se fluye dentro de la etapa del análisis.
En UML
los diagramas de secuencia muestran gráficamente los eventos que pasan de los
actores al sistema.
ACTIVIDADES Y DEPENDENCIA
Los
diagramas e secuencia de un sistema se preparan durante la fase del análisis,
para su creación debemos formular antes los casos de uso.
COMPORTAMIENTO DEL SISTEMA
Antes
de iniciar el diseño de cómo funcionara una aplicación de software, es
necesario investigar y definir su comportamiento como “una caja negra”. El
comportamiento del sistema es una descripción de lo que hace. Una parte de la
descripción es un diagrama de secuencia del sistema
DIAGRAMA DE SECUENCIA DEL SISTEMA
Los
casos de unos indican los actores interactúan con el sistema del software.
Durante esa interacción un actor genera eventos dirigidos al sistema
solicitando alguna operación a cambio conviene aísla, y explicar gráficamente
las operaciones que un actor solicita al sistema, porque ello contribuye a
entender el comportamiento del sistema.
En UML
los diagramas de secuencia dan una descripción grafica de las integraciones del
actor, y de las operaciones que los mismos originan. A todos los sistemas se
los trata como “caja negra”, los diagramas se encuentran en los eventos que
trascienden las fronteras del sistema y que fluyen desde los actores hacia los
sistemas.
El
diagrama de secuencia debe prepararse para el curso normal de los eventos de un
caso de uso y los cursos opcionales más interesantes. DIAGRAMA DE SECUENCIA =
Representación que muestra en un determinado caso de uso, los eventos generados
por actores extremos, su orden y los eventos internos del sistema.
4.6 HERRAMIENTAS PARA EL DISEÑO
Son un conjunto de métodos, utilidades y técnicas que
facilita la automatización del ciclo de vida del desarrollo de sistemas de
información, completamente o en alguno de sus fases.
El empleo de las HERMIENTAS CASE permite integrar el
proceso de ciclo de vida.
·
Análisis de
datos y procesos integrados mediante un
repositorio
·
Generación de
interfaces entre el análisis y el diseño
·
Generación de código
a partir del diseño
·
Control de
mantenimiento
Actualmente, la tendencia en el desarrollo de software
está enfocada hacia las microcomputadoras como plataforma de ingeniería de
software, que se interconectan mediante redes para que puedan comunicarse de
forma efectiva. La base de datos del proyecto, la arquitectura de entorno,
compuesta por la plataforma hardware y el soporte del sistema operativo
(incluida la red y la gestión de la base
de datos). Constituye la base del CASE, pero el entorno CASE en si mismo
necesito otros componentes. Un conjunto de servicios de portabilidad constituye
un puente entre las herramientas CASE y su marco de investigación en un
conjunto de programas especializados que permite cada herramienta CASE
comunicarse con las demás para crear una base de datos de proyectos y muestra una
apariencia homogénea al usuario final (el ingeniero de software).
La principal ventaja de la utilización de una
herramienta CASE es la mejora de la calidad de los desarrollos realizados y en
segundo término, el aumento de la productividad. Para conseguir estos dos
objetivos es conveniente contar con una organización y una metodología de
trabajo además de la propia herramienta.
La mejora calidad se consigue reduciendo
sustancialmente muchos de los problemas de análisis, inherentes a los proyectos
de mediano y gran tamaño (lógica del coherente, consolidación).
La mejora productividad se consigue a través de la
automatización de determinadas tareas como la generación de códigos y la
reutilización de objetos o módulos.
TIPOS DE CASE
No existe una única clasificación de herramientas
CASE y en ocasiones, es difícil
incluirlas en una clase determinada podrían clasificarse atendiendo a:
·
Las plataformas que
soportan.
·
Las fases de ciclo de
vida del desarrollo de sistemas que cubren.
·
La arquitectura de
las aplicaciones que producen su funcionalidad.
