MODELO BASADO EN COMPONENTES

Un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicación está ya preestablecido. Al unirse las partes, obtenemos música para nuestros oídos.

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.

Desarrollo

basado en componentes

El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases).

El modelo de desarrollo basado en componentes conduce ala reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reducción del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un índice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software.

El proceso unificado de desarrollo de software representa un número de modelos de desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje de modelado unificado define los componentes. Utilizando una combinación

Beneficios del Desarrollo de Software Basado en Componentes El uso de este paradigma posee algunas ventajas: 1. 3. Simplifica el mantenimiento del sistema. el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios. Cuando existe un débil acoplamiento entre componentes. y en los problemas que se plantean en este tipo de entornos. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.del desarrollo ¡ncremental e interactivo. En este artículo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen. como un paso hacia una verdadera ingeniería. con especial énfasis en los estándares internacionales que los definen y regulan. la atención de la comunidad científica comienza a centrarse en los aspectos extrafuncionales y de calidad. el desabollador es libre de actualizar y/o agregar componentes según sea necesario. Nos lleva a alcanzar un mayor nivel de reutilización de software. . 2. sin afectar otras partes del sistema. Una vez que la mayor parte de los aspectos funciona les de esta disciplina comienzan a estar bien definidos. Reutilización del software. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software. Simplifica las pruebas.

tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio. Muestra dónde se ubican los componentes. Puede representar los enlaces de redes. sus dependencias. su comunicación su ubicación y otras condiciones.4. También se puede crear a partir de una colección de componentes más peque ños. un componente está compuesto por numerosas clases y paquetes de clases internos. Los componentes y los Nodos Un diagrama de despliegue muestra el despliegue físico del sistema en un ambiente de producción (o de prueba). Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización. máquinas o hardware. Típicamente. Interfaces Los componentes también pueden exponer las interfaces. Mayor calidad. Estas son los puntos visibles de entrada o los servicios que un co mponente está ofreciendo y dejando disponibles a otros componentes de software y clases. Restricciones . en qué servidores. El Diagrama de Componentes El diagrama de componentes muestra la relación entre componentes de software. la calidad de una aplicación basada en componentes mejorará con el paso del tiempo La Notación de Componentes Un componente puede ser algo como un control Actives.

Conclusión Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software. las post -condiciones indican lo que debe ser verdadero después de que un componente haya realizado algún trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente. Empresas como Microsoft entendieron el potencial de esta metodología hace años y hoy nos ofrecen nuevas iniciativas y herramientas que buscan llevar al proceso de construcción de softwar e hacia el sitial privilegiado en el que debió colocarse desde un principio. y nos asombramos cada vez más al darnos cuenta de que este solo es el inicio. Análisis del riesgo Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. vemos los increíbles avances que hemos logrado en la comprensión de la forma correcta de reutilizar el software y el conocimiento existente. El desarrollo de software basado en componentes desde siempre fue la idea revolucionaria que nos llevó a pensar que sí era posible el construir software de calidad en corto tiempo y con l a misma calidad que la mayoría de las industrias de nuestro tiempo. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna función.Los componentes pueden restricciones asignadas que indican el entorno en el que operan. . El desarrollo de software basado de componentes se convirtió en el pilar de la Revolución Industrial del Software y se proyecta hoy en día en diversas nuevas formas de hacer software de calidad con los costos más bajos del mercado y en tiempos que antes eran impensables. que traerá beneficios inmensos para todos. Al mirar hacia atrás.

Ensenada.000 temas que lo componen. www. Exige una cierta habilidad en los analistas (es bastante difícil). Estoy invitando a todos los maestros y profesionales de esta area y/o carrera a colaborar construyendo este sitio dedicado a esta hermosa y util profesion aportando el material apropiado a cada uno de los mas de 1.MiTecnologico. .com es un esfuerzo personal y de muchos amigos de MEXICO y el Mundo Hispano por devolver algo de lo mucho que hemos recibido en el proceso de la educacion superior. Tambien los invito a aportar material a los mas de 30. Une los mejores elementos de los restantes modelos.Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento Desventajas: Genera mucho tiempo en el desarrollo del sistema .000 temas que constituyen las 30 carreras profesionales que se imparten en los Institutos Tecnologicos de Mexico y se encuentran en este sitio.Planificar Revisamos todo lo hecho. y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa.Modelo costoso Requiere experiencia en la identificación de riesgos Inconvenientes Genera mucho trabajo adicional. Mexico . BC. Ventajas El análisis del riesgo se hace de forma explícita y clara. evaluándolo. saludos Prof Lauro Soto.Reduce riesgos del proyecto .

