martes, 23 de febrero de 2010
martes, 16 de febrero de 2010
martes, 9 de febrero de 2010
EL PAPEL DE LA TEORIA DE INFORMACION
El objetivo global de la ingeniería de la información es aplicar tecnología de información de la mejor manera que satisfaga las necesidades generales del negocio. Para conseguirlo la ingeniería de la información debe empezar por analizar los objetivos y metas del negocio, después debe definir las necesidades de la información de cada área de negocio y del negocio en su totalidad. Solo después de hacer esto la ingeniería de la información hace la transición al dominio más técnico de la ingeniería de software; el proceso, donde los sistemas de información, aplicaciones y programas son analizados, diseñados y construidos.
DISEÑO DE SISTEMAS
Diseño del Sistema
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ámico 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 monodireccional 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 indexados 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 ordenes 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.
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.
Bibliografía
"Modelado y Diseño Orientados a Objetos"
James Rumbaugh et al
Ed. Prentice Hall 1997
Octavio Mancilla González
ocmagomx[arroba]yahoo.com.mx
Universidad Tecnológica de México
mono.temp_mono_id = 58815;
Comentarios
El comentario ha sido publicado.
Para dejar un comentario, regístrese gratis o si ya está registrado, inicie sesión.
Agregar un comentario Enviar comentario
Los comentarios están sujetos a los Términos y Condiciones
Trabajos relacionados
Estudio sobre los lenguajes de programación para la robótica
Origen de la palabra robot y su significado. Propiedades características de los robots. El robot y su funcionamiento. Cl...
Sistemas de Procesamiento de Datos Programación Orientada a Objetos
Estructura de un objeto. Encapsulamiento y ocultación. Organización de los objetos. Actualmente una de las áreas más ca...
Rupturas de Informe
Definición de una Ruptura de Informe. Especificación de Opciones de Proceso. Una Ruptura de Informe se usa para dividir...
Ver mas trabajos de Programacion
google_protectAndRun("render_ads.js::google_render_ad", google_handleError, google_render_ad);
Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior
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ámico 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 monodireccional 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 indexados 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 ordenes 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.
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.
Bibliografía
"Modelado y Diseño Orientados a Objetos"
James Rumbaugh et al
Ed. Prentice Hall 1997
Octavio Mancilla González
ocmagomx[arroba]yahoo.com.mx
Universidad Tecnológica de México
mono.temp_mono_id = 58815;
Comentarios
El comentario ha sido publicado.
Para dejar un comentario, regístrese gratis o si ya está registrado, inicie sesión.
Agregar un comentario Enviar comentario
Los comentarios están sujetos a los Términos y Condiciones
Trabajos relacionados
Estudio sobre los lenguajes de programación para la robótica
Origen de la palabra robot y su significado. Propiedades características de los robots. El robot y su funcionamiento. Cl...
Sistemas de Procesamiento de Datos Programación Orientada a Objetos
Estructura de un objeto. Encapsulamiento y ocultación. Organización de los objetos. Actualmente una de las áreas más ca...
Rupturas de Informe
Definición de una Ruptura de Informe. Especificación de Opciones de Proceso. Una Ruptura de Informe se usa para dividir...
Ver mas trabajos de Programacion
google_protectAndRun("render_ads.js::google_render_ad", google_handleError, google_render_ad);
Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior
martes, 2 de febrero de 2010
ANALISIS Y DISEÑO DE SISTEMAS.DEFINICION
Ingeniería de Sistemas ?Estudia en la U. Tadeo Lozano Solicita Más Información Aquí ! | UTadeo.edu.co
Software de ColaboraciónDescubra Los Productos de Lotus Para Colaboración y Productividad. | Ibm.com/Lotus
Planificación de proyectos de software
Análisis de Sistemas de Computación.
Diseño de Sistemas de Comput
Tema I. Planificación de un proyecto de sistemas.
Desarrollo
1.1. Que es un proyecto de Sistema o Software. ?
Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software.
La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.
1.2. Objetivos de la Planificación del Proyecto.
El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.
El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.
1.3 Actividades asociadas al proyecto de software.
1.3.1 Ambito del Software.
Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.
En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos
Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.
El Ambito se define como un pre-requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es:
La Obtención de la Información necesaria para el software. Para esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo.
1.4 RECURSOS:
La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.
Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).
Cada recurso queda especificado mediante cuatro características:
Descripción del Recurso.
Informes de disponibilidad.
Fecha cronológica en la que se requiere el recurso.
Tiempo durante el que será aplicado el recurso
1.4.1 Recursos Humanos.
La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara cada profesional.
1.4.2 Recursos o componentes de software reutilizables.
Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilizacion, esto es la creación y la reutilizacion de bloques de construcción de Software.
Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la también fácil integración.
El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación:
Componentes ya desarrollados.
Componentes ya experimentados.
Componentes con experiencia Parcial.
Componentes nuevos.
1.4.3 Recursos de entorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software.
El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces el desarrollo de las pruebas de validación de un proyecto de software para la composición automatizada puede necesitar un compositor de fotografías en algún punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.
1.5. ESTIMACION DEL PROYECTO DE SOFTWARE.
En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento mas caro de la mayoría de los sistemas informáticos.
Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:
Deje la estimación para mas adelante (obviamente podemos realizar una estimación al cien por cien fiable después de haber terminado el proyecto.
Base las estimaciones en proyectos similares ya terminados.
Utilice técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto.
Desarrolle un modelo empírico para él calculo de costos y esfuerzos del Software.
Desdichadamente la primera opción, aunque atractiva no es practica.
La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras.
Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir y generar una estimación de su tamaño.
1.5.1 Estimación basada en el Proceso.
Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea.
Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software.
1.6. DIFERENTES MODELOS DE ESTIMACION.
Existen diferentes modelos de estimación como son:
1.6.1 Los Modelos Empíricos:
Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por est razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.
1.6.2 El Modelo COCOMO.
Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm esta constituida por los siguientes:
Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de Software en función del tamaño del programa, expresado en las líneas estimadas.
Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
Modelo III. El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.
1.6.3 Herramientas Automáticas De Estimación.
Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos.
A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados.
En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado.
Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación.
TEMA II.
ANALISIS DE SISTEMAS DE COMPUTACION
TEMA II. Análisis de Sistemas de Computación.
DESARROLLO.
2.1 Conceptos y Análisis:
Es un conjunto o disposición de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Información. Esto se lleva a cabo teniendo en cuenta ciertos principios:
Suscribirse a:
Entradas (Atom)