Programación orientada a componentes - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-07-06T21:19:21Z

Texto reemplazado: «<div align="justify">» por «»

Juana pedagogico.ltu: La programación orientada a componentes trasladada a Programación orientada a componentes

2011-11-06T00:50:31Z

La programación orientada a componentes trasladada a Programación orientada a componentes

Juana pedagogico.ltu en 00:40 6 nov 2011

2011-11-06T00:40:16Z

Leydis jc.manzanillo4: /* Fuente */

2011-11-04T14:30:30Z

‎Fuente

Yaneisi jc.manzanillo4: /* Problemas típicos de la POC */

2011-11-03T21:20:25Z

‎Problemas típicos de la POC

Yaneisi jc.manzanillo4: /* Conceptos básicos de la POC */

2011-11-03T21:14:20Z

‎Conceptos básicos de la POC

Yaneisi jc.manzanillo4 en 21:12 3 nov 2011

2011-11-03T21:12:54Z

Yaneisi jc.manzanillo4: /* Conceptos básicos de la POC */

2011-11-03T21:09:51Z

‎Conceptos básicos de la POC

Yaneisi jc.manzanillo4 en 21:06 3 nov 2011

2011-11-03T21:06:56Z

Yaneisi jc.manzanillo4: /* Objetivo de la POC */

2011-11-03T20:58:16Z

‎Objetivo de la POC

@@ Línea 2: / Línea 2: @@
 |nombre= Programación orientada a componentes
 |imagen= Diagrama.gif
-}}<div align="justify">'''Programación orientada a componentes'''. Extensión natural de la [[programación]] orientada a objetos (POO) en los sistemas de aplicación abiertos, que tiene como propósito contrarrestar  las limitaciones de esta,  como la falta de una unidad concreta de composición independiente en las aplicaciones, y la definición de interfaces a  bajo [[nivel]], que dificultan la reutilización comercial de objetos.
+}}'''Programación orientada a componentes'''. Extensión natural de la [[programación]] orientada a objetos (POO) en los sistemas de aplicación abiertos, que tiene como propósito contrarrestar  las limitaciones de esta,  como la falta de una unidad concreta de composición independiente en las aplicaciones, y la definición de interfaces a  bajo [[nivel]], que dificultan la reutilización comercial de objetos.
 ==Objetivo==
 El objetivo de la programación orientada a componentes (POC) es construir un [[mercado]] global de componentes [[software]], en donde los [[usuarios]] son los desarrolladores de las aplicaciones que necesitan reutilizar componentes ya hechos y testeados para construir sus aplicaciones de forma más rápida y robusta.

@@ Línea 1: / Línea 1: @@
-{{Definición|nombre= Programación Orientada a Componentes|imagen= Diagrama.gif}}<div  align="justify">
+{{Definición
-'''La programación orientada a componentes''' (POC) surge como una variante natural ante las limitaciones de la [[programación]] orientada a objetos (POO) en los sistemas de aplicación abiertos, por problemas como la falta de una unidad concreta de composición independiente en las aplicaciones, y la definición de interfaces a demasiado bajo [[nivel]], dificultando la reutilización comercial de objetos.
+|nombre= Programación orientada a componentes
-==Objetivo de la POC==
+|imagen= Diagrama.gif
-El objetivo de la POC es  construir un [[mercado]] global de componentes [[software]], en donde los [[usuarios]] son los desarrolladores de las aplicaciones que necesitan reutilizar componentes ya hechos y testeados para construir sus aplicaciones de forma más rápida y robusta.
+}}<div align="justify">'''Programación orientada a componentes'''. Extensión natural de la [[programación]] orientada a objetos (POO) en los sistemas de aplicación abiertos, que tiene como propósito contrarrestar  las limitaciones de esta,  como la falta de una unidad concreta de composición independiente en las aplicaciones, y la definición de interfaces a  bajo [[nivel]], que dificultan la reutilización comercial de objetos.
 En general, puede verse como una extensión natural de la programación orienta a objetos dentro del ámbito de los sistemas de aplicación abiertos y distribuidos.
-Las entidades básicas de la POC son los componentes, estos pueden interpretarse como cajas negras que encapsulan cierta funcionalidad y que son diseñadas sin saber quien los utilizará, ni como, ni cuando. Los servicios de los componentes son conocidos mediante sus interfaces y requisitos.
 La POC es un paradigma de programación que se centra en el diseño e implementación de componentes, y en particular en los conceptos de encapsulación, polimorfismo, composición tardía y seguridad.
 == Conceptos básicos de la POC ==