Este proceso de industrialización ha dado ya sus inicios con implementaciones como la plataforma .net en verdaderas piezas de ensamblaje. no solo nos aseguramos de no cometer los mismos errores del pasado. la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Introducción 2. los nuevos paradigmas como las Fábricas de Software proveen de los medios para hacer la transición desde el 'hacer a mano' hacia la fabricación o manufactura de software. Fábricas de Software: el Nuevo Paradigma 6. habremos de utilizarlo desde el mismo instante en que escribamos nuestra primera línea de código. con bases firmes y calidad incomparable. la cual se centra en el diseño y construcción . Al comparar la evolución del ambiente de IT con el crecimiento de las metrópolis actuales. podemos entender el origen de muchos problemas que se han presentado históricamente en la construcción de software y vislumbrar las posibles y probables soluciones que nos llevarán hacia la industrialización del software moderno. Industrialización del Software a través de la Plataforma . uno de los primeros que se nos enseñan a quienes entramos al mundo del desarrollo de software. Asimismo. se concibió y perfeccionó lo que hoy conocemos como Ingeniería de Software Basada en Componentes (ISBC).net. convirtiendo a los componentes . deben ser construidos en tiempo récord y deben cumplir con los estándares más altos de calidad. El desarrollo de software basado en componentes permite reutilizar piezas de código preelaborado que permiten realizar diversas tareas. Introducción La complejidad de los sistemas computacionales actuales nos ha llevado a buscar la reutilización del software existente. Si hay algo que ha aprendido el ser humano desde tiempos muy antiguos es a reutilizar el conocimiento existente para sus cada vez más ambiciosas empresas. Beneficios del Desarrollo de Software basado en Componentes 3. Para hacer frente a esto. Conclusión 1. Los avances y mejoras presentados en esta plataforma van mucho más allá de las implementaciones iniciales como COM y CORBA. ideas y artefactos. En efecto. conllevando a diversos beneficios como las mejoras a la calidad. al reutilizar trozos de experiencias.Desarrollo de Software basado en Componentes Por Julio Casal Terreros Contenido 1. en un estilo muy similar a las líneas de ensamblaje modernas. Los sistemas de hoy en día son cada vez más complejos. sino que logramos construir cosas cada vez más grandes y maravillosas. la cual impulsa la idea de industrializar el software utilizando tecnologías de componentes. Este concepto de la reutilización.net 5. Metrópolis: Analogía de la Evolución del Software basado en Componentes 4.

así como las iniciativas más innovadoras como las Fábricas de Software de Microsoft. Los componentes son los "ingredientes de las aplicaciones". . en la presente década. el optar por comprar componentes de terceros en lugar de desarrollarlos. muchos se preguntan día a día el por qué son tan pocos los que realmente alcanzan el éxito siguiendo esta filosofía. Principio de la página 2. y es justo hora. la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.de sistemas computacionales que utilizan componentes de software reutilizables. Esta ciencia trabaja bajo la filosofía de "comprar. Para este momento. Simplifica el mantenimiento del sistema. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados. La adición de una pieza dada de funcionalidad tomará días en lugar de meses ó años. Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente con sus pares. Las analogías que nos han llevado a estudiar a los sistemas comparándolos con las complejas metrópolis de la actualidad. El uso de este paradigma posee algunas ventajas: 1. hasta ahora solo hemos tanteado un poco con las posibilidades del software basado en componentes. el desarrollador es libre de actualizar y/o agregar componentes según sea necesario. En realidad. que la industria del software despegará y se perfeccionará para estar a la par de cualquier otra industria del medio. Ciclos de desarrollo más cortos. de la misma forma. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. no construir". Nos lleva a alcanzar un mayor nivel de reutilización de software. Mayor calidad. posee algunas ventajas: 1. obtenemos música para nuestros oídos. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización. son la clara representación de que estamos a punto de presenciar un nuevo gran cambio en la forma como pensamos en software. ya muchos conocen las ventajas de este enfoque de desarrollo y. 4. sin afectar otras partes del sistema. una idea que ya es común en casi todas las industrias existentes. Cuando existe un débil acoplamiento entre componentes. 2. Beneficios del Desarrollo de Software basado en Componentes En esencia. 3. Al unirse las partes. El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. las conexiones son estándar y el protocolo de comunicación está ya preestablecido. un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar (1) . pero relativamente nueva en lo que a la construcción de software se refiere. que se juntan y combinan para llevar a cabo una tarea (2) . Reutilización del software. De la misma manera. Simplifica las pruebas.

