Diseño de sistemas. Parte 2.

Administración de los recursos
El diseñador de sistemas debe identificar los recursos globales y tiene que determinar mecanismos para controlar el acceso a ellos. Entre los recursos globales se cuentan: unidades físicas, tales como procesadores, unidades de cinta y satélites de comunicación; espacio, tal como el espacio en disco, una pantalla de una estación de trabajo, y los botones de un ratón; nombres lógicos, tales como la identificación de los objetos, nombres de archivos y nombres de clases; y el acceso a datos compartidos, tales como bases de datos.
Si el recurso es un objeto físico se puede controlar a sí mismo estableciendo un protocolo para obtener el acceso dentro de un sistema concurrente. SI el recurso es una entidad lógica, tal como la identidad de un objeto, o una base de datos, existe el peligro de que el acceso produzca conflictos en un entorno compartido. Podría ser, por ejemplo, que varias tareas independientes utilizasen simultáneamente la misma identidad de un objeto. Todo recurso global debe ser poseído por un objeto guardián que controle el acceso a éste. Un objeto guardián puede controlar varios recursos. Todo el acceso al recurso debe pasar a través del objeto guardián. Por ejemplo, la mayoría de los administradores de bases de datos son tareas libres a las cuales invocan otras tareas para obtener datos de la base de datos. La asignación de cada recurso global compartido a un único objeto es un reconocimiento de que ese recurso tiene una identidad.
Un recurso lógico también se puede descomponer lógicamente, de forma que los subconjuntos se asignan a distintos objetos guardianes para ser controlados de modo independiente.
En una aplicación en la cual el tiempo sea crítico, el costo de pasar todo el acceso a un recurso a través de un objeto guardián resulta a veces excesivo, por lo que los clientes deben acceder directamente al recurso. En este caso, se pueden situar bloqueos en subconjuntos del recurso. Un bloqueo es un objeto lógico asociado con algún subconjunto definido de algún recurso que proporciona a quien posea el bloqueo el derecho de acceder directamente a ese recurso. Sigue siendo necesario que exista un objeto guardián para asignar los bloqueos, pero tras una interacción con el guardián para obtener un bloqueo, el usuario del recurso puede acceder directamente al recurso. Esta aproximación es más peligrosa porque hay que confiar en que todos los usuarios de recursos se comporten correctamente en su acceso al mismo. El uso de accesos directos a recursos compartidos no debe de propugnarse en un diseño orientado a objetos a no ser que resulte absolutamente necesario.
Software de control
Durante el análisis, todas las interacciones se muestran como sucesos entre objetos. El control del hardware se parece mucho al modelo de análisis, aunque el diseñador de sistemas de be escoger entre varias maneras de implementar el control en software. Aún cuando no existe una necesidad lógica de que todos los subsistemas utilicen la misma implementación, lo normal es que el diseñador seleccione un único estilo de control. Existen dos clases de flujos de control en un sistema de software: el control externo y el interno.
El control externo es el flujo de los sucesos externamente visibles entre los objetos del sistema. Existen tres clases de control para sucesos externos: secuencial, controlado por procedimientos, secuencial controlado por sucesos, y concurrente. El estilo de control que se adopte dependerá de los recursos disponibles y de la trama de interacciones existentes en la aplicación.
El control interno es el flujo de control dentro de un proceso. Solo existe en la implementación y, por tanto, no es inherentemente concurrente ni secuencial. El diseñador puede decidir descomponer un proceso en varias tareas por claridad lógica o por rendimiento. A diferencia de los sucesos externos, las transferencias internas de control, tales como las llamadas a procedimientos o las llamadas entre tareas, están dirigidas por el programa y se pueden estructurar de la forma que más convenga. Son frecuentes tres clases de control de flujo: llamadas a procedimientos, llamadas entre tareas que son casi concurrentes y llamadas entre tareas concurrentes. Las llamadas entre tareas casi concurrentes, tales como las corrutinas o procesos ligeros, son conveniencias de programación en las cuales existen múltiples espacios de direcciones o pilas de llamada, pero en las que solamente puede estar activo un hilo de control en cada momento.
DISEÑO DE LOS OBJETOS
La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina el plan de ataque. La fase de diseño de objetos determina las definiciones completas de las clases y asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.
Aspectos generales del diseño de objetos
Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el diseño del sistema y se rellenan los detalles. Se produce un desplazamiento del énfasis pasando de los conceptos del dominio de la aplicación a los propios de las computadoras. Los objetos descubiertos durante el análisis sirven como esqueleto del diseño, pero el diseñador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecución, la memoria y el costo. En particular, las operaciones identificadas durante el análisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas más sencillas. Las clases, atributos y asociaciones del análisis deben de implementarse en forma de estructuras de datos específicas. Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecución del programa y para evitar la necesidad de recalcularlos. La optimización del diseño no debería llevarse a extremos exagerados porque la facilidad de implementación y mantenimiento y la extensibilidad son también objetivos importantes.
Algoritmos
Cada operación especificada en el modelo funcional debe ser formulada como un algoritmo. El análisis de especificaciones dice lo que hace la operación desde el punto de vista de sus clientes y los algoritmos muestran cómo se hace. Un algoritmo se puede subdividir en llamadas a operaciones más sencillas y así sucesivamente, hasta que las operaciones del nivel más bajo sean suficientemente sencillas para implementarlas directamente sin más refinamiento.
El diseñador de algoritmos debe:
- Seleccionar algoritmos que minimicen el costo de implementar las operaciones
- Seleccionar estructuras de datos adecuadas para los algoritmos
- Definir nuevas clases y operaciones internas según sea necesario
- Asignar la responsabilidad de las operaciones a las clases adecuadas
Controles
El diseñador debe refinar la estrategia para implementar los modelos de estados y sucesos presentes en el modelo dinámico. Como parte del diseño del sistema, se habrá seleccionado una estrategia básica para construir el modelo dinámico. Durante el diseño de objetos, es necesario desarrollar esta estrategia.
Para implementar el modelo dinámico hay tres aproximaciones básicas:
- Utilizar la posición dentro del programa para almacenar el estado (sistema controlado por procedimientos
- Implementación directa de un mecanismo de máquina de estados (sistema controlado por sucesos)
- Utilización de tareas concurrentes
Asociaciones
Las asociaciones son el pegamento de nuestro modelo de objetos, y proporcionan vías de acceso entre objetos siendo entidades conceptuales útiles para el modelado y el análisis. Durante la fase de diseño de objetos hay que formularse una estrategia para implementar las asociaciones habidas en el modelo de objetos. Se puede seleccionar una estrategia global para implementar todas las asociaciones uniformemente o bien seleccionar una técnica particular para cada asociación, teniendo en cuenta la forma en que será utilizada en la aplicación. Para tomar decisiones inteligentes acerca de las asociaciones se necesita analizar primero la forma en que serán utilizadas.