PT92065A

PT92065A - Sistema de gestao de espacos incorporando ambiente operativo de software

Info

Publication number: PT92065A
Application number: PT92065A
Authority: PT
Inventors: Alan Hetherington; Tim Addison
Original assignee: Nielsen A C Co
Priority date: 1988-10-21
Filing date: 1989-10-20
Publication date: 1990-04-30
Also published as: WO1990004827A1; AU4414889A; EP0377273A3; EP0377273A2; EP0378899A3; EP0378899A2; WO1990004828A1; AU4487889A

Description

FUNDAMENTO DO INVENTO

1. ÂMBITO DA INVENÇÃO

Esta invenção diz respeito a sistemas de software que operam a um nível mais elevado do que os sistemas operativos, mas a um nivel mais baixo do que os programas de aplicação. Mais específicamente, a invenção diz respeito a Ambientes de Operação nos quais uma variedade de programas de aplicações de estruturas de dados mutuamente diferentes possam ser desenvolvidos ou ser axecutados concorrentemente e nos quais uma variedade de dispositivos de dados em lotes possa ser empregue ou adicionada. A invenção reporta-se mais além a um sistema de gestão de espaço usando vantajosamen te as particularidades de um Ambiente Operativo. 2. 0 Conhecimento a que se reporta.

Os programas de computadores e os sistemas de software de vários níveis são conhecidos na arte.

Por exemplo, programas tais como programas de texto são programas de alto nível. Para além das suas capacidades de alto nivel, são capazes de executar algumas das funções de mais baixo nível geralmente associadas a sistemas de software longe do nivei das aplicações, tais como a utilização de marcas e fórmulas automáticamente executadas. Contudo, os programas de aplicação como estes são muito específicos em relação à aplicação e adaptações do programa de aplicação a dispositivos diferentes de entrada/saida ou dife- rentes computadores exigiam uma extensa revisão do código do programa de aplicação.

Os sistemas de desenvolvimento de sistemas de aplicações individuais tais como o DATAFLEX (da Data Access Corporation) permite a flexibilidade a um nível mais baixo do que o nível dos programas de aplicações. 0 DATAFLEX tem uma estrutura de dados que é flexível. Isto é, um "objecto" pode ter diferentes numeros e tipo de "campo" a descrevê-lo e os meios pelos quais diferentes objectos estão ligados podem também ser modificados. Contudo, o DATAFLEX não comporta a pluralidade de programas de aplicações desenvolvidos independentemente. Mais ainda, não há representação gráfica.

Outros sistemas de software, tais como o AUTOCAD (da Autodesk Corporation), estão específicamente concebidos para aplicação de Concepção Auxiliada por computador. Embora especificamente adequadas para apresentar uma estampagem visual de um objecto físico, a especificidade da sua aplicação impede a flexibilidade em lidas com estruturas de dados complexos ou dispositivos de entrada/saida.

Alguns sistemas conhecidos providenciam para a execução de vários programas de aplicação de uma forma não concorrente. Uma forma de execução de um programa não concorrente é referida como "alternância de programa". A alternância de programa envolve o carregamento alternado e execução alternada de vários programas em sequência. A alter-nancia de programas sofre o defeito de não existir presente qualquer ligação de dados entre dois programas por forma a que a comunicação de dados entre os dois programas é impedida. Por conseguinte custa tempo de desenvolvimento a coordenar as transparências de dados, bem como custará tempo de execução durante a operação. Também a interecção do utizador é geralmente diferente entre programas.

Uma outra forma de executar vários programas de aplicações é executá-los separadamente mas passar informação entre os dois programas por meio de um processo chamado Troca Dinâmica de dados (de Microsoft., Inc., como parte dos seu package de "Janelas"). A troca dinâmica de dados sofre do defeito que a pluralidade dos programas que comunicam dados de um para outro têm de ser conhecedores da estrutura de dados que o programa de aplicações receptores têm de aceitar. A falta de flexibilidade que pode ser inerente a uma estrutura de dados comum provoca que os custos de desenvolvimento de programas de aplicações adicionais cresçam parâ além dos custos que seriam de esperas se tivesse sido adoptada uma estrutura de dados comum. Mesmo se tivesse sido adoptada uma estrutura de dados comum antes de se escrever qualquer dos programas de aplicação, esta adopção de uma dada estrutura de dados conduziria a uma potencial inflaxibilidade entorpecente conforme se levantassem novos requesitos numa altura futura. É portanto desejável ter uma "plataforma" de software onde vários programas de aplicação tendo estruturas de dados mutuamente diferentes possam ser executados concorrentemente sem a necessidade de adaptar software de baixo nível às estruturas de dados diferentes.

Muitos programas de software conhecidos no meio envolvem a transferência de blocos de incorporação entre a memória da U.C.P. e os discos. 0 formato de incorporação nos discos variava com os programas de aplicações particulares. Por exemplo, ficheiros de texto, ficheiros de bases de dados, ou ficheiros de ASCII poderiam ser encontrados em um ou mais discos. A incorporação destes ficheiros diferentes tinham de ser acedida por software de transferência de dados em lotes. 6-

Infelizmente, se um novo dispositivo fosse acrescentado ao sistema, ou se um novo formato de dados num dispositivo físico existente fosse acrescentado, então o módulo de software incluindo as especificações de alto nível bem como as de baixo nivel para a transparência tinham de ser modificados.

Esta necessidade de modificar o software de transferência de dados em lotes torna os sistemas conhecidos ineficientes e resistentes à expansão. A inflexibilidade e o resistência à expansão é talvez provocada pelo facto que os escritores do código de alto nível trabalham nos mesmos produtos de software para os mesmos vendedores como o escritor de código de baixo nivel. Além disso, as aplicações que foram idealizados por estes escritores de software foram pensadas para serem limitadas no seu âmbito, por forma a que a habilidade para acrescentar fácilmente novos dispositivos externos ou formatos não para aí concebida. Infelizmente, se uma variedade de programas de aplicação fossem requeridos para aceder a uma crescente variedade de dispositivos e formatos, então as limitações inerentes nos sistemas conhecidos impediria a adição de melhoramentos às características existentes. E portanto desejável ter um esquema de transferência de dados em lotes no qual a adição de um novo dispositivo ou novos formatos externos de dados não exige a revisão substancial de segmentos substanciais do código. A "gestão de espaço" denota um campo onde (entre outras coisas) o posicionamento de objectos no espaço é por estratégia de acordo com critérios pró-deter-minados. Um exemplo específico de gestão de espaço é o posicionamento óptimo de uma quantidade óptima de itens de consumo escolhidos em prateleiras de um supermercado. A optimização da utilização de espaço um supermercado depende não só das di- -7-

mensões físicas do espaço no interior, dg supermercado, a planta do chão e elementos físicos fixos, mas também em factores que complicam tais como horários diferentes de entrega para vários produtos e diferentes pedidos para produtos diferentes.

Os sistemas de gestão de espaço em computador são conhecidos. Por exemplo, o SPACEMANII é um programa de aplicação de gestão de espaço da LOGISTICS DATA SYSTEMS; INC, de Irving Texas. 0 SPACEMANII tem sido licenciado a certas companhias sob condições de estrita confidencialida-de. É representativo de programas de aplicação conhecidos que estão descritos em código de computador (por exemplo a linguagem C de programação), e que não são imediatamente adaptados para clientela ou outras modificações. Geralmente, qualquer preparação para clientes do código de computador necessita das capacidades potencialmente caras de um programadores de computadores .

Estes custos adicionais e a inflexibilidade são indesejáveis, do ponto de vista do utilizador. É preferível ter conhecimentos individuais em tais áreas tais como o comércio a distribuição, o marketing, o retalho, o planeamento de chão e partes fixas e ser capaz de trabalhar no mesmo sistema de gestão de espaço por forma a que os peritos possam ser integrados. Ao trabalhar no mesmo sistema, sem ter de comunicar directamente um com os outros nas suas respectivas "linguagens" técnicas, podem contribuir aos seus respectivos peritos para optimizar o sistema de gestão de espaço no seu todo.

Os programas de aplicação conhecidos lidam geralmente com ficheiros de dados internos ao programa. Estes podem ser ficheiros de dados em ASCII legíveis separadamente para cada conjunro ser espampado no écran.

Contudo, tipicamente há muita informação comum entre os ficheiros de dados. Por exemplo, os produtos podem ser os mesmos.

Existe uma necessidade para uma única base de dados que possa armazenar toda a incorporação dos produtos, por exemplo, oriunda de ficheiros de dados separados. Uma base de dados única, torna-se mais fácil para modificar ou actualizar a importação sobre os produtos sem ter de modificar cada conjunto de dados separadamente, conforme era uma limitação nos sistemas conhecidos. Há uma necessidade para consultas, actualizar, intercalar e armazenamento de dados de diferentes lugares com regras de lógica diferentes e ser selectivo sobre que campos trabalhar.

No âmbito dos sistemas de gestão de espaço, é preferivel poder facilitar o desenvolvimento, a modificação e/ou a integração de novas características implementadas em módulos de software originados de uma variedade de indivíduos numa variedade de campos respectivos sem necessitar de habilidade de programação de computadores. É também desejável ser capaz de comercializar e de outra forma modificar as características dos sistemas de gestão de espaço sem ter de empregar indivíduos com as capacidades de um progamador de computadores.

RESUMO DA INVENÇÃO

De acordo com a presente invenção um Ambiente Operativo serve como uma plataforma de software na qual os programas de aplicação de estruturas de dados mútuamente diferentes possam ser desenvolvidos ou mutuamente executa- dos e independentemente dos dispositivos; e entrada/saída empregues .

Outro aspecto da presente invenção é a sua capacidade de apresentar flexivelmente uma variedade de estruturas de dados (e em particular preencher com dados essas estruturas) uma variedade de formatos em mapas e gráficos seleccionáveis. Preferivelmente, os dados em particulas e as estruturas de dados elas mesmas, podem ser modificadas pelo utilizador final interactivamente, utilizando um modo de apresentação quer em "mapa" ou em "modelo" (gráfico). A presente invenção permite programas de aplicações que possam ser desenvolvidos separadamente, de serem concossentemente executados, utilizando uma estrutura de dados comum que é formada por uma agregação das estruturas de dados dos programas de aplicações individuais. 0 processo de agregação compreende a obtenção de quaisquer com-flitos entre os campos dos diferentes programas de aplicações. Uma subsequente resolução dos conflitos forma estruturas de dados comuns por forma a permitir a oxecução de um agregado de programas de aplicação. A agregação pode ser executada quer na altura em que os programas de aplicações estão a ser carregadas ou na altura de correrem, ou numa combinação das duas alturas.

Este agregado de programas de aplicação executa-se mais eficazmente do que os métodos conhecidos no meio, os quais não possuem uma estrutura de dados comum cujos dados sejam concossentemente acessíveis por funções dos vários programas de aplicações individuais. A presente invenção tem em vista um largo alcance de técnicas de resolução de conflitos. A resolução dos conflitos permite a agregação de campos numa variedade de particularidades do encorponamento preferido. Por exemplo a estrutura de dados comum resultante da agregação de estruturas de dados individuais permite a· estampagem eficaz de mapas e gráficos agregados; menus; definição por teclado, modificação e função; lista de acontecimentos no tempo; macros; capacidades de dispositivos de entrada e de saída e o funcionamento de sistemas de dados em lotes.

Os conflitos entre estruturas (ou dos seus respectivos campos) poderão ser resolvidos numa grande variedade de maneiras, para cada uma dessas particularidades. Por exemplo, um conflito entre duas estruturas de dados pode ser resolvido escolhendo uma vez da outra ou modificando uma ligeiramente de acordo com as características da outra. Alternadamente, ambas as porções dos dados em conflito poderão sobreviver à resolução do conflito, com cada qual sendo modificada de acordo com as características uma da outra. Ainda, uma nova manifestação das estruturas de dados em conflito pode ser formada, a qual seja substancialmente diferente do caracter de qualquer uma das estruturas em conflito.

Naturalmente que, a presente invenção tem em vista a capacidade de alertar o conflito, suspender o processo de agregação e interagir com um utilizador por forma a percutir que seja executada numa escolha de meios para resolver o conflito.

Um outro aspecto da presente invenção tem sido ou em vista a chamada, por vários programas de aplicações, de funções dentro do Ambiente Operativo. A Ambiente Operativo de acordo com a presente invenção permite esta chamada de funções sem a alocação separada da memória para funções duplicadas o que é convencional ao meio.

Ainda um outro aspecto da presente invenção tem em vista um Sistema de Dados Em Lotes no qual uma variedade de Fontes de Dados em lotes ("BDS") em módulos de software de alto nivel possam ser definidas e modificadas independentemente dos módulos de software de mais baixo nível de -11- -11-

.........--Ί tipos de Dados era Lotes ("BDT") específicos de um dispositivo.

Qualquer dos módulos de software BDS de uma variedade alto nivel define quais os dados que são para ser transferidos e comunicam esta informação de filtragem de dados a qualquer módulo de software BDT de uma variedade de baixo nivel e específicos de um dispositivo. A flexibilidade da interligação de qualquer BDS a qualquer BDT permite uma larga variedade de transferências de dados de e para uma larga variedade de memórias externas. Assim à medida que são acrescentados novos dispositivos ao sistema, a criação de um único módulo BDT evita a necessidade de modificar o módulo de alto nível.

Ainda um outro aspecto da presente invenção tem em vista um sistema de software no qual o Sistema de dados em Lotes, o qual é capaz de abarcar uma variedade de transferências de dados, pode ele mesmo executar o carregamento, a agregação o processo de resolução de conflitos uma variedade de estruturas de dados mútuamente diferentes dos res-pectivos programas de aplicações para formar uma estrutura de dados agregada num programa de aplicações agregado.

Assim, vários aspectos da presente invenção podem ser caracterizados como se segue: A invenção contempla um método para executar concorrentemente um ou mais programas de aplicações, tendo os programas de aplicações uma variedade de estruturas de dados, compreendendo o método os passos de detec-ção da presença ou ausência de conflitos de campos entre campos definidos em estruturas de dados definidos em programas de aplicações; resolver os conflitos na eventualidade da sua presença ser detectada; agregar as estruturas de dados definidas nas várias programas de aplicações numa estrutura de dados comum, e executar um programa de aplicações agregado compreendendo a pluralidade de programas de aplicações, usando, o pro- grama de aplicações agregado, a estrutura de dados comum por forma a que os dados formados dentro da estrutura de dados comul seja concorrentemente acessível por funções do único ou mais programas de aplicações. A invenção contempla também um sistema para concorrentemente executar um ou mais programas de aplicações, tendo os programas de aplicações uma variedade de diferentes estruturas de dados, compreendendo o sistema um detector para detecção da presença ou ausência de conflitos de campos entre campos definidos nas estruturas de dados definidas nos programas de aplicações; Um solucionador para resolver os conflitos no caso da sua presença ser detectada; um agregador para agregar as estruturas de dados definidos nos vários programas de aplicações uma estrutura de dados comum e processados para executar um programa de aplicações agregado compreendendo a pluralidade de programas de aplicações, usando, o processo de aplicações agregado, a estrutura de dados comum por forma a que os dados formados dentro da estrutura de dados comum seja concorrentemente acessível por funções do úni co ou mais programas de aplicações. A invenção contempla ainda um método de carregamento de um ficheiro de estruturas para definição de objectos, campos e ligações, usando um módulo de software, BDS activado, de um conjunto flexivelmente interligado com um módulo de software BDT, activado, de um conjunto, específico de dispositivo para interacção com um tipo de armazenamento de dados escolhido, compreendendo o método os passos de inicializar um canal entre o módulo de software BDT activado e o tipo de armazenamento de dados escolhidos, executando-se a inicialização substancialmente dentro do módulo de software BDT activado; transferir o ficheiro de estruturas do tipo de armazenamento de dados escolhido e a memória da U.C.P. para a qual o controlo é passado iterativamente entre o módulo de software BDS activado e o módulo de software BDT, e, fechar o canal de dados entre o módulo de software BDT e o tipo de ar- mazenamento de dados. A invenção contempla ainda um sistema para o carragamento de um ficheiro de estruturas de um tipo de armazenamento de dados definindo objectos, campos e ligações, abrangendo o sistema um módulo activado de um conjunto de módulos de software BDS de alto nível flexivelmente interligado com um módulo activado de um conjunto de módulos de software BDT específicos de um dispositivo para interacção com um tipo de armazenamento de dados escolhidos; um módulo de inicialização localizado substancialmente dentro do módulo de software BDT activado para inicialização de um canal entre o software BDT activado e o tipo de armazenamento de dados es- » colhido; transferência de módulos para transparência do ficheiro de estruturas do tipo de armazenamento de dados escolhidos e a memória da U.C.P., na qual o controlo é passado eterativa-mente entre o módulo de software BDS activado e o módulo de software BDT activado e um módulo de fecho para fechar o canal de dados entre o módulo de software BDT e o tipo de armazenamento de dados. A invenção contempla ainda um sistema de transferência de blocos de informação para e de uma variedade de tipos de armazenamento de dados de estrutura variável, compreendendo o sistema um ou mais módulos de software BDS de alto nivel para especificar as características de trans ferência e um ou mais módulos de software BDT específicos de dispositivo, cada um flexivelmente interligado com qualquer dos módulos de software BDS para interacção dos respectivos tipos de armazenamento de dados. A invenção contempla ainda um método de transferir um bloco de dados usando um módulo de software BDS activado de um conjunto de alto nivel, flexivelmente interligado com um módulo activado de software BDT, de um conjunto, específico de um dispositivo para interacção com um tipo de armazenamento de dados escolhidos, compreendendo o método os passos de determinação do tipo de transferência; escolher qual de outros tipos de armazenamentos de dados é para -14-

ser envolvido na transferência; inicializàndo um canal entre o módulo de software BDT e o tipo de armazenamento escolhido, executando-se a inicialização substancialmente dentro do módulo de software activado; determinado, baseado nas especificações vindas do módulo de software, activado, de BDS, quais os objectos e os campos a transfesis; transferindo os dados entre os tipos de armazenamento escolhidos e a memória de U.C.P., na qual o controlo é passado iterativamente entre o módulo de software BDS activado e o módulo de software BDT activado; e fechando o canal de dados entre o módulo de software BDT e o tipo de armazenamento de dados.

Outro aspecto da presente invenção é providenciar um sistema de gestão de espaço melhorado.

De acordo com uma particularidade da presente invenção, o sistema de gestão de espaço compreende um programa de aplicação e o Ambiente Operativo. 0 programa de aplicações inclui ficheiros de apoio e ficheiros de funções. O Ambiente de operação inclui particularidades descritas algures neste resumo de invenção.

De acordo com a invenção, o sistema de gestão de espaço providencia a flexibilidade em termos de de adição de novas características, modificações das carac-terísticas existentes, e a tradução de funções conhecidas de outros sistemas de gestão de espaço. Esta flexibilidade permite substancial independência de desenvolvimento de uma variedade de módulos de software por indivíduos geralmente não familiarizados com o programação de computadores. 0 sistema de gestão de espaço da invenção permite a execução concorrente de outros programas de aplicações com o sistema de gestão de espaço.

BREVE DESCRIÇÃO DOS DESENHOS A seguinte descrição detalhada poderá ser melhor compreendida quando a lida em conjugação com os desenhos a acompanhar, na qual os numerais de referência se referem como elementos ao longo e no qual: A FIG. 1 mostra numa forma muito esquemática um diagrama de um programa de aplicações agregado formado pelo Ambiente de operação de acordo com a presente in-vensão em relação a outros sistemas de software de vários níveis com os dispositivos de entrada e de saída com os quais comunica. A FIG. 2 mostra uma estrutura de dados exemplar de acordo com o encorporamento preferido, incluindo objectos e as ligações entre eles. A FIG. 3 mostra numa forma muito esquemática um diagrama dos meios pelos quais as estruturas de dados de duas ou mais programas, aplicações estão agregadas uma estrutura agregada. A FIG. 4A mostra uma lista em mapa tipico das produzidas por programas de aplicações agregados pela encorporamento da presente invenção. A FIG. 4B mostra um mapa de todo--écran típico dos produzidos pelos programas de aplicações agregados pelo preferido encorporamento da presente invenção. A FIG. 4C mostra um mapa de definição de menus conforme pode ser capacitado pela presente invenção. -16- ι

A FIG. 4D. mostra um mapa em lista exemplar mostrando os dispositivos de saída disponíveis numa lista de dispositivos de saida. A FIG. 5. mostra um diagrama de fluxograma do processo da aplicação de carregamento que leva ao laço de análise numa sessão interactiva. A FIG. 5A é um fluxograma detalhado a estrutura de carregamento no processo mostrado na fig. 5 como bloco 512. A FIG. 5B é um fluxograma detalhando o processo de carregamento nos dispositivos de entrada e de saída mostrado na FIG. 5 como bloco 16. A FIG. 5C é um fluxograma detalhando o processo de carregamento do dispositivo de BDT mostrado na FIG. 5 como bloco 524. A FIG. 5E é um fluxograma que mostra o processo do encorporamento preferido de carregamento de menus, listas de teclados; macros e listas de acontecimentos mostrada na FIG. 5 como bloco 528. A FIG. 5F é um fluxograma detalhando o processo de carregamento BDS mostrado na FIG. 5 como bloco 532. A FIG. 3G mostra o laço principal da análise o qual é entrado após o processo de carregamento do programa de aplicações estar completo e começa uma sessão interactiva com o utilizador. A FIG. 6 mostra uma lista de toques em teclas típica das encontradas num programa de aplicações agregado de acordo com o encorporamento preferido. -17-

A FIG. 7 mostra a relação dos BDS e dos BDT do sistema de dados em lotes com respeito à memória da U.C.P. e tipos de armazenamento de dados externos. A FIG. 8 mostra uma listagem em mapa exemplar detalhando as fontes de dados num sistema para um programa de aplicações tipico. A FIG. 9 é um fluxograma de alto nível mostrando as trasparências de dados do sistema de dados em lotes de acordo com o encorporamento preferido. A FIG. 10 é um mapa indicando os valores das três guardas para cada de cinco tipos de transparências úteis em explicar as transferências de dados no sistema de transparências em lotes. A FIG. 11 mostra o sistema de transferência de dados em lotes em maior detalhe do que a fig. 9. A FIG. 11A é um fluxograma ilustrando a rotina "ESCRITA DE DADOS" indicada como bloco 1156 na FIG. 11, de acordo com o encorporamento preferido. A FIG. 11B é um fluxograma ilustrando a rotina "LEITURA DE DADOS" mostrada como bloco 1154 na fig. 11 de acordo com o encorporamento preferido. A FIG. 11B^ é um fluxograma ilustrando a rotina de limpeza de fim de registo ilustrada como bloco 11252 na fig. 11B (BDS READ) (LEITURA BDS) de acordo com o encorporamento preferido. A FIG. 12 é um mapa ilustrando de uma forma esquemática o arranjo da tabela de um BDS de um tipo vantajosamente empregue no Sistema de Dados em lotes de acordo -18-

com o encorporamento preferido. A FIG. 13 ilustra de uma forma muito esquemática um sistema de gestão de espaço preferido, 1302, compreendendo um programa de aplicações de gestão de espaço preferido e o Ambiente operativo da FIG. 1, junto com um programa de aplicações adicional 1324 que pode ser executado concorrentemente com o sistema de gestão de espaço preferido.

As FIG. 14A e 14B ilustram, respec-tivamente uma estrutura de dados mais complexa a uma relativamente simples para o sistema de gestão de espaço preferido de acordo com a presente invenção.

As FIG. 15A e 15B são fluxogramas ilustrando os passos lógicos executados pelo sistema de gestão de espaço preferido para a utilização de operações.

DESCRIÇÃO DETALHADA DO ENCORPORAMENTO PREFERIDO 1. Introdução 0 ensinamento da presente invenção será descrito com partículas referência a encorporamentos ac-tualmente preferidos. Estes ensinamentos são vantajosamente aplicados ao problema particular de um sistema de gestão de espaço para produtos de consumo em prateleiras de supermercado. Contudo deve-se entender que este encorporamento é apenas um exemplo dos muitos usos vantajosos dos ensinamentos inova-tivos aqui. -19-

Em geral, âs declarações feitas nesta especificação não delimitam necessáriamente qualquer das várias invenções reivindicadas. Mais ainda, algumas declarações podem-se aplicar a algumas particularidades inventivas, mas não a outras.

Tal como será reconhecido por aqueles hábeis no oficio, os conceitos inovativos descritos na presente aplicação podem ser modificados e variados sobre um largo âmbito de aplicações.

Assim, o âmbito da invenção não é limitado excepto pelas reivindicações em apêndice. 0 encorporamento preferido da presente invenção envolve um programa de computadores escrito em linguagem de programação 11C" originalmente desenvolvido nos Laboratórios da Bell. 0 Ambiente Operatório de acordo com o encorporamento preferido opera por de cima do sistema operativo MS-DOS. 0 Ambiente Operativo de acordo com o encorporamento preferido encontra utilidade especial em agregar a permitir a execução de programas de aplicação tais como aqueles na família, do SPACEMAN, de gestão de espaço, disponíveis na logístics Data Systems Inc. de Irving Texas. Esses programas de aplicação preferidos podem ser executados num IBM PS/2 Modelo 80 um computador com 70 megabytes de memória num dispositivo de disco. Contudo, em consonância com os ditames dos programas de aplicações particulares ou sistemas em computador pré-existentes, o ensino da presente invenção pode ser vantajosamente aplicado independentemente do ambiente e hard-ware ou de software.

Tal como é utilizado na especificação presente, o termo "estrutura" aplica-se a qualquer modelo de um sistema de dados hierárquico. Tal modelo inclui "objectos" ligados uns aos outros de uma forma hierárquica, com um ou mais "campos" associados com o objecto, por exemplo, -20-

para definir ou descrever o objecto.. Um exemplo particular e ilimitado de uma estrutura de dados encontra-se FIG 2. A FIG. 2 é descrita e referida por toda esta especificação como numa estrutura exemplar.

Tal como usado na actual especificação, o termo "ficheiro de estruturas" implica qualquer arranjo de dados, que define uma estrutura. Um exemplo sem limite de uso "ficheiro de estruturas". Um exemplo não limitativo de um ficheiro de estruturas (usado numa aplicação de gestão de espaço) pode ser encontrado no apendice A. É um aspecto da presente invenção que um ficheiro de estruturas possa ser tratado muito ao modo de um ficheiro de dados correspondente a qualquer outra "particularidade" de um programa de aplicação .

Um "registo" refere-se a uma actual ocorrência individual de um objecto. Por exemplo, quando um programa de aplicações tem um objecto "prateleira" pode haver um grande número de registos individuais que tenham o identificador "prateleira". Assim, de certas maneiras, os objectos, as ligações definindo as relações entre objectos e os campos definindo ou descrevendo os objectos, são em geral abstractos. Contudo os "registos" referem-se a ocorrências particulares de um objecto. Como descrito com especial referência para o "ficheiro de estruturas", os objectos, os comprimentos e os campos podem em certas alturas ser tratados como se fossem simplesmente outro ficheiro de dados contendo registos. De facto, tal tratamento unitário compreende uma das principais vantagens da presente invenção.

Conforme utilizado na presente especificação, o termo "características" refere-se a qualquer uma das capacidades dos programas de aplicação, "características" que procuram utilitários especiais em sistemas de gestão de espaço incluem visores, menus, teclados em listas, módulos de Sistemas de Dados em lotes, e campos baseados em fórmulas.

Geralmente, embora não necessária o exclusivamente, o termo "características" refere-se a um atributo de um programa de aplicações que é de menos preocupação central que o das "estruturas" .

Tal como usado nas presentes especificações, o termo "programa de aplicações" (ou ocasionalmente, "programa de aplicações individual") compreende um ou mais dos seguintes elementos: (1) uma definicação de uma "estrutura", conforme descrito acima: (2) 0 código objecto de funções capazes de ser executadas num aparato informático; e (3) ficheiros contendo um ou mais das seguintes "características"; visores, menus, listas de teclado, lista de acontecimentos, macros, lista de dispositivos de saída, lista de dispositivos de entrada, software de Sistemas de dados em lotes e campos baseados em partículas.

Tal como usado nas presentes especificações o termo "programa de aplicações agregado" refere-se às estruturas carregadas e agregadas e características de programas de aplicações individuais. Por exemplo, três estruturas mutuamente diferentes de três programas de aplicações individuais separadamente desenvolvidas podem ser carregadas e agregadas para formar uma "estrutura agregada" dentro do programa de aplicações agregado. Análogamente três sistemas de menus mutuamente diferentes de três programas de aplicações individuais são carregados e agregados num sistema de menu agregado dentro do programa de aplicações agregado. Claro, a interacção das estruturas, funções e características originárias de vários programas de aplicações individuais asseguram que o programa de aplicações agregado não seja uma mesa agregação de elementos dos vários programas de aplicações individuais.

Conforme utilizado nas presentes especificações, o termo "executando concorrentemente" aplica--se à execução intercalar de funções originadas de um ou mais programas de aplicações individuais. Uma vez agregado, o código objecto dos vários programas de aplicações individuais podem ser pensados como funções do programa de aplicações agr£ gado. Tanto quanto diz respeito ao utilizador, contudo, as funções dos vários programas de aplicações estão todas imediatamente disponíveis, tal que a execução sequencial de funções dos vários programas de aplicações aparecem ao utilizador como sendo execução concorrente devido à potencialmente complexa interacção de funções diferentes.

Ideia Geral Sobre as Características do Encorporamentos

Preferidos

Referindo a FIG. 1, o Ambiente Operativo de acordo com a presente invenção produz características de programa de aplicações agregado (de preferência na memória da U.C.P.) no bloco 102. O Ambiente Operativo pode ser considerado como sendo uma "plataforma" de software na qual os programas de aplicações 140, 142, 144, etc., possam ser desenvolvidos ou concossentemente executadas. 0 Ambiente Operativo por seu turno assenta sobre um sistema operativo padrão 104 que (talvez através de niveis de software não explicita-mente mostradas na fig. 1) operam até ao nivel do código máquina 106. A figura 1 é muito esquemática na sua natureza e tenciona a integrar o leito nos principais conceitos e características da invenção. Deve-se compreender que o âmbito da presente invenção não deve ser limitada pela -23- •tamm

\

descrição aqui contida, mas deve ser sobretudo definido só de acordo com as reivindicações a que se seguia. Por exemplo, deve-se entender que possa haver uma variação conceptual substancial de modo que quando o sistema operativo 104 termina e o Ambiente operativo ou o seu resultante programa de aplicações de agregado têm início. Contudo, um com habilidade na arte, sobre a leitura das reivindicações à luz da seguinte descrição detalhada dos encorporamentos preferidos, permitirá compreender e taxar o âmbito da presente invenção e reconheceu que as modificações possam ser feitas para dos encorporamentos particulares aqui descritos, mas que se mantém dentro do espírito e âmbito da invenção.

Os elementos indicados como elemento 110 a 138 estão indicadas em blocos em forma de diagrama. As ligações que são importantes à explicação do funcionamento do Ambiente Operativo estão indicadas por setas e aproximações gráficas na FIG. 1, mas os elementos de software dentro do Âmbito Operativo podem interagir em maneiras que, se não explicitamente escritas nesta descrição detalhada, seria compreendida por alguém hábil no meio com luz na descrição existente. "As funções de base" que assim seriam compreendidas estão indicadas na área 108. O encorporamento preferido da presente invenção usa programas de aplicações dirigidas para a estampagem interactiva e modificações em video de representações de objectos físicos um écran video. Mesmo mais particularmente, a invenção tende a ser usada num meio onde os produtos de consumo: estão dispostos e selectivamente manipuladas numa simulação de espaço físico de armazenamento em prateleiras num supermercado. Uma família de tais programas de simulação interactivos, SPACEMAN (GESTOR DE ESPAÇO) SPACE MANager) pode ser obtido da Logistics Data Systems, Inc., Irving Texas. É claro que se deve compreender que o âmbito e alcance da presente invenção se extende muito para além das utilizações aí usadas.

