MX2011005927A - Almacenamiento y manejo en capas multiples de componentes de software. - Google Patents

Almacenamiento y manejo en capas multiples de componentes de software.

Info

Publication number
MX2011005927A
MX2011005927A MX2011005927A MX2011005927A MX2011005927A MX 2011005927 A MX2011005927 A MX 2011005927A MX 2011005927 A MX2011005927 A MX 2011005927A MX 2011005927 A MX2011005927 A MX 2011005927A MX 2011005927 A MX2011005927 A MX 2011005927A
Authority
MX
Mexico
Prior art keywords
solution
component
protected
components
solutions
Prior art date
Application number
MX2011005927A
Other languages
English (en)
Inventor
James Scott Head
Humberto Lezama Guadarrama
Elliot Stephenson Lewis
Christian J Betrisey
Xiadong La
Ajith K Gande
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of MX2011005927A publication Critical patent/MX2011005927A/es

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/36Software reuse

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

Arquitectura que emplea entidades de filas múltiples para almacenar componentes de solución al utilizar columnas, propiedades y lógica que rastrean componentes de solución al almacenar diferentes versiones (estados) del componente en múltiples filas. La modificación de componente incluye agregar y/o modificar múltiples filas, con lo cual facilita soportar operaciones tales como desinstalación al retener información de versiones del mismo componente. Un cuadro de componente de solución maestro rastrea todos los componentes de raíz de una solución, y lógica implementada en código atraviesa los nodos de raíz para descubrir todos los nodos hijo para rastrear eficientemente todos los componentes de una solución. Los estados lógicos de protegido y no protegido para solución permiten a los clientes desarrollar múltiples soluciones en el mismo sistema (organización), proteger una solución, y construir aplicaciones compuestas con múltiples soluciones involucradas (colocación en capas de soluciones). El almacenamiento de múltiples filas facilita el almacenamiento de definición de componente y solución asociada.

Description

