Mudanças entre as edições de "Comunicação Homem-Máquina"
| Linha 27: | Linha 27: | ||
'''GERAIS:''' A linguagem para CHM deve entender basicamente aos requisitos tais como: | '''GERAIS:''' A linguagem para CHM deve entender basicamente aos requisitos tais como: | ||
| − | + | *Segurança - mecanismo que assegurem a rejeição de comandos que comprometam a integridade do sistema, ou nele interfira de modo prejudicial; | |
| − | + | *Confiabilidade - garantia de inteligibilidade e funcionabilidade do sistema de CHM; | |
| − | + | *Simplicidade de Entendimento - facilidade de interpretação das mensagens; | |
| − | + | *Conversacionalidade - possibilidade de interação através do diálogo HM; | |
| − | + | *Flexibilidade - facilidade de adaptação às necessidades da Empresa operadora, através da introdução de novos comandos; | |
| − | + | *Facilidade de Utilização - comunicação clara, direta e objetiva em lingua portuguesa. | |
A linguagem para CHM deve seguir recomendações estabelecidas pelo CCITT(recomendações Z301 à Z331). | A linguagem para CHM deve seguir recomendações estabelecidas pelo CCITT(recomendações Z301 à Z331). | ||
| Linha 42: | Linha 42: | ||
O software para CHM deve ter os seguintes requisitos: | O software para CHM deve ter os seguintes requisitos: | ||
| − | + | *Níveis de prioridade das mensagens de saída.Ex: Alarmes e relatórios. | |
| − | + | *Prioridade das mensagens de saída em relação a comandos de entrada, com possibilidade de interrupção das saídas, através de comandos específicos. | |
| − | + | *estrutura modular de forma a permitir a inserção de uma nova função sem afetar as já existentes. | |
| − | + | *Permitir a especialização de periféricos de E/S de forma a garantir um padrão de segurança e confiabilidade na interação homem-maquina. | |
| − | + | *Possuir mecanismos de segurança e confiabilidade, tendo redundância de periféricos, em caso de indisponibilidade de funcionamento outro periférico (reserva) assume automaticamente. | |
| − | + | *Possuir mecanismo de proteção (pressionamento de certas funções) contra acessos não autorizados. | |
| − | + | *Possibilidade de confirmação do comando de supressão. | |
| − | + | *Diferenciação de formato entre comando de entrada e mensagem de resposta para operador. | |
| − | + | *Consistência e critica, de imediato, aos comandos de entrada contra erros de utilização de linguagem. | |
| − | + | *Possibilidade de minimizar a intervenção de operadores , com os macro-comandos. | |
| − | + | *Qualquer solicitação de operador a partir de um periférico, deve ser respondida nele mesmo a menos que outro periférico seja indicado para a resposta. | |
| − | + | *Possibilidade de haver um periférico mestre, que registrara todas as ocorrências na comunicação. | |
| − | + | *Carga de arquivos via programas, a pedido do operador. | |
| − | + | *Atribuição de prioridades para programas, de forma que processos mais urgentes possam ser atendidos prontamente. | |
| − | + | *Gerencia de dispositivos de entrada e saída para que se tenha: Otimização de uso dos periféricos. | |
| − | + | *Geração de escalonamento de execução de programas. | |
| − | + | *Análise de compatibilidade de execução de programas. | |
| − | + | *Cancelamento de execução de programas a pedido do operador. | |
| − | + | *Possibilidade de emissão de relatórios que retrate a utilização de programas. | |
| − | + | *Possibilidade de interação entre programas carregáveis e residentes. | |
| − | + | *Continuidade nas linhas de impressão de mensagens por impressora. | |
| − | + | *Alocação de periféricos a uma tarefa especifica, a critério do operador. | |
| − | + | *Mudança do modo direto para o modo interativo ou menu. | |
| − | + | *possibilidade de perfeita navegabilidade entre as diversas opções do menu e comandos do sistema. | |
| − | + | *Possibilidade de configuração e reconfiguração do sistema e da especialização dos periféricos, com comandos de CHM. | |
| − | + | *Por CHM deverá ser possível fazer associação de códigos alfanuméricos, com a finalidade de facilitar a operação do sistema. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== COMANDOS == | == COMANDOS == | ||
Edição das 10h30min de 11 de setembro de 2006
INTERFACE HOMEM-MÁQUINA
A interface é responsável por fazer o usuário ter condições de interagir com a funcionalidade do sistema. Fazer a qualidade de vida do usuário melhor. Entender a comunidade de usuários e tarefas. Análise dos requisitos, dos usuários, das tarefas, concepção, especificação e prototipação da interface e avaliação da utilização do protótipo.
DESENVOLVIMENTO DA INTERFACE
PADRÕES: São referências, amplas e genéricas, geralmente empregadas em todos os projetos de interface. Exemplos: consistência, minimizar erros, recuperar erros, metáforas, etc.
DIRETRIZES: ações/especificações propostas por manuais, guias ou livros, geralmente disponíveis ao público. Exemplos: desenho centrado no usuário, considere a limitação da memória humana, etc.
GUIDELINES: são guias de estilo, especificam o comportamento e os elementos da interface com detalhes. Exemplos: botão de iniciar no rodapé da página, lado esquerdo, Botão cancelar é o default, etc
DEFINIÇÕES
LINGUAGEM PARA CHM: É a forma através da qual os usuários se interagem com o sistema, utilizando recursos exclusivamente computacionais. A sua finalidade é permitir a operação e a supervisão de toda a rede do SARTRA( Sistema Automático Remoto de Testes da Rede de Assinantes).
PERIFÉRICOS: São os dispositivos através dos quais são estabelecidas as comunicações entre os usuários e o sistema. Podem ser:
Terminal de vídeo com modo de transmissão caractere à caractere; Terminal de vídeo com modo de transmissão por bloco de caractere; Teleimpressora; Impressora; Microcomputadores pessoais; Telefone.
DESCRIÇÃO DOS REQUISITOS
GERAIS: A linguagem para CHM deve entender basicamente aos requisitos tais como:
- Segurança - mecanismo que assegurem a rejeição de comandos que comprometam a integridade do sistema, ou nele interfira de modo prejudicial;
- Confiabilidade - garantia de inteligibilidade e funcionabilidade do sistema de CHM;
- Simplicidade de Entendimento - facilidade de interpretação das mensagens;
- Conversacionalidade - possibilidade de interação através do diálogo HM;
- Flexibilidade - facilidade de adaptação às necessidades da Empresa operadora, através da introdução de novos comandos;
- Facilidade de Utilização - comunicação clara, direta e objetiva em lingua portuguesa.
A linguagem para CHM deve seguir recomendações estabelecidas pelo CCITT(recomendações Z301 à Z331).
DIÁLOGO: A interação entre o usuário e o sistema deve ser feita em linguagem e terminologia próprias aos usuários do sistema, deve ser minimizada a operação baseada em manuais não necessitando dos mesmos para a compreensão, deve ser possível a interação entre o sistema e o usuário durante o tratamento de qualquer comando.
SOFTWARE PARA CHM:
O software deve oferecer facilidade de controle do sistema e as necessidades de operação , supervisão, gerencia da rede configurada e informações de entrada e saída.
O software para CHM deve ter os seguintes requisitos:
- Níveis de prioridade das mensagens de saída.Ex: Alarmes e relatórios.
- Prioridade das mensagens de saída em relação a comandos de entrada, com possibilidade de interrupção das saídas, através de comandos específicos.
- estrutura modular de forma a permitir a inserção de uma nova função sem afetar as já existentes.
- Permitir a especialização de periféricos de E/S de forma a garantir um padrão de segurança e confiabilidade na interação homem-maquina.
- Possuir mecanismos de segurança e confiabilidade, tendo redundância de periféricos, em caso de indisponibilidade de funcionamento outro periférico (reserva) assume automaticamente.
- Possuir mecanismo de proteção (pressionamento de certas funções) contra acessos não autorizados.
- Possibilidade de confirmação do comando de supressão.
- Diferenciação de formato entre comando de entrada e mensagem de resposta para operador.
- Consistência e critica, de imediato, aos comandos de entrada contra erros de utilização de linguagem.
- Possibilidade de minimizar a intervenção de operadores , com os macro-comandos.
- Qualquer solicitação de operador a partir de um periférico, deve ser respondida nele mesmo a menos que outro periférico seja indicado para a resposta.
- Possibilidade de haver um periférico mestre, que registrara todas as ocorrências na comunicação.
- Carga de arquivos via programas, a pedido do operador.
- Atribuição de prioridades para programas, de forma que processos mais urgentes possam ser atendidos prontamente.
- Gerencia de dispositivos de entrada e saída para que se tenha: Otimização de uso dos periféricos.
- Geração de escalonamento de execução de programas.
- Análise de compatibilidade de execução de programas.
- Cancelamento de execução de programas a pedido do operador.
- Possibilidade de emissão de relatórios que retrate a utilização de programas.
- Possibilidade de interação entre programas carregáveis e residentes.
- Continuidade nas linhas de impressão de mensagens por impressora.
- Alocação de periféricos a uma tarefa especifica, a critério do operador.
- Mudança do modo direto para o modo interativo ou menu.
- possibilidade de perfeita navegabilidade entre as diversas opções do menu e comandos do sistema.
- Possibilidade de configuração e reconfiguração do sistema e da especialização dos periféricos, com comandos de CHM.
- Por CHM deverá ser possível fazer associação de códigos alfanuméricos, com a finalidade de facilitar a operação do sistema.
COMANDOS
CÓDIGOS DE COMANDOS:
Os códigos de comandos devem ser compostos de seis caracteres (maiúsculos) divididos em três campos. Os campos de caracteres devem ser mnemônicos a fim de identificar claramente , a ação , o objeto da ação e o recurso, cujas especificações estão descritas a seguir:
- Ação : especifica a função de operação que se pretende executar.
- Objeto da Ação : especifica a característica do recurso que sofrera a ação.
- Recurso : especifica o recurso que sofrerá a ação.
Existem oito diferentes ações que podem ser exercidas sobre o sistema para atender aos processos de operação, manutenção, supervisão e gerencia do SARTRA:
CRIAÇÃO - MNEMÔNICO C: Reconhecimento lógico da existencia de recursos físicos ou não, do SARTRA.
SUPRESSÃO - MNEMÔNICO S: Reconhecimento lógico da não existência de recursos, físicos ou não do SARTRA.
INTERROGAÇÃO - MNEMÔNICO I: Obtenção de informação sobre a configuração do sistema, dados semi-permanentes, arquivos, tabelas, falhas, alarmes etc..
MODIFICAÇÃO - MNEMÔNICO M: Alteração de configuração, dados semi-permanentes etc..
PROGRAMAÇÃO - MNEMÔNICO P: Previsão em agenda da ativação de processos de coleta de dados, de testes, controle etc..
REMOÇÃO - MNEMÔNICO R: Retirada de agenda da programação de ativação de processos de coleta de dadso, de testes, controle etc..
ATIVAÇÃO - MNEMÔNICO A: Solicitação de execução de processos de coleta de dados, de teste, controles etc..
DESATIVAÇÃO - MNEMÔNICO D: Solicitação de suspensão de execução de processos de coleta de dados, de teste, controle etc..
Os objetivos de ação para entender aos processos de operação, manutenção, supervisão e gerência do SARTRA e seus respectivos mnemônicos estão descritos a seguir:
AAL - Associação de classes de alarmes
ALM - Alarme
AGE - Agenda
CAR - Carga de programa, arquivo, tela..
CME - Conteúdo de memória, arquivo, tela..
CNF - Configuração
DEB - Descarga de Buffer
EST - Estado operacional
EXL - Exame de linhas
LCO - Limite de controle de insucessos sucessivos
MAC - Macro-comandos
PGD - Programas disponíveis
REL - Relógio
SAI - Saída de periférico
SEN - Senha
SBD - Estatus
TAB - Tabela/Arquivos
TAL - Teste de alarmes
SUD - Supervisão de desempenho
O recurso sobre o qual podem ser executadas as ações para atender as configurações do SARTRA e seu mnemônico é ST - SARTRA.
PARÂMETROS: É o mnemônico de até seis caracteres que identifica os limites de aplicação de comando descritos a seguir:
AG - Identificação de agenda
APRAL - Identificação da forma de apresentação de alarme
AQ - Arquivo/Tabela/Buffer/conteúdo de memória..
AQD - Identificador do arquivo de destino
AQO - Identificador do arquivo de origem
CLASSE - Classe de alarme
CODFAL- Código de falha
CX - Código de comando
DATA - Data
DISEM - Dia da semana
DAD - Dados
ESPEC - Especificação de periférico
EST - Estado operacional
FER - Feriado ou dia especial
FUP - Follow-up
IOP - Identificação do operador
LICOI - Limite de controle de insucessos sucessivos
LIMI - Limite inferior do padrão de referências
LIMS - Limite superior do padrão de referências
MACRO - Macro-comando
MDST - Identificação do módulo do SARTRA
MODSAI - Modo de saída
MOA - Identificação do módulo de assinante
NA - Número de assinante
NE - Número de equipamento
NAT - Número de ativação
NUR - Número de repetições
PE - Identificador de periférico de saída
PERIF - Identificador de periférico
RELOG - Relógio data e hora
RO - Identificador de rotas de central
STEST - Identificador da natureza do teste
TEA - Tempo entre ativações
TIEXL - Tipo de exame
TOBS - Tempo de observação
TEMRT - Tempo de resposta de teste
DESCRIÇÂO DE PARAMETROS DA CENTRAL TROPICO RA
FONTES
- ESPECIFICACAO DE COMUNICACAO HOMEM/MAQUINA DO SIS-TEMA AUTOMATICO REMOTO DE TESTES DA REDE DE AS-SINANTES (SARTRA) SDT -Sistema de Documentação Telebrás, Número da Prática : 235-700-716.
- Exemplo em Espanhol
- Man-Machine Language MML