las ciudades y las casas de software comparten un pasado muy similar. con aplicaciones creadas independientemente y sin mayor necesidad de interacción entre ellas. se vuelve ahora completamente asequible. Ahora la gente ya puede navegar y visitar aplicaciones muy distantes. Al comprender la evolución de las ciudades actuales. Pero lo que aún es difícil es hacer que estos datos trabajen entre distintas aplicaciones. Funcionalidad mejorada.2. el retorno sobre la inversión puede ser más favorable que desarrollando los componentes uno mismo. en la cual compara la evolución de las tecnologías de la información con la forma como las ciudades de Estados Unidos han evolucionado durante los 2 últimos siglos. Principio de la página 3. la fabricación y llevaron a la urbanización de la vida. Se inició entonces una carrera por asegurar que los artículos trabajen entre sí y cumplan estándares de compatibilidad. 3. Por muchos años. Así. Para usar un componente que contenga una pieza de funcionalidad. Cada aplicación separada e . las casas de software evolucionaron gradualmente mientras nuevas aplicaciones fueron construidas y luego extendidas. Usando correctamente esta estrategia. así como entre múltiples casas de software alrededor del mundo. A mediados del siglo XIX. Estos cambios en expectativas y capacidades alimentaron la explosión del comercio. pues ambas empezaron en ambientes que se desarrollaron aisladamente. Pero recientemente se ha vuelto muy práctico el interconectar tanto las aplicaciones dentro de una casa de software. Dado que estas aplicaciones no estaban conectadas. uno de los arquitectos con mayor experiencia en Microsoft. tal y como la conocemos hoy. En estas ciudades existían edificios con poca o ninguna conexión entre ellos. una funcionalidad que sería impráctica de implementar en la empresa.Casas de Software Las ciudades evolucionaron gradualmente como lugares para hacer comercio y manufactura. Esto permitió que las personas y distintos artículos empezaran a trasladarse de una forma que no era posible anteriormente. no había mayores consecuencias para aquello. Este desarrollo independiente conllevó a diferencias de cultura con respecto a la forma como se hacían las cosas. las vías de ferrocarril conectaron la mayor parte de las ciudades en los Estados Unidos. Cantidades cada vez más grandes de información son fácilmente transmitidas entre aplicaciones. ha desarrollado recientemente una metáfora llamada Metrópolis (4) . más no sus detalles internos. Como lo menciona Helland. Para entender entonces lo que está ocurriendo en este momento con el ambiente IT hay que explorar 6 facetas de esta analogía: Ciudades . Mejor ROI. las casas de software han desarrollado aisladamente. estilo y forma de hacer cosas (Ver Figura 1). Las ciudades tenían un contacto muy limitado con sus ciudades aledañas y desarrollaron su propia cultura. podemos darnos una idea del futuro promisorio que tiene el desarrollo de software basado en componentes. Metrópolis: Analogía de la Evolución del Software basado en Componentes Pat Helland (3) . De la misma forma. solo se necesita entender su naturaleza.

a compartir servicios y a pensar en medios creativos para alcanzar eficiencias.independiente de sus similares en la misma casa de software. Están integradas verticalmente y usualmente no aceptan el trabajo de otras aplicaciones como entrada (Ver Figura 4): . estilo y forma de hacer las cosas (Ver Figura 2): Figura 1: Evolución de las ciudades. Asimismo. Figura 2: Evolución de las casas de software. Fábricas y Edificios . Cada casa de software tenía su propia cultura. las presiones económicas están cambiando nuestras casas de software. Si uno quería un par de zapatos. armaban el ensamblado e incluso lo vendían. Producen datos procesados independientemente unos de otros. Mientras se construyen nuevas aplicaciones y se renuevan las más antiguas. Muchas de nuestras aplicaciones actuales son como aquellas fábricas. Esta no era la forma más eficiente de fabricar bienes y los ítems fabricados eran caros y usualmente no de la mejor calidad (Ver Figura 3). Volver al texto. ya que fue la oportunidad económica la que realmente llevó a las ciudades a la modernización. la manufactura típicamente era simple e independiente. Los bienes producidos estaban limitados tanto por las necesidades del mercado local. como por la sofisticación del proceso de manufactura. cómo conectarlas y cómo dividirlas de manera que se maximice la reusabilidad de las mismas. los cuales se entregan en 'mercados' limitados. Volver al texto. Las fábricas producían todas las partes del ensamblado final. tenía que irse a la fábrica de zapatos. Este es el reto al que todos nos vemos enfrentados en la actualidad.Aplicaciones En los primeros años del siglo XIX. Las presiones económicas cambiaron nuestras ciudades. hay que considerar cómo enlazarlas a la infraestructura compartida.