ALMACENAMIENTO Y MANEJO EN CAPAS MULTIPLES DE COMPONENTES DE SOFTWARE ANTECEDENTES Los desarrolladores de aplicación están limitados por los mecanismos actualmente ofrecidos por arquitecturas de desarrollo. Los componentes se desarrollan en una forma ad hoc y los componentes se almacenan sin ningún diseño evidente en mente. Además, no existen medios para agrupar el componente junto. Consecuentemente, las operaciones tales como instalación, • desinstalación de soluciones no se soportan de forma natural. Se permite que los socios y los clientes de vendedor de software desarrollen herramientas comunes costosas para manejar sus aplicaciones (soluciones). Además, en donde un editor de software manejado para crear un instalador común, una vez desarrollado en el ambiente común no hay restricciones que prevengan que el cliente conteste la solución del editor. En otras palabras, el cliente puede exportar componentes de solución con lo cual representan una amenaza a los derechos de propiedad intelectual del editor de software. Adicionalmente, por razones de propiedad intelectual, una vez que se ha desarrollado una solución y distribuido el editor de software espera que la solución no se modifique o responda sin autorización.
BREVE DESCRIPCION DE LA INVENCION Lo siguiente presenta una breve descripción simplificada con el fin de proporcionar un entendimiento básico de algunas modalidades novedosas aquí descritas. Esta breve descripción no es una revisión extensiva, y no pretende identificar elementos clave/críticos ni delinear el alcance del mismo. Su único propósito es presentar algunos conceptos en una forma simplificada como un preludio a la descripción más detallada que se presenta a continuación.
La arquitectura descrita incluye una estructura completa y herramientas que soportan una noción de "soluciones", que es un grupo de componentes (por ejemplo, datos, procesos, cambios de interfase de usuario, etc.) incorporados en la parte superior de una plataforma de manejo (por ejemplo, relaciones de cliente), el grupo tratado como una unidad individual de software. La arquitectura emplea técnicas para almacenar, agrupar, manejar, proteger, y transportar componentes de solución. Cada técnica individual encuentra aplicabilidad a una gran variedad de plataformas y estructuras.
Por ejemplo, cuando se aplica a un ambiente de manejo de relaciones de cliente (CRM), la agrupación de los componentes en un grupo lógico es parte de la ecuación. Las acciones/transiciones tales como instalación/desinstalación/restauración, y actualización, por ejemplo, de los componentes así como transporte (empaquetado) se proporcionan. Adicionalmente, por razones de propiedad intelectual, una vez que se ha desarrollado y distribuido una solución el editor de software puede confiar que esa solución no se modificará o responderá sin autorización.
Para la realización de los fines anteriores y relacionados, se describen aquí ciertos aspectos ilustrativos en conexión con la siguiente descripción y los dibujos anexos. Estos aspectos son indicativos de las varias formas en las cuales se pueden practicar aquí los principios descritos y todos los equivalentes y aspectos de los mismos pretenden estar dentro del alcance del tema reclamado. Otras ventajas y características novedosas serán evidentes a partir de la siguiente descripción detallada cuando se considera en conjunto con los dibujos.
BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1 ilustra un sistema de desarrollo de solución de software implementado por computadora de acuerdo con la arquitectura descrita.
La Figura 2 ilustra un diagrama de flujo de alto nivel y componentes para desarrollar soluciones para una plataforma consciente de solución utilizando herramientas conscientes de solución y API.
La Figura 3 ilustra una arquitectura lógica ilustrativa de la plataforma consciente de solución.
La Figura 4 ilustra un diagrama de creación y empaquetado de soluciones.
La Figura 5 ilustra un Cuadro de filas múltiples ilustrativa para un componente de solución.
La Figura 6A ilustra un diagrama de estado ilustrativo para manejo de transición.
La Figura 6B ilustra la porción de componente del sistema del diagrama de estado.
La Figura 7 ilustra un método para desarrollar soluciones de software.
La Figura 8 ilustra un método para manejar una solución.
La Figura 9 ilustra un diagrama de bloques de un sistema de cómputo operable para desarrollar soluciones y correr soluciones en una plataforma de acuerdo con la arquitectura descrita.
La Figura 10 ilustra un diagrama de bloques esquemático de un ambiente de cómputo que facilita el desarrollo y operación de solución en una plataforma.
DESCRIPCION DETALLADA La arquitectura descrita emplea entidades de filas múltiples para almacenar componentes de solución utilizando columnas, propiedades y lógica que rastrea componentes de solución al almacenar diferentes versiones (estados) del componente en múltiples filas. La modificación de componente incluye agregar y/o modificar múltiples filas, con lo cual facilita soportar operaciones tal como desinstalación al retener información de versiones del mismo componente. Un cuadro de componente de solución maestra rastrea todos los componentes de raíz de una solución, y lógica ¡mplementada en código atraviesa los modos de raíz para descubrir todos los nodos hijo para rastrear eficientemente todos los componentes de una solución.
Los estados lógicos de protegido y no protegido para la solución permiten a los clientes desarrollar múltiples soluciones en el mismo sistema (organización), proteger una solución, y construir aplicaciones compuestas con múltiples soluciones involucradas (colocar en capas las soluciones). El almacenamiento de filas múltiples facilita el almacenamiento de la definición de componente y la solución asociada utilizando múltiples filas.
Ahora se hace referencia a los dibujos, en donde números de referencia similares se utilizan para hacer referencia a elementos similares por completo. En la siguiente descripción, para propósitos de explicación, se establecen numerosos detalles específicos con el fin de proporcionar un entendimiento completo de la misma. Sin embargo, puede ser evidente que pueden practicarse las modalidades novedosas sin estos detalles específicos. En otros casos, estructuras y dispositivos bien conocidos se muestran en forma de diagrama de bloque con el fin de facilitar una descripción de los mismos. La intención es cubrir todas las modificaciones, equivalentes, y alternativas que caen dentro del espíritu y alcance del tema reclamado.
La Figura 1 ilustra un sistema de desarrollo de solución de software implementado por computadora 100 de acuerdo con la arquitectura descrita. El sistema 100 puede incluir un ambiente de desarrollo 102 para desarrollar una solución de software 104 como un grupo lógico de componentes de software 106. Un componente de almacenamiento 108 del ambiente 102 almacena una asociación de una definición de componente con la solución 104 como entidades de múltiples filas 110. Un componente de manejo de transición 112 del ambiente 102 maneja cambios de comportamiento los componentes de software 106 basándose en definiciones de transición de estado.
El componente de almacenamiento 108 almacena el estado de los componentes 106 en múltiples filas y rastrea modificaciones de componente al agregar nuevas filas al modificar filas existentes. El componente de almacenamiento 108 también rastrea componentes de raíz de la solución 104 en un Cuadro de soluciones maestra. El componente de manejo de transición 112 emplea una máquina de estado y definiciones de transición de estado para manejar cuadros de solución y modifica una definición de transición en respuesta a un cambio del comportamiento.
El componente de manejo de transición 112 emplea modos lógicos protegidos y no protegidos para la solución 104. EL ambiente de desarrollo 102 facilita la colocación en capas de una solución no protegida en la parte superior de una solución protegida. El componente de manejo de transición 112 incluye una solución activa que rastrea cambios hechos a los objetos de sistema y cambios realizados en la parte superior de las soluciones protegidas. Además, se previene que la solución protegida se exporte. El ambiente de desarrollo 102 también puede incluir un componente de transporte 114 para exportar diferencias en modificaciones a la solución 104.
La Figura 2 ¡lustra un diagrama de flujo de alto nivel 200 y componentes para desarrollar soluciones para una plataforma consciente de solución 202 utilizando herramientas conscientes de solución y API (interfases de programa de aplicación) 204. Las herramientas consientes de solución y API 204 incluyen el ambiente de desarrollo 102 de la Figura 1, por ejemplo. Un proceso 206 facilitado por las herramientas y las API 204 incluye la creación de una solución no protegida (en 208). La solución no protegida puede accederse para crear y/o agregar componentes (en 210). Los componentes creados y/o agregados entonces pueden editarse (en 212). Después de la creación, adición, y/o edición de componente para la solución no protegida se ha completado, la solución no protegida puede empaquetarse (en 214), cuyo empaquetado convierte la solución no protegida en un paquete protegido (en 216). La solución protegida entonces puede importarse por uso por la plataforma consciente de solución 202 (por ejemplo, CRM) en el modo protegido. Alternativamente, después de que se ha completado la creación, adición, y/o edición de componente para la solución no protegida, la solución no protegida puede exportarse (en 220) en un paquete no protegido (en 222). La solución no protegida empaquetada entonces puede importarse para uso por la plataforma consciente de solución 202.
La plataforma 202 entonces almacena las soluciones y los componentes de solución como almacenamiento de múltiples filas 224 en las cuadros (por ejemplo, lenguaje de consulta estructurado de SQL) para búsqueda (por ejemplo, nodos hijo-padre), control de versión (por ejemplo, estado), etc. Adicionalmente, se maneja una solución y estado de componente en los numerosos cuadros al utilizar una máquina de estado y definiciones de transición de estado que definen transiciones de estado 226.
La Figura 3 ilustra una arquitectura lógica ilustrativa 300 de la plataforma consciente de solución 202. La arquitectura 300 proporciona una vista consistente de datos de solución y metadatos con el fin de que las entidades, servicios, y sistemas se comporten como se desee. Esto se realiza al permitir que en múltiples filas de un componente de solución existan en una base de datos de organización 302.
La arquitectura 300 proporciona un modelo de metadatos/datos consistente 304 que permite la instalación, mejora, y desinstalación de solución, así como desarrollo de solución, participación de metadatos a través de organizaciones, publicación de metadatos y, estados claros y concisos para metadatos y datos. Esto permite vistas eficientes del estado actual del sistema, recuperación rápida y fácil de todos los componentes de solución, transiciones bien definidas de un estado a otro, y limitaciones de base de datos apropiadas (por ejemplo, limitaciones clave externa) que se mantienen.
El modelo de metadatos es eficiente, fácil de acceder/actualizar, y relativamente de entender. Además, la arquitectura describe una entidad de solución, componente de solución, y una dependencia de solución como entidades de primera clase en el sistema de plataforma (por ejemplo, CRM).
Los metadatos/modelo de datos pueden incluir metadatos/datos de solución activos 306, metadatos/datos de solución de sistema 308 y metadatos/datos de solución protegidos 310. Una memoria caché de metadatos 312 está consciente de solución en cuanto a que facilita la participación a través de organizaciones de sistemas y soluciones protegidas, por ejemplo.
Existen cuatro tipos de solución distintos: solución de sistema, solución activa, solución protegida, y solución no protegida. A continuación esta una descripción de cada solución.
La solución de sistema (únicamente una solución de sistema) consiste de cuatro de los componentes fuera de la caja (OOB). Esto significa que todos los metadatos proporcionados en la instalación pertenecen a la solución de sistema. La solución de sistema no puede crearse, modificarse o eliminarse por el usuario final, sino que es un punto de referencia para identificar objetos OOB que pueden compartirse por otras soluciones que adaptan el sistema.
La solución activa (únicamente una solución activa) es similar a la solución de sistema en cuanto a que tampoco puede crearse, modificarse o eliminarse por el usuario final. Esto es debido a que la solución activa es una construcción que se utiliza para rastrear todas las adaptaciones hechas a los metadatos/datos de sistema 308 y metadatos/datos de solución protegidos 310. La solución activa está oculta del usuario final y se utiliza para administración de componentes de solución dentro de soluciones no protegidas. La solución activa simplifica la vista de datos y metadatos, Para asegurar que no existe un grupo diferente de metadatos/datos para cualquier solución no protegida dada. La solución activa también garantiza una interfase consistente a los metadatos y datos a través del sistema cuando se está desarrollando más de una solución a la vez, consistente con todas las soluciones que se desarrollan que se observan igual que el grupo de adaptaciones, así como exportar las mismas adaptaciones debido a que las soluciones que están trabajando en los mismos objetos incluso aún en diferentes soluciones no protegidas.
La solución protegida (puede ser múltiples soluciones protegidas) es una agrupación lógica de componentes que pueden instalarse, mejorarse y desinstalarse. La solución protegida no puede modificarse una vez instalada en una organización. Se debe observar que no es necesario ser capaz ver los componentes exactos de la solución como se define en la instalación. Es suficiente mostrar una lista de lo que está en la solución y el estado actual de esos datos/metadatos.
Existe al menos una solución no protegida (la solución predeterminada), y los usuarios tienen la capacidad de agregar más. Una solución no protegida es una agrupación lógica de componentes de solución activos. Cuando no se identificaron ninguna de las soluciones, cualquier adaptación cae en la solución predeterminada, que es la solución no protegida que se define por el sistema con el fin de atrapar todas las adaptaciones que no pertenecen explícitamente a cualquier otra solución no protegida.
Cuando se trabaja en un editor de solución, el usuario está trabajando dentro de una solución dada. Todas las adaptaciones hechas dentro del contexto se atribuirán a la solución no protegida operativa. Las soluciones no protegidas pueden crearse, actualizarse, eliminarse (remover todas las adaptaciones hechas en esa solución), exportarse e importarse. Las soluciones no protegidas, como soluciones protegidas, puede modificarse dentro de una organización.
Generalmente, la solución de sistema y las soluciones protegidas pueden compartirse a través de organizaciones dentro de la cache de metadatos 312. La solución de sistema y la solución protegida pueden mejorarse, lo que puede o no afectar el grupo operativo de metadatos/datos. La solución de sistema puede pensarse como la solución protegida de base. La solución activa puede pensarse como la solución no protegida de base. Las soluciones protegidas únicamente dependen de otras soluciones protegidas.
El objeto de proceso de negocio 314 (Objeto de Proceso de Negocio (Acceso de datos)) se interconecta a la memoria caché de metadatos 312, el modelo de metadatos/datos 304 e interactúa con los metadatos/datos de solución no protegidos 316. El objeto de proceso de negocio 314 puede también interconectarse a un modelo de manejo de solución y servicios 318 y una API de instalación/desinstalación/mejora de solución 320.
El modelo y servicios de manejo de solución 318 incluyen la estructura para soportar soluciones dentro de la plataforma consciente de soluciones. Esto incluye la capacidad de crear un editor, una descripción de solución, y asociar componentes a la solución. También pueden agregarse dependencias en otras soluciones. El modelo y los servicios de objeto de manejo de solución 318 pueden actuar independientemente de los cambios de metadatos y datos que soportan el desarrollo de solución y la instalación/desinstalación/mejora.
La Figura 4 ilustra un diagrama 400 de creación y empaquetado de soluciones. Para diferenciar entre una solución que está abierta o en un módulo no protegido (bajo desarrollo) y una solución que está cerrada (denotada por el cuadro con "L") o en un modo lógico protegido. Las soluciones no protegidas (402 y 404) pueden adaptarse al agregar componentes a la solución por cualquier adaptador con los privilegios apropiados. Los usuarios pueden "crear" únicamente soluciones en modo no protegido.
Todas las soluciones no protegidas observan la misma copia de objetos "compartidos". Si dos soluciones no protegidas (por ejemplo, 402 y 404) modifican el mismo objeto, entonces ambas soluciones ven los mismos datos. Esto se realiza al incluir una solución "activa" (los metadatos/datos de solución activa 306 de la Figura 3) que mantienen rastro de la modificación realizada en todos los objetos de sistema 406, así como cambios realizados en la parte superior de las soluciones protegidas (por ejemplo, solución protegida 408).
Las soluciones protegidas están cerradas, lo que significa que no pueden agregarse componentes (denotados por el círculo con "c") a la solución y los componentes no pueden eliminarse de la solución. En otra modalidad, también se previene la modificación de componentes.
Como se describió previamente, se produce una solución protegida al "empaquetar" una solución no protegida. Esto se ilustra al empaquetar la solución no protegida 404 en el paquete de solución protegido (PSP) 410. Adicionalmente, la solución no protegida 404 puede servir como la base para un paquete de solución no protegido (USP) 414. Un sistema puede obtener un paquete de solución protegido al importar el PSP 412. No se permite que se "exporte" una solución protegida. Esto atiende problemas de propiedad intelectual de editores de software. Otras implicaciones para soluciones protegidas se describen aquí a continuación con respecto a la colocación en capas.
Como se indica en el cuadro punteado, una solución no protegida (por ejemplo, solución no protegida 404) puede hacer referencia a componentes (círculo con "c") de soluciones protegidas (por ejemplo, solución protegida 408), y agregar cosas en la parte superior de sus componentes protegidos.
Las soluciones incluyen no únicamente metadatos (por ejemplo, definiciones de objeto, una definición de una entidad o una definición de un atributo), sino también otros objetos tal como filas de seguridad de registro, o información tal como configuraciones y muéstreos de correo electrónico, por ejemplo. De esa forma, se permite que una solución tenga tantos datos como metadatos como parte del grupo.
En cualquier punto en el tiempo dado, los usuarios pueden realizar adaptaciones desde dentro de una solución. Si no se selecciona solución especifica, se incorporará una solución predeterminada 416.
Dicho de otra forma, se presenta a los usuarios un concepto de "solución" unificado para soluciones protegidas y no protegidas. La solución es un grupo de componentes (por ejemplo, entidades, atributos, relaciones, flujos de trabajo, reportes) que proporcionan un grupo específico de funcionalidad de la parte superior de la plataforma de núcleo (por ejemplo con CRM). Adicionalmente, una solución contiene un grupo de atributos que identifican y configuran la solución.
Los clientes y vendedores de software usualmente crean dos tipos principales de soluciones: verticales (un mercado vertical completo, por ejemplo, manejo de recurso humano HRM) y horizontal (usualmente conocido como complementos). En cualquier punto en el tiempo dado, una solución puede estar en el estado no protegido o el estado protegido. El estado no protegido puede pensarse como "proyectos" de solución o soluciones que están bajo desarrollo. En cualquier momento que pueden hacerse las adaptaciones en el contexto de una solución, esa solución se considera no protegida. Se crean nuevas soluciones en este estado. Se crea el estado protegido después de que se ha empaquetado e instalado una solución no protegida. Ninguna de las modificaciones puede realizarse en el contexto de la solución protegida. Cualquiera de los cambios a los componentes que esa solución protegida ha declarado "adaptable" puede realizarse desde dentro de una solución no protegida.
En una modalidad alternativa, puede obtenerse una solución parcial que contiene únicamente componentes seleccionados. Por ejemplo, si el usuario decide exportar únicamente un subgrupo de componentes (por ejemplo, algunas pero no todas las entidades) la solución se considera parcial.
Un componente de solución es una parte constituyente de la solución que puede utilizarse para extender la plataforma para lograr funcionalidad específica. Algunos componentes comunes incluyen entidades, atributos, complementos, flujos de trabajo, formas, etc. Un componente no adaptable es un componente una vez protegido e instalado, no puede modificarse. Un ejemplo es un atributo "fusionado" en una entidad de cuenta. Un componente adaptable es un componente que una vez protegido e instalado, aún puede modificarse (pero no eliminarse) por cualquier solución. Un ejemplo es el "Nombre de Presentación" de la entidad de Cuenta.
El bloque delta 418 indica que únicamente las diferencias (delta) en modificaciones realizadas a un componente adaptable se pasan. Un ejemplo es una solución de vendedor de software que cambia el Nombre de Presentación de una Cuenta de "Cuenta" a "Escuela". Cuando se genera el paquete de solución de vendedor de software, la redefinición de la entidad se exporta junto con el resto de los componentes de solución de vendedor. El paquete de solución (por ejemplo, PSP 410) es un grupo de archivos que incluye la definición de solución junto con todos sus componentes. En una modalidad alternativa, puede proporcionarse un depósito de solución, que es un contenedor amplio de desarrollo de soluciones que pueden desplegarse en múltiples organizaciones.
Un editor de solución es un usuario o vendedor que desarrolla soluciones en la parte superior de la plataforma. En una modalidad, pueden implementarse eventos de solución, que son un grupo de eventos para soluciones (por ejemplo, instalación, desinstalación) para los cuales los vendedores pueden incluir controladores de vendedor (por ejemplo, complementos) con el fin implementar acciones comunes.
La solución predeterminada 416 es la solución de "atrapar todo" que contiene una referencia a todos los componentes no protegidos. Las soluciones OOB no son adaptables. Una solución activa es una versión de "bosquejo" o una versión "publicada" de cada objeto en el sistema, incluso cuando múltiples soluciones retienen una referencia al mismo objeto.
La Figura 5 ilustra un cuadro de filas múltiples ilustrativa 500 para un componente de solución. La cuadro 500 es capaz de almacenar y rastrear componentes de solución. Columnas, propiedades, y lógica se proporcionan para rastrear componentes de solución al almacenar diferentes versiones (estados) del componente en múltiples filas. En cualquier momento que se modifica un componente, pueden agregarse y/o modificarse filas. Esto facilita operaciones de soporte tal como "desinstalar" ya que se almacenan y rastrean diferentes "versiones" del mismo componente.
Adicionalmente, un cuadro de componente de solución maestra rastrea todos los componentes de "raíz" de una solución. El código de lógica puede atravesar los nodos de raíz y descubrir todos los nodos hijos. El efecto es el rastreo eficiente de todos los componentes de una solución. La cuadro 500 ilustra la noción de entidades de filas múltiples.
La ID de fila es la única clave primaria de esta fila. Esta columna asegura que existe un valor único que representa esta fila. La ID es la clave utilizada para acceder a este componente por otros componentes y servicios en el sistema. El Estado de componente representa el estado de la fila, ya sea que se publicó, eliminó, o no publicó por último en la fila actual. La ID de solución representa la solución con la que está relacionada este componente. La ID de solución puede ser la ID de solución de sistema, la ID de solución activa, o cualquier ID de solución protegida. El Tiempo de Sobre escritura se refiere al tiempo en el que se sobre-escribió esta fila por otra fila con la misma ID de componente. Si el valor es NULO, entonces esta fila está actualmente activa.
A continuación está un ejemplo de componente de múltiples filas que muestra el ciclo de vida de un componente de solución, partiendo desde que se instala, entonces se actualiza, instala una solución en la parte superior, tiene una eliminación de solución, y finalmente, tiene una de las soluciones instaladas desinstaladas, existen más casos que pueden ocurrir de lo que se describe aquí.
A continuación está un ejemplo de componente de filas múltiples que muestra el ciclo de vida de un componente de solución, partiendo desde que se instala, entonces se actualiza, instala una solución en la parte superior, tiene una eliminación de solución, y finalmente, tiene una de las soluciones instaladas desinstaladas. Existen más casos que pueden ocurrir de lo que se describe aquí.
Los pasos que correrán por el componente solución incluye 1) nueva instalación de una plataforma con componente '???', 2) adaptación de componente ' xx' desde la solución de sistema, 3) instalación de Solución Protegida A, que adapta 'xxx', 4) creación de Solución no Protegida B, que crea una adaptación no publicada de componente 'xxx', 5) instalación de Solución Protegida C, que elimina 'xxx', 6) desinstalación de la Solución Protegida, que incluye 6a) la desinstalación de la Solución A y 6b) la desinstalación de la Solución C. La solución completa muestra la inclusión de un cuadro de Componentes de solución y un Cuadro de solución.
En el paso 1), en la instalación inicial del sistema, todos los componentes tienen una fila individual, marcada como [Publicado, GUID. Sistema] y ningún Tiempo de Sobre escritura. <%COMPONENTE%> Cuadro de Base Se definen tres soluciones (Sistema, Activo, y Solución Predeterminado) en la instalación.
Cuadro de Información de Solución En instalación, el cuadro de Componente de Solución contiene únicamente las filas de solución de sistema.
Cuadro de Componente de Solución ID ID de Solución Tipo de Componente ID de Objeto *contiene todas las filas de solución de sistema* En el paso 2), la adaptación del componente 'xxx', los cuadros se muestran después de que un usuario ha adaptado el componente 'xxx' en ninguna solución particular. <%COMPONENTE%> Cuadro de Base Después de adaptar los datos, no se crearon soluciones debido a que la solución predeterminada se utiliza para todas las adaptaciones que no pertenecen a una solución específica.
Cuadro de Solución Una vez que se ha adaptado un componente, se agrega una referencia a ese componente al cuadro de Componente de Solución.
Cuadro de Componente de Solución En el paso 3), la instalación de una Solución Protegida A que adapta ' xx', cuando se instala una nueva solución, el antiguo Tiempo de Sobre-escritura de adaptación se actualiza y se utiliza la nueva fila de Solución como la fila de Producción. <%COMPONENTE%> Cuadro de Base Con la instalación de una nueva solución, se agrega una nueva fila al Cuadro de solución.
Cuadro de Solución Id de Solución Nombre Unico Modo de Solución GUID. Sistema Sistema Protegido GUID. Activo Activo No protegido GUID. Predeterminado Solución Predeterminada No protegido GUID. A Solución A Protegido La solución recientemente instalada tiene todas sus referencias de componente escritas al cuadro de Componente de Solución. Incluso si se instala una nueva solución y sobre-escribe un componente, la referencia para la solución predeterminada se mantiene para ese componente en el cuadro de Componente de Solución. Esto es para que pueda realizarse una restauración de desinstalación al estado correcto.
Cuadro de Componente de Solución En el paso 4), el componente 'xxx' está adaptado en la Solución No Protegida B, creando una solución adaptable, Solución B, realiza una adaptación no publicada de esta entidad. Las entradas de cuadro son como a continuación. Se debe observar que la ID de Solución no hace referencia a la Solución B explícitamente. <%COMPONENTE%> Cuadro de Base ID de fila ID Tipo de Componente ID de Solución Tiempo de Sobre-escritura 1111-1 xxx Publicado GUID. Sistema 1/1/2008 1111-2 XXX Publicado GUID. Activo 1/2/2008 1 11-3 XXX Publicado GUID.A NULO 1111-4 xxx No Publicado GUID. Activo NULO La solución B se agrega como una nueva fila al cuadro de Solución.
Cuadro de Solución Después que se creó la solución B, se agrega la referencia de componente adaptado no publicado al cuadro de Componente de Solución.
Cuadro de Componente de Solución En el paso 5), la instalación de la Solución Protegida C que elimina 'xxx', al instalar ahora la Solución C, que elimina este componente, las filas más antiguas tendrán el Tiempo de sobre-escritura actualizado. <%COMPONENTE%> Cuadro de Base La instalación de la Solución C agrega una solución adaptable a este cuadro.
Cuadro de Solución Incluso aunque se instaló la Solución C, la Solución B aún tiene una referencia a la entidad '???'. Se debe observar que si la Solución B se exportó en la Solución B de estado actual incluye una dependencia en la Solución C (es decir, la Solución C se ha instalado para que se instale la Solución B), y la entidad ' xx' no es nada diferente a la definición en la Solución C.
Cuadro de Componente de Solución En el paso 6a), ahora puede instalarse la Solución A sin afectar la definición de metadatos actual para esta entidad, pero removiendo las adaptaciones previas. <%COMPONENTE%> Cuadro de Base La desinstalación de Solución A elimina la fila del cuadro Solución.
Cuadro de Solución La desinstalación de la Solución A no tiene efecto en lo que contiene la Solución B.
Cuadro de Componente de Solución En el paso 6b, la desinstalación de la Solución C en lugar de la Solución A, si desinstala a su vez la Solución C, la restauración es a las adaptaciones realizadas por la Solución B en la entidad '???'. <%COMPONENTE%> Cuadro de Base La desinstalación de la solución C elimina la fila del Cuadro de Solución, justo como si se desinstalara la solución A.
Cuadro de Solución Sin importar qué solución se desinstala, la Solución B mantiene su referencia a la entidad '???'.
Cuadro de Componente de Solución ID ID de Solución Tipo de ID de Objeto Componente 2222-1 GUID. Predeterminado Entidad XXX 2222-2 GUID. A Entidad XXX 2222-3 GUID.B Entidad XXX El manejo de transición emplea una máquina de estado y muchas definiciones de transición de estado. Esto proporcionó flexibilidad y extensibilidad en cuanto a que cualquier cambio en comportamiento puede realizarse al modificar las definiciones de transición. Las siguientes figuras ilustran las transiciones principales.
La Figura 6A ilustra un diagrama de estado ilustrativo 600 para manejo de transición. El diagrama de estado 600 incluye transiciones de estado que se agruparon en tres secciones separadas: una sección de soluciones, sección de sistema, sección activa. Un estado de nada 602 representa que no hay nada que representa el componente y ningún componente que exista. El estado puede cambiar en tres formas desde el estado de nada 602: hacia abajo para volverse un componente de sistema (ilustrado en la Figura 6B) hacia arriba y a la derecha para volverse un componente de solución, o hacia arriba y hacia la izquierda para volver un componente activo. Los componentes de sistema se crean como sistemas por el vendedor de distribución. Los componentes de solución pueden protegerse para propósitos de propiedad intelectual. Se emplea un componente activo para adaptación por el cliente del sistema de cliente.
Estos estados se representan en filas del cuadro de base de filas múltiples. De esa forma, se representa una transición al estado de sistema como la fila de sistema. Una transición al estado de no publicación de sistema, el estado activo de sistema o el estado de solución de sistema se representa por la fila correspondiente después de que la fila.de sistema se insertó en la parte superior.
Un signo de + (más) indica que existen múltiples filas asociadas con el estado. Por ejemplo, un signo de + al lado del sistema (es decir, sistema +) representa que existen potencialmente múltiples estados (o filas) entre la fila de sistema y la fila de solución. Puede existir una fila de base (que es la fila de sistema) que se creó primero. Puede existir una fila de solución seguida por una fila activa y entonces finalmente otra fila de solución, por ejemplo. De esa forma, el signo de más ( + ) representa todos los estados entre la primera y última fila.
Moviéndose desde el estado de nada al estado de sistema y entonces al estado de solución del sistema más, el sistema es la fila de base y la solución en la fila superior, con cualquiera entre ellos. Se debe observar que no tiene que ver nada entre ellos, sino que pueden existir potencialmente múltiples filas.
Las transiciones llaman una a otra de las flechas. Por ejemplo, ir del estado del nada al estado del sistema, se hace una operación para crear que crea la fila de sistema. Entonces ir del estado de sistema a un estado de solución de sistema más puede hacerse al realizar una actualización en la fila de sistema mientras está en el contexto de una solución. Alternativamente, un adaptador de sistema puede crear un nuevo componente que puede observarse cómo moviéndose desde el estado de nada hacia el estado activo, y cualquier transición desde ahí puede ser posible basándose en las flechas definidas en el diagrama.
Más específicamente, comenzando en el estado de nada 602, transitar a un estado de solución + 604 puede hacerse a través de una operación para crear. La transición entonces puede ser a un estado activo de solución + 606 a través de una operación de actualizar (sol), y hacia atrás en el estado de solución + 604 a través de uno o más de una de las operaciones de eliminar (sol), eliminar (act) y/o actualizar (act). El estado activo de solución + 606 entonces procesa las operaciones de actualizar (sol) y actualizar (act). El procesamiento puede cambiar del estado de soluciones + 604 a un estado no publicado de solución + 608 a través de las operaciones de actualización (sol) o eliminación (sol). Cambiar del estado no publicado de solución + 608 al estado de solución + 604 puede ser utilizando una operación de eliminación (no publicado), actualizar acción (no publicado) o de publicar. El flujo desde el estado no publicado de soluciones + 608 al estado activo de solución + 606 puede ser por operaciones de eliminar (no publicado) o de publicar. El flujo desde el estado activo de solución + 606 puede ser desde cualquier operación de actualización (act) o eliminación (act). El flujo desde el estado activo de solución + 606 al estado de solución + 604 puede ser por operaciones de eliminación (sol), eliminación (act), o actualización (act). El estado de solución + 604 revisa procesos de actualización (sol) y eliminación (sol), el estado activo de solución + 606 revisa procesos de actualización (sol) y activo (act), y el estado no publicado de solución + 608 revisa procesos de actualización (no publicado) y actualización (sol). El flujo del estado de solución + 604 hacia atrás al estado de nada 602 es por una operación de eliminación (sol).
Al moverse hacia los componentes activos, el flujo puede ser desde el estado de nada 602 hacia un estado activo 610 a través de una operación para crear, y a un estado no publicado 612 a través de una operación para crear. El flujo desde el estado activo 610 hacia un estado no publicado activo 614 puede ser por las operaciones de eliminar (act) o actualizar (act). El flujo puede moverse desde el estado no publicado activo 614 hacia atrás hacia el estado de nada 602 al utilizar una operación para publicar. El flujo puede moverse desde el estado no publicado activo 614 hacia el estado activo 610 al utilizar operaciones para publicar o eliminar (no publicado). El flujo desde el estado activo 610 hacia el estado de nada 602 puede realizarse al utilizar una operación de eliminación (act). El flujo desde el estado no publicado 612 hacia el estado activo 610 puede ser al utilizar una operación de publicar. El flujo puede ser desde el estado no publicado 612 hacia atrás hacia el estado de nada 602 al utilizar una operación para eliminar (no publicado). El estado no publicado 602 se revisa operaciones de actualización (no publicado), el estado activo 6120 realiza operaciones para actualizar (act), y el estado no publicado activo 614 revisa operaciones de actualización (no publicado).
La Figura 6B ilustra la porción de componente de sistema del diagrama de estado 600. El flujo desde el estado de nada 602 de la Figura 6A a un estado de sistema 616 de la Figura 6B puede ser por una operación para crear. El flujo desde el estado de sistema 616 hacia un estado no publicado de sistema + 618 puede ser al utilizar operaciones para eliminar (sys) o actualizar (sys). El flujo hacia atrás desde el estado no publicado del sistema + 618 hacia el estado de sistema 616 puede ser por operaciones para publicar o eliminar (no publicado). El flujo desde el estado de sistema 616 hacia un estado activo del sistema + 620 puede ser a través de una operación de actualización (sys) y hacia el estado de sistema 616 al utilizar una operación para eliminar (act). El flujo desde el estado de sistema 616 hacia un estado de solución de sistema + 622 puede ser a través de una operación para una operación de actualización (sys) y hacia atrás hacia el estado de sistema 616 que utiliza una operación para eliminar (sol).
El flujo desde el estado no publicado de sistema + 618 hacia el estado activo de sistema + 620 puede hacerse al utilizar operaciones para publicar o eliminar (no publicado). El flujo bidireccional entre el estado activo de sistema + 620 y el estado de solución de sistema + 622 puede realizarse al utilizar operaciones de eliminación (act), eliminación (sol), actualización (act) o actualización (sol). El flujo bidireccional entre el estado de solución de sistema + 622 y el estado no publicado de sistema + 618 puede realizarse al utilizar operaciones de eliminación (sol), actualización (sol), actualización (no publicado), eliminación (no publicado), y publicación. El estado del sistema 616 revisa operaciones de actualización (sys), el estado no publicado de sistema + 618 revisa operaciones de actualización (no publicada), el estado activo de sistema + 620 revisa operaciones de actualización (act), el estado de solución de sistema + 622 realiza operaciones de actualización (sol) y eliminación (sol). El flujo desde el estado del sistema 616 hacia el estado de nada 602 de la Figura 6A puede ser a través de una operación de eliminación (sys).
Incluido aquí está un grupo de cuadros de flujo representativos de metodologías ilustrativas para realizar aspectos novedosos de la arquitectura descrita. Mientras, para propósitos de simplicidad de explicación, una o más metodologías aquí mostradas, por ejemplo, en la forma de un cuadro de flujo o diagrama de flujo, se muestran y describen con una serie de hechos, se deben entender y apreciar que las metodologías no están limitadas por el orden de actos, ya que algunos actos pueden, de acuerdo con esto, ocurrir en un orden diferente y/o concurrentemente con otros actos desde aquellos mostrados y descritos aquí. Por ejemplo, aquellos expertos en la técnica entenderán y apreciarán que una metodología puede representarse alternativamente como una serie de estados o eventos interrelacionados, tal como en un estado de diagrama. Además, no todos los actos ilustrados en una metodología pueden requerirse para una implementación novedosa.
La Figura 7 ilustra un método para desarrollar soluciones de software. En 700, los componentes de software están agrupados lógicamente como una solución. En 702, una asociación de una definición de componente con la solución se almacena como múltiples filas en un cuadro. En 704, el estado de la solución se rastrea por ai menos uno de agregar nuevas filas o modificar filas existentes en el cuadro. En 706, los cuadros de solución se manejan al utilizar una máquina de estado y definiciones de transición de estado. En 708, el acceso a los componentes se maneja de acuerdo con modos protegidos y no protegidos.
La Figura 8 ilustra un método para manejar una solución. En 800, se recibe una solución. En 802, la solución está diseñada como protegida o no protegida. En 804, basándose en la designación, el flujo puede ser a 806 para una solución no protegida. En 806, se permite la adición de componentes a la solución. En 808, las soluciones no protegidas se permiten para modificar objetos de sistema. En 810, la colocación en capas de la solución protegida en la parte superior de las soluciones protegidas se permite. En 812, las modificaciones a los objetos de sistema compartidos se rastrean al utilizar una solución activa. En 814, los cambios hechos en la parte superior de la solución protegida se rastrean al utilizar la solución activa.
Alternativamente, en 804, basándose en la designación, el flujo puede ser a 816 para una solución protegida. En 816, la visión de componentes a una solución protegida se previene. En 818, se previene la eliminación de componentes desde la solución protegida. En 820, se previenen las modificaciones a los componentes de la solución protegida. En 822, se previene la exportación de la solución protegida. En 824, se restringe la creación de la solución protegida para empaquetado de una solución no protegida. Se debe notar que las medidas preventivas para la solución protegida pueden hacerse selectivamente opcionales.
Como se utiliza en esta aplicación, los términos "componentes" y "sistema" pretenden hacer referencia a una entidad relacionada con computadora, ya sea hardware, una combinación de hardware y software, software, o software en ejecución. Por ejemplo, un componente puede ser, pero no está limitado a ser, un proceso que corre en un procesador, un procesador, una unidad de disco duro, múltiples unidades de almacenamiento (de medio de almacenamiento óptico y/o magnético), un objeto, un ejecutable, una secuencia de ejecución, un programa, y/o una computadora. A manera de ilustración, tanto una aplicación que corre en un servidor como el servidor puede ser un componente. Uno o más componentes pueden residir dentro de un proceso y/o secuencia de ejecución, y un componente puede estar localizado en una computadora y/o distribuido entre dos o más computadoras. La palabra "ilustrativo" puede utilizarse aquí para significar que sirven como ejemplo, caso, o ilustración. Cualquier aspecto o diseño aquí descrito como "ilustrativo" no necesariamente va a interpretarse como preferido o ventajoso en otros aspectos o diseños.
Haciendo referencia ahora a la Figura 9, se ilustra un diagrama de bloques de un sistema de cómputo 900 operable para desarrollar soluciones y correr soluciones en una plataforma de acuerdo con la arquitectura descrita. Con el fin de proporcionar contexto adicional para varios aspectos de la misma, la Figura 9 y la siguiente discusión pretenden proporcionar una breve descripción general de un sistema de cómputo adecuado 900 en el cual pueden ¡mplementarse los varios aspectos. Aunque la descripción anterior está en el contexto general de instrucciones ejecutables por computadora que pueden correr en una o más computadoras, aquellos expertos en la técnica reconocerán que también puede ¡mplementarse una modalidad novedosa en combinación con otros módulos de programa y/o con una combinación de hardware y software.
El sistema de cómputo 900 para implementar varios aspectos incluye la computadora 902 que tiene unidad(es) de procesamiento 904, una memoria de sistema 906, y un conductor común de sistema 908. La unidad(es) de procesamiento 904 puede ser cualquiera de varios procesadores comercialmente disponibles tal como procesador individual, procesador múltiple, unidades de núcleo individual y unidades de núcleo múltiple. Además, aquellos expertos en la técnica apreciarán que los métodos novedosos pueden practicarse con otras configuraciones de sistema de computadora, que incluyen minicomputadoras, macrocomputadoras, así como computadoras personales (por ejemplo, escritorio, portátiles, etc.), dispositivos de cómputo portátiles, electrónica a base de microprocesador o de consumidor programable, y similares, cada una de las cuales puede acoplarse operativamente a uno o más dispositivos asociados.
La memoria de sistema 906 puede incluir memoria volátil (VOL) 910 (por ejemplo, memoria de acceso aleatorio (RAM)) y memoria no volátil (NO-VOL) 912 (por ejemplo, ROM, EPROM, EEPROM, etc.). Un sistema de entrada/salida básico (BIOS) puede almacenarse en la memoria no volátil 912, e incluye las rutinas básicas que facilitan la comunicación de datos y señales entre componentes dentro de la computadora 902, tal como durante el arranque. La memoria volátil 910 también puede incluir una RAM de alta velocidad tal como RAM estática para guardar en memoria caché los datos.
EL conductor común de sistema 908 proporciona una interfase para componentes de sistema que incluye, pero no se limita a, el subsistema de memoria 906 a la unidad(es) de procesamiento 904. El conductor común de sistema 908 puede ser cualquiera de varios tipos de estructura de conductor común que además pueden interconectarse a un conductor común de memoria (con o sin un controlador de memoria), y un conductor común periférico (por ejemplo, PC!, PCIe, AGP, LPC, etc.), que utiliza cualquiera de una variedad de arquitecturas de conductor común comercialmente disponibles.
La computadora 902 además incluye subsistema(s) de almacenamiento 914 e interfase(s) de almacenamiento 916 para interconectar el subsistema(s) de almacenamiento 914 al conductor común de sistema 908 y otros componentes de computadora deseados. El subsistema(s) de almacenamiento 914 puede incluir uno o más de una unidad de disco duro (HDD), una unidad de disco flexible magnético (FDD), y/o unidad almacenamiento de disco óptico (por ejemplo, una unidad CD-ROM unidad DVD), por ejemplo. La interfase(s) de almacenamiento 916 puede incluir tecnologías de interfase tal como EIDE, ATA, SATA, e IEEE 1394, por ejemplo.
Uno o más programas y datos pueden almacenarse en el subsistema de memoria 906, un subsistema de memoria removible 918 (por ejemplo, tecnología de factor de forma de unidad flash), y/o el subsistema(s) de almacenamiento 914, que incluye un sistema operativo 920, uno o más programas de aplicación 922, otros módulos de programa 924, y datos de programa 926.
Uno o más programas de aplicación 922, otros módulos del programa 924, y datos de programa 926 pueden incluir el ambiente de desarrollo 102 de la Figura 1, el flujo y entidades en el diagrama 200, la arquitectura 300 de la Figura 3, el diagrama de soluciones 400 de la Figura 4, el cuadro 500 de entidades de múltiples filas de la Figura 5, la máquina de estado ejemplificada por el diagrama de estado 600 de la Figura 6A y 6B, y los métodos de las Figuras 7-8, por ejemplo.
Generalmente, los programas incluyen rutinas, métodos, estructuras de datos, otros componentes de software, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. Todo o porciones del sistema operativo 920, aplicaciones 922, módulos 924, y/o datos 926 también pueden guardarse en memoria caché en la memoria tal como la memoria volátil 910, por ejemplo. Se debe apreciar que la arquitectura descrita puede implementarse con varios sistemas operativos comercialmente disponibles o combinaciones de sistemas operativos (por ejemplo, como máquinas virtuales).
El subsistema(s) de almacenamiento 914 y los subsistemas de memoria (906 y 918) sirven como medios legibles por computadora para almacenamiento volátil y no volátil de datos, estructuras de datos, e instrucciones ejecutables por computadora, y así sucesivamente. Los medios legibles por computadora puede ser cualquier medio disponible que puede accederse por la computadora 902 e incluye medios volátiles y no volátiles, medios removibles y no removibles. Para la computadora 902, los medios se adaptan al almacenamiento de datos en cualquier formato digital adecuado. Se debe apreciar por aquellos expertos en la técnica que otros tipos de medios legibles por computadora pueden emplearse tal unidades zip, cinta magnética, tarjetas de memoria flash, cartuchos, y similares, para almacenar instrucciones ejecutables por computadora para realizar los métodos novedosos de la arquitectura descrita.
Un usuario puede interactuar con la computadora 902, programas, y datos utilizando dispositivos de entrada de usuario externos 928 tal como un teclado y un ratón. Otros dispositivos de entrada de usuario externos 928 pueden incluir un micrófono, un control remoto IR (infrarrojo), una palanca de mandos, en una almohadilla de juegos, sistemas de reconocimiento de cámara, una pluma de estilete, una pantalla táctil, sistemas de gesto (por ejemplo, movimiento de ojo, movimiento de cabeza, etc.), y/o similares. El usuario puede interactuar con la computadora 902, programas, y datos al utilizar dispositivos de entrada de usuario incorporados 930 tal como una almohadilla táctil, micrófono, teclado, etc., en donde la computadora 902 es una computadora portátil, por ejemplo. Estos y otros dispositivos de entrada están conectados a la unidad(es) de procesamiento 904 a través de interfase(s) de dispositivo de entrada/salida (l/O) 932 a través del conductor común de sistema 908, pero puede estar conectado por otras interfases tal como un puerto paralelo, puerto en serie IEEE 1394, un puerto de juegos, un puerto USB, una interfase IR, etc. La interfase(s) de dispositivo l/O 932 también facilita el uso de periféricos de salida 934 tales como impresoras, dispositivos de audio, dispositivos de cámara, y así sucesivamente, tal como una tarjeta de sonido y/o capacidad de procesamiento de audio incorporada.
Una o más interfase(s) gráfica 936 (también comúnmente denominada como una unidad de procesamiento de gráficos (CPU)) proporciona señales gráficas y de video entre la computadora 902 y presentación(es) externa 938 (por ejemplo, LCD, plasma) y/o presentaciones incorporadas 940 (por ejemplo, para computadora portátil). La interfase(s) de gráficos 936 también puede fabricarse como parte del tablero de sistema de computadora.
La computadora 902 puede operar en un ambiente (por ejemplo con IP) al utilizar conexiones lógicas a través de un subsistema de comunicaciones por cable/inalámbricas 942 a una o más redes y/u otras computadoras. Las otras computadoras pueden incluir estaciones de trabajo, servidores, enrutadores, computadoras personales, aparato de entretenimiento basado en microprocesador, un dispositivo par u otro modo de red común, y típicamente incluyen muchos o todos los elementos descritos con relación a la computadora 902. Las conexiones lógicas pueden incluir conectividad por cable/inalámbrica a una red de área local (LAN), una red de área ancha (WAN), punto común, y así sucesivamente. Los ambientes en red LAN y WAN comúnmente están ubicados en oficinas y compañías y facilitan las redes de computadora extendidas en empresa, tales como intranets, todas de las cuales pueden conectarse a una red de comunicaciones globales tal como Internet.
Cuando se utiliza en un ambiente en red la computadora 902 se conecta a la red a través de un subsistema de comunicación por cable/inalámbrica 942 (por ejemplo, un adaptador de interfase de red, subsistema de transductor incorporado, etc.) para comunicarse con redes por cable/inalámbricas, impresoras por cable/inalámbricas, dispositivos de entrada por cable/inalámbricos 944, y así sucesivamente. La computadora 902 puede incluir un módem o tiene otros medios para establecer comunicaciones en la red. En un ambiente en red, los programas y datos relativos a la computadora 902 pueden almacenarse en la memoria remota/dispositivo de almacenamiento, como está asociado con un sistema distribuido. Se apreciará que las conexiones de red mostradas son ilustrativas y pueden utilizarse otros medios para establecer un enlace de comunicaciones entre las computadoras.
La computadora 902 es operable para comunicarse con dispositivos por cable/inalámbricos o entidades utilizando las tecnologías de radio tal como la familia de estándares IEEE 802. xx, tales como dispositivos inalámbricos operativamente dispuestos en comunicación inalámbrica (por ejemplo, técnicas de modulación aérea IEEE 802.11) con, por ejemplo, una impresora, escáner, escritorio y/o computadora portátil, asistente digital personal (PDA), satélite de comunicaciones, cualquier pieza de equipo o ubicación asociada con etiqueta inalámbricamente detectable (por ejemplo, un quiosco, un puesto de periódicos, baños), y teléfono. Esto incluye al menos Wi-Fi (o Fidelidad Inalámbrica) para puntos comunes, WiMax, y tecnologías inalámbricas de Bluetooth™. De esa forma, las comunicaciones pueden ser una estructura predefinida como con una red convencional o simplemente una comunicación ad hoc entre al menos dos dispositivos. Las redes Wi-Fi utilizan tecnologías de radio llamadas IEEE 802.11 x (a, b, g, etc.) para proporcionar conectividad inalámbrica segura, confiable, rápida. Una red Wi-Fi puede utilizarse para conectar computadoras entre sí, a Internet, y a redes por cable (que utilizan medios y funciones relacionadas con IEEE 802.3).
Haciendo referencia ahora a la Figura 10, se ilustra un diagrama de bloques esquemático de un ambiente de cómputo 1000 que facilita el desarrollo de la solución y la operación en la plataforma. El ambiente 1000 incluye uno o más cliente(s) 1002. El cliente(s) 1002 puede ser hardware y/o software (por ejemplo, secuencias, procesos, dispositivos de cómputo). El cliente(s) 1002 puede alojar cookie(s) y/o información contextual asociada, por ejemplo.
El ambiente 1000 también incluye uno o más servidor(es) 1004. El servidor(es) 1004 también puede ser hardware y/o software (por ejemplo, secuencias, procesos, dispositivos de cómputo). Los servidores 1004 pueden alojar secuencias para realizar transformaciones al emplear la arquitectura, por ejemplo. Una comunicación posible entre un cliente 1002 y el servidor 1004 puede estar en la forma de un paquete de datos adaptado para transmitirse entre dos o más procesos de computadora. El paquete de datos puede incluir un cookie y/o información contextual asociada, por ejemplo. El ambiente 1000 incluye una estructura de comunicación 1006 (por ejemplo, una red de comunicación global tal como Internet) que puede emplearse para facilitar comunicaciones entre el cliente(s) 1002 y el servidor(es) 1004.
Las comunicaciones pueden facilitarse a través de una tecnología por cable (incluyendo fibra óptica) y/o inalámbrica. El cliente(s) 1002 están operativamente conectados a uno o más almacenamiento(s) de datos de cliente 1008 que pueden emplease para almacenar información local al cliente(s) 1002 (por ejemplo, cookie(s) y/o información contextual asociada). Similarmente, el servidor(es) 1004 están operativamente conectados a uno o más almacenamiento(s) de datos de servidor 1010 que pueden emplearse para almacenar información local a los servidores 1004.
Lo que se describió anteriormente incluye ejemplos de la arquitectura descrita. Por supuesto, no es posible describir toda combinación concebible de componentes y/o metodologías, pero un experto en la técnica puede reconocer que son posibles muchas combinaciones y cambios adicionales. Por consiguiente, la arquitectura novedosa pretende abarcar todas esas alteraciones, modificaciones y variaciones que caen dentro del espíritu y alcance de las reivindicaciones anexas. Además, a la extensión que el término "incluye" se utiliza en la descripción detallada a las reivindicaciones, tal término pretende ser inclusivo en una forma similar al término "que comprende" ya que "que comprende" se interpreta cuando se emplea como una palabra de transición en una reivindicación.

