MXPA04009835A - Diseno de interfases de programacion de aplicacion (apis). - Google Patents

Abstract

La primera implementacion del metodo de ejemplo para disenar una interfase de programacion de aplicacion (API) incluye: preparar muestras de codigo multiples para un escenario de nucleo, correspondiendo cada una de las muestras de codigo de las muestras de codigo multiples a un lenguaje de programacion respetivo de lenguajes multiples de programacion; y derivar la API del escenario de nucleo en respuesta a las muestras de codigo multiples. Un segundo metodo de ejemplo para el diseno de una API incluye: seleccionar un escenario de nucleo para un area de caracteristicas; escribir al menos una muestra de codigo para el escenario de nucleo; y derivar una API para el escenario de nucleo en respuesta a dicha al menos una muestra de codigo. Un tercer metodo de ejemplo para disenar las API incluye: derivar una API para un escenario en respuesta a por lo menos una muestra de codigo escrita con respecto al escenario; realizar uno o mas estudios de posibilidad de uso en la API que utilizan desarrolladores multiples; y revisar la API basada en dichos uno o mas estudios de posibilidad de uso.

Description

DISEÑO DE INTERFASES DE PROGRAMACIÓN DE APLICACIÓN (APIs) Campo de la Invención La presente invención se refiere en general a interfases de programación de aplicación (APIs) y en particular, a modo de ejemplo pero sin limitación, al diseño de APIs que son fáciles de utilizar mientras que proporcionan simultáneamente control y flexibilidad. Antecedentes de la Invención Las interfases de programación de aplicación (APIs) son utilizadas por los desabolladores para crear una amplia variedad de aplicaciones y programas. Los desabolladores se encuentran en un rango desde trabajadores de oficina que registran macros hasta autores de unidades de aparatos de bajo nivel. Estos desabolladores dependen de diferentes lenguajes y/o diferentes sistemas con complejidades diferentes, mientras efectúan las programaciones con conjuntos de habilidades diferentes y/o para propósitos diferentes. Tradicionalmente, han sido diseñadas APIs diferentes para tener como objetivos niveles diferentes de habilidad individual y demandas diferentes para el control (por ejemplo, basados en los diferentes escenarios relevantes). Aunque este método puede ser exitoso para producir APIs que son optimizadas para un desarrollador específico, tienen desventajas importantes. Por ejemplo, ios métodos de sistemas múltiples crean situaciones en donde los desarrolladores tienen dificultad para transferir el conocimiento de un nivel de habilidad de un tipo de escenario al otro. Cuando existe una necesidad de que ellos implementen un escenario utilizando un sistema diferente, los desarrolladores se enfrentan a una curva de aprendizaje muy abrupta. Y la curva de aprendizaje no es solamente es muy abrupta, sino que generalmente requiere que el código escrito a un primer sistema de nivel de habilidad inferior, se vuelva a escribir desde el trazado a un segundo sistema de nivel de habilidad más alta. Además, la creación de sistemas separados para niveles diferentes de habilidad de los desarrolladores, generalmente da como resultado situaciones en las cuales las APIs que tienen como objetivo o que son implementadas por un nivel de desarrollador, no se pueden utilizar por otro nivel de desarrollador. La figura 1 ilustra una gráfica 101 de una curva de aprendizaje de una API tradicional con respecto a dos ! sistemas diferentes. El primer sistema corresponde a un sistema que tienen un nivel relativamente más bajo de habilidades requeridas y/o dificultad y concomitantemente una capacidad relativa inferior para ser controladas por medio de un desarrollador. Por otra parte, el segundo sistema corresponde a un sistema que tiene un nivel relativamente más alto de habilidades requeridas y/o dificultad y una capacidad concomitantemente relativamente más alta para el control por parte del desarrollador. Dicho primer sistema podría ser utilizado por un desarrollador novato o infrecuente y dicho segundo sistema podría ser utilizado por un desarrollador experimentado profesional. Por ejemplo, el primer sistema puede corresponder a un sistema diseñado para el Visual Basic, y el segundo sistema podría corresponder a uno diseñado para C + + . En este método tradicional, son diseñadas o empleadas como parte de cada sistema APIs relativamente separadas y dispares. Una curva de aprendizaje escalonada pero relativamente corta es atravesada para habilitar el uso de la API para el primer sistema en un nivel de habilidad y capacidades de control relativamente inferiores. Debido a la naturaleza separada y dispar de los dos sistemas API, la experiencia con el primer sistema contribuye poco, si se adquiere algún aprendizaje de conocimientos hacia la segunda API del segundo sistema. Por consiguiente, se atraviesa una curva de aprendizaje igualmente abrupta, pero más alta para hacer posible el uso de la API para el segundo sistema. En otras palabras, el aprendizaje de una API del primer sistema no proporciona una base para el aprendizaje de una API del segundo sistema. La naturaleza regresiva de este conjunto de sistemas API es indicada por una brecha de continuidad. Un desarrollador el cual ha aprendido la API del primer sistema, no está más cerca de aprender la API del segundo sistema y por lo tanto, debe comenzar con los conocimientos básicos del segundo sistema. Otro problema con los sistemas tradicionales es que tienden a tener una posibilidad de uso general pobre en cualquier caso. En general, las metodologías de diseño/desarrollo orientadas al objeto (OOD) (por ejemplo, lenguajes de modelado unificados (UML)) son "optimizados" para la capacidad de mantenimiento del diseño resultante, y no para la posibilidad de uso de los sistemas resultantes. Las metodologías OOD son más convenientes para los diseños internos de arquitectura, y menos adecuadas para diseños de una capa de API de una biblioteca grande que se vuelve a utilizar. Por ejemplo, la capacidad de utilización deficiente puede ser el resultado de las metodologías OOD que se enfocan solamente en la destilación hacia un bloque fundamental más bajo y/o que tienen una lealtad constante a una jerarquía estricta de herencia a través del diseño de la API. Por consiguiente, existe una necesidad de esquemas y/o técnicas que puedan aminorar por lo menos la brecha de continuidad regresiva de una curva de aprendizaje de API tradicional y/o que puedan presentar una mejor posibilidad de uso general de la API. Sumario de la Invención En un primer método de impiementación de ejemplo, un método para el diseño de una interfase de programación de aplicación (API) incluye: la preparación de muestras de códigos múltiples para un escenario central, respondiendo cada muestra de código respectiva de las muestras de código múltiples a un lenguaje de programación respectivo de lenguajes de programación múltiples; y derivar la API del escenario de núcleo en respuesta a las muestras del código múltiple. En un segundo método de impiementación de ejemplo, un método para diseñar una API incluye: seleccionar un escenario de núcleo para un área característica; escribir por lo menos una muestra de código para el escenario de núcleo y derivar una API para el escenario de núcleo en respuesta a por lo menos una muestra del código. En un tercer método de impiementación de ejemplo, un método para el diseño de un API incluye: derivar un API para un escenario en respuesta a por lo menos una muestra de código descrita con respecto al escenario; realizar uno o más estudios de posibilidad de uso en la API que utiliza desabolladores múltiples y la revisión de la API basada en el uno o más estudios de posibilidad de uso. En la presente descripción se describen otro método, sistema, aparato, dispositivo, medios, APIs, procedimientos, matrices, etc., e ¡mplementaciones. Breve Descripción de los Dibujos Los mismos números son utilizados en todos los dibujos para referirnos a aspectos, características y componentes similares y/o correspondientes. La figura 1 es una gráfica de una curva de aprendizaje tradicional de API con respecto a dos diferentes sistemas. La figura 2 ilustra una gráfica de una curva progresiva de aprendizaje API de ejemplo con respecto a dos niveles de abstracción diferentes. La figura 3 ilustra los principios y prácticas de diseño de ejemplo para las APIs. La figura 4 es un diagrama de flujo que ilustra una técnica de ejemplo para el diseño de APIs por área característica. La figura 5 es un diagrama de bloque que ilustra un esquema de ejemplo para el diseño de APIs por escenario de núcleo. La figura 6 ilustra la disparidad potencial entre los tipos de componentes de ejemplo que son enfocados hacia dos propósitos diferentes. La figura 7 ilustra una relación de ejemplo entre dos tipos de componentes que están diseñados para ser extensibles y/o interoperables como para cubrir dos propósitos diferentes. La figura 8 ilustra un componente agregado de ejemplo (AC) y los tipos factorizados asociados (FTs) para manejar dos propósitos diferentes con una API de dos capas. La figura 9 ilustra un componente agregado de ejemplo y las APIs asociadas que pueden soportar un patrón de uso de creación- ajuste-invocación. La figura 10 ilustra un entorno operativo de cómputo de ejemplo (o aparato general) que tiene la capacidad de implementar (total o parcialmente) por lo menos un aspecto del diseño y/o el uso de las APIs, tal y como aquí se describen. Descripción Detallada e la Invención La figura 2 ilustra una gráfica 200 de una curva de aprendizaje progresiva de API de ejemplo con respecto a dos niveles diferentes de abstracción. Los dos niveles diferentes de abstracción ilustrados son un nivel de abstracción relativamente alto y un nivel de abstracción relativamente bajo. El nivel de abstracción relativamente alto corresponde a un ámbito de desarrollo que comprende un nivel relativamente más bajo de habilidades requeridas y/o dificultad y una capacidad relativamente inferior para el control por medio del desarrollados El nivel de abstracción bajo, por otra parte, corresponde a un entorno de desarrollo que comprende un nivel relativamente más alto de habilidades requeridas y/o dificultad y concomitantemente, una capacidad relativamente más alta para el control por parte de un desarrollados Una curva de aprendizaje progresiva de API se muestra originándose desde el punto de las habilidades más bajas requeridas y las capacidades de control concomitantes de una manera relativamente suave, a través de las áreas para los niveles alto y bajo de abstracción hasta un punto de las habilidades más altas requeridas y la capacidad de control concomitante. La curva de aprendizaje de API progresiva exhibe una zona de continuidad entre las áreas de nivel de abstracción alto y el nivel de abstracción bajo. Un sistema API integrado hace posible una curva de aprendizaje gradual. Debido a la naturaleza integrada del sistema API, la experiencia con el nivel de abstracción del nivel alto contribuye al conocimiento para el aprendizaje del uso de la API para el nivel de abstracción bajo, así como para los escenarios que demandan un control mayor. En otras palabras, el aprendizaje de la API para los niveles de abstracción más altos proporciona un trampolín para el aprendizaje y/o la extensión de la API dentro de niveles de abstracción más bajos. Esto es indicado por la forma del sistema de dos capas (API) que comprende ambas las áreas de nivel de abstracción alta y baja. La naturaleza progresiva de ciertas APIs, tal y como se describirá más adelante, hace posible que los desabolladores utilicen inicialmente las APIs simples y que comiencen a utilizar gradualmente (parcialmente) componentes de las API más complicadas. Por lo tanto, los desabolladores que han aprendido las APIs que se enfocan en los niveles de abstracción más altos, se pueden mover al uso de las APIs que se enfocan en los niveles de abstracción más bajos, ya que su experiencia les garantiza y/o conforme la complejidad de los escenarios que ellos están obligados a enfrentar. Una API progresiva puede ser fácilmente utilizable (especialmente durante las fases tempranas de aprendizaje) y poderosamente altos (especialmente como en las API son exploradas con el paso del tiempo). Una API que se puede utilizar puede incluir uno o más de los siguientes atributos de ejemplo: para iniciar es requerido un número pequeño de conceptos y/o clases, unas cuantas líneas de códigos pueden implementar escenarios simples, clases/métodos que tienen nombres intuitivos, es aparente un punto de inicio natural y/u obvio, y existe una progresión clara (por ejemplo, que se puede descubrir) para los conceptos/clases importantes y/o adicionales requeridos. Una API progresiva también puede hacer posible un avance incremental del desarrollo en un punto de dificultad más baja, y una capacidad de control concomitante a un punto de dificultad más alta y capacidad de control concomitante. Los paradigmas de ejemplo para el diseño de APls progresivas, así como APIs que se pueden utilizar de una manera extensa, se describen a continuación. La figura 3 ilustra principios y prácticas de diseños de ejemplo para las APls en una tabla 300. La tabla 300 incluye los principios y prácticas generales del diseño para cuatro categorías de ejemplos de la 302 a la 308. Específicamente, las siguientes cuatro categorías son dirigidas como: un diseño conducido por el escenario 302, un diseño orientado a los componentes 304, opciones por omisión (defaults) que se pueden personalizar 306 y un modelo de objeto con documentación 308. Cuando se diseña una API determinada, pueden ser empleados los principios y prácticas del diseño para cualquiera o más de las categorías indicadas del 302 al 308. Además, dentro de una categoría determinada del 302 al 308, se pueden implementar uno o más de los principios y prácticas de diseño ilustradas. En otras palabras, ni cada categoría, ni cada principio y práctica de diseño, necesitan ser empleados e implementados para una API de diseño determinado. La categoría del diseño conducida por el escenario 302 ¡lustra cuatro principios y prácticas de diseño de ejemplo. En primer lugar, se definen escenarios de núcleos para características o áreas tecnológicas seleccionadas. En segundo lugar, se escriben primero las muestras de núcleo correspondientes a los escenarios de núcleo, y la API es diseñada en respuesta a la segunda. En tercer lugar, es diseñada una API progresiva como es introducida anteriormente y que se describe más adelante,. En cuarto lugar, la utilización de los escenarios núcleo definidos se hace fácil mientras que se utilizan otros escenarios que se hacen posibles. El diseño conducido por el escenario 302 se describe con mayor detalle más adelante en la sección titulada "Diseño Conducido por el Escenario". La categoría de diseño orientada por el componente 304 ilustra tres prácticas y principios de diseño de ejemplo. En primer lugar, se crean componentes agregados a (ACs). Generalmente, los componentes agregados están dirigidos hacia los escenarios de núcleos, son relativamente simples y fáciles de usar y están construidos en la parte superior de los tipos factorizados (FTs). Los tipos factorizados son más fundamentales y están se descomponen hacia los niveles lógicos inferiores. Esto da como resultado un diseño de una API de dos capas. En segundo lugar, estos componentes agregados son interrelacionados con los picos factorizados. En tercer lugar, es soportado el patrón de uso de creación-ajuste-invocación especialmente para los componentes agregados. El diseño por los componentes 304 se describe con mayor detalle más adelante en la sección titulada "Diseño Orientado del Componente".

