miércoles, 14 de octubre de 2009

Diseño de sistemas. Parte 1.


El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado
La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones. Una forma de caracterizar una aplicación es por la importancia relativa de sus modelos de objetos, dinámica y funcional. Las distintas arquitecturas ponen distintos grados de énfasis en los tres modelos.
El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. AL tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajarán independientemente en distintos subsistemas. El diseñador de sistemas debe tomar las siguientes decisiones:
- Organizar el sistema en subsistemas
- Identificar la concurrencia inherente al problema
- Asignar los subsistemas a los procesadores y tareas
- Seleccionar una aproximación para la administración de almacenes de datos
- Manejar el acceso a recursos globales
- Seleccionar la implementación de control en software
- Manejar las condiciones de contorno
- Establecer la compensación de prioridades

Definición de subsistema
En todas las aplicaciones, salvo en las más pequeñas, el primer paso para diseñar un sistema consiste en dividir el sistema en un pequeño número de componentes. Cada uno de los componentes principales de un sistema se llama subsistema. Cada subsistema abarca aspectos del sistema que comparten alguna propiedad común.
Un subsistema no es ni una función ni un objeto, sino un paquete de clases, asociaciones, operaciones, sucesos y restricciones interrelacionados, y que tienen una interfaz razonablemente bien definida y pequeña con los demás subsistemas. Normalmente, un subsistema se identifica por los servicios que proporciona. Un servicio es un grupo de funciones relacionadas que comparten algún propósito común, tal como el procesamiento de entrada-salida, dibujar imágenes o efectuar cálculos aritméticos. Un subsistema define una forma coherente de examinar un aspecto del problema.
Cada subsistema posee una interfaz bien definida con el resto del sistema. Ésta especifica la forma de todas las interacciones y el flujo de información entre los límites de subsistemas, pero no especifica cómo está implementado internamente el subsistema. Cada subsistema se puede diseñar, entonces, independientemente, sin afectar a los demás.
Los subsistemas deberían definirse de tal manera que la mayoría de las interacciones se produzcan dentro de y no entre los límites de distintos subsistemas, con objeto de reducir las dependencias existentes entre ellos. Todo sistema debería dividirse en un pequeño número de subsistemas. Cada subsistema, a su vez, debe descomponerse en subsistemas propios aún más pequeños. Los subsistemas de más bajo nivel se denominan módulos.
La relación entre dos subsistemas puede ser cliente-proveedor o punto a punto. En las primeras, el cliente debe conocer la interfaz del proveedor, pero éste no necesita conocer las interfaces de aquellos porque todas las interacciones son iniciadas por los clientes, empleando la interfaz del proveedor. En una relación entre pares, cada subsistema puede llamar a los demás. Una comunicación desde un subsistema hacia otro no va necesariamente seguida por una respuesta inmediata. Las interacciones entre pares son más complejas porque los subsistemas deben conocer las interfaces del otro. Hay ciclos de comunicaciones que son difíciles de entender y proclives a sutiles errores de diseño. Hay que buscar descomposiciones cliente-proveedor siempre que sea posible, porque una interacción mono direccional es mucho más fácil de construir, comprender y modificar que una interacción bidireccional.
Identificación de la concurrencia
EN el modelo de análisis, al igual que en el mundo real y en el hardware, todos los objetos son concurrentes. En una implementación, sin embargo, no todos los objetos del software son concurrentes, porque un procesador puede dar soporte a muchos objetos. En la práctica, se pueden implementar muchos objetos en un único procesador si los objetos no pueden estar activados a la vez. Un objetivo importante del diseño del sistema es identificar los objetos que deben estar activados concurrentemente, y los objetos que tienen actividad que sea mutuamente exclusiva. Estos últimos objetos se pueden plegar y juntar en un único hilo de control o tarea.
Asignación
Cada subsistema concurrente debe ser asociado a una unidad de hardware, bien a un procesador de propósito general o a una unidad funcional especializada. El diseñador del sistema deberá:
- Estimar las necesidades de rendimiento y los recursos necesarios para satisfacerlas
- Seleccionar las implementaciones de hardware o de software para los subsistemas
- Asignar los subsistemas de software a los procesadores para satisfacer las necesidades de rendimiento y para minimizar la comunicación entre procesadores
- Determinar las conexiones de las unidades físicas que implementan los subsistemas.
Almacenamiento de datos
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.
Los archivos son una forma de almacenamiento de datos barata, sencilla y permanente. Sin embargo, las operaciones de archivos son de bajo nivel y las aplicaciones deben incluir un código adicional para proporcionar un nivel de abstracción adecuado. Las implementaciones de los archivos son distintas según los diferentes sistemas de computadoras, así que las aplicaciones transportables deben de aislar cuidadosamente las dependencias con sistemas de archivos. Las implementaciones para archivos secuenciales son las más comunes, pero las ordenes y los formatos de almacenamiento para ficheros de acceso aleatorio e indexado varían mucho.
Las bases de datos, que son administradas mediante sistemas de gestión de bases de datos, son otro tipo de almacenamiento. Existen varios tipos de sistemas de gestión disponibles comercialmente: jerárquicos, en red, relacionales, orientados a objetos y lógicos. Estos sistemas intentan reservar los datos de acceso frecuente en memoria, con objeto de alcanzar la mejor combinación posible de costo y rendimiento desde y hacia la memoria y el almacenamiento en disco. Las bases de datos son potentes y hacen que las aplicaciones sean más fáciles de transportar a sistemas operativos y a distintas plataformas, por cuanto el vendedor transporta el código del sistema de gestión. Una desventaja es que tienen una interfaz compleja.
Las siguientes líneas generales caracterizan el tipo de datos que pertenece a una base de datos formal:
- Datos que requieran un acceso a niveles finos de detalle por parte de múltiples usuarios
- Datos que puedan ser administrados eficientemente mediante órdenes de un sistema gestor de base de datos
- Datos que deban transportarse a través de múltiples sistemas operativos y muchas plataformas hardware
- Datos a los que deba acceder más de un programa de aplicación
Las siguientes líneas caracterizan las clases de datos que pertenecen a un archivo y no a una base de datos relacional:
- Datos que sean voluminosos respecto a cantidad pero difíciles de estructurar en los confines de un sistema de datos.
- Datos que sean voluminosos en cantidad y con una baja densidad de formación
- Datos crudos que estén resumidos en la base de datos
- Datos volátiles que se mantengan durante un corto periodo de tiempo y se descarten después.

No hay comentarios:

Publicar un comentario