Claims (15)

REIVINDICACIONES
1. - Un sistema de desarrollo de solución de software implementado por computadora (100), que comprende: un ambiente de desarrollo (102) para desarrollar una solución de software como un grupo lógico de componentes de software; un componente de almacenamiento (108) del ambiente para almacenar una asociación de una definición de componente con la solución como entidades de filas múltiples; y un componente de manejo de transición (112) del ambiente para manejar cambios de comportamiento en los componentes de software basándose en definiciones de transición de estado.
2. - El sistema de acuerdo con la reivindicación 1, en donde el componente de almacenamiento almacena el estado de los componentes en múltiples filas y rastrea modificación de componente al agregar nuevas filas o al modificar filas existentes.
3. - El sistema de acuerdo con la reivindicación 1, en donde el componente de almacenamiento rastrea componentes de raíz de la solución en un cuadro de soluciones maestro.
4.- El sistema de acuerdo con la reivindicación 1, en donde el componente de manejo de transición emplea una máquina de estado y definiciones de transición de estado para manejar cuadros de solución y modifica una definición de transición en respuesta a un cambio en comportamiento.
5.- El sistema de acuerdo con la reivindicación 1, en donde el componente de manejo de transición emplea modos lógicos protegidos y no protegidos para la solución.
6. - El sistema de acuerdo con la reivindicación 1, en donde el ambiente de desarrollo facilita colocar en capas una solución no protegida en la parte superior de una solución protegida.
7. - El sistema de acuerdo con la reivindicación 6, en donde el componente de manejo de transición incluye una solución activa que rastrea cambios hechos a objetos de sistema y cambios realizados en la parte superior de soluciones protegidas.
8.- El sistema de acuerdo con la reivindicación 6, en donde se evita que la solución protegida se exporte.
9.- El sistema de acuerdo con la reivindicación 1, que además comprende un componente de transporte para exportar diferencias en modificaciones a una solución.
10.- Un método implementado por computadora para desarrollar soluciones de software, que comprende: agrupar lógicamente componentes de software como una solución (700); almacenar una asociación de una definición de componente con la solución como múltiples filas en un cuadro (702); rastrear el estado de la solución por al menos uno de agregar nuevas filas o modificar filas existentes en el cuadro (704); manejar cuadros de solución al utilizar una máquina de estado y definiciones de transición estado (706); y manejar acceso a los componentes de acuerdo con modos protegidos y no protegidos (708).
11.- El método de acuerdo con la reivindicación 10, que además comprende desarrollar la solución como protegida o no protegida .
12.- El método de acuerdo con la reivindicación 10, que además comprende colocar en capas soluciones protegidas y no protegidas en la parte superior de una plataforma de manejo de relación de cliente.
13. - El método de acuerdo con la reivindicación 10, que además comprende evitar la exportación de una solución protegida.
14. - El método de acuerdo con la reivindicación 10, que además comprende actualizar la solución a través de diferencias entre la solución y una actualización a la solución.
15. - El método de acuerdo con la reivindicación 10, que además comprende construir una solución no protegida en la parte superior de una solución protegida.
MX2011005927A 2008-12-10 2009-11-03 Almacenamiento y manejo en capas multiples de componentes de software. MX2011005927A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/331,451 US20100146478A1 (en) 2008-12-10 2008-12-10 Multi-layered storage and management of software components
PCT/US2009/063117 WO2010068348A2 (en) 2008-12-10 2009-11-03 Multi-layered storage and management of software components

