ferramenta para administração de um sistema

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
FERRAMENTA PARA ADMINISTRAÇÃO DE UM SISTEMA
GERENCIADOR DE SUBMISSÕES BATCH
RELATÓRIO DE ESTÁGIO SUPERVISIONADO SUBMETIDO À UNIVERSIDADE
REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS DE
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA
COMPUTAÇÃO - BACHARELADO
MARCIO ELIAS GONÇALVES
BLUMENAU, JUNHO DE 1999.
1999/1-42
FERRAMENTA PARA ADMINISTRAÇÃO DE UM SISTEMA
GERENCIADOR DE SUBMISSÕES BATCH
MARCIO ELIAS GONÇALVES
ESTE TRABALHO DE ESTÁGIO SUPERVISIONADO FOI JULGADO ADEQUADO
PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO OBRIGATÓRIO PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
Prof. Everaldo Artur Grahl — Supervisor na Furb
Clóvis Murilo Vasselai — Orientador na Empresa
Prof. José Roque Voltolini da Silva — Coordenador na
FURB do Estágio Supervisionado
BANCA EXAMINADORA
Prof. Everaldo Artur Grahl
Prof. Wilson Pedro Carli
Prof. Luiz Heinzen
ii
DEDICATÓRIA
Dedico este trabalho de conclusão de curso à minha família, e em especial aos meus
pais Elias e Leonilda Maria Gonçalves, pelo esforço que fizeram para que eu chegasse até
aqui.
Dedico também à minha namorada, Silene Dalmolin , pelo incentivo e apoio durante
a realização deste trabalho.
iii
AGRADECIMENTOS
Gostaria de agradecer à Teclógica Serviços em Informática Ltda e em especial os
Srs. Clóvis Murilo Vasselai e Luiz Carlos Scheid pelo grande apoio e compreensão no
decorrer deste trabalho, bem como comentar também o quanto é bom trabalhar com estes
profissionais qualificados.
Agradecer ao professor Everaldo Artur Grahl, pelo incentivo, orientação e atenção
dispensada durante a supervisão do estágio.
Por fim, agradeço a todos que de um modo ou outro influenciaram na conclusão
deste trabalho.
iv
SUMÁRIO
Dedicatória ...........................................................................................................................iii
Agradecimentos .................................................................................................................... iv
Sumário ................................................................................................................................. v
Listas de figuras.................................................................................................................. viii
Resumo.................................................................................................................................. x
Abstract ................................................................................................................................ xi
1 Introdução........................................................................................................................... 1
1.1 Origem............................................................................................................................ 1
1.2 Objetivos ........................................................................................................................ 2
1.3 Organização .................................................................................................................... 2
2 Conceitos de Banco de Dados............................................................................................ 4
2.1 Sistemas de Banco de Dados ........................................................................................... 4
2.2 Arquitetura de um Sistema de Banco de Dados ............................................................... 6
2.3 Banco de Dados Relacional............................................................................................. 6
2.4 Banco de Dados ORACLE.............................................................................................. 7
2.5 Estruturas do Banco de Dados Oracle.............................................................................. 8
2.5.1 Estruturas Lógicas ........................................................................................................ 9
2.5.2 Estruturas Físicas ........................................................................................................ 11
3 Ferramentas de Desenvolvimento .................................................................................... 12
3.1 FORMS 4.5................................................................................................................... 12
3.1.1 Navegador .................................................................................................................. 15
3.1.2 Editores e Propriedades............................................................................................... 16
3.2 Reports 2.5.................................................................................................................... 17
v
3.2.1 Navegador .................................................................................................................. 19
3.2.2 Editores do REPORT 2.5 ............................................................................................ 20
4 Ferramenta CASE DESIGNER/2000............................................................................... 23
4.1 Introdução..................................................................................................................... 23
4.2 Método CASE da ORACLE.......................................................................................... 23
4.3 Ferramentas do DESIGNER/2000 1.3.2 ........................................................................ 24
4.3.1 Entity Relationship Diagrammer ................................................................................. 25
4.3.2 Data Flow Diagrammer............................................................................................... 26
4.3.3 Function Hierarchy Diagrammer................................................................................. 26
4.3.4 Data Schema............................................................................................................... 27
4.3.5 Module Structure Diagrammer.................................................................................... 27
4.3.6 Forms Generator ......................................................................................................... 27
4.3.7 Reports Generator....................................................................................................... 28
5 Estrutura do Sistema Operacional Unix ........................................................................... 29
5.1 Histórico do Sistema Operacional UNIX...................................................................... 29
5.2 Recursos do Unix.......................................................................................................... 30
5.3 Sistema Hierárquico de Arquivos .................................................................................. 33
5.4 Multitarefa .................................................................................................................... 33
5.5 Multiusuário.................................................................................................................. 34
6 Sistema de Utilitários da Souza Cruz ............................................................................... 35
6.1 Histórico ....................................................................................................................... 35
6.2 Impactos com a Migração ............................................................................................. 35
6.3 Visão Geral................................................................................................................... 36
6.4 Modelo de Dados da Submissão Batch.......................................................................... 37
6.5 Funcionamento do Scheduler ........................................................................................ 37
vi
6.5.1 Pedidos de Execução de Processos.............................................................................. 38
6.5.2 Pedidos de Impressão.................................................................................................. 38
7 Interface do Administrador do Sistema............................................................................ 39
7.1 Apresentação e Objetivos da Ferramenta....................................................................... 39
7.2 Especificação da Ferramenta ......................................................................................... 40
7.3 Módulos da Ferramenta do Administrador.................................................................... 40
7.3.1 Tela Principal ............................................................................................................. 41
7.3.2 Itens do Menu Opções ................................................................................................ 42
8 Conclusões ...................................................................................................................... 55
Referências Bibliográficas ................................................................................................... 56
Glossário e Termos....................................................................................................................58
Anexo 1 Modelo Entidade Relacionamento do Sistema de Submissão Batch ..................... 599
Anexo 2 Modelo Entidade Relacionamento da Ferramenta Interface do Administrador........ 68
Anexo 3 Modelo Físico de Dados da Ferramenta Interface do Administrador....................... 70
Anexo 4 Modelo Hierárquico dos Módulos da Ferramenta Interface do Administrador ........ 72
Anexo 5 Relatórios da Ferramenta Interface do Administrador ............................................ 74
vii
LISTA DE FIGURAS
Figura 1 : Sistema de banco de dados......................................................................................... 4
Figura 2 : Níveis da arquitetura de um banco de dados ............................................................... 6
Figura 3 : Visão geral das ferramentas do FORMS 4.5 ............................................................ 12
Figura 4 : Visão de um módulo form base table block .............................................................. 13
Figura 5 : Visão de um módulo form control block................................................................... 14
Figura 6 : Componentes de um form ........................................................................................ 15
Figura 7 : Object Navigator do FORMS 4.5 ............................................................................. 16
Figura 8 : Visão geral das ferramentas do REPORTS 2.5 ......................................................... 17
Figura 9 : Componentes de um report ...................................................................................... 19
Figura 10 : Object Navigator do REPORTS 2.5 ....................................................................... 20
Figura 11 : Data model editor .................................................................................................. 21
Figura 12 : Layout editor.......................................................................................................... 21
Figura 13 : Tela de parâmetros em um report........................................................................... 22
Figura 14 : Tela principal do DESIGNER/2000 1.3.2............................................................... 25
Figura 15 : Arquitetura modular do UNIX................................................................................ 31
Figura 16 : Tela principal da ferramenta Interface do Administrador........................................ 41
Figura 17 : Menu da ferramenta Interface do Administrador .................................................... 42
Figura 18 : Inicialização do scheduler ...................................................................................... 43
Figura 19 : Finalização do scheduler ........................................................................................ 44
Figura 20 : Tela de configuração do scheduler ......................................................................... 45
Figura 21 : Log de execução do scheduler................................................................................ 47
Figura 22 : Log de impressão do scheduler............................................................................... 47
Figura 23 : Tela de parâmetros dos relatórios da ferramenta Interface do Administrador .......... 48
viii
Figura 24 : Tela de manutenção das filas de execução.............................................................. 49
Figura 25 : Tela de manutenção dos limites de submissão batch............................................... 50
Figura 26 : Tela de transferência de jobs programados ............................................................. 52
Figura 27 : Tela de manutenção dos formulários de impressão ................................................. 53
ix
RESUMO
Este trabalho descreve manutenções e melhorias sucedidas na aplicação de
submissão batch do Sistema de Utilitários da Souza Cruz e relata também os estudos
realizados com a intenção de viabilizar a execução deste projeto. Os temas descritos neste
trabalho abordam sistemas operacionais (UNIX) , banco de dados (ORACLE), ferramentas
CASE (DESIGNER/2000) e ferramentas de desenvolvimento (FORMS, REPORTS). Dentro
das manutenções previstas para a submissão batch de processos do Sistema de Utilitários da
Souza Cruz foi desenvolvido uma ferramenta para o administrador do sistema utilizando
como recursos de desenvolvimento FORMS e REPORTS da ORACLE em modo caracter
mode. Esta nova versão do sistema de submissão batch encontra-se no momento em fase de
implantação.
x
ABSTRACT
This work describes the maintenance and updating of the submission batch of the
utility system of Souza Cruz and also shows the studies involved in the preparation of this
project. The subjects described in this work are operational system (UNIX), database
(ORACLE), tools CASE (DESIGNER/2000) and developing tools (FORMS, REPORTS). In
the expected maintenance of the submission batch of the utility system of Souza Cruz, it was
developed a special tool for the administrator of the system, using as developing resources the
FORMS and REPORTS of ORACLE in caracter mode. This new version of the batch
submission system is under the implantation phase at the moment.
xi
1
1 INTRODUÇÃO
1.1 ORIGEM
A crescente demanda de produtos e serviços nas empresas faz com que aumente
também
a massa de informações sobre os mais variados assuntos nas empresas. Estas
informações são recursos muito valiosos para as empresas. Diante disto, a empresa Souza
Cruz tem a preocupação de gerenciar da melhor maneira possível suas informações, provendo
maior segurança e técnicas mais rápidas para a recuperação e processamento de seus dados.
O Sistema de Utilitários da Souza Cruz conhecido como DUT (sigla que o
identifica) é um sistema com essas características e que possui duas funções distintas:
a) controle de acesso dos programas às bases de dados;
b) gerência dos pedidos de submissão batch dos usuários.
A segurança da informação hoje é um ponto muito significativo para as empresas e é
algo tratado com muita cautela, pois existem dentro de uma companhia informações dos mais
variados tipos. É através do controle dos programas à base de dados que o sistema DUT
consegue manter de forma mais segura o controle de seus dados, não deixando que programas
executem em sites não permitidos, que usuários executem funções não cabíveis aos seus
perfis , e que dados sejam manipulados por programas não liberados [CAS96].
Um outro aspecto importante para as empresas hoje é a viabilidade de utilizar os
recursos computacionais com o intuito de melhorar a qualidade de seus sistemas (como
também a estrutura de seus negócios) para uma maior satisfação dos usuários. Com esta
intenção, o DUT implementa também um gerenciamento do pedidos de submissão batch dos
usuários que é um recurso utilizado para executar nos seus servidores relatórios complexos
(Oracle Reports Character Mode), programas PL em SQLPLUS e shells em UNIX [MIT95].
Assim então, os usuários podem executar programas em background (processos que
executam independente da sessão do usuário), determinar prioridades para estes programas,
visualizar relatórios, visualizar log’s de execução, apontar filas de impressão para processos
já executados e aproveitar desta maneira melhor os recursos de informática da empresa. Um
ponto bastante importante também é que, com a execução em background, os usuários podem
utilizar seus terminais (micro computadores) normalmente para continuarem seus trabalhos,
2
sem a necessidade de ficar com a máquina presa até o final da execução dos programas
[CAS96].
O sistema de utilitários da Souza Cruz (DUT) representa hoje para a empresa uma
grande ferramenta e é utilizado por todas as suas unidades no país, porém necessita de
grandes modificações e implementações para suprir as necessidades atuais da empresa.
1.2 OBJETIVOS
O objetivo principal deste estágio é prover manutenções e melhorias necessárias na
aplicação submissão batch do sistema de utilitários da Souza Cruz (DUT), isto para tornar as
submissões batch nos servidores mais robustas (visto que no momento atual a aplicação
possui problemas e necessita de novos recursos). Será desenvolvida uma ferramenta em
FORMS e REPORTS da ORACLE para que o administrador responsável pelas submissões
possa monitorar os processos submetidos. Para isto, será utilizada a ferramenta
DESIGNER/2000 da ORACLE para prover as atualizações necessárias no modelo de dados
do sistema.
1.3 ORGANIZAÇÃO
A seguir serão descritos brevemente o assunto abordado em cada capítulo do
trabalho.
No segundo capítulo serão vistos os conceitos básicos de banco de dados relacional
como também conceitos específicos e a funcionalidade do banco de dados ORACLE, isto
com o objetivo de aprofundar o conhecimento sobre o ambiente de trabalho do Sistema de
Utilitários da Souza Cruz.
O terceiro capítulo aborda as ferramentas de desenvolvimento FORMS e REPORTS
da ORACLE, procurando dar uma visualização rápida de como são os procedimentos de
desenvolvimento nestes ambientes.
No quarto capítulo
será abordado como segue o processo de documentação e
desenvolvimento de software na ferramenta CASE DESIGNER/2000.
O quinto capítulo apresenta a estrutura do sistema operacional UNIX, visto que o
sistema de submissões batch da Souza Cruz utiliza este tipo de plataforma.
3
No capítulo 6 é apresentado um breve histórico e explanado o funcionamento do
Sistema de Utilitários da Souza Cruz referente às submissões batch, isto justamente para
visualizar o sistema e facilitar o entendimento dos conceitos implementados na nova
ferramenta para o administrador do sistema.
No sétimo capítulo é apresentada a ferramenta Interface do Administrador,
procurando descrever os objetivos para os quais foi projetada e descrever o seu
funcionamento.
No oitavo capítulo são apresentadas as principais conclusões e sugestões do trabalho.
4
2 CONCEITOS DE BANCO DE DADOS
Este capítulo tem como objetivo prover ao leitor conceitos básicos de banco de dados
relacional como também conceitos específicos e a funcionalidade do banco de dados
ORACLE.
2.1 SISTEMAS DE BANCO DE DADOS
Sistema de banco de dados é basicamente um sistema de manutenção de registros por
computador – ou seja, um sistema cujo objetivo global é manter informações e torná-las
disponíveis quando solicitadas. Trata-se de qualquer informação significativa ao indivíduo ou
à organização servida pelo sistema – em outras palavras, que seja necessária ao processo de
tomada de decisão daquele indivíduo/organização. A figura 1 mostra uma visão de um
sistema de banco de dados [DAT91].
GERENCIADOR DO SISTEMA DE BANCO
DE DADOS (DBMS).
BANCO DE DADOS
PROGRAMAS
DE APLICAÇÃO
USUÁRIOS FINAIS
Fonte: [DAT91]
Figura 1. Sistema de banco de dados
5
A figura 1 mostra que um sistema de banco de dados envolve quatro componentes
principais [DAT91]:
a) Dados: consiste na totalidade dos dados armazenados em um banco de dados.
Uma série de arquivos agrupados que aparecem para o usuário como se fosse um
único arquivo de dados. Estes dados são integrados e podem ser compartilhados
entre diversos usuários ou serem de uso exclusivo de um único usuário;
b) Hardware: é a plataforma onde reside o banco de dados. É considerado um fator
determinante em questões que envolvam o compartilhamento do banco de dados,
ou seja, se o banco de dados será utilizado por vários usuários ou se apenas será
utilizado por um único usuário;
c) Software: é a interface entre o banco de dados físico e os usuários do sistema.
Todas as solicitações de acesso ao banco de dados feitas pelos usuários são
manipuladas por estes softwares, os quais são comumente conhecidos como
Sistema Gerenciador de Banco de Dados (SGDB), nome que provêm do inglês
Database Management System (DBMS). Sua função é isolar os usuários do
banco de dados dos detalhes a nível de hardware, ou seja, fazer com que os
usuários tenham uma visão do banco de dados acima do nível de hardware,
suportando suas operações de manipulação dos dados como inserções, exclusões,
alterações e consultas a um nível mais alto e amigável;
d) Usuários: os usuários são o conjunto de pessoas que irão acessar as informações
armazenadas em um banco de dados. Existem três grandes classes de usuários: os
programadores de aplicações, que seriam responsáveis pela definição de
programas que utilizam alguma linguagem de programação de aplicativos de
banco de dados; os usuários finais, que interagem com o sistema a partir de um
terminal on-line, utilizando alguma aplicação ou linguagem de consulta; e os
administradores de banco de dados, que seria uma pessoa ou um grupo de
pessoas que detêm a responsabilidade central sobre os dados armazenados no
banco.
6
2.2 ARQUITETURA DE UM SISTEMA DE BANCO DE
DADOS
Segundo [DAT91], na maioria dos sistemas de banco de dados pode-se dividir a
arquitetura dos sistemas em três níveis gerais chamados:
a) nível interno: este nível é o mais próximo ao armazenamento físico do dados,
isto é, relaciona-se à forma de como os dados são realmente armazenados;
b) nível externo: este é o nível mais próximo aos usuários, ou seja, é a forma como
os dados são vistos pelos usuários de forma individual;
c) nível conceitual: é o nível intermediário entre o nível interno e externo, sendo
então, toda a representação de informações do banco de dados.
A figura 2 ilustra este níveis da arquitetura de um sistema de banco de dados:
Nível Externo
(visões do usuário)
Nível Conceitual
(visão do conjunto de usuários)
Nível Interno
(visão do armazenamento)
Fonte: [DAT91]
Figura 2. Níveis da arquitetura de um banco de dados
2.3 BANCO DE DADOS RELACIONAL
Segundo [DAT91], um banco de dados é conhecido como relacional quando seus
dados são vistos pelo usuário somente como um conjunto de tabelas, onde as informações
7
ficam armazenadas em tabelas (logicamente) de acordo com os tipos de informação e
estruturas.
As tabelas de um banco de dados são definidas por linhas e colunas onde ficam
armazenados os dados. Cada coluna pode armazenar um determinado tipo de informação
podendo possuir características próprias como tipo de dado e tamanho. Já cada linha da
tabela corresponde aos registros que serão eventualmente armazenados no banco.
Cada linha de uma tabela pode também possuir uma chave que a identifique
unicamente. Esta chave pode ser uma coluna ou um conjunto de colunas cujos valores não são
duplicados e também não são nulos.
2.4 BANCO DE DADOS ORACLE
O ORACLE é um sistema gerenciador de banco de dados relacional (RDBMS) que
possibilita o armazenamento de um grande volume de informações e torna estas disponíveis
para manipulação por parte dos usuários. Os dados são armazenados na forma de tabelas
bidimensionais (linhas e colunas) e entre estas tabelas podem ser definidos relacionamentos.
O ORACLE é mais que um conjunto de programas que facilitam o acesso aos dados,
podendo ser comparado a um sistema operacional sobreposto ao sistema operacional do
computador onde reside. Possui suas próprias estruturas de arquivo, de buffer, memória e uma
capacidade de se ajustar muito além das capacidades fornecidas no sistema operacional. O
ORACLE controla seus próprios processos, monitora seus registros, faz consistências e
limpezas de memória.
O banco de dados ORACLE quando está em operação, consiste de uma série de
eventos que acontecem sobre o banco. Segundo [ORA92], os principais tipos de eventos que
podem ocorrer são:
a) transações: unidade lógica de trabalho composta por um ou mais comandos
SQL, executados por um único usuário. No ORACLE, os efeitos de uma
transação podem ser aplicados definitivamente ao banco de dados com um
comando commit ou desfeitos através de um comando rollback. Contudo, uma
transação começa com a execução de um comando SQL pelo usuário e termina
8
com a execução de um commit (aplicando os efeitos da transação ao banco de
dados) ou com um rollback (desfazendo os efeitos da transação);
b) bloqueio (locks): bloqueios são mecanismos utilizados para controlar o acesso
concorrente a um determinado recurso. Sua principal finalidade é evitar que uma
transação destrua os efeitos de outra transação. Os locks podem ser de dois tipos,
os causados pelos comandos do tipo DML (Data Manipulation Language) e os
causados por comandos do tipo DDL (Data Definition Language). Os locks são
utilizados para realizar duas importantes metas, a consistência (assegura que os
dados vistos ou alterados por um usuário não sejam alterados por outro enquanto
a transação não for finalizada) e a integridade dos dados (assegura que os dados e
estruturas reflitam todas as trocas em uma seqüência correta). Os locks garantem
a integridade dos dados, enquanto admitem um máximo acesso concorrente por
usuários ilimitados;
c) sessões (sessions): uma sessão especifica uma conexão ao banco de dados via
processo do usuário. Quando o usuário conecta-se à base de dados, precisa
informar uma conta e uma senha válidos para que a sessão seja estabelecida.
Múltiplas sessões podem ser criadas por um mesmo usuário, mas cada uma delas
é considerada como uma sessão diferente.
2.5 ESTRUTURAS DO BANCO DE DADOS ORACLE
Segundo [ORA92], os três principais aspectos do modelo relacional no qual o
ORACLE se baseia são as estruturas, as operações e as regras de integridade.
As estruturas são os objetos que guardam os dados de um banco de dados. Essas
estruturas e os dados podem ser manipulados através de operações.
As operações são as ações que permitem aos usuários manipular os dados e as
estruturas de um banco de dados. Essas operações devem aderir a um conjunto de regras de
integridade predefinidas.
As regras de integridade são as leis que governam quais operações são permitidas
nos dados e nas estruturas de um banco de dados, com o propósito de protegê-los de
operações indevidas.
9
Um banco de dados ORACLE possui estruturas físicas e lógicas que são
independentes entre si, isto é, as estruturas físicas podem ser gerenciadas sem afetar o acesso
às estruturas lógicas.
2.5.1 ESTRUTURAS LÓGICAS
As estruturas lógicas são os objetos que estão armazenados na base de dados e que
são manipulados pelos usuários. Conforme [MOR95], as estruturas lógicas são determinadas
por uma ou mais tablespaces e pelos objetos dos esquemas dos usuários de um banco de
dados.
Essas estruturas lógicas, incluindo os segmentos, extensões e bloco de dados ditam como
o espaço físico de um banco de dados é usado.
Segundo [MOR95], seguem as principais estruturas lógicas de um banco de dados
ORACLE:
a) tablespaces: são unidades lógicas de armazenamento dos dados usadas para
agrupar outras estruturas lógicas relacionadas entre si. Um ou mais arquivos de
dados são criados explicitamente para cada tablespace, isto é, cada tablespace é
formada por um ou mais arquivos no sistema operacional, chamados de data
files, armazenados em disco. As tablespaces são utilizadas para controlar a
alocação do espaço em disco para os dados de um banco de dados, assinalar
quotas específicas de espaço para os usuários, controlar a disponibilidade dos
dados, executar operações parciais de cópia e recuperação de um banco de dados,
e alocar o armazenamento dos dados entre diferentes dispositivos para melhorar a
performance de um banco de dados;
b) data block: os blocos de dados formam as estruturas lógicas de menor nível em
um banco de dados. Um bloco de dados corresponde a um número específico de
bytes guardados fisicamente em disco. O tamanho dos blocos de dados é
específico a cada banco de dados e sistema operacional, sendo definido na
criação do banco de dados. Este tamanho é um múltiplo do bloco do sistema
operacional e forma a menor unidade de I/O em um sistema de banco de dados
ORACLE;
10
c) extents: as extensões são o próximo nível de estruturação lógica de um banco de
dados, após os blocos de dados. Uma extensão é um número específico de blocos
de dados contínuos, obtidos em uma simples alocação. Estes blocos são usados
para guardar um tipo específico de informação;
d) segments: os segmentos são o nível imediatamente superior às extensões, usados
para armazenar
os dados. Um segmento é um conjunto de extensões
alocadas para um certo tipo de estrutura lógica que fica guardado em uma
tablespace, existindo assim diferentes tipos de segmentos (segmentos de dados,
índices, rollback);
e) schema objects: um esquema é uma coleção de objetos ligados à identificação
única de um usuário em um banco de dados, ou seja, é o local onde são
armazenados os objetos de um determinado usuário;
f) objects: Os objetos são todos os tipos de estruturas lógicas que referenciam
diretamente os dados de um banco de dados, tais como, tabelas, visões,
seqüências, sinônimos, índices, clusters entre outros;
g) tables: uma tabela é uma unidade básica usada para guardar os dados de um
banco de dados, contendo todos os dados acessíveis pelos usuários. Uma tabela é
formada por linhas e colunas, possuindo um único nome que a identifica. Cada
coluna da tabela possui um único identificador, um tipo de dado associado e uma
definição de tamanho;
h) views: uma visão é a representação customizada dos dados de uma ou mais
tabelas. Uma visão não armazena dados, simplesmente contém comando SQL
usado para realizar consultas. Uma visão é vista pelo usuário como se fosse uma
tabela, sendo possível a este realizar operações de consulta, inserção, alteração e
deleção;
i) sequences: as seqüências são objetos do banco de dados que fornecem números
seqüenciais. Elas são úteis para gerar valores de chave exclusiva para entrada de
colunas do tipo numérico, onde a entrada deve ser única ou uma seqüência
numérica;
j) synonyms: um sinônimo é um apelido para um objeto do banco de dados. Os
sinônimos podem ser públicos quando acessados por todos os usuários de um
11
banco de dados, ou privados quando criado por um usuário e somente está
disponível a este usuário;
k) Indexes: os índices são estruturas que possibilitam o acesso mais rápido a uma
informação, melhorando a performance de acesso aos dados e podendo também
garantir a unicidade dos valores armazenados nas colunas que os compõem . São
criados a partir de uma ou mais colunas de uma tabela.
2.5.2 ESTRUTURAS FÍSICAS
As estruturas físicas de um banco de dados são determinadas pelos arquivos do
sistema operacional que constituem o banco de dados. Conforme [ORA92], cada banco de
dados ORACLE possui três tipos de arquivos que formam sua estrutura física, os quais são
descritos a seguir:
a) Arquivos de dados (Data Files): cada banco de dados ORACLE possui um ou
mais arquivos de dados em disco, os quais contêm todos os dados de um banco
de dados e são usados para armazenar fisicamente os dados das estruturas lógicas
como tabelas, índices, etc. Segundo [MOR95], os arquivos de dados podem ser
associados a somente um banco de dados e uma vez criados não podem ter o seu
tamanho alterado. Um ou mais arquivos de dados formam uma unidade lógica de
armazenamento de dados chamada tablespace;
b) Arquivos de Redo Log (Redo Log Files): cada banco de dados possui um ou
mais arquivos para recuperação do banco de dados. Conforme [MOR95], os
arquivos de redo log registram um histórico de todas as alterações feitas nos
dados de um banco de dados. As informações registradas são utilizadas para
recuperação do banco de dados em caso de falha do sistema;
c) Arquivos de Controle (Control Files): Segundo [MOR95], todo banco de dados
possui um ou mais arquivos de controle onde são registradas as estruturas físicas
que compõem um banco de dados, contendo informações como o nome do banco
de dados, os nomes e localização dos arquivos de dados e arquivos redo log que
compõem o banco de dados, e outros vários tipos de informação. Toda vez que o
banco de dados é inicializado, o arquivo de controle é lido a fim de identificar os
arquivos de dados e redo log
operações.
que devem ser abertos para realização das
12
3 FERRAMENTAS DE DESENVOLVIMENTO
Este capítulo tem como objetivo prover ao leitor uma abordagem sobre as
ferramentas de desenvolvimento FORMS 4.5 e REPORTS 2.5 da ORACLE, procurando dar
uma visualização rápida de como são os procedimentos
de desenvolvimento nestes
ambientes.
3.1 FORMS 4.5
A ferramenta DEVELOPER/2000 FORMS 4.5 é uma ferramenta que disponibiliza
aos programadores várias facilidades de desenvolvimento de aplicações quando se trata da
utilização de banco de dados, tendo como objetivo também fornecer ao usuário final
aplicações com interfaces amigáveis e com fácil modo de utilização.
A figura 3 mostra a ferramenta FORMS 4.5:
Fonte: [ORA94]
Figura 3. Visão geral das ferramentas do FORMS 4.5
13
Quando se cria uma nova aplicação FORMS pode-se trabalhar com três tipos de
módulos: menus, forms e librarys. O módulo form é o corpo principal de uma aplicação
FORMS e será utilizada como foco para definir e para dar uma breve explanação desta
ferramenta.
Segundo [ORA94], um módulo form é uma coleção de objetos e dados usados que
interagem com modificações em tabelas no banco de dados. Tipicamente, um form contém
vários blocos no qual estes blocos são containers lógicos para os objetos. Existem dois tipos
de blocos:
a) base table block: estes são blocos associados com tabelas do banco de dados e
que interagem diretamente com elas;
b) control block: estes são blocos não baseado em tabelas.
Na construção de aplicações de banco de dados com FORMS, muitos dos blocos são
associados com específicas tabelas ou visões do banco de dados. Quando base table block são
utilizados, links das colunas das tabelas do banco de dados são criadas com os itens de
interface do form. Um base table block automaticamente suporta funcionalidades de
consultas, alterações, inserções e deleções de dados na tabela a qual o bloco está associado.
A figura 4 mostra um módulo form utilizando um bloco no modo base table block:
Fonte: [ORA94]
Figura 4. Visão de um módulo form base table block
14
Já os control block e seus itens não são associados com o banco de dados, ou seja
control block são usualmente utilizados para executar funções nas aplicações como para obter
e mostrar informações baseados em operação e entrada de dados. Quando se define um
control block, simplesmente se assume as opções defaults do new block window, e então criase o número desejado de itens de interface e então soma-se o código que define cada item
proposto. Freqüentemente se utiliza control block para desenvolver botões de atalho (toolbar
buttons), para se inicializar transações no banco de dados ou para se executar navegação no
form.
A figura 5 mostra um módulo form utilizando um bloco no modo control block:
Fonte: [ORA94]
Figura 5. Visão de um módulo form control block
Segundo [ORA94], um form não só contém vários itens de interface para o usuário,
como também contém procedimentos e definições de origem de dados. Em tempo de
execução os itens de interface e outros elementos aparecem em uma janela conhecida como
canvas. O canvas é uma superfície desenhada que é visualizada em uma janela e é onde os
objetos são arranjados e mostrados.
15
A figura 6 mostra todos os componentes de um módulo form:
Fonte: [ORA94]
Figura 6. Componentes de um form
3.1.1 NAVEGADOR
O object navigator é uma janela da aplicação FORMS que provê ao programador
uma árvore hierárquica contendo todos os objetos definidos em todos os módulos abertos no
momento. O object navigator é muito útil para o programador e é utilizado para visualizar ou
criar, copiar e selecionar objetos [ORA94] .
Os objetos do forms são agrupados em diferentes nodos no object navigator, os
nodos são separados em heading nodos, estes são os cabeçalhos dos nodos que definem que
tipo de objetos aparecerão abaixo deles.
Os nodos de topo no navigator incluem Forms, Menus, Librarys, Built-in Packages e
Objects Database, todos os outros nodos e objetos neles contidos estão indentados na árvore
indicando que eles estão em um nível mais baixo, pertencendo a um nodo de mais alto nível.
Para uma melhor compreensão do funcionamento do object navigator veja a figura 7.
16
Fonte: [ORA94]
Figura 7. Object Navigator do FORMS 4.5
3.1.2 EDITORES E PROPRIEDADES
O FORMS possui também no seu ambiente de desenvolvimento dois editores (áreas
de trabalho para criar e modificar a forma dos objetos) e uma janela de propriedades (mostra
uma lista de categorias de propriedades dos objetos) bastante utilizados. A figura 3 mostrada
anteriormente dá uma breve visão destas ferramentas.
O Layout editor é um editor utilizado no FORMS para criar, formatar e arranjar itens
de interface e os nomes associados a estes itens.
O Layout PLSQL é um editor utilizado para gerar códigos PLSQL , como
procedimentos e triggers utilizados pelo form.
E por fim, a janela Properties window é utilizada para inspecionar e modificar
propriedades dos objetos definidos no form.
17
3.2 REPORTS 2.5
A ferramenta DEVELOPER/2000 REPORTS 2.5 é uma ferramenta que disponibiliza
aos programadores várias facilidades de desenvolvimento de relatórios com qualidade e em
vários formatos como: tabular, matrix, master-detail, mailing label e form letter. O
REPORTS 2.5 também disponibiliza recursos como inclusão de textos, figuras , gráficos e
interação de botões nos relatórios. A interação de botões no relatório disponibiliza recursos
nos relatórios como poder disparar outros relatórios, executar comandos PLSQL, etc. Outra
facilidade desta ferramenta também é a opção de se especificar parâmetros (variáveis
informadas antes de um relatório iniciar a execução) para passar aos relatórios a serem
executados [ORA95].
A figura 8 mostra a ferramenta REPORTS 2.5:
Fonte: [ORA95]
Figura 8. Visão geral das ferramentas do REPORTS 2.5
Segundo [ORA95], um report é uma coleção de objetos que define nele dados,
layout e interface em tempo de execução. Os dados de um report são definidos em um data
model. Os data model definem quais os dados que devem ser buscados do banco de dados, a
ordem desses dados e então processam estes dados para um relatório.
Como sub-ítens de um data model existem query, group ,columns e parameters:
18
a) Query: consulta os dados de um banco de dados padrão, como ORACLE, DB2,
SQL/DS – usando comandos SQL;
b) Group: organiza os dados dentro de conjuntos e hierarquias. O group contém
todas as colunas de uma consulta;
c) Columns: são as colunas do banco selecionadas por uma consulta;
d) Parameters: são variáveis do relatório para as quais o usuário pode associar
valores em tempo de execução.
Com isso então, após a definição de um data model para um report específico, o
programador deve especificar o layout do report. O layout especifica como os objetos do data
model aparecerão na tela em tempo de execução (como eles são formatados) .
O layout de um report é definido em field, frame, repeating frame e body:
a) Field: são os espaços reservados para as colunas das tabelas. São eles que
definem como as colunas irão aparecer no relatório, bem como o formato de
somas, datas e outros itens contidos nos relatórios;
b) Frame: os frames são usados para organizar o layout de vários objetos juntos.
Eles também são usados para proteger o layout dos objetos de serem sobreescritos por reapeting frames em tempo de execução;
c) Reapeting Frame: são espaços reservados para group’s, ou seja, vários conjuntos
de colunas juntos. São eles que formatam os registros no relatório e que buscam
os dados do banco de dados.
A figura 9 ajuda a definir melhor os conceitos de data model e layout , como também
o itens de cada um deles.
19
Fonte: [ORA95]
Figura 9. Componentes de um report
3.2.1 NAVEGADOR
O object navigator é um painel de controle que permite ao programador visualizar e
editar seus reports. Ele mostra todos os objetos definidos em todos os reports abertos no
momento em forma hierárquica [ORA95]. Veja que este conceito de painel também é
utilizado na ferramenta FORMS (Figura 7).
Como no FORMS, o object navigator é contido por vários nodos. Alguns nodos são
cabeçalhos que definem que tipo de objetos aparecerão abaixo deles. O navigator é
utilizado também no REPORTS para mostrar editores (áreas de trabalho para criar e modificar
objetos em um report).
Na figura 10 é dada uma melhor visualização do object navigator na ferramenta
REPORT 2.5:
20
Fonte: [ORA95]
Figura 10. Object Navigator do REPORTS 2.5
3.2.2 EDITORES DO REPORT 2.5
A ferramenta ORACLE REPORT 2.5 disponibiliza ao programador três tipos de
editores [ORA95] , que são:
a) Data Model Editor: este editor permite ao programador definir as consultas a
serem executadas no banco de dados, relacionamento entre esses dados, bem
como criar sumários e fórmulas para um determinado relatório (Veja figura 11);
b) Layout Editor: O layout editor permite ao programador definir a aparência dos
relatórios, permitindo ao programador customizar os objetos, tal como, definir
frames e fields nas diferentes seções de um relatório, ou seja, no cabeçalho do
relatório, nas margens, no corpo, etc (Veja figura 12);
c) Parameter Form Editor: Este editor permite ao programador definir a aparência
da tela de parâmetros, permitindo definir o layout e as variáveis que serão
solicitadas pelo relatório em tempo de execução (Veja figura 13).
21
Fonte: [ ORA95]
Figura 11. Data model editor
Fonte: [ORA95]
Figura 12. Layout editor
22
Fonte: [ORA95]
Figura 13. Tela de parâmetros em um report
23
4 FERRAMENTA CASE DESIGNER/2000
4.1 INTRODUÇÃO
As ferramentas CASE se propõem a auxiliar no processo de desenvolvimento de
sistemas sob a forma de um suporte computadorizado. As ferramentas auxiliam no
desenvolvimento de sistemas aumentando a produtividade de seus analistas, projetistas e
programadores.
Para a utilização de uma ferramenta CASE de forma produtiva é importante definir
um método de desenvolvimento de sistemas. Com a utilização de ferramentas CASE o
desenvolvimento de sistemas fica padronizado, pois quanto mais abrangente são os padrões,
maiores as possibilidades de ganho em produtividade.
Uma ferramenta CASE pode abranger todo o ciclo de um projeto de
desenvolvimento de sistemas ou apenas parte deste ciclo. A seleção de uma ferramenta CASE
depende das diversas etapas pretendidas do ciclo de vida do projeto, das técnicas selecionadas
e do ambiente de desenvolvimento e operação dos sistemas.
Segundo [CAR89] a ferramenta CASE fornece um base de dados para a engenharia
de sistemas e uma série de facilidades que automatizam as técnicas durante todo o ciclo de
vida do sistema.
4.2 MÉTODO CASE DA ORACLE
Segundo [DEF93] o método CASE da ORACLE procura tornar o ambiente
automatizado o mais próximo possível da realidade da Engenharia de Sistemas. Os processos
de desenvolvimento são baseados em sete passos básicos que são descritos em:
a) Estratégia: neste passo os processos e as informações necessárias para o trabalho
são estabelecidas. Primeiro através de visões gerais e depois com o
desenvolvimento do modelo de trabalho. Este modelo estando de acordo com os
analistas de sistemas, fornece um conjunto de objetivos e intenções claras, que
por si, formam a estrutura do sistema;
24
b) Análise: na análise são definidos os detalhes das funções do sistema, as entidades
envolvidas e o fluxo de dados, estendendo uma maior profundidade de
entendimento estabelecida no passo anterior, de modo a documentar as
necessidades precisas da aplicação em desenvolvimento;
c) Projeto: é nesta fase que começa a implementação, onde é definido o mecanismo
de armazenamento de dados. São definidos os módulos que implementam as
funções definidas na análise. Além disso são definidas a arquitetura do sistema e
os modos de transação entre os módulos;
d) Construção: é na construção que são desenvolvidos todos os componentes do
sistema, ou seja, as tabelas são criadas, os módulos são codificados e testes são
efetivados sobre todos os componentes;
e) Documentação: A documentação é elaborada praticamente em todas as fases de
desenvolvimento do sistema. Podendo ser gerados relatórios, tabelas de
performance, matrizes, documentação em linha de código. Isto tudo no decorrer
do desenvolvimento do sistema ou após o fim do processo;
f) Transição: Nesta fase o novo sistema é cuidadosamente inserido na empresa.
Novos procedimentos, documentação e treinamento são feitos para preparar a
equipe de operação do sistema;
g) Produção: Na fase de produção o sistema já está livremente funcionando na
empresa, porém uma equipe ainda fica locada e atenta para corrigir diversos erros
que porventura possam aparecer nesta fase.
4.3 FERRAMENTAS DO DESIGNER/2000 1.3.2
São abordadas aqui, algumas das ferramentas integrantes da ferramenta CASE
DESIGNER/2000 1.3.2 da ORACLE, dando uma visão do objetivo e do potencial destas
ferramentas.
A figura 14 mostra a tela principal da ferramenta DESIGNER/2000 1.3.2, que
contém o links (acesso) para todas as ferramenta deste aplicativo.
25
Figura 14. Tela principal do DESIGNER/2000 1.3.2
4.3.1 ENTITY RELATIONSHIP DIAGRAMMER
O entity relationship diagrammer é uma ferramenta de modelagem utilizada para
definir a informação necessária de um negócio qualquer em um modelo de entidade e
relacionamento [CAR89].
Este diagrama de entidade e relacionamento é um modelo em rede que descreve a
diagramação dos dados armazenados de um sistema qualquer em um alto nível de abstração,
segundo [YOU90].
26
O diagrama de entidade e relacionamento é um ferramenta de modelagem útil para
gerenciar e controlar as informações de uma empresa, bem como organizar, gerenciar e
controlar o banco de dados eficientemente.
Segundo [CAR89] o diagrama de entidade e relacionamento é usado eficientemente
nas fases de estratégia e análise para definir a informação que se precisa do negócio como um
modelo de entidades. O diagrama representa entidades, relacionamentos entre elas, e os
atributos para descrevê-las.
4.3.2 DATA FLOW DIAGRAMMER
O data flow diagrammer é uma ferramenta para construção de diagramas de fluxo
de dados que permite criação e manutenção de funções de negócios, definição de base de
dados, fluxo de dados e entidades externas envolvidas com o sistema.
Segundo [BEL93], o diagrama de fluxo de dados é utilizado no estágio de análise
para criar diagramas que mostram o fluxo da informação entre a organização, coisas que
afetam a organização e onde o dado será armazenado.
Porém [CAR89] diz que o diagrama de fluxo de dados é utilizado para mostrar as
entidades e dados envolvidos no sistema, a partir de eventos. E com isto, o diagrama de fluxo
de dados é utilizado por analistas para mostrar as funções à medida que elas são descritas
pelos usuários.
4.3.3 FUNCTION HIERARCHY DIAGRAMMER
Segundo [CAR89], a ferramenta function hierachy diagrammer permite criar
diagramas hierárquicos de todas as funções executadas por um dado negócio e mostrar qual
partes do negócio podem ser automatizados.
O diagrama de funções hierárquicas é utilizado para decompor as funções do
negócio, definir os elementos das funções e mostrar como as funções do negócio utilizam os
dados.
O diagrama de funções pode ser usado para transformar anotações feitas durante
entrevistas em estruturas de funções. Descrevendo assim, o que a organização precisa fazer,
independente de como é feita.
27
4.3.4 DATA SCHEMA
A ferramenta data diagrammer (ou data schema) tem a finalidade de realizar a
modelagem final dos dados da aplicação e umas das várias facilidades que esta ferramenta
oferece é a visualização do modelo entidade relacionamento para a representação das tabelas e
restrições que serão utilizadas na base de dados.
O data diagrammer é uma ferramenta gráfica que serve para modelar logicamente e
fisicamente o designer de um banco de dados. Com o data diagrammer os objetos de um
banco de dados podem ser representados graficamente em diagrama de dados, os quais
mostram os relacionamentos entre as tabelas, visões e snapshots no sistema, e as constraints
de integridade contidas nos objetos [CAR89].
4.3.5 MODULE STRUCTURE DIAGRAMMER
O module structure diagrammer é uma ferramenta gráfica para construção de
diagramas de estruturas dos módulos. O module structure diagrammer serve então para
construir e modificar definições dos módulos, bem como para construir e reestruturar redes de
módulos.
Um dos principais objetivos para o qual esta ferramenta é utilizada, é para refinar os
módulos candidatos que são criados pelas definições de funções do sistema na ferramenta
function hierachy diagrammer [CAR89].
4.3.6 FORMS GENERATOR
A ferramenta forms generator é um programa que gera aplicações em FORMS
ORACLE a partir dos módulos definidos e gravados no repositório do DESIGNER/2000.
O forms generator pega a definição do que o programa deve fazer do dicionário
CASE e automaticamente gera um programa funcional escrito em linguagem de quarta
geração (FORMS). Subseqüentemente a ferramenta FORMS da ORACLE, pode ser utilizada
para refinar o programa gerado.
28
4.3.7 REPORTS GENERATOR
A ferramenta reports generator é um utilitário do DESIGNER/2000 que é utilizado
para gerar relatórios com alta qualidade a partir de módulos definidos e gravados no
repositório do CASE.
Como no forms generator, o reports generator pega a definição do que o programa
deve fazer a partir do dicionário do CASE e automaticamente gera um programa em
REPORTS. Subseqüentemente a ferramenta REPORTS da ORACLE pode ser utilizada para
refinar o relatório.
29
5 ESTRUTURA DO SISTEMA OPERACIONAL UNIX
Segundo [UNI95], um sistema operacional é um programa especial de computador
(software) que controla o computador (hardware). O sistema operacional serve de ligação
entre os consumidores (usuários) e os recursos, geralmente coordenando a alocação de
recursos limitados para um grande número de consumidores. Os recursos incluem, por
exemplo, a CPU, os discos rígidos, memória e impressoras e os consumidores estão rodando
programas que requisitam acesso a estes recursos. Como um exemplo, um usuário (ou um
programa) pode solicitar o armazenamento de um arquivo, com isso o sistema operacional
intervém para gerenciar a alocação de espaço no disco e a transferência desta informação da
memória para o disco.
5.1 HISTÓRICO DO SISTEMA OPERACIONAL UNIX
O sistema operacional UNIX nasceu nos Laboratórios Bell em 1969. Ken Thompson,
com a ajuda de Rudd Canaday, Doug Mcllroy, Joe Ossana, e Dennis Ritchie, elaborou um
sistema pequeno que logo atraiu a atenção das pessoas. Com a promessa de proporcionar boas
ferramentas para o setor administrativo dos Laboratórios, os primeiros pesquisadores
obtiveram um computador maior e prosseguiram com o desenvolvimento.
Nos meados dos anos 70, o sistema UNIX foi licenciado para as universidades e
ganhou imensa popularidade na comunidade acadêmica pelo fato de que era pequeno (os
sistemas antigos utilizavam grande espaço de disco) , flexível (o fonte era disponível e era
escrito em uma linguagem de programação de alto nível), e era barato (as universidades
conseguiam uma licença do sistema UNIX basicamente pelo preço de um fita. As primeiras
versões do sistema UNIX proporcionavam recursos poderosos, disponíveis apenas em
sistemas operacionais que rodavam em computadores mais caros.
Essas vantagens superavam as desvantagens que o sistema UNIX possuía na época: não
tinha suporte (a AT&T já tinha investido muito no MULTICS e não estava interessada em
explorar o sistema operacional UNIX), possuía bugs (e como não havia suporte, não havia
garantia de que os bugs seriam identificados e consertados) e possuía pouca ou quase
nenhuma documentação (porém sempre se podia usar o código fonte).
30
Num passo seguinte, o sistema operacional UNIX chegou à Universidade da
Califórnia em Berkeley, onde os usuários de Berkeley criaram sua própria versão do sistema.
Com o apoio do departamento de defesa, eles incorporaram vários novos recursos no sistema.
Com isso, a AT&T reconheceu o potencial do sistema operacional e começou a licenciá-lo
comercialmente. Para melhorar o produto, a AT&T uniu os projetos de desenvolvimento do
sistema UNIX em processo de conclusão em diferentes departamentos da empresa, e também
começou a incorporar os aperfeiçoamentos desenvolvidos em Berkeley [UNI95].
Por fim, o sucesso posterior do UNIX pode ser atribuído aos seguintes fatores:
a) interface de usuário flexível e um ambiente operacional que inclui inúmeros
utilitários;
b) modularidade do sistema que permite a inclusão de novos utilitários;
c) capacidade de suportar múltiplos processos e múltiplos usuários ao mesmo
tempo;
d) disponibilidade para uso em microcomputadores relativamente poderosos e
baratos;
e) disponibilidade para uso em uma ampla gama de plataformas de hardware;
f) padronização da definição de interface, proporcionando portabilidade de
aplicativo.
5.2 RECURSOS DO UNIX
Conforme [UNI95], o sistema UNIX proporciona um sistema operacional timesharing que controla as atividades e recursos do computador, e uma interface flexível e
interativa. O sistema foi projetado para administrar múltiplos usuários, com a finalidade de
facilitar o compartilhamento de dados entre membros de uma equipe de projeto. O ambiente
operacional foi projetado com uma arquitetura modular em todos os níveis. Para uma melhor
visualização dos níveis modulares da arquitetura do UNIX veja a figura 15.
31
Shell
Ferramentas e
Aplicativos
Kernel
csh
ksh
sort
ls
Hardware
vi
mail
sh
date
sh-posix
Fonte:[UNI95]
Figura 15. Arquitetura modular do UNIX
Como mostrado na figura 15 o kernel é o sistema operacional, e é o responsável pelo
gerenciamento dos recursos disponíveis pelo acesso ao hardware. O kernel contém módulos
para cada componente do hardware que
juntos fazem a interface. Esses módulos
proporcionam a funcionalidade que permite o acesso de programas à CPU, memória, discos,
terminais, rede, etc. À medida que novos tipos de hardware são instalados no sistema, novos
módulos podem ser incorporados ao kernel.
O nível das ferramentas e aplicativos do sistema UNIX é onde o design modular do
sistema torna-se mais evidente. A filosofia de comandos do sistema UNIX espera que cada
comando faça uma coisa, e o conjunto de comandos forme uma caixa de ferramentas. Quando
executa-se uma tarefa, busca-se as ferramentas adequadas e tarefas complexas podem ser
feitas combinando-se adequadamente as ferramentas. Desde a sua criação, a caixa de
ferramentas do sistema UNIX inclui mais do que os comandos básicos necessários para se
interagir com o sistema. O sistema UNIX também fornece utilitários para correio eletrônico,
edição de arquivos, processamento de textos, formatação de textos, desenvolvimento de
32
programas, gerenciamento de programas, comunicação intersistemas, contabilidade de
processos e de usuários.
Como o ambiente do usuário do sistema UNIX foi projetado para ser interativo,
programável e modular, novos utilitários podem ser facilmente desenvolvidos e adicionados à
caixa de ferramentas do usuário, podendo as ferramentas desnecessárias serem removidas sem
prejudicar o funcionamento do sistema.
No nível mais externo do sistema UNIX encontra-se o shell que é um interpretador
interativo de comandos. Os comandos são introduzidos no prompt do shell e trabalhados à
medida que são emitidos. Um usuário comunica-se com o computador através do shell, ou
seja, o shell pega a entrada que o usuário digita no teclado e traduz o comando para uma
forma que o kernel possa entender , e o kernel então executa o comando.
Como visto então, o shell é separado do kernel e se uma interface provida por um
shell não for agradável, pode ser facilmente substituída. Muitos shells estão disponíveis
atualmente, alguns são acionados por comandos e outros incluem um menu de interface. Os
shells comuns que acompanham o sistema UNIX incluem tanto um interpretador de
comandos quanto uma interface programável.
Existem quatros tipos de shells geralmente disponíveis no ambiente do sistema
UNIX [UNI95] :
a) Bourne shell: é o shell original oferecido nos sistemas da AT&T, provê um
interpretador de comandos e suporta uma interface programável para desenvolver
programas em shell ou scripts. As interfaces programáveis e interativas fornecem
recursos tais como definição e substituição de variáveis, teste de variável e de
arquivo, desvios e loops;
b) C shell: este foi o shell desenvolvido na Universidade da Califórnia em Berkeley,
e é considerado um aperfeiçoamento do Bourne shell porque oferece recursos
interativos, como empilhamento de comandos que permite facilmente a reentrada
e edição de comandos introduzidos anteriormente, e o uso do alias, que permite o
uso de nomes alternativos personalizados para comandos existentes;
c) Korn shell: é um projeto mais recente dos Laboratórios Bell, pode ser
considerado um Bourne shell aperfeiçoado porque suporta a interface
programável simples do Bourne shell, porém tem os recursos interativos do C
33
shell. O código também foi otimizado para oferecer um shell mais rápido e
eficiente;
d) POSIX shell: linguagem de programação de comandos conforme POSIX e
interpretador de comandos residente no arquivo /usr/bin/sh. Esse shell é
semelhante ao Korn shell em muitos aspectos, provê um mecanismo de registro
histórico, suporta controle de tarefas e outros recursos interessantes.
5.3 SISTEMA HIERÁRQUICO DE ARQUIVOS
No UNIX, a informação é armazenada no disco em recipientes conhecidos como
arquivos. Cada arquivo recebe um nome, e o usuário indica o nome do arquivo para acessá-lo.
Os arquivos normalmente contêm dados, texto, programas, etc. Um sistema UNIX
normalmente contém centenas de arquivos, de modo que um outro container (o diretório) é
oferecido para permitir aos usuários organizar seus arquivos em agrupamentos lógicos. No
sistema UNIX um diretório pode ser usado para armazenar arquivos ou outros diretórios.
A estrutura de sistema de arquivos é muito flexível, de maneira que, em caso de
alteração das necessidades de organização de um usuário os arquivos e diretórios podem ser
facilmente movidos, renomeados ou agrupados em diretórios novos ou diferentes através de
comandos simples do sistema UNIX. Portanto, o sistema de arquivos é como um gabinete
eletrônico, permite aos usuários separar e organizar suas informações em diretórios
apropriados para seu ambiente e aplicação [HAN95].
5.4 MULTITAREFA
No sistema UNIX, várias tarefas podem ser realizadas ao mesmo tempo. A partir de
um único terminal, um único usuário pode executar vários programas que dão a impressão de
estarem rodando simultaneamente, isto significa que um usuário pode editar um arquivo de
texto enquanto outro arquivo está sendo formatado, e um outro está sendo impresso. Na
verdade, a CPU pode executar apenas uma tarefa por vez, porém o sistema operacional UNIX
tem a capacidade de compartilhar o tempo da CPU entre múltiplos processos programados
para rodar ao mesmo tempo. Assim, para o usuário parece que todos os programas estão em
execução simultânea [UNI95].
34
5.5 MULTIUSUÁRIO
O sistema operacional UNIX possui também capacidade de multiusuário que permite
que mais de um usuário tenha acesso e use o sistema ao mesmo tempo. Múltiplos terminais e
teclados podem ser ligados ao mesmo computador. Essa é uma extensão natural da
capacidade de multitarefa. Se o sistema pode rodar múltiplos programas simultaneamente,
alguns desses programas deverão ser capazes de suportar outras sessões de usuários. Além
disso, um único usuário poderá entrar várias vezes no mesmo sistema através de múltiplos
terminais. Uma grande vantagem desta arquitetura é que membros de um grupo de trabalho
podem ter acesso aos mesmos dados ao mesmo tempo, do ponto de vista do projeto ou do
ponto de vista do usuário [UNI95].
35
6 SISTEMA DE UTILITÁRIOS DA SOUZA CRUZ
O Sistema de Utilitários da Souza Cruz (DUT), é um sistema que atende às
necessidades gerais dos Sistemas de Informática da Companhia Souza Cruz em geral, ou seja,
é um sistema de apoio que está automaticamente incorporado aos diversos sistemas
desenvolvidos em todas as unidades da empresa, disponibilizando recursos de processamento
com utilidade para os usuários. O Sistema de Utilitários da Souza Cruz tem como objetivos
distintos já citados anteriormente, manter uma certa segurança no acesso aos dados e
disponibilizar recursos de submissões batch em servidores [CAS96].
A atual manutenção corretiva e evolutiva do sistema foi justamente investida em
cima dos recursos de submissão batch, onde os processos de manutenções no sistema
envolveram vários profissionais da área como: gerentes de projeto, analistas de sistemas,
projetistas, programadores e analistas de suporte.
6.1 HISTÓRICO
A finalidade da Souza Cruz em desenvolver um sistema gerenciador de submissão de
processos em batch surgiu logo após
o início da descentralização do Centro de
Processamento de Dados da empresa para a dispersão de microcomputadores por toda a
Companhia. Isto há dez anos atrás, quando a empresa optou em migrar para a arquitetura
client/server. Devido ao descarte dos mainframes (grandes computadores utilizados para
processamento centralizado) e a opção do uso de computadores pessoais e servidores de
dados, a Souza Cruz na verdade optou por não utilizar mais os computadores VAX (Sistema
Operacional VMS) utilizados pela empresa até então, e sim por microcomputadores e
servidores de banco de dados (Máquinas HP com sistema operacional UNIX HP-UX). Com
isso então a empresa “eliminou” o processamento centralizado, e passou de fato a utilizar
recursos de informática em todos os departamentos das unidades da empresa.
6.2 IMPACTOS COM A MIGRAÇÃO
Contudo, com essa migração, surgiram problemas no decorrer da implantação do
novo ambiente de informática da empresa pela necessidade que a mesma possui de utilizar
máquinas mais potentes para executar processos mais complexos (relatórios, programas de
36
carga de dados, etc.) e pela necessidade da empresa centralizar alguns tipos de rotinas
(programas PLSQL’s e shells), devido a dois motivos:
a) questões de segurança: ambientes como SQLPLUS que são utilizados por
programas PLSQL’s não devem ficar disponíveis aos usuários, pois os dados
podem correr o risco de serem manipulados indevidamente;
b) conforto aos usuários: estas rotinas podem ser disparadas nos servidores pelos
usuários do seu local de trabalho (client).
Porém, estas necessidades acabaram em impacto justamente devido à nova
arquitetura, pois centralizando processos no servidores os mesmos não se adequaram às
mesmas características de submissão em um mainframe.
A verdade é que como a empresa utilizava máquinas VAX, o sistema operacional
desta máquina, o VMS, possuía implementado no sistema a capacidade de submissão batch
com um conceito de enfileiramento de processos e controle de prioridades. Um processo era
submetido na máquina indicando uma fila lógica onde iria executar, bem como a
prioridade
poderia
deste processo, e esta fila por sua vez possuía conceitos de quantos processos
deixar executar ao mesmo tempo na máquina. Isto disponibilizava aos usuários a
opção de gerenciar melhor prioridades para seus trabalhos.
Porém, nos servidores HP-UX este conceito no sistema operacional UNIX não
existe, suportando o UNIX somente o conceito de executar processos em batch, e não
suportando gerenciamento de filas para um maior controle dos processos.
Com isso então, a Souza Cruz decidiu investir no desenvolvimento de um sistema
para gerenciamento de submissão de processos em batch (o DUT), programado em um nível
de linguagem mais alto (PRO*C e shells do UNIX) e utilizando informações de banco de
dados ORACLE.
6.3 VISÃO GERAL
As submissões batch do DUT possibilitam aos usuários a execução de três tipos de
processos em servidores HP-UX. Estes três processos que podem ser submetidos em
background são:
a) relatórios modo caracter desenvolvidos em REPORTS da ORACLE;
37
b) scripts PL/SQL em SQLPLUS;
c) shells em UNIX.
Para isto existe um conjunto de rotinas escritas em PRO* C (e shells no UNIX),
chamadas de scheduler e que executam os jobs programados pelos usuários no servidor.
Além
da execução destes três tipos de processos nos servidores, o scheduler
disponibiliza também aos usuários os recursos de impressões nos servidores. Desta forma, as
impressões solicitadas pelos usuários são despachadas pelo scheduler para as impressoras no
servidor .
As submissões de relatórios, scripts ou shells em batch são utilizadas principalmente
quando o volume de dados ou o tempo de execução envolvido nos processos é muito grande,
e portanto precisa-se de máquinas mais poderosas para executá-los, isto por questão de tempo,
economia e eficiência. Outra vantagem além desta, é que as submissões de processos em
batch não “prendem” os terminais dos usuários, deixando-os livres para executarem outros
trabalhos. Na verdade vários processos podem ser executados ao mesmo tempo, enquanto os
computadores pessoais dos usuários podem ficar realizando outras tarefas [CAS96].
Outro destaque da aplicação de submissão batch em sua nova versão, é prover aos
usuários a possibilidade de programar processos para executarem mais tarde, ou programá-los
para executar a cada certo tempo, como exemplo: diariamente, semanalmente, mensalmente,
etc.
6.4 MODELO DE DADOS DA SUBMISSÃO BATCH
Para um melhor esclarecimento do sistema vide no ANEXO 1 o novo modelo de
dados que o scheduler (programa responsável pelas submissões em batch) utiliza para
submeter no sistema operacional os pedidos de submissão dos usuários.
6.5 FUNCIONAMENTO DO SCHEDULER
O scheduler tem como objetivos monitorar periodicamente os pedidos de submissão
em batch do usuários e submetê-los para executar no sistema operacional (estes pedidos ficam
gravados na tabela JOB_BATCH_ORACLE no banco de dados).
38
Para isto o scheduler reconhece dois distintos pedidos de submissão em batch :
a) Pedidos de execução de processos: programas PLSQL, shells e relatórios;
b) Pedidos de impressão: arquivos a imprimir referente a processos que já
executaram.
6.5.1 PEDIDOS DE EXECUÇÃO DE PROCESSOS
Para atender os pedidos de execução de processos o scheduler utiliza o conceito de
filas de execução, ou seja, ele valida o job que está para executar verificando a fila de
execução (tabela FILA_EXEC) que este job está submetido, verifica se esta fila de execução
está ativa , verifica se esta fila possui restrição de horário para executar, verifica quantos job’s
esta fila pode ficar executando ao mesmo tempo e valida quantos job’s estão executando neste
momento no sistema operacional. Se a quantidade de job’s que estão executando neste
momento for menor que o suportado na fila o scheduler grava
o pedido na tabela
LOG_BATCH_ORACLE e grava os arquivos de saída na LOG_ARQ_SAIDA (tomando
como base a tabela ARQ_SAIDA) e então dispara o processo no sistema operacional.
6.5.2 PEDIDOS DE IMPRESSÃO
Para atender os pedidos de impressão o scheduler não tem muita interação como nos
pedidos de execução (onde seguindo certas regras o scheduler identifica se pode ou não
colocar
para
executar
os
processos).
Quando
o
scheduler
identifica
na
JOB_BATCH_ORACLE um pedido de impressão, o mesmo apenas executa no sistema
operacional um comando de impressão indicando quais são os arquivos que deverão ser
impressos, qual o tipo de formulário que deve se utilizado e qual a impressora solicitada que
fará a impressão.
39
7 INTERFACE DO ADMINISTRADOR DO SISTEMA
7.1 APRESENTAÇÃO E OBJETIVOS DA FERRAMENTA
A ferramenta desenvolvida para o administrador do sistema, chamada de Interface
do Administrador, tem como objetivo auxiliar o administrador a monitorar, definir e alterar
características do sistema de submissões em batch. A ferramenta provê a este tipo de usuários
a permissão para fazer alterações no modo de ação do scheduler (o qual é responsável por
fazer as submissões dos programas nos servidores), bem como deixá-lo mais informado do
estado de consistência do scheduler e das submissões do processos (relatórios, PL/SQL’s e
shells) através da visualização de log’s e relatórios que esta ferramenta disponibiliza ao
administrador.
Outra opção também disponibilizada na ferramenta e de responsabilidade exclusiva
para o administrador do sistema são as opções de manter alguns cadastros de informações,
que por sua vez são base de dados para a atuação do scheduler.
Como pode-se analisar, tornou-se importante e assim necessário uma pessoa de
suporte, responsável por este cargo. Esta pessoa ou usuário, diga como quiser, são atualmente
profissionais de suporte operacional da empresa, ou seja, estão intimamente ligados à
problemas de informática , suprindo já no momento a empresa com outras funções de suporte
de informática como: responsáveis por manutenções em máquinas (computadores),
responsáveis por backup dos dados, atendimento aos usuários de sistemas, etc.
Com isso então optou-se por construir esta ferramenta para ser executada em ambiente
caracter mode, ou seja, utilizando a plataforma UNIX HP-UX da empresa, pelo fato de que as
rotinas responsáveis pelas submissões de processos em batch estão instaladas neste tipo de
plataforma e os log’s do scheduler e dos processos submetidos são arquivos gerados nestas
máquinas. Isto acabou não prejudicando, como também beneficiando os usuários desta
ferramenta devido ao grande conhecimento que os mesmos já tem a respeito deste tipo de
plataforma, pois com as funções de suporte operacional, já estão intimamente ligados a este
tipo de sistema operacional no seu dia a dia.
Para a construção da ferramenta Interface do Administrador foram utilizadas as
ferramentas de desenvolvimento FORMS e REPORTS da ORACLE, as quais permitiram o
40
desenvolvimento desta aplicação normalmente em ambiente gráfico e depois possibilitaram a
esta aplicação uma conversão para ambiente caracter mode, isto através de ferramentas que a
própria ORACLE fornece para este tipo de conversão.
7.2 ESPECIFICAÇÃO DA FERRAMENTA
Para a especificação da ferramenta Interface do Administrador foram definidos:
a) Modelo Entidade Relacionamento;
b) Modelo Físico dos Dados;
c) Modelo Hierárquico dos Módulos.
O Modelo Entidade Relacionamento (MER) enfatiza as entidades (e atributos) com
que o sistema lida, bem como a relação entre elas. Para a visualização do modelo vide
ANEXO 2.
O modelo físico dos dados já diz respeito às tabelas utilizadas pela ferramenta bem
como quais as chaves criadas para a relação entre estes objetos no banco de dados. Para
visualização do modelo vide ANEXO 3.
E finalizando, foi utilizado a ferramenta Module Structure do DESIGNER/2000 para
definir os módulos a serem implementados para suportar as funções do sistema, bem como os
níveis destes na estrutura da aplicação. Para visualizar o modelo hierárquico dos módulos vide
ANEXO 4.
7.3 MÓDULOS DA FERRAMENTA DO ADMINISTRADOR
Serão apresentados aqui todos os módulos que compõem a ferramenta Interface do
Administrador, especificando as suas funcionalidades e interações com o sistema de
submissão batch.
41
7.3.1 TELA PRINCIPAL
A figura 16 mostra a tela principal do aplicativo Interface do Administrador:
Figura 16. Tela principal da ferramenta Interface do Administrador
Como pode-se ver na figura 16, a tela principal da ferramenta do administrador
indica ao administrador qual banco de dados está utilizando e disponibiliza a este usuário
quatro opções de menus para todos os módulos do programa:
a) Arquivo: este item de menu disponibiliza as opções de gerar nova tela para
cadastramento de dados, fechar a tela, salvar os dados, imprimir a tela e sair do
aplicativo;
b) Editar: neste item são disponibilizados as opções de desfazer as alterações,
recortar, copiar, colar, limpar item selecionado, excluir registro, incluir registro,
selecionar dados, exibir dados;
42
c) Auxílio: neste item de menu ficam disponíveis as opções de teclas de funções do
programa, lista de valores, ajuda , acesso ao programa de utilitários e informações
sobre o programa;
d) Opções: este item de menu é específico da aplicação, ou seja , as outras opções de
menus especificadas acima, são itens de menu comumente utilizados por todas as
aplicações da Souza Cruz, as quais a Companhia tornou padrão de todas as
aplicações. Os sub-itens
disponibilizados por este item são: Scheduler, Log
Analyser, Report e Manutenção. Como pode-se observar alguns destes sub-itens
possuem a descrição em inglês, isto pelo fato de que os operadores que serão os
usuários desta aplicação estarem familiarizados com estes termos.
Na figura 17 é mostrado a hierarquia das opções de menu do aplicativo:
Figura 17. Menu da ferramenta Interface do Administrador
7.3.2 ITENS DO MENU OPÇÕES
Como pode-se ver na figura 17, os sub-itens do menu opções possuem várias opções,
as quais são descritas separadamente para que se possa ter uma visão mais focalizada e
descritiva das funções específicas desta ferramenta.
43
7.3.2.1 SCHEDULER
A opção de menu scheduler disponibiliza ao administrador as seguintes opções que
interagem com o programa scheduler (programa que monitora periodicamente os pedidos de
submissão batch):
a) Inicializar: Esta é uma opção para o administrador do sistema poder inicializar
o scheduler responsável pela execução dos processos submetidos, fazendo então
com que um programa executável no sistema operacional “levante a submissão
batch”. Para isto foi projetado um shell no UNIX para que no momento desta
opção ser escolhida, o mesmo se encarregará de “levantar o sistema de
submissão batch” e retornar para a ferramenta do administrador se a ação foi
bem sucedida ou não (veja figura 18);
Figura 18 . Inicialização do scheduler
44
b) Finalizar: Esta opção é proporcionalmente inversa a inicializar, pois quando
escolhida, é executado um shell no sistema operacional para “derrubar a
submissão batch”, não sendo e não podendo então mais nenhum processo que
estava submetido ser executado. Este shell também é o responsável de retornar
para a ferramenta se ação foi sucedida ou não (veja figura 19);
Figura 19. Finalização do scheduler
c) Configurar: Esta opção chama a tela de configuração do modo de atuação do
scheduler, podendo então o administrador visualizar e modificar os critérios de
atuação do scheduler em relação à submissão e atendimento dos processos. Esta
tela atualiza no banco de dados as tabelas CONFIG_SCHLER
e
SCHLER_NOTIFY_USERS_NOTES, as quais podem ser vistas no modelo
físico de dados no ANEXO 3 (veja figura 20);
45
Figura 20. Tela de configuração do scheduler
Na tela da figura 20, as seguintes opções estão disponíveis ao administrador do
sistema:
a) Visualização do nome do banco de dados utilizado pelo scheduler;
b) Visualização e alteração da máquina onde o scheduler está instalado e onde os
processos submetidos são executados;
c) Visualização do status do scheduler, indicando se o sistema de submissão está
ativo ou inativo;
d) Visualização e alteração dos número de dias que os log’s gerados pelo processos
submetidos dos usuário devem ficar guardados;
e) Indicar ao scheduler se o mesmo deve gerar um log de suas funções mais
descritivas ou não;
f)
Indicar ao scheduler se o mesmo deve enviar mensagens críticas via mail para o
administrador quando acontecerem problemas nas submissões, como falta de
46
espaço em disco, banco de dados fora do ar, tablespace do banco de dados
estourou;
g) Indicar ao scheduler se o mesmo deve poder utilizar o recurso de enviar
mensagens dos processos executados para os usuários.;
h) Cadastrar, eliminar, consultar todos os administradores responsáveis pelo
sistema de submissões batch em um banco de dados.
7.3.2.2 LOG ANALYSER
O Log Analyser é uma opção de menu que permite ao administrador do sistema
visualizar log’s do scheduler, tanto de execução de processos como de pedidos de impressão,
utilizando o editor de texto VI ou JOE do UNIX:
a) Log de Execução: Esta opção permite ao administrador editar o log de execução
do scheduler, podendo assim extrair-se informações das atividades do scheduler
referente aos pedidos de submissão executados por ele. Com isto o
administrador pode visualizar no log informações como:
-
momento em que um pedido foi atendido;
-
tipo do pedido (execução, cancelamento, impressão);
-
número do pedido e usuário que o solicitou;
-
programa e parâmetros que foram executados pelo pedido;
-
arquivos de saída gerados pelo pedido (veja figura 21);
b) Log de Impressão: Esta opção permite ao administrador editar o log de
impressão do scheduler, podendo assim extrair-se mais informações das
atividades do scheduler referentes aos pedidos de impressão atendidos por ele.
No log de impressão várias informações podem ser vistas pelo administrador,
tais como:
-
momento em que uma impressão foi enviada à impressora;
-
arquivo que foi impresso (relatório);
-
impressora e formulário que foi utilizado;
-
range de páginas e numero de cópias que foram impressas. (veja figura 22).
47
Figura 21. Log de execução do scheduler
Figura 22. Log de impressão do scheduler
48
7.3.2.3 REPORT
A opção de menu report disponibiliza ao administrador a opção estatísticas, cuja tela
permite ao administrador optar pela execução de dois relatórios de estatísticas de processos
(como mostrado na figura 23):
a) Relatório de estatísticas de execução: mostra para o administrador uma certa
quantidade de programas submetidos que mais gastaram tempo executando em
um certo mês. A quantidade de programas mostrados e o mês sobre o qual o
relatório é gerado, é passado pelo administrador através de parâmetros
(quantidades de linhas mostradas, mês e ano);
b) Relatório de aplicações por tempo de execução: mostra para o administrador uma
certa quantidade de programas submetidos que mais gastaram tempo executando
e quantas vezes foram executados em um certo mês. A quantidade de
programas mostrados e o mês sobre o qual o relatório é gerado, também é
passado pelo administrador através de parâmetros (quantidades de linhas
mostradas, mês e ano).
Figura 23. Tela de parâmetros dos relatórios da ferramenta Interface do Administrador
49
Para obter mais informações sobre os relatórios gerados pela ferramenta Interface
do Administrador vide ANEXO 5 (Relatórios da Ferramenta do Administrador).
7.3.2.4 MANUTENÇÃO
A opção de menu manutenção disponibiliza ao administrador as seguintes opções que
interagem com o programa scheduler (programa que monitora periodicamente os pedidos de
submissão batch):
a) Filas de execução: Esta opção chama a tela de manutenções nas filas de
execução utilizadas pelo scheduler. Estas filas de execução são as amarrações
lógicas para distribuição dos processos submetidos, usadas para organizar as
submissões em classes e que foram comentadas no capítulo funcionamento do
scheduler. Esta tela atualiza no banco de dados a tabela FILA_EXEC, que pode
ser vista no modelo físico no ANEXO 3 (Veja figura 24).
Figura 24. Tela de manutenção das filas de execução
50
As opções disponíveis na tela de manutenção das filas de execução são:
Seleção, Inserção, Modificação e Deleção de filas de execução, informando a estas
filas um código único (de A à ZZ), uma descrição da fila de execução (descrevendo que tipos
de processos serão executados utilizando esta fila),
a quantidade de job’s , ou seja, a
quantidade de processos que poderão executar ao mesmo tempo utilizando esta fila, o status
que a fila se encontra, um horário de domínio de atuação da fila e a quantidade de horas que
esta fila pode ficar executando.
b) Limites de Submissão: Este item chama a tela de manutenção nos limites de
submissão batch utilizados pelo scheduler. Estes limites são as restrições que o
scheduler verifica e obedece em relação à visualização de relatórios, impressão
de relatórios e compactação de arquivos (veja figura 25).
Figura 25. Tela de manutenção dos limites de submissão batch
51
Na tela da figura 25 as seguintes opções estão disponíveis para o administrador:
Seleção, Inserção, Modificação e Deleção de tipos de limite de submissão,
informando a
estes limites um código único, uma descrição indicando o limite e a
quantidades em bytes de dados que este limite se aplica.
A tela de manutenções dos limites de submissão batch atualiza no banco de dados a
tabela LIMITE_SUBMISSAO_BATCH (Vide ANEXO 3).
c) Transferência de JOB’s programados: Este item de menu chama a tela
transferência de jobs programados, a qual disponibiliza ao administrador a
possibilidade de transferir os processos programados de um usuário para um
outro usuário. Este foi um recurso solicitado pela empresa Souza Cruz pelo fato
de todos os processos submetidos em batch possuírem um respectivo dono, ou
seja, no cadastramento do pedido de submissão de um job o nome da conta do
usuário também é gravado. Na versão antiga do sistema os usuários se
encontravam com um problema específico. Exemplo disto, seria a necessidade
de um usuário A passar a sua função responsável de gerar um certo relatório
para um usuário B, a verdade é que na versão antiga do sistema isto não era
possível, devendo então o usuário A eliminar o seu job programado do sistema
de submissões e o usuário B programá-lo novamente. Na transferência de um job
programado de um usuário para outro, o programa checa as seguintes
informações:
- verifica para quais perfis de programas, o programa a ser transferido está
liberado, através da busca da informação na tabela PROG_COMPUT_PERFIL
( vide ANEXO 3);
- verifica se o novo usuário a receber o job programado possui um dos perfis
para o qual o programa está liberado. Esta informação é consultada na tabela
USUAR_PERFIL (vide ANEXO 3).
52
A figura 26 mostra a tela de transferência de jobs programados:
Figura 26. Tela de transferência de jobs programados
As opções disponíveis na tela transferência de job’s programados são:
a) Visualizar o número de identificação interna dos job,s programados;
b) Visualizar o nome do programa que cada um dos job executa;
c) Visualizar a descrição dos programas;
d) Visualizar e Alterar o usuário dono do job programado. A alteração ocorre no
campo NOM_USUAR da tabela JOB_BATCH_ORACLE (vide ANEXO 3).
53
d) Formulários de Impressão: esta opção permite ao administrador fazer
manutenções no cadastro dos formulários de impressões. Estes formulários são
formatos que indicam para as impressoras como os arquivos devem ser
impressos, com isso então, quando impressões são submetidas para que o
scheduler as execute, estas impressões podem indicar que tipo de formulário
deve-se utilizar. Um exemplo de utilização de formulário seria a impressão de
uma nota fiscal , esta possui um formulário único para preenchimento da nota , a
a qual indica para a impressora aonde encontram-se os campos a serem
preenchidos, porém este formulário não pode ser utilizado por um outro
documento qualquer, pois o formato de impressão deste documento será
totalmente diferente (Veja figura 27).
Figura 27. Tela de manutenção dos formulários de impressão
54
As opções disponíveis na tela de manutenção de formulários de impressão são:
Seleção, Inserção, Modificação e Deleção dos tipos de formulários de impressão,
informando a cada formulário, um nome para o formulário e uma descrição.
A tabela atualizada no banco de dados através da tela de manutenção de formulários
de impressão é a FORMLR_IMPR, (vide ANEXO 3 Modelo Físico de Dados).
55
8 CONCLUSÕES
A ferramenta Interface do Administrador desenvolvida neste trabalho é uma parte
de um grande projeto de manutenções e melhorias aplicadas em um sistema de submissão
batch específico da empresa Souza Cruz.
Como manutenções e melhorias no sistema de submissão batch, a ferramenta do
administrador disponibiliza ao sistema opções de configurar e alterar as suas propriedades
(permitindo ao administrador inicializar o sistema, finalizar, setar parâmetros, etc.), bem
como disponibilizar informações precisas da atuação do sistema através de relatórios e log’s.
Desta maneira o sistema de submissão batch trabalha de forma mais robusta e eficaz.
O ponto produtivo deste trabalho foi o conhecimento tecnológico adquirido durante o
estágio, visto que o sistema (DUT) para o qual a ferramenta Interface do Administrador foi
implementada apresenta uma certa complexidade.
Outro fato importante é que a ferramenta Interface do Administrador não foi
implementada com o objetivo de um protótipo, pois está sendo implantada com a nova versão
do sistema de submissão batch e atuará em todas as unidades da Souza Cruz.
Esta ferramenta foi desenvolvida para um sistema específico de submissões batch.
Para que a mesma seja utilizada por algum outro tipo de aplicação de submissão que exista ou
venha existir no mercado esta ferramenta precisará de manutenções e ajustes.
Como sugestão para futuros trabalhos, a ferramenta Interface do Administrador
poderia ser convertida para o modo gráfico, podendo assim tornar-se ainda mais amigável
para os usuários. E outras funções que a ferramenta não suporta atualmente poderiam ser
implementadas como disponibilizar ao administrador a configuração do tempo que o
scheduler deve aguardar para verificar novos pedidos de execução e impressão.
56
REFERÊNCIAS BIBLIOGRÁFICAS
[BEL93]
BELLIN, David e Suchman Susan. Manual de Desenvolvimento de Sistemas
Estruturados. São Paulo: Editora Makron Books do Brasil Ltda, 1993.
[CAR89]
CARSON, Chris. Case Designer User’s Guide and Tutorial. V 1.1. Oracle
Corporation UK Limited, Chertsey Surrey, England, 1989.
[CAS96]
CASTRO, Marcelo Armando. Sistema de Segurança e Utilitários. Souza Cruz,
1996.
[DAT91]
DATE, C. J. Introdução a Sistema de Banco de Dados. trad. Hélio Auro
Gouveia. Rio de Janeiro : Campus, 1991.
[DEF93]
DÉFENSE ORACLE. Gerando uma aplicação em Case Oracle.1993.
[HAN95]
HANSEN, Aguie. Salvo pelo ... UNIX; Trad. Carlos Augusto P.
Gomes. São Paulo : Érica, 1995.
[MIT95]
MITSUYA, Lia A.; SOPHIA, Walter. Submissão Batch no Servidor Risc.
Souza Cruz, 1995.
[MOR95]
MORAIS, Rinaldo de Oliveira. Oracle 7 Server – Conceitos Básicos. São
Paulo: Érica, 1995.
[ORA92]
ORACLE7 Server Concepts Manual. Estados Unidos: Oracle Corporation,
1992.
[ORA94]
BROWN, Denise; MAGEE, John; MUENCH Steve. Oracle Forms
Reference Manual . Redwood : Oracle Corporation, 1994.
[ORA95]
BRONDUM, Per; HSIEH, Alex; SUKLIKAR Atul. Oracle Reports
Reference Manual . Redwood : Oracle Corporation, 1995.
[UNI95]
Sistema Operacional UNIX. São Paulo: Edisa Hewlett Packard S.A., 1995.
[YOU90]
YOUDORN, Edward. Análise Estruturada Moderna. Editora Campus,
1990.
57
GLOSSÁRIO DE TERMOS
Arquivo de log Arquivo que contém informações do acompanhamento da execução de um programa.
Batch Processo que executa independente da sessão do usuário (background).
Backup Procedimento de fazer cópia das informações para a segurança dos dados.
Byte Mínima unidade lógica para representação de um dado (composta por oito bits).
Caracter mode Ambiente operacional que disponibiliza recursos no modo caracter, não suportando recursos
gráficos (Exemplo: Sistema operacional UNIX e DOS no modo comando de linha).
Client/server Arquitetura de computadores utilizada onde existem computadores clientes que utilizam recursos
(programas) e servidores que fornecem recursos.
Default Valor que é assumido inicialmente caso não seja informado nenhum outro.
Filas de execução Classificações dos jobs em categorias. A cada fila é dado um conjunto de características
(horário de funcionamento, quantidade de jobs suportados, etc.).
Filas de impressão São as impressoras disponíveis na rede.
Formulário Arquivo texto contendo comandos para impressora que são enviados para a mesma antes da
impressão do relatório.
JOB Solicitação de execução de um programa.
Log’s Arquivos que contém informações do acompanhamento da execução de programas.
Mainframe Grandes computadores utilizados para processamento centralizado.
Mail Envio de mensagem para correio eletrônico.
Perfil Característica dada a um usuário conforme sua função.
PLSQL Linguagem utilizada para gerar códigos procedurais utilizando banco de dados.
Processo Programa em execução.
PRO*C Linguagem de programação de terceira geração que disponibiliza comandos para acesso a banco de
dados.
Range de páginas Domínio de páginas de um documento. Exemplo: Impressão de um relatório da página 10 à
20.
Scheduler Processo que monitora e atende as solicitações dos usuários (JOB, cancelamento, impressão).
Scripts Arquivos de programa em lote.
Servidor Máquina que disponibiliza recursos aos usuários (clientes).
58
Shell Programa em lote que roda na plataforma UNIX.
SQL Linguagem padrão ANSI para acesso à banco de dados.
SQLPLUS Ferramenta da ORACLE que disponibiliza acesso a banco de dados.
Submeter Significa solicitar a execução de um programa.
Status Indica os estado de um processo.
59
ANEXO 1 MODELO ENTIDADE RELACIONAMENTO
DO SISTEMA DE SUBMISSÃO BATCH
60
ARQUIVO SAIDA
#
*
*
o
o
BANCO DADOS
NOM_ARQ_SAIDA
NOM_PATH
NOM_SUF_ARQ
FLG_SEQ
NUM_SEQ
*
*
*
*
*
#
*
*
o
o
o
COD_BANCO_DADO
DSC_BANCO_DADO
DSC_CONNCT_STRING
FLG_BD_LOCAL
IND_TIPO_AMBIEN
NOM_BANCO_DADO
NOM_DEFLT_TBSPCE
NOM_TEMPOR_TBSPCE
FLG_ROLE
NOM_CONNCT_ODBC
NOM_DBLINK
PROGRAMA
COMPUTADOR
*
#
o
o
o
o
o
o
o
o
o
o
o
o
o
LOG BATCH ORACLE
DSC_PROG
NOM_PROG
DSC_TIPO_MODULO
FLG_PROG_PUBLIC
FLG_TRANSF
IND_CARACT_IMPR
IND_CLASSF_RISCO
IND_FONTE
IND_LOCAL_EXEC
IND_NIVEL
IND_NIVEL_DRTRIO
NOM_CLASSE
NUM_PRIORI
NUM_VERSAO_REPORT
SIG_AREA_USUAR
CONFIGURACAO
SCHEDULER
*
o
o
*
o
FLG_DEBUG_PROCES
NUM_DIAS_PERM_LOG
FLG_STAT_SCHED
FLG_SEND_CRITIC_MAIL
FLG_SEND_MAIL_JOB
NUM_IDENT_INTERN
NOM_EXE
NOM_PROG
NOM_CLASSE
NUM_PRIORI
DSC_PARM
NOM_ARQ_SAIDA
NOM_USUAR
IND_TIPO_EXEC
DAT_HOR_EXEC
QTD_HOR_SOMA
FLG_EXEC_CONT
NOM_PROG_SUBSAO
FLG_SEND_MAIL_NOTES
IND_CONT_EXEC
IND_SEMAN
NUM_DIA
IND_RESTR
DAT_VALID_JOB
#
*
o
o
o
*
*
COD_FILA
DSC_FILA
IND_STAT_FILA
HOR_INIC
QTD_HORAS
QTD_JOB_PADRAO
QTD_JOB_TEMPOR
SCHEDULER
NOTIFY USERS
NOTES
JOB BATCH ORACLE
#
o
o
o
o
o
o
o
*
o
o
o
o
o
*
o
o
o
o
FILA EXECUCAO
#
o
o
*
*
*
o
#
o
o
o
o
o
o
o
o
DAT_CADSTR
FLG_UTLZCO_FAX
NOM_CONTA_USUAR
NOM_GUERRA
NOM_USUAR
TIPO_USUAR
COD_DEPEN_RH
COD_EMPR
COD_GRUPO_COTAC
COD_UNID_ORGZNL
DAT_ATUALZ_SENHA
DAT_DISPEN_USUAR
DAT_EXCLUS_USUAR
DAT_EXPIRA_SENHA
DAT_LIMITE_TERCER
DSC_ASSNTA_ELETRO
DSC_USUAR_CCMAIL
FLG_BLOQ_USUAR
IND_USUAR
NOM_IMPSRA_PAD
NOM_NOTES
NUM_CPF_USUAR
NUM_RAMAL_TEL
NUM_TEL
SENHA_USUAR_ESPEC
USUAR_DISPEN
USUAR_TROCA_SENHA
#
o
o
o
o
o
o
o
o
*
#
o
o
o
DSC_NODO_REDE
NOM_NODO_REDE
IND_TIPO_SERVDR
NOM_IP
NUM_END_REDE
NOM_ARQ_SAIDA
QTD_BYTE_ARQ_SAIDA
IND_ARQ_SAIDA
QTD_PAGINA
FLG_ARQ_REDUZ
FLG_COMPRS
IND_CARACT_IMPSRA
NUM_SEQ
IND_ARQ_STATUS
PROFILE USUARIO
FILA IMPRESSAO
o NOM_FILA_IMPSAO_ULT
*
*
#
o
o
FLG_COR
IND_TIPO_IMPSAO
NOM_FILA_IMPSAO
DSC_LOCALZ
IND_CARACT_IMPRSA
FORMULARIO
IMPRESSAO
# NOM_FORMLR
o DSC_FORMLR
LIMITE SUBMISSAO
BATCH
# COD_TIPO_LIMITE
o DSC_LIMITE
o QTD_LIMITE_BYTE
PROGRAMA COMPUTADOR
PERFIL
NODO REDE
LOG ARQ SAIDA
USUARIO
*
*
#
*
*
*
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
NUM_IDENT_INTERN
NUM_IDENT_EXEC
NOM_EXE
NOM_PROG
NOM_CLASSE
NUM_PRIORI
DSC_PARM
NOM_USUAR
DAT_HOR_INCL
DAT_HOR_INIC_EXEC
DAT_HOR_FIM_EXEC
DAT_HOR_IMPR
IND_JOB_STATUS
IND_JOB_CANCDO
NOM_PROG_SUBSAO
NOM_ARQ_LOG
LOG BATCH ORACLE ACUM
*
*
*
*
*
o
o
o
o
NUM_IDENT_INTERN
NOM_EXE
NOM_CLASSE
NOM_USUAR
DAT_HOR_INCL
DAT_HOR_INIC_EXEC
DAT_HOR_FIM_EXEC
NOM_PROG_SUBSAO
DSC_PARM
* DAT_INCL_PROG_PERFIL
* IND_STATUS_REG
USUARIO PERFIL
PERFIL
#
*
*
o
COD_SEQ_PERFIL
DAT_ULT_RECONC
NOM_PERFIL
DSC_PERFIL
*
*
*
o
DAT_LIBER_USUAR
FLG_MODIF_BLOQ
IND_CATEG_LIBER
NOM_CONTA_USUAR_LIBER
61
ENTITY MODEL INFORMATION
ARQUIVO SAIDA
Which has significance as :
Entidade que contém os arquivos de saída à serem gerados.
Um PROGRAMA DE COMPUTADOR pode ter um ou mais arquivos de saída.
O Scheduler utiliza esta informação para gravar na LOG_ARQ_SAIDA
os arquivos de saída que serão gerados pelo programa submetido.
Information includes
flg_seq : Indica se a extensão deve ser gerada ticamente
nom_arq_saida : Nome do arquivo de saída
nom_path : Path do arquivo
nom_suf_arq : Extensão do arquivo
num_seq : Número Seqüência
Each must be ter
one and only one programa computador
BANCO DADOS
Which has significance as :
Entidade que contém os banco de dados segundo os padrões da
empresa.
Information includes
cod_banco_dado : Número sequencial do banco de dados
dsc_banco_dado : Descricao do Banco de Dados
dsc_connct_string : String de conexão na rede
flg_bd_local : Indica se o banco de dados é local
flg_role : Indica o status da role
ind_tipo_ambien : Tipo de ambiente (UNIX, NT,...)
nom_banco_dado : Nome do Banco de Dados
nom_connct_odbc : Nome da Conexão ODBC
nom_dblink : Nome do Database Link
nom_deflt_tbspce : Nome da tablespace default
nom_tempor_tbspce : Nome da tablespace temporária
Each may be anterior one and only one banco dados
and may be proximo
one or more banco_dado
and must be instalado one and only one nodo rede
and may be pertencer
one or more fila_exec
and may be ter one and only one configuracao scheduler
CONFIGURACAO SCHEDULER
Which has significance as :
Informações da configuração ativa (do momento) do scheduler.
O scheduler é o programa que fica rodando em memória e executa os
processos solicitados pelos usuários.
62
Information includes
flg_debug_proces : Gerar informações adicionais no LOG
flg_send_critic_mail : Envio de mensagens críticas para o
mail do administrador
flg_send_mail_job : Seta o envio de mail para os usuários
ind_status_schler : Status do scheduler
num_dias_perm_log : Número de dias que o arquivo log é
guardado
Each must be pertencer one and only one nodo rede
and must be pertencer one and only one banco dados
and may be ter
one or more schler_notify_user_notes
FILA EXECUCAO
Which has significance as :
Informações e características das FILAS de execução disponíveis.
Information includes
cod_fila : Código da fila de execução
dsc_fila : Descrição da fila de execução
hor_inic : Hora do inicio da execução
ind_status_fila : Status da fila
qtd_horas : Quantidade de horas à executar
qtd_job_padrao : Quantidade de Jobs que a fila suporta
qtd_job_tempor : Quantidade de Jobs temporário utilizados
pela fila
Each must be ter
one and only one banco dados
FILA IMPRESSAO
Entidade que especifíca as impressoras da companhia e suas
características.
Information includes
dsc_localz : Localização da impressora correspondente à
fila
flg_cor : Impressora colorida (S/N)
ind_caract_imprsa : Padrão de caractere da impressora
(Normal, Postscript)
ind_tipo_impsao : Tipo de impressora
nom_fila_impsao : Nome da fila de impressão
Each must be localizada one and only one nodo rede
and may be pertencer
one or more profil_usuar
FORMULARIO IMPRESSAO
Which has significance as :
Tipos de Formulários de impressão disponíveis.
Information includes
dsc_formlr : Descrição do Formulário
nom_formlr : Nome do Formulario
Each may be pertencer one or more
profil_usuar
63
JOB BATCH ORACLE
Which has significance as :
Esta entidade contém as solicitações de execução e impressão dos
usuários.
Information includes
dat_hor_exec : Data e hora da solicitação de início da
execução.
dat_valid_job : Data em que o JOB programado não será mais
válido
dsc_parm : Parâmetros das execução/impressão/cancelamento
flg_send_mail_notes : Indica se é para transmitir Mail
após execução do Job
ind_cont_exec : Indicador de tipo de programação de JOB
ind_restr : Indicador de restrição de dia
ind_seman : Indicador de dias da semana para execução do
job
ind_tipo_exec : Indicador de tipo de execução
nom_arq_saida : Nome do arquivo de saída
nom_classe : Nome da fila de execução
nom_exe : Nome do executável
nom_prog : Nome do programa já montado com o path
nom_prog_subsao : Nome do programa submetido
nom_usuar : Nome da conta do usuário
num_dia : Número do dia do mês que o job deve executar
num_ident_intern : Número de identificação interna do JOB
num_priori: Prioridade do JOB
qtd_hor_soma : Quantidade de horas que o programa deve
novamente ser submetido
Each must be estar
one and only one programa computador
LIMITE SUBMISSAO BATCH
Which has significance as :
Entidade que contém os limites da submissão batch. Especifíca
tipos de restrições aos usuário.
Information includes
cod_tipo_limite : Código do tipo de limite
dsc_limite : Descrição da função do limite
qtd_limite_byte : Quantidade de bytes na qual o limite
passa a valer
LOG ARQ SAIDA
Which has significance as :
Relação de arquivos gerados pelo JOB.
Esta lista é derivado das entidades Prog_comput e Arq_saida.
Information includes
flg_arq_reduz : Indica se o arquivo deve ser reduzido
flg_comprs : Indica se o arquivo deve ser comprimido
ind_arq_saida : Status da gravação do arquivo
ind_arq_status : Status do arquivo
64
ind_caract_impsra : Tipo de impressora Post-script ou
Texto
nom_arq_saida : Nome do arquivo de saída
num_seq : Numero de sequencia do arquivo de saida para um
mesmo job
qtd_byte_arq_saida : Quantidade de Bytes do arquivo de
saida
qtd_pagina : Quantidade páginas do relatório
Each must be pertencer
one and only one log batch oracle
LOG BATCH ORACLE
Which has significance as :
Esta entidade contém o registro de execução dos JOBs.
Os JOBs que estão nesta entidade são todos que estão executando
ou já executaram.
Information includes
dat_hor_fim_exec : Data e hora de fim da execução
dat_hor_impr : Data e Hora do pedido de impressão
dat_hor_inic_exec : Data e hora de início da execução do
JOB
dsc_parm : Parâmetros das execução/impressão
ind_job_cancdo : Flag de JOB Cancelado
ind_job_status : Status do JOB
nom_arq_log : Nome do log de saida
nom_classe : Código da classe (fila de execução)
nom_exe : Nome do executável
nom_prog : Nome do programa com o path
nom_prog_subsao : Nome do programa submetido
nom_usuar : Nome da conta do usuário
num_ident_exec : Numero de identificação do sistema
Operacional
num_ident_intern : Numero de identificação interna do JOB
num_priori : Prioridade do JOB
Each must be ter
one or more
log_arq_saida
LOG BATCH ORACLE ACUM
Which has significance as :
Entidade utilizada para acumular as estatísticas de execução.
Information includes
dat_hor_fim_exec : Data e hora de fim da execução
dat_hor_incl : Data e hora de inclusão do JOB na fila
dat_hor_inic_exec : Data e hora de início da execução do
JOB
dsc_parm : Parâmetros das execução/impressão
nom_classe : Código da classe (fila de execução)
nom_exe : Nome do executável
nom_prog_subsao : Nome do programa submetido
nom_usuar : Nome da conta do usuário
num_ident_intern : Numero de identificação interna do JOB
65
NODO REDE
Which has significance as :
Entidade que contém todos os servidores da companhia. Maquinas
servidoras no escopo Souza Cruz.
Information includes
dsc_nodo_rede : Descrição do Nodo de Rede
ind_tipo_servdr : Indica o tipo de servidor
nom_ip : Numero de IP da máquina
nom_nodo_rede : Nome do Nodo de Rede
num_end_rede : Numero de endereço na rede
Each may be ter
one or more banco_dado
and may be possui
one or more fila_impsao
and may be ter one and only one configuracao scheduler
PERFIL
Which has significance as :
Perfil dos usuários. Determina as funções que um usuário pode
Executar em um determinado sistema.
Information includes
cod_seq_perfil : Codigo Sequencial do perfil
dat_ult_reconc : Data da última reconciliação
dsc_perfil : Descrição do perfil
nom_perfil : Nome do perfil
Each may be estar liberado
one or more prog_comput_perfil
and may be definir
one or more usuar_perfil
PROFILE USUARIO
Which has significance as :
Informações referentes a última impressora e
formulário utilizado pelo usuário.
Information includes
nom_fila_impsao_ult : Nome da ultima impressora utilizada
Each must be ter one and only one formulario impressao
and must be pertencer one and only one usuario
and must be ter one and only one fila impressao
PROGRAMA COMPUTADOR
Information includes
dsc_prog : Descrição do programa
dsc_tipo_modulo : Descrição do tipo de módulo
flg_prog_public : Indica se o programa é público ou não
flg_transf : Indica se o programa é transferível ou não
ind_caract_impr : Tipo de impressora Post-script ou Texto
ind_classf_risco : Classificação de risco
ind_fonte : Tipo de fonte
ind_local_exec : Local de execução
66
ind_nivel : Nivel de compartilhamento do programa
ind_nivel_drtrio : Nivel de compartilhamento do programa
entre aplicações
nom_classe : Código da classe (fila de execução)
nom_prog : Nome do programa
num_priori : Prioridade execução
num_versao_report : Versão do report (se couber)
sig_area_usuar : Sigla da área de atuação
Each may be estar liberado
one or more prog_comput_perfil
and may be ser dependente one and only one programa computador
and may be ter
one or more prog_comput
and may be possuir
one or more arq_saida
and may be pertencer one and only one job batch oracle
PROGRAMA COMPUTADOR PERFIL
Information includes
dat_incl_prog_perfil : Data de inclusão do programa no
perfil
ind_status_reg : Índice de status do registro
Each must be liberar one and only one perfil
and must be ser de one and only one programa computador
SCHEDULER NOTIFY USERS NOTES
Which has significance as :
Esta entidade comtém uma lista de usuário que irão receber mail
NOTES, caso ocorra erros críticos no DUT.
Exemplo de erros Críticos:
Falta de espaço no FileSystem,
Falta de espaço no tablespace USERS ou TEMP
Banco de dados não disponível.
Each must be pertencer one and only one configuracao scheduler
and must be pertencer one and only one usuario
USUARIO
Which has significance as :
Entidade que abrange todos os usuários da companhia.
Information includes
cod_depen_rh : Código do RH (Recursos Humanos)
cod_empr : código do empregado
cod_grupo_cotac : código do grupo de cotação
cod_unid_orgznl : Código da unidade organizacional
dat_atualz_senha : Data da atualização da senha
dat_cadstr : Data do cadastramento
dat_dispen_usuar : Data de dispensa do usuário
dat_exclus_usuar : Data de exclusão do usuário
dat_expira_senha : Data da expiração da senha
dat_limite_tercer : Data do limite do terceiro
dsc_assnta_eletro : Descrição assinatura eletrônica
dsc_usuar_ccmail : Descrição do mail
flg_bloq_usuar: flg de bloqueio do usuário
67
flg_utlzco_fax : flg de utilização de FAX
ind_usuar : índice do usuário
nom_conta_usuar : Nome da conta do usuário
nom_guerra : Nome de guerra
nom_impsra_pad : impressora associada ao usuário
nom_notes : Nome no correio eletrônico
nom_usuar : Nome do usuário
num_cpf_usuar : número do CPF
num_ramal_tel : número do ramal
num_tel : número do telefone
senha_usuar_espec : Senha do usuário especial
tipo_usuar : tipo do usuário (NORMAL, ESPECIAL)
usuar_dispen : flg usuário dispensado
usuar_troca_senha, etc.
Each may be supervisionar
one or more usuar
and may be ser supervisionado one and only one usuario
and may be pertencer
one or more usuar_perfil
and may be é tranferido one and only one usuario
and may be transferiu para one and only one usuario
and may be cadastra2
one or more usuar
and must be ser cadastrado2 por one and only one usuario
and may be ter one and only one profile usuario
and may be ter one and only one scheduler notify users notes
USUARIO PERFIL
Which has significance as :
Entidade associativa entre perfil e usuários
define os perfis de um usuário para um sistema.
Information includes
dat_liber_usuar : Data de liberação ao usuário
flg_modif_bloq : flag de modificação de bloco
ind_categ_liber : Indice da categoria de liberação
nom_conta_usuar_liber : Nome da conta do usuário
administrador
Each must be definir one and only one usuario
and must be pertencer one and only one perfil
68
ANEXO 2 MODELO ENTIDADE RELACIONAMENTO
DA FERRAMENTA INTERFACE DO
ADMINISTRADOR
69
FILA EXECUCAO
CONFIGURACAO SCHEDULE
R
*
o
o
*
o
#
*
o
o
o
*
*
FLG_DEBUG_PROCES
NUM_DIAS_PERM_LOG
IND_STATUS_SCHLER
FLG_SEND_CRITIC_MAIL
FLG_SEND_MAIL_JOB
COD_FILA
DSC_FILA
IND_STATUS_FILA
HOR_INIC
QTD_HORAS
QTD_JOB_PADRAO
QTD_JOB_TEMPOR
NODO REDE
*
#
o
o
o
DSC_NODO_REDE
NOM_NODO_REDE
IND_TIPO_SERVDR
NOM_IP
NUM_END_REDE
BANCO DADOS
*
*
*
*
*
#
*
*
o
o
o
SCHEDULER NOTIFY USERS NOTES
COD_BANCO_DADO
DSC_BANCO_DADO
DSC_CONNCT_STRING
FLG_BD_LOCAL
IND_TIPO_AMBIEN
NOM_BANCO_DADO
NOM_DEFLT_TBSPCE
NOM_TEMPOR_TBSPCE
FLG_ROLE
NOM_CONNCT_ODBC
NOM_DBLINK
USUARIO
JOB BATCH ORACLE
*
*
#
*
*
*
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
#
o
o
o
o
o
o
o
*
o
o
o
o
*
o
o
o
o
DAT_CADSTR
FLG_UTLZCO_FAX
NOM_CONTA_USUAR
NOM_GUERRA
NOM_USUAR
TIPO_USUAR
COD_DEPEN_RH
COD_EMPR
COD_GRUPO_COTAC
COD_UNID_ORGZNL
DAT_ATUALZ_SENHA
DAT_DISPEN_USUAR
DAT_EXCLUS_USUAR
DAT_EXPIRA_SENHA
DAT_LIMITE_TERCER
DSC_ASSNTA_ELETRO
DSC_USUAR_CCMAIL
FLG_BLOQ_USUAR
IND_USUAR
NOM_IMPSRA_PAD
NOM_NOTES
NUM_CPF_USUAR
NUM_RAMAL_TEL
NUM_TEL
SENHA_USUAR_ESPEC
USUAR_DISPEN
NUM_IDENT_INTERN
NOM_EXE
NOM_PROG
NOM_CLASSE
NUM_PRIORI
DSC_PARM
NOM_ARQ_SAIDA
NOM_USUAR
IND_TIPO_EXEC
DAT_HOR_EXEC
QTD_HOR_SOMA
NOM_PROG_SUBSAO
FLG_SEND_MAIL_NOTES
IND_CONT_EXEC
IND_SEMAN
NUM_DIA
IND_RESTR
DAT_VALID_JOB
PROGRAMA COMPUTADOR
*
#
o
o
o
o
o
o
o
o
o
o
o
o
o
LIMITE SUBMISSAO BATCH
# COD_TIPO_LIMITE
o DSC_LIMITE
o QTD_LIMITE_BYTE
PROGRAMA COMPUTADOR PERFIL
* DAT_INCL_PROG_PERFIL
* IND_STATUS_REG
DSC_PROG
NOM_PROG
DSC_TIPO_MODULO
FLG_PROG_PUBLIC
FLG_TRANSF
IND_CARACT_IMPR
IND_CLASSF_RISCO
IND_FONTE
IND_LOCAL_EXEC
IND_NIVEL
IND_NIVEL_DRTRIO
NOM_CLASSE
NUM_PRIORI
NUM_VERSAO_REPORT
SIG_AREA_USUAR
USUARIO PERFIL
*
*
*
o
DAT_LIBER_USUAR
FLG_MODIF_BLOQ
IND_CATEG_LIBER
NOM_CONTA_USUAR_LIBER
LOG BATCH ORACLE
#
o
o
*
*
*
o
#
o
o
o
o
o
o
o
NUM_IDENT_INTERN
NUM_IDENT_EXEC
NOM_EXE
NOM_PROG
NOM_CLASSE
NUM_PRIORI
DSC_PARM
NOM_USUAR
DAT_HOR_INIC_EXEC
DAT_HOR_FIM_EXEC
DAT_HOR_IMPR
IND_JOB_STATUS
IND_JOB_CANCDO
NOM_PROG_SUBSAO
NOM_ARQ_LOG
PERFIL
FORMULARIO IMPRESSAO
#
*
*
o
# NOM_FORMLR
o DSC_FORMLR
COD_SEQ_PERFIL
DAT_ULT_RECONC
NOM_PERFIL
DSC_PERFIL
LOG BATCH ORACLE ACUM
*
*
*
*
*
o
o
o
o
NUM_IDENT_INTERN
NOM_EXE
NOM_CLASSE
NOM_USUAR
DAT_HOR_INCL
DAT_HOR_INIC_EXEC
DAT_HOR_FIM_EXEC
NOM_PROG_SUBSAO
DSC_PARM
70
ANEXO 3 MODELO FÍSICO DE DADOS DA
FERRAMENTA INTERFACE DO ADMINISTRADOR
71
BCOD_PROXIMO
# * COD_FILA
* NOM_BANCO_DADO
* DSC_FILA
* QTD_JOB_PADRAO
* QTD_JOB_TEMPOR
* IND_STATUS_FILA
o HOR_INIC
o QTD_HORAS
NODO_REDE @ *ALL* (#)
BANCO_DADO @ *ALL* (#)
FILA_EXEC @ *ALL* (#)
FLE_BCOD_FK
BCOD_INSTALADO
# * NOM_BANCO_DADO
* DSC_BANCO_DADO
* DSC_CONNCT_STRING
o FLG_BD_LOCAL
* NOM_NODO_REDE
o NOM_BANCO_DADO_PROX
o NOM_DBLINK
* NOM_DEFLT_TBSPCE
* NOM_TEMPOR_TBSPCE
* IND_TIPO_AMBIEN
* NOM_CONNCT_ODBC
* FLG_ROLE
* COD_BANCO_DADO
CS_BCOD_FK
SNUN_CS_FK
SCHLER_NOTIFY_USER_NOTES @ *ALL* (#)
# * NOM_BANCO_DADO
# * NOM_CONTA_USUAR
# * NOM_NODO_REDE
* DSC_NODO_REDE
* COD_EMP
* COD_LOCALD
o NUM_END_REDE
o IND_TIPO_SERVDR
o NOM_IP
o NOM_NOTES_ENVIO
CS_NDRD_FK
CONFIG_SCHLER @ *ALL* (#)
# * NOM_BANCO_DADO
* FLG_DEBUG_PROCES
* FLG_SEND_CRITIC_MAIL
o NUM_DIAS_PERM_LOG
* IND_STATUS_SCHLER
o FLG_SEND_MAIL_JOB
* NOM_NODO_REDE
V_LOG_BATCH @ *ALL*
o NOM_EXE
o NOM_USUAR
o NOM_PROG_SUBSAO
o DAT_HOR_INIC_EXEC
o DAT_HOR_FIM_EXEC
o QTD_TPO_EXEC
FORMLR_IMPR @ *ALL* (#)
USUAR_PERFIL @ *ALL* (#)
# * COD_SISTEM
# * COD_SEQ_PERFIL
# * NOM_CONTA_USUAR
* DAT_LIBER_USUAR
* FLG_MODIF_BLOQ
* IND_CATEG_LIBER
o NOM_CONTA_USUAR_LIBER
# * NOM_FORMLR
o DSC_FORMLR
US_SER_SUPERVISIONA
US_SER_CADASTRADO2_POR_USUAR
USUAR @ *ALL* (#)
SNUN_US_FK
USPF_PERTENCER
USPF_DEFINIR
JOB_BATCH_ORACLE @ *ALL* (#)
PERFIL @ *ALL* (#)
# * COD_SISTEM
# * COD_SEQ_PERFIL
* NOM_PERFIL
o DSC_PERFIL
* DAT_ULT_RECONC
PGPF_LIBERAR
# * NUM_IDENT_INTERN
* IND_TIPO_EXEC
* IND_CONT_EXEC
* NOM_USUAR
o NOM_EXE
o NOM_PROG
o NOM_CLASSE
o NUM_PRIORI
o DSC_PARM
o NOM_ARQ_SAIDA
o DAT_HOR_EXEC
o QTD_HOR_SOMA
o NOM_PROG_SUBSAO
o FLG_SEND_MAIL_NOTES
o IND_SEMAN
o NUM_DIA
o IND_RESTR
o DAT_VALID_JOB
JBO_US_FK
JBO_PROG_FK
# * NOM_CONTA_USUAR
* NOM_USUAR
* NOM_GUERRA
* FLG_UTLZCO_FAX
* DAT_CADSTR
o NOM_CONTA_USUAR_SUPERV
o NOM_IMPSRA_PAD
o NUM_RAMAL_TEL
o NUM_TEL
* COD_EMP
* COD_LOCALD
* SIG_AREA
o DSC_USUAR_CCMAIL
o DAT_ATUALZ_SENHA
* TIPO_USUAR
o SENHA_USUAR_ESPEC
o DSC_ASSNTA_ELETRO
o COD_EMPR
o COD_DEPEN_RH
o NOM_NOTES
o COD_UNID_ORGZNL
o FLG_BLOQ_USUAR
o COD_GRUPO_COTAC
o DAT_DISPEN_USUAR
o DAT_LIMITE_TERCER
o IND_USUAR
o DAT_EXPIRA_SENHA
o COD_CATEG_USUAR
o NOM_CONTA_USUAR_RESPON
o USUAR_DISPEN
o USUAR_TROCA_SENHA
o NOM_CONTA_USUAR_TRANSF
o NUM_CPF_USUAR
o DAT_EXCLUS_USUAR
...
US_SER_TRANSFERIDO
PROG_COMPUT @ *ALL* (#)
PROG_COMPUT_PERFIL @ MTB1CDBD (#)
# * COD_SISTEM
# * COD_SEQ_PERFIL
# * NOM_PROG
* DAT_INCL_PROG_PERFIL
* IND_STATUS_REG
PGPF_ESTAR_LIBERADO
LIMITE_SUBMISSAO_BATCH @ *ALL* (#)
# * COD_TIPO_LIMITE
o DSC_LIMITE
o QTD_LIMITE_BYTE
# * NOM_PROG
* DSC_PROG
* COD_APLIC_SISTEM
* COD_TIPO_AMBIEN
o NOM_CLASSE
o IND_LOCAL_EXEC
o NUM_PRIORI
o IND_FONTE
o SIG_AREA_USUAR
o IND_NIVEL_DRTRIO
o IND_CLASSF_RISCO
o FLG_PROG_PUBLIC
o IND_CARACT_IMPR
o DSC_TIPO_MODULO
o FLG_TRANSF
o COD_FORMAT_IMPSAO
o NUM_VERSAO_REPORT
72
ANEXO 4 MODELO HIERÁRQUICO DOS MÓDULOS
DA FERRAMENTA INTERFACE DO
ADMINISTRADOR
73
74
ANEXO 5 RELATÓRIOS DA FERRAMENTA
INTERFACE DO ADMINISTRADOR