4.1
Estrategias de Diseño
El diseño es el
primer paso de la fase de desarrollo de cualquier producto o sistema de
ingeniería, el diseño de software, al igual que los métodos de diseño de todas
las ingenierías, cambian continuamente al aparecer nuevos métodos, mejores
análisis y ampliar los conocimientos. El problema es que el diseño de software
se encuentra en una etapa relativamente temprana en su evolución.
El objetivo de este tema es presentar
los conceptos fundamentales que se pueden aplicar a todos los diseños de
programas.
Ingeniería del software y diseño del software
Una vez que se han
establecido los requisitos del software, el diseño es la primera de tres
actividades técnicas: diseño, codificación
y prueba.
Cada actividad transforma la información de forma que al final se obtiene un
software validado.
Mediante algunas
metodologías de diseño se realiza el diseño de datos, el diseño arquitectónico
y el diseño procedimental.
Ø El diseño de datos transforma el modelo de campo de información,
creado durante el análisis, en las estructuras de datos que se van a requerir
para implementar el software.
Ø El diseño arquitectónico define las relaciones entre los principales
elementos estructurales del programa.
Ø El diseño procedimental transforma los elementos estructurales en una
descripción procedimental del software.
A continuación, se genera el código
fuente y, para integrar y validar el software, se llevan a cabo las pruebas.
Las fases de diseño,
codificación y prueba absorben el 75% o más del coste de la ingeniería del
software (excluyendo el mantenimiento). El diseño es la única forma mediante la
que podemos traducir con precisión los requisitos del cliente en un producto o
sistema acabado.
El proceso de diseño
El diseño del
software es un proceso mediante el que se traducen los requisitos en una
representación del software, que se acerca mucho al código fuente. Desde el
punto de vista de la gestión del proyecto, el diseño del software se realiza en
dos etapas: el diseño preliminar y el diseño detallado.
Ø El diseño preliminar se centra en la transformación de los
requisitos en los datos y la arquitectura del software.
Ø El diseño detallado se ocupa del refinamiento y de la
representación arquitectónica que lleva a una estructura de datos refinada y a
las representaciones algorítmicas del software.
Además del diseño de
datos, del diseño arquitectónico y del desarrollo procedimental, muchas
aplicaciones modernas requieren un diseño
de la
interfaz.
4.2
Diseño de Objetos
No sólo es un
paradigma de programación Es una filosofía que afecta a buena parte del proceso
de desarrollo de software.
• Diseño Orientado a
Objetos
Además de la
naturalidad que se obtiene al reflejar objetos “reales” en objetos software, el
DOO incorpora técnicas de programación que fomentan la reutilización y
facilitan la ampliación/adaptación de los programas.
Diseño Estructurado (DE) tipo Pascal o C
• Datos y
procedimientos están separados.
• Los procedimientos
se pasan datos y operan sobre ellos.
• Los programas se
dividen en módulos de procedimientos similares, que se usan entre sí y usan a
los de otros módulos.
Diseño
Orientado a Objetos (DOO) tipo Java o C++
• Datos (= atributos)
y procedimientos (= métodos) están juntos formando lo que llamamos “objetos”.
• Los objetos se
comunican entre ellos, transmitiendo órdenes e información (incluso referencias
a otros objetos).
• Los programas se
dividen en paquetes de clases (de objetos) similares, que se relacionan de
varias formas entre sí y se relacionan con las de otros paquetes.
Conceptos
fundamentales
Abstracción
• “Ocultar algunos aspectos de bajo nivel para
que se muestren con mayor claridad otros de más alto nivel”
• Simplificar la realidad
que queremos modelar para centrarnos en el comportamiento de los objetos
software y no en la implementación de su código
Encapsulación
• “Ocultar algunos aspectos internos para que
se muestren con mayor claridad otros aspectos más externos”
• Restringir el
acceso a los atributos y métodos de los objetos para centrarnos en el tipo de
órdenes e información que se transmiten y no en su estructura y funcionamiento
interno.
Beneficios de la
tecnología OO
Tres conceptos
importantes diferencian el enfoque OO de la ingeniería de software convencional.
El encapsulamiento empaqueta datos y operaciones que los manejan.
La herencia permite
que los atributos y operaciones de una clase sean heredados por todas las
subclases y objetos que se instancien de ella. El polimorfismo permite que una
operación pueda implementarse de maneras diferentes y conserve el mismo nombre.
Estas características
propias de la tecnología OO, sumadas a una disciplina de desarrollo que las
potencie y maximice el reusó, permiten desarrollar aplicaciones complejas y de
alta calidad con menor inversión de tiempo y esfuerzo.
Los principales
beneficios que la tecnología OO aporta son:
Reducción de la
brecha semántica entre el mundo real y el modelo: El mundo está
formado por objetos. Desde una etapa temprana categorizamos los objetos y
descubrimos su comportamiento. Los usuarios finales y los especialistas del
dominio piensan de manera natural en término de objetos, eventos y mecanismos
de activación.
El análisis se traduce de manera
directa en el diseño y la implementación.
Diseño más rápido: Muchas aplicaciones
se crean a partir de componentes ya existentes, probados y verificados, lo cual
acelera el proceso de diseño y reduce la posibilidad de falla. Los componentes
se pueden adaptar para un diseño particular.
Mantenimiento más
sencillo: Las
modificaciones no tienen impacto global. El encapsulado separa muy bien el qué
del cómo. Cada clase efectúa funciones independientemente de las demás. Las
clases son como cajas negras y sólo dentro de la misma clase se puede ver su
interior.
Independencia de la
plataforma: Las
clases están diseñadas para ser independientes del ambiente de plataformas,
hardware y software al utilizar solicitudes y respuestas con formato estándar.
Mayor modularidad y
extensibilidad: Los
programas se forman a partir de piezas pequeñas, cada una de las cuales se
puede crear fácilmente. El encapsulamiento y la comunicación vía mensajes
contribuye a generar pequeños módulos. Se construyen clases a partir de otras
clases, permitiendo construir componentes complejos de software que a su vez
intervienen en otros bloques más complejos. La herencia y el polimorfismo
facilitan la extensión de las clases.
Integridad: Las estructuras de
datos sólo se pueden utilizar con métodos específicos.
El objeto esconde sus
datos de los demás objetos y permite el acceso mediante sus propios métodos. El
encapsulado evita la corrupción de los datos de un objeto y los protege del uso
arbitrario y no pretendido.
Reusabilidad: La generación de
componentes reusables (clases) es una consecuencia natural del paradigma. Las
clases están diseñadas para que se reutilicen en muchos sistemas. La
reusabilidad proporciona beneficios inmediatos y sumamente valiosos en la
calidad del producto y en la productividad de los procesos.
Mayor calidad: Los diseños suelen
tener mayor calidad puesto que se integran a partir de componentes probados y
verificados, y porque la mayoría de los factores que determinan la calidad de
un producto de software (fiabilidad, integridad, reusabilidad, flexibilidad,
facilidad de mantenimiento) son naturalmente encontrados en los productos
desarrollados con tecnologías OO.
4.3
Diseño de Sistema
En sentido general, diseñar es una forma de resolución de problemas. Por ello, al
diseñar se utilizan nociones como.
Ø Objetivos
Ø Restricciones
Ø Alternativas
Ø Representaciones
Ø Soluciones
Diseño Conceptual y
Técnico
Para transformar los requerimientos en un sistema
que funcione, los diseñadores deben satisfacer tanto a los clientes como a los
constructores de sistemas.
Los clientes deben comprender lo que el sistema debe
hacer, y los constructores deben comprender cómo debe operar el sistema.
Diseño Conceptual o del Sistema
Se realiza primero, y le dice al cliente que es lo
que hará realmente el sistema.
Una vez que se aprueba este diseño, se vuelca el
trabajo a un trabajo de diseño más detallado.
El diseño conceptual describe el sistema en un
lenguaje que el cliente pueda comprender, en lugar de usar términos técnicos o
jergas de computación.
Diseño Técnico
Permite que los
constructores comprendan el hardware y el software concretos que se necesitan
para resolver el problema del cliente.
Es decir este diseño
describe:
•
La
configuración de hardware.
•
Las
necesidades de software.
•
Las
interfaces de comunicación.
•
Las
entradas y salidas del sistema.
•
La
arquitectura de red.
•
Y
cualquier otro aspecto que incida en la transformación de los requerimientos en
una solución.
Descomposición y
Modularidad
Todo método de
diseño abarca un tipo de descomposición a partir de una descripción de alto
nivel de los elementos claves del sistema, y creando visiones a niveles
inferiores para ver como las características y funciones del sistema se
acomodaran en conjunto.
4.4
Revisión de Diseño
El objetivo es
identificar aquellos atributos del diseño que se correlacionan con los problemas
del sistema. Entonces durante la revisión de diseño, se investigarán dichos atributos
para determinar si el equipo de proyecto los ha tratado apropiadamente.
El equipo de revisión
de diseño comprende los siguientes miembros:
Personal del proyecto: El personal del proyecto puede
conducir su propia revisión del diseño. Normalmente la persona asignada con la
responsabilidad de la revisión del proyecto no es la misma que realmente diseñó
el sistema; sin embargo el que revisa puede tener responsabilidad parcial en el
diseño.
Equipo de revisión independiente: Los miembros de este
equipo de revisión no son miembros del proyecto que está siendo revisado.
Pueden ser de otros proyectos o del equipo de aseguramiento de la calidad.
La siguiente es una
guía en la conducción de una revisión de diseño:
Seleccionar el equipo de revisión: Los miembros del
equipo de revisión deben seleccionarse antes del proceso de revisión
propiamente dicho.
Entrenar los miembros del equipo de revisión: Las personas que
conducirán la revisión deben estar entrenadas sobre cómo dirigir la revisión.
Notificar al equipo del proyecto: El equipo del
proyecto debe estar notificado de la revisión con varios días de antelación
cuando comienza la revisión y su responsabilidad durante la misma.
Asignar tiempos adecuados: La revisión debe
conducirse formalmente y tan eficientemente como sea posible.
Documentar los datos de la revisión: Deben registrarse
todos los hallazgos realizados en la revisión.
Revisar los datos con el equipo de proyecto: La precisión de los
datos debe ser comprobada por todas las personas involucradas, y la revisión no
debe continuar si esto no está hecho.
Desarrollar recomendaciones de revisión: Basándose en los
datos, el equipo de revisión hará sus recomendaciones para corregir cualquier
situación de conflicto.
Revisar recomendaciones con el equipo de proyecto: El equipo de
proyecto debe ser el primero en recibir las recomendaciones y tener la
oportunidad de aceptar, modificar o rechazar las recomendaciones.
Preparar un reporte: Se debe preparar un reporte para
documentar los hallazgos, y las acciones tomadas o a tomar acerca de las
recomendaciones
Revisión del Diseño de Alto Nivel
Cada defecto
descubierto durante la revisión del diseño lógico o de alto nivel debe
documentarse. Se confecciona un reporte de defectos para llevar registro de los
mismos, incluyendo tipo y categoría de los defectos. La descripción de cada
defecto se registra bajo una columna de Faltante, Erróneo o Adicional. Al final
de la revisión del diseño lógico, los defectos se resumen y totalizan. En la figura
se muestra un formulario de registro de defectos en la fase de diseño de alto
nivel:
Revisión del Diseño Detallado
Cada defecto
descubierto durante la revisión del diseño físico o detallado debe
documentarse. Se confecciona un reporte de defectos para llevar registro de los
mismos, incluyendo tipo y categoría de los defectos. La descripción de cada
defecto se registra bajo una columna de Faltante, Erróneo o Adicional. Al final
de la revisión del diseño físico, los defectos se resumen y totalizan. En la
figura se muestra un formulario de registro de defectos en la fase de diseño
detallado:
4.5
Diagramas de Secuencias de Diseño
Utilidad
Un diagrama de casos de uso
muestra la interacción de un conjunto de objetos en una aplicación a través del
tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el
modelado de una vista business del escenario, el diagrama de secuencia
contiene detalles de implementación del escenario, incluyendo los objetos y
clases que se usan para implementar el escenario y mensajes intercambiados
entre los objetos.
Típicamente se examina la
descripción de un caso de
uso para determinar qué objetos son necesarios para la implementación del
escenario. Si se dispone de la descripción de cada caso de uso como una
secuencia de varios pasos, entonces se puede "caminar sobre" esos.
Tipos de mensajes
Existen dos tipos de mensajes:
sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con
llamadas a métodos del objeto que recibe el mensaje.
El objeto que envía el mensaje
queda bloqueado hasta que termina la llamada. Este tipo de mensajes se
representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan
inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se
representan con flechas con la cabeza abierta.
Pueden ser usados en dos
formas
- De instancia: describe un escenario específico (un escenario es una
instancia de la ejecución de un caso de uso).
- Genérico: describe la interacción para un caso de uso; Utiliza
ramificaciones ("Branches"), condiciones y bucles.
Estructura
Los mensajes se dibujan cronológicamente
desde la parte superior del diagrama a la parte inferior; la distribución
horizontal de los objetos es arbitraria. Durante el análisis inicial, el
modelador típicamente coloca el nombre 'business' de un mensaje en la línea del
mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con
el nombre del método que está siendo llamado por un objeto en el otro. El
método llamado, o invocado, pertenece a la definición de la clase instanciada
por el objeto en la recepción final del mensaje.
- Diagrama de flujo
- Diagrama de actividades
- Diagrama de casos de uso
4.6
Herramientas CASE para el Desarrollo
Es la aplicación de tecnología
informática a las actividades, las técnicas y las metodologías propias de
desarrollos de sistemas y al igual que las herramientas a cada diseño asistido.
En el ambiente de la
informática es crucial la época en la cual el hardware era de mayor tamaño de
software para agrupar el conjunto de etapas.
La tecnología CASE supone la
automatización del desarrollo del software, contribuyendo a mejorar la calidad
y la productividad de los sistemas de información.
Permite la aplicación práctica
de metodología practicas estructuradas la cual a ser estructuradas con una
herramienta conseguimos agilizar el trabajo.
Facilitar la realización de
prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento
de los programados.
