Ingeniera de software

PRESENTADO POR MARCO ANTONIO DOEZ RUBIO Y LUIS CARLOS LUGO MUOZ
RESUMEN UNIDAD 3

UNIDAD 3: ARQUITECTURAS DE
SOFTWARE
DESCOMPOSICIN MODULAR
Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los
componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin
modular que no inventa nada ya inventado.
Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad
autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los
mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de
los efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y sus efectos se
limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los
errores.
El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener
un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los
beneficios de un sistema modular.
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus
ventajas: claridad, reduccin de costos y reutilizacin.
Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda
considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad
PATRONES DE DISEO
Un patrn de diseo es: una solucin estndar para un problema comn de programacin
Una tcnica para flexibilizar el cdigo hacindolo satisfacer ciertos criterios
Un proyecto o estructura de implementacin que logra una finalidad determinada
Un lenguaje de programacin de alto nivel
Una manera ms prctica de describir ciertos aspectos de la organizacin de un programa
Conexiones entre componentes de programas
La forma de un diagrama de objeto o de un modelo de objeto.
Ejemplos:
Les vamos a presentar algunos ejemplos de patrones de diseo que ya conocen. A cada diseo de
proyecto le sigue el problema que trata de resolver, la solucin que aporta y las posibles
desventajas asociadas. Un desarrollador debe buscar un equilibrio entre las ventajas y las
desventajas a la hora de decidir que patrn utilizar. Lo normal es, como observar a menudo en la
ciencia computacional y en otros campos, buscar el balance entre flexibilidad y rendimiento.
Encapsulacin (ocultacin de datos):
Problema: los campos externos pueden ser manipulados directamente a partir del cdigo
externo, lo que conduce a violaciones del invariante de representacin o a dependencias
indeseables que impiden modificaciones en la implementacin.
Solucin: esconda algunos componentes, permitiendo slo accesos estilizados al objeto.
Desventajas: la interfaz no puede, eficientemente, facilitar todas las operaciones deseadas. El
acceso indirecto puede reducir el rendimiento.
Subclase (herencia):
Problema: abstracciones similares poseen miembros similares (campos y mtodos).
Esta repeticin es tediosa, propensa a errores y un quebradero de cabeza durante el
mantenimiento.

ARQUITECTURA DE DOMINIO ESPECFICO

Existen dos modelos de dominio especfico:
Modelos genricos que son abstracciones de varios sistemas reales.
Modelos de referencia que son modelos abstractos y describen a una clase mayor de
sistemas.
1. Modelo genrico: flujo de datos de un compilador
2. Modelo de referencia: la arquitectura OSI


El reto para el diseo es disear el software y hardware para proporcionar caractersticas
deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos
sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de
sistemas distribuidos.
Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-
servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se
proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se
tratan de forma diferente en estos sistemas. Arquitecturas de objetos distribuidos.
Para esta arquitectura no hay distincin entre servidores y clientes, y el sistema puede ser visto
como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin
entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan
ampliamente en la industria, pero la distribucin de las aplicaciones generalmente tiene lugar
dentro de una nica organizacin. La distribucin soportada es, por lo tanto, intraorganizacional.
Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms adecuadas
para la distribucin interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y
arquitecturas orientadas a servicios.
Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero estn
comenzando a usarse para aplicaciones de empresa. Los componentes en un sistema distribuido
pueden implementarse en diferentes lenguajes de programacin y pueden ejecutarse en tipos de
procesadores completamente diferentes. Los modelos de datos, la representacin de la
informacin y los protocolos de comunicacin pueden ser todos diferentes. Un sistema
distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar
que dichas partes se puedan comunicar e intercambiar datos. El trmino middleware se usa para
hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del
sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar
computacin distribuida. El middleware es un software de propsito general que normalmente se
compra como un componente comercial ms que escribirse especialmente por los desarrolladores
de la aplicacin. Ejemplos de middleware son software para gestionar comunicaciones con bases
de datos, administradores de transacciones, convertidores de datos y controladores de
comunicacin. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximacin
orientada a objetos.
Estos sistemas estn formados por partes independientes pobremente integradas, cada una de las
cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas
partes del sistema pueden tener que responder a eventos independientes. Los objetos software
reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los componentes de
sistemas distribuidos.

