quinta-feira, 26 de novembro de 2009
segunda-feira, 23 de novembro de 2009
[FSI] Aula do dia 23/11/2009
Ai pessoal, material de suporte para GED no http://tinyurl.com/yhwnclz e Workflow no http://tinyurl.com/yajmtdu
[inap] Requisitos
Levantamento de Requisitos
Entrevistas
Workshop de requisitos
Brainstorm
Storyboards
Casos de uso
Role playing
Prototipagem
Levantamento de Requisitos (Entrevista)
Técnica simples e direta
Questões livres de contexto podem ajudar no alcance de entrevistas não-tendenciosas
Quem são os usuários?
Quem são os clientes?
As necessidades deles são diferentes?
Onde a solução desse problema pode ser encontrada?
Resultado: repositório de requisitos
Questionário não substitui uma entrevista.
Gerente:
Qual é sua visão do problema?
Quais são as mudanças desejadas com a solução do problema?
Em que ambiente essa solução deverá funcionar?
Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução?
Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)?
Gerente:
Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc...);
Como serão as integrações entre os sistemas?
Haverá migração de dados ? Em que estrutura estão esses dados?
Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue?
Como está estruturada a equipe de TI?
Usuário:
Qual é sua visão do problema?
Quais são as mudanças desejadas com a solução do problema?
Que facilidades você espera do sistema?
Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)?
Quais são as macro funcionalidades necessárias para os sistema?
Usuário:
Quais são as pessoas que se relacionam com o sistema?
Como são as telas imaginadas para o sistema (esboços de telas)?
Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar layout dos arquivos / fontes de dados)?
Outros
Manutenções:
Quais são as dificuldades de manutenção do sistema?
Qual é a qualidade das estruturas do banco de dados?
Qual é a qualidade do código fonte do aplicativo?
A documentação do sistema é suficiente e compreensível?
Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)?
Quais são os pontos de “gargalo” do sistema atual
Levantamento de Requisitos (Brainstorm)
É uma técnica em que as pessoas colocam tudo que vier na cabeça com relação ao projeto.
Muito útil quando existem diversos interessados no projeto.
É dividido em duas etapas.
Na primeira, anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o que importa mais é a quantidade, não deixe de anotar nada.
Na segunda etapa, debate-se com o grupo para ir refinando as idéias apresentadas anteriormente. Deixe as regras bem claras, e defina uma pessoa (facilitador) para “comandar” a reunião, para garantir que as regras sejam respeitadas.
Pode ser efetiva no desenvolvimento de um novo projeto, na fase inicial, para identificar requisitos de alto nível, aqueles mais macros.
Levantamento de Requisitos (Storyboarding)
Corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Esta técnica foi utilizada inicialmente no cinema e desenhos animados, representando um esboço dos personagens e da história.
Levantamento de Requisitos (Casos de Uso)
Descreve a funcionalidade proposta para o novo sistema.
Representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema.
É uma unidade de um trabalho significante.
Ex: o "login para o sistema", "registrar no sistema" e "criar pedidos".
Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto.
Um Caso de Uso pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.
Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.
Levantamento de Requisitos (Role Playing)
Esta técnica consiste em observar o usuário executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, você fazendo o trabalho deste usuário, para identificar suas dificuldades e necessidades, sentindo na pele como é realizar a tarefa.
Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos.
Levantamento de Requisitos (Prototipagem)
Criação, apresentação e debate de modelos de interação não funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema.
É a atividade de desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos, permitindo a descoberta de falhas difíceis de serem encontradas na comunicação verbal.
Um processo que propõe a criação de um protótipo de software objetiva apoiar a fase levantamento de requisitos a fim de prevenir as possíveis falhas no sistema.
Um protótipo simula a aparência e funcionalidade do software permitindo que os clientes, analistas, desenvolvedores e gerentes percebam os requisitos do sistema podendo interagir, avaliar, alterar e aprovar as características mais marcantes na interface e funções.
Os protótipos podem ser evolutivos ou descartáveis.
Regras de Negócio
Estabelecem requisitos gerais para o sistema, provenientes do próprio negócio como normas, políticas, legislações etc.
São declarações que restringem, derivam e fornecem condições de existência, representando o conhecimento do negócio.
Ex: Toda conta de telefone atrasada mais de n dias terá seu número bloqueado para receber chamadas.
Regras de Negócios
São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.
Descrevem a maneira pela qual a organização funciona.
Estas regras são identificadas e documentadas no chamado modelo de regras do negócio.
A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.
Alguns exemplos de regras do negócio:
O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.
Regras do negócio normalmente têm influência sobre uma ou mais funcionalidades.
Nome
Quantidade de inscrições possíveis Descrição
Um aluno não pode ser inscrever em mais de seis disciplinas por semestre letivo. Fonte
Coordenador da escola de informática Histórico
Data de identificação: 16/04/2006
Revisão - Passos de Requisitos
Levantar os requisitos do sistema através de entrevistas com representantes do usuário gestor e usuários finais, e registrá-los no Documento de Requisitos do Sistema
Atualizar o Glossário do projeto com novos termos identificados durante o levantamento de requisitos
Priorizar os requisitos levantados, em conjunto com o responsável por sua definição, como: essencial, importante ou desejado.
Classificar os requisitos levantados como: funcionais, não-funcionais ou regras de negócio.
Identificar, com base nos requisitos funcionais levantados, os usuários do sistema
Identificar os relacionamentos entre usuários e funcionalidades, representando-os através de um Diagrama de Casos de Uso inicial.
Revisar, junto aos representantes do usuário gestor e de usuários finais, o Documento de Requisitos do Sistema.
Entrevistas
Workshop de requisitos
Brainstorm
Storyboards
Casos de uso
Role playing
Prototipagem
Levantamento de Requisitos (Entrevista)
Técnica simples e direta
Questões livres de contexto podem ajudar no alcance de entrevistas não-tendenciosas
Quem são os usuários?
Quem são os clientes?
As necessidades deles são diferentes?
Onde a solução desse problema pode ser encontrada?
Resultado: repositório de requisitos
Questionário não substitui uma entrevista.
Gerente:
Qual é sua visão do problema?
Quais são as mudanças desejadas com a solução do problema?
Em que ambiente essa solução deverá funcionar?
Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução?
Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)?
Gerente:
Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc...);
Como serão as integrações entre os sistemas?
Haverá migração de dados ? Em que estrutura estão esses dados?
Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue?
Como está estruturada a equipe de TI?
Usuário:
Qual é sua visão do problema?
Quais são as mudanças desejadas com a solução do problema?
Que facilidades você espera do sistema?
Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)?
Quais são as macro funcionalidades necessárias para os sistema?
Usuário:
Quais são as pessoas que se relacionam com o sistema?
Como são as telas imaginadas para o sistema (esboços de telas)?
Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar layout dos arquivos / fontes de dados)?
Outros
Manutenções:
Quais são as dificuldades de manutenção do sistema?
Qual é a qualidade das estruturas do banco de dados?
Qual é a qualidade do código fonte do aplicativo?
A documentação do sistema é suficiente e compreensível?
Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)?
Quais são os pontos de “gargalo” do sistema atual
Levantamento de Requisitos (Brainstorm)
É uma técnica em que as pessoas colocam tudo que vier na cabeça com relação ao projeto.
Muito útil quando existem diversos interessados no projeto.
É dividido em duas etapas.
Na primeira, anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o que importa mais é a quantidade, não deixe de anotar nada.
Na segunda etapa, debate-se com o grupo para ir refinando as idéias apresentadas anteriormente. Deixe as regras bem claras, e defina uma pessoa (facilitador) para “comandar” a reunião, para garantir que as regras sejam respeitadas.
Pode ser efetiva no desenvolvimento de um novo projeto, na fase inicial, para identificar requisitos de alto nível, aqueles mais macros.
Levantamento de Requisitos (Storyboarding)
Corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Esta técnica foi utilizada inicialmente no cinema e desenhos animados, representando um esboço dos personagens e da história.
Levantamento de Requisitos (Casos de Uso)
Descreve a funcionalidade proposta para o novo sistema.
Representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema.
É uma unidade de um trabalho significante.
Ex: o "login para o sistema", "registrar no sistema" e "criar pedidos".
Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto.
Um Caso de Uso pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.
Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.
Levantamento de Requisitos (Role Playing)
Esta técnica consiste em observar o usuário executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, você fazendo o trabalho deste usuário, para identificar suas dificuldades e necessidades, sentindo na pele como é realizar a tarefa.
Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos.
Levantamento de Requisitos (Prototipagem)
Criação, apresentação e debate de modelos de interação não funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema.
É a atividade de desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos, permitindo a descoberta de falhas difíceis de serem encontradas na comunicação verbal.
Um processo que propõe a criação de um protótipo de software objetiva apoiar a fase levantamento de requisitos a fim de prevenir as possíveis falhas no sistema.
Um protótipo simula a aparência e funcionalidade do software permitindo que os clientes, analistas, desenvolvedores e gerentes percebam os requisitos do sistema podendo interagir, avaliar, alterar e aprovar as características mais marcantes na interface e funções.
Os protótipos podem ser evolutivos ou descartáveis.
Regras de Negócio
Estabelecem requisitos gerais para o sistema, provenientes do próprio negócio como normas, políticas, legislações etc.
São declarações que restringem, derivam e fornecem condições de existência, representando o conhecimento do negócio.
Ex: Toda conta de telefone atrasada mais de n dias terá seu número bloqueado para receber chamadas.
Regras de Negócios
São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.
Descrevem a maneira pela qual a organização funciona.
Estas regras são identificadas e documentadas no chamado modelo de regras do negócio.
A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.
Alguns exemplos de regras do negócio:
O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.
Regras do negócio normalmente têm influência sobre uma ou mais funcionalidades.
Nome
Quantidade de inscrições possíveis Descrição
Um aluno não pode ser inscrever em mais de seis disciplinas por semestre letivo. Fonte
Coordenador da escola de informática Histórico
Data de identificação: 16/04/2006
Revisão - Passos de Requisitos
Levantar os requisitos do sistema através de entrevistas com representantes do usuário gestor e usuários finais, e registrá-los no Documento de Requisitos do Sistema
Atualizar o Glossário do projeto com novos termos identificados durante o levantamento de requisitos
Priorizar os requisitos levantados, em conjunto com o responsável por sua definição, como: essencial, importante ou desejado.
Classificar os requisitos levantados como: funcionais, não-funcionais ou regras de negócio.
Identificar, com base nos requisitos funcionais levantados, os usuários do sistema
Identificar os relacionamentos entre usuários e funcionalidades, representando-os através de um Diagrama de Casos de Uso inicial.
Revisar, junto aos representantes do usuário gestor e de usuários finais, o Documento de Requisitos do Sistema.
quinta-feira, 19 de novembro de 2009
[oc] tabela ASC no Assembly
.model small
.stack
.code
PRINT_ASCII PROC
MOV DL,00h ;move o valor 00h para o registrador DL
MOV CX,255 ;move o valor decimal 255 para o registrador CX
;usado para fazer um laço com 255 interações
PRINT_LOOP:
CALL WRITE_CHAR ;Chama o procedimento que imprime
INC DL ;Incrementa o valor do registrador DL
LOOP PRINT_LOOP ;Loop para imprimir 10 caracteres
MOV AH,4Ch ;Função 4Ch
INT 21h ;Interrupção 21h
PRINT_ASCII ENDP ;Finaliza o procedimento
WRITE_CHAR PROC
MOV AH,2h ;Função 2h para imprimir um caracter
INT 21h ;Imprime o caracter que está em DL
RET ;Retorna o controle ao procediemento que chamou
WRITE_CHAR ENDP ;Finaliza o procedimento
END PRINT_ASCII ;Finaliza o programa
segunda-feira, 9 de novembro de 2009
[INAP] Interdisciplinar
Informatização e Automatização da Agência de Viagens Pé no Mundo
A locadora de veículos "Roda Carro" pretende atualizar seu sistema de atendimento implantando um novo cadastro automatizado. A locadora precisa manter um cadastro de clientes com nome, RG, endereço, filiação e telefone. A locadora também mantém um cadastro de funcionários (mecânicos e atendentes) com nome, RG, telefone, matricula, data de admissão. A locadora faz empréstimos de 3 tipos de veículos: carros de passeio, utilitários e mini-vans. O cadastro dos veículos deve manter a placa do carro, nr chassi, cor, marca, modelo, e taxa de locação. O custo da locação dos carros de passeio é dado através do valor da taxa de locação do veículo adicionado a um custo por quilometro rodado. O custo da locação dos utilitários e mini-vans é dado através do valor da taxa de locação do veículo adicionado a um custo diário. Os clientes podem solicitar reserva de automóveis ou ir direto a locadora para efetuar a locação. Quando uma locação é realizada precisa-se manter o nome dos clientes, a placa do carro, a quilometragem inicial e data de retirada do veículo. Ao finalizar a entrega é informada a quilometragem atual e a data de entrega do veículo. Os clientes também podem solicitar empréstimo de veículos “in house”, ou seja, o carro é entregue no endereço que o cliente solicitar.
Para a unidade curricular de Informática Aplicada, identificar as proposições do texto e montar as operações, usando variáveis lógicas. O aluno deve projetar, caso seja necessário, os conetivos lógicos condicionais e/ou bicondicionais. Aplique as propriedades lógicas de equivalência e use a TV para provar as mesmas.
Para a unidade curricular de Informática Aplicada, identificar as proposições do texto e montar as operações, usando variáveis lógicas. O aluno deve projetar, caso seja necessário, os conetivos lógicos condicionais e/ou bicondicionais. Aplique as propriedades lógicas de equivalência e use a TV para provar as mesmas.
Forma de Entrega do Trabalho
Para a unidade curricular Informática Aplicada: Entregar neste próprio documento, a parte referente a unidade curricular.
Semana de Entrega do Trabalho
A semana de entrega do trabalho será uma semana antes da prova do 2º bimestre. Essa nota deve fazer parte da nota do 2º.bimestre.
Peso do Trabalho
1.0 sobre a nota do 2º bimestre.
[FSI] Interdisciplinar
COMPETÊNCIAS: Compreender os impactos do uso estratégico dos sistemas de informações gerenciais de apoio à tomada de decisão, sistemas integrados e varejo eletrônico. (Fundamentos de Sistema de Informação)
Escopo do Projeto
Informatização e Automatização de uma Fila de Atendimento Bancário
Escopo do Projeto
Informatização e Automatização de uma Fila de Atendimento Bancário
Uma empresa de fomento, o qual oferece os serviços de abertura de conta corrente, poupança e empréstimo bancário, possui diferentes operações a serem informatizadas e automatizadas. Para o reconhecimento dos clientes, a empresa utiliza um numero de conta corrente, bem como o nome do cliente, seus dependentes, endereço do cliente, data de nascimento, seus bens e faixa salarial. Um dos serviços que a empresa oferece é a do atendimento bancário nos seus caixas, os quais realizam as seguintes operações: saques, depósitos, investimentos, pagamentos e transferências. Para a organização do atendimento, uma única fila de clientes é formada e se oferece um total de 5 caixas de atendimento. A empresa precisa agilizar o tempo de atendimento, bem como o tempo de espera de um cliente na fila, logo realiza analises quantitativas, no decorrer do tempo de abertura da empresa, para identificar quais são os horários de maior pico, ou seja, a maior quantidade de clientes numa fila, bem como o maior tempo de espera na mesma. Para tal, são anotados o dia da semana, o horário de inicio e termino da análise, o total de clientes na fila, o tempo médio de espera e o tempo de atendimento no caixa. A empresa também precisa aumentar o seu escopo de clientes, procurando oferecer novas formas de uso de seus serviços, ou seja, agregando novos perfis de, os quais não precisam visitar a empresa. Um cliente pode ou não uma conta de investimento, mas para tal, precisa ter uma conta corrente. Um cliente pode ter ou não dependentes, os quais podem ter apenas conta corrente. Uma conta de investimento, possui um código seqüencial, além da própria conta corrente, bem como o seu saldo. Um cliente pode ser um funcionário da própria empresa de fomento, o qual é reconhecido pelo seu código interno, nome e função. Um funcionário pode ter apenas uma conta corrente.
Atividades desenvolvidas em cada Unidade Curricular
Para a unidade curricular de Fundamentos de Sistemas de Informação, realizar uma análise de quais tipos de sistemas de informações poderão ser aplicados na solução deste projeto, bem como as tecnologias as quais poderão ser aplicadas. O aluno deve projetar os processos e recursos necessários para atender o projeto de informatização e automatização, considerando o texto acima. Deve ser realizado um orçamento da implantação das tecnologias. Grupo de no máximo 2 alunos.
Peso: 2 pontos
Atividades desenvolvidas em cada Unidade Curricular
Para a unidade curricular de Fundamentos de Sistemas de Informação, realizar uma análise de quais tipos de sistemas de informações poderão ser aplicados na solução deste projeto, bem como as tecnologias as quais poderão ser aplicadas. O aluno deve projetar os processos e recursos necessários para atender o projeto de informatização e automatização, considerando o texto acima. Deve ser realizado um orçamento da implantação das tecnologias. Grupo de no máximo 2 alunos.
Peso: 2 pontos
quinta-feira, 5 de novembro de 2009
[OC] - G2 - Aula 3
Tipos de Variávies
DB define byte (8 bits)
DW define word (16 bits, 2 bytes consecutivos)
DD define doubleword (2 palavras, 4 bytes consecutivos)
DQ define quadword (4 palavras, 8 bytes consecutivos)
DT define ten bytes (10 bytes consecutivos)
Exemplos:
Alfa DB 0 ;equivale a 00h
A DB 10h
B DB 0150h ;ilegal, por que?
BIT DB ? ;não inicializada
Array: sequência de bytes ou words consecutivos na memória
• armazenar dados relacionados
• armazenar caracteres ASCII organizados (ex: texto)
Exemplos:
BYTE_ARRAY DB 10h,20h,30h
WORD_ARRAYDW 1000h,123h,0h,0FFFFh
Um array pode conter um string de caracteres, sendo definido como:
LETRAS DB ‘abC’ ;e´ equivalente aos caracteres ASCII
LETRAS DB 61h,62h,43h ;depende se maiúscula ou minúscula
Combinação de caracteres e números numa mesma definição:
MENSAGEM DB ‘Alo!’, 0Ah,0Dh,’$’
O caracter '$' marca o fim de um string de caracteres e não é exibido.
Constante é um nome simbólico para um dado de valor constante, que seja muito utilizado num programa. Para atribuir um nome a uma constante, utiliza-se a pseudo-instrução EQU (equates -> igual a) e a sintaxe:
EQU
Exemplos:
LF EQU 0Ah ;caracter Line Feed como LF
CR EQU 0Dh ;caracter Carriage return como CR
LINHA1 EQU ‘Digite seu nome completo’
MENSAGEM DB LINHA1,LF,CR
Atenção:
MOV WORD1,WORD2 ;instrução inválida
;esta restrição é contornada como segue
MOV AX,WORD2 ;primeiro o conteúdo de WORD2 p/ AX
MOV WORD1,AX ;depois, o conteúdo de AX é movido p/
;posição de memória WORD1
LEA destino,fonte
Significa Load Effective Address -> coloca uma cópia do offset do endereço
da posição de memória fonte no registrador destino.
Exemplo:
.DATA
MENSAGEM DB ‘Adoro Fusca!$’
.CODE
LEA DX,MENSAGEM ;DX carregado com o offset de MENSAGEM
Obs: após esta operação, DX conterá o offset da posição de memória onde
inicia o string MENSAGEM
Vamos a um código completinho...
.MODEL SMALL
.STACK 100H
.DATA
MENSAGEM DB 'ALO! Como voces estao indo?!$'
.CODE
MAIN PROC
;inicializando o registrador DS
MOV AX,@DATA
MOV DS,AX ;segmento de dados inicializado
;obtendo o offset da posição de memória de MENSAGEM
LEA DX,MENSAGEM ;offset do endereço vai para DX
;
;exibindo a MENSAGEM
;
MOV AH,9 ;funcao DOS para exibir 'string'
INT 21H ;exibindo
;
;retorno ao DOS
;
MOV AH,4CH ;funcao DOS para saida
INT 21H ;saindo
MAIN ENDP
END MAIN
DB define byte (8 bits)
DW define word (16 bits, 2 bytes consecutivos)
DD define doubleword (2 palavras, 4 bytes consecutivos)
DQ define quadword (4 palavras, 8 bytes consecutivos)
DT define ten bytes (10 bytes consecutivos)
Exemplos:
Alfa DB 0 ;equivale a 00h
A DB 10h
B DB 0150h ;ilegal, por que?
BIT DB ? ;não inicializada
Array: sequência de bytes ou words consecutivos na memória
• armazenar dados relacionados
• armazenar caracteres ASCII organizados (ex: texto)
Exemplos:
BYTE_ARRAY DB 10h,20h,30h
WORD_ARRAYDW 1000h,123h,0h,0FFFFh
Um array pode conter um string de caracteres, sendo definido como:
LETRAS DB ‘abC’ ;e´ equivalente aos caracteres ASCII
LETRAS DB 61h,62h,43h ;depende se maiúscula ou minúscula
Combinação de caracteres e números numa mesma definição:
MENSAGEM DB ‘Alo!’, 0Ah,0Dh,’$’
O caracter '$' marca o fim de um string de caracteres e não é exibido.
Constante é um nome simbólico para um dado de valor constante, que seja muito utilizado num programa. Para atribuir um nome a uma constante, utiliza-se a pseudo-instrução EQU (equates -> igual a) e a sintaxe:
Exemplos:
LF EQU 0Ah ;caracter Line Feed como LF
CR EQU 0Dh ;caracter Carriage return como CR
LINHA1 EQU ‘Digite seu nome completo’
MENSAGEM DB LINHA1,LF,CR
Atenção:
MOV WORD1,WORD2 ;instrução inválida
;esta restrição é contornada como segue
MOV AX,WORD2 ;primeiro o conteúdo de WORD2 p/ AX
MOV WORD1,AX ;depois, o conteúdo de AX é movido p/
;posição de memória WORD1
LEA destino,fonte
Significa Load Effective Address -> coloca uma cópia do offset do endereço
da posição de memória fonte no registrador destino.
Exemplo:
.DATA
MENSAGEM DB ‘Adoro Fusca!$’
.CODE
LEA DX,MENSAGEM ;DX carregado com o offset de MENSAGEM
Obs: após esta operação, DX conterá o offset da posição de memória onde
inicia o string MENSAGEM
Vamos a um código completinho...
.MODEL SMALL
.STACK 100H
.DATA
MENSAGEM DB 'ALO! Como voces estao indo?!$'
.CODE
MAIN PROC
;inicializando o registrador DS
MOV AX,@DATA
MOV DS,AX ;segmento de dados inicializado
;obtendo o offset da posição de memória de MENSAGEM
LEA DX,MENSAGEM ;offset do endereço vai para DX
;
;exibindo a MENSAGEM
;
MOV AH,9 ;funcao DOS para exibir 'string'
INT 21H ;exibindo
;
;retorno ao DOS
;
MOV AH,4CH ;funcao DOS para saida
INT 21H ;saindo
MAIN ENDP
END MAIN
Marcadores:
aula 3,
g2,
Organização de Computadores
Assinar:
Postagens (Atom)