-== Conceptos básicos de la  POC ==
+Existe un conjunto de conceptos básicos que intervienen en la POC y que permiten diferenciarla del resto de los [[paradigmas de programación]]. Entre ellos se encuentran:
-Existe un  conjunto de conceptos básicos que intervienen en la POC, y que permiten diferenciarla del resto de los [[paradigmas de programación]]. Entre ellos se encuentran los siguientes:
+*Composición tardía: composición que se realiza en un [[tiempo]] posterior al de la compilación del componente, puede ser durante su enlazado, carga o ejecución, y por alguien ajeno a su [[desarrollo]], es decir, que sólo conoce al componente por su interfaz o contrato, sin necesidad de conocer detalles de implementación, ni la forma en que fue creado.
-*Composición tardía: Composición que se realiza en un [[tiempo]] posterior al de la compilación del componente, como puede ser durante su enlazado, carga o ejecución, y por alguien ajeno a su [[desarrollo]], es decir, que sólo conoce al componente por su interfaz o contrato, sin necesidad de conocer detalles de implementación, ni la forma en que fue creado.
+*[[Eventos]]: mecanismo de comunicación por el que se pueden propagar las situaciones que ocurren en un sistema de forma asíncrona. Emitidos para avisar a los componentes de su entorno de cambios en su estado.
-*[[Eventos]]: Mecanismo de comunicación por el que se pueden propagar las situaciones que ocurren en un sistema de forma asíncrona. Emitidos para avisar a los componentes de su entorno de cambios en su estado.
+*Reutilización: posibilidad de utilizar un componente [[software]] en contextos distintos a aquellos para los que fue diseñado (reutilizar no significa usar más de una vez).
 *Contratos: especificación que se añade a la interfaz de un componente y que establece las condiciones de uso e implementación que ligan a los clientes y proveedores del componente. Los contratos cubren aspectos tanto funcionales (semántica de las operaciones de la interfaz) como no funcionales (calidad de servicio, prestaciones, fiabilidad o seguridad).
-*Polimorfismo: habilidad de un mismo componente de mostrarse de diferentes formas, dependiendo del contexto; o bien la capacidad de distintos componentes de mostrar un mismo comportamiento en un contexto dado. En POC muestra tres nuevas posibilidades:
+*Polimorfismo: posibilidad de que un mismo componente se muestre de diferentes formas, dependiendo del contexto; o bien la capacidad de distintos componentes de mostrar un mismo comportamiento en un contexto dado. En POC muestra tres nuevas posibilidades:
-. La reemplazabilidad (Inclusión), o capacidad de un componente de reemplazar a otro en una aplicación, sin romper los contratos con sus clientes.
+. La reemplazabilidad (inclusión), o capacidad de un componente de reemplazar a otro en una aplicación, sin romper los contratos con sus clientes.<br />
+. El polimorfismo paramétrico, o implementación genérica de un componente. Este no se resuelve en [[tiempo]] de compilación (generando la típica explosión de código), sino en [[tiempo]] de ejecución. <br />
-. El polimorfismo paramétrico, o implementación genérica de un componente. Este no se resuelve en [[tiempo]] de compilación (generando la típica explosión de código) sino en [[tiempo]] de ejecución.
+. El polimorfismo acotado, para indicar restricciones sobre los tipos sobre los que se puede parametrizar un componente.
+*Seguridad: garantía que debe ofrecer un componente de respetar sus interfaces y contratos:
-.Por último, el polimorfismo acotado, para indicar restricciones sobre los tipos sobre los que se puede parametrizar un componente.
+. Seguridad a nivel de tipos: asegura que las invocaciones usen los parámetros adecuados (o supertipos) y que los valores que devuelven son del tipo adecuado (o subtipos).<br />
+. Seguridad a nivel de módulo: asegura que solo se utilizan los servicios ajenos al componente que se han declarado.
-*Seguridad: Garantía que debe ofrecer un componente de respetar sus interfaces y contratos.
+*Reflexión: habilidad para conocer y modificar el estado de un componente.
+== Problemas típicos de la POC ==
-. Seguridad a nivel de tipos: Asegura que las invocaciones usen los parámetros adecuados (o supertipos) y que los valores que devuelven son del tipo adecuado (o subtipos).
+La POC es una disciplina muy joven y por tanto en la que los resultados obtenidos se centran más en la identificación de los problemas que en la resolución de los mismos. Algunos de los retos y problemas con los que se enfrenta son:
 ==Fuente==
