UNIDAD I CONCEPTOS INTRODUCTORIOS 1.

1 INTRODUCCION A LOS SISTEMAS SISTEMA: Conjunto organizado de partesinterdependientes que interactan entre s formando un todo unitario y complejo. 1.1.1 DESCRIPCION GENERAL Las partes forman las funciones bsicas realizadas por el sistema de las cuales podemos enumerarlas en: Las salidas de un sistema se convierten en entrada de otro, qu e la procesar para convertirla en otra salida, repitindose este ciclo indefinidamente. 1.1.2 TIPOS (21-01-10) Sistemas de Soporte para la Toma de Decisiones (DSS: DecisionSupportSystems): apoyar la toma de decisiones mediante la generacin y evaluacin sistemtica de diferentes alternativas o escenarios de decisin.Un DSS no soluciona problemas, ya que solo apoya al proceso de toma de decisiones. Sistemas de Soporte para la Toma de Decisiones de Grupo (GroupDecisionSupportSystems): cubren el objetivo de l ograr la participacin de un grupo de personas durante la toma de decisiones en ambientes de anonimato y consenso, apoyando decisiones simultneas. Sistemas Expertos de Soporte para la Toma de Decisiones (DEss: ExpertDecisionSupprtSystems): permiten cargar bases de conocimiento que se integran por una serie de reglas de sentido comn para que diferentes usuarios las consulten, apoyen la toma de decisiones, la capacitacin. UNIDAD I Pgina 1 Fundamentos de Desarrollo de Sistemas Sistemas de Informacin para Ejecutivos (EIS: ExecutiveinformationSystems): estn dirigidos a apoyar el proceso de toma de decisiones de los altos ejecutivos de una organizacin, presentado informacin relevante y usando recursos visuales de fcil interpretacin, con el ejecutivo de m antenerlos informados. 1.1.3 CLASIFICACION (22-01-10) ABIERTOS. Son los que intercambian informacin, materiales y energa con su ambiente. CERRADOS. Son auto contenido, no interactan con el medio ambiente. PROBABILISTICO. No se conoce con certeza su comportamiento. DETERMINISTICO. Cualquier estado futuro que adopten puede preciarse con antelacin. 1.2 CICLO DE VIDA DE UN PROYECTO DE SOFTWARE (25-01-10) Expresin de necesidades Esta etapa tiene como objetivo la consecucin de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecer al usuario del sistema a desarrollar (qu, y no cmo, se va a desarrollar). Especificaciones UNIDAD I Pgina 2 Fundamentos de Desarrollo de Sistemas Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomar como punto de partida para esta fase. Su contenido es an insuficiente y lleno de imprecisiones que ser necesario completar y depurar. Anlisis Es necesario determinar qu elementos intervienen e n el sistema a desarrollar, as como su estructura, relaciones, evolucin en el tiempo, detalle de sus funcionalidades. Para ello se enfocar el sistema desde tres puntos de vista relacionados pero diferentes: y y y Diseo Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cmo va a hacerlo (cmo debe ser construido el sistema?; aqu se definirn en detalle entidades y relaciones de las bases de datos, se pasar de casos de uso esenciales a su definicin como casos expandidos reales, se

seleccionar el lenguaje ms adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, libreras, configuraciones hardware, redes). Implementacin Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin y/o para un determinado sistema gestor de bases de datos. Funcional. Esttico. Dinmico. Pruebas El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseo y/o programacin. Es conveniente que sean planteadas al menos tanto a nivel de cada mdulo (aislado del resto), como de integracin del sistema (segn sea la naturaleza del proyecto en cuestin se podrn tener en cuenta pruebas adicionales, p.ej. de rendimiento). Validacin Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase tambin es interesante contar con los use cases, generados a travs de las correspondientes fases previas, que servirn de gua para la verificacin de que el sistema cumple con lo descrito por estos). Mantenimiento y evolucin UNIDAD I Pgina 3 Fundamentos de Desarrollo de Sistemas Finalmente la aplicacin resultante se encuentra ya en fase de produccin (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de m antenimiento, que supondr ya pequeas operaciones tanto de correccin como de mejora de la aplicacin (p.ej. mejora del rendimiento), as como otras de mayor importancia, fruto de la propia evolucin (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto). 1.2.1 PLANIFICACION Y GESTION DEL PROYECTO La gestin de proyectos busca las tcnicas necesarias para planificar, organizar, supervisar y controlar proyectos de software. El objetivo de gestionar proyectos es te ner un producto de alta calidad. Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y su s procesos para aumentar su calidad. La gestin de un proyecto de software se centra en tres partes como son: y y y Personal Problema Proceso PERSONAL: El factor humano es importante en la ingeniera de software. (Es importante tener la capacidad de gesti n del personal con el fin de aumentar la preparacin en la organizacin del software). PROBLEMA: Se establecen los objetivos y se deben considerar soluciones alternativas e identificar las dificultades tcnicas y de gestin. (Con esta informacin es posibl e definir unas estimaciones razonables del costo, una valoracin efectiva del riesgo, una subdivisin realista de las tareas del proyecto o una planificacin del proyecto asequible que proporcione una indicacin fiable del progreso). PROCESO: Proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. (Las actividades estructurales se pueden aplicar a todos los proyectos de software, sin tener en cuenta su tamao o complejidad). El proceso de software lo componen participantes que pueden clasificarse en cinco categoras: y y y y y GESTORES SUPERIORES: definen los aspectos de negocios que a menudo tienen una significativa influencia en el

proyecto. GESTORES TCNICOS DEL PROYECTO: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software. PROFESIONALES: proporcionan las capacidades tcnicas para la ingeniera de un producto CLIENTES: especifica los requisitos para la ingeniera de software. USUARIOS FINALES: interaccionan con el software una vez que se ha entregado para la produccin. UNIDAD I Pgina 4 Fundamentos de Desarrollo de Sistemas En la mayora de los desafos tcnicos, las mtricas nos ayudana entender tanto el procesotcnico que se utiliza para desarrollar un prod ucto, como el propio producto. (El proceso paraintentar mejorarlo, el producto se mide para intentar aumentar su calidad). MTRICAS DEL SOFTWARE. Existen diferentes mtricas estn relacionadas con el desarrollo del software para medir su funcionalidad, complejidad, y eficiencia. MTRICAS TCNICAS: Se centran en las caractersticas de software. (Por ejemplo: lacomplejidad lgica, el grado de modularidad. Mide la estructura del sistema, el cmo est hecho). MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se ajusta el software a losrequisitos implcitos y explcitos del cliente. (Es decir cmo voy a medir para que mi sistema seadapte a los requisitos que me pide el cliente). MTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniera delsoftware. (Es decir que tan productivo va a ser el software que voy a disear). MTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e informacin sobre laforma que la gente desarrolla el software de computadoras y sobre todo el punto de vistah umano de la efectividad de las herramientas y mtodos. (Son las medidas que voy a hacer de mi personal que har el sistema). MTRICAS ORIENTADAS AL TAMAO. Es para saber en qu tiempo voy a terminar elsoftware y cuantas personas voy a necesitar. (Son medidas directas al software y el proceso porel cual se desarrolla). 1.2.3ANALISIS Y DISEO. El anlisis de coste-beneficio es complicado porque los criterios varan segn las caractersticas del sistema a desarrollar, el tamao relativo del proyecto y la recup eracin esperada de la inversin como parte del plan estratgico de la compaa. Adems, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles. ANALISIS:Es indispensable determinar qu elementos van a intervenir en el sistemas a desarrollar, su estructura, relaciones, evolucin a corto o largo plazo, su funcionalidad, los que nos dar una descripcin clara de que sistema vamos a desarrollar, qu funcionalidades va a aportar y qu comportamiento va a tener. Es importante realiza r un anlisis econmico y tcnico (anlisis de costos beneficios), significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema. DISEO: Realizada la etapa anterio r ya se tiene claro que debe hacer el sistema,ahora tenemos que plantear como va a hacerlo (cmo debe ser construido el sistema?;aqu se definirn en detalle entidades y relaciones de las bases de datos, se pasar de casos de uso esenciales a su definici n como casos expandidos reales, se UNIDAD I Pgina 5

Fundamentos de Desarrollo de Sistemas seleccionara el lenguaje ms adecuado, el Sistema Gestor de Base de Datos a utilizar en un caso, libreras, configuraciones hardware, redes, y dems condiciones para el desarrollo del sistema). Para ello nos enfocamos en cuatro etapas: El diseo de los datos. Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software. El Diseo Arqu itectnico. Define la relacin entre cada uno de los elementos estructurales del programa. El Diseo de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con l y con los operadores y usuarios que lo emplea n. El Diseo de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede definir en una sola palabra Calidad. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente.

Ciclo de Vida de un Sistema Informtico Definicin.- Conjunto de etapas que se han de llevar a cabo para crear, explotar y mantener un Sistema Informtico

Fases del Ciclo 1) Definicin de requerimientos 2) Anlisis y diseo del sistema 3) Implementacin (codificacin) 4) Integracin y pruebas 5) Explotacn y mantenimiento