La categoría de opciones por omisión (default) que se pueden personalizar 306 ilustra dos principios y prácticas de diseño de ejemplo. En primer lugar, se reducen las inicializaciones requeridas para utilizar por lo menos los componentes agregados. Las opciones por omisión (default) son utilizadas para reducir las inicializaciones requeridas. En segundo lugar, las opciones por omisión (default) son seleccionadas de manera que son apropiadas para los escenarios de núcleo definidos. Las opciones por omisión (default) que se pueden personalizar 306 se describen con mayor detalle más adelante en la sección titulada "Opciones por omisión" (default) que se pueden personalizar. La categoría de modelo de objeto de auto documentación 308 ilustra cuatro principios y prácticas de diseño de ejemplo. En primer lugar, nombres simples e intuitivos son reservados para los escenarios núcleos, en segundo lugar, los nombres son seleccionados basados en su uso pretendido o el propósito del tipo del componente, en vez de una adherencia de límite oculto a la jerarquía de herencia. En tercer lugar, las excepciones que pueden tener una acción son descartadas, de modo que el desarrollador recibe instrucciones que indican la forma en cómo fijar un error del mensaje de excepción. En cuarto lugar, se producen espacios de nombres limpios, colocando tipos que son difícilmente utilizados en sus espacios de nombre, para evitar la acumulación de espacios de nombre principales. El modelo de objeto de auto documentación 308 se describe con mayor detalle más adelante en la sección titulada "Modelo de Objeto de Auto Documentación". Diseño Conducido por el Escenario En una implementación descrita, las especificaciones de la API son conducidas por los escenarios. Por consiguiente, los diseñadores de la API escriben primero el código que los usuarios de la API tendrán que escribir en los escenarios de núcleo (por ejemplo, principales). Entonces los diseñadores de la API diseñan un modelo de objeto para soportar estas muestras de código. El método contrasta con el inicio de un diseño de un modelo de objeto (utilizando varias metodologías de diseño), y luego escribiendo las muestras del código basados en la API resultante. En otras palabras, especialmente para diseños de API públicas, los diseñadores de la API inician con una lista de escenario para cada característica o área de tecnología y las muestras de código para las mismas y producen una descripción del modelo de objeto de estilo de encabezado basado en las mismas. Los ejemplos de las áreas características incluyen: archivo y/o, conexión a redes, envío de mensajes, consola, diagnósticos, acceso a la base de datos, páginas web, programación de interfases, gráficas del usuario (GUI), y así sucesivamente.

La figura 4 es un diagrama de flujo 400 que ilustra una técnica de ejemplo para el diseño de las API por área de característica. En el bloque 402, se seleccionan escenarios del núcleo para un área de característica determinada. Por ejemplo, para un área de tecnología determinada, pueden ser seleccionados los escenarios superiores del 5 al 10. Ellos pueden ser seleccionados basados en las funciones utilizadas más generalmente (por ejemplo, las tareas más comunes), o las metas perseguidas más frecuentemente para un área de tecnología determinada. Por ejemplo, los escenarios de ejemplo para un área característica de tecnología de archivo y/o se están leyendo de un archivo y escribiendo en un archivo. En el bloque 404, las muestras de código para un escenario de núcleo se escriben en lenguajes múltiples (por ejemplo dos o más). Por ejemplo, las muestras de código asociadas con un escenario de núcleo seleccionado pueden ser escritas en tres lenguajes diferentes. Las muestras de códigos pueden implementar el escenario de código seleccionado actual en los tres lenguajes. Dichos lenguajes incluyen, por ejemplo, VB, C#, MC++, un lenguaje de marca, y así sucesivamente; sin embargo, también se pueden utilizar otros lenguajes. Tal y como lo indica el asterisco, deberá quedar entendido que una muestra de núcleo (o aún más de una muestra de núcleo) pueden ser escritas para el escenario de núcleo en un solo lenguaje cuando se diseña una API poderosa que se puede utilizar para un solo lenguaje. La escritura de las muestras de código en lenguajes múltiples puede ser realizada debido a que algunas veces el código escrito en diferentes lenguajes, difiere de manera importante. En una implementación descrita, las muestras del núcleo para el escenario de núcleo seleccionado actual son escritas utilizando estilos diferentes de codificación que son comunes entre los usuarios del lenguaje particular (por ejemplo, utilizando características o tratados específicos del lenguaje, utilizando las prácticas/hábitos de los desabolladores, etc.), en el cual se escribe una muestra de código particular. Por ejemplo, las muestras pueden ser escritas utilizando el alojamiento específico del lenguaje. Por ejemplo, el VB es un caso-insensible, de modo que las muestras de código escritas en VB reflejan esa variabilidad. Las muestras de códigos escritas en C#, por otra parte, consideran el alojamiento estándar para las mismas. Otro ejemplo se relaciona con una manifestación denominada "uso", la cual soporta el C#. Por ejemplo, la invocación "uso" encapsula un bloque de tratar/finalmente. Sin embargo, no soporta esta característica, y escribiendo los códigos se puede indicar que utilizando esta característica en una declaración de tratar/finalmente, es poco manejable para los usuarios del VB. Todavía otro ejemplo se relaciona con las asignaciones en una cláusula condicional, las cuales soportan el C#. En un ejemplo de archivo y/o: "si funciona el ((texto = reader.Readl_¡ne() != nuil)" en el C#. Sin embargo, la manifestación de asignación no puede ser utilizada dentro de la cláusula "si" en el VB, en vez de ello, el código está dividido en manifestaciones múltiples. Todavía otro ejemplo se relaciona con la tendencia de los desarrolladores del C# a utilizar construcciones parametrizadas, mientras que los desarrolladores del VB no lo harán. Por ejemplo, una codificación del nuevo C# puede ser "MyClass x = yClass ("valor")", mientras que el VB descodificador correspondiente es un "Dim x As MyClass" y "x. Property = "valué". En el bloque 406, la API es derivada del escenario de núcleo actual que responde a las muestras de núcleo escritas en lenguajes múltiples. Por ejemplo, los factores provenientes de las muestras de código escritas en cada uno de los lenguajes múltiples pueden ser incorporadas en la API. Dichos factores pueden incluir similitudes en las diferentes muestras de códigos, diferencias entre dos o más muestras de códigos y así sucesivamente. Dichos factores, así como otros aspectos de los bloques 404 y 406, se describirán con mayor detalle más adelante haciendo referencia a la figura 5.

De un modo similar, cuando se diseña una API para un solo lenguaje, la API es derivada del escenario de núcleo actual que responde a la muestra de núcleo escrita en un solo lenguaje. Por lo tanto, los factores obtenidos de la muestra de código escrita en un solo lenguaje pueden ser incorporados en la API. Como un ejemplo del factor de diseño de la API adicional, para situaciones de un solo lenguaje o lenguajes múltiples, un factor de diseño de la API puede incluir la compatibilidad con las herramientas que están orientadas hacia el lenguaje o lenguajes para los cuales son escritas las muestras de código. En el bloque 408, se determina si la API es demasiado compleja. Por ejemplo, la API puede ser revisada por el diseñador de la API para determinar si la API es o no demasiado compleja. En otras palabras, se puede llevar a cabo una revisión inicial para considerar si la API puede ser utilizada sin un entendimiento importante de otras APIs múltiples específicas, sin la experimentación indebida y así sucesivamente. Dicha revisión inicial también puede verificar si la API derivada realmente puede funcionar en el escenario de núcleo actual en cada lenguaje importante. Si la API es demasiado compleja, entonces la API es refinada por los diseñadores con referencia al escenario de núcleo actual y en respuesta a las muestras del núcleo descritas en los lenguajes múltiples en el bloque 406. Si, por otra parte, se determina que la API no es demasiado compleja (en el bloque 408), entonces el bloque 410 estudia las capacidades de uso que son revisadas por diseñadores típicos. Por ejemplo, se pueden llevar a cabo uno o más estudios de posibilidad de uso que utilizan un ámbito de desarrollo similar al que utiliza normalmente el desarrollador típico. Dicho entorno de desarrollo normal probablemente incluye el sentido inteligente (intellisense), editores, lenguajes y un conjunto de documentación que es más ampliamente usado por el grupo de desabolladores objeti o. Estudios de Posibilidad de Uso Los estudios de posibilidad de uso que están enfocados a un amplio rango de desarrolladores facilitan el diseño conducido por el escenario, especialmente cuando se diseñan APIs públicas generales. Las muestras de códigos escritas por el diseñador de la API para los escenarios núcleo probablemente parecen simples para ellos, pero las muestras de códigos podrían no ser igualmente simples para ciertos grupos de desarrolladores para los que, de hecho, están enfocados (por ejemplo, especialmente novatos y/o desarrolladores ocasionales). Adicionalmente, el entendimiento, el cual es obtenido a través de los estudios de posibilidad de uso con respecto a la manera en la cual manejan los desarrolladores cada escenario del grupo, puede proporcionar una visión poderosa dentro del diseño de la API, y la manera en que cubre las necesidades de todos desarrolladores objetivo.