-*Vallecillo, Troya, & Fuentes, [[2001]]. Desarrollo de [[Software]] Basado en Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, [[2001]], Universidad de Málaga.
+*Fuentes, L., Troya, José M. & Vallecillo, A. [[2001]].  Desarrollo de [[software]] basado en componentes. Universidad de Málaga.
-*Metodología de Desarrollo de [[Software]] Basada en Componentes, trabajo de cátedra.
+*Metodología de desarrollo de [[software]] basada en componentes, trabajo de cátedra.
- [[Category:Programación]][[Category:Informática]]
+[[Category:Programación]][[Category:Informática]]

@@ Línea 1: / Línea 1: @@
-{{Desarrollo}}{{Definición|nombre= Programación Orientada a Componentes|imagen= Diagrama.gif}}<div  align="justify">
+{{Definición|nombre= Programación Orientada a Componentes|imagen= Diagrama.gif}}<div  align="justify">
 '''La programación orientada a componentes''' (POC) surge como una variante natural ante las limitaciones de la [[programación]] orientada a objetos (POO) en los sistemas de aplicación abiertos, por problemas como la falta de una unidad concreta de composición independiente en las aplicaciones, y la definición de interfaces a demasiado bajo [[nivel]], dificultando la reutilización comercial de objetos.
 ==Objetivo de la POC==
@@ Línea 40: / Línea 40: @@
 ==Fuente==
-*Vallecillo, Troya, & Fuentes, 2001. Desarrollo de Software Basado en Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, 2001, Universidad de Málaga.
+*Vallecillo, Troya, & Fuentes, [[2001]]. Desarrollo de [[Software]] Basado en Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, [[2001]], Universidad de Málaga.
-*Metodología de Desarrollo de Software Basada en Componentes, trabajo de cátedra.
+*Metodología de Desarrollo de [[Software]] Basada en Componentes, trabajo de cátedra.
   [[Category:Programación]][[Category:Informática]]

@@ Línea 34: / Línea 34: @@
 *Percepción del entorno. Habilidad de un componente de descubrir tanto el tipo de entorno en donde se está ejecutando (de [[diseño]] o de ejecución), como los servicios y recursos disponibles en él.
 *Particularización. Cómo particularizar los servicios que ofrece un componente para adaptarlo a las necesidades y requisitos concretos de nuestra aplicación, sin poder manipular su implementación.
-*Falta de soporte formal. La POC también se encuentra con otro reto añadido, como es la dificultad que encuentran los métodos formales para trabajar con sus peculiaridades, como puede ser la composición tardía, el [[polimorfismo]] o la evolución de los componentes.
+*Falta de soporte formal. La POC también se encuentra con otro reto añadido, como es la dificultad que encuentran los métodos formales para trabajar con sus peculiaridades, como puede ser la composición tardía, el polimorfismo o la evolución de los componentes.
 *El problema de la clase base frágil (FBCP). Este problema ocurre cuando la superclase de una clase sufre modificaciones. El FBCP existe a dos niveles, sintáctico y semántico. A nivel sintáctico ocurre cuando las modificaciones de la superclase son puramente a este nivel. A nivel semántico ocurre cuando lo que se altera es la implementación de los métodos de la superclase.
 *Asincronía y carreras de eventos. Problema que se presenta por los tiempos de comunicación en los sistemas abiertos (no se pueden despreciar retrasos). Es muy difícil garantizar el orden relativo en el que se distribuyen los [[eventos]]. El proceso de difusión de eventos es complicado cuando los emisores y receptores pueden cambiar con el tiempo.
 *Interoperabilidad. Actualmente, los contratos de los componentes se reducen a la definición de sus interfaces a nivel sintáctico, y la interoperabilidad se reduce a la comprobación de los nombres y perfiles de los métodos. Sin embargo, es necesario ser capaces de referirnos y buscar los servicios que necesitamos por algo más que sus nombres, y poder utilizar los métodos ofrecidos en una interfaz en el orden adecuado.
 ==Fuente==
 *Vallecillo, Troya, & Fuentes, 2001. Desarrollo de Software Basado en Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, 2001, Universidad de Málaga.
 *Metodología de Desarrollo de Software Basada en Componentes, trabajo de cátedra.
   [[Category:Programación]][[Category:Informática]]