1. Definicin de requerimientos Estudio detallado de la situacin actual del problema a tratar, definicin de los requerimientos que debe cumplir el sistema. 2. Anlisis y diseo del sistema Descomposicin modular de toda la aplicacin, descripcin detallada de cada uno de los mdulos y sus inter-relaciones, todo ello para poder facilitar al mximo la fase de codificacin. 3. Implementacin (codificacin) Cada mdulo como resultado de la fase anterior es traducido a la herramienta o lenguaje apropiado. 4. Integracin y pruebas Verificacin del correcto funcionamiento de cada mdulo y todo el sistema una vez ha sido integrado, detectar errores en la codificacin, definiciones de requerimientos y de diseo. 5. Explotacin y mantenimiento Garantizar el mantenimiento del sistema, correccin de errores detectados en esta fase, adaptacin del sistema a nuevos entornos.

UNIDAD 6
El objetivo primordial de esta unidad es darnos a conocer algunas de las ventajas, desventajas y las cualidades para que pueda ser valida la descomposicin modular como son: Independencia funcional Acoplamiento Cohesin Comprensibilidad Adaptabilidad El diseo modular es una metodologa de desarrollo de programas complejos, que utiliza la filosofa top -down, conocida tambin como diseo descendente o refinamiento por pasos sucesivos Sin dejar a un lado la arquitectura de dominio especifico en el cual se les dar una breve pero significativa introduccin a los modelos genricos y de referencia as como tambin alos distintos tipos que posee cada uno. Esperando que la informacin contenida en esta investigacin sea de vital ayuda no solo para nosotros sino tambin para todas las dems personas que necesiten saber acerca de estos temas y su contenido. 6.1 DESCOMPOSICION MODULAR El diseo modular es una metodologa de desarrollo de programas complejos, que utiliza la filosofa TOP -DOWN, conocida tambin como diseo descendente o refinamiento por pasos sucesivos; o comnmente conocido por los programadores como Divide y Vencers; puesto que enfrenta un problema desde lo abstracto (TOP) hacia lo particular (DOWN). Esta tcnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Mdulos Funcionales. La descomposicin modular contribuye a las caractersticas deseables para la programacin estructurada (y aplicable a nuestro quehacer diario ); y que permite resolver cada mdulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignrsele un nombre y pasar al desarrollo de otro mdulo y, ms adelante retomar el mdulo incompleto para darle solucin al obtener mayor conocimiento sobre dicho proceso, es decir, la solucin del problema no se detiene por falta de conocimiento de algn proceso en particular, esta tcnica se conoce como Estrategia de scarlata Ohara. Por lo consiguiente, podemos concluir que esta metodologa presenta las siguientes ventajas: y Facilita el trabajo en grupos, puesto que la resolucin del problema puede llevarse a cabo por varios programadores en forma paralela, gracias a la divisin del probl ema en diferentes mdulos. y Contribuye a la comprensin y eleva el grado de legibilidad de los algoritmos.