Pronto esto implicaría cambios en los procesos de negocios. Con una demanda arrolladora de transporte. Tanto para las fábricas como para las aplicaciones. . Volver al texto. el movimiento de los artículos despertó la expectativa de que las cosas funcionen en conjunto. JPEGs. El navegador le permitió a la persona el transportarse para interactuar directamente con una aplicación distante. aunque la independencia es esencial. Pero. haciendo muy limitados los procesos de negocios a través del Internet. sino que ahora los comerciantes podían vender artículos de formas nunca antes pensadas. ya que es a través de la reutilización del trabajo de los demás que uno logra cumplir su trabajo con éxito y es justamente la demanda que ejercen los demás sobre nuestro trabajo lo que nos da el estímulo económico para seguir existiendo. Los negocios se especializaron e independizaron. la independencia es esencial. Se invirtieron montos enormes en navegación. La componentización les permitió a los artesanos enfocarse en sus principales competencias. MP3s y chat. Antes del ferrocarril simplemente no importaba si los bienes de un fabricante eran incompatibles con los de otro fabricante. Volver al texto. Sin embargo. El ferrocarril alteró profundamente la manufactura. Figura 6: Comunicaciones. Las nuevas conexiones implicaron nuevos cambios en la estandarización de los artículos y los datos. eventualmente todo Estados Unidos estaba interconectado por ferrocarril. correo electrónico. no se pueden olvidar las ventajas de la interconexión.Comunicaciones A mediados del siglo XIX llegó el ferrocarril. Figura 4: Aplicaciones. Se hicieron enormes cantidades de dinero moviendo personas.Figura 3: Fábricas y edificios. Al final del siglo XX llegó Internet. Pero más importante aún. Transporte . el mismo permitió que los fabricantes locales produjeran bienes más sofisticados y de mayor calidad. Volver al texto. Volver al texto. en lugar de tener que entender los diversos procesos necesarios para producir todo un ensamblado sofisticado. carbón y trigo de un lugar a otro. Figura 5: Transporte. Al bajar los costos de transportar las partes fabricadas. Uno no puede terminar su trabajo si se necesita hacer que todo trabaje en conjunto perfectamente. No solo que la gente empezó a viajar a nuevos lugares para conocer nuevas culturas. Se tendieron los hilos para permitir la navegación y el movimiento de las formas más simples de datos. el movimiento de los datos aún no funciona bien en conjunto.

Las compañías que produjeron las partes con un alto grado de precisión tuvieron éxito. Ensamblados Fabricados . Esto significa estandarizar la funcionalidad de conceptos de negocio como un 'cliente' o una 'orden de compra'. Pero para finales del siglo XVIII la idea ya se había expandido entre los fabricantes y se produjeron todo tipo de estándares para las partes comunes. lo que tenían un proceso menos consistente. Al crear ensamblados con los mejores componentes disponibles. Sin embargo. El resultado de este cambio será un boom económico para las compañías que sobrevivan a él y un dramático mejoramiento para el diario vivir de las personas.Datos Estructurados A inicios del siglo XVIII los bienes se hacían a mano. el mismo demandará el intercambio de datos en un futuro cercano. Pioneros como Honore LeBlanc y Eli Whitney propusieron la idea de crear partes estandarizadas en el proceso de manufactura. se ajustaba la cerradura de alguna manera para que permita el paso de la llave. fracasaron (Ver Figura 7 y Figura 8): Figura 7: Bienes fabricados. Había tamaños y medidas para los artículos. de la misma forma como quienes hacen camisas no producen sus propios botones. Las compañías de hoy en día . se pudieron realizar masivas producciones de todo tipo de artículos. esta era una estandarización hacia dentro de las empresas.Empresas Virtuales La mayoría de los fabricantes de bicicletas no producen llantas. Hoy en día aún tenemos estructuras de datos no estandarizadas. Volver al texto. con la expectativa de que aquellos producidos por una fábrica serían intercambiables e interoperables con componentes similares y complementarios producidos por otra.Bienes Fabricados . los fabricantes de bicicletas pueden crear productos más sofisticados y de mayor calidad. Para lograr esto. La competencia entre fabricantes de componentes conlleva eficiencias y mejoras en la calidad. Al establecer controles severos sobre la especificación y producción de las partes componentes. Si una llave no encajaba en la cerradura. necesitan especificaciones detalladas de las partes componentes. Cada aplicación modela la información a su propia manera y dependemos de operadores humanos para 'ajustar' las aplicaciones y así lograr integrarlas. Volver al texto. De la misma forma como el mercado demandó que se pudieran intercambiar artículos a finales de los '80. Es necesario agregar semántica para hacer que las aplicaciones se entiendan. Los ensamblados se creaban "haciendo ajustes". Las organizaciones que no se percaten de las eficiencias de la integración-por-diseño perderán a la larga frente a los que persigan estas eficiencias. Figura 8: Datos estructurados. así como deben también considerar el contexto en el que cada parte será usada.