DISEO DE SOFTWARE DE ARQUITECTURA
MULTIPROCESADOR
Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma
concurrente, la razn es porque actualmente la mayora de las cpus solo pueden ejecutar un
proceso cada vez. La nica forma de que se ejecuten de forma simultanea varios procesos es tener
varias cpus ya sea en una maquina o en varias en un sistema distribuido.
VENTAJAS
Es econmica
Las computadoras paralelas son inherentes escalables permitiendo actualizarlas para adecuarse a
la necesidad
DESVENTAJAS
Puede ser limitante fsica, existen factores que limitan la velocidad mxima de un procesador
independiente del factor econmico
Las barreras fsicas infranqueables tales como la velocidad de la luz, efectos de tamao, la
capacidad.
DISEO SOFTWARE ARQUITECTURA CLIENTE /
SERVIDOR
Modelo Cliente / Servidor:
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 informacin separando la interfaz del usuario de la gestin de
la informacin. El funcionamiento bsico de este modelo consiste en que un programa cliente
realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta.
Caractersticas de un cliente: En la arquitectura C/S el remitente de una solicitud es conocido
como cliente.
Sus caractersticas son:
Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la
comunicacin (dispositivo maestro o amo).
Espera y recibe las respuestas del servidor.
Por lo general, puede conectase a varios servidores a la vez.
Normalmente interacta directamente con los usuarios finales mediante una interfaz
grfica de usuario.
Caractersticas de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se
conoce como servidor.
Sus caractersticas son:
Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean entonces un
papel pasivo en la comunicacin (dispositivo esclavo).
Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al cliente.
Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos casos el
nmero mximo de peticiones puede estar limitado)
No es frecuente que interacten directamente con los usuarios finales.
Ventajas:
Centralizacin 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 daar el sistema.
Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado.
Fcil mantenimiento
Desventajas:
La congestin del trfico (a mayor nmero de clientes, ms 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 especfico, sobre todo en el lado
del servidor, para satisfacer el trabajo. Por supuesto, esto aumentar el costo

DISEO DE SOFTWARE DE ARQUITECTURA
DISTRIBUIDA
Un sistema distribuido es un sistema de informacin en el cual las funciones se reparten por reas
de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la
organizacin asigna a ese sistema de informacin.
La plataforma de proceso. Una vez diseado el sistema, es el elemento encargado de
proporcionar los recursos fsicos y el software de base para ejecutarlo. Est formado por los
Mainframe, PCs, PDAs, telfonos, etc Los elementos de la conectividad. Son los encargados se
proporcionar el transporte para comunicar e integrar los elementos de la plataforma de proceso.
Son bsicamente las redes y las comunicaciones. El almacenamiento de datos, formado por los
datos en si y los gestores donde
Se localizan. Los elementos de software donde se incluyen las aplicaciones, los servicios
Que ayudan a crearlas y las interfaces que ayudan a usarlas. 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 exposicin pondremos especial cuidado en presentar las caractersticas y posibilidades
las tres ltimas. Sistemas de seguridad. Finalmente, debe realizarse la gestin del sistema como
un conjunto integrado y coordinado a travs de los recursos de direccin y administracin. La
gestin del sistema debe permitir la coexistencia de varios centros de gestin diferentes. Parte
fundamental del sistema de gestin 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 informacin automtica a los gestores de como la realidad se mueve respecto a las
previsiones de los objetivos de negocio en tiempo real. El cuadro de mandos de explotacin
desde donde se centraliza y coordina toda la administracin, supervisin y explotacin del sistema.


DISEO DE SOFTWARE DE TIEMPO REAL
Las computadoras se utilizan para controlar una amplia variedad de sistemas desde maquinas
domesticas sencillas hasta plantas enteras de fabricacin. Estas computadoras interactan
directamente con dispositivos hardware. El software de dichos sistemas es software de tiempo
real embebido que debe reaccionar a eventos generados por el hardware y emitir seales de
control como respuesta a estos eventos. Est embebido en sistemas hardware mquina y debe
responder, en tiempo real, a eventos del entorno del sistema.
Los sistemas de tiempo real embebidos son diferentes de otros tipos de sistemas de software. Su
correcto funcionamiento depende de que el sistema responda a los eventos dentro de un corto
intervalo de tiempo. Se puede definir un sistema de tiempo real como sigue:
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 especificacin temporal.
Los estmulos pueden pertenecer a dos clases:
Estmulos peridicos. Ocurren a intervalos de tiempo predecibles. Por ejemplo, si el sistema debe
examinar un sensor cada 50 milisegundos y realizar una accin (respuesta) dependiendo del valor
de ese sensor (estmulo).

Estmulos aperidicos. Ocurren de forma regular. Normalmente son provocados utilizando el
mecanismo de interrupciones de la computadora. Un ejemplo de dicho estmulo podra ser una
interrupcin para indicar que una transferencia de E/S se ha completado y que los datos estn
disponibles en el bfer.


Un sistema de tiempo real tiene que responder a estmulos que ocurren en diferentes instantes de
tiempo. Por lo tanto, se tiene que organizar su arquitectura para que, tan pronto como se reciba
un estmulo, el control sea transferido al manejador adecuado. Esto no es prctico en programas
secuenciales. Por consiguiente, los sistemas de tiempo real se disean como un conjunto de
procesos concurrentes que cooperan entre s. Con el objetivo de soportar la gestin de estos
procesos, la plataforma de ejecucin para la mayora de los sistemas de tiempo real incluye un
sistema operativo de tiempo real. Las facilidades que proporciona este sistema operativo son
accedidas a travs del sistema de soporten tiempo de ejecucin (run-time system) para el
lenguaje de programacin de tiempo real utilizado.
La generalidad de este modelo estmulo-respuesta de un sistema de tiempo real conduce a un
modelo arquitectnico genrico abstracto en el que hay tres tipos de procesos. Para cada tipo de
sensor, hay un proceso de gestin del sensor; los procesos computacionales calculan la respuesta
requerida para el estmulo recibido por el sistema; los procesos de control de actuadores
controlan el funcionamiento del actuador. Este modelo permite recoger rpidamente los datos
desde el sensor (antes de que la siguiente entrada est disponible) y permite que su
procesamiento y la respuesta asociada al actuador se realicen ms tarde.
La ventaja de utilizar un lenguaje de programacin 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 gestin 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 programacin son ms probables.
Los programas son tambin ms a menudo ms difcil de comprender debido a que las
caractersticas de tiempo real no estn explicitas en el programa.