Generalmente, los estudios de posibilidad de uso pueden ser conducidos temprano en el ciclo del producto y nuevamente después de cualquier rediseño importante del modelo del objeto. Aunque ésta es una práctica de diseño costosa, realmente puede ahorrar recursos a largo plazo. El costo de fijar una API que no se puede utilizar o que simplemente está defectuosa, sin introducir los cambios es enorme . El bloque 412, se asegura si los desabolladores típicos pueden utilizar la API sin problemas importantes. Por ejemplo, la mayor parte de los sujetos podrían describir un código para el escenario seleccionado actual sin problemas mayores. Si ellos no pueden, la API es revisada (tal y como se describe más adelante con referencia al bloque 414). La interpretación de los problemas importantes/mayores, se articula en el nivel deseado de posibilidad de uso para un grupo determinado de desabolladores objetivo. Por ejemplo, la referencia frecuente y/o extensa para la documentación de la API detallada para el escenario de núcleo actual por parte de los sujetos de prueba, puede constituir problemas importantes. Generalmente, si la mayoría de los desabolladores de la prueba no pueden implementar el escenario de núcleo actual, o si el método que ellos utilizan es significativamente diferente al que se espera, la API puede ser valuada para revisiones futuras (hasta e incluyendo un rediseño completo). Si se asegura que los desabolladores típicos no pueden utilizar la API sin problemas mayores (en el bloque 412), entonces en el bloque 414 la API es revisada basada en las lecciones de los estudios de posibilidad de uso. Por ejemplo, se puede cambiar una opción por omisión (default), se puede agregar otra propiedad, se pueden exponer uno o más atributos envés de los encapsulados, y así sucesivamente. Si, por otra parte, se asegura que los desabolladores típicos pueden utilizar la API sin problemas mayores (en el bloque 412), entonces en el bloque 416 se repite el proceso para cada escenario de núcleo. Por ejemplo, otro escenario núcleo de los escenarios núcleo seleccionados para la característica determinada llega a ser el escenario de núcleo actual para el cual las muestras del núcleo son escritas (en el bloque 404). dtra técnica de ejemplo para el diseño de las APIs, la cual sé enfoca más en un diseño de una API de dos capas se describe adicionalmente más adelante en conjunto con la figura 8. La figura 5 es un diagrama de bloque 404/406 que ilustra un esquéma de ejemplo para el diseño de las APIs por escenario de núcleo. El esquema de ejemplo ilustrado corresponde a los bloques 404 y 406 de la figura 4 para una implementación de lenguaje múltiple. Se ¡lustra una muestra del código 502(1) para un primer lenguaje, una muestra de código 502(2) para un segundo lenguaje y una muestra de código 503(3) para un tercer lenguaje. Cada una de las tres muestras de código 502(1, 2, 3) están dirigidas a un escenario de núcleo actual determinado. Aunque se muestran tres muestras de código 502(1, 2, 3) correspondientes a tres lenguajes, se pueden usar alternativamente dos o más muestras de código 502 de cualquier numero arbitrario de lenguajes objetivo en esta implementación de ejemplo de lenguaje múltiple. En una implementación descrita, los factores 506 son recolectados de las muestras de código 502(1, 2, 3) que están escritas en cada uno de los tres lenguajes. Estos factores 506 son incorporados en la API 504. Específicamente, la API 504 está diseñada para soportar las tres muestras de código 502(1, 2, 3) que son escritas en los tres lenguajes correspondientes respectivos. Sin embargo, deberá quedar entendido que los factores 506 también pueden ser aplicables a implementaciones de un solo lenguaje. Algunos factores 506 de ejemplo que se describen anteriormente con referencia a los bloques 404 y 406 de la i figura 4. Y otrojs factores 506 de ejemplos están indicados en el diagrama de bloque 404/406 de la figura 5. Dichos factores 506 incluyen comandos específicos del lenguaje que son rebelados por una revisión de las muestras de clave 502(1, 2, 3). Un ejemplo de una restricción especifica de lenguajes se describe con respecto a la siguiente línea de ejemplo del código: "Foo f = new Foo();". Una API progresiva que está diseñada para soportar esta línea de muestra tienen que incluir un constructor por omisión (default); de otro modo, la muestra del código no se compilará de una manera correcta. Los factores 506 también incluyen expectativas del desarrollador que están inspiradas por ambas las peculiaridades del lenguaje, y los niveles de experiencia/habilidad diferentes de los desarrolladores típicos que gravitan naturalmente hacia los lenguajes diferentes. Los factores 506 incluyen además similitudes de las prácticas de código y codificación en los diferentes lenguajes que se puedan descubrir, por medio de una revisión de las muestras de código 502(1, 2, 3). Aunque se consideran factores 506 que se relacionan directamente con lenguajes diferentes, otros factores 506, como los qué aquí se describen, continúan siendo considerados. Por ejemplo, los siguientes factores 506 también son pertinentes para las APIs progresivas que tienen por objetivo entprnos de un solo lenguaje, así como entornos de lenguaje múltiple. Primero, se requiere que un número de tipos de componentes diferentes que son requeridos para completar un escenario sean un factor. Generalmente, los i tipos de componientes adicionales que son requeridos, hacen más difícil que sean aprendidos. Un segundo factor es la conexión entre las líneas del código siguientes. Hasta el punto en que el uso de un tipo de componente conduce a un desarrollados hacia el uso del segundo tipo de componente requerido, la API es más fácil de utilizar. Tercero, la consistencia en la denominación de los identificadores es otro factor. Un cuarto factor comprende el uso de propiedades, métodos y eventos apropiados. Un quinto factor se relaciona con similitudes posibles a una o más APIs existentes. Sexto, otro factor comprende el cumplimiento con las instrucciones generales de diseño para una API. Un séptimo factor se relaciona con si las APIs se traslapan con otros tipos de componentes del sistema. Octavo, la compatibilidad con las herramientas que están orientadas hacia un lenguaje particular, es todavía otro factor. Por ejemplo, los desabolladores de VB generalmente quieren constructores de menos parámetros y ajustadores de propiedad. Otros factores 506 pueden ser considerados alternativamente. Todavía otros factores 506 que se relacionan con las j interrelaciones | de los componentes agregados y los tipos factorizados se describen a continuación, especialmente haciendo referencia a la figura 8. Aunque el método y esquema de las figuras 4 y 5 puede ser aplicado al diseño de I las APIs en general, son particularmente aplicables al diseño de APIs de dos capas. Un paradigma de API de dos capas (por ejemplo, con componentes agregados y tipos factorizados) se describe a continuación haciendo referencia a las figuras de la 6 a la 8, en la sección titulada "Diseño Orientado a los Componentes. Diseño Orientado a los Componentes La figura 6 ilustra una disparidad potencial entre los tipos de componentes de ejemplo 602 que son objetivos para dos propósitos diferentes a lo largo de una continuidad 600. La continuidad 600 se extiende desde un rango de alta posibilidad de uso al lado izquierdo, a un rango de alta capacidad de control al lado derecho. Los tipos de componentes múltiples 602, son difundidos en la continuidad 600. Generalmente, los tipos de componentes 602 que son ilustrados como que son relativamente más grandes representan tipos que son más simples y por lo tanto, más fáciles de utilizar. Por el contrario, los tipos de componentes 602 que son ilustrados como que son tipos relativamente pequeños representan tipos que son más complejos y por lo tanto, más difíciles de utilizar. Los términos simple y complejo en este contexto, se refieren a la facilidad o a la dificultad que se encuentra para utilizar los tipos de componentes particulares 602 cuando se implementa un escenario especificado. Los tipos componentes 602 que son ilustrados como que son relativamente más pequeños generalmente son más difíciles de utilizar por un número de razones de ejemplo como las siguientes: Primera, los desabolladores tienen más elecciones con respecto a cual de los tipos de componentes 602 deben de utilizar. En el ejemplo ilustrado, existen 14 "opciones" para los tipos de componentes más pequeños 602, comparados con las 3 "opciones" para los tipos de componentes más grandes 602. Más específicamente, un desarrollador debe de saber o discernir de entre los diferentes tipos de componentes 602(HC), qué tipo o tipos de componentes utilizar. Esto comprende el entendimiento de cada uno de los tipos de componentes múltiples 602(HC) (por ejemplo, 14) así como la forma en que ellos se interrelacionan, la cual contrasta con el inicio con un solo tipo de componente 602(HU) de entre los menos tipos de componentes 602(HU) (por ejemplo, 3). Las diferencias entre los tipos de componentes 602(HU) y los tipos de componentes 602(HC) se describen con mayor detalle más adelante. A modo de una analogía de ejemplo, los tipos de componentes más pequeños 602 son como los componentes individuales de un sistema de estéreo; de ahí, que el usuario debe de conocer cuales componentes son necesarios y como enlazarlos. Sin enlazarlos, generalmente no son útiles. Los tipos de componentes más grandes 602 son como los estéreos todo en uno, que son fácilmente utilizables, pero probablemente son menos poderosos, así como menos flexibles. Una segunda razón por lo que los tipos de componentes más pequeños 602 son más difíciles de usar es que existen potencialmente más "puntos de iniciación". Tercero, generalmente existen más conceptos que entender. Cuarto, un desarrollador tiene que entender la forma en que se relacionan los tipos de componentes individuales 602 con los otros tipos de componentes 602. En la implementación descrita, los tipos de componentes 602 son divididos entre aquellos con alta posibilidad de uso 602(HU), y aquellos con una alta capacidad de control 602(HC). Los tipos de componentes con una posibilidad de uso alta 602(HU) son más simples y fáciles de usar, pero tienden a ser más inflexibles, limitativos y/o restrictivos. Generalmente pueden ser utilizados sin un conocimiento extenso de una API general. Los tipos de componente de posibilidad de uso alta 602(HU) generalmente tienen la capacidad de implementar un número limitado de escenarios, y cuando mucho un número limitado de métodos de interés para cada escenario. Los tipos de componente de alta capacidad de control 602(HC), por otra parte, son complejos para utilizarlos, pero proporcionan un grado mayor de control a los desarrolladores. Ellos son relativamente poderosos y hacen posible que los desarrolladores efectúen un toque de bajo nivel y sintonización. Sin embargo, desarrollar los tipos de componentes con alta capacidad de control 602(HC), comprende un entendimiento más completo de muchos tipos de componentes 602 para hacer posible la ejemplificacion de tipos de componentes múltiples de alta capacidad de control 602(HC) que están entrelazados correctamente para implementar hasta escenarios relativamente directos. Generalmente, los tipos de componentes de alta posibilidad de uso 602(HU) están presentes en lenguajes introductorios, tales como el VB, y los tipos de componentes de alta capacidad de control 602(HC) están presentes en lenguajes de tipo de programador profesional avanzado, tales como el C + + . La disparidad potencial entre los tipos de componentes de alta posibilidad de uso 602(HU) y los tipos de componentes de alta capacidad de control 602(HC) que está ¡lustrada en la figura 6, es por lo menos aliviada parcialmente por los tipos de componentes 702 de la figura 7. Específicamente, se establece una interrelación entre los tipos de componentes de alta posibilidad de uso 602(HU) y los tipos de componentes de alta capacidad de control 602(HC), por una API progresiva. La figura 7 ilustra una relación de ejemplo entre los tipos de componentes 702 que son diseñados para que sean extensibles y/o interoperables como para que cubran por lo menos dos propósitos diferentes a lo largo de una continuidad suficiente. En una implementación descrita, los tipos de componentes con un propósito de alta posibilidad de uso son realizados como componentes agregados 702(AC), y los tipos de componentes con un alto propósito de capacidad de control son realizados como el tipo factorizado 702(FT). Aunque los tipos de componentes 702 son divididos solamente entre dos propósitos, ellos pueden ser separados alternativamente en tres o más propósitos (u otras categorías). Una clave 704 indica que una línea sólida representa una relación para los tipos factorizados expuestos y que una línea de guiones representa una relación para los tipos encapsulados factorizados. Tal y como se ilustra, el componente agregado 702(AC)(1) tiene una relación con tres tipos factorizados 702(FT). Específicamente, los tipos factorizados 702(FT)(1) tienen una relación expuesta de tipo factorizado con el componente agregado 702(AC)(1) y los tipos factorizados 702(FT)(2) y 702(FT)(3), tienen una relación encapsulada de tipos factorizados con el componente agregado 702(AC)(1). Aunque no se ilustra de esta manera, dos o más componentes agregados 702(AC) pueden tener una relación encapsulada y/o expuesta con el mismo tipo factorizado 702(FT). Los tipos factorizados expuestos encapsulados 702(FT) y los componentes agregados 702(AC), así como las relaciones entre ellos, se describen con mayor detalle más adelante, incluyendo los que hacen referencia a la figura 8. El diseño orientado a los componentes se relaciona con ofrecer un solo objeto por concepto del usuario opuesto al requerimiento de objetos múltiples por concepto lógico. Por lo tanto, los componentes agregados generalmente corresponden a un concepto del usuario y son más simples desde una perspectiva de posibilidad de uso. Los componentes agregados son colocados en capas en la parte superior de los tipos factorizados. A modo de una comparación de ejemplo, los componentes agregados pueden modelar una cosa tal como un archivo y los tipos factorizados pueden modelar una condición de una cosa, tal como una vista en el archivo. Juntos, los componentes agregados y los tipos factorizados proporcionan una curva de aprendizaje progresiva y gradual para los nuevos desabolladores, especialmente con respecto a una API particular determinada. Diseño Orientado a los Componentes para los Componentes Agregados Muchas áreas características se pueden beneficiar de los tipos apariencia que actúan como vistas simplificadas sobre las APIs de áreas más complejas, pero bien factorizadas restantes de la característica. En una implementación descrita, la apariencia cubre los escenarios del 5 al 10 superiores en un área de característica determinada y opcionalmente, otras operaciones de alto nivel. Los componentes agregados 702(AC) pueden servir como tales tipos apariencia y los tipos factorizados 702(FT) pueden proporcionar un panorama de una API compleja bien factorizada restante. Cada componente agregado se une a múltiples clases factorizadas de nivel más bajo en un componente de nivel más alto para soportar los escenarios de núcleos superiores. Por ejemplo, un componente agregado de correo se puede unir con un protocolo SMTP, con sockets, codificaciones, y así sucesivamente. Generalmente, el componente agregado proporciona un nivel de abstracción más alto, en vez de solamente una manera diferente de hacer las cosas. Proporcionar operaciones de alto nivel simplificadas es útil para aquellos desabolladores que no quieren aprender el grado total de la funcionalidad proporcionada por un área de característica, y simplemente desean realizar sus tareas de una manera frecuente y muy simple, sin un estudio importante o la exploración de la API. Generalmente, el diseño orientado a los componentes es un diseño basado en constructores, propiedades, métodos y eventos. El uso de componentes agregados es una aplicación relativamente extrema de componentes de diseño orientado a los componentes. A continuación se proporciona un conjunto de parámetros de ejemplo para el diseño orientado a los componentes de componentes agregados: Constructores: los componentes agregados tienen constructores por omisión (default) (menos-parámetros). Constructores: los parámetros opcionales del constructor corresponden a las propiedades. Propiedades: la mayor parte de las propiedades tienen afinadores de vacío y ajustadores. Propiedades: las propiedades tienen opciones por omisión (default) sensibles. Métodos: los métodos no toman los parámetros si los parámetros especifican opciones que permanecen constantes en las invocaciones del método (en los escenarios de núcleo seleccionados), dichas opciones pueden ser especificadas utilizando las propiedades. Eventos: los métodos no toman delegados como parámetros. Los recordatorios son implementados en términos de los eventos. El diseño orientado a los componentes comprende tomar en consideración la forma en que son utilizadas las APIs, en vez de enfocarse a las simples inclusiones de los métodos, propiedades y eventos en el modelo de objeto. El modelo de uso de ejemplo para el diseño orientado a los componentes, comprende un patrón para ejemplificar un tipo con una opción por omisión (default), o un constructor relativamente simple, ajustando algunas propiedades del caso y luego invocar los métodos simples. Este patrón es denominado un patrón de uso de Creación-Ajuste-invocación. Un ejemplo general es el siguiente: ' VB ' Ejemplificar Dim T As New T() ' Ajustar propiedades/opciones. T.P1 = V1 T.P2 = V2 T.P3 = V3 ' Métodos de invocación; opcionalmente cambian las opciones entre las invocaciones. T.M1() T.P3 = V4 T.M2() Cuando los componentes agregados soportan este patrón de uso de Creación-Ajuste-Invocación, los componentes agregados se comportan con las expectativas de los usuarios principales de los componentes agregados. Además, se optimizan herramientas, tales como el sentido inteligente (intellisense) y diseñadores, para este patrón de uso. Un ejemplo de código concreto que muestra el patrón de uso Creación-Ajuste-Invocación es el siguiente: 1 VB ' Ejemplificar Dim File As New FileObjectQ ' Ajustar propiedades. File. Filename = "c:\ foo.txt" File. Encoding = Encoding. Ascii ' Método de invocación. File.Open(OpenMode.Write) File.WriteLine("Hello World") File.CloseQ Con un componente agregado de ejemplo, que es parte de una API progresiva, el ajuste de la propiedad "File. Encoding" es opcional. La API tiene una opción por omisión (default) para un archivo previamente seleccionado que codifica si se especifica más de uno. De un modo similar, con respecto a la opción "File.Open()", es opcional especificar un "Open Mode. Write" . Si no se ha especificado, una opción por omisión (default) se emplea "OpenMode" como previamente seleccionado por la API. Un problema con el diseño orientado a los componentes es que da como resultado tipos que pueden tener modos y condiciones inválidos. Por ejemplo, un constructor por omisión (default) permite que los usuarios ejemplifiquen un "FileObject", sin especificar un "FileName". El intentar invocar Open() sin establecer primero el "FileName" da como resultado una excepción debido a que el "FileObject" es una condición inválida con respecto a ser abierta (por ejemplo, todavía no se ha especificado el nombre del archivo). Otro problema es que las propiedades, las cuales se pueden presentar opcional e independientemente, no ponen en acción cambios consistentes y atómicos para la condición del objeto. Además, dichas propiedades "de modo" inhiben el compartir un caso de objeto entre consumidores, debido a que un primer usuario tiene que revisar un valor establecido anteriormente antes de volver a utilizarlo en el caso de que un segundo usuario haya cambiado el valor en el ínterim. Sin embargo, la posibilidad de uso de los componentes agregados contrarresta estos problemas para una basta multitud de desabolladores. Cuando los usuarios invocan métodos que no son válidos en la condición actual del objeto, se descarta un "InvalidOperationException". El mensaje de excepción puede explicar claramente las propiedades que necesitan ser cambiadas para obtener el objeto en una condición válida. Estos mensajes claros de sección superan parcialmente el problema de la condición inválida y dan como resultado un modelo de objeto que es más auto-documentado. Los diseñadores de la API con frecuencia tratan de diseñar tipos, de modo que no puedan existir objetos de una condición inválida. Por ejemplo, esto se lleva a cabo teniendo todos los ajustes requeridos conforme a los parámetros para el constructor, y teniendo propiedades sólo de obtención para los ajustes que no pueden ser cambiados después de la iniciación, o dividiendo la funcionalidad en tipos separados, de modo que las propiedades y métodos no se traslapen. En una implementación descrita, este método es empleado por tipos factorizados, pero no por componentes agregados. Para los componentes agregados, a los desabolladores se les ofrecen excepciones claras que comunican las condiciones inválidas para ellos. Estas excepciones claras pueden ser descartadas cuando una operación está siendo realizada, en vez de hacerlo cuando el componente es inicializado (por ejemplo, cuando un constructor es invocado, o cuando una propiedad es establecida) como para evitar situaciones en donde la condición inválida es temporal, y se obtienen "fijas" en una línea de código posterior. Tipos Factorizados Tal y como se describieron anteriormente, los componentes agregados proporcionan desventajas para la mayor parte de las operaciones comunes de nivel alto y generalmente son implementadas como una apariencia en un conjunto de tipos más complejos, pero también más ricos, los cuales son denominados tipos factorizados. En una implementación descrita, los tipos factorizados no tienen modos y no tienen tiempos de vida muy claros. Un componente agregado puede proporcionar acceso a sus tipos factorizados internos a través de algunas propiedades y/o métodos. Los usuarios acceden a los tipos factorizados internos en escenarios relativamente avanzados, o en escenarios en donde la integración o donde es requerida la integración con partes diferentes de sistema. La capacidad para acceder a los tipos factorizados que están siendo utilizados por un componente agregado, hace posible que la codificación que ha sido escrita utilizando el componente agregado, agregue incrementalmente complejidad para los escenarios avanzados, o se integre con otros tipos de componentes, sin tener que volver a escribir el código desde el inicio, con un enfoque en el uso de los tipos factorizados. El ejemplo siguiente muestra un componente agregado de ejemplo ("FileObject") exponiendo su tipo factorizado interno de ejemplo ("Stream Writer"): ' VB Dim File As New FileObject("c:\foo.txt") File.Open(OpenMode.Write) Fiie.WriteLine("Hello World") AppendMessageToTheWorld(File.StreamWriter) File.Close() Public Sub AppendMessageToTheWorld(ByVal Writer As StreamWriter) End Sub Operaciones de Alto Nivel En una implementación descrita, los componentes agregados, como las APIs de nivel más alto o superior (por ejemplo, desde una perspectiva del nivel de abstracción), son implementados de modo que parecen funcionar "mágicamente" sin que el usuario esté advertido de las cosas que suceden en el fondo, la cuales algunas veces son complicadas. Por ejemplo, un componente agregado "EventLog" oculta el hecho de que un registro tiene una manija solo de lectura y una de escritura, y ambas de las cuales están abiertas con el objeto de usarlas. En la medida que concierne a un desarrollados el componente agregado puede ser ejemplificado, las propiedades pueden ser establecidas, y los eventos de registro pueden ser escritos sin tomar en cuenta el funcionamiento interior. En algunas ocasiones, una transparencia además de un bit puede facilitar alguna tarea con el desarrollados Un ejemplo es una operación en la cual el usuario toma una acción explícita como resultado de la operación. Por ejemplo, el abrir implícitamente un archivo y luego requerir que el usuario lo cierre explícitamente, probablemente toma el principio del funcionamiento "mágico" demasiado lejos. Sin embargo, un diseñador diligente de una API, con frecuencia puede tener la capacidad de diseñar soluciones ingeniosas que ocultan esas complejidades. Por ejemplo, la lectura de un archivo puede ser implementada como una sola operación que abre un archivo, lee su contenido y lo cierra; por lo tanto, el usuario está protegido de las complejidades relacionadas con la abertura y cierre de los archivos. Además, el uso de componentes agregados no comprende la ¡mplementación de interfases algunas, la modificación de archivos de configuración algunos, y así sucesivamente. En vez de ello, los diseñadores de las librerías pueden enviar implementaciones por omisión (default) para fases que son declaradas. Además, los ajustes de configuración son opcionales y soportados por opciones por omisión (default) sensibles. La figura 8 ilustra un componente agregado de ejemplo 702(AC) y los tipos factorizados asociados 702(FT) para manejar dos propósitos diferentes con una API de dos capas 800. El componente agregado 702(AC) representa una primera o la capa más alta y los tipos factorizados 702(FT) representan una segunda o la capa interior. La primera capa efectivamente se construye en la segunda capa con una ¡nterfase de personalización. Tal y como se ¡lustró, el componente agregado 702(AC) incluye elementos de componentes agregados múltiples (AC) 802. Específicamente, se muestran los elementos de los componentes agregados 802(1), 802(2), 802(P)(1), 802(P)(2), 802(M)(1), 802(M)(2), y 802(M)(3). El componente agregado 702(AC) incluye también tipos factorizados expuestos 702(FT-Ex) y tipos factorizados encapsulados 702(FT-En). Específicamente, se muestran los tipos factorizados expuestos 702(FT-Ex)(1 ) y 702(FT-Ex)(2) y los tipos factorizados encapsulados 702(FT-En)(1 ) y 702(FT-En)(2). Los tipos factorizados 702(FT) también incluyen elementos de tipo factorizados (FT) 804. En una implementación descrita, el componente agregado 702(AC) incluye por lo menos un elemento de componente agregado 802, el cual puede ser por ejemplo, un método o una propiedad. Por la tanto, los elementos del componente agregado 802 pueden incluir métodos de componente agregado 802(M), y propiedades de componente agregado 802(P). Estos elementos del componente agregado 802, tales como los elementos del componente agregado 802(1) y 802(2) pueden ser específicos para el componente agregado 702(AC). En otras palabras, algunos elementos del componente agregado 802 igual que los elementos del componente agregado 802(1) y 802(2) que están sobre el componente agregado 702(AC) pueden no depender de tipos factorizados algunos 702(FT). Alternativamente, algunos elementos del componente agregado 802 pueden estar enlazados a tipos factorizados subyacentes 702(FT). Los tipos factorizados 702(FT) pueden ser tipos factorizados expuestos 702(FT-Ex), o tipos factorizados encapsulados 702(FT-En). Los tipos factorizados expuestos 702(FT-Ex) son tipos factorizados 702(FT) de un componente agregado 702(AC) determinado que puede ser accesible por o para otros tipos de componentes generales 702(FT ó AC) sin utilizar o ir a través de los elementos individuales del componente agregado 802 de un componente agregado 702(AC) determinado. Si un tipo factorizado 702(FT-Ex/En) es regresado por el elemento del componente agregado 802 (ya sea un método o una propiedad) entonces ese tipo factorizado 702(FT-Ex) es expuesto. De otro modo, ese tipo factorizado 702(FT-En) es encapsulado. En otras palabras, un elemento del componente agregado 802 puede exponer un elemento de tipo factorizado 804 o un elemento de componente agregado 802 puede regresar un caso de tipo factorizado. Esto ultimo puede ocurrir con los tipos factorizados expuestos 702(FT-Ex), y lo anterior puede ocurrir con los tipos factorizados encapsulados 702(FT-En). Los tipos factorizados encapsulados 702(FT-En) son tipos factorizados 702(FT) de un componente agregado determinado 702(AC) que están contenidos dentro o que son internos para el componente agregado determinado 702(AC). Cada componente factorizado 702(FT) puede incluir uno o más elementos 804 (algunos de los cuales están indicados específicamente en la figura 8) que son métodos y/o propiedades. Tal y como se ilustro, dos elementos de método 804 del tipo factorizado encapsulado 702(FT-En)(1 ) son expuestos por el componente agregado 702(AC), como un elemento de método 802(M)(1) y el elemento de método 802( )(2). Un elemento de método 804 del tipo factorizado encapsulado 702(FT-En)(2) es expuesto por el componente agregado 702(AC), como el elemento del método 802(M)(3). El tipo factorizado 702(FT-Ex)(1 ) está expuesto por sí mismo como un elemento de propiedad 802(P)(1) del componente agregado 702(AC). De un modo similar, el tipo factorizado expuesto 702(FT-Ex)(2) también es expuesto con un elemento de propiedad 802(P)(2) del componente agregado 702(AC). Tal y como se indicó, el elemento del tipo factorizado (FT) 804 del tipo factorizado expuesto 702(FT-Ex)(1) es expuesto como para que sea accesible por separado (por ejemplo, accesible sin utilizar directamente un elemento individual 802 del componente agregado 702(AC)). Por lo tanto, todavía se puede tener acceso a un elemento de tipo factorizado 804 de un tipo factorizado expuesto 702(FT-Ex), si no está expuesto individualmente por un elemento de componente agregado 802 del componente agregado 702(AC). Por lo tanto, el elemento agregado 804 del tipo factorizado expuesto 702(FT-Ex)( 1 ) es expuesto, para que sea accesible para los tipos de componentes 702 que son externos al componente agregado 702(AC) sin utilizar el elemento 802 del mismo. Tal y como lo indica una línea de guiones que emana de tipo factorizado expuesto 702(FT-Ex)(1), los tipos factorizados expuestos 702(FT-Ex), pueden ser "desconectados", para utilizarlos por otros tipos de componentes 702 (especialmente por otros tipos factorizados 702(FT)) que no pueden interactuar con los componentes agregados 702(AC) o que pueden lograr mejor su propósito pretendido, utilizando la desconexión de los tipos factorizados expuestos solos 702(FT-Ex)(1 ). Deberá observarse que el objeto (tipo factorizado expuesto 702(FT-Ex)(1)), que es "desconectado" no es una copia, sino más bien una parte real del componente agregado que se expone 702(AC). Como resultado, las operaciones del objeto desconectado afectan al componente agregado 702(AC). Generalmente, si un tipo factorizado 702(FT) es encapsulado, no está expuesto a un consumidor; en vez de ello, el establecimiento de propiedades 802(P) o la invocación de los métodos 802(M) en un componente agregado 702(AC) puede ocasionar que sean creados tipos factorizados 702(FT), que sean establecidas propiedades 804, o métodos 804 para ser invocados en el tipo factorizado subyacente 702(FT). Estos elementos 802 y 804 pueden tener una correspondencia de uno a uno: por ejemplo, establecer varias propiedades 802(P) en un componente agregado 702(AC), pueden ser almacenados en la memoria instantánea del componente agregado 702(AC). Posteriormente el invocar un método 802(M) en un componente agregado 702(AC) puede ocasionar que sea creado un tipo factorizado 702(FT) utilizando los valores de varias propiedades 802(P) explicados con anterioridad como argumentos del constructor para el tipo factorizado 702(FT). En una implementación descrita, los componentes agregados 702(AC) difieren de los componentes orientados al objeto más tradicionales, de por lo menos dos maneras además de la exposición de los tipos factorizados expuestos 702(FT-Ex). Primero, un componente agregado 702(AC) no expone necesariamente cada elemento 804 de todos sus tipos factorizados 702(FT). En otras palabras, los componentes agregados 702(AC) no están dedicados estrictamente a una jerarquía de herencia. Segundo, los componentes agregados 702(AC) pueden tener modos y por lo tanto, pueden tener periódicamente condiciones que dan como resultado operaciones inválidas. Como una guía para el diseño orientado los componentes con respecto a los factores 506 (de la figura 5), si un tipo factorizado 702(FT) es expuesto o encapsulado dentro de un componente agregado 702(AC) puede estar basado en uno o más de un número de factores. Primero, un tipo factorizado particular 702(FT) es expuesto como un elemento de propiedad 802(P), de un componente agregado determinado 702(AC), si el tipo factorizado particular..702(FT) incluye la funcionalidad que no está expuesta por el componente agregado 702(AC). Segundo, un tipo factorizado particular 702(FT) está expuesto por un elemento de propiedad 802(P), de un componente agregado determinado 702(AC), si otros tipos de componentes generales 702 del sistema se pueden beneficiar de una desconexión para el consumo directo del tipo factorizado particular 702(FT). Por otra parte, un tipo factorizado particular 702(FT) no está expuesto (y por lo tanto, está encapsulado) cuando la funcionalidad del tipo factorizado particular 702(FT) está completamente expuesta por un componente agregado determinado 702(AC) y cuando el tipo factorizado particular 702(FT) no es útil para la desconexión a otros tipos de componente 702. Un desarrollador puede iniciar con el componente agregado 702(AC) especialmente para implementar escenarios más simples y/o de núcleo. Cuando el desarroilador desea o necesita implementar un escenario más complejo, el desarroilador puede comenzar a acceder ¡ncremental y gradualmente de manera directa y utilizar los tipos factorizados expuestos 702(FT-Ex), incluyendo los atributos de bajo nivel de los mismos, con el paso del tiempo. No necesita deshacerse del código original que dependía del componente agregado más simple 702(AC) y reemplazarlo por una codificación más complicada que depende únicamente de los tipos factorizados 702(FT). Las dos capas del sistema API pueden ser utilizadas en proporciones variables y pueden coexistir simultáneamente. El diseño de un sistema API de dos capas puede ser revisado utilizando la siguiente técnica de ejemplo que se describe en dos fases: primero, se selecciona un conjunto de escenarios de núcleo para un área de característica particular. Segundo, se escriben códigos de muestra que muestran líneas de código preferidas para los escenarios de núcleo seleccionados. Tercero, se derivan componentes agregados con los métodos apropiados, opciones por omisión (defaults), abstracciones, denominaciones, etc., para soportar las muestras de código de las líneas de código. Cuarto, las muestras de código de la segunda fase se vuelven a definir según sea apropiado de acuerdo con los componentes agregados derivados. Quinto, las muestras de código redefinidas son evaluadas para determinar si son o no lo suficientemente simples. Si no es así, la técnica continúa nuevamente a la tercera fase. Si es así, entonces en la sexta fase se determina si existen escenarios adicionales, usos, interacciones con otros componentes y/o otros requerimientos. Séptimo, el diseñador de la API decide si cualquiera de los requerimientos adicionales descubiertos en la fase 6 pueden ser agregados a los componentes agregados, sin agregar una complejidad indebida al escenario de núcleo seleccionado. Octavo, si los requerimientos adicionales no pueden ser agregados a los componentes agregados, se define basado en la séptima fase, la factorización ideal (por ejemplo, basada en las metodologías orientadas al objeto u otras metodologías analíticas) de un conjunto completo de funcionalidad para tipos factorizados. Novena, si se determina la forma y si los componentes agregados se encapsulan o exponen la funcionalidad de los tipos factorizados que son definidos en la octava fase. Décima, los tipos factorizados se vuelven a definir según sea apropiado, para soportar los componentes agregados, así como los requerimientos adicionales. Utilizando esta técnica de ejemplo, se puede diseñar un sistema API de dos capas que tiene componentes agregados 702(AC), y tipos factorizados 702(FT).