Por seguintes subsecções apresentam uma descrição do preferido encorporamento das várias ca-racterísticas de software 110-138 mostradas na porção de memória da U.C.P. indicada em 102 (FIG. 1). Numa secção posterior, a implementação do encorporamento preferido, será apresentada uma descrição de um processo preferido pelo qual o encorporamento preferido cumpre o carregamento, a agregação e a resolução de conflitos que resulta um programa de aplicações agregado a correr suavemente tal como a ilustrada na FIG. 1.

A. A FLEXIBILIDADE DAS ESTRUTURAS DE DADOS O Ambiente Operativo de acordo com a presente invenção providência a capacidade para trabalhar com programas de aplicação usando uma variedade de estruturas de dados.

Qualquer estrutura de dados hierárquica pode ser modelada usando o ambiente operativo preferido. Uma "Estrutura de dados hierárquica" define-se como uma estrutura de dados no qual os objectos estão ligados em arranjos um-a-um o um-a-vários.

Um conjunto de objectos e ligações características de um programa de aplicações conbido para simular, por exemplo, a colocação de produto de consumo em pra teleiras de armazenamento pode ser como se segue. Referindo a FIG. 2 um objecto "armazém" 202 pode ser ligado para baixo via "ligação dono" ao objecto "gondola" 204 o qual pode ser ligado via outro desligado ao objecto "prateleira" 206, o qual finalmente pode ser ligado ao objecto "parição do produto" 208. Ao mesmo tempo, o objecto "armazém" 202 pode ser ligado via uma ligação dono 212 ao objecto "produto" 210, o qual pode também estar ligado ao objecto "posição do produto" 208.

No encorporamento preferido, cada ligação 212 pode ligar um só objectos. Isto é, muitos "produtos" 210 podem ser ligados pela ligação 212 a um objecto "armazém" 202 . A estrutura de dados de programas de aplicações particulares é lida pelo Ambiente Operativo. A leitura de entrada de estruturas de dados baseada na aplicação particular permite uma flexibilidade significativa que não existem sistemas conhecidos. A aproximação convencional á formação convencional de estruturas de dados é a de adoptar mentalmente uma certa estrutura de dados e depois escrever o código de programa à volta dela. Este método conhecido sofre óbviamente o defeito de que, para adaptar uma nova estrutura de dados, o software de ser modificado e recompilado.

No encorporamento preferido, a estrutura de dados a qual o Ambiente Operativo pode usar encontrar-se em ficheiros de estruturas 312, 314, 316 e assim por diante (FIG. 3). Os ficheiros de estruturas contêm apenas informação revelante às estruturas actuais elas mesmas (armazéns, gondola, prateleira, etc.) a natureza dos atributos de cada objecto (armazenado em campos) e as ligações que relacionam os objectos.

Um ficheiro de estruturas é para se distinguir de um ficheiro de dados. Um ficheiro de dados contém "registos" de informação específica relativos a armazéns, gondolas ou prateleiras particulares etc. Os dados nos registos à vantajosamente arranjada para ser protamente acessível em formatos definidos pelo ficheiro de estruturas. De acordo com o encorporamento preferido, as estruturas de dados, elas mesmas (objectos campo, e ligações) tais como na FIG. 2 podem ser convenientemente modificadas pelos utilizadores, não

só os dados actuais dentro dos registos de ficheiro de dados.

As estruturas de dados formam a base de outras características da invenção, tais como mapas, modelos e menus. A agregação das estruturas de dados de programas de aplicações individuais podem ser descritas como se segue, com referência à FIG. 3.