Se pueden incluso crear proveedores especializados que ofrezcan servicios de marketing. de bajo costo y centralizada en un solo punto (Ver Figura 11): .están 'creando ensamblados' de su funcionalidad de negocios (Ver Figura 9). Wal-Mart logró nuevas eficiencias al hacer primar el poder del comercio sobre los fabricantes. muy pronto la estandarización de los tamaños redujo significativamente el costo de muchos bienes permitiendo la producción masiva y la habilidad de transportar bienes a ubicaciones centrales para la venta y dieron origen a los centros comerciales y el supermercado. ventas. En lugar de fabricar el producto. Los bienes se habían vuelto más sofisticados y las opciones del consumidor habían aumentado. Las comunicaciones de alta velocidad e información estructurada ofrecen beneficios similares. Sin embargo. En lugar de crear un departamento de distribución y entrega. Un día de compras podía implicar el tomar el tren hacia la ciudad. se puede lograr la composición de cualquier cosa.Procesos de Negocio A finales del siglo XIX los centros de comercio urbanos se habían desarrollado. etc. con estándares. Wal-Mart logró proveer de una experiencia de compras placentera. luego ir donde el carnicero y luego donde el panadero. Volver Figura 10: Empresas virtuales. recursos humanos. Para lograr esto. se delega la construcción del mismo a una compañía que se especialice en producción de bajo costo y alta calidad. Comercialización y Distribución . La definición de 'compañía' evoluciona (Ver Figura 10): Figura 9: Ensamblados fabricados. el ir de compras era algo tedioso. Así. producción. pasar comprando las verduras y por último una vuelta por la farmacia. Se puede crear un modelo de componentes de negocio definiendo claramente la semántica y requerimientos operacionales de nuestras capacidades de negocios. se necesitan especificaciones detalladas de las capacidades de los componentes. produciendo la virtualización de las organizaciones. Volver al al texto. porque los proveedores de componentes pueden manejar el costo de optimización a través de mercados amplios y la competencia conlleva cada vez mayores eficiencias. se puede encapsular los detalles de cómo estas capacidades son implementadas y cada componente puede ser orquestado como miembro de cualquier número de procesos. el trabajo se entrega como outsourcing. Al definir interfaces claras. texto. Así por ejemplo. Sin embargo.

los procesos de negocios crecerán para ser la fuerza que le dé la forma y defina los estándares para las nuevas aplicaciones.net representa una nueva etapa en la evolución de COM.net. Industrialización del Software a través de la Plataforma . Figura 12: Procesos de negocios. han logrado producir partes intercambiables básicas. a través de la cual un compilador automáticamente crea un 'plano' de la interacción de componentes en 'assemblies'. nos recuerda las líneas de ensamblaje recientes. de la misma forma como Wal-Mart impone los estándares para cientos y miles de artículos (Ver Figura 12). Con ella. podemos observar dos tipos de integración. Una de ellas se basa simplemente en enviar un fax y esperar que el mismo haya sido recibido y que tal vez nos respondan. En lo futuro. El mayor avance de la Plataforma . Examinando la situación actual de los procesos de negocios.net es la implementación de la parte intercambiable de software en la herramienta de desarrollo misma. la plataforma de componentes de Microsoft.net La Plataforma . equivalentes a la era industrial temprana. Clemens Szyperski (6) . arquitecto experimentado de Microsoft. Volver al texto. la cual permite el uso del porta papeles para copiar datos entre aplicaciones. Microsoft impulsa la idea de 'industrializar' el software utilizando tecnologías de componentes (5) . donde la unidad que está siendo ensamblada lleva consigo las instrucciones para su creación. la cual entrega a los vendedores de software ambientes especializados de desarrollo. Otra técnica que reduce errores es la conocida integración ALT-TAB. Los procesos de negocios aún son hechos a mano y los estándares son muy pobres. Principio de la página 4. Volver al texto. conocidos también como 'fábricas' para el ensamblaje eficiente de 'máquinas de software' basadas en servicios Web. Pero si se quiere hacer algo realmente mejor. Las tecnologías COM y CORBA.Figura 11: Comercialización y distribución. de manera que cada 'parte' de software creada es un componente intercambiable. La plataforma en sí es análoga a una industria de creación de herramientas. se necesita lograr el intercambio y estandarización de datos y operaciones. La tecnología de metadatos del Lenguaje Intermedio (IL) de . confirma esta analogía: . Este es un avance equivalente a la etapa de 'línea de ensamblaje' de la industrialización.