La figura 9 ilustra un componente agregado de ejemplo 702(AC), y las APIs 902, 802(P), 802(M), y 904 asociadas que pueden soportar un patrón de uso de creación-ajuste-invocación. Se ilustran los siguientes grupos de API de ejemplo: constructores 902, propiedades 802(P), métodos 802(M) y eventos 904. Con un patrón de uso de creación, ajuste, denominación, se crea inicialmente un caso de componente agregado 702(AC) por parte del desarrollador dependiendo de los constructores por omisión (default) 902 (por ejemplo, menos-parámetros). En segundo lugar, el desarrollador establece cualesquiera propiedades 802(P) para los cuales los valores por omisión (default) son inapropiados y/o no preferidos para el uso pretendido del objeto. En tercer lugar, los métodos deseados 802(M) son invocados por el desarrollador. Entonces son implementados los recordatorios en términos de los eventos 904. Opciones por Omisión (Default) Que Se Pueden Personal izar Las opciones por omisión (default) que se pueden personalizar se refieren a aquéllas que tienen opciones por omisión (default) siempre que es práctico para por lo menos los componentes agregados. Cuando se diseña una API, por ejemplo, con muestras de código múltiples correspondientes a lenguajes múltiples, es pasado un valor idéntico en cada una de las muestras de código, en vez de establecer como una opción por omisión (default) para el componente agregado. Las opciones por omisión (default) que se pueden personalizar pueden ser cambiadas, ajustando una o más propiedades del componente agregado. Muchos desarrolladores prefieren codificar por medio de ensayo y error, opuesto a tomarse el tiempo para leer la documentación y entender completamente un área de característica antes de comenzar un proyecto. Esto es particularmente cierto para desarrolladores novatos y ocasionales, tales como aquellos que codifican con VB. Estos desarrolladores con frecuencia tratan de experimentar con una API para descubrir lo que es y cómo funciona, y luego ajustan su código lentamente e incrementalmente hasta que la implementación de la API logra su meta. La popularidad del método de edición y continuación para el desarrollo es una manifestación de esta preferencia. Algunos diseños de API se prestan ellos mismos para la "codificación por experimentación" y algunos no. Existen múltiples aspectos que afectan el nivel de éxito que es probable que tenga un desarrollador cuando utiliza una codificación por el método de experimentación. Estos aspectos incluyen: (i) lo fácil que es localizar la API correcta para la tarea que se tiene a la mano; (ii) lo fácil que es el inicio utilizando una API independientemente de si hace (inicialmente) lo que el desarrollador desea o si no lo hace; (iii) lo fácil que es descubrir qué puntos de la personalización son para una API; (iv) lo fácil que es descubrir la personalización correcta para un escenario determinado; y (v) así sucesivamente. En la implementación deseada, las APIs son diseñadas para que requieren poca, si es que alguna inicialización (por ejemplo, una cantidad mínima de inicialización). Por ejemplo, una API puede ser diseñada de modo que el constructor por omisión (default) o un constructor con un parámetro simple es suficiente para comenzar a trabajar con un tipo. Cuando es necesaria la inicialización, una excepción que es resultado de no realizar la inicialización claramente, explica lo que se necesita hacer y/o cambiar con el objeto de eliminar o evitar la excepción. Por ejemplo, una excepción puede estipular qué o cuáles propiedades necesitan ser ajustadas. A modo de ejemplo pero no de limitación, una regla empírica es que el constructor más simple tiene tres o menos parámetros (con un límite superior de cinco). Además, los constructores más simples deben evitar los tipos complejos ya que cualquiera de los parámetros, cuando los tipos son complejos, pueden ser otros tipos factorizados o componentes agregados. Otra regla empírica, es que los constructores más simples dependen de tipos de primitivas, tales como enumeraciones, cadenas, enteros, y así sucesivamente. Los tipos también pueden implementar cargas de constructores más complejos para soportar escenarios más complejos. Brevemente, la posibilidad de personalización de las APIs puede ser simplificada proporcionando propiedades con buenas opciones por omisión (default) para todos los puntos de personalización. (Sin embargo, los desabolladores generalmente deben de poder agregar nuevos códigos al código existente cuando están personalizando sus escenarios; debe de ser opcional volver a escribir un código completo desde cero utilizando una API diferente). Por ejemplo, una fila de envíos de mensaje de sistema agrega componentes que hacen posible el envío de mensajes después de pasar una cadena de trayectoria del constructor, e invocar un método de envío. Las propiedades del mensaje, tales como la prioridad del mensaje y los algoritmos de encriptación, pueden ser personalizados agregando códigos al escenario de núcleo. Modelo de Objeto de Autodocumentación El modelo de objeto de autodocumentación se refiere al diseño de un sistema API en el cual un desarrollador puede mirar objetos y elementos del mismo para aprender acerca de ellos, y también cómo puede utilizarlos. Por ejemplo, los nombres pueden estar basados en como se espera que pueda ser utilizado un tipo, en vez de la dedicación a una jerarquía de herencia que muchos desabolladores no desean estudiar.