No encorporamento preferido, a assumia-mos primeiro que o programa de aplicações 140 tem uma primeira estrutura de dados (compreendendo definições de ob-jectos, campos e ligações) 312, e que o programa de aplicações 142 tem uma segunda estrutura de dados (compreendendo definições de objecto, campos e ligações 314. A estrutura de dados agregada teria objectos, campos e ligações indicados em 310.

Durante a execução do programa que usa a estrutura de dados agregada (dentro do "programa de aplicações agregado" referido nesta especificação), sempre que as características do primeiro programa de aplicações são invocadas, as estruturas originadas em 312 são usadas. Análogamente, quando as características do segundo programa de aplicações é invocada, então as estruturas originadas em 314 são empregues. A invocação de 310, reflete os campos que são comuns aos dois programas de aplicações, demostra a capacidade para dois programas de aplicações independentes de aceder e modificar dados nessas localizações na estrutura de dados comum. A maneira particular na qual a formação da estrutura de dados comum 110 é conseguida no encorporamento preferido é descrito em detalhe na reacção de Fluxo de Programas, abaixo.

Uma vantagem da estrutura de dados comum (agregada) 110/310 é que os programas de aplicações que eram concebidos independentemente e desenvolvidas podem . -27-

ser intercalados e executados como um único "programa de aplicações agregado" utilizando a estrutura de dados comum. Ao ní-v vel abstracto das estruturas de dados (em oposição a caracte-rísticas como mapas, modelos e menus, as questões da detecção "de conflitos" dos campos das estruturas de dados de diferentes programas de aplicações é vantajosamente resolvido em muitas circunstâncias incluindo simplesmente quaisquer campos não duplicados das estruturas de dados dos programas de aplicações individuais na estrutura de dados agregada e inserindo um só campo de dado para campos de dados que estão duplicados entre os programas de aplicações individuais.

Testes mais sofisticados para resolver conflitos de campos incluem, por exemplo a resolução de um conflito de um campo inteiro e um campo com ponto flutuante escolhendo um campo de ponto flutuante no objecto agregado.

Para os propósitos desta descoberta, deve-se entender que a palavra "conflito" deve ser interpretada em sentido lato. A ideia de um conflito engloba não só a situação onde dois programas de aplicações diferentes pretendem que as operações de conflito sejam executadas. O termo "conflito" engloba também situações onde, por exemplo, um programa de aplicações assumiu que um segundo programa de aplicações providenciaria informação necessária relativa a estruturas de dados ou o seu conteúdo, mas segundo programa de aplicações assumiu que o primeiro providendiaria essa informação. A falta de definição de informação necessária por qualquer dos programas de aplicação ou uma especificação de uma estrutura ou alguns dados que é ambígua devido a falta de informação de outro programa de aplicações, deve-se compreender como sendo acompanhada pela palavra "conflito" conforme usado nesta especificação, aperas do facto que os programas de aplicações poderão não estar activamente a rivalizar pelo controle de . algum processo. A capacidade da agregação do encorporamento preferido está relacionada com outros vantagens. Estas outras vantagens incluem o facto de que os programas de aplicações -28-

possam ser carregados sem "ligar em" conforme é conhecido em sistemas conhecidos.

Em sistemas conhecidos, o processo para o desenvolvimento de programas envolve a compilação de vários módulos fonte em código para formar um conjunto de res-pectivos módulos em código objecto. Posteriormente, os vários módulos de código objecto têm de ser ligados a um programa executável. Em sistemas conhecidos, por isso, uma modificação num só módulo de código fonte necessitava não só a compilação desse módulo, mas também a ligação com todos os outros módulos de código objecto. Desde que, em qualquer programa grande, o número de módulos em código objecto pode ser de milhares, as desvantagens dos sistemas conhecidos são aparentes.

Em contraste, o Ambiente Operativo de acordo com o encorporamento preferido permite outros programas de aplicações de serem corridos sem "ligações" com todos os módulos objectos de Ambiente Operativo. Os módulos de código ponte dentro de um programa de aplicações devem ainda assim ser ligados em conjunto, mas o Ambiente Operativo combina automáticamente o programa de aplicações executável resultante para apresentar ao utilizador um só programa que incorpora as características do Ambiente Operativo e todos os programas de aplicações.

Cada programador de aplicações assim precisa de se preocupar com a ligação de módulos em código objecto no seu próprio programa de aplicações. 0 objecto executável em código do Ambiente Operativo 102, préviamente ligado sem qualquer intervenção da parte de um programador de aplicações, não é modificado. A ligação entre o código de aplicações executável e o código executável do Ambiente de Operação não é necessária. O evitar das ligações tem a vantagem que quem desenvolver a aplicação não tem de lidar em coisa alguma com os métodos e módulos objecto do Ambiente Operativo, tornando o seu próprio estágio de ligação mais rápido e mais indepen- -29- dente.

Igualmente, o utilizador pode adicionar ou remover programas de aplicações simplesmente adicionando ou removendo ficheiros executáveis; não tem de executar a tecnicamente e demorada tarefa de se ligar, o que é de especial vantagem quando o utilizador não está especialmente treinado. B. VISOR: Estampagem de Estruturas de dados A informação contida no ficheiro de estruturas providencia a base na qual a estrutura de dados geralmente e dados particulares respeitantes a objectos e os seus, campos, associados possam ser mostrados ao utilizador. Dois modos principais de estampagem são simplesmente implementados pelo encorporamento preferido da presente invenção, mapas e modelos.

Os modos de estampagem permitem não só a visão, mas também a modificação, das actuais dados e estruturas de dados. Isto é, os dados ou estruturas de dados podem ser trocadas interactivamente pelo uso de menus ou chaves de funções. Estes menus e funções em chaves descritas com mais detalhe abaixo. Nesta altura, contudo, a flexibilidade de modificar, bem como a estampagem de dados e de estruturas de dados numa variedade de formatos tanto textual como gráfica, deve ser tida em conta. A característica do VISOR do encorporamento preferido envolve a estampagem de informação a qual se pode originar de mais de um programa de aplicações -30-

sendo concorrentemente executados. Nas características de visão, quer sejam sob a forma de mapas ou modelos, a aparição de conflitos como tentativa de mais de um programa de aplicações encher os mesmos elementos do quadro. O Ambiente Operativo de acordo com a presente invenção permite que tais conflitos sejam resolvidos.

Os conflitos são resolvidos numa variedade de maneiras. Conforme foi expresso em termos mais abstractos no Resumo da Invenção, um dos programas de aplicações pode ter uma prioridade simples sobre o outro programa de aplicações, de tal modo que o primeiro programa de aplicações toma efectivamente o controlo desses elementos do quadro. Num formato em mapa, isto implica que o texto do primeiro programa de aplicações é estampado no écran, em vez do texto que de outra forma seria estampado no écran pelo segundo programa de aplicações. Há outras maneiras de resolver os conflitos de visão do que a solução ou um ou outro acima descritos. Por exemplo, num formato em mapa, se dois programas de aplicações desejassem posicionar uma porção de texto na mesma localização no écran, a um primeiro programa de aplicações pode-lhe ser dada prioridade quanto àquela localização particular, mas o texto do segundo programa de aplicações sim-plasmente seria redeslocado para uma porção diferente do écran (em vez de ser completamente escrito por cima). Igualmente, se algum texto de um dado programa de aplicações tivesse de ser removido devido a um conflito com texto de outro programa de aplicações, o texto redeslocado pode ser orientado de alguma maneira para indicar a sua redeslocação. Tal orientação pode tomar a forma de esteriscos, setas ou indicadores adequados.

Preferivelmente, os conflitos em modelos podem ser evitados em conjunto não atribuindo nomes idênticos a quaisqueE dois visores. Ainda, uma vez que os visores simplesmente representam objectos cujos conflitos deviam ter sido resolvidos na altura do carregamento, no encorpora-mento preferido, então não devem sobreviver conflitos para serem lidados pelo sistema de observação. No formato de modelo, a resolução de conflitos pode ser estampado por, por exemplo, posicionar o objecto físico de um programa de aplicações por forma a aparecer "em frente do", fisicamente, objecto do outro programa de aplicações. A presença do objecto físico escondido ou parcialmente escondido, do programa de aplicações de prioridade mais baixa pode provocar o aparecimento no écran por forma a indicar a sua presença. Por exemplo, uma linha ponteada, por fora, a sombrear e algo mais, podem alertar o utilizador para o facto que houve um conflito no que toca à localização particular envolvido.

Dependendo do programa de aplicações particular envolvido, podem respeitar provisões especiais quer dentro do Ambiente Operativo ou através de um "treino" do sistema interactivamente, para implementar funções lógicas de alto nível, dependendo da aplicação particular. Por exemplo, se um objecto físico conhecido como sendo transparente está em conflito com um objecto físico de um segundo programa de aplicações conhecido como sendo opaco, então o objecto físico transparente pode ser feito aparecer "em frente de" o objecto físico opaco. Esta técnica de alto nível de resolução dependente de dados e de aplicação permite a ambos os objec-tos físicos de serem estampados, enquanto minimiza o quanto um objecto físico priva o outro de visão pelo utilizador.

Esta capacidade de resolução do conflito que pode ser adaptada por um utilizador após todos os programas de aplicações e os Ambiente Operativos tenham sido escritos, indica a extensão à qual pode ser idealizado o Ambiente Operativo como um sistema de desenvolvimento de software de e para si mesmo. A capacidade de um utilizador "programas" efectivamente os meios de interacção e resolução de conflitos de diferentes programas de aplicações tem a vantagem que nenhum código dos programas de aplicação ou Ambiente -32-

Operativos precisam de ser modificados.

Dado que o utilizador pode modificar a estrutura de dados bem como manipular a localização e maneira na qual os objectos e os seus campos associados são mostrados, o utilizador tem efectivamente um controlo total sobre todo o processo de estampagem sem ter de recorrer a reais mudanças no software. Isto não é mais:que uma base na qual o ambiente operativo pode ser idealizado como sistema de desenvolvimento de software, e não meramente como um meio de ajudar à execução de software.

Deve ser relevado que os meios de modificar a estrutura de dados e os meios de modificar outras caracteristicas da presente invenção (tais como as punções do OBSERVADOR) podem ser todas executadas usando substancialmente a mesma família de comendos. Assim, a propriedade de amigo do utilizador do sistema é enaltecida, uma vez que o utilizador "aprenda a sentir" a uma variedade de sequência de modifjl cação enquanto aprende uma só sequência.

1. MAPAS

Um mapa é um texto estampado descrevendo um ou mais objectos com campos associados numa de uma variedade de formatos pré-determinados ou escolhidos pelo utilizador. -33-

a. LISTA DE MAPAS A Fig. 4A, entitulada PRODUTOS EM STOCK NO ARMAZÉM RA455, mostra uma estampagem de texto de seis objectos diferente (produtos de consumo) com informação asso -ciada com cada objecto (campo de dados tais como a etiqueta UPC, quantidade por caixa, custo por caixa, custo unitário, etc.).

Os conflitos que surgem numa lista em mapa, são mais prováveis de ocorrer quando a informação associada em cada objecto é diferente para programas de aplicação diferentes. Por exemplo, um programa de aplicações pode ter a etiqueta da UPC e o custo unitário, enquanto outro programa de aplicação pode ter encomendas e informação de movi -mentos. A informação em conflito toma a forma de colunas etiquetadas na lista do mapa. Na ausência de outros programas de aplicações, as colunas associadas com cada programa de aplica ção individual tenderia a ocupar a coluna mais à esquerda na lista do mapa. Contudo, o ambiente operativo de acordo com o encorporamento preferido resolve estes conflitos colocando as colunas originadas no programa de aplicações de mais alta prioridade nas colunas mais à esquerda e colocando as colunas originadas no programa de mais baixa prioridade nas colunas à direita delas.

Os campos que estão duplicados, tais como a identificação do produto na coluna mais à esquerda, podem ser impressas uma só vez em vez de duas. A medida que um utilizador ganha experiência com o sistema e aprende como arranjar as suas li£ tas em mapa mais eficientemente então podem ser implementadas funções lógicas de mais alto nível que são mais sofisticadas que a simples regar de que os programas de aplicação de mais alta prioridade sejam atribuídos às colunas mais à esquerda. -34-

A atribuição de campos de dados de vários programas de aplicação a colunas específicas pode ser escolhido conforme a dependência na prioridade dos campos, baseada na natureza dos cam -pos. Deste modo, o conteúdo de dados actual dos diferentes cam pos dos vários programas de aplicação pode determinar a ordem e o posicionamento das colunas na lista do mapa como é finalmente estampado.

De acordo com o encorporamento pre ferido, várias funções matemáticas tais como as que se podem encontrar em programas comencionais de processamentos de texto bem como funções ainda não concebidas ou implementadas, que es tão no âmbito da presente invenção. Por exemplo, a soma dos numeros numa dada coluna pode ser totalizada, e o total pode ser estampado no fundo da coluna. Tais funções matemáticas são descritas mais abaixo, na secção entitulada "Sistema de Fórmulas" . O utilizador pode escolher especificar dados diferentes no mapa podendo assim "penetrar" em cer tas áreas do mapa.

b. MAPA DE TODO-ÉCRAN A Fig. 4B, também entitulada PRODUTOS EM STOCK NO ARMAZÉM RA455, mostra um mapa de todo-écran exemplar. Um mapa de todo-écran, é um mapa no qual um só re -gisto é mostrado com os seus dados associados. Tal como na lista de mapa, acima descrita, o conteúdo e o formato da es -tampagem pode também ser modificada pelo utilizador de acordo com os princípios descritos, com especial referência para os menus, os teclados e acontecimentos no tempo.

Tal como foi descrito mais genéricamente acima, na secção intitulada VISOR. A estampagem de Estruturas e de Dados, a presente invenção providencia uma larga variedade de meios para resolver conflitos que se levantam quando dois programas de aplicação desejam posicionar rex-to na mesma zona de um mapa de estampagem de todo-écran. As técnicas resolução de conflitos de dados relativamente simples tais como escolher um texto e ignorar o outro ou localizando o texto de mais baixa prioridade num local diferente na estampagem de mapa de todo écran pode ser suplementado por técnicas de resolução de conflitos mais sofisticados. Técnicas de resolução de conflitos mais sofisticados podem incluir, por exemplo resolver o conflito entre um objecto azul de um programa de aplicações e um objecto amarelo de outro programa de aplicações a ser indicado num mapa de todo-écran como de cor verde.

Mais além, está dentro das capacidades do utilizador redefinir as localizações da estampagem dos diferentes campos, permitindo-lhe "passar por cima" de qualquer ou todas as localizações de outra forma impostas pelos programas de aplicações individuais. 2. Modelos

No encorporamento preferido, um modelo pode ser conceptualizado como uma estampagem gráfica de dados (quadro) estruturado, mais todas as estruturas de dados abaixo dele ligados. De frequência, a total hierarquia das estruturas de dados (ou os dados eles mesmos) a todos os níveis de um nivel presentemente escolhido, podem ser mostrados .

No decurso de uma secção interac-tiva, a estampagem de mais alto nível pode ser alterada pelo utilizador. Assim por exemplo, o utilizador de um sistema de gestão de espaço teria possibilidade de se "lançar" da estampagem de toda uma grande a uma prateleira na gondola, a um conjunto particular de produtos uma porção da prateleira.

Tal como acima descrito de uma forma mais genérica, na secção intitulada VISOR. A Estampagem de Estruturas e de Dados, um objecto físico pode ser gráficamente mostrado após simples ou mais legantes técnicas derreso-lução de conflito. Por exemplo, os objectos físicos que dois programas de aplicações de outra forma colocariam na mesma parte do écran pode ser resolvido relocalizando um dos objectos fazendo aparecer como se um objectos fosse em frente de segundo objecto fazendo a segundo objecto aparecer em "fastas-ma" atrás do segundo objecto e assim-.por diante. 0 mesmo objec to, mas com diferentes atributos (tal como a cor) pode ser resolvido, por exemplo, fazendo com que seja estampado um objecto em verde quando os dois programas de aplicações em conflito desejassem que o objecto aparecesse em azul e em amarelo respectivamente.

Os conflitos entre visores de modelos podem ser evitados, conforme estão no encorporamento preferido, nomeando os visores únicamente. C. Criação de MENU, Modificações e Funções

Os menus são uma das três principais maneiras na qual as funções e as macros podem ser invocadas de acordo com o encorporamento preferido. (Os outros dois meios preferidos são por Definição de teclas e listas de acontecimentos). A superfície, os menus de acordo com a presente invenção podem parecer-se individualmente a menus conhecidos no meio. Contudo, a enaltecida flexibilidade que caracteriza a presente invenção é evidenciada no facto que, no encorporamento preferido, os itens do menu podem-se referir a funções préprogramadas, macros (quer pró-programadas ou definidas pelo utilizador), ou referir-se a outros menus, sub-menus. A presente invenção, tem em vista que os menus possam ser do tipo horizontal ou vertical ou em árvore, ou qualquer combinação deles. Por exemplo, um primeiro menu pode ter cinco itens listados horizontalmente ao longo do topo do écran.

Se o utilizador escolher o quarto dos cinco itens listados horizontalmente, uma lista verticamente orientada de submenus de opção aparece por baixo do quarto item do menu. 0 utilizador pode clientalizar os seus próprios menus, em termos quer de conteúdo ou formato de estampagem. Por exemplo, o utilizador pode acrescentar ou retirar itens do menu, ou criar menus inteiros totalmente novos. Poderá definir as suas prórpias macros tornálas acessíveis de qualquer menu dado. A FIG. 4C mostra um método de sistema exemplar de definição de menus no qual vários menus diferentes conjuntamente com as suas características associadas são mostradas no formato de folha de texto. As características definidas ou mutáveis pelo utilizador tais como a posição (fixa ou a solar) a orientação vertical ou horizontal, a presença ou ausência de uma fronteira, a presença ou ausência de um título e cores de fundo são exemplos de itens que são modificáveis pelo utilizador no encorporamento preferido.

Podem surgir conflitos entre diferentes programas de aplicações quando, para um dado menu, cada programa de aplicação tem um conjunto diferente (talvez sobreposto) de opções. Talvez a maneira mais simples de resol- 38-

ver o conflito é permitir que um programa de aplicações de mais alta prioridade gira o posicionamento dos itens de menu mais elevados. 0 programa de aplicações de mais baixa prioridade provocaria que quaisquer entradas ainda não presentes no primeiro programa de aplicações a ser estampadas por baixo das entradas de um menu do primeiro programa de aplicações. É claro que o utilizador nem necessite de analizar os vários itens de menu originados em diferentes programas de aplicações individuais; a lista de opções de menus agregada aparece-lhe simplesmente. Tal como quando o utilizador escolhe uma das opções do menu para ser executada, ele não tem de se preocupar para qual dos programas de aplicações o controle tem de ser passado por forma a executar a selecção do menu. Porque os conflitos entre os programas de aplicações foram resolvidos prioritáriamente a qualquer selecção, a utilizador não experimente qualquer atraso devido aos programas de aplicações que são concorrentemente executados.

Isto é, de facto de que os programas de aplicações separadamente desenvolvidos estejam a ser concorrentemente executados não impere negativamente com a interação do utilizador, devido ã suave resolução de conflitos facilitada pelo Ambiente Operativo de acordo com a presente invenção. Conforme se verá abaixo, com a apreciação a ganhar--se com a compreensão das macros cuja execução é possibilitada pelo encorporamento preferido, a sequenciada e rápida execução de funções de diferentes programas de aplicações é facilitada sem os atrasos consumidores de tempo inerentes à alternância de programas e técnicas de troca dinâmica de dados conhecidos no meio. D. Definição de TECLAS, Modificação e· Funções.

Um segundo meio pelo qual as funções ou macros podem ser invocados pelo Ambiente Operativo é pela programação de teclas de função. A função de várias teclas específicas em teclado (ou por exemplo pressões de botão numa barra de comando do rato) pode ser definido e modificado pelo utilizador. Tal é o caso com muitas outras das características do Ambiente Operativo de acordo com o encorporamento preferido, a maneira em como as teclas de função podem ser definidas é substancialmente semelhante à maneira como outra caracterís-tica possa ser definida. A actual definição, ou modificação da definição, de uma tecla de função particular pode ser atingida, por exemplo, pela utilização do sistema de menus, ou talvez uma série de teclas de função pré-determinados ou escolhidas pelo utilizador.

As funções que são executadas em resposta a uma tecla de função pré-definida ou escolhida pelo utilizador incluem o seguinte. Um menu pode ser chamado, ou uma função de macros pode ser executada. Embora sejam comercialmente as teclas etiquetadas F1, F2, F3, e assim por diante, o que muitos dos utilizadores acharão útil em cenérios prá· ticos, deve-se compreender que qualquer conjunto de teclas no teclado pode ser modificado, mesmo indo ao ponto de cansar que um teclado inteiro seja novamente definido.

Podem surgir conflitos entre programas de aplicações diferentes que pretendem que uma toda tecla específica faça funções diferentes. No^encorporamento preferido, uma "lista de Teclas" é pesquisada de modo topo-a -fundo. Esta lista contém funções programadas ou funções que são para ser executadas na eventualidade do fecho de uma tecla. As funções que cada programa de aplicações individual associaria com uma tabela particular pode algumas vezes gerar conflito.

Quando existe um conflito, o Ambiente Operativo resolve o conflito, quer antecipadamente ou interactivamente. Tal é o caso em muitas outras técnicas de resolução de conflitos derigidos a outras características do encorporamento preferido, um programa de aplicações de mais alta prioridade pode tomar conta da função originada num programa de aplicações de mais baixa prioridade que de outra forma estaria associada com essa tecla. Alternativamente, uma tecla que o programa de aplicação de mais baixa prioridade desejasse que lhe estivesse associada com a função, poderia ser "deslocado" a uma tecla diferente. Neste caso, o utilizador pode ser alertado para a mudança nas teclas de função.

Num encorporamento preferido, uma estampagem de écran é providenciada por forma a que o utilizador possa visualizar cada tecla especialmente programada com a sua função acompanhante. É claro que, a lista finalmente resolvida de teclas de função agregada não tem que reflec-tir para o utilizador que as várias teclas de função não são originárias de um simples programa de aplicações. O utilizador não tem de que se preocupar com a origem das funções. É claro que a flexibilidade do Ambiente Operativo de acordo com o encorporamento preferido permite ao utilizador definir ou redefenir (sobrepondo-se ao programa de aplicações) teclas de funções particulares. E. Lista de acontecimentos

No encorporamento preferido, uma lista de acontecimentos é vantajosamente incluido como um terceiro meio pelo qual as funções ou os macros que são copiados para o Ambiente Operativo pode ser invocada. Brevemente, uma lista de acontecimentos preferidos pode ser uma lista de funções ou macros que estão para ser executadas numa data a altura, a uma dada altura após um acontecimento pré-determinado, ou repetidamente a intervalos fixos.

Esta lista de acontecimentos pode ser lido para o Ambiente Operativo por um programa de aplicações. Opcionalmente, a lista de acontecimentos pode ser modificada interactivamente pelo utilizador muito ao modo que as outras características do Ambiente Operativo podem ser modificadas. (exemplo, pelo uso de menus ou teclados ou sequências logo após). Vantajosamente, as funções ou macros especificadas na lista de acontecimentos podem ser executada um dado número de vezes, possivelmente a intervalos regulares ou irregulares pré-determinados. Uma aplicação exemplar desta caracte-rística seria carregar modificações em produtos de consumo de um computador principal a intervalos pré-determinados, assim sendo a base de dados de sistema é repetidamente actualizada.

Podem surgir conflitos quando dois programas de aplicações diferentes chamam para execução defun-ções respectivamente diferentes, ao mesmo tempo. Este conflito pode ser resolvido permitindo o programa de aplicação de mais alta prioridade de prevalecer. Isto é, a função que o programa de aplicações de mais alta prioridade deseja ser executada nessa altura particular será executada e as funções desejadas de serem executadas pelo programa de aplicações de mais baixa prioridade pode alternativamente ser retardada, iguosada ou modificada por uma técnica de lógica mais sofisticada que é baseada na natureza actual das duas funções. Um -42-

Λ

exemplo de uma técnica de resolução mais sofisticada, dependendo da função é a que uma função se pode "auto-desligar" (indicar que não está apropriada para ser invocada), tais como quando uma transferência tabelada foi temporáriamente incapacitada. F. Entrada de Macros

Tal como acima descrito, uma macro é uma sequência de comandos entrada pelo utilizador que é armazenada para posterior execução em sequência. Vantajosamente, as macros possibilitadas no encorporamento preferido formam uma extensa ordenação. Por exemplo, as etiquetas e os GO TO (desvios incondicionais), os proses SE (IK) as variáveis dinâmicas, laços de FOR e WHILE (enquanto) submacros (macros concatenados), estampagem automática de mensagens e os prontos estão disponíveis. No encorporamento referido, as macros, podem ser compiladas tais como são as fórmulas (abaixo descritas) para apesar de operar em campos de objectos. Apesar da sua flexibilidade e compreensividade, a linguagem das macros é concebida para facilidade de utilização seguindo substancial mente a mesma sintaxe que as fórmulas dos campos do objectos. Tal como outras características do Ambiente Operativo, a definição de macros pode-se proceder de uma maneira que seja independente do programa de aplicação particular em execução. A definição de macros, referenciação e execução pode ser conseguida como se segue, um encorporamento preferido. A nomenclatura das macros particulares dos vários programas de aplicações podem ser facili-

I

-43- tada incluindo no nome de cada função um identificador do pro grama de aplicação seguido de um período requerido por indicie de função que especifica unicamente a função particular sendo referenciada no programa de aplicações. Assim, 1.7 indicaria a sétima função no programa de aplicações número 1. e 4.3 indicaria a terceira função no programa de aplicações numero 4. Um número de função "de 0 pode ser usado vantajosamente para indicar macros no Ambiente Operativo. Assim 0,5 in dica a quinta função providenciada no próprio Ambiente Operativo .

Os conflitos entre macros de diferentes programas de aplicações pode ser resolvida uma varie dade de maneiras. Primeiro os macros podem só ter simplesmente uma guarda designando estarem incompletas e assim nunca serem compiladas. Alternadamente, um tal conflito pode ser resolvido ramificando a outras funções, talvez baseadas no conteúdo actual das funções em conflito. Idealmente os conflitos podem ser evitados por preparação avançada e planeamento da nomenclatura, para que desenvolvimentos separados de programas de aplicações diferentes não produzam macros que entrem em con flitos. A nomenclatura dos macros acima delineados evita tais conflitos de se levantarem em primeiro lugar.

G. LISTA DE DISPOSITIVOS DE SAÍDA

Uma lista de dispositivos de saída, de acordo com o encorporamento preferido da presente in -venção, compreende uma lista de dispositivos de saída (tais como impressoras, cartas e estampagens videoj' com especificações e capacidades associadas. A Fig. 4D, intitulada DISPOSITIVOS DE SAIDA DISPONÍVEIS, mostra onze dispositivos de saída exemplares com as características pertinenetes, incluindo a resolução horizontal e vertical e altura e largura da estampa^ gem. Outras caracteristicas relevantes podem incluir capacida des de escrever por cima, por especificação conforme uma série de dispositivos de acesso aleatório, disponibilidade de cores diferentes, especificações de como aceder aos dispositivos (rotinas de cumprimento, por exemplo) e assim por diante. A independência do código executa vel do Ambiente Operativo da modificação devido a modifica -ções nos dispositivos de saída é providenciada pela inclusão desta lista de dispositivos de saída. Qunado um novo dispositivo de saida é acrescentado ao sistema, só as especificações na lista de dispositivos de saida tem de ser modificada; o software do Ambiente Operativo pode ser propriamente executado sem mudanças ou subsequente compilação. Modificações na lista de dispositivos de saída podem-se efectuar independentemente dos programas de aplicação particulares cuja execução é anticipada. H. Lista de Dispositivos de Entrada

De acordo com o encorporamento preferido, a flexibilidade em acrescentar novos dispositivos de entrada tais como teclados, "manches", ou módulos de comunicação de dados de outros computadores, podem ser conseguidos substancialmente da mesma maneira como para conseguida para os dispositivos de saída, descritos acima com referência à lista do dispositivos de saída. Uma lista de dispositivos

I

-45- de entrada, adaptada para o propósito de permitir que se acomodem novos dispositivos de entrada pelo Ambiente Operativo, é tudo quanto necessita ser modificado. 0 código executável do ambiente operativo mantem-se imutado e a adição de um novo dispositivo de entrada pode ser conseguida independentemente dos programas de aplicações que estarão eventualmente para utilizar esses dispositivos de entrada. I. Sistemas de Dados em Lotes 0 sistema de dados em lotes, de acordo com o encorporamento preferido, permite a transferência de grandes quantidades de dados, geralmente não associados com o exemplo da entrada de dados interactiva especialmente preparada pelas listas de despositivos de entrada e de saida. 0 sistema de dados em lotes compreende dois componentes principais, um estando num nivel mais alto de isolamento do tipo de isolamento do tipo de dados particular sob consideração. A Fonte de Dados em lotes (BDS) é o software de mais alto nivel, lidando em especial com a definição do canal de dados. 0 Tipo de Dados em Lotes, por outro lado, é o conjunto de módulos de software específicos de um dispositivo que lidam menos selectivamente com os dados em cru, indo para e vindo dos dispositivos de dados em lotes.

I

-46-

Fontes de Dados em Lotes A Fonte de Dados em Lotes é essencialmente a configuração com a qual o utilizador pode interagir directamente. A BDS define essencialmente o canal de dados no sentido de lato, descrevendo que objectos e que campos são para ser transferidos. A BDS nunca necessita de ser modificada meramente para a adição de um novo tipo de software de dados em lotes. Esta imunidade da modificação assegura que o utilizador não necessita de aprender outro conjunto todo de instruções onde estruturas de dados sempre que é acrescentado novo software de dados aqueles com o qual o Ambiente Operativo deve comunicar.

Geralmente a BDS, encontra conflitos entre diferentes programas de aplicações quando as diferentes programas de aplicações desejam que diferentes objectos e campos estejam para ser transferidos. Os conflitos podem também surgir quando diferentes dados referido por dois programas de aplicações diferentes sejam desejáveis de ser colocados na mesma localização. 0 encorporamento preferido da presente invenção resolve esses conflitos tais como "conflitos" de duplicação de dados.

Uma vez que a BDS tem geralmente de transferir um conjunto escolhido de objectos e/ou campos, a resolução de conflitos envolve a decisão de que dados devem ser colocados numa dada localização ou aonde posicionar uma dada estrutura com relação a estruturas pré-existentes, no caso dos programas de aplicações sejam silenciosos ou estejam em desacordo. Também, estando os programas de aplicações em desacordo quanto ao destino dos mesmos dados ou relacionamento às estruturas de dados pré-existentes dos mesmos novas es-turas de dados, o Ambiente Operativo resolve estes conflitos. -47-

Λ

Ο encorporamento preferido da presente invenção contempla também um âmbito de opções para lidas com conflitos que reagem e surgem ao nivel do relacionamento das ligações dos diferentes objectos. (Com propósitos de compreensão, isto é para ser confrontado com os conflitos no posicionamento ou localização de dados de entrada, descritos acima com respeito aos sistemas de opções de lidas com duplicados). É concebível que, durante a trans ferência, a estrutura (em forma de registo de dados) que não tenha uma descrição hierárquica completa possa ser transferida. Por exemplo, uma prateleira pode ser desejável de transferir sem também transferir a gondola. Esta falta de definição de uma ligação particular pode ser resolvida por atribuições de "substitutos de pais" automáticamente, pelo mesmo até uma altura em que um estrutura de dados hierarquicamente mais completa esteja disponível. A estrutura hierárquica pode ser completada quer mais tarde na mesma transferência de dados, ou pode ser completada uma transferência de dados futura. No exemplo particular de uma prateleira para a qual não existe uma gondola presentemente, uma gondola substituta é criada automáticamente.

Um outro meio de resolver conflitos é através do uso de uma opção de CONTEXTO. A opção de contexto engloba presumir que os registos cuja estrutura de dados hierárquica está indefinida são localizados sob o objecto corrente (assumindo que isto tem significado). Por exemplo, se o utilizador está presentemente a examinar uma dada gondola num armazém, um registo de dados cujos relacionamentos na hierarquia seja ambígua é localizado (quer por tentativas ou permanentemente) na estrutura de dados correntes (tal como as gondolas).

Também uma opção de encomenda permite a ligação da ambigua ou não especificada estrutura para ser determinada pela estrutura de dados mais recentemente transferida a qual pode resolver a ambiguidade ou a falta de especificação. Por exemplo se uma prateleira é transferida com uma ligação a uma gondola a qual não é especialmente especificada, então essa ligação na hierarquia está determinada (permanentemente ou por tentativas) por essa gondola que tinha sido transferida mais recentemente. Recíprocamente, está no âmbito do presente invento que a ambiguidade de ligações possa ser resolvida por essas estruturas que seguem (em oposição ao precedente) a estrutura hierárquica presente por ordem de transferência. A questão de formato no qual os dados devem entrar num destino externo numa transferência dirigida para fora pode ser também resolvido pelo encorporamen-to preferido da presente invenção. Primeiro, se não existe destino pró-determinada do formato, o formato destino pode ser vantajosamente criado usando a mesma estrutura do que o formato fonte. Efectivamente isto causa uma duplicação tanto de formato como do conteúdo dos dados. A característica DESTINO permite que se use o formato de destino pré-determinado. Quando esta opção é seleccionada, os dados no formato de destino pré-determinado é modificado de acordo com as técnicas de resolução de conflito acima descritas, na descrição do sistema de tratamento de duplicados. Os dados eles só e, não o formato, podem ser modificados.

Alternadamente, o formato de destino pode ser especificado um ESCANTILHÃO que contém uma descrição do formato de destino. 0 formato destino do ficheiro de Escantilhão é relevante para as operações de armazenar.

Uma característica central de BDS é arbitrar quais objectos e que campos a serem transferidos. Que objectos serão transferidos é determinado pelo encorpora- mento preferido pelo qual os tipos de registos serão transferidos, dado que as estruturas de registo em ficheiros de dados comuncente conhecidos são especialmente apropriados para a estrutura de dados hiérarquica de objectos de acordo com o en-corporamento preferido da presente invenção. 2. Tipos de Dados em Lotes 0 tipo de Dados em Lotes (BDT) é essencialmente um direccionador de dados de baixo nível, em que os dados particulares de operação o utilizador numa experiência. Inerente com a BDT é uma lista das funções actuais que têm de ser executadas por forma a ligar com sucesso a vários dispositivos de dados em lotes, tais como bases de dados locais ao computador na qual o Ambiente Operativo está residente, ficheiros de programas de processamento de texto de di-ferenres padrões, ficheiros ASCII, ficheiros de bases de dados ou ficheiros de sistema.

Juntos a BDS e a BDT adaptam o Ambiente Operativo a muitos tipos de transferências de dados em lotes sem a necessidade de modificar o software do Ambiente Operativo (pelo menos ao nivel da BDS), forçando o utilizador a aprender um novo formato de dados ou um conjunto de comandos, ou a alterar quaisquer programas de aplicações particulares. 0 utilizador, pode simplesmente especificar quais objectos e campos são de seu interesse uma aplicação particular e o sistema de dados do Ambiente Operativo entrega a informação especificada enquanto o repara as particularidades da transferência. O utilizador pode ser, ou escolher não ver, tanto dos dados como ele pensa desejável, o software BDS mostrando no écran efectivamente a informação indesejável.

I

-50- X.

Por forma a acomodar um novo tipo de dado, dá o BDT (orientador de dados) tem de ser acrescentado (ou um BDT anterior ser modificado). J. Sistema de Fórmulas

Qualquer campo de qualquer objec-to no ficheiro de estruturas pode estar associado com uma fór mula que define os conteúdos desses campos de dados. A definição de campos de dados por fórmulas suplementa as capacidades do utilizador ou programador de aplicações a definir especialmente cada campo como um valor constante. Qualquer das funções que estão presentes em programas de processamento de texto convencionais po -dem ser incluídos no Ambiente Operativo. Um campo particular pode ser definido como uma combinação de elementos de lógica matemática ou estatística de outros campos que sejam pré-determinados ou constantes escolhidos do utilizador. Quando os campos não especificados com uma fórmula dada, os campos podem ser escolhidos quer de outros campos na mesma estrutura ou podem ser campos de outras estruturas.

Entradas como NA (indisponível) e ERR (erro) poderão ser especialmente entradas pelo utilizador ou geradas por operações do programa.

De acordo com o encorporamento preferido, se um campo particular é encontrado que tem uma entrada NA resultante de uma fórmula referenciando outros campos NA, o estado NA desse campo pode ser forçadamente modificado enquanto se mantém a consistência mútua dos dados.

I

Esta modificação é conseguida pelo que é chamado de uma capacidade de "pistagem de trás". Quando um valor particular en -tra em campo NA, a função de "pistagem de trás" funciona "para trás" por forma a suprir quaisquer campos NA dos quais o campo forçado dependesse. Os campos NA anteriores são substituídos com o valor que seja necessário para provocar ao cam po "forçado" de assumir o primeiro valor.

Esta característica de pistagem para trás permite ao utilizador a capacidade, por exemplo, de determinar que condições iniciais possam ser requeridas p£ ra atingir certos resultados. Por exemplo, a preçagem de um produto de consumo num grupo de produtos de consumo pode ser determinado para uma margem de lucro dada, assumindo que o preço dos restantes produtos foi já estabelecida. A margem de lucro NA, seria simplesmente forçada para o valor desejado e o produto de consumo Na seria automáticamente acertado pelo procedimento automático de pistagem para trás. K. Referência a Funções de e para fora do Ambiente Operativo

De acordo com o preferido encorpes ramento, o Ambiente Operativo pode eficazmente invocar funções que estão presentes em programas de aplicações. Uma referên -cia à função dos programas de aplicações compreende vantajosa mente uma referência ao programa de aplicações ele mesmo (por nome ou por indice, por exemplo) bem como sendo uma função de indexação nessa aplicação particular. 0 Ambiente Operativo pode invocar as funções de um ou mais programas de aplicações que estão a ser executadas concorrentemente, conforme permi -tido pelo sistema do Ambienet Operativo.

Uma vantagem dessa capacidade de invocar funções de mais de um programa de aplicações é estar dentro da velocidade realçada de execução, tanto quanto a capacidade óbvia a necessidade de carregar e ligar programas de aplicação no meio da secção do utizador. Esta flexibilidade é demonstrada pela capacidade de escrever, compilar e ligar programas de aplicações adicionais sem codificar o Ambiente Operativo. A flexibilidade do encorporamento preferido do Ambiente Operativo é demonstrada mais além pela capacidade de chamar funções de programas de aplicações que por seu lado chamam funções utilitárias que são inerentes ao Ambiente Operativo ele mesmo. A capacidade de voltar a ligar às Funções do Ambiente Operativo é conseguida pelo uso de uma biblioteca (uma lista de funções que pode ser referenciada a uma "tabua de gancho"). A tabela de ganchos compreende uma série de endereços no Código do Ambiente Operativo para transferir o controlo quando o programa de aplicações deseja executar a função.

Tanto quanto não seja requerida uma compilação separada devido às inerentes interligabilidades o utilizador não experiente não experimenta qualquer atraso durante uma sessão de terminal que de outra forma seria causada por um procedimento de ligação menos eficiente. Também a desnecessária duplicação de códigos é evitada. Várias características particularmente importantes do encorporamento preferido de acordo com a presente invenção estão descritas abaixo.

Uma primeira característica importante é o processo de carregamento e a agregação, incluindo a resolução de quaisquer conflitos, com especial aplicação ao carregamento e à agregação de estruturas de dados de diferentes programas de aplicações.

Uma segunda característica importante refere-se ao sistema de Dados em Lotes, compreendendo BDSs e BDTs (processo de Fontes de Dados em Lotes e Tipos de Dados em Lotes) que flexivelmente interagem.

Outra característica importante de acordo com o encorporamento preferido da presente invenção é o uso de uma certa porção do Sistema de Dados em Lotes ele mesmo no processo de carregamento e agregação. III. Implementação do Encorporamento preferido A. Carregamento e Agregação de Programas de Aplicação

Na FIG. 5 está ilustrado um flu-xograma do processo de carregamento e agregação 500 conduzindo ao laço de análise numa secção interactiva.

Após a inicialização, é compilada uma lista de todos os programas de aplicação contendo funções e estruturas a serem carregadas e agregadas num programa de aplicações agregado. Esta função é geralmente indicada como bloco 504 na FIG. 5. A criação da lista dos programas de aplicação está dentro de capacidade de algúem hábil na matéria .

Em seguida, tal como indicado no bloco 508, o encorporamento preferido carrega uma "imagem" de cada programa de aplicações. Um icom pode ser uma estampagem representativa do programa de aplicações. Vantajosamente, po-

de também possuir uma expressão estilística, talvez relacionada com a função e o propósito de programa de aplicações particular .

Todas as imagens podem então ser estampadas, por forma a confirmar ao utilizador que todos os programas de aplicações desejados estão de facto a ser carregados. 0 Bloco 512 indica o processo de carregamento da estrutura, e será descrita abaixo com maior detalhe, com sujeito a FIG. 5A. Neste bloco 512, as estruturas (Uma das quais se pode assemlhar à mostrada na FIG. 2) são lidas dos vários programas de aplicação. Neste bloco, quaisquer conflito entre estruturas são resolvidas. Mais além quaisquer programas de aplicações tendo estruturas cujos ob-jectos e ou comprimentos estão relacionados com os objéctos e ou comprimentos dentro das estruturas de outros programas de aplicações estão combinadas para formar uma estrutura (comum) agregada. 0 Bloco 516 representa o processo pelo qual os orientadores dos dispositivos de saida são carregados. Este processo é descrito com mais detalhe abaixo, com respeito à FIG. 5B. 0 bloco 520 representa o processo pelo qual os orientadores de BDT não carregados. Este processo será descrito com mais detalhe abaixo com respeito à fig. 5C. O bloco 524 representa o processo pelo qual os visores podem ser carregados e agregados. Este processo é descrito abaixo com maior detalhe, com respeito à fig. 5D. 0 bloco 528 representa o processo pelo qual os menus, as listas de teclados, as macros, e as listas de acontecimentos podem ser carregados e agregados.

Este processo será descrito com maior detalhe abaixo, com respeito à FIG. 5E. O carregamento e agregação destas quatro características foi combinado no encorporamento preferido, mas tal combinação não é necessário para a prática da invenção. A razão pela qual no encorporamento preferido, o carregamento e a agregação destes quadros característicos está combinado no que pode ser concebido como um processo único é porque o ficheiro xxx.MEN de acordo com o encorporamento preferido contém informação relacionada com estas quatro características. 0 seu carregamento e a sua agregação é vantajosamente consolidada devido ao intimo relacionamento da lista de teclados, da lista de acontecimentos macro (sequência de funções) e os nomes que possam estar envolvidos com a invocação de qualquer deles.

No encorporamento preferido a resolução de conflitos de teclados, ocorre após o processo de carregamento, à altura de correr. Veja-se abaixo a subsecção sobre "Resolução de Conflito de Teclado na altura de Correr" sob a descrição do "Principal Laço de Análise" na secção "implementação de Encorporamento Preferido". Este é um exemplo de como a resolução de conflito pode ser resolvida quer na altura de carregamento, na altura de correr ou numa combinação de ambos e ainda assim se manter no âmbito da presente invenção . 0 bloco 532 representa o processo pelo qual as fontes de dados em lotes (BDS) podem ser carregadas e agregadas. Este processo será descrito em maior detalhe abaixo, com respeito à fig. 5F.

As características de carregamento e agregação da presente invenção não tem de ser limitada aos programas de aplicações que possuem essas características descritas na FIG. 5, e em figuras detalhando essas características já revistas nesta discussão de FIG. 5. A presente inven- ção tem em vista a capacidade de carregar·, e agregar caracte-rísticas de uma variedade de programas de aplicações conhecidas agora e desenvolvidos mais tarde conquanto as caracterís-ticas dos vários programas de aplicação sejam desejados de ser carregados e agregados (com um possível resolução de conflitos) um programa de aplicações agregado. Assim, a invenção, não deve ser limitada em âmbito pelas particulares caracterís-ticas mostradas na FIG. 5 ou enumeradas na discussão relacionada, mas deve ser sómente ser limitada de acordo com as reivindicações que seguem esta descrição do encorporamento preferido.

Após o programa de aplicações e todas as suas características estarem carregadas e agregadas e tenham sido resolvidos tantos conflitos quanto os desejados, então o programa de aplicações agregado estará completo. A sessão interactiva do utilizador pode começãr. No ancorpora-mento preferidos, num primeiro mapa gerado no bloco 536 pelo programa de aplicações agregado é apresentado ao utilizador. 0 controle é então passado a um laço de análise ao longo de caminho 538. Um encorporamento preferido do laço de análise é descrito exacto abaixo, com referência à FIG. 5G. 1. Carregamento de estruturas A FIG. 5A ilustra em grande detalhe o processo de carregamento de estruturas mostrado como bloco 512 na FIG. 5.

Os blocos 5104, 5106 e 5108 na FIG. 5A ilustram o laço no qual as estruturas (tal como a FIG. 2) de vários programas de aplicações são carregadas e agrega- i

-57- dos. Uma exposição mais detalhada do processo de carregamento e agregação é descrito em maior detalhe abaixo, com especial referência às FIG. 9, 10, 11, 11B e 11B1. Estas figuras representam, em detalhe progressivamente maior, o processo pelo qual as características dos programas de aplicações em geral e as estruturas de dados em particular são carregadas e agregadas . A esta altura é suficiente mencionar que o processo de carregamento e agregação é levado a cabo por software que serve a um propósito mais geral. 0 mais geral dos processos ilustrados nas FIG. 9, 10, 11 e 11B e 11B1 nomeadamente transferência de dados em lotes) é aplicado nos blocos 5104 da (FIG. 5A) para o propósito particular de carregar estruturas. De facto, é uma das características inventivas da presente invenção que o software dos Sistemas de dados em lotes possam ser usados directamente para carregar e agregar estruturas. O Bloco 5104 (FIG. 5A) envolve a execução de um caminho na fig. 11, no qual uma transferência "INTERCALAÇÃO'·1 deste tipo é escolhida. Brevemente, na FIG 11 o caminho seguido no processo de carregamento e agregação 5014 (FIG. 5A) pode ser seguida na FIG 11 pelos blocos 904, 906, 1110, 1116, 1134, 1136, 1138, 1142, 1154, 958, 1160, 1164, 1172 e 1174. Após a execução do processo assim indicado na FIG. 11, o controlo retorna ao bloco de fim de laço indicado esquemáticamente como 5108 na FIG. 5A. O laço 5104, 5108 e 5106 (FIG. 5A) é executado uma vez para cada programa de aplicações. Desta forma, o programa de aplicações agregado é formado "acumulando" (falando a traços largos) os objectos e campos das estruturas de cada programa de aplicações conforme são processados no laço. É claro que o processo de carregamento de estruturas e agregação (incluindo a redução de conflitos) não necessita de ser executada pelo software já presen- -58-

te no Sistema de Dados em Lotes. Contudo a economia de usar o mesmo código é vantajosa. A invenção contempla não sómente o uso de código de Sistema de Dados em Lotes para o processo de carregamento e agregação mas qualquer processo de carregamento e agregação consistindo com as reivindicações que seguem esta descrição do encorporamento preferido.

Mais além, a estrutura de laço ilustrada como elementos 5104, 5108 e 5106 (FIG. 5A) não limita a invenção. Outro processo pelos quais as estruturas possam ser carregadas e agregadas (tais como processar os vários programas de aplicação numa maneira mais paralela) também faz dentro do âmbito da presente invenção.

Retomando a descrição de encorporamento preferido, após ter sido processado o último programa de aplicação pelo laço 5104/5108, o tamanho das agregações e resoluções de conflitos foi completada. 0 que fica do controle é passado do bloco 5108 ao bloco 5110 e mais além pode ser considerada como "guarda-livros') ou procedimento de limpeza que devem ser executados por forma a permitir o programa de aplicações agregado de opérar suavemente em estruturas de dados .

Primeiro, no bloco 5110, o objec-to de mais alto nível é determinado na estrutura agregada. No exemplo da FIG 2.o objecto de mais alto nivel seria o objecto armazém 202.

Após o objecto de mais alto nivel ser determinado no vloco 5110, um laço é executado uma vez para cada objecto no programa de aplicação agregado. Este laço de objecto, mostrado com o ponto de entrada 5112 e a decerção de fim de laço no bloco 5138, concatenou no seu seio dois laços .

I

-59-

De acordo com a convenção adopta-da na presente especificação, cada "objecto" pode ter um ou mais "campos" associados. Os campos especificam informação acerca do objecto. Também uma das características do objecto é a ligação desse objecto a outros objectos. Assim as especificações de objectos podem incluir informações tais como a descrição de que características que um objecto tem, mas inclui também o seu relacionamento com outros objectos. Tais especificações indicadoras de relacionamento são chamadas "ligações" de acesso com o padrão adoptado com respeito à FIG. 2.

Dois laços concatenados 5114/5122 e 5121/5130 dentro do laço maior de objecto 5114/5138 estão arranjado á maneira de séries. Este arranjo de laços em série é baseado um arranjo preferido num "ficheiro de estruturas" (Ver apêndice A). Num arranjo preferido de um ficheiro de estruturas as linhas do ficheiro representando campos descritos, são posicionados antes nas linhas do ficheiro descrevendo as ligações. Este arranjo não é necessário a todos os encorpora-mentos da invenção, mas é preferido pela sua simplicidade organizacional. 0 laço 5114/5122 é executado uma vez por cada campo descritivo no objecto. Logo após, o laço 5126/5130 é executado uma vez para cada ligação no objecto. A completação do processamento de campos e ligações no objecto permite que o carregamento total do objecto seja calculado com 5134.

Referindo de novo o laço 5114/5122 o comprimento de cada caixa de campo é calculado em 5114. Brevemente, uma "caixa", em estado que o "campo de caixa" pode tomar. Cada um tem um nome externo e um correspondente valor interno. O comprimento do campo de caixa é assim simplesmente o máximo comprimento dos nomes externos para todas as caixas.

Então, o espaço de memória para cada campo tem de ser colocado em cada registo. (Um "registo" é uma instância particular de um objecto, e pode conter dados particulares definindo essas instâncias particulares). O espa-

ço é colocado por forma a que, quando dádòs particulares são recebidos foi reservada memória suficiente no registo para o suportar.

Os campos são espaços de memória alocada relativa ao início do registo. Os campos são vantajosamente localizados numa ordem pré-determinada no registo. Quando o comprimento de todos os campos é calculado, então o comprimento total do registo é calculado para se fazer a alo-cação de memória. 0 comprimento de cada campo é determinado pelo tipo de campo. Por exemplo, o espaço alocado a um simples caracter, ou a uma é determinado pelo comprimento de caracter multiplicado pelo comprimento da cadeia, então o comprimento do apontador (endereço) determina o espaço a ser colocado. Se os tipos do campo são inteiros, interno grandes ou números de ponto flutuante, o comprimento dos números de ponto flutuante de 16-bits, 32-bits ou o padrão de IEE de 64 bits, pode por exemplo ser usado para determinar a alocação de espaço. Em instâncias onde o tipo de campo é uma "caixa" (uma guardada de múltiplos estados), então o comprimento a ser alocado é determinado pela etiqueta. Se o tipo de campo é uma referência a uma função, o espaço a ser alocado é determinado pelo dobro do comprimento de um inteiro. Um inteiro é o número da aplicação; o outro é o número de função nessa tabela de funções de aplicações.

Estes não são exemplos de alocação de espaço de memória que devem ter lugar nos blocos 5116 (FIG. 5A). Adições modificações e variações dos tipos de campos descritos e correpondentes métodos de alocação de memória pode ser feito por os hábeis na arte, enquanto ainda se mantém no âmbito da presente invenção.

Finalmente, quaisquer campos que são definidos por meio de fórmula de sistema (isto é, o con- -61-

teúdo particular dos dados do campo é para ser determinado como função do conteúdo de dados de outro campo) são compilados em 5118. Após estas funções terem sido executadas para cada campo no objecto, então o controlo passa do laço 5114/ 5118 ao longo do caminho 5124 para entrar no laço 5126/5130.

Um laço e executado uma vez para cada ligação e envolve a alo-cação de espaço para cada dessas ligações. Vários meios de alocar ligações faz no âmbito da presente invenção. Por exemplo, diferentes objectos podem ser ligados tendo o endereço de um primeiro objecto membro presente na especificação da ligação do dono. 0 primeiro objecto membro pode ter espaço alocado não somente para um apontador no início do registo de objecto do dono, mas pode ter um apontador para o início de um segundo registo de objecto membro. O segundo membro pode ter o endereço de um terceiro membro de objecto (em adição ao registo de objectos de dono) e assim por diante. (Conforme mostrado na FIG. 2, o objecto "armazém" 202 é um objecto dono com respeito ao membro objecto "gondola" 204).

Qualquer que seja o modo de ligação que seja escolhido, o espaço é alocado no bloco 5126. Contudo muitas ligações estão presentes no objecto determinam a quantidade de espaço alocado para as ligações especificadas.

Finalmente, após todos os campos e comprimentos no registo terem sido processados (e espaço alocado consequentemente) nos laços 5114/5122 e 5126/5130, então o tamanho total do objecto é calculado ou 5134.

Todo este cálculo do tamanho total de um objecto é usado para reservar espaço para os objectos durante a operação do programa.

Quando o tamanho total de um dado objecto é calculado, o laço 5114/5138 é repetido até todos cs X . X . objectos no programa de aplicações tenham1 sido processados. Após o último objecto no programa de aplicações agregado ter sido processado, o controlo passa o caminho 514 (FIG. 5) para os outros procedimentos de carregamento e agregação. 2. Carregar orientadores Dispositivos de Entrada e Saída A FIG. 5B é uma ilustração de um fluxograma ilustrando o processo pelo qual os orientadores de dispositivos de entrada e de saida são carregados e agregados e subsequentemente processados.

Geralmente, cada programa de aplicações pode providenciar um ou mais dispositivos de entrada ou de saida com as suas funções de suporte identificadas por um número. Após carregamento, as funções elas mesmo são baseadas nesse número. Então os dispositivos de saída para textos, gráficos e relatórios são decididos, baseados nas capacidades dos dispositivos candidatos.

Referindo mais específicamente à FIG. 5B, o controle passa pelo caminho 514 para entrar no laço 5204/5206/5208. Este laço é executado uma vez para cada programa de aplicações. A função do laço é carregar e agregar os orientadores de dispositivos de entrada e de saída. Brevemente isto é conseguido lendo um ou mais orientadores de um ficheiro de orientadores (XXX.DEV) de cada programa de aplicações. Cada dispositivo de saida é adicionado à lista de orientadores de saida e cada orientador de dispositivo de entrada é adicionado à lista de orientadores de entrada. -63-

Após os orièhtadores dos dispositivos de todos os programas de aplicações terem sido carregados e agregados, o controle passa do laço em 5208 para entrar os blocos 5210. A função do Bloco 5210 é encontrar as funções que são referenciados nos orientadores dos dispositivos. Nesta altura, estas funções são para ser encontrados no ficheiro executável dos programas de aplicações. Encontrar as funções permite a descrição de informação na lista de dispositivos de ser conectada às funções orientadoras actuais.

Finalmente é determinado um dispositivo de saida por defeito, conforme indicado no bloco 5214.

Os meios pelos quais os dispositivos por defeito são determinados são como se segue a lista de orientadores de dispositivos de saida resultante é prescritada para encontrar um orientador que possa lidar com as nacessidades com uma sessão do écran interactiva e se houver muitas, escolherá a que tiver a melhor estampagem (resolução de écran e profundidade de cor). O controle passa ao longo do caminho 518 para entrar no bloco 520 (FIG. 5) relacionado ao carregamento do BDTs.

3. Carregamento de orientadores BDT A FIG. 5C é um fluxograma ilustrando o processo pelo qual os orientadores BDT, são carregados, agregados e subsequentemente processados.

Geralmente cada programa de aplicações pode providenciar um ou mais tipos de Dados em lotes, com as suas funções de resposta referenciadas por número. Após o carregamento, as funções elas mesmas são encontradas com base no número.

Referindo mais em especial a FIG. 5C, o controle passa ao longo do caminho 518 para entrar no laço 5304/5306/5308. Este laço é executado uma vez para cada programa de aplicações. A função do laço é a de carregar e agregar os orientadores do BDT. Em resumo, isto é conseguido ao ler um ou mais orientadores de BDT do ficheiro (XXX.BDT) de cada aplicação BDT. Cada orientador é acrescentado á lista de orientadores BDT.

Após terem sido carregados e agr£ gados todo os orientadores de dispositivo de todos os programas de aplicações, o controle passa o laço em 5308 para entrar no Bloco 5210. A função do bloco 5310 é de encontrar as funções que são referenciadas nos orientadores de BDT. Nesta altura, estas funções são para ser encontradas no ficheiro executável de aplicações. Encontrar as funções permite a descrição de informação na lista BDT para ser ligada às funções orien tadoras actuais.

Finalmente, o controle passa pelo caminho 522 para entrar no bloco 524 (FIG. 5) relacionado com o carregamento dos visores. 4. Carregamento de visores A FIG. 5D é um fluxograma ilustrando o processo pelo qual os visores são carregados, agregados e subsequentemente processados.

Geralmente, cada programa de aplicações pode providenciar um ou mais visores. Conforme são carregados, posteriores aplicações podem ser actualizados ou modificar os visores já providenciados, bem como juntar novos visores.

Referindo mais específicamente à fig. 5D, o controle passa ao largo de caminho 522 para um laço 5404/5406/5408. Este laço é executado uma vez para cada programa de aplicações. A função do laço é carregar e agregar os laços, visores e campos dos visores dos vários programas de aplicações. Em resumo, isto é conseguido lendo um ou mais visores e campos de visores de cada ficheiro de aplicações de visores (XXX.VIE). Cada novo visor é acrescentado á lista de visores interna, com os seus campos. Uma aplicação pode modificar ou acrescentar a um visor de outro incluindo o mesmo visor pelo nome com informação diferente que então irá escrever por cima (ou parcialmente escrever por cima) o original de acordo a que informação é dada no seu ficheiro de visores.

Após todos os visores de todos os programas de aplicações terem sido carregados, o controle passa do laço em 5408 para entrar no bloco 5410. A função de bloco 5410 é para encontrar os visores que são sequenciados noutros visores. Uma ocasião em que um virus referência outro viros, por exemplo, é quando um visor que descreve como um objecto pode ser desenhado quer disparar o desenho de objectos de mais baixo nivel. Faz isto referindo ao visor que descreve como é desenhado esse objecto de mais baixo nivel. Os visores que referenciam cada outro são então conectados.

No subsequente bloco 5414, as referências a funções por número são também encontradas (funções de desenho). Em resumo, uma "função de desenho" é uma função que dado um registo desse objecto pode desenha-lo (como um ou mais blocos) baseado nos campos nesse registo. No bloco 5416, o número máximo de "páginas" para cada visor é determinado en- -66-

contrando a página de referência de mais alto número de visor. Uma "página" é uma colecção de campos um écran cheio de visor que enche o écran. 0 utilizador pode então trocar entre páginas para ver e mudar campos (um registo) que encheria um écran.

No bloco 5418, os campos e as ligações referenciadas por nome são encontradas nas estruturas.

Finalmente, o controlo passa ao longo do caminho 5426 para outros blocos 528 (FIG. 5) relacionado com o carregamento de menus, listas de teclas, macros e listas de acontecimentos. 5. Carregamento de Menus, Lista de Teclas, Macros e Listas de Acontecimento A FIG. 5E é um fluxograma ilustrando o processo pelo qual os ménus, as listas de teclados, as macros e listas de acontecimentos são carregados agregados e subsequentemente processados.

Geralmente, cada programa de aplicações pode providenciar um ou mais menus, teclados, macros ou acontecimentos. Programas de aplicações posteriores podem actualizar ou mudar menus, entradas de teclas, macros, acontecimentos que tinham já sido providenciadas, bem como adicionar novos. Os Menus, as entradas de teclas, as macros e os acontecimentos que se referenciam uns aos outros são conectados. Finalmente, todas as macros são compilados numa forma interna para uma execução mais rápida.

Referindo mais especialmente a FIG. 5E, o controle passa ao longo do caminho 526 para entrar no laço 5504/5506/5508. Este laço é executado uma vez por cada programa de aplicações. A função do laço é a de carregar e agregar os menus, listas de teclado, macros e listas de acontecimentos vários programas de aplicações. Brevemente isto é conseguido lendo um ou mais menus, atribuições de teclas, macros e acontecimentos de cada ficheiro de menus de aplicações (XXX.MEN).

Cada novo menu é acrescentado à lista de menus. O mesmo processo é seguido para as listas de teclas, listas de macros e lista de acontecimentos. Uma aplicação pode modificar ou adicionar a um outro menu incluindo o mesmo menu por nome com diferentes entradas que então escreverão por cima ou adicionarão ao menu original.

Após os menus, as listas de teclas, macros e listas de acontecimentos de todos os programas de aplicações terem sido carregadas e agregadas, o controle passa do laço em 5508 para entrar no bloco 5510. A função do bloco 5510 é para encontrar os menus que são referênciados por outra entrada de menu. Um exemplo de quando uma tal referência pode ocorrer é quando uma entrada de menu conduz o utilizador a um segundo nivel de menus.

Os blocos seguintes conseguem a interligação dos vários menus, teclas, macros e listas de acon tecimentos conforme é conseguido no encorporamento preferido. É imediatamente aparente que o ordenamento particular da interligação, ou a adição ou anulação de certas das interligações, para aplicações particulares, está dentro de habilidade de alguém hábil na matéria sem sair do âmbito da invenção.

No bloco 5512, quaisquer macros que sejam referenciados pelas entradas de menus são encontradas. Nesta altura, as macros podem ser encontradas na lista de macros (acima descrita).

No bloco 5514, quaisquer menus que são referenciados por teclas particulares, são encontrados .

No bloco 5516, quaisquer macros que são referenciados por teclas particulares são encontradas.

No bloco 5518, as macros são compiladas para serem executadas mais rápidamente.

No bloco 5520, as macros que são referênciadas por acontecimentos particulares são encontradas.

Finalmente, o controlo passa pelo caminho 530 para entrar no bloco 532 (FIG. 5), relacionado para carregar os orientadores do BDS.

6. Carregamento de dispositivos orientadores BDS A Fig. 5F é um fluxograma ilus -trando o processo pelo qual os orientadores BDS são carregados, agregados e subsequentemente processados.

Geralmente, cada programa de apli^ cações pode providenciar um ou mais Fontes de Dados em lotes (BDS's. Uma vez carregadas as referências às BDTs são encon -tradas, como o são as referências aos objectos, campos e lige* ções na estrutura e referência aos visores.

Referindo mais especialmente à Fig.5F o controlo passa pelo caminho 530 para entrar um laço 5604/5606/5608. Este laço é executado uma vez por cada progra ma de aplicações. A função do laço é carregar e agregar os BDS vários programas de aplicações. Em resumo, isto é conse -guido pela leitura de um ou mais BDS de cada ficheiro de apl_i cações BDS (XXX.BDS). Cada BDS é junto à lista interna de BDS.

Após terem sido carregados e agregados todos os BDS de todos os programas de aplicações, o controlo passa do laço em 5608 para entrar no bloco 3610. A fun -çao do bloco 5610 é para encontrar os BDTs que são referenciados pelo BDSs. Nesta altura, os BDTs podem ser encontrados na lista de BDT já lida (Fig.5C).

No bloco 5612, quaisquer objectos, campos e ligações referenciado no critério BDS (na tabela de BDS, Fig.12) serão encontrados. Nesta altura, os objectos, cam pos e ligações podem ser encontradas na estrutura agregada (Fig. 5A).

No bloco 5614, quaisquer visores que sejam referenciados nos BDS serão encontrados. Nesta altu ra, os visores podem ser encontrados na lista de visores (Fig. 5D) .

Finalmente, o controlo para ao longo do caminho 5634, para entrar no bloco 5636 (Fig.5) o la ço principal de análise. 7. 0 laço principal de Análise A Fig. 5G é um fluxograma ilus -trando o laço de análise principal de acordo com o encorpora-mento preferido. 0 laço de análise principal da Fig. 5G é entrado após completação do processo de carregamento do programa de aplicações 500, (Fig.5).

Se o programa se encontra no modo de mapa, então os detalhes do mapa são dispostos de acordo com as especificações do utilizador no bloco 5708. Por exem -pio, o mapa é preparado para iniciar do primeiro registo na lista e do campo mais à esquerda. A "lista de ordenação" bloco 5712 executa a função de ordenar a lista de registos de acordo com os detalhes dados no visor corrente. O mapa é, na realidade desenhado no bloco 5714 O laço de análise ele mesmo, começa no bloco 5716, no qual o cursor, é desenhado (ou redesenhado). No laço de análise preferido, vários testes são executados nos blocos 5718, 5728, e 5738. Os três testes são: (1) Se uma mecro está a correr na altura; (2) Se é devido um acontecimento, e (3) Se uma chave (ou botão do rato e assim) foi poluida.

Se alguma destas condições se verificar, então o controlo passa pelos respectivos ramos 5720, 5730 e 5740. Os processos encontrados nestes ramos contigentes são similares, em que as funções (ou conjuntos de funções) -71-

são executadas, tais como 5724 (macros), 5732 (acontecimentos) e 5746 (teclados). Também, uma vez que as respectivas funções (ou sequências de funções) tenham sido executadas, qualquer código de retorno produzido pelas funções são processados, como mostrado nos blocos 5726, 5736 e 5748. É possivel que algumas caracterís-ticas do programa de aplicação agregado tenha os conflitos resolvidos na altura de correr, mais do que durante o processo inicial de carregamento e agregação, (FIG. 5). Uma escolha de uma característica que pode vantajosamente ter os seus conflitos resolvidos na altura de correr são as teclas. Uma tal resolução de conflito exemplar é indicada no bloco 5741 (FIG. 5G). Porque este é um caso muito especial será descrito abaixo com maior detalhe, na reacção sobre teclados em altura de correr, resolução de conflitos. a. Processo de Código de Retorno

Esta subsecção descreve posicionamentos de código de retorno exemplares e descrevem a acção a levar a cabo nos blocos 5726, 5736 ou 5748 (FIG. 5G) se os dados códigos de retorno são inicializados.

Nesta especificação, uma palavra do código de retorno compreende um conjunto de bits que são retornados por uma função de um programa de aplicação após a execução. 0 que se segue é uma descrição de bits de código de retorno que estão presentes ao ambiente preferido.

Ineficaz: se em uso, este bit significa que a função não foi executada. Uma razão possivel para que a função não tenha sido -72-

executada foi que, por exemplo, a função" pòderá só ser executada com significado se o programa de aplicações agregado estivesse presente no"mapa" em modo, quando na realidade estava em modo "modelo". Preferivelmente o pôr em uso o bit "ineficaz" provoca o laço que analisa continue apesar da não execução da função.

Registo de verificação: Se este bit é posto em uso, a "rotina de registo" de verificação é invocada. Em resumo um "registo de verificação" a rotina, executa a função de chamar a função (especificada na estrutura para cada objecto) suprida pelo utilizador para fazer quaisquer verificações específicas da aplicação.

Repor o desenho/Escala/Cursor/Mapa: Este bit, reposto em uso, causa cada um destes conjuntos de variáveis correntes para serem repostas no seu estado antes do comando ter sido iniciado. Esta reposição de variáveis assegura que a manipulação nas funções destas variáveis não afecta adversamente outros usos dos valores destas variáveis noutras rotinas.

Reorganizar o mapa; Este bit, se posto em uso, provoca que a informação do mapa seja reorganizado de acordo com os detalhes no visor corrente.

Próxima chave: Este bit provoca o posicionamento posterior dos escolhidos dos códigos de redesenho seguintes até uma chave ser carregada.

Redesenhar a imagem: (Só com significado no modo "modelo") provoca o redesenho da imagem de uma representação interna do objecto tridimensional, da imagem préviamente desenhada.

Redesenhar dados: provoca que uma imagem inteira seja redesenhada a partir dos dados originais.

Redesenhar o registo: provoca que só um registo particular seja redesenhada.

Re-estampagem: provoca que o écran seja re-estampado de uma cópia manchada da imagem. b. Resolução de conflitos em teclados na altura de correr r

No encorporamento preferido a resolução de conflitos de teclas é executada na altura de correr no bloco 5744 (FIG. 5G). A fim de eliminar ambiguidades, pode ser preferível em muitos programas de aplicações agregados primeiro traduzir a tecla na lista para maiusculas. Então é entrado um laço onde as entradas numa lista de teclas é processada em comparação com o símbolo da tecla. Ao longo desta discussão, a palavra "tecla" é usada como uma rotação encurtada para um sinal de um dispositivo de entrada de qualquer tipo concebível, aqui conhecida, ou após desenvolvida. Por exemplo, as entradas de um leitor de código de barras, pressões no botão de um "rato", movimento de uma "manche" e assim por diante faz no âmbito de contemplação da invenção presente. Os teclados são o foco da presente discussão, mas o facto de que são muitas vezes usados meios de entrada no encorporamento preferido não limita o âmbito do princípio inventivo exemplificado aqui. A lista de teclados de acordo com o encorporamento preferido pode ser concebido como um mapa tendo quatro colunas. Uma lista de teclas exemplar é mostrada na FIG. 6 e ilustra a associação de teclas com funções particulares, menus ou macros. A coluna mais à esquerda é uma lista de teclas dos vários programas de aplicações individuais que possam ligar de ponta-a-ponta. A segunda coluna é uma lis-

ta da função que é para ser executada em resposta às correspondentes teclas na coluna. Vantajosamente, um número a esquerda do ponto decimal na função de referência refere-se ao programa de aplicações e o número à direita do ponto decimal refere-se à função particular nesse programa de aplicações. A terceira coluna na lista de 4 teclas é a coluna de "menus". Se uma tecla particular é a que invoca um menu, então o nome do menu aparece na coluna de menus ainda da entrada particular da tecla.

Finalmente, o nome de uma macro para ser executada em resposta a um teclado particularmente primida pode ser encontrada ao lado da tecla na posição mais à direita da coluna "macro".

Pode haver entradas em nenhuma, uma ou mais que uma das três colunas etiquetadas "função", menu" e "macro".

Esta lista de teclas é meramente exemplar representa em abstracto um meio preferido de implementação e explanação de um método de resolução de conflito de teclas de acordo com o encorporamento preferido. Por exemplo, outras listas de teclas pode ser formado no qual listas das diferentes programas de aplicações não são ligados de ponta a ponta, mas não ordenadas da outra por uma para fins particulares .

Conflitos de teclas surgem quando a mesma tecla aparece em diferentes aplicações mas têm funções diferentes, menus ou macros associados com esse tecla nos res-pectivos programas de aplicações. Um tal exemplo, ilustrado na FIG. 6, pode ocorrer se o caracter "escape" (ESC) aparece em ambos os programas de aplicações número 1 e o programa de aplicações número 2. Neste caso, ESC apareceria duas vezes na coluna "teclas". Para além da primeira ocorrência do caracter -75- ESC. pode nas suas funções 1.7 de um primeiro programa de aplicações. Além disso a segunda ocorrência do caracter ESC pode ser uma segunda função 2.8 de um segundo programa de aplicações.

Voltando agora a como os conflitos de teclas são resolvidos na altura de correr, a rotina de resolução de conflitos de teclas examina o conteúdo da lista de teclas agregado. Num encorporamento preferido, a lista de teclas é examinada de uma forma do topo para baixo. Contudo, outras sequências de ordenamento e exame das entradas da lista de teclas está dentro da contenplação da presente invenção.

Por exemplo, a cada uma das entradas de teclas pode ser dada uma "prioridade" que é um número de 1 a cerca de 10000 no encorporamento preferido. A tabela de teclas agregada é ordenada por esta prioridade por forma a que a prioridade mais alta de entrada de teclas vão para o topo da tabela antes da execução. Este arranjo dá vantajosamente aos que escrevem aplicações o controle sobre como resolver conflitos de teclas.

No encorporamento mostrado na FIG. 6, as entradas nas três colunas à direita das teclas são examinadas .

Primeiro, se há uma entrada na coluna de "menus", o seguinte processo é executada. Se existir uma função pré-menu (isto é, uma função e um menu através de entrada em um linha de Lista de Teclas), então a função é chamada. Se a execução da função provoca que o menu seja inibido (evitar a sua operação), então o menu não é executado e a próxima linha na Lista de Teclas é examinada. Se a função não inibe o menu, então o menu é activado por forma a que as funções subsequentes ou a sequência de funções são chamadas. Um código de retorno do sistema de menus é então processado.

Isto termina' a descrição do que ocorre se existe uma entrada de menu na lista de teclas. Se uma macro está macro está presente na lista de teclas, a execução da macro é então iniciada. O código de retorno da macro completada é então processada de acordo com os princípios acima descritos, na secção sobre "processamento de códigos de retorno".

Se uma função está presente na lista de teclas, então o processador verifica para ver se a função existe. Se afunção não existe, então a próxima linha na Lista de Teclas é processada. Se a função não existir, então a função "só-para descrição". 0 chamar a função "só para descrição" a função é estampa ao utilizador (a estampagem é só nos menus") de modo a que o utilizador pode abortar a execução. Uma descrição compreende efectivamente um comentário de ajuda a um utilizador activo, o qual é um característica de auto-documentação das funções de acordo com o encorporamento preferido. Se alguma característica automática no software escolhe abortar a função prioritáriamente à sua execução, então a função pode ser posta "ineficaz" mesmo nesta altura prematura. A função é seguidamente verificada para "invalidade". A breve trecho, "invalidade" significa que a função ela mesma devolve um código significando que é inválida no presente contexto (devolvida de uma chamada a "só descrição" acima descrita).

Se afunção se encontra inválida, a presente linha na lista de teclas é saltada e a próxima linha na Lista de Teclas é examinada. Se afunção existe e passou os testes acima, então a função é chamada para execução. Após a execução, o código de retorno é processado de acordo com a descrição do Processamento de Códigos de Retorno acima. Final- mente, os laços de controlo, vêm atrás como que para verificar a próxima entrada na lista de teclas.

No encorporamento preferido, este laço é executado até todas as entradas na lista de teclas tenham sido examinadas. A descrição acima providenciada como para representar uma mistura óptima substancial de prati-calidade, eficiência e de amizade do utilizador e tem sido en contrada especialmente adaptada em programas de aplicações en volvendo a gestão de espaço. Contudo, variações e adaptações do encorporamento preferido a outras aplicações está dentro da contemplação da presente invenção, conforme definida pelas reivindicações apostas.

Se as linhas da lista ou teclas forem arranjadas de maneira diferente, por forma a que o seu processamento ocorresse numa ordem diferente, por exemplo, en tão os meios efectivos de resolução do conflito de teclas seriam diferentes. Dada a descrição acima, contudo, alguém com habilidade na matéria está preparado para praticar variações no encorporamento preferido. A descrição acima, descreve um processo no qual essa função é executada a que primeiro fôr encontrada na lista de Teclas associada com a tecla preferida. Em adição a escolher um meio diferente de juntas ou intermé -dias as entradas na Lista de Teclas, tais outros meios de resolver resoluções de conflitos de teclas inclui dar a cada t£ cia na tabela de teclas um número de prioridade e executar a função de mais alta prioridade primeiro onde houver um confl_i to. !

Β. Ο Sistema de Dados em Lotes A Fig. 7 representa o relacionamento do sistema de dados em lotes 701 com outra porção da memória da U.C.P. 720 e armazenamentos dados externos exempla res 736, 738, 740 e 742. A Fig. 7 também representa, de uma forma esquemática, o relacionamento dos BDS 702 (Sistemas de Dados em Fonte) e BDT1s 704 (Tipos de Dados em Lotes).

Uma fonte de dados em lotes (BDS) tal como os módulos 706, 708 e 710 é um módulo de software de mais alto nivel que os BDT's 712, 714, 716 e 718. Os BDS espe cificam controlos sobre como a transferência é para ser lidada. Os BDS podem incluir informações tais como por em uso antecipado (ou especificado pelo utilizador) nomes de ficheiros quadros de direcção, especificações de actualização ou escri-ta-por-cima, filtros de dados (gerais, de registos e de nivel de campo), bem como referências modificáveis a BDT's particulares .

Os módulos de tipos de dados em lotes (BDT) 712, 714, 716 e 718, por outro lado, são cada um módulos de software específicos de dispositivo o qual, no en corporamento preferido, lida muito menos selectivamente com dados não tratados indo de e para tipos de armazenamento de dados externas 736, 738, 740 e 742.

Em regra, é propósito do Sistema de Dados em lotes para eficaz, eficientemente e flexivelmente levar a cabo as transferências dados em lotes. Geralmente, uma transferência de dados em lotes ocorre entre a memória da U.C.P. e um tipo de armazenamento de dados externo. Tais armazenamentos de dados incluem muitas vezes ficheiros num disco ligado a um sistema informático em que está residente o

I

-79-

Ambiente Operativo de acordo com o encorporamento preferido. Por exemplo, um ficheiro de texto 736, um ficheiro de base de dados 738 ou um ficheiro ASCII 740 são muitas vezes usados como exemplos de ficheiros de dados encontrados em gestões de espaço em programas de aplicações. Contudo, está bem dentro do âmbito do encorporamento preferido que os dados de um computador manuseado (ilustrado como elemento 742 na Fig.7) pode constituir um armazenamento de dados para o qual o Sistema de Dados em lotes pode comunicar. Mais além, os ficheiros de dados em computadores principais externos (não especialmente en contrados na Fig.7) são armazenamentos de dados com o qual o sistema de dados em lotes pode comunicar.

Finalmente, o sistema de dados em lotes de acordo com o encorporamento preferido pode transfe -rir dados de uma parte da memória da U.C.P. para outra parte da memória da U.C.P., conquanto uma das porções da memória central esteja no espaço colocado ao Ambiente Operativo. A ou tra porção da memória da UCP, de ou para a qual os dados são transferidos, é considerada (para os propósitos da transferên cia) para constituir o "armazenamento de dados" que correspon de ao armazenamento de dados exemplar "externo" 736, 738, 740 e 742. 1. Interacção dos BDS's com os BDT1s

Preferindo de novo a Fig. 7 os BDS 706, 708, 710 estão mostrados em justaposição com os BDT's 712, 714, 716 e 718 no Sistema de Dados em lotes 701.

Cada um dos BDS individuais no bloco BDT 704. A correcção particular mostrada na Fig. 7 é uma

I

-80- na qual a BDS 708 está ligada à BDT 716. Esta ligação permite uma transferência de dados em lotes de dados entre um ficheiro ASCII 740 e a memória UCP 720. A BDS 708 poderia tão facilmente ter sido conectada a outras BDTs, tal como a 712, 714 ou 718, por forma a que os dados poderem ser transferidos entre a memória de UCP, 720 e o ficheiro de texto 736, o ficheiro de base de dados 738 ou um computador manuseável 742, respec-tivamente.

Análogamente, a BDT 716 poderia ter sido fácilmente conectado a outras BDS com 706 ou 710. A presente invenção contempla a possibilidade de transferir dados da porção da memória da UCP 720 alocada ao Sistema Operativo de ou para outra secção 750 da memória da U.C.P.

Isto é conseguido através de uma interligação indicada no caminho 726 (Fig.7). A representação da interacção dos BDS e BDT uma natureza esquemática. O fluxo actual de con trolo de programas no encorporamento é descrito abaixo em maior detalhe, com respeito às Fig. 9, 10, 11, 11B e 11B1. Para a presente discursão, é importante compreender que cada BDS, coresponde uma especificação de alto nível da informação que o utilizador deseja transferir de e para fora da memória de UCP 720 durante a execução do programa de aplicações agregado. Tais especificações de alto nível podem incluir quais objectos, conjuntos de objectos, campos ou conjuntos de campos que o utilizador deseja que sejam transferidos. É claro, que o utilizador não necessita ter consciência ou apreciar que está a lidar com "objectos" ou "campos". Preferivelmente, tudo o que poderá conscientemente estar a par de, durante uma sessão interacti-va com o programa de aplicações agregado é que, por exemplo, ele queira transferir um conjunto de preços de retalho (campos) para um conjunto pré-determinado de produtos de consumo (correpondentes objectos)que estejam numa dada prateleira (um objecto) uma dada gondola (um objecto) um dado armazém (um objecto). Assim, embora esta especificação declare que o utilizador "experimente" a BDS ele fá-lo de um modo que lhe é compreensível. 0 utilizador não "experimenta" o funcionamento dos BDT. Qualquer que seja o BDS (tal como 708) invocado e/ou definido pelo utilizador escuda efectivamente o utilizador de lidar com qualquer das especificidades da BDT (tal como 716). Esta é uma das vantagens da invenção.

Mais uma vantagem permitida pela interligabilidade flexivel dos BDS e BDT é que quando um novo armazenamento de dados externos 744 está para ser acrescentado ao sistema, todo o que necessita ser acrescentado ao software é um novo BDT 746. Não fosse pela flexivel interligabilidade dos vários BDS com os vários BDT, então (assumindo haver só trés BDS, 706, 78 e 710) o artista primeiro teria de ter escrito software de transferência de dados em lotes em três módulos: módulos que executam as tarefas conseguidas por 706/ /746 e 710/746.

Usando a presente invenção, novo software de baixo nivel específico de BDT. pode ser acrescentado sem fazer quaisquer modificações ao BDS. Isto é de grande utilidade, ainda mais por as características de muitos BDS estarem definidos interactivamente por um utilizadas que tem potencialmente pouca "habilitação literária computacional".

Um BDT típico (por exemplo, um dedicado a um ficheiro de texto 736) teria tido de concordante do formato do ficheiro de texto. Por exemplo, teria de sa- \ ber ο ordenamento das etiquetas para as colunas, a natureza e ordenamento das entradas de acordo com o texto e das convenções adoptadas para referenciar outras entradas no texto se a fórmula de sistema fosse empregue. A habilidade para efectuar um meio racional de transferir dados de e para um tal ficheiro de texto está dentro da capacidade de alguém hábil na matéria .

Os detalhes de como escrever de o software' de transferência do actual ficheiro não necessita aqui ser detalhado, em tanto quanto essa tarefa particular, de e para ela mesma não faz no coração da presente invenção. Antes, a flexivel interligação dos BDS e BDTs representa um só na matéria sobre os sistemas de software conhecida de identidade única no qual tanto as funções de alto nível como as de baixo nível têm de ser modificadas e recompilados sempre que um armazenamento de dados com um novo formato está para ser acrescentado.

Referindo a FIG. 8, um mapa mostrado um conjunto típico de módulos de dados BDS é mostrada.

Na coluna mais à esquerda, o nome do BDS é mostrada. Na coluna imediatamente à direita do nome BDS está o nome de BDT que está presentemente ligado ao correspondente módulo BDS de dados. A interligação de módulos de software de BDT e BDS antes mostrado na FIG. 7 pode ser modificado interactivamente entran do informação em qualquer das colunas mais à esquerda na FIG. 8. Estes meios simples e eficazes de reconceber as relações entre os módulos BDS e BDT mostrou-se eficaz em aplicações quando se usa o encorporamento preferido, mas muitas variações poderão ai ser praticadas por alguém hábil na matéria sem fugir ao espírito da presente invenção. Quaisquer meios pelos quais uma BDS possa ser flexivelmente interligada com um módulo de software BDT está na contemplação da presente invenção. A terceira a quarta e a quinta colunas da esquerda do mapa na FIG. 8 refletem o valor de três guardas importantes ao processo de transferência. A guarda de Direcção, Novo/Adicio-nar e Actualizar, não só actualizar e as suas funções em dirigir a operação do processo do Sistema de transferência de dados em lotes são descritas abaixo com mais detalhe na subsecção intitulada "0 Processo de Transferência de Dados BDS". A sexta coluna no mapa FIG. 8 mostra a especificação do utilizador em como registos duplicados (isto é, ocorrência do mesmo objecto com campo de chaves duplicadas) são lidadas pelo sistema. A sétima e a coluna mais à direita da FIG. 8 reflete a especificação de que objectos estão para ser transferidos. 0 significado das especificações nestas duas colunas será também descrito em maior detalhe abaixo. A sétima coluna da FIG. 8, intitulada "objectos", mostra que objectos são para serem transferidas e se o utilizador deve ter algum controle interactivo durante o processo. Ver discussão da FIG. 8 abaixo, na subsecção "0 Processo de Transferência de Dados BDS". A oitava coluna da FIG. 8, intitulada "orfãos", mostra como lidar com objectos que podem ser dados com ligações incompletas de informação. (Ver subsecção intitulada "A Rotina do Leitura de Dados). A nona coluna de FIG. 8 intitulada "formato de destino", mostra se se deve usar uma estrutura que já está no destino, uma cópia da estrutura interna, ou outra separadamente especificada, estrutura de "escantilhão". (Ver descrição do bloco 1126 abaixo, na descrição da FIG. 11.). A décima coluna da FIG 8, intitulada "Estampagem" mostra se as utilizadas deve ser dado uma estampagem no écran descrevendo a transferência e também se os erros durante a transferência devam ser mostrados ou ignorados. A décima primeira coluna na fig. 8, intitulada "ficheiro de acionamento", mostra o ficheiro a usar para a tranferência ou um "meta-caracter" especificando um conjunto de ficheiros do qual o utilizador escolherá. 0 mapa da FIG. 8 é apresentado como um exemplo não limitativo do uso com o qual a transferência de dados, o processo, pode ser dirigido pelo utilizador. 0 conteúdo e arranjo do mapa exemplar na FIG. 8 não deve ser constituído como características de definição que são necessária a todos os encorporamentos da invenção. Certas características podem ser anuitidas e outras não serem explicitamen-te descritas aqui podem estar presentes e ainda estarem dentro do âmbito do concenito inventivo de interligação flexível de módulos de software de alto nível com direccionadores de ligações de baixo nível. 2. 0 processo de Transferência BDS, de Dados

Referindo de novo a FIG. 7, o processo pelo qual os dados são transferidos entre a memória da U.C.P. 720 e um tipo de armazenamento de dados extenso tal como o ficheiro ASCII 740 será descrito aqui. A maioria desta descrição respeitará à maneira como as funções são colocadas em BDS típico e um BDT típico. A FIG. 7 é esquemática quanto à sua natureza. Embora o BDS 708 e o BDT 716 sejam propriamente indicados como módulos de software separados o controle é passado entre os dois módulos repetidamente através de uma transferência de dados típica no encorporamento preferido.

Esta passagem repetida do controlo será agora descrita. -85-

Referindo a FIG. 9, um fluxograma básico do processo de transferência do BDS é apresentado.

Na FIG. 9 (bem como nas figuras que a seguem) os blocos tais como 908 e 958 são desenhados com linhas duplas nos lados direito e esquerdo dos blocos. As linhas duplas indicam que a função é substancialmente executada na BDT. Um bloco que não tenha linhas duplas nos lados direito e esquerdo do bloco indica que a função é executada substancialmente a BDS. Um bloco tendo linhas ponteadas nos lados direito e esquerdo é executado concorrentemente na BDS e BDT, sendo o controlo partilhado entre os dois módulos.

Uma transferência é invocada por, por exemplo, um utilizador entrando um comando que requere informação adicional para ser enviado de ou para um dispositivo de dados externo ou um "disco RAM" (ou blocos da Memória UCP, um ambiente de multitarefa). Sobre esta invocação de transferência, o conteúdo do controlo passa pelo caminho 902 ao bloco 904.

No bloco 904, o tipo de transferência é determinado com base em (no encorporamento preferido) três quardas diferentes em bits. Referindo brevemente a FIG. 10, cinco tipos de transferência que são especialmente úteis nas colunas de topo do encorporamento preferido num mapa. O valor das guardas de três guardas diferentes definindo cada tipo de transferência dadas são listadas no mapa.

GUARDAS

As três guardas têm os seguintes signif içados: DIRECÇÃO: Uma guarda de direcção tendo um valor de "dentro" significa que a transferência é para ser de um dispositivo de armazenamento externo ou ("disco "RAM") para a memória da UCP. Sua guarda de direcção tem o valor "fora", então a direcção da transferência de dados é fora da Memória da U.C.P. para o tipo de armazenamento de dados. NOVO/ADICIONAR: Esta guarda (se "novo") determinar que os dados existentes no ficheiro de destino são apagadas antes da transferência. "ACTU ALIZAR/NÃO SÓ ACTUALIZAR": Esta guarda (se em " ACTUALIZAR11) determina que só os registos com chaves concordantes com os dos registos de dados pré-existentes actualizam os registos de dados pré-existentes, o que os dados de registos de entrada que não têm chaves concordantes de outros registos pré-existentes são ignorados. TIPOS DE TRANSFERENCIA:

Cinco tipos de transferência úteis ao encorporamento preferido da presente invenção podem ser descritos como se segue. CARREGAMENTO: Provoca a que toda a informação presentemente existente na memória da UCP seja apagada. Novos dados serão

transferidos . INTERCALAÇÃO: A informação presentemente na memória de U.C.P. é deixada intacta e novos dados são adicionados à existente informação pela transferência de dados em lotes. A transferência de tipo intercalação é seguida durante o carregamento e agregação das várias características dos programas de aplicação (FIG. 5). ACTUALIZAR DE: A informação existente de momento na memória de UCP é deixada intacta e alguns dados novos são transferidos de dados em lotes. Contudo, os dados só são transferidos para os registos se esses registos já existem. Se os dados na transferência de dados em lotes é seguida para registos inexistentes, estes dados não requeridos não são escritos na memória da U.C.P. ACTUALIZAR PARA: Provoca uma transferência de dados fora da memória da U.C.P. A informação presentemente existente no armazenamento de dados destino é deixada intacta. Quaisquer dados na transferência de dados em lotes que não escrevesse por cima desses dados pré-existentes no armazenamento de dados é permitida de ser escrita no tipo de armazenamento de dados. ARMAZENAR: Os dados no armazenamento de dados é apagada e os dados da memória da U.C.P. é transferida para o armazenamento de dados externos.

Referindo de novo brevemente a FIG. 8, sobre os meios de lidas duplicados mais especificamen-te na sexta coluna, para cada BDS listada na primeira coluna. 0 encorporamento preferido engloba um sistema de lidar com duplicado que resolve conflitos numa variedade de maneiras. Primeiro, a opção de escrever por cima apaga um registo existente para arrajar espaço para todos os campos de um registo de entrada. A opção de escrever por cima dos campos permite que só os campos que são transferidos de serem actualizados; -88-

os outros campos que presumivelmente não serão actualizados serão deixadas inafectados pela transferência. A opção DEIXAR trata os registos existentes como tendo uma prioridade mais alta do que os dados dos registos de entrada. Nesta opção, os cínicos dados da informação que é permitida de ser escrita é a que vai ocupar registos préviamente inexistentes. A opção de FAZER CÓPIA pode ser seguida por forma a que na eventualidade de um conflito entre registos ou campos, o identificador descritivo do registo de entrada ou campo é modificado e o registo ou campo novos preexistentes são inseridos sob o identificar descritivo prévio.

Isto são só exemplo de modos contemplados pela presente invenção pela qual os conflitos de duplicação podem ser resolvidos. A coluna intitulada "Objectos" no FIG. 8, indica três opções que estão entre aqueles presentes no encorporamento preferido para mostrar quais os objectos a serem transferidos. TODOS: A opção "todos" indica que todos os objectos são para serem transferidos. Isto é, nenhum filtro é para ser executado na transferência de dados em lotes. LISTADOS: A opção "Listados" indica que só os objectos que estão listados num campo pré-determinado (acessível e modificável através do sistema de menu, por exemplo) não para serem transferidos. SELECCIONAR: A opção "seleccionar" indica que o utilizador pode seleccionar interactivamente quàis os objectos que estão para serem transferidos imediatamente antes da própria transferência .

I

-89-

Voltando à fig. 9, após ter sido escolhido o tipo de transferência como acima descrito com respeito aos valores das guardas na FIG. 10, o ficheiro a dados externos é escolhido no bloco 906. Esta escolha externa de ficheiro é determinada (explicita ou implicitamente) pela escolha de informação do utilizador que ele deseja transferir.

Se há uma ambiguidade o utilizador pode escolher prontamente de uma das possibilidades.

No bloco 908, a, rotina "INIT, BDT" é chamada. Esta rotina residente no próprio BDT, inicia-liza a BDT para as transferências. Por exemplo, uma base de dados BDT necessitaria de ser "aberta" antes de qualquer trans ferência possa ser feita.

Os blocos indicados como 910 e 936 representam a determinação dar estrutura (como entendido na FIG. 2) da transferência de dados em lotes. Esta determinação é descrita em maior detalhe com respeito à FIG. 11 abaixo. Brevemente, o sub-bloco etiquetado 910 (FIG 9) respeita a características mais automáticas de determinação da estrutura de transferência. Inversamente o sub-bloco 936 respeita a determinação de especificações para objectos e campos a serem transferidos que podem ser mais dependentes de dados e são por conseguinte mais virados para o utilizador (do que automáticos ) .

No bloco 954/956 a transferência de dados é executada incluindo resolução de quaisquer conflitos .

Finalmente, no bloco 958, a rotina "FECHO DO BDT" é chamado. Esta rotina leva a cabo a rotina de fecho do canal que são complementares às da rotina 908 "BDT INICIALIZAÇÃO" acima descrita. Em resumo, a rotina de FECHO BDT executa as funções de, por exemplo, dizer a um controlador de disco que o módulo terminou de processar o fi- -90-

cheiro ou dizer a uma base de dados que terminou uma transferência, de modo a que não ocorram situações "pendurada" e que todas as áreas de memória sejam libertos para uso futuro.

Durante o processo de transferência, se houvesse um problema sério com o canal de dados, então a rotina BDT pode devolver um código de falha ao BDS. Tais problemas sérios podem incluir ocorrências quando um ficheiro específico não é encontrado, há ligação física em falha na ligação de dados, ou um disco está cheio e assim por diante. Quando a BDS recebe o código de falha do BDT, o BDS pode parar o processo e mistificar o utilizador com uma mensagem de falha genérica ou uma mensagem específica sufrida pela rotina de BDT particular. Após uma falha tal como esta, a rotina de fecho BDT é chamada para terminar o processo de transferência. Tais acontecimentos não são especificamente indidos na FIG. 9, devido à sua natureza extraordinária, Contudo, deve-se compreender que a rotina de fecho de BDT pode ser entrada virtual^ mente em qualquer ponto após a rotina de INICIALIZAÇÃO é executada. A Tabela BDS.

Uma compreensão mais detalhada do processo de transferência de Dados de BDS pode ser facilitada se a tabela exemplar do BDS na FIG. 12 por compreendida. É claro que, as variações e modificações da Tabela exemplar de BDS pode ser feita por aqueles que são hábeis na matéria, enquanto ainda se mantêm no âmbito da presente invenção.

Em resumo, é função de uma tabela de BDS descreve as características do tipo-independente de ar-

I

-91- mazenamentode alto nível de uma transferência de dados de ou para um armazenamento de memória interna. A FIG. 12 é um desenho em como a configuração das entradas num BDS são armazenadas internamente. Muitas das entradas são posicionadamente "só-uma-vez" que se aplicam a todo o BDS. Outras entradas podem ser posicionadas para cada objecto listado no BDS. As se-tas descrevem ligações (1 para 11), mostrando, por exemplo, que cada BDS pode ter muitos OBJECTOS BDS. 0 significado de termos significantes na tabela BDS são descritos noutro lado nesta especificação.

Mais específicamente, o nivel dos blocos etiquetados "BDS" especificam entradas feitas uma.vez só para cada BDS. As setas que apontam das entradas do BDS indicam muitos OBJECTOS BDS que podem ser supridos em cada BDS. 0 nível da tabela BDS etiquetada "Objecto BDS" específica entradas feitas uma só vez para cada OBJECTO BDS. As setas que partem dos OBJECTOS BDS, indo para os CRITÉRIOS BDS, indicam

muitos critérios BDS que podem ser supridos com cada OBJECTO BDS. 0 nivel da Tabela do BDS etiquetada "Critérios BDS" es pecifica entradas feitas uma só vez para cada Critério BDS. 0 nivel de Tabela BDS etiquetado "Campo BDS" especifica entradas feitas uma só vez para cada campo BDS.

Com esta compreensão da Tabela BDS, o Processo de Transferência de Dados BDS, pode ser mais fácilmente compreendido. A FIG. 11 A visão global do processo de transferência de dados BDS mostrado na FIG. 9 será agora descrito com maior especificidade com referência à FIG. 11.

Referindo a FIG. 11, os blocos 904, 906 e 908 executam as funções como descritos acima, com respeito à fig. 9. 92-

0 Bloco 1110 indica que o controlo continua ao longo de um dos cinco caminhos, dependendo em qual dos cinco tipos de transferências forem determinadas no bloco 904. Embora o bloco 1110 indicasse que um só ramo é executado, uma tal centralização da lógica de ramificação não é necessária para implementar a invenção. Por exemplo, um caminho único principal pode ter uma série de testes individuais que se ramificam a funções tão específicas como as indicadas no bloco 1124, 1126, 1132 e 1144. Não é portanto uma caracte-rística da invenção a de centralizar o "ramo no tipo de transferência" na função, mas antes é apresentada como que para simplificar a exposição dos processos envolvidos. Trés nomes diferentes de blocos de tipos de transferência 1110, 1138 e 1160 estão presentes na FIG. 11. Os cinco tipos de transferências com significado de acordo com o encorporamento preferido são vantajosos os arranjados verticalmente sobre os ramos correspondentes para o mesmo tipo de transferência como que para facilitar a compreensão.

Referindo novamente ao ramo no bloco do tipo de transferência 1110, um dos cinco caminhos 1114, 1116, 1118, 1120 ou 1122 é seguido, dependendo do tipo de tranferência.

Se as três guardas (direcção, novos/adição, actualizar) não só actualizadas determinam que o tipo de transferência é "carregar" então o caminho 1114 é seguido. No encorporamento preferido o utilizador é aprontado para verificar que de facto quer ter todos os dados presentemente existentes na memória da U.C.P. destruidos por forma a que novos dados do tipo de armazenamento de dados externo possam ser carregados em seu lugar. (Se o utilizador não quer que os dados existentes sejam escritos por cima, então o controlo segue um caminho que obestará toda a transferência). Assumindo que o utilizador verifica a sua intensão de apagar todos os dados presentes na memória da U.C.P., o controlo segue um caminho 1125 para o "FORMATO LEITURA" em rotina presen- te na BDT.

Se as três guardas determinam que o tipo de transferência é "Intercalação","Actualização De" ou "Actualização Para", então o controlo passa pelas linhas 1116, 1118 ou 1120, respectivamente, para a rotina do "FORMATO DE LEITURA" 1134. Esta leitura de rotina será descrita em maior detalhe abaixo.

Se as três guardas determinam que o tipo de transferência é "ARMAZENAR" então o controlo passa ao longo do caminho 1122 para um bloco de decisão 1126. Basea do numa guarda de 3 vias chamada "estrutura pré-definida" o controlo passa ao longo de um dos 3 caminhos 1128, 1130 ou 1131, dependente em se uma estrutura Destino, Fonte ou Escantilhão, é para ser usada como estrutura externa "alvo".

Destino significa que a estrutura deve ser lida do ficheiro alvo existente, antes da transferên cia; Fonte significa a estrutura interna.

Em resumo, um ficheiro escantilhão é um ficheiro de dados ou ponte externa do mesmo tipo como reconhecido pelo BDT como uma estrutura que é usada (se DEST=ES-CANTILHÃO) para a nossa estrutura externa. O ficheiro Escantilhão é formado armazenando préviamente um ficheiro de dados, ou criar-se externamente. Se a estrutura pré-definida é dete£ minada pelo FICHEIRO ESCANTILHÃO, então o controlo passa ao longo da linha 1131 para a rotina de FORMATO DE LEITURA no BDT. A rotina de formato de leitura é executada para o ficheiro ESCANTILHÃO.

Se a estrutura pré-definida é determinada pela fonte, então a estrutura de dados interna de -finida pelo conteúdo da memória U.C.P. é usada. O controlo passa ao longo do caminho 1130, evitando a necessidade de cha mar a rotina de formato de leitura de BDT. -94-

Se á estrutura pré-definida é vi£ ta como sendo a estrutura destino, então o controlo passa pelo caminho 1128 para a rotina de FORMATO DE LEITURA NO BDT opera no ficheiro externo. Em resumo, o propósito da rotina de formato de leitura executado quer nos blocos 1132 ou 1134 é de terminar a estrutura que: é de se esperar na transferência entre o BDT e o tipo de armazenamento de dados externo. Os detalhes desta rotina de FORMATO DE LEITURA está dentro da capacidade de alguém hábil na matéria, dado um conhecimento do tipo particular de armazenamento de dados externos (ficheiro de tex_ to, ficheiro de bases de dados, ou ficheiros de ASCLI). Alguém hábil na matéria reconhecerá que as funções que a rotina de FORMATO DE LEITURA pode fazer incluir aprender que objectos estão disponíveis, que campos estão disponíveis para cada objecto e o tipo de campo. A rotina de FORMATO DE LEITURA providencia também ligações entre objectos.

Sem olhar se a rotina de FORMATO DE LEITURA no BDT foi executada em 1132 ou 1134, ou se foi ul_ trapassada ao longo do caminho 1130, o controlo eventualmente passa para o bloco 1136. O bloco 1136 envolve a produção pelo BDS (possivelmente com o auxílio de comandos interactivos de mais especificações para os objectos, campos e critérios de campos que são para filtrar dados indesejados de alcançar o destino. As especificações formadas no bloco 1136 podem ser pensadas como filtros suplementares de mais alto nivel nos dados que poderia de outra forma ser transferida sómente se a es trutura de transferência determinada no bloco 1135 possa mantida.

Em resumo, as especificações do BDS para objectos, campos e critérios de campos pode estar re sidente numa tabela de BDS. A tabela de BDS é, no encorpora -mento preferido, interactivamente modificável através da inte-racção do utilizador.

Uma tal tabela do BDS está indica, da em forma exemplar na Fig. 12. Tipicamente, conforme especjL ficado na tabela do BDS, o critério a ser aplicado com regras de filtro compreende um objecto ou campo seguido por uma rela ção (tal como = ,;>,<) seguido por seu lado por um valor. Um exemplo pode ser "nome-produto=comida de cão".

Se fossem estar as únicas especificações, então só esses objectos tendo um nome de produto de "comida de cão" seriam transferidos. Claro, podem-se juntar critérios diferentes usando lógica Booleana, de modo a que uma variedade de objectos de diferentes especificações podem ser transferidos, por exemplo, usando um corrector "ou" entre os diferentes critérios de especificações.

Existem várias opções para escolher quais os objectos a transferir, quais os campos a transferir e critérios de campos (limitando que registos são para serem transferidos).

As opções para objectos, registos e campos serão descritas a seguir. A opção todos permite que todos os objectos possiveis sejam transferidos (isto é, tudo entendido como ponte e formato destino). A opção só_ permite que sejam trans_ feridos só aqueles objectos pré-determinados que estão especificados na lista de OBJECTOS DO BDS. A opção de ESCOLHA permite ao uti lizador seleccionar )na altura de correr) objectos especifi -cos a serem transferidos. -96-

Registos

Para cada objecto escolhido, o en-corporamento preferido permite a determinação de que registos serão transferidos. Neste fim, um filtro actual de dados (tal como "igual a" ou "menos que") pode ser usado.

Na opção TODOS, todos os registos para um dado objecto podem ser transferidos. Isto é, efectiva-mente não são empregues filtros. A opção SÓ especifica de uma lista pré-determinada (a lista de critérios BDS) as condições do campo para inclusão na transferência. A opção ESCOLHA permite que o utilizador especifique as condições de campo na altura de correr.

Campos 0 encorporamento preferido permite também uma função semelhante de filtro a ser executada, usando as opções TODO, SÓ e ESCOLHA que são análogos ás usadas para filtros objectos e registos. Todos os campos, uma lista pré-determinada de campos ou uma especificação de campos escolhidos na altura de correr podem ser empregues. O sistema de tratamento de duplicados como acima descrito para registos é também aplicável a outros níveis num BDS. Por exemplo, os campos abaixo do nível de registo e os objectos acima do nivel de registo podem tam- bém ser tratados do mesmo modo como acima descrito.

Referindo de novo à FIG. 11 no

Bloco 1138 está outro ramo na decisão do tipo de transferência. Se a guarda direccional tem o valor IN, então o controlo passa ao longo de uma das linhas 1140, 1142 ou 1144, dependendo de se o tipo de transferência particular é carregar Intercalar, ou Actualizar De, respectivamente. Em qualquer um dos casos, a rotina de LEITURA DE DADOS é executada. A rotina de LEITURA de DADOS será descrita em maior detalhe abaixo, mas com respeito às FIG. 11B e 11B1.

Se a guarda direccional tem o valor OUT, então o controlo passa ao longo do caminho 1148 ou 1150, dependendo se o tipo de transferência é actualizar para ou armazenar respectivamente.

Se o tipo de transferência é Armazenar (Indicando-que os dados no armazenamento extremo são para ser apagados antes de serem transferida para a UCP), então a rotina de FORMATO de ESCRITA é executada em 1152.

A rotina de FORMATO DE ESCRITA 1152 está residente no BDT particular. A rotina de FORMATO DE ESCRITA pode ser codificada por alguém hábil na matéria, dado um conhecimento de armazenamento externo particular que está para ser o destino da transferência ARMAZENAR. São executadas funções complementares na rotina de FORMATO de ESCRITA 1132 como foram executadas na rotina de FORMATO de LEITURA 1132 ou 1134. Especificamente a estrutura de transferência que ocorre entre o BDT e o armazenamento externo é determinada aqui. Porque quaisquer dados préviamente existentes e a estrutura de dados acompanhantes foram primeiro apagadas na estrutura de dados de armazenamento externo, então a rotina de FORMATO DE ESCRITA força efectivamente a estrutura de dados para o destino. -98-

A rotina dè‘FORMATO de ESCRITA de acordo com o encorporamento preferido necessita saber do BDS quais os objectos a armazenar, que campos armazenar e o tipo de campos bem como os detalhes de ligações entre objectos. Isto é tudo dado à ROTINA DE FORMATO DE ESCRITA exacta-mente da mesma maneira como a rotina de FORMATO de LEITURA, é espesada de os devolver.

Nenhuma estrutura de dados externa i.deve ser posicionada se o tipo de transferência é ACTUALI_ ZAR PARA, de forma a que a rotina de FORMATO DE ESCRITA é ultrapassada nesse caso, como o controlo é passado pelo caminho 1148.

Independente se o tipo de.transferência Actualizar para ou Armazenar é invocado, o controlo passa para a rotina ESCRITA DE DADOS 1156. Neste bloco 1156, os dados são de facto transferidos da memória da U.C.P. para o armazenamento de dados destino. A rotina de escrita de dados é descrita abaixo com maior detalhe, com referência à FIG. 11A.

Quando a transferência de dados estiver completa (quer na memória da UCP pela rotina LEITURA DE DADOS 1154 ou fora da memória da UCP pela rotina de escrita de dados 1156), o controlo passa para a rotina de FECHO de BDT 958. A rotina de fecho do BDT funciona conforme acima descrito, com referência especial à FIG. 9.

Embora a transferência de dados propriamente esteja tecnicamente completa após terminada a rotina de FELHO do BDT, 958, algumas tarefas são vantajosamente executadas no caso de uma transferência para dentro da memória da U.C.P. 0 bloco 1160 é um ramo no bloco de decisão de tipo de transferência no qual a guarda de direcção tem o va- lor IN (indicando que o tipo de transferência deve ser quer Carregamento, Intercalação ou Actualizar De), então o controlo tem de passar ao longo do caminho 1162, 1164 ou 1166, res-pectivamente. Quando o controlo passa ao longo de um destes três caminhos, quaisquer campos com base em fórmulas (esses compostos de campos cujos valores estão definidos em termos de valores presentes noutros campos) são calculados no bloco 1172 prioritariamente ao processamento subsequente. Após os campos com base em fórmulas terem sido calculadas em 1172, o controlo passa para fora do Sistema de Dados em Lotes pela rotina de Transferência destes. Não é necessário qualquer cálculo de campos baseados em fórmula se a guarda de direcção tem o valor FORA. Nas transferências ACTUALIZAR PARA e ARMAZE__ NAR, o controlo passa directamente ao longo do caminho 1168 e 1170 respectivamente por sair da transferência de dados. O utilizados poderá continuar a sua secção interactiva, tendo a transferência de dados completa. a. A Rotina "ESCRITA DE DADOS".

Referindo a FIG. 11A, a rotina de ESCRITA DE DADOS é mostrada no formato de fluxo de dados. Man-tendo-se com o padrão estabelecido no fluxograma prévio nesta especificação, os blocos como em 11118, 11124 e 11126 são desenhados com linhas verticais duplas nos lados esquerdo e direito para indicar as funções que são executadas substancialmente dentro de BDT. As funções que são executados substancial mente dentro de BDS são mostrados sem linhas duplas nos lados esquerdo e direito. Como pode ser visto da FIG. 11A, o controlo é passado para trás e para a frente entre o BDS e o BDT mesmo internamente para o laço de "campo" concatenado dentro do laço de registo.

Quando a rotina de ESCRITA de ... DADOS é invocada, o controlo passa pelo caminho 11102 para o bloco 11104. No bloco 11104, o critério para um dado registo é verificada. Se qualquer dos critérios falha, esse registo é ignorado (não escrito). O controlo passa ao longo do caminho 11108 para a próxima aplicação do bloco 11104 para o registo de dados subsequentes. Se todos os critérios para o registo são satisfeitos, então o controlo passa pelo caminho 11110 sob um laço que opera em cada campo no registo. O campo é traduzido para o "tipo" (tal como inteiro, ponto flutuante e assim por diante) que corresponde ao tipo de campo dos campos destina. Se não por necessária qualquer tradução não ocorrem traduções no bloco 11112 e o controlo passa para o bloco 14.

No bloco U114, os dados num campo pertencente a um registo tendo passado todos os critérios é passado para a rotina ESCRITA de BDT para transferência.

Uma guarda de "primeiro registo" (ou quaisquer outros meios de comunicação quer seja a primeira passagem pelo laço de campo definido entre elementos 11112 e 11128) é passado para a rotina do BDT. Um bloco de decisão 11118, se este é determinado como sendo o primeiro registo na transferência, então a rotina INICIALIZAÇÃO para o novo registo é executada no BDT no bloco 11124 para o novo registo. Em resumo, a rotina de INICIALIZAÇÃO executa a função de inicia-lizar o BDT para uma transferência. (Por exemplo, um BDT de base de dados necessitaria de ser "aberto" antes de qualquer transferência ser executada).

Após a rotina de INICIALIZAÇÃO estãr completa (ou se não for necessária devido a não ser o primeiro registo), então o controlo passa do bloco 11124 ou directamente ao longo do caminho 11122 para o bloco 11126. O bloco 11126 representa a transferência actual dos valores dos campos da BDT para o armazenamento de dados externo. 0 laço definido pelos blocos 11112, 11128 e 11130 é repetido para cada campo dentro do registo.

Após a completação do laço de campo para o último campo no registo, o controlo passa pelo caminho 11134 para o bloco de decisão 11136. O bloco de decisão 11136 determina quando o último registo foi transferido. Enquanto houver mais registos para serem transferidos, o controlo passa de retorno ao longo do caminho 11138 para o bloco de verificação de critérios de registo 11104. Quando o último registo foi transferido, o controlo passa ao longo do caminho 11140 para sair da rotina de ESCRITA de DADOS.

Esta descrição da rotina de escrita de dados é feita uma escolha vantajosa de arranjos de campos nos registos. Este arranjo vantajoso tem-se mostrado eficaz no encorporamento preferido, nas variações aí podem ser feitas nem sair do âmbito Ida invenção. Por exemplo, o processamento sequencial de campos de diferentes registos está dentro da concepção da presente invenção, embora a eficiência no desenvolvimento e execução de encorporamento preferido dita a concatenação de laços de campo dentro do laço de registo. b. A rotina de "LEITURA de DADOS".

Referindo a FIG. 11B, a rotina de LEITURA de DADOS é ilustrado na forma de fluxograma.

Em resumo, muito à mesma maneira como a rotina de ESCRITA DE DADOS, a rotina de LEITURA de DADOS presente, compreende um laço concatenado num laço de registo . A rotina de LEITURA DE DADOS é invocada em 11202 e o controlo passa para o inicio do laço de registo para entrar o bloco 111204. O bloco 11104 passa o controlo para o BDT, onde o nome do objecto para o presente registo é determinado pelo armazenamento de dados externo. Este nome de objecto é passado para o BDS.

Após o controlo ser passado de novo para o BDS no bloco 11206, o objecto é verificado contra uma lista na Tabela do BDS de objectos requeridos. No bloco 11208, o controlo ramifica-se de acordo de se o objecto é requerido. Se o objecto não é requerido. Se o objecto não é requerido, o controlo passa ao longo do caminho 11210 e este registo é ignorado (não escrito). O máximo registo será então examinado, após o que o controlo passa ao longo pelo caminho 11260 para reentrar o topo do laço de registo em 11204.

Se um objecto é requerido uma comparação com as tabelas de BDS, então o controlo passa ao longo do caminho 11212 para o, registo, bloco de processamento de registo 11214. Básicamente, o bloco de processamento de registo pode envolver as alocações de espaço para o registo de entrada. Também uma rotina de pré-inserção (se alguma for necessária para este objecto) é executada. Tal rotina de pré-inserção pode envolver a atribuição de quaisquer valores por defeito ou procedimento análogo que estão na bibliotéca. Embora não explicitamente indicada na FIG. 11B, a transferência deste registo pode ser pasada neste ponto (e o controle devolvido ao bloco 11204) se, por exemplo, ocorre a condições que as rotinas de pré-processamento determinam que não é permitido mais carregamento desse objecto (por exemplo uma sessão DEMO de um programa permitindo não mais que um certo número de objectos a serem usados).

Assumindo que a transferência de dados não estivesse terminada no bloco de processamento de registo 11214, o controlo passa para o início de um laço de cam- po delimitado pelos blocos 11216 e 11250. '0 laço de campo 11216/11250 inicia-se pela rotina de BDT indo buscar o valor do campo de armazenamento externo em 11216. No bloco 11220, o valor do campo e o tipo de campo (tal como um inteiro, ponto flutuante e assim por diante) é determinado.

No bloco 11222, o campo é ramificado contra os critérios na Tabela do BDS. Os critérios do campo podem ser, se o preço (um campo) de um produto particular de consumo, um (objecto) é maior que um valor particular em dólares, ou se o campo de identificação do objecto é igual a "comida de cão" e assim por diante. Se o campo falha a verificação de critério, o controlo passa pelo bloco de decisão 11224 ao longo de caminho 11226 e o resto do registo é ignorado. Neste caso, o controlo passa então ao longo do caminho 11260 para reentrar pelo topo do laço de registo no bloco 11204.

Se o campo passa a verificação de critérios, então o controlo passa pelo bloco de decisão 11224 ao longo do comando 11228. Então o bloco 11230 determina se o campo é requerido internamente. Em resumo, um teste a se um campo é requerido internamente compreende a verificação de "que campo" entrada do OBJECTO BDS e então encontrá-lo na lista de CAMPOS de BDS.

Se o campo não é requerido internamente, então o controlo passa pelo bloco de decisão 11232 ao longo do caminho 11234 por forma a que o presente campo seja ignorado. 0 controlo pode assim ser devolvido ao topo do laço da campo no bloco 11216.

Se o campo é requerido internamente, então o controlo passa pelo bloco de decisão 11232 ao longo do caminho 11236. Então uma tradução de um tipo (inteiro, ponto flutuante e assim por diante) é executada no bloco 11238, se necessária. -104-

Então no bloco 11240, o valor ac-tual do campo é transferido da BDT pelo BDS para a memória da U.C.P. Após a tranferência actual estar completa, é determinado se um campo é um campo descritivo ou se o campo é uma ligação. Se o campo é uma ligação, então o controlo passa pelo bloco de decisão 11242 ao longo do caminho 11246 para o bloco 11248. 0 bloco 11248 adiciona a ligação é "árvore de família". Se o campo não é uma ligação, então o controlo passa pelo bloco de decisão 11242 ao longo do caminho 11244 para o fim do laço de campo em 11250. 0 Laço de campo definido pelo bloco 11216 e o bloco 11250 é processado uma vez para cada valor do campo no registo. Após o campo final ter sido processado, então o controlo passa do laço de campo pelo bloco de decisão 11250 para entrar na rotina de limpeza de fim de registo ' 11252. A rotina de limpeza EOR 11252 é descrita abaixo com maior detalhe, com respeito à fig. 11B1.

Após a rotina FDR de limpeza estar completa, o controlo passa para o bloco de decisão 11254, o bloco de decisão 11254 determina se existem mais registos a serme transferidos. Se há mais registos a serem transferidos, então o controlo passa ao longo do caminho 11258 para o topo do laço de registo no bloco 11204. Se não há mais registos a serem transferidos, o controlo passa ao longo do caminho 11262 para sais de rotina de LEITURA DE DADOS.

Em resumo, uma "arvore de família" é um traço da complexa hierarquia de um registo até ao topo da estrutura de dado por forma a poder ser ligado no ponto correcto. Referindo agora a FIG. 11B1, a rotina de limpeza de fim de registo (FDR LIMPEZA) 11252 (FIG. 11B) esta ilustrada. Embora a rotina de LIMPEZA DE FDR esteja ilustrada na FIG. 11B como sendo após o bloco de decisão 11250 que termina o laço de campo, é para ser compreendido que a rotina de poder ser colocada dentro do laço de campo num ramo que testou- -se a última ligação estava a ser processada; A rotina de LIMPEZA FDR está ilustrada fora do laço para efeito de clareza e simplicidade tanto quanto é executada após o campo final no registo ter sido processado. 0 controlo passa para a rotina de LIMPEZA FDR ao longo do caminho 112102 (FIG 11B1). No bloco de decisão 112104, o registo é verificado para ver se todos os critérios foram satisfeitos. Embora as verificações prévias de critérios possam ter sido encontradas no passado durante a interação do laço de campo na FIG. 11B, podendo restar critérios adicionais de teste para esta rotina de LIMPEZA FDR. Por exemplo, um teste que depende de uma função de todos os campos no registo não pode ser executada até todos os campos terem sido transferidos. Por exemplo uma função (ou é) terá talvez de ser aplicada a uma série de campos para determinar se algum deles (ou todos) possuem um certo valor. Claramente, neste exemplo, um critério de verificação multicampo poderia ter sido executado iterativamente no laço de campo 11216/11250 (FIG. 11B). O presente critério de verificação 112104 (FIG. 11B1) é apenas uma das várias variações no encor-poramento preferido que está dentro do âmbito da presente invenção .

Se o critério de verificação determina que certos critérios não são satisfeitos, então o controlo passa ao longo do caminho 112106, e o resto do presente registo é ignorado. 0 controlo passa ao longo dos caminhos 112158 e 112162 para re-entrar o laço de "registo" cujo fim está marcado pelo bloco 11254 (FIG. 11B).

Se o critério de verificação no bloco 112104 (FIG. 11B1) destermina que todos os critérios são satisfatórios, então o controlo passa ao longo do caminho 112108 para o bloco 112116. 0 bloco 11210 provoca o enchimento do espaço na árvore de família para ser cheio de acordo com quatro métodos prescritos na Tabela do BDS. Quatro métodos

I

X. -106- para preencher espaços da árvore de f amilia- jprovaram ser especialmente úteis em aplicações encontradas pelo encorporamen-to preferido. Esses métodos incluem o que se segue: CONTEXTO: Neste método, a posição actual do utilizador determina se, por exemplo, o objecto se adapta à árvore de familia tomando em conta a posição actual do utilizador no sistema. Por exemplo, se o utilizador está a visualizar uma gondola particular e o objecto de entrada é uma prateleira , o procedimento de CONTEXTO atribui o objecto prateleira à gondola que o utilizador está a visualizar. ORDEM: Neste procedimento, o registo mais recentemente transferido para o objecto requerido determina como deve ser preenchido a árvore de família com respeito ao registo actual. NENHUMA: Nesta opção, não se toma qualquer acção. Isto é, não são efectivamente preenchido espaços na árvore de família. CAÇA-TODOS (Sempre executada após um dos métodos anteriores): Se ainda falta informação na árvore de família, então, são criados parentes artificialmente com o nome "AUTO" por forma a ligar-lhe o registo de todo.

Qualquer que seja o método escolhido, o controlo passa ao longo de uma das linhas 112110, 112212, 112114 ou 112116 para o bloco 112118. No bloco 112118, os espaços não preenchidos pelos métodos acima, são preenchidos fazendo substitutos. Desta maneira, o registo é conectado até à estrutura de dados interna de uma forma temporária.

Em seguida, no bloco 112120, as "chaves" do registo são verificadas para assegurar que não se -107-

trata de um registo duplicado. (Conforme e bem entendido na matéria, uma"chave" é um conjunto de caracter a outros identificadores que identificam únicamente um item). Se o objecto é um duplicado, o controlo passa pelo bloco de decisão 112122 ao longo do caminho 112126. Se o presente registo não é um duplicado, então o controlo passa pelo bloco de decisão 11122 ao longo do caminho 112124. Se o registo original é um substituto, então o controlo passa pelo bloco de decisão 112128 ao longo do caminho 112130. O substituto é então escrito por cima no bloco 112124.

Se o registo original não é um substituto, então o controlo passa pelo bloco de decisão 112128 ao longo do caminho 11232 para o bloco de tratamento de duplicados 112136. O bloco de tratamento de duplicado 112136 funciona como se segue.

Os meior de tratar um registo que é um duplicado de um registo original é baseado numa escolha de uma variedade de métodos de tratar duplicados especificados de BDS. Quatro especificações de tratamento de duplicados que tiveram uma utilidade especial nas aplicações abrangidas pelo encorporamento preferido incluem o seguihte: ESCRITA-POR-CIMA: Um registo novo é copiado sobre o velho registo de forma a que mesmo, não modificados, (não duplicado) os campos, se perdem do registo original. ESCRITA-POR-CIMA DOS CAMPOS: Neste de tratamento de duplicados os campos transferidos de novos registos de entrada são copiados para os velhos campos. Este é a única escolha com todo o sentido para a "ACTUALIZAÇAO DE", como transferência. DEIXAR: O registo original é deixado intacto; o novo registo de entrada é ignorado. FAZER DUPLICADO: Neste método, de tratamento de duplicação as chaves dos novos registos são modificados dê modo a que não se trata de um duplicado do registo original.

Voltando a discussão do caso com-mum onde o registo de entrada não é um duplicado do registo existente no destino, o controlo passado do bloco de verificação de duplicados 112122 ao longo do caminho 112124.

Então, a guarda de actualização é verificada. Se a guarda de actualização tiver o valor "ACTUA-LIZAR", isto indica que todos os campos pré-existentes devem ser actualizados e o controlo passa ao longo do caminho 112152 por forma a que o presente registo (não um duplicado de um registo existente) seja ignorado. 0 controlo passa ao longo de caminho 112152, 112158 e 112162 para voltar ao fim do laço de registo (FIG. 11B) para que o próximo registo de entrada possa ser processado.

Se a guarda de ACTUALIZAÇAO for posicionada no valor "não só actualizar", então o controlo passa pelo bloco de decisão 112150 ao longo de 112154. Em todos os casos quando o registo de entrada fosse um duplicado de um registo existente, bem como em casos em que os registos de entrada não duplicativa fossem recebidos com uma guarda "não só actualizar", o controlo passa ao longo das respectivas linhas 112138, 112140, 112142, 112148 ou 112154 para o bloco 112146.

No bloco 112146, o novo registo é ligado à estrutura de dados interna de acordo com a informação na, agora completa, árvore de família. Após este novo registo ter sido conectado à estrutura de dados interna no bloco 112146.

Então o controlo passa ao longo do caminho 112162 para sair da rotina LIMPEZA FDR para alcançar o fim do laço do registo 109-

(FIG. 11B).

Desta forma, novos registos de entrada serão conectados à estrutura de dados interna em acumulação à medida que a transferência progride. IV. Sistema de Gestão de Espaço, Software Incorporado Ambiente Operativo.

Referindo à FIG. 13, está ilustrado um encorporamento preferido de um sistema de gestão de espaço de acordo com a presente invenção designado geralmente pelo número de referência 1302. O sistema preferido de gestão de espaço 1302 inclui um programa de aplicação de gestão de espaço 1304 e o Ambiente Operativo 102, conforme ilustrado e descrito acima com referência às FIGS. 1-12. O sistema de gestão de espaço preferido 1302 pode ser escrito em linguagem C, embora codificar noutras linguagens certamente está no âmbito da presente invenção. A combinação de programa de aplicação preferido de gestão de espaço 1304 e o Ambiente Operativo 102 facilita a concorrente execução de programas de aplicação adicionais com o programa de aplicações preferido de gestão de espaço 1304. Isto resulta da característica de agregação do Ambiente Operativo discutida em detalhe acima.

No sistema de gestão de espaço preferido, só os ficheiros de Mensagens são mantidos refasadas entre os programas de aplicação. Estas são lidas em separado porque, comoficheiros independentemente, permitem aos programas de aplicações de serem compreendidos numa variedade de -110-

linguagens.

Conforme mostrado na FIG. 13, o programa de aplicações de gestão de espaço preferido 1304 inclui um ficheiro de funções 1308 e um conjunto de ficheiros de apoio 1306.

Os ficheiros de apoio 1306 incluem um ficheiro de estruturas 1310, um ficheiro de menus 1312, um ficheiro de teclas 1314, um ficheiro de macro 1316 um ficheiro de acontecimentos 1317, um ficheiro de visualização 1318, um ficheiro de fonte de dados em lotes 1320 e um ficheiro de mensagens 1322. Um segundo programa de aplicações 1324 incluin do um conjunto de ficheiros de apoio 1326 é mostrado com o sistema de gestão de espaço 1302. 0 Ambiente Operativo 102 permite ao programa de aplicações preferido de gestão de espaço 1304 do sistema de gestão de espaço preferido de ser concorrentemente executado com o programa de aplicações 1324. Um ficheiro de estruturas incluso nos ficheiros de apoio 1326 de programa de aplicações 1324 está agregado com o ficheiro de estruturas 1310 para formar uma estrutura de dados comum. A formação de uma estrutura agregada é possível pelo Ambiente Operativo acima descrito.

Deve-se compreender que um grande número de outros programas de aplicações tais como o programa 1324 pode ser concorrentemente executado com o sistema de gestão de espaço 1302. O número máximo de programas de aplicações varia grandemente e é determinado de acordo com a dimensão da memória disponível do computador utilizado e com a dimensão de cada um dos programas de aplicações. O sistema de gestão de espaço preferido 1302 de acordo com a presente invenção providencia bastante flexibilidade usando vantajosamente as características

I I

-111- residentes no Ambiente Operativo 102. Assim, no sistema preferido de gestão de espaço 1302, é o Ambiente Operativo 102, que comparado com o programa de aplicações preferido de gestão de espaço 1304, que inclui muitas características de uso geral, tais como funções 124, macro 122 e fórmulas 138. A flexibilidade relevada permitida pelo sistema preferido de gestão de espaço pode ser alcançada adaptando funções de um programa de aplicações conhecido quer nos programas de aplicações 1304 ou o Ambiente Operativo 102. Vantajosamente, as funções adicionadas ao ambiente operativo 102 não são específicos de aplicação, mas são geralmente úteis com vários outros programas de aplicações também.

Uma vantagem de armazenamento funções genérica do tipo utilitário no Ambiente Operativo 102 é para evitar as duplicações em vários outros programas de aplicações e de usar eficazmente o Ambiente Operativo 102. As funções específicas à gestão de espaço são armazenadas nas funções 1308 no programa de aplicações 1304. O critério preferido usado para determinar a colocação óptima de uma função particular é se a função é uma específica da gestão de espaço.

Por exemplo, se um esquema conhecido de relatório permite por um valor em campo específico de parâmetros de produto em relatórios, ou gerar subtotais, são necessárias funções específicas internas que providenciam estes esquemas de relatório.

As características equivalentes no sistema de gestão de espaço preferido 1302 está no sistema de visualização 114 residente no Ambiente Operativo 102. Esta função de Visualização tem muito mais flexibilidade no sistema de gestão de espaço preferido 1302 do que nas funções de relatório de sistemas conhecidos. Há significativamente mais opções disponíveis com o sistema de gestão de espaço preferido -112-

com a função de Visualização.

Por exemplo o sistema de gestão de espaço preferido 1302 não está limitado a relatórios respeitantes a produtos, pode antes gerar relatórios ao nivel do armazém, listando gondolas e secções) e pode adicionar campos definidos pelo utilizador construidos por fórmulas e outras opções seleccionadas pelo utilizador.

Contudo, o sistema preferido de gestão de espaço 1302 está vantajosamente arranjado para ser usado pelos utilizadores de programas de aplicações existentes sem serem confundidos pela sua flexibilidade dramáticamente aumentada. Num encorporamento, é critério de concepção de facto limitar a flexibilidade externa aparente do Ambiente Operativo 102 assim o utilizador não estaria sobrecarregado com o número de opções disponíveis. Esta limitação da aparência da flexibilidade é melhor atingida usando as caracterís-ticas de Ambiente Operativo para limitar as opções disponíveis. O Ambiente Operativo 102 é preferivelmente arranjado a tal ponto que os nomes dos campos são armazenados em ficheiros de estruturas e os dados são armazenados em ficheiros de dados separados.

Em programas de Aplicações conhecidos, o utilizador tem normalmente a capacidade de modificar os ficheiros de dados. Em contraste, no sistema de gestão de espaço preferido 1302, o utilizador pode modificar a estrutura de dados modificandoe adicionando objectos e campos no ficheiro de estruturas 1310. O Ambiente Operativo 102 mantém ..os ficheiros de estruturas com os nomes de campos separados dos dados. Esta é uma vantagem distinta sobre os sistemas conhecidos, nos quais os nomes de campos eram armazenados com os campos. Assim, para facilitar a clientelização pelo utilizador do sistema preferido de gestão de espaço. Ambiente Operativo permite ao utilizador de modificar os ficheiros de estru- 113-

turas. 0 programa de aplicações preferido de gestão de espaço 1304 inclui o Ficheiro de Funções 1308 que consiste de uma pluralidade de funções separadas ou módulos de funções que podem ser ligadas em conjunto. Os Ficheiros de Suporte 1306 são lidos pelo Ambiente Operativo 102 da mesma maneira, sensivelmente que os ficheiros de dados.

Os Ficheiros de Dados preferidos 1306 compreendem vários grupos de ficheiros dispostos como se segue. O Ficheiro de estruturas 1310 implementa ou define uma estrutura de dados tal como ilustrada nas FIGS. 14A. ou 14B.

Os menus 1312, teclados 1314, macros 1316, são armazenados no mesmo ficheiro no encorporamento preferido; contudo, poderiam ser escritos em ficheiros separados. As Macros 1316 não outra maneira de especificar código executável que também pode ser modificado pelo utilizador. Os acontecimentos 1317 são usados para funções específicas às funções de gestão de espaço. A Visualização 1318 controla como serão écrans, incluindo como desenhos algo em gráficos. As Fontes de Dados em Lote 1320 não espacíficas do programa de aplicações de gestão de espaço para especificas as regras lógicas de fluir dados para dentro e para fora de bases de dados externos. As BDS 1320 determinam a que informação se deseja aceder. As Mensagens 1322 são essencialmente curtos programas que providenciam dados para várias funções do Ambiente Operatório 102. Estas funções podem estar residentes no Ambiente Operativo 102 quando não podem ser específicas do sistema de gestão de espaço preferido 1302 ou de outra forma residir no programa de gestão de espaço preferido 1304. As Mensagens são acedidas pelos seus números associados para poderem trabalhar em diferentes paises; permitem especificar certas palavras por número em areas separadas; os nomes podem ser traduzidos e o sistema correrá da mesma maneira.

I

0 bloco de Funções 1308 consiste de funções específicas ao programa de aplicações preferido de gestão de espaço. Por exemplo, "o enchimento proporcional" é uma função de comando para encher uma prateleira para manter todos os produtos na prateleira em proporções. As funções predeterminadas no bloco de Função 1308 podem compreender cerca de 75% do programa de gestão de espaço preferido 1304, embora diferentemente indicado na Fig. 13.

Os programas de aplicações conhecidas de gestão de espaço podem geralmente ser vistos como um congelamento de função e blocos de suporte intermisturado de tal modo que não há flexibilidade em clientelizar o programa para utilizadores. Por exemplo a estrutura de menu pode não ser modificada pelos não programadores porque está incorporada em código executável. Virtualmente todas as modificações requeriam indivíduos com o nível de habilidade de programadores de computadores para cuodificar o código todo de programa de aplicações para fazer modificações. Em contraste, o sistema de gestão de espaço preferido 1302 providencia vários níveis de clientelização que podem ser conseguidos pelo utilizadores sem necessitar de conhecimentos de programador de computador, descrito abaixo com respeito às FIGS. 15A e 15Β.

Uma característica significativa é que o Ambiente Operativo 102 permite ao programa de aplca-ções preferido de gestão de espaço 1304 e outros programas de aplicações tais como o 1324 de serem desenvolvidos independentemente e depois integrados pelo Ambiente Operativo 102 para correr concorrentemente. Assim, para o utilizador, os novos programas tais como o 1324 aparecerão como uma parte integrada do sistema de gestão de espaço preferido 1302.

As FIGS. 14A e 14B ilustram de forma esquemática (análogamente à FIG. 2) ficheiros de estruturas de dados exemplares que podem ser empregues no ficheiro de estruturas 1310 do sistema de gestão de espaço preferido -115-

1302 de acordo com a presente invenção.

Diferentes versões de sistema de gestão de espaço podem ser definidas que são mais complexas que qualquer sessão existente no mercado. Esta escolha de um sistema de gestão de espaço permite a alguém de utilizar todas as características, a flexibilidade e as vantagens do Ambiente Operativo. Alguns programas de Aplicações podem ter, por exemplo, seis objectos (como mostra a FIG 2). Uma sessão do sistema de gestão de espaço preferido tem apróximadamente 15 objectivos (ver FIG. 14A) que poderão ser de mais para um utilizador lidas eficazmente. A estrutura de sistema de gestão de espaço pode ser muito mais complexo que a mostrada na FIG. 2.Contudo, lista de esta complexidade adicional torna bastante mais difícil tomas de código de programas de aplicações conhecidas e converte-las em programas que usem de toda a flexibilidade permitida podendo muito do funcionamento do Ambiente Operativo 102. Uma estrutura simplificada, tal como a mostrada na FIG. 14B é desejável em casos onde é permitida menor complexidade ou os orçamentos de desenvolvimento de software são limitadas. Uma tal estrutura inclui um núcleo de objectos que modelam efectivamente a estrutura de dados de programas de aplicações conhecidas tendo estruturas em código-duro por forma a que as funções dos sistemas conhecidos possam de imediato ser incorporados no programa de aplicações 1304 enquanto usam a flexibilidade permitida pela concepção em conjunto com o Ambiente Operativo.

Um sistema de gestão de espaço funcional 1302 usa a estrutura mostrada na FIG. 14B. (Uma diferença entre a FIG. 2 e a FIG. 14B, contudo, é que o termo "gondola" foi modificado para "secção" e "prateleira" pois modificado para "fixos" ou "elementos fixos"). O último é mais representativo das capacidades do sistema de gestão de espaço corrente preferido, o qual tem adicionada a capacidade de con- siderar prateleira divisórias, portões, vecLações e assim por diante.

Uma razão para adicionar objectos à estrutura é das classificações diferentes a coisas diferentes. Por exemplo, secções múltiplas um armazém são realmente agrupadas por gondolas, que por seu turno compreendera conjuntos de prateleiras em cada lado de uma ala; um departamento pode ter, por exemplo, 6 alas; múltiplos departamentos podem fazer um armazém. As gondolas as prateleiras, os departamentos e assim por diante, são apenas outras maneiras de agrupar em secções. Não há necessidade de os ter como objectos separados: podem ser definidos como campos sob a "secção" objecto. A biblioteca (na FIG. 14B)'é um objecto separado usada para suportar listas separadas de outros objectos usados noutras sítios na estrutura. Geralmente, a Biblioteca permite o armazenamento e a selecção de uma colec ção de objectos interrelacionados em certos niveis da estrutura (prateleiras por exemplo). A biblioteca usa o facto de que a estrutura do sistema de gestão de espaço preferido pode-lhe ser adicionado. 0 benefício para o utilizador é poder ter uma lista separada em memória de conjuntos armazenados de partes fixas que podem ser usados novamente. Os sistemas conhecidos podem não ter uma base de dados externa para as prateleiras e não ter uma biblioteca para armazenar listas de prateleiras, de modo a que não existia flexibilidade para adicionar ou modificar requesitos de espaço e representações.

No sistema de gestão de espaço preferido, uma transferência BDS pode ser feita de uma biblioteca de prateleira exterior ao sistema para uma biblioteca interna de prateleiras; ou as partes fixas na área de trabalho podem ser a actualizada da biblioteca externa. Clientes fixos adicionais podem ser copiados para a biblioteca de prateleiras

Existe um mercado inteiro para os especialistas de sistemas de gestão de espaço preferidos. Um especialista elebora a fixas adicionando prateleiras específicas e divisórias, um comerciante usa um programa de aplicações de gestão de espaço para adicionar produtos aos fixos. Actual-mente, em organizações comerciais de grande envergadura os dois departamentos estão inteiramente separados e há só uma comunicação limitada entre ambos. Em concordância com o sistema de gestão de espaço preferido, o especialista de fixar pode agora usar o sistema de gestão de espaço preferido para adicionar produtos directamente baseado em informações dadas pelo comerciante. 0 especialista de fixos pode usar o mesmo software para ambas as tarefas; haverá portanto maior interacção entre departamentos. Isto é uma nova possibilidade disponivel para os utilizadores do sistemas de gestão de espaço preferido o qual não está disponível se forem empregues sistemas conhecidos . A operação do sistema de gestão de gestão de espaço preferido será agora descrita.

Na inicialização, o Ambiente Operativo 102 compila uma lista em ficheiro de programas de aplicações disponíveis que inclui o programa de aplicações de gestão de espaço. Para cada programa de aplicações, o Ambiente Operativo 102 lê todos os Ficheiros de Funções incluindo as FUNÇÕES 1308 para a memória Ambiente Operativo assim telas-à imediatamente disponiveis para a execução, em aditamento a funções que estão residentes ao Ambiente Operativo 102.

Após as Funões e os Ficheiros de Suporte Terem sido lidos para o Ambiente Operativo 102, é lido um primeiro visor para estampar o primeiro écran o que é aparente para o utilizador.

Este primeiro écran estampado, é o menu principal para i sistema de gestão do espaço 1302 mos- trado abaixo na tabela III.

As funções são seleccionadas por entradas do utilizador por teclas pré-determinadas ou entradas de menus. Algumas chaves não têm funções associadas com elas; em vez disso, têm menus associados com elas. Quando é pressionado este tipo de chave é pressionado o Ambiente Operativo estampa o meno particular (conforme foi armazenado no ficheiro de Menus no programa de aplicações do sistema de gestão de espaço preferido). As entradas para os menus poder dar referência a função ou a outros menus. Por exemplo, o menu principal contêm a palavra "ANALISE", que por seu lado chama o menu ANALISE para mostrar. Então, o menu ANALISE contém o termo "PREENCHIMENTO PROPORCIONAL" com um número da função associado. Quando algum número de função é activado, o sistema chama a função particular da localização na melhoria no Ambiente Operativo 102 ou fora do bloco de Funções 1308 do programa de aplicações do sistema de gestão de espaço preferido.

Após a tomada de controlo da função do programa de aplicações de gestão de espaço, executa as operações necessárias. Assim, para a, função "preenchimento proporcional" dentro do sistema de gestão de espaço preferido, o sistema de gestão de espaço preferido olha para a prateleira designada pelo utilizador (por exemplo pelo posicionamento do cursor) e faz um número de cálculos para determinar como há-de preencher o espaço vazio na prateleira. Quando a função estiver completa, o sistema de gestão de espaço preferido devolve o controlo para o Ambiente Operativo com um código de retorno o qual é interpretado pelo Ambiente Operativo para provocar a execução da próxima função.

No caso do "preenchimento proporcional" , esta próxima função será redesenhada no écran baseado em novos cálculos. Em resumo, o Ambiente Operativo olha para a entrada do utilizador e correlaciona esse imput com as várias funções no sistema de gestão de espaço preferido. -119-

As funções ter origem no Ambiente Operativo 102, propriamente, ou no ficheiro de FUNÇÕES 1308 do programa de aplicações 1304, de gestão de espaço. Quando a função estiver completa, o Ambiente Operativo então executa as funções para estampagem em indicar ao utilizador um resultado da execução da função completa.

Algumas das funções invocadas pelo utilizador são algumas das executadas directamente pelo Ambiente Operativo 102 e nunca utilizam as funções 1308 do pro-gama de aplicações do sistema de gestão de espaço 1304. Por exemplo uma função zoom ent/saída está residente no Ambiente Operativo 102; outras funções igualmente residentes estão listadas em baixo na Tabela I. Da mesma maneira como as funções 1308 internas ao programa de aplicações de gestão de espaço 1304, quando a execução da função residente do Ambiente Operativo estiver completa, o controlo é devolvido à parte principal do Ambiente Operativo com um código apropriado (chamado código de retorno) para indicar ao utilizador o resultado da operação (por exemplo para a função de zoom, o código ordenaria ao Ambiente Operativo para redesenhar o écran).

No programa de aplicações, do sistema de gestão de espaço preferido, 1304, os ficheiros de suporte 1306 são ficheiros ASCII legiceis e editáveis.

Os ficheiros de suporte 1306 podem ser editados por alguém com conhecimentos no campo de aplicações. As funções de edição dcs ficheiros de suporte no Ambiente Operativo 102 permite a uma pessoa editar os ficheiros na forma normal na qual o Ambiente Operativo é editado.

Por contraste nos sistemas conhecidos, virtualmente todos os equivalentes aos ficheiros 1306 do sistema de gestão de espaço não fixos no contexto de todo o código executável em geral. -120

A e‘strutura ;dé dados é em código duro dentro do código executável na linguaaem de programação de computador. A estrutura pode ser incorporada em ficheiros codigo fonte (por exemplo, a linguagem de programações C).

Assim, a estrutura não pode ser modificada, a naõ ser com uma pessoa com o nivel de um programador de computadores. A única maneira de fazer alterações a outras características tais como menus requere um programador que conheca a linguagem de programação e o programa específico.

Geralmente, é possivel adaptar código de programas de aplicações para serem usados com o Ambiente Operativo 102. Os utilizadores de sistemas conhecidos que se estiverem a familiarizar com o sistema de gestão de espaço preferido poderão utilizar muitas das mesmas funções às quais estão acustomados. Uma vantagem principal de usarem o sistema de gestão de espaço preferido é que o sistema de gestão de espaço preferido é mais fácilmente assimilável conforme são escritas novas funções ou versões. A modularidade do sistema de gestão de espaço preferido permite ser assimilável sem eliminar funções correntes para as quais o cliente se auto-treinou a usar. Por exemplo, a função de "preenchimento proporcional" pode ser retida, incluindo o seu uso via menu. Se uma função de preenchimento proporcionar nova ou de melhor tipo se torna disponível, pode ser atribuída ao novo programa de aplicação, e pode-se fazê-lo aparecer com outro ficheiro de menu no menu de Análise sob um nome diferente, dando assim ao utilizador a opção de dois tipos de funções de preenchimento proporcional. Assim, novas funções e objectos podem ser adicionados muito fácilmente em qualquer altura sem diminuir a utilidade (ou alterar o aspecto e sensibilidade) de outras versões anteriores

Conforme acima descrita uma vantagem do sistema de gestão de espaço 1302 sobre os sistemas conhecidos é o posicionamento das características em ficheiros discretos os quais podem ser fácilmente .editados por qualquer um no campo das aplicações. A separação das características em unidades discretas e fácilmente modificáveis também o tornam subtancialmente mais de de comercializar o produto para clientes individuais e, ou para uso em diferentes países. Esta facilidade de comercialização permite aos não-programadores de fazer modificações necessárias ou desejáveis. Porque os programadores não sabem de mercado de retalho (ou outro campo respeitante ou utilizador de programas de aplicações de gestão de espaço) e porque as pessoas conhecedoras do comércio geralmente não sabem como programar computadores, existe geralmente uma falta de capacidade de comunicar entre ambos. 0 sistema de gestão de espaço preferido permite aos conhecedores de comércio que não sejam programadores de fazerem as modificações que sentem necessárias para apresentarem a saida apropriada ao utilizador ou outro cliente.

Referindo as Figs. 15A-15B, a operação de clientalização interactiva do utilizador do sistema de gestão de espaço 1302 serão agora descritas com referência aos fluxogramas Referindo primeiro a Fig. 15A, as operações sequenciais de clientelização do sistema 1302 inicia-se em resposta a uma selecção de clientelização recebida do utilizador indicada no bloco 1500. O utilizador pode entrar esta selecção de clientelização por uma relação de submenu conforme listada na Tabela III abaixo do primeiro menu o qual é primeiro apresentado ao utilizador na inicialização (538 da FIG. 5.) e está disponível para o utilizador durante a correr a uma tecla de entrada definida.

Uma nova entrada do utilizador é recebida como indicado no bloco 1502. A próxima entrada do utilizador é identificada como uma de uma pluralidade de características possíveis para serem clientelizados, por exemplo, tal como, uma edição de menu indicada no bloco 1504, uma edição de tecla indicada no bloco 1506", uma edição de macro indicada num bloco 1508, um editor de visualização indicado um bloco 1510 em uma adição de uma FONTE de DADOS em Lotus indicada ura bloco 1512. As características adicionais não mostradas na FIG. 15A podem ser clientelizadas tal como os dispositivos de entrada e de saída.

Uma lista correspondente é então mostrada para o utilizador a selecção identificadora do utilizador conjuntamente com quaisquer mensagens de ajuda prontas, num bloco 1514.

Uma próxima entrada de nivel de relação é recebida e indicada num bloco 1516 e corresponde a uma modificação seleccionada tal como para modificar uma ca-racterística existente ou adicionar uma nova característica.

Então o utilizador entre os pro-gâmatros particulares para a modificação para a característica existente ou para uma nova característica que é recebida pelo sistema 1302 indicada no bloco 1518. As mensagens de auxílio ao utilizador podem ser estampadas a cada passo tal como com o bloco 1518 para receber parâmetros seleccionados para a característica relaccionada, tal como uma do menu exemplar, teclas, macros, visualização ou Fonte de Dados em Lotes como indicado nos blocos 1504 1506, 1508 e 1510.

Uma tecla pré-determinada é então pressionada indicada um bloco 1520 para voltar à entrada a nivel do utilizador um bloco 1516 por forma a continuar as operação de clientelização ou é pressionada outra tecla para voltar às operações normais do sistema a correr indicado um bloco 1522. As operações no sistema a correr estão ilustradas e descritas com referência à FIG. 5C acima.

Um exemplo de um processo de clien telizaçao, quando a adição do menu é identificada como selec- ção do utilizador no bloco 1504, pode ser.adicionado uma entrada adicional a um menu existente pelo utilizador ao selec-cionar um menu particular. Então uma posição no menu particular seleccionado mostrado no bloco 1514, é seleccionada.

Então uma tecla pré-determinada é pressionada pelo utilizador para adicionar uma nova entrada de menu vazio uma posição seleccionada do menu no bloco 1516. Quando a entrada de menu corresponde a uma função então o correspondente número de função, tal como 1219 é entrado pelo utilizador no bloco 1518. De outra forma, quando a nova entrada do menu corresponde quer a uma macro ou a um submenu a ser acedido, então o correspondente nome de macro ou do submenu, tal como uma etiqueta ou um número, é entrado pelo utilizador no bloco 1518. Alternadamente, após terem sido seleccionados o menu particular e a posição particular no menu, uma entrada de menu particular existente, pode ser modificada ou anulada usando outras teclas pré-determinadas no bloco 1518.

Um novo menu pode ser adicionado seguindo uma relação correspondente a um novo nivel de menu no bloco 1516.

Todos os parâmetros de dados desejáveis incluindo entradas de menus múltiplos são então recebidos no bloco 1518. Referindo agora a FIG. 15B, um fluxograma é mostrado ilustrando as operações do sistema de gestão 1302 para clientelizar um ficheiro de estruturas, tal como o ficheiro de estruturas 1310 do programa de aplicações de gestão de espaço 1304.

As operações sequenciais iniciam--se indicadas no bloco 1530 com um comando de início pré-determinado para o sistema de gestão de espaço 1302. Uma entrada de selecção de ficheiro de estrutura pelo utilizador é recebido como indicado no bloco 1532. O ficheiro de estruturas seleccionado é carregado indicado no bloco 1534 e um lista de -124- - /

objectos para o ficheiro de estruturas s«leecionado é mostrado indicado um bloco 1536. A selecção de clientelização se-leccionada pelo utilizador, tal como a de adicionar um campo a um objecto existente ou de outro modo modificar o ficheiro de estruturas seleccionadas, tal como adicionar um novo objecto à estrutura seleccionada é recebida indicado no bloco 1538. Uma selecção do utilizador para modificar um objecto existente é identificada, indicado no um bloco 1540. Uma selecção do utilizador para adicionar um objecto existente é identificado indicado um bloco 1542.

Após a selecção para modificar um objecto existente ser identificada no bloco 1540, então as adições seleccionadas e as modificações nos campos para os objectos seleccionados no ficheiro de estruturas de ser recebidas e indicadas no bloco 1544. Análogamente, após a selecção para adicionar um objecto ser identificada no bloco 1542, então a descrição do novo objecto no ficheiro de estruturas é recebida e indicada num bloco 1546. A descrição do novo objecto inclui informação providenciada pela selecção do utilizador tal como um nome e múltiplos campos e ligações, foram arranjadas num ficheiro de estruturas tal como as mostradas no seguin te APENDICE A.

Após os detalhes serem recebidos nos blocos 1544 e 1546 então o novo ficheiro de estruturas resultante é armazenado indicado um bloco 1548. Então o sistema 1302 pode ser reiniciado indicado um bloco 1550 por forma a carregar e agregar o novo ficheiro de estruturas como ilustrado e acima descrito com respeito à FIG. 5.

Durante cada um dos passos sequenciais para clientelizar qualquer característica ou ficheiro de estruturas, texto exemplificativo e mensagens de auxílio genérico podem ser mostradas ao utilizador. A operação do. Sistema de Dados em Lotes com respeito ao sistema de gestão de espaço preferido 1302 será agora descrito. Conforme acima descrito, o sistema de gestão de espaço preferido, 1302, contém uma pluralidade de ficheiros de dados. O sistema de gestão de espaço usa informação ou dados destes ficheiros de dados e de bases de dado de fora (por exemplo, ficheiro de bases de dados e de texto). 0 sistema de Dados em Lotes facilita as transferências de dados de e para o sistema de gestão de espaço preferido 1302. As fontes de dados em lotes 1320 incluem informações que é independentemente do dispositivo lógico (tipo de armazenamento de dados) envolvida. A informação de BDS respeita a especificações para uma transferência de dados. (Por exemplo, o BDS determina com que objectos lidar; quer lidando com uma lista de produtos ou uma lista prateleiras ou múltiplos objectos; a assim por diante). 0 BDS está configurado para permitir ao utilizador escolher os campos (por exemplo, o objecto ser um "produto" e o campo de interesse seria "movimento") e permite lidar com duplicados. O BDS 1320 providencia critérios para os parâmetros dentro dos campos e dos objectos (por exemplo, produtos com um movimento superior a 100).

Em resumo, o BDS 1320 no sistema de gestão de espaço preferido 1320 contém regras para as trans ferências de dados, mas nada específico ao tipo de armazenamento actual que está a ser lido de ou a ser escrito. (Esta comunicação específica de dispositivo é lidada pelo BDT ou "Tipo de Dados", acima descrito).

As regras do BDS podem ser pré--estabelecidas ou podem ser entradas pelo utilizador. Para cada objecto transferido de umBDT, quatro elementos não especificados incluindo nome de campo, relacionamento, valor e agrupamento. 0 nome de campo e o nome de um agrupamento de objecto particular (por exemplo, "fabricante"). A relação é a relação lógica (por exemplo, =,<,;>, =< , =>, etc). 0 valor é qualquer valor fixo (por exemplo, "XYZ Companhia"). Finalmente o agrupamento liga critério múltiplos (por exemplo, "e" ou"ou"). Assim, um item de dados requerido de um BDT poderia ser: Na XYZ Companhia, os produtos que custam >$10.00 e que custam ,£20.00.

Para tornar em conta o facto que bases de dados diferentes usarão provávelmente termos diferentes para o mesmo campo ou objecto, uma "Lista de Sinónimos" ou "Conjuntos de Tesoararia" pode ser construída nos BDS.

Cada Lista de Sinónimos é específica de um BDS. Os BDS fazem parte da estrutura do programa de aplicações. Se um novo campo é adicionado ao ficheiro de estruturas do sistema de gestão de espaço preferido, será necessário adicionar o mesmo campo a cada Lista de Sinónimos em cada BDS.

Em cada BDS há interruptores in-teractivos. Se o interruptor interactivo apropriado estiver ligado (por exemplo, o interuptor interactivo de relação de campo), o utilizador verá todos os campos possíveis de selec-cionar. Vantajosamente se o desejar, os campos pré-seleccio-nados poderão ser mostrados numa cor (por exemplo vermelho) e os restantes campos mostrados numa segunda cor (preto por exemplo). A lista de campos compreende todos os campos disponíveis na intersecção de campos disponíveis no BDS e do (BDT) Tipo de Dados em Lotes. Por outras palavras, a lista de campos disponíveis compreende todos os campos da base de dados no (BDT) que podem ser lidos pelo sistema de gestão de espaço preferido (i.e. aqueles campos listados no ficheiro de Estruturas do sistema de gestão de espaço preferido) Os sinónimos são usados para que de outro modo os nomes de campos não reconhecidos na ponte externa sejam reconhecidos

-12 7- por forma a poderem ser ligados a nome campo conhecido pela Lista de Sinónimos.

Se o interruptor interactivo estiver desligado, não há interacção do utilizador; as selecções de campo e as transferências ocorrem automáticamente baseadas em estabelecimentos prévios. 0 pré-estabelecimento de campos é uma das numerosas características de clientelização na combinação do programa de aplicações de gestão de espaço preferido 1304 e do Ambiente Operativo 102. Cada BDS terá talvez certamente mais do que um interruptor interactivo, para seleccio-nar campos específicos para cada objecto, para fazer critério de selecção interactivos (por exemplo, mpg=CompanhicL ABC, mo-viment. <,100, ou uma combinação de critérios usando o

TABELA I

Resumo das capacidades do Sistema de Gestão de espaço preferi-do O sistema de gestão de espaço preferido pode ser considerado como um produto só, tanto como aparece ao utilizador como um só programa de computador executável contudo como descrito acima, o sistema de gestão de espaço preferido é de facto em duas partes—O programa de aplicações e o Ambiente Operativo. 0 programa operando básicamente (Isto é, o Ambiente Operativo) detém dados (tais como dados do planograma) uma estrutura de base de dados em memória, e

I

-128- permite o acesso do utilizador aos dados quer através de tabelas e entradas por écran ou por uma interacção num tipo de gráfico a 3 dimensões. 0 programa de aplicações preferido lida sd com as funções específicas da aplicação, tal como aloca-ções e preenchimento proporcional e também especifica a estrutura de dados e outra informação da configuração. 0 Ambiente Operativo: A seguinte descrição de Ambiente Operativo suplementa as descrições acima, relacionadas com o Ambiente Operativo considerado como uma entidade separada de qualquer programa de aplicações particular. Aqui, o Ambiente Operativo é descrito com especial referência ao seu uso como plataforma para o sistema de gestão de espaço preferido. Deve-se compreender que o Ambiente Operativo é especialmente concebido para ser uma "plataforma" (isto é, um "Ambiente Operativo") não só para o sistema de gestão de espaço, mas para qualquer outro número de programas de aplicações. 1. Estrutura de dados. Quando iniciado, o Ambiente Operativo inspecciona um ficheiro de dados fornecido pelo programa de aplicações que descreve a sua estrutura. 0 ficheiro descreve objectos particulares tais como GONDOLAS, PRATELEIRAS e PRODUTOS dando os seus campos (por exemplo, IDENTIFICAÇÃO, PREÇO, LARGURA) e também como estão relacionados (por exemplo, a GON-DOLA tem muitas prateleiras, as PRATELEIRAS têm muitas.(ou posições). 2. Mapas. Cada objecto e todos os seus campos podem ser tornados visiveis ao utilizador numa lista tabular denominada mapa. Por exemplo, existe um mapa no sistema preferido de gestão de espaço para descrever os produtos de consumo e os atributos que estão armazenados nos seus campos. Os dados visiveis nestes mapas são editáveis. Também é fornecido um conjunto de formatos diferentes (chamado um visor) para representação

gráfica de objectos e os seus campos. Estes visores podem ser fixos, de edição antecipada ou editáveis durante a execução de programa. Os visores podem especificar totais no écran e informação em título e podem também ordenar préviamente os dados por campos específicos. 3. Entradas por écran. Bem como descrever formatos para mapas, os visores podem igualmente definir entradas por écran. Por exemplo, onde em vez de um registo (por exemplo, um produto de consumo) tomar apenas uma linha no écran, um registo ser preparado para tomar todo o écran com os seus campos de dados. 4. Sistema gráfico. Qualquer mapa pode também ser mostrado gráficamente e a representação gráfica pode ser visualizada de qualquer ângulo. Os objectos podem ser movidos livremente em gráficos quer com as setas das teclas ou, por exemplo, com um rato. 5. Menus e comandos. A entrada pode ser conseguida, por exemplo, através de menus ou por comandos directos de teclas. Por exemplo, uma tecla começa uma operação particular, onde a operação pode ser uma avaliação complexa ou pode ser simplesmente movimentar o cursor. Os menus e as listas de comandos por teclas são fornacidos pelo programa de aplicações e são também editáveis antes e durante o programa. 6. Programas de aplicação. Quando iniciado, o Ambiente Operativo carrega a estrutura de dados, os menus, as comandos, os visores e assim por diante, de programa de aplicações de gestão de espaço. 0 Ambiente Operativo carregará também as funções do programa de aplicações de gestão de espaço na memória por forma a que possam ser corridos conforme necessário durante a execução do programa tão rápidamente como se o programa de aplicações e o Ambiente Operativo fossem só um programa. 0 Ambiente Operativo pode também lidar com mais do que um programa de aplicações concorrentemente, de tal modo que, por exemplo, um programa de aplicações para lidar com a preçagem automática possa correr concorrentemente com o programa de aplicações de gestão de espaço. Os dois programas de aplicações estariam assim a aceder aos mesmos dados em memória sem modificações ao Ambiente Operativo ou os programas de aplicações existentes. 7. Relatório. A Ambiente Operativo pode dar relatórios sobre quaisquer dados usando da flexibilidade do sistema de VISUA-LISAÇÃO e pode mostrar, por exemplos quebras totais e subtotais em qualquer campo no programa de aplicações. 7. Acesso a dados de fora. 0 Ambiente Operativo pode carregar/ intercalar/actualizar para e de qualquer tipo de armazenamento de dados exterior com total controlo sobre que objectos e campos a transferir, critérios particulares que os campos devem satisfazer, como tratar os duplicados, e assim por diante. As ligações entre programas chamados módulos de Tipo de Dados em lotes que fazem de facto a leitura e a escrita são programados específicamente para cada tipo de fonte de dados externa. Contudo, o aumento do Ambiente Operativo lida com a maioria das especificações de alto nivel da transferência, o que torna a criação destes módulos de BDT específicos de um dispositivo razoávelmente simples. Os orientadores dos BDT para armazenamentos de dados mais geralmente usados podem ser fornecidos, por exemplo, pelo fornecedor do Ambiente Operativo, ou poderão ser escritos pelo utilizador para adaptar a tipos de armazenamento de dados menus vulgares. Estes orientadores podem incluir (um encorporamento útil preferido) ficheiros de bases de dados, listagens de programas de textos, ficheiros de dados escolhidos pelos fornecedores, ficheiros de computadores manuseados e do género. -131- 9. Fórmulas. A cada campo pode ser atribuído uma fórmula por forma a que o seu valor é calculado pela fórmula maior do que ser explícitamente dado. Uma fórmula pode incluir referências a campos quer nos objectos ou noutros objectos relacionados.

Todas as funções de Lotus estão disponiveis para uso em fórmulas. Os campos podem tomar o valor NA (não disponível) e ERR (erro) para total compatibilidade com os sistemas de texto. As fórmulas podem ser entradas e editadas antes ou durante o correspondente programa e apli-cam-se a todas as situações do objecto for os quais são entradas maia do que uma "célula". As fórmulas são compiladas internamente para execução rápida e muitos das verificações de erros (por exemplo, argumentos errados, funções desconhecidas) foram feitas quando forem compiladas. 10. Macros. As macros podem ser entradas como linhas de comandos , onde cada comando é executado em sequência após o macro ser invocado. As macros são compilados como fórmulas e seguem uma sintaxe semelhante para facilidade de aprendizagem. Todos os comandos normalmente disponíveis, tal como os comandos especiais e capacidades usadas para definir "macros" "especiais" podem ser usadas em macros: etiquetas e GOTOS; frases de IF (teste de condição); variáveis dinâmicas; laços de FOR, WHILE, com BREAK e CONTINUE; submacros; estampagem de mensagens; valores de ponto; e assim por diante. 11. Dispositivos de Entrada e Saida. Tais como Écrans, Impressoras planificadas Ratos. A Ambiente Operativo é independentemente do tipo particular de écran que usa, mas acede-lhe através de um programa de ligação conhecido como Orientador de Dispositivos de Saida. Semelhantes orientadores são usados para ligar a outros tipos respectivos de dispositivo de saida tais como planificadores, impressoras e dispositivos fotográficos. Novos orientadores podem assim ser fácilmente escritos

para cobrir qualquer tipo de écran, impressora ou modo gráfico que seja adicional ao sistema. Um sistema de Orientação de Dispositivos de Entrada Semelhante lida com qualquer tipo de dispositivos de entrada, tal como um teclado, rato ou entradas digitais sucessivas.

TABELA II

Uso das Características do Ambiente Operativo pelo Sistema Preferido de Gestão de Espaço 0 uso das características pelo sistema de gestão de espaço preferido, pode ser resumido nesta secção. Deve-se compreender, contudo, que as variações do resumo que se segue dentro das capacidades dos hábeis na matéria dentro do âmbito. Assim, a alocação de funções entre o programa de aplicações preferido de gestão de espaço 1304 e o Ambiente Operativo 102 pode ser modificado dessa alocação prescrita nesta Especificação e ainda faz no âmbito da presente invenção como definido pelas reivindicações em apêndice e as reivindicações de quaisquer patentes relacionadas ou patentes de aplicações. A. As funções do Ambiente Operativo que se relacionam aos objectos:

Estampagem de :

Visualização da direcção Janelas de visualização -133-

Exclusão de subconjunto, por exemplo xsect Ârea de écran

Grelhas

Uso de imagens de vectores (conjuntos ligados dos pontos coordenados).

Uso de imagens, (bancos de cor)

Estampagem interactiva

Posicionamento do cursor Referência do cursor Adicionar/mover/denelas objectos Viragem de Objectos Deixar/objecto flutuante

Movimento de bloco/cópia de objectos semelhantes

Verificação de colisões

Posição corrente do cursor no écran

Desenho baseado na estrutura

Parte de lógica de estampagem

Entrada de dados por écrans

Visor— de objectos especiais Por linha Por écran

Actualização de campos relacionados num registo Totais e subtotais

Entrada do distância/data e valores de tempo.

Sistema de ajuda de linha simples e página cheia.

Relatórios

Reescrita de, dados, écrans de entrada de dados ou estampagem de gráficos para outros orientadores de dispositivos.

Ordenação

Sobre combinação de campo sob controlo de um visor Ficheiros Entrada e Saída

Versão do sistema reservando o formato para permitir compatibilidades de alto a baixo entre versões

Armazenar ASCII

Carregar ASCII

Actualizar Selectiva do ASCII Anular ASCII

Toda a gestão de base de dados usa conectores fornecidos de baixo nivel

Armazenar para a base de dados

Carregar da base de dados

Actualização selectiva da base de dados

Actualização selectiva para a base de dados

Anular registos da base de dados

Sistema de Controlo Écran de remanescente de memória corrente Écran de opção de validação corrente. -135-

Β. Ο Sistema Preferido da Gestão de Espaço usa do Ambiente Operativo

Ficheiro de Entrada e Saida ASCII: o Ambiente Operativo ASCII de armazenar/carre-gar/actualizar (de)/anular

Fornecendo o objecto ARMAZÉM e todos os objec-tos subsidiários

Separar o carregamento/intercalação de bibliotecas soltas.

Lotus: o Ambiente Operativo ASCII de armazenar/carre-gar/actúalizar (de)/anular.

Fornecendo objectos relevantes, critérios de selecção e detalhes de formato em conformidade com o formato WKS. dBASE: 0 Ambiente Operativo de base de dados de arma-zenar/carregar/actualizar'(de)/anular

Fornecendo objectos relevantes, critérios de selecção e conectores dBASE

Outras bases de dados: O mesmo com conectores relevantes

Estampagem do Planograma

Estampagem em Ambiente Operativo do Objecto ARMAZÉM" causa estampagem automática dos objectos membros A estampagem do objecto GONDOLA, pelo Ambiente Operativo, etc.

I

Adicionar/mover/anular Adicionar/mover/anuiar Adicionar/mover/anular Adicionar/mover/anular Operativo.

Interactivo de Gondola Interactivo de Prateleira Interactivo de Posição em objecto relevante no Ambiente

Modificações de entrada de teclas Armazem/Gondola/Prateleira/produto Manipulador de écran de entrada de dados no Ambiente Operativo, Fornecendo um VISOR

Mapa

Manipulador de écran de entrada de dados do Ambiente Operativo Fornecendo um objecto PRODUTO.

Execução de relatórios

Manipulação de relatórios do Ambiente Operativo Fornecendo um VISOR com ligações hierárquicas a outros

Geração e modificação de relatórios

Manipulador de entrada de dados por écran no Ambiente Operativo Fornecendo um VISOR referindo-se a um objecto VISOR.

Armazenamento e reposição no formato de relatório.

Armazenamento/carregamento/Actualização(de)/anulação do objecto VISOR.

Ordenação de produtos Écran de entrada de dados do Ambiente Operativo no Visor incluindo detalhes de critério.

Ordenação do objecto Produto no Ambiente Operativo dados um visor em extensão.

Rotinas especiais

Alocação preenchimento.

TABELA III

Os Ficheiros do Suporte 1306 de Sistemas de Gestão de Espaço Preferido

Estrutura 1310: Uma estrutura de dados-para o programa de aplicações do sistema de gestão de espaço preferido está ilustrado na FIG. 14B. Uma estrutura de dados mais complexa, secundária, está ilustrada na FIG. 14A. A estrutura da FIG. 14B é preferida por alguns utilizadores pela sua simplicidade e será o foco da discussão. Contudo, deve-se compreender que muitas variações na estrutura podem ser efectuadas pelos hábeis na matéria. A estrutura exemplar da FIG. 14B pode também ser representada como se segue onde os espacejamentos abaixo de um certo nível implicam ligações para baixo:

Armazém

Secção

FIXOS

Posição (1 de 2)

Bloco

Produto

Posição (2 de 2)

Bloco

Biblioteca

Produto

Secção

Fixos

Pino

Horário de Modelo

Horário de Pedidos

Horário de Fornecimentos

Horário de verificação de existência

Menus 1312: Num encorporamento preferido, é mostrado um menu principal, automáticamente, na inicialização. O menu principal está disponível quase todo o tempo durante o programa e tem as seguintes entradas:

Ficheiro Edição Análise Saida Sistema Misc Sair

Todos os menus excepto Sais, trazem outros menus. As opções que estão preferencialmente ligados directamente às funções do Ambiente Operativo são mostrados com um "OE" para designar. Outras opções referem-se a funções do programa de aplicações do sistema de gestão de espaço -139- preferido.

Os sub-menus podem incluir:

Ficheiro (Sistema de Dados em Lotes)

Carregamento Armazenar (OE)

Intercalar Actualizar de Actualizar para OE Novo

Edição:

Adicionar:

Secção com base/retorno

Fixos

Produtos

Posição

Modificação:

Secção

Fixos

Produtos

Posição

Movimento:

Fixos

Posição

Remover

Fixos

Produtos

Posição

Duplicados:

Fixos

Produtos

Posição

Listagem:

Fixos

Produto

Posição

Bloco:

Adicionar:

Posições

Posições da listagem

Movimento:

Fixos

Posições

Remover:

Fixos

Posições .“-v Cópia:

Fixar

Posições

Análises:

Janela de informação: mais detalhes ácerca do produto/prateleira corrente

Enchimento proporcional: ajustar o espaço dado a cada produto numa prateleira proporcionalmente para encher a prateleira

Forçar o mínimo: encurtar o espaço de produto para um mínimo.

Recomendado: mostrar o nivel de existência de um produto. Ênfase: Sobressair certos produtos dependendo de critérios entrados pelo utilizador.

Descarregar produtos: vaziar todas as prateleiras

Remover produtos fora de uso: esquecer quaisquer produtos que não estejam correntemente numa prateleira

Saida:

Relatório deste (visor corrente) OE

Relatório (seleccionar visor(es) da lista)

Trocar dispositivos OE - trocar para outro écran

Repor dispositivos OE - voltar ao écran original

Trocar VIDA ON/OFF OE - trocar a estampagem ON/OF de imagens manchadas

Trocar as formas ON/OF OE - trocar ON/OFF estam- -142- ι

pagens de imagens enwectores '

Gerar o ficheiro VIDA - Criar um ficheiro para usar no sistema vivo de captura/armazém

Sistema: DOS OE - voltar temporariamente ao sistema operativo OE de Manutenção em memória

Misc:

Clientelizar:

Sistema de Menu OE Visores OE

Dispositivos de entrada OE Dispositivos de saída OE Fontes de Dados em lotes OE Tipos de Dados em lotes OE

Correcção: <Várias rotinas para correcçãoy Nivel:

Baixar o nivel de um grau OE Seleccionar o próximo visor OE Elevar o nível de um grau OE

Visor: -143-

Rápidamente entrar OE Rápidamente sair OE

Rapidamente voltar ao nosos sistema OE

Centro OE

Vista de topo OE

Vista da esquerda OE

Vista da direita

Vista de frente

Vista de trás

Outras opções de visualização OE POSICIONAMENTO DA AUTO-AJUDA OE TECLAS 1314: Muitas das funções por teclas de outro modo dis-poniveis pelos menus acima listados. Outras disparam o menu principal ou outros menus subalter-nor directamente. Outras são teclas de "abortar" ou "finalizar" somente disponíveis em certos écrans.

Macros 1316: Mostrou-se vantajoso usar as seguintes macros

Copias-último: Eèta é uma macro de utilitário para ajudar na edição de longas tabelas de dados.

Abandonar: Esta é um macro do menu principal que toma a confirmação do programa e depois sair do programa. AUTO EXECUTAR: Esta é uma macro executada automáticamente pelo Ambiente Operativo quando é inicializado. Pode ser configurado para carregar automáticamente dados na biblioteca pendurada de um ficheiro de ligados, padrão. -144-

Acontecimentos 1317: Um acontecimento é umá função (ou macro) que é regulada pelo tempo para ser executada sem intervenção do utilizador num tempo específico e possivelmente repetida em intervalos pares após aquele tempo.

Um acontecimento que é vantajosamente implementado é uma função chamada cada 1-2 segundos que estampará automáticamente uma pequena janela no canto do écran reflectindo o produto ao qual o utilizador está correntemente a apontar com o cursor.

Visores 1318: Os visores são formatos de écrans, cada um para um objecto particular na estrutura. Os visores vêm em três variedades: 1. Visores de mapa: Este mostra os dados no écran (ou uma janela) um formato tabular, um registo por linha. 2. Visores de todo o écran: Este mostra cada registo em todo o écran (ou janela), posicionando os campos precedidos pelos seus nomes em vários pontos no écran de acordo com os detalhes no visor. 3. Visor de Modelo: Este extrai informação tri-dimensional para desenho de cada registo de acordo com detalhes no visor e a estampagem é graficamente no écran (ou janela), os visores de modelo podem ser encadeados em conjunto para permitir a múltiplos objectos de serem estampados gráficamente num écran.

Os visores são seleccionados pelas funções do sistema de gestão de espaço preferido fazendo pedi- dos ao Ambiente Operativo nas funções internas, que então disparam e gerem as estampagems na altura.

Os visores preferidos podem incluir: OBJECTO NOME TIPO Armazém ...000 Écran tot. Armazém ...001 Écran tot. Armazém A.A. Armazém Modelo Armazém OPS. ADIÇÕES Écran tot Secção SECTOR A.C. Modelo Secção GONDOLA A.C. Modelo Secção SECC. B.C. Modelo Secção ADIC. SECC. Écran tot. Secção Fácil. SECC. Ecran tot. Secção LIST. SECC. Mapa Secção LIST. GOND Mapa Secção BIB-SECC. Mapa Fixos FIXOS. A.E. Modelo Fixos ASM.A.E. Modelo Fixos AMOSTRA Modelo Fixos ADIC. FIXOS Écran. tot. Fixos Sei. FIXOS Mapa Fixos LIST: FIXOS Mapa

DESCRIÇÃO

Sinalizar o visor, mostra a versão e os direitos de autor

Branco

Modelo Padrão de Armazém Opções de nivel de armazém Modelo padrão de reacção Modelo de reacção com dimensões Modelo de reacção cores diferentes Edição de secção

Secação com campos base/retorno incluído

Listagem da secção

Listagem, uma só gondola

Listagem da secção para uso na biblioteca

Modelo padrão de fixar Modelo de fixar, uma só montagem Experimental Edicção de fixos

Lista de fixos, usada para selecção de fixos.

Listagem padrão de fixos -146-

Fixos BIBL. FIXOS Mapa Fixos LISTA ASM Mapa Posição POS. A.F. Modelo Posição ADIC. POSIÇÃO Écran tot. Posição ADIC. POS. Écran-tot Posição DTL. Posição Modulo Posição LIST. POSIÇÃO Mapa Produto ADIC. PROD. Écran-tot. Produto LST. PROD. MAPA Produto SEL. PROD. Mapa Bloco BLOCO A.G. Modelo Bloco LISTA-BLOCO Mapa Cavilhas BIB1. CAVILHAS Mapa Catalogo de Modelos ADIC. MODELO Écran-tot. Catálogo de Modelo LIST-MODELO Mapa Catálogo de Modelo ADIC-MODELOS Écran-tot. Catálogo de Pedido LISTA-PEDIDOS Mapa Catálogo de Stock ADICtSTOCK Écran-tot. Catálogo de Stock LISTA-STOCK Mapa Catálogo de fornecimento LISTA-FORNEC. Écran. tot.

Lista de fixos para uso na biblioteca

Lista de fixos um só elementto de montagem

Modelo padrão para posição

Edição de Posição

Edição de Posição alternativo

Modelo de posição alternativo

Listagem de posição

Edição de produto

Listagem de produtos

Selecção de produto na lista

Modelo padrão para bloco

Lista de BLOCO

Lista de cavilhas

Edição de catálogo de modelo

Edistagem de catálogo de modelo

Edição de catálogo de Pedidos

Lista de catálogo de pedido

Edição de catálogo de stocks

Lista de Stock em catalogo

Edição do catálogo de fornecimento -147-

Catatálogo de fornecimento LISTA. FORNEC. Mapa Lista de Catálogo de forne cimento

Visores de finalidade especial para uso interno do sistema es pecial de gestão de espaço: OPÇÕES DE ADIÇÃO DE BLOCO entrada de opções para uso durante o posicionamento de adição de bloco. LISTFICHBDS mostra a lista de ficheiros disponíveis antes da transferência do BDS. XYZ edição de XYZ posição do cursor. EXEC. OPÇÕES entrada de opções de execução usados durante o preenchimento proporcional OPÇÕES.FOCEM entrada de opções usadas pela forçagem mínima OPÇÕES.ENFASE entrada de opções usadas pela característica enfase. OPÇÕES.CORTE entrada de opções usadas durante o posicionamen to for certo Podem também ser incluídos outros visores do sistema usados para clientelizar menus, visores e do género.

Fontes de Dados em Lotes 1320 Os BDS (algumas vezes referidos como 'banais de dados") que são vantajosa mente empregues, podem incluir: NOME BDT DESCRIÇÃO Planogramas OE ASCII Ficheiros de planogramas padrão todos os objectos Biblioteca de cavilhas OE ASCII Só cavilhas

J

OE ASCII SP.IIASCII

Biblioteca de fixar

Spaceman II

Produtos dBASE(R) dBASEIII(R)

Folha de Cálculo Lotus (R)

CAREGAMCAVILHAS OE ASCII

Secções/fixar sob a biblioteca

Ficheiros do SPACEMAN II, todos os objectos.

Lista de produtos de/para o ficheiro dBASE

Lotus (R)ALL todos os objectos de/ para a folha de cálculo Lotus. Só cavilhas, não há estampagem durante a tranferência.

Mensagens 1322: Esta é uma lista de todas as mensagens usadas pelo progrma de aplicações, mantidas separadamente e indexadas por número dos outros ficheiros de aplicação para permitir a tradução fácil entre linguagens (isto é, linguagens "humanas" tais como o Alemão, o Francês, o Inglês e assim).

Os nomes, as descrições, as men-i sagens de erro são referidos nas funções do sistema de gestão de espaço preferido e os outros Ficheiros de Apoio como números, que correspodem a mensagens reais no Ficheiro de Mensagem .

TABELA IV

Funções do Sistema de Gestão de Espaço Preferido 1308 Funções de apoio ao sistema: SYSINIT. inicializa internamente os valores do sistema de gestão de espaço preferido. não-entrada conectado a alguns campos para para a edição do utilizador fim 1. fim 2 esc 1 esc 2 barra 1 barra 2 armazena o registo editado e depois permite uma movimentação armazena o registo editado e permite uma movimentação ignora o registo editado ignora o registo editado traz o menu principal traz um pequeno menu de edição durante a entrada de dados. salta-página troca de páginas num visor de écran total entrada 1 selecciona o item corrente. novos-dados novo ficheiro - remove todos os dados correntes internamente.

fim-s/mover armazena o registo editado, sem mover fim-clecç finaliza um selecção múltipla, modo flooplano troca para o VENICE modo planograma troca para o modo planograma regular modo-bibl-secção troca para a biblioteca de secção modo-bibl.-fixos troca para a biblioteca de fixos modo-bibl.-cav. troca para a biblioteca de cavilhas troca-unidades troca entre unidades/modo bloco para estampagem de posição. info-pos desenha uma janela de informação respeitante ao produto corrente. dim.cur. mostra a posição corrente do cursor cur.bill mostra o espaço de anúncios para a prateleira corrente encontra encontra o produto corrente na lista, encontra de.ch encontra o produto corrente no modelo auto-janela traz informação resumida do produto corrente

Rotinas de nivel de armazém: pré-armazem inicializa um armazém pós-armazém verifica um armazém após ter sido editado armazem-novo Edita Adicionado armazém (não está agora em uso) modif-armazem Edita armazém modificado

Rotinas de Catalogo: pré-modelo inicializa um catálogo de modelo pós-modelo verifica um catálogo de modelo entrado lista-modelo Lista catélogo de modelo novo-modelo Adiciona catálogo de modelo dupl.-modelo Duplica catálogo de modelo modif.-modelo Modifica catálogo de modelo rem-modelo Remove o catalogo de modelo análogo para os catálogos de pedido, existências e fornecimentos .

Secção de rotinas de edição: pré-secc. lista-sec nova-sec dup-sec inicializa uma nova secção Edita a lista de secções Edita a secção adicionada Edita a secção duplicada -151-

modif-sec remove-sec move-sec xfr-sec põe secção

Edita a secção modificada

Edita a secção removida

Edita a movimentação da secção

Edita a toma da secção (ainda não saída), transferência dentro da biblioteca

Edita a secção posta (ainda não saída), transferência fora da biblioteca

Funções semelhantes para edição de fixas, produto e posição e também objectos agrupados, gondolas, departamento e ala.

Funções extra de desenho: dim-aberta-prop dim-altura-fixas dim-largura-fixas desenha-grade dim-grade d e s e nh arreta-tráfico desenha as dimensões para a profundidade de prateleira aberta desenha a altura dos fixas desenha a largura dos fixas desenha uma grade numa prateleira aberta desenha as dimensões numa grade desenha uma seta mostrando o tráfico de tráfego para uma secção desenha-todas-as cavilhas desenha todas as gavilhas num quadro de cavilhas desenha-cavilhas desenha uma cavilha num produto desenha-cavilha-presente desenha uma posição total da cavilha na parte da frente do produto desenha espaços desenha um espaço entre os produtos numa prateleira -152-

Funções de Análise: locinfo posição do cursor descarrega-tudo Análisa Descarga de produtos remove-fora de uso Analisa Remoção de produtos fora de uso forcem Analisa a Forcagem mínima dist-prop. Analisa o preenchimento proporcional auto-preço função de autopreçagem (NYI) inforeq Análise Recomendada - mostra o inventário recomendado optiquery Avalia o inventário em resumo (NYI) enfase Analisa o enfase VIVOS (sombreado) funções relacionadas: faz ficheiro vivo Gera um ficheiro vivo para a secção corrente

As funções especificas de ficheiro do sistema de gestão de espaço preferido: carrega fic Carregamento do ficheiro intercala fic Intercala o ficheiro actualiza fic Actualiza o ficheiro de F-s3bds Para invocar um BDS através do sistema preferido de gestão de espaço, de uma macro funções BDT criadas no SPACEMAN II s2bdt-inic s2bdt-ler -153-

s2bdt-pmtler s3bdt-fechar

TABELA V

Características Vantajosamente Empregues no Sistema de Gestão de Espaço

As características listadas nesta secção refletem essas características que podem ser usadas vantajosamente no programa de aplicações do sistema de gestão de espaço preferido em conjunto com o Ambiente Operativo- Esta reacção dà àqueles hábeis na matéria uma lista das características que são desejáveis num sistema de gestão de espaço. Os que estiverem acustomados a usar outro sistema de gestão de espaço poderão fazer uso do grau de transferência de uma variedade de características dos programas de aplicações existentes, em aditamento aos programas de aplicações que possam ser especialmente concebidos para operar conjuntamente com o Ambiente Operativo. Os que são hábeis na matéria têm a habilidade, baseados na presente descrição, para conceber e implementar programas de gestão de espaço que são derivados de programas existentes com características desejáveis ou que são desenvolvidos independentemente.

Gerindo os Fixos.

Posicionamento automático de prateleira 0 posicionamento de uma prateleira uma secção uma vez entradas nos seus detalhes pode ser auto matisada com base no posicionamento de outras prateleiras préviamente postas e o espaço de mercadorias que necessitam.

Posicionamento de prateleiras por número de corte 0 posicionamento de uma prateleira na reacção pode alternadamente ser baseada verticalmente um número de corte entrado pelo utilizador, sendo o número: a) o número de cortes desde o chão b) o número de cortes abaixo da prateleira, próxima, mais alta

Subsecções A reacção pode ser dividida horizontalmente em subsecções pela entrada de comprimentos de subsecções no registo de secção. Estes podem ser usados para: a) A estampagem de linhas verticais de subsecção b) A estampagem gráfica de um só subsecção c) 0 posicionamento automático de prateleiras (ser acima).

Paredes de armazém

Ajudadas a construção para permitir a fácil construção de paredes numa planta do chão do armazém .

Produtos

Listas de produtos. A listas de produtos implementados como visores mostrando os mesmos campos como podem-se apresentar em sistemas de gestão de espaço conhecidos.

Encontrar o modelo

Uma função para encontrar e mover (na secção mostrada) o produto corrente na lista de produtos.

Definições de descrições

Alguns campos de descrição de produtos (geralmente denominados DESC A a DESC J) podem ter os seus nomes modificados num écran central, após o qual, quaisquer listas de produtos, em mapas (ou quaisquer outros écrans que mostrem os nomes desses campos) mostrarão os nomes dos campos já redefinidos. Isto é conseguido por uma mudança global a todos os visores relevantes.

Actualização de um só produto de uma base de dados

Actualizar todos os campos de um produto por entrada do utilizador de um só identificador tal como o número de UPC.

Colocação de produtos numa prateleira

Desenho da prateleira/posição periférica

Certas características de certos produtos/prateleiras não lidadas automáticamente pelas funções automáticas de desenho do Ambiente Operativo podem ser desenhadas por funções específicas de desenho. Estas incluem o desenho de: a) Cavilhas em placas de cavilhas b) Espacejadores em prateleiras c) Grades em frente das prateleiras

