Sei sulla pagina 1di 8

Diseo y arquitectura de productos de software

Definicin
Se refieren a tcnicas de ingeniera para crear un portafolio de sistemas de software similares, a partir de un conjunto compartido de activos de software, usando un medio comn de produccin (Krueger, 2006) es un conjunto de sistemas de software que comparten un conjunto comn y gestionado de aspectos que satisfacen las necesidades especficas de un segmento de mercado o misin y que son desarrollados a partir de un conjunto comn de activos fundamentales [de software] de una manera prescrita Clements and Northrop, 2002 consiste de una familia de sistemas de software que tienen una funcionalidad comn y alguna funcionalidad variable (Gomma, 2004) Beneficios La entrega de productos de software de una manera ms rpida, econmica y con una mejor calidad las LPS producen mejoras en: Tiempo de entrega del producto (time to market) Costos de ingeniera Tamao del portafolio de productos Reduccin de las tasas de defectos Calidad de los productos Beneficios tcticos y estratgicos (Krueger, 2006):

6.1.-DESCOMPOSICION MODULAR
Despus de que se haya elegido la organizacin del sistema en su totalidad, es necesario decidir la aproximacin a usar para descomponer los subsistemas en mdulos. No existe una distincin rgida entre la organizacin del sistema y la descomposicin modular. Sin embargo, los componentes de los mdulos son normalmente ms pequeos que en los subsistemas, lo cual permite usar estilos alternativos de descomposicin. No hay una distincin clara entre subsistemas y mdulos, pero resulta til pensar sobre ellos de la siguiente forma:
1. Un subsistema es un sistema en si mismo, cuyo funcionamiento no depende de los servicios proporcionados por otros subsistemas. Los subsistemas se componen de mdulos y tienen interfaces definidas, las cuales se usan para comunicarse con otros subsistemas. 2. Un mdulo es normalmente un componente de un sistema que proporciona uno o ms servicios a otros mdulos. A su vez este usa los servicios proporcionados por otros mdulos. Esto no se suele considerar como un sistema independiente. Los mdulos se componen normalmente de varios componentes del sistema ms simples.

Hay dos estrategias principales que se pueden usar cuando se descomponga un subsistema en mdulos.
1. Descomposicin orientada a objetos, en la que se descompone un sistema en un conjunto de objetos que se comunican. 2. Descomposicin orientada a flujos de funciones, en la que se descompone un sistema en mdulos funcionales que aceptan datos y los transforman en datos de salida.

En la aproximacin orientada a objetos, los mdulos son objetos con estado privado y operaciones definidas sobre ese estado. En el modelo de flujos de funciones, los mdulos son transformaciones funcionales. En ambos casos, los mdulos pueden implementarse como componentes secuenciales o como procesos. Debera evitarse tomar decisiones prematuras acerca de la concurrencia en un sistema. La ventaja de evitar el diseo concurrente de un sistema es que los programas secuenciales son ms fciles de disear, implementar,

verificar y probar que los sistemas en paralelo. Las dependencias temporales entre los procesos son difciles de formalizar, controlar y verificar. Es mejor descomponer los sistemas en mdulos, y entonces decidir durante la implementacin si estos necesitan ejecutarse secuencialmente o en paralelo.
6.2 Arquitecturas de dominio especfico

Al igual que los modelos generales, tambin pueden usarse los modelos arquitectnicos que son especficos para un dominio particular de aplicacin. Si bien las instancias de estos sistemas difieren en los detalles, la estructura arquitectnica comn puede realizarse cuando se desarrollan nuevos sistemas. Estos modelos arquitectnicos se denominan arquitecturas de dominio especfico.
1. Modelos genricos. Son abstracciones obtenidas a partir de varios sistemas reales. Encapsulan las caractersticas principales de estos sistemas. Por ejemplo, en sistemas de tiempo real, podra haber modelos arquitectnicos genricos de diferentes tipos de sistemas tales como sistemas de recoleccin de datos o sistemas de monitorizacin. 2. Modelos de referencia. Son ms abstractos y describen una clase ms amplia de sistemas. Constituyen un modo de informar a los diseadores 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 aplicacin. Representan una arquitectura ideal que incluye todas las caractersticas que los sistemas podran incorporar.

No hay, desde luego una distincin rgida entre estos tipos de modelos. Los modelos genricos tambin pueden servir como modelos de referencia. Hacemos aqu la distincin entre ellos debido a que los modelos genricos pueden reutilizase directamente en un diseo. Los modelos de referencia se usan normalmente para comunicar conceptos del dominio y comparar o evaluar posibles arquitecturas. Las arquitecturas de referencia normalmente no se consideran como un camino para la implementacin. En su lugar, su principal funcin es una forma de tratar arquitecturas especficas del dominio y de comparar sistemas diferentes en un dominio. Un modelo de referencia proporciona un vocabulario para realizar comparaciones. Dicho modelo acta como una base, frente a la cual los sistemas pueden ser evaluados. El modelo OSI es un modelo de siete capas para interconexin de sistemas abiertos. El modelo se ilustra en la figura 1.1. Las funciones exactas de las capas no son importantes aqu. En esencia, las capas inferiores estn con la interconexin fsica, las capas intermedias con la transferencia de datos y las capas superiores con la transferencia de informacin de la aplicacin semnticamente significativa como documentos estandarizados. Los diseadores del modelo OSI tuvieron el objetivo prctico de definir una implementacin estndar para que los sistemas acordes con ella pudiesen comunicarse unos con otros.