Brevemente, un modelo de objeto de autodocumentación facilita la capacidad de descubrimiento por los que serían los desarrolladores. Tal y como se indicó anteriormente, algunos desarrolladores prefieren codificar por medio del método de ensayo y error, y clasificar para la documentación solo de lectura cuando falla su intuición para ¡mplementar su escenario preferido. Por lo tanto, el modelo de objeto de autodocumentación debe evitar el requerimiento de que los desarrolladores lean la documentación cada vez que quieren realizar hasta tareas simples. A continuación se presenta un conjunto de principios de ejemplo y prácticas para ayudar a producir las APIs intuitivas que son relativamente de autodocumentación para una implementación descrita. Se pueden utilizar cualquiera o más de ellas con una API determinada y/o implementación del diseño API. Denominación Un principio de guía es reservar nombres simples e intuitivos para tipos que necesitan utilizar los usuarios (por ejemplo, ejemplificar) en los escenarios más comunes. Los diseñadores con frecuencia "malgastan" los mejores nombres para las abstracciones, con las cuales no tienen que estar relacionados la mayor parte de los usuarios. Por ejemplo, ia denominación de una clase básica abstracta "archivo" y luego proporcionar un tipo concreto "XYZFile" funciona bien si las expectativas es que todos los usuarios tendrán que entender la jerarquía de herencia antes de que puedan comenzar a utilizar las APIs. Sin embargo, si los usuarios no entienden la jerarquía, lo primero que es probable que traten de utilizar, y muy frecuentemente de manera poco exitosa, es el tipo de "Archivo". Más específicamente, los nombres más comunes y esperados están reservados para los componentes agregados que tienen por objetivo los escenarios de núcleos superiores con nombres menos comunes o familiares utilizados en conceptos y abstracciones. Un segundo principio de guía es utilizar nombres del identificador descriptivos que manifiesten claramente cuál de cada método hace y cuál de cada tipo y parámetro representa. Por ejemplo, los diseñadores de API no deben de dudar en ser más bien verbosos cuando seleccionan los nombres del identificador. Por ejemplo, "EventLog. DeleteEventSource (fuente de cadena, string machineName", puede ser visto como más bien muy verboso, pero se puede argüir que tiene un valor de capacidad de utilización positiva neto. Además, los nombres de los tipos y parámetros manifiestan que es lo que representa un tipo o parámetro, en vez de lo que hace. Los nombres de los métodos manifiestan lo que hace el método. Por supuesto, un método verboso exacto no tiene nombres que son más fáciles para los métodos que tienen semánticas simples y claras, la cual es otra razón por la que se evitan las semánticas complejas, lo cual es un buen principio general de diseño para seguir. Una guía de la práctica de diseño es incluir una explicación acerca de las selecciones de denominación como una parte importante de las revisiones y/o pruebas de la especificación de la API. Las consideraciones y preguntas de ejemplo incluyen: ¿Cuáles son los tipos con los que inicia la mayor parte de los escenarios?, ¿Cuáles son los nombres que la mayor parte de la gente cree que son los primeros cuando tratan de implementar un escenario determinado? ¿Son los nombres de los tipos comunes los que los usuarios piensan primero?. Por ejemplo, debido a que "archivo" es el nombre en el que la mayor parte de la gente piensa cuando está tratando con escenarios de archivo y/o, el componente agregado para acceder a los archivos, puede ser denominado "archivo". Adicionalmente, los métodos utilizados más generalmente de los tipos utilizados de manera más común y sus parámetros son revisados y probados. Por ejemplo, ¿puede cualquiera que está familiarizado con la tecnología, pero no con el diseño específico de la API que está bajo consideración, reconocer e invocar rápida, correcta y fácilmente todos los métodos? Excepciones Tal como se explicó anteriormente, las excepciones pueden facilitar las APIs de autodocumentación . En otras palabras, las APIs deben de conducir al usuario para hacer la siguiente cosa requerida y las excepciones tienen la capacidad y son buenas para comunicar lo que se requiere después. Por ejemplo, el siguiente código de ejemplo lanza una excepción con un mensaje que necesita "la propiedad 'FileName', para ser establecida antes de intentar abrir el 'FileObject"".