Adição de blocos A colocação de um grupo de produtos numa prateleira pode ser feito de uma só vez por: a) escolhendo-os da lista de produtos b) seleccionando o critério com base em certos campos de produtos

Preenchimento proporcional

Quando uma prateleira não está cheia, um algoritmo de preenchimento proporcional pode adicionar mais coberturas de alguns ou de todos os produtos existentes para encher as prateleiras, enquanto ainda as mantém em proporção, tanto quanto possível.

Forcagem mínima

Esta função removerá as coberturas de alguns ou de todos os produtos numa prateleira, deixando só o número mínimo de coberturas necessárias pelo sistema de cálculo de inventário.

Troca/espelho

Esta função inverterá a ordem dos produtos nas prateleiras e se pretendido a colocação horizontal das prateleiras também.

Descarga

Esta função remove todos os produtos de todas as prateleiras na secção, deixando a lista de produtos intacta. Ênfase

Esta função modifica a etiqueta-gem ou a cor dos produtos no écran por forma a lhes dar realce, com base no critério de entrada incluso: a) Melhores/Piores produtos em acção (venda) b) produtos em excesso/ou em falta em existência c) produtos correspondendo a certos campos entrados pelo utilizador

Resumo de produtos

Esta função resume todos os produtos com um ou mais produtos "medianos" para uso numa análise geral de nivel de armazém.