6.2.1 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 slo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten de forma simultnea varios procesos es tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido.La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta operacin 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 no es algo difcil de entender: ms procesadores significa ms potencia computacional. Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de proceso ejecutndolas en paralelo. Esa es la teora, pero otra historia es la prctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software. Es necesario conocer ampliamente como

estn interconectados dichos procesadores, y la forma en que el cdigo que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al mximo sus prestaciones.

6.2.2 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 distribuyen 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

6.2.3 Diseo Software Distribuido


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.

Elementos de un sistema Distribuido En l se integran. 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. Esta 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 interfcies 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.

6.2.4 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 maquina 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.

Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero en algunos casos, no necesita una respuesta rpida. Por ejemplo, el sistema de bombeo de insulina es un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos peridicos no es necesario responder muy rpidamente 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 estmulos recibidos por el sistema, las respuestas asociadas y el tiempo en que dichas respuestas deben producirse. 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. Los estmulos peridicos en un sistema de tiempo real son generados normalmente por sensores asociados al sistema. Estos proporcionan informacin sobre el estado del entorno del sistema. Las respuestas son dirigidas a un conjunto de actuadores que controlan algn equipo como una bomba, que influye en el entorno del sistema. Los estmulos aperidicos pueden generarse por actuadores o por sensores. A menudo indican alguna condicin excepcional como un fallo en el hardware, que debe ser manejado por el sistema. Este modelo sensor-sistema actuador de un sistema de tiempo real embebido se ilustra en la figura 2.2. 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 estimulo 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 arquitectura genrica puede instanciarse a varias arquitecturas de aplicaciones diferentes que amplan el conjunto de arquitecturas. Las arquitecturas de aplicaciones de tiempo real son instancias de la arquitectura conducida por eventos en la cual el estimulo, directa o indirectamente. Provoca la generacin de eventos. Los lenguajes de programacin desarrollados para sistemas de tiempo real tienen que incluir facilidades para acceder al hardware del sistema, y debera ser posible predecir la duracin de operaciones particulares realizadas en estos leguajes.los sistemas de tiempo real duros todava se programan algunas veces en ensamblador para que puedan cumplirse los estrechos plazos de tiempo (deadline). Los lenguajes a nivel de sistemas como C, que permiten generar cdigo eficiente tambin se utilizan en general.

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.
6.2.2.- ARQUITECTURAS CLIENTE SERVIDOR.

Esta arquitectura un modelo para el desarrollo de sistemas de informacin en el que las transacciones se dividen en procesos independientes que cooperan entre s para intercambiar informacin, servicios o recursos. Se denomina cliente al proceso que inicia el dilogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece slo lo particular de cada usuario.Los clientes realizan generalmente funciones como: Manejo de la interfaz de usuario. Captura y validacin de los datos de entrada. Generacin de consultas e informes sobre las bases de datos. Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestin de perifricos compartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces de comunicaciones con otras redes de rea local o extensa.

Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y ste le responde proporcionndolo. Normalmente, pero no necesariamente, el cliente y el servidor estn ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo. Entre las principales caractersticas de la arquitectura cliente/servidor se pueden destacar las siguientes: El servidor presenta a todos sus clientes una interfaz nica y bien definida. El cliente no necesita conocer la lgica del servidor, slo su interfaz externa. El cliente no depende de la ubicacin fsica del servidor, ni del tipo de equipo fsico en el que se encuentra, ni de su sistema operativo. Los cambios en el servidor implican pocos o ningn cambio en el cliente. 6.2.3.- DISEO DE SOFTWARE DISTRIBUIDO Sistemas cuyos componentes hardware y software, que estn en ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo. Se establece la comunicacin mediante un protocolo prefijado por un esquema cliente-servidor. Caractersticas: Concurrencia.- Esta caracterstica de los sistemas distribuidos permite que los recursosdisponibles en

la red puedan ser utilizados simultneamente por los usuarios y/o agentes que interactan en la red. Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realizacin de una tarea, no tienen una temporizacin general, esta ms bien distribuida a los componentes. Fallos independientes de los componentes.- Cada componente del sistemapuede fallar independientemente, con lo cual los dems pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando. Evolucin: Procesamiento central (Host).- Uno de los primeros modelos de ordenadores interconectados, llamados centralizados, donde todo el procesamiento de la organizacin se llevaba a cabo en una sola computadora, normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores personales. Los problemas de este modelo son: Cuando la carga de procesamiento aumentaba se tena que cambiar el hardware del Mainframe, lo cual es ms costoso que aadir ms computadores personales clientes o servidores que aumenten las capacidades. El otro problema que surgi son las modernas interfases grficas de usuario, las cuales podan conllevar a un gran aumento de trfico en los medios de comunicacin y por consiguiente podan colapsar. 6.2.4.- DISEO DE SOFTWARE DE TIEMPO REAL. El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al mbito del problema en un tiempo dictado por el mbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las caractersticas del sistema operativo, por los requisitos de la aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo. La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos. Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de computacin de tiempo real. La computadora esta controlando algo que interactua con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin. Los sistemas de tiempo real generan alguna accin en respuesta a sucesos externos. Para realizar esta funcin, ejecutan una adquisicin y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real estn frecuentemente dedicados a una nica aplicacin. Durante muchos aos, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reduccin del coste del hardware ha hecho posible para la mayora de las compaas, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatizacin industrial, investigacin medica y cientfica, grficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentacin industrial. Consideraciones Sobre los Sistemas Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, par conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.

El problema para los sistemas de tiempo real es realzar la asignacin importante como la funcin, pero las decisiones de asignacin relativas al rendimiento son frecuentemente difciles de hacer con seguridad. Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo? Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real.

Potrebbero piacerti anche