@@ Línea 1: / Línea 1: @@
-{{Definición|nombre= Programación Orientada a Componentes|imagen= Diagrama.gif}}<div  align="justify">
+{{Desarrollo}}{{Definición|nombre= Programación Orientada a Componentes|imagen= Diagrama.gif}}<div  align="justify">
 '''La programación orientada a componentes''' (POC) surge como una variante natural ante las limitaciones de la [[programación]] orientada a objetos (POO) en los sistemas de aplicación abiertos, por problemas como la falta de una unidad concreta de composición independiente en las aplicaciones, y la definición de interfaces a demasiado bajo [[nivel]], dificultando la reutilización comercial de objetos.
 ==Objetivo de la POC==
@@ Línea 34: / Línea 34: @@
 *Percepción del entorno. Habilidad de un componente de descubrir tanto el tipo de entorno en donde se está ejecutando (de [[diseño]] o de ejecución), como los servicios y recursos disponibles en él.
 *Particularización. Cómo particularizar los servicios que ofrece un componente para adaptarlo a las necesidades y requisitos concretos de nuestra aplicación, sin poder manipular su implementación.
-*Falta de soporte formal. La POC también se encuentra con otro reto añadido, como es la dificultad que encuentran los métodos formales para trabajar con sus peculiaridades, como puede ser la composición tardía, el polimorfismo o la evolución de los componentes.
+*Falta de soporte formal. La POC también se encuentra con otro reto añadido, como es la dificultad que encuentran los métodos formales para trabajar con sus peculiaridades, como puede ser la composición tardía, el [[polimorfismo]] o la evolución de los componentes.
 *El problema de la clase base frágil (FBCP). Este problema ocurre cuando la superclase de una clase sufre modificaciones. El FBCP existe a dos niveles, sintáctico y semántico. A nivel sintáctico ocurre cuando las modificaciones de la superclase son puramente a este nivel. A nivel semántico ocurre cuando lo que se altera es la implementación de los métodos de la superclase.
 *Asincronía y carreras de eventos. Problema que se presenta por los tiempos de comunicación en los sistemas abiertos (no se pueden despreciar retrasos). Es muy difícil garantizar el orden relativo en el que se distribuyen los [[eventos]]. El proceso de difusión de eventos es complicado cuando los emisores y receptores pueden cambiar con el tiempo.
 *Interoperabilidad. Actualmente, los contratos de los componentes se reducen a la definición de sus interfaces a nivel sintáctico, y la interoperabilidad se reduce a la comprobación de los nombres y perfiles de los métodos. Sin embargo, es necesario ser capaces de referirnos y buscar los servicios que necesitamos por algo más que sus nombres, y poder utilizar los métodos ofrecidos en una interfaz en el orden adecuado.
 ==Fuente==
 *Vallecillo, Troya, & Fuentes, 2001. Desarrollo de Software Basado en Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, 2001, Universidad de Málaga.
 *Metodología de Desarrollo de Software Basada en Componentes, trabajo de cátedra.
   [[Category:Programación]][[Category:Informática]]

← Revisión anterior	Revisión del 00:50 6 nov 2011
(Sin diferencias)

Programación orientada a componentes - Historial de revisiones

Javiermartin jc: Texto reemplazado: «» por «»

Juana pedagogico.ltu: La programación orientada a componentes trasladada a Programación orientada a componentes

Juana pedagogico.ltu en 00:40 6 nov 2011

Leydis jc.manzanillo4: /* Fuente */

Yaneisi jc.manzanillo4: /* Problemas típicos de la POC */

Yaneisi jc.manzanillo4: /* Conceptos básicos de la POC */

Yaneisi jc.manzanillo4 en 21:12 3 nov 2011

Yaneisi jc.manzanillo4: /* Conceptos básicos de la POC */

Yaneisi jc.manzanillo4 en 21:06 3 nov 2011

Yaneisi jc.manzanillo4: /* Objetivo de la POC */

Javiermartin jc: Texto reemplazado: «
» por «»