Publications (1)

Publication Number Publication Date
MX2011005927A true MX2011005927A (es) 2011-06-20

Family

ID=42232500

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2011005927A MX2011005927A (es) 2008-12-10 2009-11-03 Almacenamiento y manejo en capas multiples de componentes de software.

Country Status (8)

Country Link
US (1) US20100146478A1 (es)
EP (1) EP2356606A2 (es)
CN (1) CN102246141A (es)
BR (1) BRPI0921239A2 (es)
IL (1) IL212298A0 (es)
MX (1) MX2011005927A (es)
RU (1) RU2011123642A (es)
WO (1) WO2010068348A2 (es)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7707255B2 (en) 2003-07-01 2010-04-27 Microsoft Corporation Automatic grouping of electronic mail
US7703036B2 (en) 2004-08-16 2010-04-20 Microsoft Corporation User interface for displaying selectable software functionality controls that are relevant to a selected object
US8255828B2 (en) 2004-08-16 2012-08-28 Microsoft Corporation Command user interface for displaying selectable software functionality controls
US8146016B2 (en) 2004-08-16 2012-03-27 Microsoft Corporation User interface for displaying a gallery of formatting options applicable to a selected object
US8239882B2 (en) 2005-08-30 2012-08-07 Microsoft Corporation Markup based extensibility for user interfaces
US8627222B2 (en) 2005-09-12 2014-01-07 Microsoft Corporation Expanded search and find user interface
US9727989B2 (en) 2006-06-01 2017-08-08 Microsoft Technology Licensing, Llc Modifying and formatting a chart using pictorially provided chart elements
US8484578B2 (en) 2007-06-29 2013-07-09 Microsoft Corporation Communication between a document editor in-space user interface and a document editor out-space user interface
US8762880B2 (en) 2007-06-29 2014-06-24 Microsoft Corporation Exposing non-authoring features through document status information in an out-space user interface
US9588781B2 (en) 2008-03-31 2017-03-07 Microsoft Technology Licensing, Llc Associating command surfaces with multiple active components
US9665850B2 (en) 2008-06-20 2017-05-30 Microsoft Technology Licensing, Llc Synchronized conversation-centric message list and message reading pane
US8799353B2 (en) 2009-03-30 2014-08-05 Josef Larsson Scope-based extensibility for control surfaces
US8560944B2 (en) * 2010-04-04 2013-10-15 Hewlett-Packard Development Company, L.P. Document modeling using concurrent hierarchical state machines
US8302014B2 (en) * 2010-06-11 2012-10-30 Microsoft Corporation Merging modifications to user interface components while preserving user customizations
US10110442B2 (en) * 2015-02-20 2018-10-23 Microsoft Technology Licensing, Llc Hierarchical data surfacing configurations with automatic updates
US11900084B2 (en) * 2022-04-29 2024-02-13 Grid.ai, Inc. Distributed application development platform

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7127702B2 (en) * 2000-10-27 2006-10-24 Kabushiki Kaisha Toshiba Application development system and method
US20030051026A1 (en) * 2001-01-19 2003-03-13 Carter Ernst B. Network surveillance and security system
US20030172368A1 (en) * 2001-12-26 2003-09-11 Elizabeth Alumbaugh System and method for autonomously generating heterogeneous data source interoperability bridges based on semantic modeling derived from self adapting ontology
US7818615B2 (en) * 2004-09-16 2010-10-19 Invensys Systems, Inc. Runtime failure management of redundantly deployed hosts of a supervisory process control data acquisition facility
US7620885B2 (en) * 2005-05-12 2009-11-17 International Business Machines Corporation Automatic generation of documentation for component-based computing solution
US8015546B2 (en) * 2007-08-03 2011-09-06 International Business Machines Corporation Rapidly assembling and deploying selected software solutions