Las Fábricas de Software no son más que el siguiente paso lógico en la evolución continua de los métodos y prácticas de desarrollo de software. En sí. es claro que deberíamos empezar a construir software basado en componentes. Yo iría más allá y aseguraría que no se puede hablar de ingeniería antes de haber dominado este paso . Los editores WYSIWYG por ejemplo. Principio de la página 5. depuración.El construir software ensamblando componentes conlleva grandes promesas para la ingeniería de software de la nueva generación. ¿Es posible automatizar el desarrollo del software? En realidad. La especialización de recursos. Actualmente usamos UML para la documentación. sin embargo. La Revolución Industrial del software está finalmente ante nosotros. A pesar de su ubicuidad.. la aplicación de estos conceptos a la industria moderna del software solamente ha empezando. Los lenguajes de definición de contratos están en el límite de la ciencia de las computadoras. más que solamente en objetos (9) . la experiencia muestra que se necesitan características más precisas del lenguaje para soportar compilación.net se convierte en una implementación ejemplar que ya es parte de la Revolución Industrial del Software que nos mencionaba Bill Gates (7) hace varios años ya: .. estándares para partes intercambiables. algo similar a la manufactura temprana previa a la Revolución Industrial. prometen cambiar el carácter de la industria de software introduciendo patrones de industrialización (8) .. proveyendo beneficios como independencia de dispositivos y el ensamblaje visual. se está hablando de hacer las cosas a mano. Mientras los estereotipos y los tags pueden ser usados para decorar modelos UML. . El diseño de base de datos ofrece formas similares de automatización. la clave para el intercambio e interoperabilidad. en términos de un 'contrato' que la interfaz hace con su infraestructura. la plataforma . lo que buscamos hoy en día es la productividad. Estos 'planos' conocidos como metadatos representan la interfaz del componente. Así. El tema recurrente que podemos observar en la creación de este tipo de herramientas es el hecho de pensar en modelos. una Fábrica de Software es un ambiente de desarrollo configurado para soportar el desarrollo acelerado de un tipo específico de aplicación. Uno de los elementos clave de este patrón es el elevar el nivel de abstracción de los desarrolladores. Así que. Si no. ya lo hemos hecho. pruebas y otros tipos de tareas de desarrollo. Fábricas de Software: el Nuevo Paradigma Las Fábricas de Software son una iniciativa propuesta por Microsoft que plasma la necesidad y provee de los medios para hacer la transición desde el 'hacer a mano' hacia la fabricación o manufactura. y herramientas de ensamblaje de última generación han sido usadas en otras industrias por cientos de años para acelerar el desarrollo de productos altamente complejos.. Sin embargo. hacen mucho más fácil el construir y mantener interfaces gráficas de usuario.