'VB 'Ejemplificar Dim File As New FileObjectQ ?? nombre del archivo no se ha establecido. File.OpenQ Tipificación Fuerte Otro principio de guía para facilitar las APIs intuitivas es la tipificación fuerte. Por ejemplo, invocar "Customer. Ñame" es más fácil que invocar "Customer. Properties['Name']". Además, teniendo dicha propiedad "Nombres" se regresa el nombre común a la cadena que se puede utilizar más que si la propiedad regresada es un objeto. Existen casos en donde la propiedad lleva un accesador basado en una cadena, invocaciones de enlace posterior, y otros tipos que no son tan fuertes de APIs como son desean, pero son relegadas a la rareza y no son la regla. Además, los diseñadores de la API pueden proporcionar auxiliares fuertemente tipificados para las operaciones más comunes que realiza el usuario en la capa de API tipificada no tan fuertemente. Por ejemplo, un tipo de cliente puede tener una bolsa de propiedad, pero puede proporcionar adicionalmente APIs tipificadas fuertemente para propiedades más comunes "nombre", "dirección", y así sucesivamente. Vectorización hacia la Simplicidad Todavía otro principio de guía es esforzarse por la simplicidad, especialmente para los escenarios de núcleo. Las metodologías estándar de diseño son auxiliadas produciendo diseños que son optimizados para su capacidad de mantenimiento, tales como utilizando abstracciones. Por consiguiente, las metodologías de diseño moderno producen muchas de las abstracciones. Un problema es que muchas metodologías de diseño operan sobre un supuesto de que los usuarios de los diseños resultantes se volverán expertos en ese diseño antes de empezar a implementar aún los escenarios simples. Sin embargo, con frecuencia no son los casos en el mundo real. En una implementación descrita, para escenarios por lo menos simples, los diseñadores de la API aseguran que las jerarquías del modelo de objeto sean lo suficientemente simples para que ellas puedan ser utilizadas sin tener que entender la forma en que se adapta junta o interopera el área de la característica completa. Una API bien diseñada resultante puede requerir que el desarrollador entienda el escenario de núcleo que está siendo implementado, pero no requiere un entendimiento completo del diseño de la librería que está siendo implementada para utilizarlo. Generalmente, las APIs de escenario de núcleo están enfocadas o corresponden a partes lógicas físicas o bien conocidas del sistema, en vez de las abstracciones. Los tipos que corresponden a las abstracciones generalmente son difíciles de utilizar sin el entendimiento de la forma en que encajan e interoperan todas las partes del área de la característica. Por lo tanto, son más importantes cuando es requerida una integración de característica cruzada. Otra práctica de guía es utilizar las metodologías estándar de diseño (por ejemplo, UML) cuando se diseñan arquitecturas internas y algunos de los tipos f actorizados, pero no cuando se diseñan las APIs para los escenarios de núcleo o comunes (por ejemplo, aquellos con componentes agregados). Cuando se diseñan componentes agregados para los escenarios de núcleo, el diseño conducido por el escenario junto con el establecimiento de prototipos, los estudios de posibilidad de uso y la iteración (tal como se describieron anteriormente) son utilizados en vez de ellos.

Espacios de Nombres Limpios Todavía otro principio de guía es que los tipos que son utilizados rara vez (muchos) son colocados en subnombres de espacios para evitar el agrupamiento de los nombres de espacio principales. Por ejemplo, los siguientes dos grupos de tipos pueden ser separados de sus nombres de espacio principales: tipos de permiso y tipos de diseño. Por ejemplo, los tipos de permiso pueden residir en un subnombre de espacio "permiso", y los tipos solo para el tiempo de diseño pueden residir en un subnombre de espacio "diseño". Las acciones, aspectos, características, componentes, etc. de las figuras de la 1 a la 9 están ilustrados en diagramas que están divididos en bloques múltiples. Sin embargo, el orden, interconexiones, interrelaciones, distribución, etc. en los cuales están descritas y/o están mostradas las figuras de la 1 a la 9 no pretenden ser interpretadas como una limitación, y cualquier número de bloques pueden ser modificados, combinados, reacomodados, aumentados, omitidos, etc., de cualquier manera para implementar uno o más sistemas, métodos, aparatos, procedimientos, medios, aparatos de APls, aparatos, adaptaciones, etc. para diseñar las APls. Además, aunque la presente descripción incluye referencias e implementaciones específicas (y el entorno operativo de ejemplo de la figura 10), las implementaciones ilustradas y/o descritas pueden ser ¡mplementadas en cualquier hardware, software, firmware o combinación adecuada de los mismos, y utilizando cualquier arquitectura de software, lenguaje de codificación, definiciones de escenario, formato de estudio de posibilidad de uso, adecuados y así sucesivamente. Entorno Operativo de Ejemplo para Computadoras y Otros Aparatos La figura 10 ilustra un entorno operativo de cómputo de ejemplo (un aparato general) 1000 que tiene la capacidad de implementar (total o parcialmente) por lo menos un sistema, aparato, componente, adaptación, protocolo, métodos, procedimientos, medios, APIs, alguna combinación de los mismos, etc., para diseñar las APIs tal y como aquí se describen. Los entornos de operación 1000 pueden ser utilizados en arquitecturas de computadora y red que se describen más adelante. El entorno operativo de ejemplo 1000 solamente es un ejemplo de un entorno y no se pretende sugerir cualquier limitación con respecto al alcance de uso o funcionalidad del aparato aplicable (incluyendo computadora, nodo de red, aparato de entretenimiento, accesorio móvil, aparatos electrónicos generales, etc.) arquitecturas. Ni los entornos operativos 1000 (o aparatos de los mismos) pueden ser interpretados como que tienen dependencia o requerimiento alguno relacionado con cualquiera o con cualquier combinación de componentes, tal y como se ilustraron en la figura 10. Adicionalmente, el diseño de las APIs y/o las APIs resultantes de los mismos pueden ser implementadas con otros propósitos generales numerosos o aparatos para propósitos especiales (incluyendo sistemas de cómputo) ambientes o configuraciones. Los ejemplos de aparatos, sistemas, ambientes y/o configuraciones bien conocidos que pueden ser adecuados para utilizarlos incluyen, pero no están limitados a, computadoras personales, computadoras de servidor, clientes delgados, clientes gruesos, asistentes personales digitales (PDAs) o teléfonos móviles, relojes, aparatos portátiles y manuales, sistemas de multiprocesadores, sistemas basados en microprocesadores, cajas de descodificadores, productos electrónicos programables por el consumidor, máquinas de video-juegos, consolas de juegos, unidades de juegos manuales o portátiles, PCs de red, minicomputadoras, computadoras de sistema, nodos de red, entornos de cómputo de procesamiento múltiple o distribuido que incluyen cualquiera de los sistemas o aparatos anteriores, algunas combinaciones de los mismos y así sucesivamente. Las implementaciones para el diseño de las APIs y/o las APIs resultantes de las mismas se pueden describir en el contexto general de las instrucciones ejecutables por el procesador. Generalmente, las instrucciones ejecutables por el procesador Incluyen rutinas, programas, módulos, protocolos, objetos, interfases, componentes, estructuras de datos, etc., que realizan y/o hacen posible tareas particulares y/o implementan tipos de datos abstractos particulares. El diseño de las APIs y/o las APIs resultantes de los mismos tal y como se describieron en algunas implementaciones de la presente descripción, también pueden ser practicados y/o estar presentes en entornos de procesamiento distribuidos en donde las tareas son realizadas por aparatos de procesamiento enlazados remotamente que están conectados a través de un enlace de comunicación y/o red. Especialmente pero no exclusivamente, en un entorno de cómputo distribuido, las instrucciones ejecutables por el procesador pueden ser localizadas en medios de almacenamiento separados, ejecutadas por diferentes procesadores y/o propagadas por medios de transmisión. El entorno de operación de ejemplo 1000 incluye un aparato de cómputo de uso general en la forma de una computadora 1002, la cual puede comprender cualquier (por ejemplo aparato electrónico) con capacidades de cómputo/procesamiento. Los componentes de la computadora 1002 pueden incluir, pero no están limitados a, uno o más procesadores o unidades de procesamiento 1004, un sistema de memoria 1006, y un bus del sistema 1008 que conecta diferentes componentes del sistema incluyendo el procesador 1004 a la memoria del sistema 1006. Los procesadores 1004 no están limitados por los materiales de los cuales están formados, o los mecanismos de procesamiento que se emplean en los mismos. Por ejemplo, los procesadores 1004 pueden comprender semiconductores y/o transistores (por ejemplo, circuitos electrónicos integrados (ICs)). En dicho contexto, las instrucciones ejecutables por el procesador pueden ser instrucciones ejecutables electrónicamente. Alternativamente, los mecanismos de y para los procesadores 1004, y aquellos de y para la computadora 1002, pueden incluir, pero no están limitados a, el cómputo cuántico, el cómputo óptico, el cómputo mecánico (por ejemplo, que utiliza nanotecnología) y así sucesivamente. El bus del sistema 1008 representa uno o más de cualquiera de muchos tipos de estructuras de bus cableados o inalámbricos, incluyendo un bus de memoria o un controlador del bus, una conexión de punto a punto, un material de conmutación, un bus periférico, un puerto acelerado de gráficos, y un procesador o bus local que utiliza cualquiera de una variedad de arquitecturas del bus. A modo de ejemplo, dichas arquitecturas pueden incluir una arquitectura estándar de la industria (ISA), en la forma de un bus, un bus de arquitectura de microcanal (MCA), un bus ISA Mejorado (EISA), un bus local de la Asociación de Estándares Electrónicos de Video (VESA), y un bus que interconecta componentes periféricos (PCI) como un bus de Mezzanine, alguna combinación de los mismos y así sucesivamente. La computadora 1002 generalmente incluye una variedad de medios accesibles para el procesador. Dichos medios pueden ser cualesquiera medios adecuados a los que se pueda acceder por medio de una computadora 1002 u otro aparato (por ejemplo electrónico), que incluye tanto medios volátiles como no volátiles, medios removibles como no removibles, y medios de almacenamiento y transmisión. La memoria del sistema 1006 incluye un medio de almacenamiento accesible para el procesador en la forma de una memoria volátil, tal como una memoria de acceso aleatorio (RAM) 1040, y/o una memoria no volátil tal como una memoria sólo de lectura (ROM) 1012. Un sistema de entrada/salida básico (BIOS) 1014, que contiene rutinas básicas que ayudan a transferir información entre elementos dentro de la computadora 1002, tal como durante el inicio, que generalmente es almacenado en una memoria ROM 1012. La memoria RAM 1010 generalmente contiene datos y/o módulos/instrucciones del programa que son accesibles inmediatamente para y/o que están siendo operados actualmente por la unidad de procesamiento 1004. La computadora 1002 también puede incluir otros medios de almacenamiento removibles/no removibles y/o volátiles/no volátiles. A modo de ejemplo, la figura 10 ilustra una unidad de disco duro, o una matriz de unidad de disco duro 1016 para leer y escribir (generalmente) medios magnéticos no removibles, no volátiles (no mostrados por separado); una unidad de disco magnético 1018 para leer y escribir un disco magnético removible (generalmente) no volátil 1020 (por ejemplo, un "disquete"); una unidad de disco óptico 1022 para leer y/o escribir en un disco óptico (generalmente) removible, no volátil 1024 tal como un CD, DVD, u otros medios ópticos. La unidad del disco duro 1016, la unidad del disco magnético 1018 y la unidad del disco óptico 1022 cada una están conectadas al bus del sistema 1008 por una o más ¡nterfases de medios de almacenamiento 1026. Alternativamente, la unidad del disco duro 1016, la unidad del disco magnético 1018 y la unidad del disco óptico 1022 pueden estar conectados al bus del sistema 1008 por medio de una o más de otras interfases separadas o combinadas (no mostradas). Las unidades de disco y sus medios accesibles al procesador asociado proporcionan el almacenamiento no volátil de las instrucciones ejecutables por el procesador, tales como estructuras de datos, módulos del programa y otros datos para la computadora 1002. Aunque la computadora de ejemplo 1002 ilustra un disco duro 1016, un disco magnético removible 1020 y un disco óptico removible 1024, se deberá apreciar que son accesibles otros tipos de medios accesibles al procesador que pueden almacenar instrucciones para un aparato, tales como casetes magnéticos y otros aparatos de almacenamiento magnéticos, memoria instantánea, discos compactos (CDs), discos digitales versátiles (DVDs), u otro almacenamiento óptico, memorias RAM, ROM, memorias sólo de lectura programables que se pueden borrar eléctricamente (EEPROM), y así sucesivamente. Dichos medios también incluir los chips IC de cables duros, o de propósitos especiales. En otras palabras, se puede utilizar cualesquiera medios accesibles por el procesador para realizar los medios de almacenamiento del entorno operativo de ejemplo 1000. Pueden ser almacenados cualquier número de módulos del programa (u otras unidades o conjuntos de instrucciones/códigos, incluyendo un sistema API y/o basados en los objetos en el mismo), en el disco 1016, el disco magnético 1020, el disco óptico 1024, la memoria ROM 1012, y/o la memoria RAM 1040, incluyendo a modo de ejemplo general, un sistema operativo 1028, uno o más programas de aplicación 1030, otros módulos del programa 1032 y datos del programa 1034. Un usuario puede ingresar comandos y/o información en la computadora 1002 por medio de los aparatos de entrada, tales como un teclado 1036 y un aparato de señalización 1038 (por ejemplo un "ratón"). Otros aparatos de entrada 1040 (no mostrados específicamente) pueden incluir un micrófono, palanca, almohadilla de juego, un plato de satélite, un puerto de serie, un escáner y/o similares. Estos y otros aparatos de entrada son conectados a la unidad de procesamiento 1004 por medio de interfase de entrada/salida 1042 que están conectadas al bus del sistema 1008. Sin embargo, los aparatos de entrada y/o aparatos de salida pueden ser conectados en vez de ellos por otra interfase y estructuras del bus, tales como un puerto paralelo, un puerto de juego, un puerto del bus de serie universal USB), un puerto infrarrojo, una interfase IEER 1394 ("Firewire"), una interfase inalámbrica IEEE 802.11, una interfase inalámbrica Bluetooth®, y así sucesivamente. La pantalla de visión/monitor 1044 y otro tipo de pantalla también pueden estar conectados al bus del sistema 1008 por medio de una interfase, tal como un adaptador de video 1046. El adaptador de video 1046 (u otro componente) pueden ser o pueden incluir una tarjeta de gráficos para los cálculos intensos de gráficos de procesamiento y para manejar requerimientos que demanda la pantalla. Generalmente, una tarjeta de gráficos incluye una unidad de procesamiento de gráficos (GPU), una memoria RAM de video (VRAM), etc., para facilitar el despliegue en pantalla rápido de los gráficos y la realización de operaciones de gráficos.