Also Published As

Publication number Publication date
WO2010068348A2 (en) 2010-06-17
WO2010068348A3 (en) 2010-08-05
EP2356606A2 (en) 2011-08-17
RU2011123642A (ru) 2012-12-20
US20100146478A1 (en) 2010-06-10
CN102246141A (zh) 2011-11-16
IL212298A0 (en) 2011-06-30
BRPI0921239A2 (pt) 2018-10-23

Similar Documents

Publication Publication Date Title
MX2011005927A (es) Almacenamiento y manejo en capas multiples de componentes de software.
US8706772B2 (en) Strict tenant isolation in multi-tenant enabled systems
US10866791B2 (en) Transforming non-Apex code to Apex code
JP4812337B2 (ja) フォームタイプを使用してフォームを生成する方法および装置
US20190187969A1 (en) Method for virtualizing software applications
Cinar Android apps with Eclipse
US7281248B2 (en) Virtualized and realized user interface controls
US20070203956A1 (en) Metadata Customization Using Diffgrams
US7984115B2 (en) Extensible application platform
US7363578B2 (en) Method and apparatus for mapping a data model to a user interface model
US8707158B2 (en) Customizing a form in a model-based system
US8918709B2 (en) Object templates for data-driven applications
AU2005201433A1 (en) Method and apparatus for generating user interfaces based upon automation with full flexibility
US20090288069A1 (en) Dynamic Declarative Application Description
US20170351506A1 (en) Automating feature graduation
JP2019511796A (ja) ファイル管理方法及びこれを利用したファイル管理装置{method for managing files and apparatus using the same}
US9525673B1 (en) Content protection for extract, transform, load (ETL) scripts
US20090013306A1 (en) Optimized Computer Diagramming Method
KR101733833B1 (ko) 플랫폼 독립적 프리젠테이션 조직
Waldemarin et al. OBO to UML: Support for the development of conceptual models in the biomedical domain
US8527446B2 (en) Information integrity rules framework
US20160313990A1 (en) Extensibility bundles for a cloud and devices suite
KR101354110B1 (ko) 가상 디스크 드라이브 시스템 및 제공 방법
US8615730B2 (en) Modeled types-attributes, aliases and context-awareness
US11720333B2 (en) Extending application lifecycle management to user-created application platform components

Legal Events

Date Code Title Description
FA Abandonment or withdrawal