será necesaria la creación de patrones con dominio específico. Cuando se configura con una plantilla de fábrica de software. Una especificación de producto es como una orden de comida específica. Un ambiente de desarrollo extensible. Una fábrica de software es una línea de producto que configura herramientas de desarrollo extensibles como Microsoft Visual Studio Team System con contenido empaquetado y guías. herramientas personalizadas como herramientas para edición visual de DSLs. Especifica qué Lenguajes de Dominio Específico (DSL) pueden ser usados y describe cómo los modelos basados en estos DSLs pueden transformarse en código y otros artefactos. debemos considerar los procesos que usamos para analizar requerimientos. los productos son como comidas servidas en un restaurante. Necesitamos disponer de las mejores prácticas. La analogía de esto es una receta. Un ejemplo más concreto del uso de una fábrica de software sería el diseño de un esquema para la construcción de aplicaciones de clientes livianos para comercio electrónico usando el Microsoft . desarrollar software y ponerlo en producción. Para ello. autodescriptivos e independientes de ubicación. Microsoft Biztalk Server y el Microsoft Host Integration Server . XSDs. Provee los patrones. no lo son todo. Microsoft SQL Server. y otros ingredientes para construir el producto. código fuente. o preparar comidas fuera del menú. los cuales podrían modificar las definiciones de las comidas. Una fábrica de software contiene tres ideas básicas: y y y Un esquema de fabricación. procesos. frameworks.net Framework. y qué ingredientes. Una plantilla de fábrica de software. hojas de estilos. y explica cómo deberían ser combinados para crear el producto. Los desarrolladores del producto son como cocineros que preparan las comidas descritas en las órdenes. y las relaciones clave entre componentes y frameworks que la componen. scripts. Si llevamos más allá la analogía. contenido reutilizable y distintos tipos de patrones. como proyectos. Más aún. C#. para producir así familias de sistemas similares. archivos SQL y archivos de configuración. adaptar y ensamblar rápidamente componentes desarrollados independientemente. el Microsoft Business Framework.Pero aún cuando los modelos juegan un rol importante. plantillas. Un ambiente como Visual Studio Team System es la cocina en la cual la comida es cocinada. ejemplos. Podríamos usar este esquema de . cuidadosamente diseñadas para construir tipos específicos de aplicaciones. En ella se listan ingredientes. Los desarrolladores de la línea de producto son como chefs que deciden qué aparecerá en el menú. y equipo de cocina se usará para prepararlos. Los clientes de la fábrica de software son como los clientes que ordenan comidas de un menú. directorios.una familia amplia pero muy útil de aplicaciones. Para llegar a niveles más altos de productividad necesitamos la habilidad de configurar. Visual Studio Team System se convierte en una fábrica de software para la familia de productos. o en otros modelos. La aplicación de todo esto en conjunto se conoce como Fábrica de Software. frameworks y herramientas que se alineen tanto con la arquitectura del producto como con el ciclo de vida del producto. Esta es una gran bolsa de supermercado que contiene los ingredientes listados en la receta. guías. pero diferentes. Describe la arquitectura de la línea de producto.

Empresas como Microsoft entendieron el potencial de esta metodología hace años y hoy nos ofrecen nuevas iniciativas y herramientas que buscan llevar al proceso de construcción de software hacia el sitial privilegiado en el que debió colocarse desde un principio. . un DSL para describir procesos de negocios. que traerá beneficios inmensos para todos. Para este ejemplo. Volver al texto. políticas de check-in de Team Foundation Server. y aplican patrones específicos de automatización a tareas de desarrollo manual existentes. En esa plantilla incluiríamos algunos bloques de aplicación liberados por el grupo de Microsoft Patterns and Practices. y un DSL para describir entidades de negocio.com/Services/WhatAreComponents.com/componentization.fábrica de software para configurar Visual Studio Team System para convertirse en una fábrica de software que construya miembros de esta familia.asp?bhcp=1. un DSL para describir la navegación Web. Con esta fábrica de software. Las fábricas de software son posibles hoy en día y representan el intento de aprender de otras industrias que encaran problemas similares. cada una conteniendo características únicas basadas en requerimientos únicos de clientes específicos.shtml. What are components?.componentsource. Las fábricas de software vuelven más rápida. Podríamos usar las características de extensibilidad de Visual Studio Team System para hostear una plantilla de fábrica de software basada en este esquema. barata y fácil la construcción de aplicaciones. 6. el equipo de desarrollo podría rápidamente lanzar una variedad de aplicaciones de comercio electrónico. http://www. (2) ComponentSource. la guía de proceso de Microsoft Solution Framework (MSF). y nos asombramos cada vez más al darnos cuenta de que este solo es el inicio. concretando así la visión de la industrialización del software moderno. Conclusión Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software. Al mirar hacia atrás. el esquema de software podría contener un DSL que represente requerimientos configurables. Volver al texto. (1) WebCab Components. un DSL para describir modelos lógicos y físicos. http://webcabcomponents. El desarrollo de software basado en componentes desde siempre fue la idea revolucionaria que nos llevó a pensar que sí era posible el construir software de calidad en corto tiempo y con la misma calidad que la mayoría de las industrias de nuestro tiempo. estructuras de proyecto. entre otros. vemos los increíbles avances que hemos logrado en la comprensión de la forma correcta de reutilizar el software y el conocimiento existente. El desarrollo de software basado de componentes se convirtió en el pilar de la Revolución Industrial del Software y se proyecta hoy en día en diversas nuevas formas de hacer software de calidad con los costos más bajos del mercado y en tiempos que antes eran impensables. About Component Based Development.