Estampagem do modo Unidades/bloco.

Utilizando diferentes visores os produtos nas prateleiras podem ser mostrados como um todo ou unidades separadas.

Etiquetagem A etiquetagem de produtos pode ser controlada e clientelizada usando o visor do Ambiente Operativo e o sistema de fórmulas.

Justificação à direita

Os produtos podem-se agrupar para a direita de uma prateleira parcialmente cheia em vez de ser pela esquerda como é usual.

Janela de posicionamento/prateleira automática

Quando aponta a um produto/prate-leira o sistema pode mostrar automáticamente uma janela com detalhes dessa posição/prateleira um canto do écran sempre que o cursor não seja movido por um custo período de tempo.

Encher/não-encher/colocação manual

Existem opções de colocação ao longo de uma prateleira a) Não encher— normal mas encostar todos os produtos à esquerda ou à direita b) Encher-automáticamente fazer um preenchimento proporcional após cada colocação. c) Manual—posicionar os produtos exactamente onde especificado sem ajustamento

Encontrar o próximo produto

Encontra a próxima ocorrência do mesmo produto na secção se hà uma. -159- Écran de avaliação

Estampa estatísticas financeiras correntes de todo o geral Écran recomendado

Mostra o inventário recomendado para o produto corrente.

Gestão de dados