Además el monitor 1044, otros aparatos periféricos de salida pueden incluir componentes tales como bocinas (no mostradas), y una impresora 1048, la cual puede estar conectada a la computadora 1002 por medio de interfases de entrada/salida 1042. La computadora 1002 puede operar en un ambiente de red utilizando conexiones lógicas a una o más computadoras remotas, tales como un aparato de cómputo remoto 1050. A modo de ejemplo, el aparato de cómputo remoto 1050 puede ser una computadora personal, una computadora portátil (computadora portátil, computadora de tableta, PDA, estación móvil, etc., una computadora de bolsillo, un reloj, un aparato de juegos, un servidor, un enrutador, una computadora de red, un aparato semejante, otro nodo de red u otro aparato del tipo de la lista anterior, y así sucesivamente. Sin embargo, el aparato de cómputo remoto 1050 es ilustrado con una computadora portátil que puede incluir muchos y todos los elementos y características aquí descritos con respecto a la computadora 1002. Las conexiones lógicas entre la computadora 1002 y la computadora remota 1050 están ilustradas como una red de área local (LAN) 1052, y una red de área ancha general (WAN) 1054. Dichos ambientes de red son un lugar común en las oficinas, redes de cómputo amplias de las empresas, intranets, la Internet, redes telefónicas fijas y móviles, redes inalámbricas de infraestructura y ad-hoc, otras redes inalámbricas, redes de juegos, algunas combinaciones de las mismas y así sucesivamente. Dichas redes y conexiones de comunicación son ejemplos de los medios de transmisión. Cuando está implementada en un ambiente de red LAN, la computadora 1002 generalmente es conectada a la LAN 1052 por medio de una interfase de red o adaptador 1056. Cuando está implementada en un entorno de red WAN, la computadora 1002 generalmente incluye un módem 1058 u otro componente para establecer comunicaciones por la WAN 1054. El módem 1058, el cual puede ser interno o externo a la computadora 1002, puede ser conectado al bus del sistema 1008 por medio de interfases de entrada/salida 1042, o cualquier otro mecanismo apropiado. Deberá apreciarse que las conexiones de red ilustradas son ejemplos y que se pueden emplear otras maneras para establecer enlaces de comunicación entre las computadoras 1002 y 1050. En un ambiente de red, tal como el entorno de operación ¡lustrado 1000, los módulos de programa y otras instrucciones que son ilustradas en relación con la computadora 1002 o porciones de los mismos, pueden ser almacenados total o parcialmente en un aparato de almacenamiento de medios remoto. A modo de ejemplo, los programas de aplicación remota 1060 residen en un componente de memoria de la computadora remota 1050, pero pueden ser utilizados o se puede acceder a ellos de otro modo por medio de la computadora 1002. También, para propósitos de aplicación, los programas de aplicación 1030 y otras instrucciones ejecutables por el procesador, tales como el sistema operativo 1028 están ilustrados aquí como bloques separados, pero debe de ser reconocido que dichos programas, componentes y otras instrucciones residen en diferentes tiempos de los diferentes componentes de almacenamiento del aparato de cómputo 1002 (y/o aparato de cómputo remoto 1050) y son ejecutados por el procesador 1004 de la computadora 1002 (y/o aquellos del aparato de cómputo remoto 1050). Aunque los sistemas, medios, aparatos, métodos, procedimientos, técnicas, APIs, esquemas, métodos, procedimientos, matrices y otras implementaciones han sido descritas en un lenguaje específico para las características y/o diagramas estructurales, lógicos, algorítmicos, funcionales y características basadas en la acción, deberá quedar entendido que la presente invención definida en las reivindicaciones adjuntas, no está necesariamente limitada a las características o diagramas específicos aquí descritos. En vez de ello, las características y diagramas específicos están descritos en formas de ejemplos de implementación de la invención reclamada.

Claims (59)

1. REIVINDICACIONES 1. Un método para el diseño de una interfase de programación de aplicación (API), comprendiendo el método: la preparación de una pluralidad de muestras de códigos para un escenario de núcleo, correspondiendo cada muestra de código respectiva de la pluralidad de muestras de código a un lenguaje de programación respectivo de una pluralidad de lenguajes de programación; y derivar una API del escenario de núcleo en respuesta a la pluralidad de muestras de código.
2. 2. El método tal y como se describe en la reivindicación 1, el cual comprende además: determinar por parte del diseñador de la API, si la API derivada es demasiado compleja.
3. 3. El método tal y como se describe en la reivindicación 2, el cual comprende además: si la API derivada es determinada como demasiado compleja, entonces redefinir, por parte del diseñador de la API, la API derivada para producir una API refinada.
4. 4. El método tal y como se describe en la reivindicación 3, el cual comprende además: determinar por el diseñador de la API, si la API refinada es demasiado compleja.
5. 5. El método tal y como se describe en la reivindicación 1, el cual comprende además: realizar uno o más estudios de posibilidad de uso de la API utilizando una pluralidad de desarrolladores.
6. 6. El método tal y como se describe en la reivindicación 5, caracterizado porque la realización comprende: realizar el uno o más estudios de posibilidad de uso en la API utilizando la pluralidad de desarrolladores en donde la pluralidad de desarrolladores son típicos para la pluralidad de lenguajes de programación.
7. 7. El método tal y como se describe en la reivindicación 5, el cual comprende además: asegurar si la pluralidad de desarrolladores pueden utilizar la API sin problemas importantes.
8. 8. El método tal y como se describe en la reivindicación 7, el cual comprende además: si la pluralidad de los desarrolladores no puede asegurar que pueden utilizar la API sin problemas importantes, entonces revisar la API.
9. 9. El método tal y como se describe en la reivindicación 8, caracterizado porque la revisión comprende: revisar la API basada en por lo menos una lección de uno o más estudios de posibilidad de uso.
10. 10. El método tal y como se describe en la reivindicación 1, en donde la derivación comprende: derivar la API para soportar la pluralidad de muestras de códigos que corresponde respectivamente a la pluralidad de lenguajes de programación.
11. 11. El método tal y como se describe en la reivindicación 1, caracterizado porque la derivación comprende: recolectar los comandos específicos del lenguaje de la pluralidad de las muestras de código; e incorporar comandos específicos de lenguaje en la API.
12. 12. El método tal y como se describe en la reivindicación 1, caracterizado porque la derivación comprende: recolectar las expectativas del desarrollador inspiradas en el lenguaje proveniente de la pluralidad de muestras de código; e incorporar las expectativas del desarrollador inspiradas en el lenguaje en la API.
13. 13. El método tal y como se describe en la reivindicación 1, caracterizado porque la derivación comprende: recolectar similitudes de la pluralidad de muestras de código; e incorporar las similitudes en la API.
14. 14. El método tal y como se describe en la reivindicación 1, caracterizado porque la derivación comprende: derivar la API para que tenga un componente agregado que une una pluralidad de tipos factorizados de nivel más bajo juntos para soportar el escenario del núcleo.
15. 15. Un método para diseñar una interfase de programa de aplicación (API), comprendiendo el método: seleccionar un escenario de núcleo para un área de característica ; escribir por lo menos una muestra de código para el escenario de núcleo; y derivar una API para el escenario de núcleo en respuesta a por lo menos una muestra de código.
16. 16. El método tal y como se describe en la reivindicación 15, caracterizado porque la selección comprende: seleccionar una pluralidad de escenarios de núcleo para el área de característica.
17. 17. El método tal y como se describe en la reivindicación 16, el cual comprende además: repetir la escritura y la derivación de cada escenario de núcleo de la pluralidad de escenarios de núcleo que son seleccionados para el área de característica.
18. 18. El método tal y como se describe en la reivindicación 15, caracterizado porque la escritura comprende: escribir una pluralidad de muestras de códigos para el escenario de núcleo, y cada muestra de código respectiva de la pluralidad de las muestras de código correspondiente a un lenguaje de programación respectivo de una pluralidad de lenguajes de programación.
19. 19. El método tal y como se describe en la reivindicación 18, caracterizado porque la derivación comprende: derivar la API para el escenario de núcleo en respuesta a la pluralidad de muestras de código.
20. 20. El método tal y como se describe en la reivindicación 15, el cual comprende además: realizar uno o más estudios de posibilidad de uso en la API utilizando una pluralidad de desabolladores; asegurar si la pluralidad de desabolladores pueden utilizar la API sin problemas importantes; y si no se asegura que la pluralidad de desabolladores puedan utilizar la API sin problemas importantes, entonces revisar la API.
21. 21. El método tal y como se describe en la reivindicación 20, caracterizado porque la revisión comprende: revisar la API basada en por lo menos una lección del uno o más estudios de posibilidad de uso para producir una API revisada.
22. 22. El método tal y como se describe en la reivindicación 21, el cual comprende además: repetir la realización y el aseguramiento con respecto a la API revisada.
23. 23. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: derivar la API para soportar por lo menos una muestra de código escrita para el escenario de núcleo produciendo una API de dos capas que incluye un componente agregado y una pluralidad de tipos factorizados subyacentes.
24. 24. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: recolectar uno o más comandos específicos del lenguaje desde al menos una muestra de código; e incorporar el uno o más comandos específicos del lenguaje en la API.
25. 25. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: encapsular un tipo factorizado particular en un componente agregado que está asociado con el escenario de núcleo si todos los elementos del tipo factorizado particular son expuestos por el componente agregado.
26. 26. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: encapsular un tipo factorizado particular en un componente agregado que está asociado con el escenario de núcleo si el tipo factorizado particular no es interesante independientemente para otros tipos de componentes.
27. 27. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: exponer un tipo factorizado particular de un componente agregado que está asociado con el escenario de núcleo, si por lo menos un elemento del tipo factorizado particular no es expuesto por el componente agregado.
28. 28. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: exponer un tipo factorizado particular de un componente agregado que está asociado con el escenario de núcleo si el tipo factorizado particular puede ser utilizado provechosamente por otro tipo de componente de manera independiente del componente agregado.
29. 29. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: producir un sistema de dos capas que incluye tipos de componentes que tienen por objetivo un nivel de abstracción relativamente más alta, y tipos de componentes que tienen por objetivo un nivel de abstracción relativamente más baja.
30. 30. El método tal y como se describe en la reivindicación 29, caracterizado porque los tipos de componentes que tienen por objetivo el nivel de abstracción relativamente más alto están enfocados a los escenarios de núcleo.
31. 31. El método tal y como se describe en la reivindicación 29, caracterizado porque los tipos de componentes que tienen por objetivo el nivel de abstracción relativamente más bajo proporcionan una cantidad relativamente mayor de control a los desabolladores comparados con los tipos de componentes que tienen por objetivo el nivel de abstracción relativamente más alto.
32. 32. El método tal y como se describe en la reivindicación 15, caracterizado porque la derivación comprende: derivar la API como para hacer posible que un desarrollador implemente un patrón de uso de creación-ajuste-invocación para el escenario de núcleo.
33. 33. El método tal y como se describe en la reivindicación 32, caracterizado porque la derivación comprende: producir la API con parámetros previamente seleccionados que son apropiados para el escenario de núcleo.
34. 34. Un método para diseñar una interfase de programación de aplicación (API), comprendiendo el método: derivar una API para un escenario en respuesta por lo menos una muestra de código escrita con respecto al escenario; realizar uno o más estudios de posibilidad de uso de la API utilizando una pluralidad de desabolladores; y revisar la API basada en dichos uno o más estudios de posibilidad de uso.
35. 35. El método tal y como se describe en la reivindicación 34, el cual comprende: escribir una pluralidad de muestras de código con respecto al escenario, correspondiente cada muestra de código respectiva de la pluralidad de muestras de códigos a un lenguaje de programación respectivo de una pluralidad de lenguajes de programación; caracterizado porque la derivación comprende: derivar la API para el escenario en respuesta a la pluralidad de muestras de código.
36. 36. El método tal y como se describe en la reivindicación 34, el cual comprende además, antes de realizar uno o más estudios de posibilidad de uso de la API: determinar por el diseñador de la API, si la API derivada es demasiado compleja; si la API derivada es determinada como demasiado compleja, entonces retinar por el diseñador de la API, la API derivada para producir una API refinada; y determinar por el diseñador de la API, si la API refinada es demasiado compleja.
37. 37. El método tal y como se describe en la reivindicación 34, el cual comprende además: asegurar si la pluralidad de desabolladores pueden utilizar la API sin problemas significativos; y cuando no se asegura que la pluralidad de desabolladores pueden utilizar la API sin problemas importantes, entonces implementar la revisión; en donde la revisión comprende: revisar la API basada en por lo menos una lección de uno o más estudios de posibilidad de uso para producir una API revisada.
38. 38. El método tal y como se describe en la reivindicación 37, el cual comprende además: repetir por lo menos la realización y el aseguramiento con respecto a la API revisada.
39. 39. El método tal y como se describe en la reivindicación 37, caracterizado porque el aseguramiento comprende: el aseguramiento de si la pluralidad de desarrolladores pueden utilizar la API sin problemas importantes con respecto al nivel deseado de posibilidad de uso para por lo menos un grupo de desarrolladores objetivo, caracterizado porque el nivel de posibilidad de uso deseado incluye consideraciones con respecto a (i) referencia frecuente y/o extensiva a la documentación API detallada por la pluralidad de los desarrolladores, (ii) una falla de una mayoría de la pluralidad de los desarrolladores para implementar el escenario, y (iii) si la pluralidad de desarrolladores toma un método que es significativamente diferente del que fue esperado por el diseñador de la API.
40. 40. El método tal y como se describe en la reivindicación 34, el cual comprende además: seleccionar una pluralidad de escenarios de núcleo para un área de característica; repetir la derivación, la realización, y la revisión por cada escenario de núcleo de la pluralidad de escenarios de núcleo.
41. 41. El método tal y como se describe en la reivindicación 40, caracterizado porque la derivación comprende: producir un componente agregado por cada escenario de núcleo de la pluralidad de escenarios de núcleo.
42. 42. El método tal y como se describe en la reivindicación 34, caracterizado porque la derivación comprende: producir un componente agregado que tiene una relación respectiva con cada tipo factorizado respectivo de una pluralidad de tipos factorizados.
43. 43. El método tal y como se describe en la reivindicación 42, caracterizado porque la producción comprende: producir el componente agregado para soportar el escenario para el cual está escrita por lo menos una muestra de código.
44. 44. El método tal y como se describe en la reivindicación 42, caracterizado porque la producción comprende: producir el componente agregado para que tenga una relación expuesta con por lo menos un tipo factorizado de la pluralidad de tipos factorizados, y una relación encapsulada con por lo menos otro tipo factorizado de la pluralidad de tipos factorizados.
45. 45. El método tal y como se describe en la reivindicación 44, caracterizado porque al menos otro tipo factorizado de la pluralidad de tipos factorizados que tiene la relación encapsulada con el componente agregado puede ser desconectado por el componente agregado para la interacción directa con otro tipo de componente.
46. 46. El método tal y como se describe en la reivindicación 42, caracterizado porque la pluralidad de tipos factorizados son diseñados utilizando una metodología orientada por el objeto.
47. 47. Un método para diseñar una interfase de programación de aplicación (API), comprendiendo el método: preparar una pluralidad de muestras de códigos para un escenario de núcleo, correspondiendo cada muestra de código respectiva de la pluralidad de muestras de códigos a un lenguaje de programación respectivo de una pluralidad de lenguajes de programación; derivar la API para el escenario de núcleo en respuesta a la pluralidad de muestras de código; realizar uno o más estudios de posibilidad de uso en la API utilizando una pluralidad de desarrolladores; y revisar la API basada en el uno o más estudios de posibilidad de uso.
48. 48. Un método para diseñar una interfase de programación de aplicación (API), comprendiendo el método: escribir por lo menos una muestra de código para un escenario; y derivar una API para el escenario en respuesta con al menos una muestra de código, incluyendo la API (i) un componente agregado que está adaptado para facilitar la implementación del escenario y (ii) una pluralidad de tipos factorizados que proporcionan una funcionalidad subyacente para el componente agregado, habilitando la API una progresión gradual del uso del componente agregado en las situaciones más simples al uso de una porción creciente de la pluralidad de tipos factorizados en situaciones crecientemente más complejas.
49. 49. Un método para diseñar una interfase de programación de aplicación (API) comprendiendo el método: derivar por lo menos un componente agregado para soportar por lo menos una muestra de código para al menos un escenario; determinar requerimientos adicionales con respecto a dicho al menos un escenario; decidir si los requerimientos adicionales pueden ser agregados a dicho al menos un componente sin agregar complejidad indebida a por lo menos un escenario; y si no es así, definir una pluralidad de tipos factorizados en respuesta a la decisión.
50. 50. El método tal y como se describe en la reivindicación 49, el cual comprende además: si es así, refinar dicho al menos un componente agregado para incorporar los requerimientos adicionales.
51. 51. El método tal y como se describe en la reivindicación 49, el cual comprende además: seleccionar una pluralidad de escenarios de núcleo para un área de características, incluyendo la pluralidad de escenarios de núcleo dicho al menos un escenario; escribir una pluralidad de muestras de código que muestran las líneas de código preferidas para la pluralidad de escenarios de núcleo, incluyendo la pluralidad de muestras de código dicha al menos una muestra de código; caracterizado porque la derivación comprende: derivar una pluralidad de componentes agregados, la cual incluye dicho al menos un componente agregado para soportar la pluralidad de muestras de código para la pluralidad de escenarios de núcleo.
52. 52. El método tal y como se describe en la reivindicación 49, caracterizado porque la derivación comprende: derivar dicho al menos un componente agregado con métodos, opciones por omisión (defaults) y abstracciones apropiadas para soportar dicha al menos una muestra de código para al menos un escenario.
53. 53. El método tai y como se describe en la reivindicación 49, el cual comprende además: refinar dicha al menos una muestra de código de acuerdo con al menos un componente agregado derivado; y evaluar la muestra de código refinada con respecto a la simplicidad; y repetir la derivación si la muestra refinada de dicha al menos una muestra de código falla en ser lo suficientemente simple en la evaluación.
54. 54. El método tal y como se describe en la reivindicación 49, caracterizado porque la determinación comprende: determinar requerimientos adicionales con respecto a dicho al menos un escenario, caracterizado porque los requerimientos adicionales incluyen escenarios adicionales, usos adicionales e interacciones adicionales con otros tipos de componente.
55. 55. El método tal y como se describe en la reivindicación 49, caracterizado porque la decisión comprende: considerar si la adición de los requerimientos adicionales a dicho al menos un componente agregado obstaculiza un patrón de creación-ajuste-invocación.
56. 56. El método tal y como se describe en la reivindicación 49, caracterizado porque la definición comprende: definir la pluralidad de tipos factorizados en respuesta a la decisión con la factorizacion ideal de un conjunto completo de funcionalidad.
57. 57. El método tal y como se describe en la reivindicación 49, caracterizado porque la definición comprende: definir la pluralidad de tipos factorizados en respuesta a la decisión utilizando una o más metodologías orientadas al objeto.
58. 58. El método tal y como se describe en la reivindicación 49, el cual comprende además: determinar si dicho al menos un componente agregado es para encapsular o exponer la funcionalidad de cada tipo factorizado de la pluralidad de tipos factorizados.
59. 59. El método tal y como se describe en la reivindicación 49, el cual comprende además: refinar la pluralidad de tipos factorizados para soportar dicho al menos un componente agregado y los requerimientos adicionales.