NOMBRE DE LA ESCUELA: INSTITUTO UNIVERSITARIO DE MÉXICO
NOMBRE DEL ALUMNO: LILIA LÓPEZ ALVARADO
MATERIA: ANALISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN
CATEDRATICO: ISC.ADRIÁN IBARRA RUÍZ.
TEMA: DISEÑO Y ARQUITECTURA DE PRODUCTOS DE SOFTWARE.
TAPACHULA, CHIAPAS A; 03
DE MAYO DEL 2014
DISEÑO Y ARQUITECTURA DE PRODUCTOS DE SOFTWARE
4.1 DESCOMPOSICION
MODULAR
Después de que se haya elegido la organización del
sistema en su totalidad, es necesario decidir la aproximación a usar para
descomponer los subsistemas en módulos. No existe una distinción rígida entre
la organización del sistema y la descomposición modular. Sin embargo, los
componentes de los módulos son normalmente más pequeños que en los subsistemas,
lo cual permite usar estilos alternativos de descomposición.
- Un subsistema es un sistema en si mismo, cuyo funcionamiento no depende de los servicios proporcionados por otros subsistemas. Los subsistemas se componen de módulos y tienen interfaces definidas, las cuales se usan para comunicarse con otros subsistemas.
- Un módulo es normalmente un componente de un sistema que proporciona uno o más servicios a otros módulos. A su vez este usa los servicios proporcionados por otros módulos. Esto no se suele considerar como un sistema independiente. Los módulos se componen normalmente de varios componentes del sistema más simples.
Existen dos estrategias principales que se pueden
usar cuando se descomponga un subsistema en módulos.
- Descomposición orientada a objetos, en la que se descompone un sistema en un conjunto de objetos que se comunican.
- Descomposición orientada a flujos de funciones, en la que se descompone un sistema en módulos funcionales que aceptan datos y los transforman en datos de salida.
4.2 ARQUITECTURAS DE DOMINIO
ESPECÍFICO
Los modelos arquitectónicos se denominan arquitecturas de dominio específico.
- Modelos genéricos. Son abstracciones obtenidas a partir de varios sistemas reales. Encapsulan las características principales de estos sistemas. Por ejemplo, en sistemas de tiempo real, podría haber modelos arquitectónicos genéricos de diferentes tipos de sistemas tales como sistemas de recolección de datos o sistemas de monitorización.
- Modelos de referencia. Son más abstractos y describen una clase más amplia de sistemas. Constituyen un modo de informar a los diseñadores sobre la estructura general de esta clase de sistemas. Los modelos de referencia normalmente se obtienen a partir de un estudio del dominio de la aplicación. Representan una arquitectura ideal que incluye todas las características que los sistemas podrían incorporar.
Las arquitecturas de referencia normalmente no se
consideran como un camino para la implementación. En su lugar, su principal
función es una forma de tratar arquitecturas específicas del dominio y de
comparar sistemas diferentes en un dominio. Un modelo de referencia proporciona
un vocabulario para realizar comparaciones. Dicho modelo actúa como una base,
frente a la cual los sistemas pueden ser evaluados.
4.2.1
DISEÑO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR
Un sistema multiproceso o multitarea es aquel que
permite ejecutar varios procesos de forma concurrente, la razón es porque
actualmente la mayoría de las CPUs sólo pueden ejecutar un proceso cada vez. La
única forma de que se ejecuten de forma simultánea varios procesos es tener
varias CPUs (ya sea en una máquina o en varias, en un sistema distribuido. La
ventaja de un sistema multiproceso reside en la operación llamada cambio de
contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro
proceso y volver a colocar el primero sin que se entere de nada.
El multiproceso significa más potencia
computacional. Un conjunto de tareas puede ser completado más rápidamente si
hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría,
pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que
requiere unos profundos conocimientos tanto del hardware como del software. Es
necesario conocer ampliamente como están interconectados dichos procesadores, y
la forma en que el código que se ejecuta en los mismos ha sido escrito para
escribir aplicaciones y software que aproveche al máximo sus prestaciones.
Este modelo es un prototipo de sistemas
distribuidos que muestra como los datos y el procesamiento se distribuye a lo
largo de varios procesadores. Es una forma de dividir las responsabilidades de
un sistema de información separando la interfaz del usuario de la gestión de la
información. El funcionamiento básico de este modelo consiste en que un
programa cliente realiza peticiones a un programa servidor, y espera hasta que
el servidor de respuesta. Características de un cliente En la arquitectura C/S
el remitente de una solicitud es conocido como cliente. Sus características
son:
Ø Es quien inicia solicitudes o
peticiones, tienen por tanto un papel activo en la comunicación (dispositivo
maestro o amo).
Ø Espera y recibe las respuestas
del servidor.
Ø Por lo general, puede conectase a
varios servidores a la vez.
Ø Normalmente interactúa
directamente con los usuarios finales mediante una interfaz gráfica de usuario.
VENTAJAS: Centralización del control: Los
accesos, recursos y la integridad de los datos son controlados por el servidor
de forma que un programa cliente defectuoso o no autorizado no pueda dañar el
sistema. Escalabilidad: Se puede
aumentar la capacidad de clientes y servidores por separado. Fácil mantenimiento.
DESVENTAJAS: La congestión del tráfico (a
mayor número de clientes, más problemas para el servidor). El software y el hardware de un servidor son
generalmente muy determinantes. Un hardware regular de un ordenador personal
puede no poder servir a cierta cantidad de clientes. Normalmente se necesita
software y hardware específico, sobre todo en el lado del servidor, para
satisfacer el trabajo. Por supuesto, esto aumentará el costo
Un sistema distribuido es un sistema de información
en el cual las funciones se
reparten por áreas de trabajo diferentes que trabajan de forma coordinada para
asumir los objetivos que la organización asigna a ese sistema de información.
reparten por áreas de trabajo diferentes que trabajan de forma coordinada para
asumir los objetivos que la organización asigna a ese sistema de información.
ELEMENTOS DE UN SISTEMA
DISTRIBUIDO
Una vez diseñado el sistema, es el elemento
encargado de proporcionar los recursos físicos y el software de base para
ejecutarlo. Esta formado por los Mainframe, PC’s, PDA’s, teléfonos. Los
elementos de la conectividad. Son los encargados se proporcionar el
transporte para comunicar e integrar los elementos de la plataforma de
proceso. Son básicamente las redes y las comunicaciones. El
almacenamiento de datos, formado por los datos en si y los gestores donde se
localizan.
En este componente se integran las
arquitecturas posibles para crearlas: centralizada, Batch, transaccional,
cliente / servidor basado en sistema operativo, cliente / servidor basada
en Internet y aplicaciones Web Internet. A lo largo de
la exposición pondremos especial cuidado en presentar las características
y posibilidades las tres últimas. Sistemas de
seguridad. Finalmente, debe realizarse la gestión del sistema como un
conjunto integrado y coordinado a través de los recursos de dirección y
administración. La gestión del sistema debe permitir la coexistencia de
varios centros de gestión diferentes. Parte fundamental del sistema de
gestión es el cuadro de mandos. Hay dos cuadros de mandos
diferentes:
El cuadro de mandos de seguimiento de
los objetivos de negocio pensado para proporcionar información automática
a los gestores de como la realidad se mueve respecto a las previsiones de
los objetivos de negocio
en “tiempo real”.
en “tiempo real”.
El cuadro de mandos de explotación desde
donde se centraliza y
coordina toda la administración, supervisión y explotación del sistema.
coordina toda la administración, supervisión y explotación del sistema.
4.2.4 DISEÑO DE SOFTWARE DE
TIEMPO REAL
Un sistema de tiempo real es un sistema software
cuyo correcto funcionamiento depende de los resultados producidos por el mismo
y del instante del tiempo en el que se producen estos resultados. Un sistema de
tiempo real blando (soft) es un sistema cuyo funcionamiento se degrada si los resultados
no se producen de acuerdo con los requerimientos temporales especificados. Un
sistema de tiempo real duro (hard) es un sistema cuyo funcionamiento es
incorrecto si los resultados no se producen de acuerdo con la especificación
temporal.
Una respuesta a tiempo es un factor importante en
todos los sistemas embebidos, pero en algunos casos, no necesita una respuesta
rápida. Por ejemplo, el sistema de bombeo de insulina es un sistema embebido.
Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos
periódicos no es necesario responder muy rápidamente a los eventos externos.
Una forma de ver un sistema de tiempo real es como
un sistema de estimulo/respuesta. Dando un determinado estimulo de entrada, el
sistema debe producir la correspondiente salida. Se puede, por lo tanto,
definir el comportamiento de un sistema de tiempo real haciendo una lista de
los estímulos recibidos por el sistema, las respuestas asociadas y el tiempo en
que dichas respuestas deben producirse.
Los estímulos pueden pertenecer a dos clases:
Estímulos periódicos. Ocurren a intervalos de
tiempo predecibles. Por ejemplo, si el sistema debe examinar un sensor cada 50
milisegundos y realizar una acción (respuesta) dependiendo del valor de ese
sensor (estímulo).
Estímulos aperiódicos. Ocurren de forma regular. Normalmente son provocados utilizando el mecanismo de interrupciones de la computadora. Un ejemplo de dicho estímulo podría ser una interrupción para indicar que una transferencia de E/S se ha completado y que los datos están disponibles en el búfer.
Estímulos aperiódicos. Ocurren de forma regular. Normalmente son provocados utilizando el mecanismo de interrupciones de la computadora. Un ejemplo de dicho estímulo podría ser una interrupción para indicar que una transferencia de E/S se ha completado y que los datos están disponibles en el búfer.
Los estímulos periódicos en un sistema de tiempo
real son generados normalmente por sensores asociados al sistema. Estos
proporcionan información sobre el estado del entorno del sistema. Las
respuestas son dirigidas a un conjunto de actuadores que controlan algún equipo
como una bomba, que influye en el entorno del sistema. Los estímulos
aperiódicos pueden generarse por actuadores o por sensores. A menudo indican
alguna condición excepcional como un fallo en el hardware, que debe ser
manejado por el sistema.
Un sistema de tiempo real tiene que responder a
estímulos que ocurren en diferentes instantes de tiempo. Por lo tanto, se tiene
que organizar su arquitectura para que, tan pronto como se reciba un estímulo,
el control sea transferido al manejador adecuado. Esto no es práctico en
programas secuenciales. Por consiguiente, los sistemas de tiempo real se
diseñan como un conjunto de procesos concurrentes que cooperan entre sí. Con el
objetivo de soportar la gestión de estos procesos, la plataforma de ejecución
para la mayoría de los sistemas de tiempo real incluye un sistema operativo de
tiempo real. Las facilidades que proporciona este sistema operativo son
accedidas a través del sistema de soporten tiempo de ejecución (run-time
system) para el lenguaje de programación de tiempo real utilizado.
La ventaja de utilizar un lenguaje de programación
de sistemas de bajo nivel como C es que permite el desarrollo de programas muy
eficientes. Sin embargo, estos lenguajes no incluyen construcciones para
soportar la concurrencia o la gestión de recursos compartidos. Estas se
implementan atreves de llamadas al sistema operativo de tiempo real que no
pueden ser comprobados por el compilador, de forma que los errores de programación
son más probables. Los programas son también más a menudo más difícil de
comprender debido a que las características de tiempo real no están
explicitas en el programa.