Spaceman II ligação de ficheiros Implementada como um BDT DXF Autocad saida

Saida para um sistema CAD padrão, ficheiro DXF implementado como um BDT

Saida

Dimensões de secção

Funções periféricas de desenho adicionadas aos visores para desenhar informação de dimensões em: a) Prateleiras b) Toda a secção c) Cavilhas d) Grades de Prateleira e) Direcção do tráfico de fluxo

Ficheiro VIVO

Saida de um produto especificamen-te para uso no sistema de Logística com impressão/imagem sombreada de armazém

Orientadores para outros écrans

a) EGA

b) EVGA c) Targa V. Conclusão

Enquanto os vários detalhes do encorporamento preferido da presente invenção foram descritos acima, deve-se compreender que a descrição detalhada acima, foi apresentada por forma de exemplo e não de limitação. Assim a largura e âmbito da presente invenção não deve ser limitada pelas características acima descritas, mas deve ser definida sómente de acordo com as seguintes reivindicações e os seus equivalentes.

APÊNDICE A: FICHEIRO DE ESTRUTURAS EXEMPLAR LIGAÇÃO, ID, 1, DESCRIÇÃO,1, MULTI-DNO, 3, MULTI_MEMBRO, 3, DE, -1, FORMAÇÃO, -1, PARA, -1 CAIXA, ETIQUETA, 1, VALOR, 3, DETERMINAÇÃO, -1, DE, -1, FORMAÇÃO, -1 CAMPO, ID, 1, TIPO, 7, COMPRIMENTO, 3, PREC, 3, VIS, 7, AJUDA 1, PRE-ENTRADA, 8, PÓS-ENTRADA, 8, SÓ-FORMULA, 2, DE -1, FORMAÇÃO, -1 OBJECTO, ID, 1, DIMENSÃO, 3, DESENHOS, 8, PRÉ-adição, 8, PÓS--ENTRADA, 8, FORMAÇÃO, -1 SISTEMA, ID, 1, DESCRIÇÃO, 1