Reduce el tiempo y el coste del desarrollo del software al permitir la reutilizacin de mdulos anteriormente desarrollados en nuevos proyectos, que necesiten trabajar con estos mdulos. Agiliza el mantenimiento de los programas, al permitir la depuracin de errores de forma independiente, con lo cual el software se adapta en mejor forma a su entorno cambiante. Una descomposicin modular debe poseer cie rtas cualidades mnimas para que se pueda considerar suficientemente vlid
y o o o o o

Independencia funcional Acoplamiento Cohesin Comprensibilidad Adaptabilidad

INDEPENDENCIA FUNCIONAL Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada funcin ser realizada en un mdulo distinto. Si las funciones son independientes los mdulos tendrn independencia funcional. Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre mdulos al mnimo. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin. y ACOPLAMIENTO El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la comp lejidad de la interface:
y y o

FUERTE,  POR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro  COMN, se emplea una zona comn de datos a la que tienen acceso varios mdulos o MODERADO,  DE CONTROL, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto implica que un cambio en el formato de datos afecta a todos estos mdulos  POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, rbol, grafo, )
o

DBIL,  DE DATOS, viene dado por los datos que intercambian los mdulos. Es el mejor posible  SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

COHESIN

Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el n de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y relacionados en un mismo mdulo
y o

ALTA


COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de objetos  COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica o MEDIA  COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma secuencial  COHESIN DE COMUNICACIN, elementos que operan con le mismo conjunto de datos de entrada o de salida  COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos o BAJA  COHESIN LGICA, se agrupan elementos que realizan funciones similares. Ejs.: mdulos de E/S o de tratamiento de errores  COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un mdulo no guardan relacin alguna.
y

COMPRENSIBILIDAD Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable:
y o

IDENTIFICACIN: el nombre debe ser adecuado y descriptivo o DOCUMENTACIN: debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el propio cdigo o SIMPLICIDAD:las soluciones sencillas son siempre las mejores

ADAPTABILIDAD La adaptacin de un sistema resulta ms dificil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores para facilitar la adaptabilidad
y o

PREVISIN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner

estos elementos en mdulos independientes, de manera que su modificacin afecte al menor nmero de mdulos posible o ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e implementacin para obtener un conocimiento suficiente del sistema antes de proceder a su adaptacin o CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los documentos afectados DIAGRAMAS DE ESTRUCTURA MODULAR La estructura modular, es decir, el conjunto de mdulos de un programa y la forma en que se invocan unos a otros, se puede representar grficamente mediante un diagrama de estructura modular. Esto es particularmente til si el programa es complejo y consta de muchos mdulos con relaciones complicadas entre s. En el diagrama se representan los mdulos mediante cajas, en cuyo interior figura el nombre del mdulo, unidos por lneas, que representan las interconexiones entre ellos. En cada lnea se puede n escribir los parmetros de invocacin y los datos devueltos por el mdulo invocado. El diagrama de estructura siempre tiene forma de rbol invertido. En la raz figura el mdulo principal, y de l cuelgan el resto de mdulos en uno o varios niveles. En el diagrama tambin se puede representar el tipo de relacin entre los mdulos. Las relaciones posibles se corresponden exactamente con los tres tipos de estructuras bsicas de la programacin estructurada: y Estructura secuencial: cuando un mdulo llama a otro, despus a otro, despus a otro, etc.
y

Estructura selectiva: cuando un mdulo llama a uno o a otro dependiendo de alguna condicin

Estructura iterativa: cuando un mdulo llama a otro (o a otros) en repetidas ocasiones Las tres estructuras de llamadas entre mdulos se representan con tres smbolos diferentes:
y

6.2 ARQUITECTURAS DE DOMINIO ESPECFICO 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. T ambin 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 comu nicacin 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 qu e 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 pued e interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes.
y y

y y

Son modelos de arquitectura los cuales son especficos para algn dominio de aplicacin. Dos tipos de modelos de dominio especfico son: o Modelos Genricos. Estos son abstracciones de un nmero de sistemas reales y que encapsulan las caractersticas principales de estos sistemas. o Modelos de Referencia. Estos son ms abstractos, son modelos idealistas. Proporcionan un significado de informacin con respecto a sistemas de clases y comparacin de diversas arquitecturas. Los modelos genricos usualmente surgen de manera bottom -up surgen de la prctica. Los modelos de referencia son modelos top -down surgen de estudios tericos muy profundos.

MODELOS GENRICOS (1) y Un modelo de Compilador es un ejemplo conocido a travs de otros modelos que existen en dominios de aplicaciones especializadas: o Analizador Lxico o Tabla de Smbolos o Analizador de Sintxis o Analizador Semntico o Generador/Optimizador de Cdigo y Un modelo de compilador genrico puede ser organizado de acuerdo a diversos modelos de arquitectura.

ARQUITECTURAS DE REFERENCIA (1)

y y y y

Los modelos de referencias son derivados del estudio del dominio de una aplicacin, en lugar del estudio de sistemas existentes. Pueden ser utilizados como una base para la implementacin de un sistema o para comparar sistemas diversos. Actan como un estndar, contra el cual los sistemas que pueden ser evaluados. El modelo OSI es un modelo en capas para sistemas de comunicacin, y adems, es un modelo de referencia.

La arquitectura de software es la responsable de la derivacin de un modelo de sistema estructural, un modelo de control y un modelo de descomposicin en subsistemas. Los sistemas grandes rara vez conforman un modelo simple de arquitectura.

Los modelos de estructuracin de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de mquina abstracta. Los modelos de control incluyen control centralizado y modelos manejadores de eventos. Los modelos de descomposicin modular incluyen los modelos orientados a objetos y los modelos de flujo de datos.

Los modelos de dominio especfico son abstracciones sobre el dominio de una aplicacin. Estos pueden ser construidos mediante la abstraccin de sistemas existentes o pueden estar basados en modelos de referencia (ideales).

CONCLUSION En conclusin podemos decir que algo muy importante y de mucho realce en nuestra investigacin fueron algunas de las ventajas de descomposicin modular que son: y Facilita el trabajo en grupos, puesto que la resolucin del problema puede llevarse a cabo por varios programadores en forma paralela, gracias a la divisin del problema en diferentes mdulos. y Contribuye a la comprensin y eleva el grado de legibilidad de los algoritmos. y Reduce el tiempo y el coste del desarrollo del software al permitir la reutilizacin de mdulos anteriormente desarrollados en nuevos proyectos, que necesiten trabajar con estos mdulos. y Agiliza el mantenimiento de los programas, al permitir la depuracin de errores de forma independiente, con lo cual el software se adapta en mejor forma a su entorno cambiante. En cuanto a la estructura de dominio especifico podemos decir que 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 est os servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la

distribucin de las aplicaciones generalmente tiene lugar dentro de una nica organizacin.