Principio de la página El desarrollo de aplicaciones por componentes se basa en la reutilización de código elaborado con anterioridad. Volver al texto.asp. El extracto presentado fue sacado de una publicación hecha en el año de 1997. . http://msdn.com/architecture/journ/default. (9) Jack Greenfield. Dueño de uno de los imperios de software más grandes que jamás haya existido y probablemente una de las personas más influyentes del mundo moderno. Volver al texto.NET Platform as Component Infrastructure.com/architecture/journ/default.asp. ESEC/FSE.htm.com/NETPlatform/default.aspx?pull=/library/enus/dnmaj/html/aj3softfac.microsoft. (5) Components Online. este código en su momento fue probado.aspx?pull=/library/enus/dnmaj/html/aj2metrop. Metrópolis. Volver al texto. (7) Bill Gates. procesamiento de transacciones y sistemas distribuidos. http://blogs. ya que no todos los proyectos van a tener la misma oportunidad de reutilización. Julio Casal Terreros es Ingeniero de Sistemas Computacionales de la Universidad Católica de Santiago de Guayaquil.aspx. y su funcionalidad fue comprobada. Su galardonado libro "Component Software: Beyond ObjectOriented Programming" fue revisado y extendido hacia una segunda edición en el 2002. Volver al texto. incluyendo ECOOP. (4) Microsoft Architects Journal 2. Fue uno de los fundadores del equipo que implementó y llevó al mercado el Microsoft Transaction Server (MTS).com/askburton/archive/2004/09/20/232065. Industrializing Software Development. y OOPSLA y ha organizado varios eventos internacionales. http://msdn.net. Su enfoque está en el uso efectivo del softwre de componentes para construir nuevos tipos de software. Volver al texto. (6) Clemens Szyperski se unió a Microsoft Research como Arquitecto de Software en 1999. Ha trabajado por más de 20 años en bases de datos. Volver al texto. Ha servido en numerosos comités de programas. como aquella de 'un computador en cada hogar'. ahora conocido como COM+. de este modo lo que se tiene que hacer es revisar nuestros proyectos anteriores o comprar lo que necesitemos de otras personas.(3) Pat Helland tiene 25 años de experiencia en la industria del software y ha sido arquitecto en Microsoft desde 1994. Volver al texto.components-online. Es Microsoft Certified Application Developer y trabaja como Desarrollador de Soluciones . http://www. The Case for Software Factories.msdn. por sus ideas innovadoras y altamente acertadas. ICSE. Chairman y Chief Software Architect de Microsoft. (8) Microsoft Architects Journal. Mediante el uso de varios componentes simples se pueden construir proyectos bastante complejos los cuales si se realizaran desde el principio tomarían demasiado tiempo. .microsoft. luego de esto podemos pasar a juntar las piezas que se van a reutilizar y las demás piezas que debemos obligatoriamente especificar para cada proyecto.

Es una muy buena opción usar código. tiene la información de que componentes van a usar y las características del modelo y como van a suplir los requerimientos que les hace falta. De este modo se pueden juntar o combinar partes hechas en distintos lugares. Links Este es del Proyecto WEST Tecnología Software Orientada a Ambientes Web.dsic.upv. como la definició . de este modo podemos establecer nuestro estilo en las aplicaciones que realicemos y así podemos hacer conocer nuestros productos y nuestro trabajo a otros desarrolladores que necesiten un componente que hayamos fabricado. básicamente cuando existen diversos grupos de trabajo en distintos lugares.htm Este tiene una información bastante completa del desarrollo de software basado en componentes (DSB) y sus diferencias con otros paradigmas como el orientado a objetos. es mejor que sean pocas partes mas grandes (granularidad). y es mejor que lo que se reutilice sea muy general y bien probado para asegurar los resultados que se vayan a obtener de estos componentes. puede ser una ventaja porque cada grupo piensa únicamente en la finalización de su parte del proyecto y al final hay que juntar las piezas.co/~jcpymes/Docs/DSBC.javeriana. si es proyecto así lo permite.edu. http://www. probadas y que fueron efectivas para la venta de un producto.pdf. pero para poder tener una buena cantidad de componentes reutilizables de nuestra autoría pasara mucho tiempo y varios proyectos.es/~west/westtask4_e. Este es parecido al anterior pero contiene mas detalles del DSBC. Por otro lado también es muy eficiente comprar componentes de otras personas pero no se puede garantizar su correcto funcionamiento por lo que se debe verificar que este trabajando como uno espera. http://pegasus. sin embargo no se pueden pensar en combinar un numero demasiado grande de piezas. Se debe producir software con el propósito de reutilizarlo en el desarrollo de aplicaciones futuras. documentación o interfaz graficas que uno mismo ha hecho y que en proyectos anteriores ya fueron usadas.No podemos tratar de hacer un proyecto totalmente con piezas preelaboradas ya que habrá partes que sean específicas para cada proyecto.

Sign up to vote on this title
UsefulNot useful