SISTEMA, SPACEMAN, Estrutura de dados Spaceman III OBJECTO, ARMAZÉM, 0, 0,237, 0.0, 0.0, SPACEMAN CAMPO, ID, STR, 12, 0, SIM, "", 0.0, 0.0, NÃO, , ARMAZÉM, SPACEMAN CAMPO, /2.10J, STR, 12.0, SIM, 0.0., 0.0, NÃO, "", ARMA_

ZEM, SPACEMAN CAMPO, X, DUPLO, 12,3, SIM, 0.0, 0.0, NÃO, ARMAZÉM,

SPACEMAN CAMPO, Y, DUPLO, 12,3, SIM, "11 , 0.0, 0.0, NÃO, ARMAZÉM,

SPACEMAN

CAMPO, ALTURA, DUPLO, 12, 3, SIM, "", 0.0, 0.0, NÃO, "", ARMAZÉM; SPACEMAN

CAMPO, LARGURA, DUPLO, 12, 3, SIM, 0.0, 0.0, NÃO, "".AR

MAZÉM, SPACEMAN CAMPO, PROFUNDIDADE, DUPLO, 12, 3, SIM, 0.0, 0.0, NÃO, ""

ARMAZÉM, SPACEMAN

CAMPO, VENDAS, DUPLO, 12, 3, SIM, "", 0.0, 0.0, NÃO, "". ARMAZÉM, SPACEMAN CAMPO, TIPO, INT, 2, 0, SIM, "", 0.0, 0.0, NÃO, "", ARMAZÉM,

