Cartmaneses Weblog

Blog Software

INIC IO

ANTIVIRUS

JUEGOS

RIP P EADORES

ANTISP YWARE

P ERSONALIZAC ION

Diseo y arquitectura de productos de software

Hola que tal amigos, en esta ocasin les voy a exponer un tema muy interesante comenzamos con lo siguiente: Como es bien sabido los sistemas informticos estn compuestos por ordenadores y sus perifricos. Entre ellos podemos distinguir dos tipos de subsistemas: Sistemas Hardware: son los elementos materiales, los que se pueden tocar. Sistemas Software: los programas que gobiernan el funcionamiento del computador.

CATEGORAS
Elegir categora

mayo 2013 M X J V S D 2 9 16 23 30 3 10 17 24 31 4 11 18 25 5 12 19 26

1 6 7 8 13 14 15 20 21 22 27 28 29 dic

BUSC AR

BLOGROLL WordPress.com WordPress.org Diseo y arquitectura de productos de software META Registrarse Acceder RSS de las entradas RSS de los comentarios WordPress.com TOP CLICKS lsi.upc.edu/~gomariz/inde | View Show | Create Your Own El objetivo de los sistemas informticos es el tratamiento de la informacin: almacenamiento, elaboracin y presentacin de datos. De esta forma se automatizan determinadas acciones. SOFTWARE RECIENTE BY CARTMANESE Bueno Amig@s ya tenia algo de tiempo que no pub diciembre 10, 2011 Bueno Amig@s ya tenia tiempo que no publicaba algo nuevo en este su Blog por cuestiones escolares haci que ahora tratare de actualizar lo mas seguido posible, esperando que les sirva de algo y sea de su agrado pues trataremos contenidos relacionados con el Mundo Linux y el software libre, haci como tambien una que [...] cartmanese

La idea bsica: *Ensamblaje de partes de software previamente elaboradas *Inspirada en los procesos de produccin de sistemas fsicos Produccin de aviones, vehculos, computadores, aparatos electrnicos, etc. Fundamentada en la Reutilizacin de Software Asume la existencia de una industria de partes

Definicin
Se reeren 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 especcas 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): *Beneficios tcticos de ingeniera: *Reduccin en el tiempo promedio de creacin y entrega de nuevos productos *Reduccin en el nmero promedio de defectos por producto *Reduccin en el esfuerzo promedio requerido para desarrollar y mantener los productos *Reduccin en el costo promedio de produccin de los productos *Incremento en el nmero total de productos que pueden ser efectivamente desplegados y mantenidos

Aspectos fundamentales
*El paradigma de desarrollo de software LPS requiere que las empresas que lo adopten consideren: *Aspectos conceptuales *Conceptos en los que las LPS se fundamentan *Aspectos tecnolgicos *Qu tecnologas son fundamentales para desarrollar y mantener activos y productos de software *Aspectos metodolgicos *Cmo desarrollar y mantener los activos y productos de software *Aspectos organizativos *Cmo debe la empresa organizarse internamente *Aspectos gerenciales *Cmo gestionar los proyectos de desarrollo de activos y productos

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 ujos 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 denidas sobre ese estado. En el modelo de ujos 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 mas fciles de disear, implementar, vericar y probar que los sistemas en paralelo. Las dependencias temporales entre los procesos son difciles de formalizar, controlar y vericar. Es mejor descomponer los sistemas en mdulos, y entonces decidir durante la implementacin si estos necesitan ejecutarse secuencialmente o en paralelo.

6.2 Arquitecturas especfico

de

dominio

Al igual que los modelos generales, tambin pueden usarse los modelos arquitectnicos que son especcos para un dominio particular de aplicacin. Si

bien las instancias de estos sistemas dieren en los detalles, la estructura arquitectnica comn puede realizarse cuando se desarrollan nuevos sistemas. Estos modelos especfico. arquitectnicos se denominan arquitecturas de dominio

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 especcas 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 gura 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 denir 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 signica 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 nales mediante una interfaz grca de usuario.

| View Show | Create Your Own 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 trco (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 especco, 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 s is tema Dis tribuido

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 denir 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, denir 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 inuye 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 ecientes. 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. Dejen sus Comentarios

comentarios

Referencias Bibliogrficas
http://www.mitecnologico.com/Main/FundamentosDeDesarrolloDeSistemas http://www.lsi.upc.edu/~gomariz/index_archivos/IntroduccionSDEnricMartinez.pdf Cargando...

3 respuestas

Edson Shinoda (23:24:27) : Muy buena informacin , me ha salvado; no encontraba nada referente al tema! Gracias! Responder

28 04 2011

cartmanese (21:09:49) : por nada Edson Shinoda ya tenia un rato que no entraba a mi blog, de hecho este tema fue para una tarea escolar, y me alegra a ver podido ayudar Responder

29 04 2011

SPIDERPYN (19:20:22) : MUCHAS GRACIAS POR LA INFORMACIN, EN VERDAD ME FUE DE MUCHA AYUDA. SALUDOS Y MUCHA SUERTE. Responder

9 12 2011

Deja un comentario
Aade tu comentario aqu...

Blog de WordPres s .com. Tema Fres hy por Jide.

Seguir