SPACEMAN

CAMPO, ÃREA, STR, 30, 0, SIM, "", 0.0, 0.0, NÃO, "", ARMAZÉM, SPACEMAN

CAMPO, GERENTE, STR, 30, 0, SIM, "", 0.0, 0.0, NÃO, "", ARMAZÉM. SPACEMAN

CAMPO, GRUPO, INT, 2, 0, SIM, 0.0, 0.0, NÃO, ARMAZÉM,

SPACEMAN

CAMPO, DEPARTAMENTOS, INT, 3, 0, SIM, 0.0, 0.0, NAO, "" , ARMAZÉM, SPACEMAN

LIGAÇÃO, DENTRADA, "", 0.1, ARMAZÉM, SPACEMAN, GONDOLA

LIGAÇÃO, ENTRADA STOCK EM, 0.1, ARMAZÉM, SPACEMAN, PRODUTO

OBJECTO, GONDOLA, 0, 0.237, 2.7, 0.0, SPACEMAN CAMPO, ID, STR, 12, 0, SIM, 0.0, 0.0, NÃO, "", GONDOLA,

SPACEMAN

CAMPO, NOME, STR, 12, 0, SIM, ”", 0.0, 0.0, NÃO, "", GONDOLA, SPACEMAN CAMPO, X, DUPLO, 8, 3, "SIM", 0.0, 0.0, NÃO, "", GONDOLA,

SPACEMAN

CAMPO, Y, DUPLO, 8, 3, "SIM", "", 0.0, 0.0, NÃO, "", GONDOLA, SPACEMAN

CAMPO, Z, DUPLO, 8, 3, "SIM", "", 0.0, 0.0, NÃO, "", GONDOLA, SPACEMAN CAMPO, DIRECÇÃO, INT, 3, o, SIM, "" , o.o, o * o NÃO, It II t GON- DOLA, SPACEMAN CAMPO, ALTURA, DUPLO, 8, 3, SIM, "", 0.0, 2.8, NÃO, II II t GON- DOLA, SPACEMAN CAMPO, COMPRIMENTO, DUPLO, 8, 3, SIM, o o o o NÃO, II II r

GONDOLA, SPACEMAN

CAMPO, PROFUNDIDADE, DUPLO, 8, 3, SIM, "", 0.0., 0.0, NÃO,"", GONDOLA, SPACEMAN

CAMPO, ALTURA BASE, DUPLO, 8, 3, SIM, "", 0.0., 0.0, NÃO, GONDOLA; SPACEMAN

CAMPO, COMPRIMENTO BASE, DUPLO, 8, 3, SIM, "", 0.0, 0.0, NÃO, GONDOLA, SPACEMAN

CAMPO, PROFUNDIDADE BASE, DUPLO, 8, 3, SIM, "", 0.0, 0.0, NÃO, "", GONDOLA, SPACEMAN

CAMPO, GROSSO, DUPLO, 8, 3, SIM, 0.0, 0.0, NÃO, GON

DOLA, SPACEMAN CAMPO, OBSTRUÇÃO, CAIXA, 3, 0, SIM, "·'! , 0.0, 0.0, NÃO,

GONDOLA, SPACEMAN

CAIXA, NÃO, 0, OBSTRUÇÃO, GONDOLA, SPACEMAN CAIXA, SIM, 1, OBSTRUÇÃO, GONDOLA, SPACEMAN -163-

CAMPO, Y, DUPLO, 8, 3, SIM, "", 0.0, 0.0 ,: NÃO; (SADD(/Y], /base altura/), gondola, spaceman CAMPO, BASE, X, DUPLO, 8, 3, SIM, 0.0. , 0.0, NÃO, (9ADICIO-

NA (A7, ^DIVIDIR ^ÒSUBTRAIR (/COMPRIMENTO/; /BASE COM-'PRIMENTO/ ), 2)), GONDOLA, SPACEMAN LIGAÇÃO, ON, 0, 1, GONDOLA, SPACEMAN, PRATELEIRA

OBJECTO, PRODUTO, 0, 0.237, 0.0, 0.0, SPACEMAN CAMPO, ID, STR, 12, 0, SIM, SPACEMAN II II / 0.0, 0.0, NÃO, II II l PRODUTO, CAMPO, ID, STR, 12, 0, SIM, SPACEMAN II M / 0.0, 0.0, NÃO, II II / PRODUTO, CAMPO, UBS; STR, 12, 0, SIM SPACEMAN II II / , 0.0, 0.0, NÃO II II f , PRODUTO; CAMPO; COR, INT, 3, 0, SIM, SPACEMAN 11 II ; 0.0, 0.0, NÃO, II II t PRODUTO, CAMPO, ALTURA, DUPLO, 8, 3, DUTO, SPACEMAN SIM , 0.0, 0.0, NÃO , "" , PRO- CAMPO, ESPESSURA, DUPLO, 8, 3, SIM, 0.0, 0 .0, NÃO,

PRODUTO, SPACEMAN CAMPO, H+W, DUPLO, 8, 3, SIM, 0.0, 0.0, SIM, (3Adição(/"al

tura/, /largura/), PRODUTO, SPACEMAN CAMPO, PROFUNDIDADE, DUPLO, 8 DUTO, SPACEMAN , 3, SIM, 0.0, 0.0, NAO, PRO CAMPO, CAIXA MAÇO, INT, 3, 0, PRODUTO, SPACEMAN SIM "" 0 0 2.6, NÃO, CAMPO, CAIXA CUSTO, DUPLO, 8, PRODUTO, SPACEMAN 2, SIM, »", 0 .0, 2,6, NÃO, , CAMPO, CUSTO UNITÁRIO, DUPLO, "", PRODUTO, SPACEMAN 8, 2, SIM, »" , 2.5, 0.0, NÃO, CAMPO, TESTE, INT, 3, 0, SIM, SPACEMAN II II / 0 0 0 • 0 NAO, PRODUTO, CAMPO, TEST2, INT, 2, 0, SIM, SPACEMAN II II / 0 • 0 0 0 NÃO, PRODUTO, CAMPO, TEST3, IONT, 3,0, SIM, SPACEMAN II II / 0 0 0 0 NÃO, PRODUTO, CAMPO, CUSTO TRABALHO, DUPLO; 11", PRODUTO, SPACEMAN 8, 2, SIM, "" , 0.0, 0.0, NÃO,

CAMPO, DPC, DUPLO, 8, 2, SIM, 0.0, 0.0, NAO, PRODUTO,

SPACEMAN CAMPO, MOVIMENTO, DUPLO, 8, 2, SIM, 0.0, 0.0, NO, "",

PRODUTO, SPACEMAN

CAMPO, PREÇO, DUPLO, 8, 2, SIM, 0.0, 0.0, NÃO, "", PRODU

TO, SPACEMAN CAMPO, ENCOMENDA, DUPLO, 8, 2, SIM, 0.0, 0.0, NÃO, ,

PRODUTO, SPACEMAN LIGAÇÃO, DE, 0, 1, PRODUTO, SPACEMAN, POSIÇAõ

OBJECTO, PRATELEIRA, 0, 0.237, 0.0, 0.0, SPACEMAN CAMPO, ID, STR, 12, 0, SIM, 0.0, 0.0, NAO, "", PRATELEIRA,

SPACEMAN CAMPO, TIPO SH, CAIXA, 10, 0, SIM, 0.0, 0.0, NÃO, "",

PRATELEIRA, SPACEMAN

CAIXA, PRATELEIRA ABERTA, 0, SH, TIPO, PRATELEIRA, SPACEMAN

CAIXA, PLACA DE CAVILHAS, 1, SH TIPO, PRATELEIRA, SPACEMAN

CAIXA, CH FRIGORIFICO, 2, SH TIPO, SHELF, SPACEMAN

CAIXA, BAR, 0, SH TIPO, SHELF, SPACEMAN CAMPO, X, DUPLO, 8,3, SIM, It II 9 0.0, 0.0, NÃO, PRATELEIRA, SPACEMAN CAMPO, Y, DUPLO, 8, 3 , SIM II II 9 , 0.0, 0.0, NÃO, "" , PRATELEIRA SPACEMAN CAMPO, Z, DUPLO, 8, 3 , SIM II II 9 , 0.0, 0.0, NÃO, " " , PRATELEIRA SPACEMAN CAMPO, COMPRIMENTO, DUPLO, 8, 3, SIM, 0.0, 0.0, NÃO, "", PRATELEIRA, SPACEMAN CAMPO, COMPRIMENTO, DUPLO, 8, 3, SIM, 0.0, 0.0, NÃO, "",

PRATELEIRA, SPACEMAN CAMPO, PROFUNDIDADE, DUPLO, 8,3, SIM, 0.0, 0.0, NÃO,

PRATELEIRA, SPACEMAN

CAMPO, ESPESSO, DUPLO, 8, 3, SIM, 0.0, 0.0, NÃO, "", PRA

TELEIRA, SPACEMAN

CAMPO, DIRECÇÃO, INT, 3, 0, SIM, 0.0, 0.0, NÃO, PRA

TELEIRA, SPACEMAN

CAMPO, PENDOR, INT, 3, 0, SIM, "", 0.0, 0.0, NÃO, "“, PRATELEIRA, SPACEMAN

CAMPO, TOPO, DUPLO, 0, 3, SIM, 0.0, NÃO, (dADIÇÃO(,

/ÈSPESSOj), PRATELEIRA, SPACEMAN LIGAÇÃO, COLOCADO EM, ΟΝ, 0, 1, PRATELEIRA, SPACEMAN, POSIÇÃO OBJECTO, POSIÇÃO, 0, 0,237, 0.0, 0.0, SPACEMAN

CAMPO, ID, STR, 12, 0, SIM·, " " , 0.0, o « o POSIÇÃO, SPACEMAN CAMPO, FRENTES, INT, 4, 0, ÇÃO, SPACEMAN SIM, o o o « o NÃO, "" , POSI- CAMPO, X, DUPLO, 8, SPACEMAN 3, SIM, " " , 0.0, o • o NÃO, II II r POSIÇÃO, CAMPO, Y, DUPLO, 8, SPACEMAN 3 , ’SIM, "" , 0.0, o • o NÃO, II II / POSIÇÃO, CAMPO, Z, DUPLO, 8, SPACEMAN 3, SIM, " " , 0.0, o o NÃO, II (I / POSIÇÃO, CAMPO, ALTURA, DUPLO, 8, 3, SIM, o • o o o NÃO, , POSI

ÇAO, SPACEMAN

CAMPO, LARGURA, DUPLO, 8, 3, SIM, 0.0, o o NÃO, PO- SIÇÃO, spaceman CAMPO, PROFUNDIDADE, duplo, 8, 3, SIM, o o NAO, , PO- SIÇÃO, SPACEMAN CAMPO, COR, CAIXA, 8, 0, SIM, o • o o • o , NÃO II U / / POSIÇÃO SPACEMAN CAIXA, BRANCA, 15, COR, POSIÇÃO, SPACEMAN CAIXA, AMARELA, 14, COR; POSIÇÃO, SPACEMAN

CAIXA, ROSA, 13, COR, POSIÇÃO, SPACEMAN CAIXA, ENCARNADO VIVO, 12, COR, POSIÇÃO, SPACEMAN CAIXA, CASTANHO CLARO, 11, COR, POSIÇÃO, SPACEMAN CAIXA, VERDE CLARO, 10, COR, POSIÇÃO, SPACEMAN CAIXA, AZUL CLARO, 9, COR, POSIÇÃO, SPACEMAN CAIXA, CINZENTO, 7, COR, POSIÇÃO, SPACEMAN CAIXA, CASTANHO, 6, COR, POSIÇÃO, SPACEMAN CAIXA, VIOLETA, 5, COR, POSIÇÃO, SPACEMAN CAIXA, ENCARNADA, 4, COR, POSIÇÃO, SPACEMAN CAIXA, CASTANHO, 3, COR, POSIÇÃO, SPACEMAN CAIXA, VERDE, 2, COR, POSIÇÃO, SPACEMAN CAIXA, AZUL, 1, COR, POSIÇÃO, SPACEMAN CAIXA, PRETO, 0, COR, POSIÇÃO, SPACEMAN

EXPLICAÇÃO DO FICHEIRO DE ESTRUTURA EXEMPLAR O apêndice A, ilustra um ficheiro de estruturas típico. Com vantagem, o ficheiro de estruturas pode ser nomeado com um ".str" em sufixo no nome do programa de aplicações. Por razões de clareza, as marcas quotidianas foram omitidas das especificações textuais, excepto onde um campo textual estiver totalmente vazio (" "). Também foram inseridos espaços entre os objectos listados, por forma a delimitar mais claramente as diferentes secções das especificações do ficheiro de estruturas.

Referindo o Apêndice A, é mostrado um formato de trabalho para um ficheiro de estruturas. Podem ser feitas muitas variações no ficheiro de estruturas do Apêndice A, enquanto ainda nos mantemos no âmbito da presente invenção. Contudo qualquer ficheiro de estrutura, trabalhável com a presente invenção deve conter uma especificação de ob-jecto, campos ai contidos e ligações entre os objectos. Podem ser feitas adições de características rearranjos e melhoramentos, conquanto esteja presente alguma definição da estrutura na qual o programa de aplicações possa operar.

Isto é exemplificativo dos ficheiros de estruturas que são tratados como ficheiros de dados normais que seguem o caminho de transferência "Intercalação" no Sistema de Dados em Lotes (FIG. 11) durante o processo de carregamento/ e agregação (FIG. 5 e 5A)

Referindo às primeiras poucas linhas antes da linha em branco no ficheiro de estruturas, a definição geral do formato de ligações, casos, campos, objectos, e o sistema são fornecidos. Toda a porção restante do restante ficheiro de estruturas (após a primeira linha em branco) inclui a definição actual dos campos particulares, ligações a casos nos objectos.

Cada um destes objectos, campos, ligações e casas requerem o formato geral definido nas poucas linhas do topo do ficheiro. Claro que, este arranjo não necessita ser seguido em todos os encorporamentos da invenção. Contudo, a organização ilustrada de um ficheiro de estruturas tem-se mostrado efectiva.

Para ilustrar como o formato de entradas no corpo do ficheiro de estruturas seguem as definições no inicio do ficheiro de estruturas, pode-se ver que na linha imediatamente a seguir à primeira linha em branco, a palavra "sistema" corresponde à palavra "sistema" imediatamente antes da linha em branco. A palavra "Spaceman" (abreviatura de SPACE MANAger o programa de aplicações da Logistics Data Systems, INC., de Irving, Texas) corresponde ao campo de "ID" na definição. 0 número "1" significa que o campo "ID"é do tipo "cadeia de caracteres".

Finalmente, correpondendo ao campo "descrição" está o termo "estrutura de dados" "Spaceman III" em título.

No encorporamento preferido, cada objecto é primeiro especificado, declarando um objecto e nomeando-o com um "ID" de, por exemplo, "armazém". Este exemplo particular pode ser visto na linha após a segunda linha em branco no ficheiro de estruturas.

Seguindo a declaração do objecto estão várias definições de campos. 0 objecto "armazém" é mostrado no apêndice A como tendo 14 campos. Cada linha é aloca-da para cada campo do objecto "armazém".

Seguindo as 14 declarações de campo estão duas definições de ligação. Não há especificações de "casos" sob o objecto "armazém". Contudo o objecto "gondola" tem de facto campos "de especificação de caixas"..No campo cujo "ID" é "obstrução", o terceiro campo é visto como sendo "caixa". (Campos prévios no objecto gondola têm um "tipo" quer de cadeia ("str") dupla precisão ("dupla"), ou inteiro ("int").

Mas porque o campo "obstrução" tem um tipo "caixa", duas especificações "caixa" peguem a especificação de campo "obtru-ção". As duas caixas" têm "etiquetas" que são ou "não" ou "sim".

Segue-se uma breve descrição de um formato apresentado nas primeiras poucas linhas do ficheiro de estrutura exemplar mostrado no Apêndice A.

LIGAÇÃO ID. Uma cadeia de caracter única e explicativa mostrando a relação entre os dois objectos que liga. DESCRIÇÃO: Uma versão mais longa da ID, não necessariamente única, a ser estampada para o utilizador. MULTI-DONO: Especifica se esta ligação tem ou não tem multi-donos. MULTI-MEMBRO: Especifica se esta ligação tem ou não múltiplos membros. DE: Especifica o objecto "dono". FORMAÇÃO: Uma ligação de volta ao nome da estrutura global da qual está é uma parte. PARA: Especifica o objecto no "membro" final da ligação

CAIXA ETIQUETA: 0 nome correspondente a um valor particular VALOR: Especifica um valor numérico armazenado internamente correspondente à "etiqueta". DETERMINANTE: Especifica o campo ID que tem o tipo de campo "case" DE: Ligação de volta ao objecto. FORMAÇÃO: Uma ligação de volta ao nome da estrutura geral de qual faz parte.

CAMPO ID: 0 nome do campo TIPO: Especifica o tipo de campo (tal como cadeia de carácter, ponto flutuante, e assim por diante). COMPRIMENTO: 1) Comprimento da Cadeia; 2) Numérico—quantos caracteres a mostrar, normalmente na representação déci-mal. PREC: Quantas posições decimais a mostrar normalmente na representação decimal VIS: Vivivel ao utilizador ou totalmente escondida. AJUDA: Referência a uma mensagem de ajuda que explica o significado deste campo. PRÉ-ENTRADA: Função chamada antes de editar um campo. PÓS-ENTRADA: Função chamada após ter editado um campo. SÓ-FORMULA: Se este campo é ou não armazenado no registo, ou simplesmente calculado da fórmula cada vez que é necessário. FÓRMULA: Fórmula ou campo (se presente) baseado noutros campos. DE: Referência ao objecto FORMAÇÃO: Referência à estrutura global

OBJECTO ID: Nome do objecto. objectos a.·que se liga. DIMENSÃO: Anão grande é um registo deste objecto—calculado internamente com base em campos/ligações. DESENHO: Função de desenho por defeito para este objecto . PRÉ-ADIÇÃO: Função chamada antes de um novo registo deste tipo de objecto ser adicionado. PÓS-ENTRADA: Função chamado após um novo registo deste tipo de objecto foi adicionado ou modificada. FORMAÇÃO: Referência à estrutura da qual este objecto faz parte.

SISTEMA

Nome global da estrutura.

Com a descrição acima de um ficheiro de estrutura preferido exemplificativo para um programa de aplicações vulgarmente usado com o Ambiente Operativo de acordo com o encorporamento preferido da presente invenção, aqueles hábeis na matéria poderão praticar a invenção, incluin do o carregamento, a agregação, a resolução de conflitos de estruturas de diferentes programas de aplicações. Também os meios pelos quais os ficheiros de estruturas são carregados e agregados, com a resolução de conflitos dentro de Sistema de Dados em Lotes de acordo com o encorporamento preferido, está aqui disponível.

Claims

REIVINDICAÇÕES: li. - Sistema de gestão de espa -ços, caracterizado por compreender: (a) um primeiro programa de aplicações de gestão de espaços compreendendo: (1) uma série de ficheiros de suporte incluindo um ficheiro de estruturas; e (2) um ficheiro de funções; e (b) um Ambiente Operativo próprio para facilitar a execução do primeiro programa de aplicações, sozinho ou em colaboração com outros programas de aplicações com os respecti -vos ficheiros de estruturas, através da utilização de uma es -trutura de dados comum formada por uma agregação de estruturas de dados proveninetes dos ficheiros de estruturas do primeiro programa de aplicações e de qualquer outros programas de aplicações e dos respectivos ficheiros de estruturas. 2â. - Sistema de gestão de espa -ços, de acordo com a reivindicação 1, caracterizado por com -preender também: um segundo programa de aplicações independente do pri meiro programa de aplicações, que executa em colaboração com o pfimeiro programa de aplicações. 3â. - Sistema de gestão de espa -ços, de acordo com a reivindicação 2, caracterizado por o segundo programa de aplicações compreender um segundo ficheiro -172-

de estruturas que é diferente do ficheiro -de estruturas do pri. meiro programa de aplicações. 4â. - Sistema de gestão de espa -ços, de acordo com a reivindicação 1, caracterizado por com -preender também meios de adaptação ao cliente próprios para habilitar alterações escolhidas pelos utilizadores nos referi dos ficheiros de suporte. 5â. - Sistema de gestão de espa -ços, de acordo com a reivindicação 4, caracterizado por os re feridos meios de adaptação ao cliente incluírem meios próprios para receber uma primeira entrada escolhida pelo utilizador e meios que respondem a referida primeira entrada escolhida pelo utilizador, que foi recebida, por forma a visualizar uma série de escolhas possíveis de adaptação ao cliente. 6i. - Sistema de gestão de espa -ços, de acordo com a reivindicação 1, caracterizado por com -preender também meios de adaptação ao cliente próprios para habilitar alterações escolhidas pelos utilizadores nos referi dos ficheiros de estruturas. 7â. - Sistema de gestão de espa -ços, de acordo com a reivindicação 6, caracterizado por os re feridos meios de adaptação ao cliente incluírem meios próprios para receber no referido ficheiro as alterações escolhidas pelos utilizadores de estruturas, meios próprios para conservar no referido ficheiro de estruturas as referidas alterações escolhidas pelos utilizadores que foram recebidas ezmeios que respondem às referidas alterações escolhidas pelos utilizadores, que foram conservadas, a fim de fazer arrancar novamente o siistema de gestão de espaços. -173-

8ã. - Sistema de gestão de espa -ços, caracterizado por compreender: (a) um primeiro programa de aplicações de gestão de espaços compreendendo: (1) uma série de ficheiros de suporte incluindo um ficheiro de estruturas; e (2) um ficheiro de funções; e (b) um Ambiente Operativo próprio para facilitar a execução do primeiro programa de aplicações, sozinho ou em co laboração com outros programas de aplicações com os respecti-vos ficheiros de estruturas, através da utilização de uma estrutura de dados comum formada por uma agregação de estrutu -ras de dados provenientes dos ficheiros de estruturas prove -nientes do ficheiro de estruturas do primeiro programa de apli^ cações e de quaisquer outros programas de aplicações e dos respectivos ficheiros de estruturas, compreendendo o Ambiente Operativo. um ou mais módulos de dispositivo específico, do tipo daqueles que são constituídos por dados em lotes, que se podem interligar de uma maneira flexível a um ou mais módulos de fontes de dados em lotes a fim de se poderem ligar por meio de uma interface com uma variedade de armazéns de dados de estrutura variável de modo a transferir blocos de informação para os respectivos módulos dos armazéns de dados. 9§, - Sistema de gestão de espa -ços, caracterizado por compreender: (a) um primeiro programa de aplicações de gestão de espaços compreendendo: -174-

um ficheiro de estruturas? um ficheiro de menus; um ficheiro de cursos de teclas; um ficheiro macro; um ficheiro de concorrências; um ficheiro de observadores; um ficheiro de fontes de dados em lotes compreendendo um ou mais módulos de fontes de dados em lotes de alto nível para a especificação de características de transferência; um ficheiro de mensagens; e um ficheiro de funções; e (b) um Ambiente Operativo próprio para facilitar a execução do primeiro programa de aplicações, sozinho ou em colaboração com outros programas de aplicações com os respectivos ficheiros de estruturas, através da utilização de uma estrutura de dados comum formada por uma agregação de estruturas de dados provenientes dos ficheiros de estruturas provenientes do ficheiro de estruturas do primeiro programa de aplicações e de quaisquer outros programas de aplicações e dos respectivos ficheiros de estruturas, compreendendo o Ambiente Operativo um os mais módulos de dispositivo específico, do tipo daqueles que são constituídos por dados em lotes, que se podem interligar de uma maneira flexível a um ou mais módulos de fontes de dados em lotes a fim de se poderem ligar por meio de uma interface com uma variedade de armazéns de dados de es- -175- trutura variável de modo a transferir blocos de informação para os respectivos módulos dos armazéns de dados e a partir dos respectivos módulos dos armazéns de dados. Lisboa, 20 de Outubro de 1989

Agente Oílciá da Prspnsdads kâustrisl RUA VICTCFi CCRDSN, 10-A, 1.* 1200 LISBOA