segunda-feira, 28 de julho de 2014

Leia um pouco Criando minha primeira classe!

Resumo
Nesta aula vamos aprender como usar o C# para criarmos nossa primeira classe. Como criar uma instancia desta classe e usarmos em um programa.

Palavra-chave: POO, Classes, Minha primeira classe, Orientação a Objetos, C#, CSharp, Usando C#.

Nova Página
Criando minha primeira classe

O estudo da programação orientada a objeto em C# passa obrigatoriamente pela criação de sua primeira classe. Nesta webaula vamos fazer passo a passo como criar uma classe.

            Para desenvolvermos todos os nossos exercícios vamos criar aplicativos do tipo CONSOLE APPLICATION.

Vamos la!
Vamos abrir o C# e criarmos um novo projeto selecionando no menu do sistema a opção  File -> New Project..., o C# mostrará a sua biblioteca de templates de projetos, selecione a template Console Application e na parte inferior da tela de templates, ele aguarda que você digite um nome para o nosso projeto. Então no campo Name coloque o nome do projeto de WebAula1.
Se tudo deu certo, estará aparecendo na sua tela o seguinte trecho de código:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}


Muito bem, para testarmos se o nosso projeto foi criado corretamente, vamos fazer um teste:
Escreva o seguinte código que está em negrito logo após a linha static void Main(string[] args). Ficando então da seguinte forma:

static void Main(string[] args)
{
   Console.WriteLine("Ola Mundo");
   Console.Write("Pressione uma tecla para continuar");
   Console.ReadKey(); 
}
Agora pressione a tecla F5 para executar a aplicação. Será mostrada a seguinte tela:

Figura 1
Ok!!!
Bom Isso foi só para aquecer, vamos agora criar a nossa classe.


Nova Página
Conforme a figura abaixo, na janela Solution Explorer clique com o botão direito sobre o nome do projeto que criamos; WebAula1 depois selecione Add Class...   
Figura 2

Novamente o C# mostrará a janela que disponibiliza as templates do projeto. Como você pode ver a template Classjá está selecionada, então vamos dar um nome para a nossa classe substituindo o nome default (Class1.cs) que o C# sugere, digitando o nome Pessoa no campo Name na parte inferior da tela das templates e clique no botão Add.

Temos agora em nosso projeto uma arquivo chamado Pessoa.cs como está sendo mostrado na janela do Solution Explorer.

A primeira coisa que vamos fazer é renomear a nossa classe, para _Pessoa, isso mesmo coloque um tacinho (underline) no começo do nome. Isso será um padrão que vamos assumir em todas a classes que criarmos, vocês vão entender mais a frente a razão disto.
Agora vamos criar os atributos private da nossa classe. Entre as chaves do corpo da nossa classe vamos começar a codificar isto.

namespace WebAula1
{
    class Pessoa
    {
        private DateTime dataCadastro;
       private int      codigo;
      private string   nome;
       private string   cpf;
       private string   endereco;
       private string   cidade;
       private string   uf;
       private string   cep;
    }
}

Nova Página

Veja criamos somente atributos private isso quer dizer que estes atributos não estarão disponíveis fora desta classe. Para que possamos usar esta classe e gravar valores nos atributos, precisamos publica-los ou seja criarmos propriedades publicas que permitam o acesso a estes atributos. Vamos fazer isto agora.

public DateTime DataCadastro
       {
           get { return dataCadastro; }
           set { dataCadastro = value; }
        }

        public int Codigo
        {
           get { return codigo; }
           set { codigo = value; }
        }

        public string Nome
        {
           get { return nome; }
           set { nome = value; }
        }

        public string Cpf
        {
           get { return cpf; }
           set { cpf = value; }
        }

        public string Endereco
        {
           get { return endereco; }
           set { endereco = value; }
        }

        public string Cidade
        {
           get { return cidade; }
           set { cidade = value; }
        }

        public string Uf
        {
           get { return uf; }
           set { uf = value; }
        }

        public string Cep
        {
           get { return cep; }
           set { cep = value; }
        }

Com isto já podemos usar nossa classe. Vamos ver como isso pode ser feito.

Nova Página

Selecione o arquivo Programa.cs dando um duplo click no seu nome no Solution Explorer ou selecione na aba dos de arquivos:
Figura 3

Apague as trez linhas que fizemos no começo da aula e vamos escrever o seguinte código para instanciar nossa classe:

namespace WebAula1
{
    class Program
    {
        static void Main(string[] args)
        {
            Pessoa pessoa = new Pessoa();
        }
    }
}

A linha em negrito esta criando um objeto do tipo Pessoa.
Bom vamos seguir com o nosso código, depois de criar o objeto vamos usa-lo,  para isso vamos escrever um código que pergunte na tela os dados para preencher os campos da nossa classe, veja como ficaria:

Nova Página

namespace WebAula1
{
    class Program
    {
        static void Main(string[] args)
        {
            Pessoa pessoa = new Pessoa();

            Console.Write("Digite o código.....:");
            // Veja que nesta linha precisamos fazer a conversão
            // do valor digtado pelo usuário pois toda entrada via console
            // é do tipo texto e o nosso código e int, por isso devemos
            // fazer a conversão utilizando o metodo ToInt32 da classe
           // Convert.
            pessoa.Codigo = Convert.ToInt32(Console.ReadLine());

            Console.Write("Digite o nome.......:");
            pessoa.Nome = Console.ReadLine();

            Console.Write("Digite o cpf........:");
            pessoa.Cpf = Console.ReadLine();

            Console.Write("Digite o endereço...:");
            pessoa.Endereco = Console.ReadLine();

            Console.Write("Digite a cidade.....:");
            pessoa.Cidade = Console.ReadLine();

            Console.Write("Digite o estado.....:");
            pessoa.Uf = Console.ReadLine();

            Console.Write("Digite o cep........:");
            pessoa.Cep = Console.ReadLine();
            Console.WriteLine("=========================================");
            Console.WriteLine("   Mostrando o conteúdo da classe Pessoa");
            Console.WriteLine("=========================================");

            Console.WriteLine("Codigo.......: {0}", pessoa.Codigo);
            Console.WriteLine("Nome.........: {0}", pessoa.Nome);
            Console.WriteLine("Cpf..........: {0}", pessoa.Cpf);
            Console.WriteLine("Edereço......: {0}", pessoa.Endereco);
            Console.WriteLine("Cidade.......: {0}", pessoa.Cidade);
            Console.WriteLine("Estado.......: {0}", pessoa.Uf);
            Console.WriteLine("Cep..........: {0}", pessoa.Cep);

            Console.ReadKey();


        }
    }
}

segunda-feira, 21 de julho de 2014

Leia um pouco sobre Recuperação e atomicidade de Transações!



Recuperação e Atomicidade de transações
Um banco de dados controla todas as ações feitas em seus dados como uma transação de banco de dados. Acontece que estas transações podem ter problemas em seu processamento e como é que o SGBD vai garantir que as transações já realizadas não sejam perdidas em caso de problemas. Explicar o que acontece e como sair desta situação é o nosso objetivo.
E sempre que acontece uma situação destas, dados podem ser perdidos e uma das principais funções de um banco de dados é garantir a recuperação causada por uma falha e restaurar a consistência e integridade do banco de dados.



Atomicidade
Como já foi visto, representa a indivisibilidade de uma transação.

Classificação de falhas
As falhas podem ser classificadas em duas modalidades:
  •          Falhas com perdas de informação.
  •          Falhas sem perda de informação.
Para que o sistema possa propor algoritmos que assegurem a consistência, integridade e atomicidade após cada falha, precisaram primeiro identificar os tipos de falhas possíveis e dividir o procedimento de recuperação em duas partes.
  •          Ações a serem tomadas durante o processamento normal da transação com o objetivo de assegurar que tenhamos informações suficientes para a recuperação em caso de falha.
  •          Ações a serem tomadas após a falha para assegurar a consistência do banco de dados e a atomicidade da transação.



Modelo de transação
Se estiver consistente quando uma transação iniciou, o banco de dados precisa ser consistente quando a transação terminar com sucesso.
Entretanto, durante a execução de uma transação, pode ser necessário temporariamente permitir esta inconsistência.

Consistência e Atomicidade
Cada transação precisa ser um programa que preserve a consistência do banco de dados. Todas as operações associadas a uma transação precisam ser executadas até o final, ou nenhuma deve ser executada.
Uma transação nem sempre pode completar sua execução com sucesso, quando isto acontece dizemos que ela foi abortada.
A fim de garantir a atomicidade, uma transação abortada não pode ter efeito no estado do banco de dados.
Assim o banco de dados precisa ser restaurado ao estado anterior ao início da transação que foi abortada. Este procedimento de desfazer o que foi iniciado recebe o nome de rollback.
Uma transação completada com sucesso é chamada de compromissada ou comitada (commited).

Estado de transação
Uma transação possui o seguinte modelo abstrato:
  •          Ativo – o estado inicial.
  •          Parcialmente compromissado – depois que a última instrução foi executada.
  •          Falhado – depois da descoberta de que uma execução normal não pode mais prosseguir.
  •          Abortado – depois que a transação foi desfeita e o banco de dados foi restaurado ao seu estado anterior ao início da transação.
  •          Compromissado – depois de a transação ser completada com sucesso.



Uma transação entra no estado falhado depois de ser determinado que a transação não possa mais prosseguir com sua execução normal, então ela precisa ser desfeita, a transação entra no estado abortado, nesse ponto o sistema tem duas opções:
  •          Reiniciar a transação – uma transação reiniciada é considerada uma nova transação. Apenas quando houve um erro de hardware ou software operacional (não de lógica).
  •          Matar a transação – ocorre quando o erro foi de lógica interna, necessitando rever a programação do programa.

Recuperação baseada em Log
A fim de garantir a atomicidade, o sistema de banco de dados, armazena um espelho da transação que será realizada, descrevendo as modificações envolvidas. Este modelo é chamado de log do banco de dados.



Leia um pouco sobre Controle de concorrência de banco de dados!

Controle de concorrência de banco de dados



Controle de concorrência
Um SGBD trabalha individualmente com uma transação muito bem, mas o grande desafio para a sua consagração no mercado é sem dúvida a sua capacidade de tratar diversas transações simultaneamente.
Hoje em dia é muito comum e fácil o acesso a computadores com vários processadores ou então com processadores com vários núcleos, a esta característica chamamos de multiprocessador.
Existe também o multiprocessamento, que é a capacidade do sistema operacional executar mais de um programa ao mesmo tempo.
Isto pode ocorrer com um computador com um único processador, neste caso o processador acaba realizando o processamento em paralelo de diversos programas ao simultaneamente.
Se colocarmos mais processadores, ele vai distribuir as tarefas passando rotinas de processamento para cada processador, de modo independente.
E se apenas um programa estiver sendo executado, apenas um processador é utilizado, os demais ficam ociosos.
Mas existem sistemas operacionais mais inteligentes, que aproveitam a capacidade de multiprocessadores dos computadores e realizam uma melhor distribuição de carga de processamento.
Se apenas um programa estiver executando no servidor, o sistema operacional divide as tarefas deste programa entre os diversos processadores do servidor, otimizando assim a carga sobre um único processador e distribuindo entre os vários processadores, acelerando em muito a conclusão do processo.
Este tipo de sistema operacional é conhecido como multiprocessamento simétrico ou SMP, onde é realizado o balanceamento de carga.
O SGBD trabalha em conjunto com o sistema operacional para retirar a melhor performance possível na execução de transações concorrentes, garantindo inclusive a efetiva consistência de todas as transações envolvidas.
Um bom SGBD deve suportar e transacionar desde poucas transações ao mesmo tempo até dezenas e centenas de transações simultaneamente.
A sua capacidade de resolver os problemas que possam ocorrer durante as transações e a integridade que o mesmo garante, fazem com que o SGBD seja confiável.



Escalonamento (schedules)
Quando diversas transações são executadas concorrentemente, a consistência do banco de dados pode ser destruída apesar de cada transação individual estar correta.
Podemos afirmar que o escalonamento representa a ordem cronológica da execução de cada instrução no banco de dados.
Uma transação de um programa deve sair de um estado consistente e levar o banco de dados para outro estado consistente também.
Surge então o conceito de seriabilidade, ou seja, o escalonamento das execuções.

Escalonamento serial
Um escalonamento serial consiste de uma seqüência de instruções de várias transações na qual as instruções pertencentes a uma única transação aparecem juntas naquele escalonamento.
A ordem das transações afeta diretamente o resultado final.

Escalonamento não serial
Um escalonamento não serial consiste de uma seqüência de instruções de várias transações intercaladas entre si, o que pode provocar temporariamente um estado inconsistente.
Podemos concluir que o escalonamento não serial pode comprometer a consistência do banco de dados e causar transtornos enormes.

Por uma questão óbvia o escalonamento não serial não é permitido nos SGBDs comerciais mais famosos.

Protocolo baseado em bloqueios
Um modo de assegurar a seriabilidade é requerer que o acesso aos itens de dados seja feito de uma maneira mutuamente exclusiva, isto é, enquanto uma transação faz o acesso a um item de dado, nenhuma outra transação pode modificar aquele item.
O método mais fácil de garantir isto, é fazer com que uma transação ao acessar um dado, mantenha um bloqueio neste dado até o término da sua transação.

Formas de bloqueio
Bloqueio partilhado – se uma transação T obteve um bloqueio (lock) no modo partilhado (representado por P) no item de dado A, então T pode ler este item A mas não pode gravar A.
Bloqueio exclusivo – se uma transação T obteve um bloqueio (lock) no modo exclusivo (representado por X) no item de dado A, então T pode ler este item A e somente T poderá gravar A.
Bloqueio de duas fases – nesta forma de bloqueio, o protocolo divide-se em:
  • Fase de crescimento – uma transação pode obter bloqueios, mas não pode liberar nenhum dos bloqueios feitos.
  • Fase de encolhimento – uma transação libera um dos bloqueios, mas não pode obter nenhum outro bloqueio até concluir a transação atual.
Inicialmente, uma transação está na fase de crescimento, obtendo quanto bloqueios forem necessários para a sua transação. Uma vez que libere um bloqueio, a transação entrará na fase de encolhimento e não pode mais bloquear nenhum outro dado, até que a transação atual termine. Só então ela poderá começar outra transação com novos bloqueios.
Bloqueio baseado em grafos – nesta técnica, o modelo mais simples requer que tenhamos o conhecimento anterior da ordem na qual os itens do banco de dados serão utilizados, a única instrução permitida é o lock-x (modo exclusivo).
Os bloqueios são realizados utilizando a árvore de acesso aos dados. Muitos dados desnecessários são bloqueados e pode comprometer outras transações.
É um protocolo livre de deadlock, porém bloqueia muitos dados desnecessários para a transação.
Bloqueio baseado em marcador de tempo – o método mais comum para fazer isso é utilizar o esquema de ordenação por marcadores de tempo, criando duas variáveis w-timestamp(A) e r-timestamp (A).
Estas variáveis contêm os marcadores de tempo lógico do sistema para identificar nas transações quem chegou primeiro e quem chegou depois no dado.
Os marcadores de tempo são atualizados toda vez que uma instrução read ou write for executada.



Leia um pouco sobre Transação de um banco de dados!

Conceito de Transação



Transação de um banco de dados
Como já sabemos, um banco de dados é composto de tabelas que estão inter-relacionadas umas com as outras.
As ações ou movimentações que são realizadas no banco de dados, consistem basicamente em gravar novos dados, consultar dados gravados existentes, modificar dados previamente gravados existentes e remover dados previamente gravados existentes.
Então podemos definir que existem 4 tipos de operações:
- gravar dados, que vamos tratar de agora em diante como ‘inserir dados’.
- consultar dados, que vamos continuar como está.
- modificar dados, que vamos tratar de agora em diante como ‘atualizar dados’.
- remover dados, que vamos tratar de agora em diante como ‘deletar dados’.
Destas operações, podemos afirmar que:
- a operação consultar dados não provoca modificações nos dados armazenados no banco de dados.
- as operações inserir dados, atualizar dados, deletar dados provocam alterações nos dados armazenados.
Um banco de dados deve sempre manter a sua integridade e consistência nos dados armazenados, para garantir que as regras de negócio estabelecidas estejam sendo cumpridas.
Porém sempre que uma das três operações que provocam alterações nos dados armazenados (inserir dados, atualizar dados e deletar dados) são executados, dizemos que o banco de dados realizou uma transação.

Para iniciar uma transação, o banco de dados recebe um aviso de início de transação que chamaremos de ‘início de transação’ ou ‘begin transaction’.
Ao final da transação, o banco de dados recebe outro aviso, agora indicando o encerramento da transação que chamaremos de ‘fim de transação’ ou ‘end transaction’.
Quanto mais operações colocarmos dentro de uma única transação, mais demorado e crítica torna-se esta transação, porém o tamanho de uma transação dependerá muito da ‘regra de negócio a ser cumprida’.


Propriedades ACID
Todo Sistema Gerenciador de Bando de Dados (SGBD) aplica em seu funcionamento o conceito denominado ACID, que representa a inicial de quatro propriedades fundamentais.
  • Atomicidade
  • Consistência
  • Integridade
  • Durabilidade
Um SGBD não pode aplicar apenas algumas destas propriedades, todas as propriedades devem ser cumpridas, senão não podemos considerar um SGBD de verdade.

Atomicidade
Dizemos que uma transação é atômica, pois a transação não é divisível em partes, ou seja, a transação deve ser realizada por inteiro ou ela não pode ser realizada.
Lembramos que uma transação pode ter várias operações de alteração de dados, então ou cumprimos todas elas ou não realizamos nenhuma delas.

Consistência
Uma transação quando começa, os dados armazenados estão todos consistentes, ao concluir a transação os dados devem estar consistentes novamente, ou seja, as regras de negócio devem continuar sendo executadas e cumpridas.

Integridade
Uma transação deve ser íntegra, ou seja, as regras de negócio devem ser cumpridas durante a realização das operações na transação independentemente de existirem mais transações simultaneamente e ao final delas, esta integridade deve permanecer.

Durabilidade
Uma transação depois que for realizada e confirmada deve obrigatoriamente ser durável, ou seja, não pode desaparecer do banco de dados sem que outra transação realize esta operação.

Confirmação ou não de uma transação
Quando terminamos uma transação, necessitamos confirmar ou não a realização desta transação.
A confirmação desta transação é realizada com a execução de um comando de confirmação ou ‘COMMIT’.
Ou então devemos descartar a transação, através do comando ‘ROLLBACK’. Este comando desfaz as operações que estavam sendo realizadas até o início da transação, levando a um ponto onde as quatro propriedades ainda permanecem garantindo os dados do banco de dados.

DeadLock
Abraço mortal é uma situação onde duas transações T1 e T2, cada uma bloqueou inicialmente A e B respectivamente, e para concluírem suas transações agora necessitam de B e A respectivamente.
Porém nenhuma das duas transações abre mão dos seus dados previamente bloqueados.

domingo, 13 de julho de 2014

Leia um pouco sobre Gerenciamento de Requisitos!

Gerenciamento de Requisitos

     O gerenciamento de requisitos é o processo de controlar as mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento. Torna-se necessário manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes de modo que possa avaliar os impactos das mudanças de requisitos. 
Considerando que os requisitos são inevitavelmente incompletos e inconsistentes, novos requisitos surgem durante o processo de desenvolvimento e os diferentes pontos de vista que esses requisitos possuem frequentemente são contraditórios. 
Existem várias razões pelas quais as mudanças são inevitáveis dentre as quais destaca-se:
  • A prioridade dos requisitos de diferentes pontos de vista se modifica;
  • As pessoas que pagam pelo sistema podem especificar os requisitos de maneira conflitantes com os requisitos das pessoas que irão utilizar o sistema;
  • A empresa e o ambiente técnico do sistema se modificam durante o seu desenvolvimento. 

Evolução dos requisitos
Do ponto de vista da evolução, os requisitos dividem-se em duas classes: 
  1. Requisitos permanentes
São requisitos estáveis, derivados da atividade principal da organização. Ex. Em um hospital sempre haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras a aos tratamentos.
  1. Requisitos voláteis
São requisitos que se modificam durante o desenvolvimento ou quando o sistema está em uso. Requisitos resultantes de políticas governamentais. Ex: planos de assistência médica.
Os requisitos voláteis podem ser classificados em:
a) Requisitos mutáveis - Requisitos que se modificam por causa do ambiente do sistema que está operando. 
b) Requisitos emergentes - Requisitos que surgem à medida que a compreensão do sistema pelo cliente progride durante o desenvolvimento do sistema. 
c) Requisitos consequentes - Requisitos que resultam da introdução do sistema de computador, onde pode criar novas formas de trabalho que geram novos requisitos de sistema.
d) Requisitos de compatibilidade - Requisitos que dependem de outros sistemas ou processos de negócio específicos dentro da organização.

Gerenciamento de mudanças de requisitos
A figura abaixo mostra o processo de gerenciamento de requisitos, o qual deve ser aplicado a todas as mudanças propostas aos requisitos. A vantagem de usar um método formal  para gerenciar mudanças está no fato de que as propostas são tratadas consistentemente e a documentação dos requisitos é feita de maneira controlada.
Figura 1– Gerenciamento de Mudança de Requisitos


Fonte:Sommerville (2011, p. 79)
 Existem três estágios no processo de gerenciamento de mudanças que são: 
  • Análise do problema e especificação da mudança.
    Discute-se os problemas com os requisitos e propõe-se mudanças. 
  • Análise e custo da mudança.
    Avalia-se os efeitos da mudança em outros requisitos do sistema. 
  • Implementação das mudanças.
    O documento de requisitos e outros documentos são alterados de forma a refletir as mudanças.

Técnicas de Requisitos 
A seguir apresentaremos algumas técnicas para Elicitação ( levantamento)  e análise de requisitos: 
  • Levantamento baseado em pontos de vista;
  • Entrevistas;
  • Cenários de utilização do sistema;
  • Etnografia (análise do ambiente de trabalho dos usuários).

1. Levantamento baseado em pontos de vista 
As abordagens baseadas em pontos de vista tem como ponto forte o reconhecimento de várias perspectivas, fornecendo um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholder. Lembra o que era Stakeholder, certo? 
Sistemas médios e grandes possuem diferentes tipos de usuários finais: 
  • Pessoas envolvidas com o sistema possuem diferentes interesses e pontos de vista a respeito do sistema;
  • A análise desta multi-perspectiva é importante para descobrir e esclarecer os requisitos conflitantes, propostos por diferentes usuários.
2. Entrevistas 
Fazem parte da maioria dos processos de engenharia de requisitos. Nestas entrevistas a equipe de engenheiros formula questões para os stakeholders sobre o sistema a ser desenvolvido. 
As entrevistas podem ser abertas, em que o stakeholder responde um conjunto de perguntas predefinidas oufechadas, nas quais não há um roteiro definido, onde o engenheiro explora vários assuntos com os stakeholders no sistema, desenvolvendo assim uma maior compreensão das necessidades dos mesmos.
As entrevistas são úteis para obter um entendimento geral sobre o que os stakeholders fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam com o sistema atual, porém não são eficientes para elicitação de conhecimento sobre os requisitos e suas restrições.
 
3. Cenários de utilização do sistema
Geralmente, as pessoas consideram mais simples relatar exemplos da vida real que abstrair descrições, desta forma os cenários podem ser descritos e criticados por eles como uma forma de interação com o sistema de software.

Os cenários são úteis para adicionar detalhes a um esboço da descrição de requisitos, onde cada cenário abrange uma ou mais interações possíveis. Assim sendo, diversos cenários foram desenvolvidos, cada um dos quais fornecendo diferentes tipos de informações sobre o sistema em diversos níveis de detalhamento.  
Descrições de cenários incluem: 
  • Estado do sistema no início do cenário;
  • Fluxo normal de eventos no cenário;
  • O que pode sair errado e como lidar com isso;
  • Outras atividades concorrentes;
  • Estado do sistema no final do cenário.
4. Etnografia (análise do ambiente de trabalho dos usuários) 
É uma técnica de observação que pode ser usada na compreensão dos requisitos sociais e organizacionais, na qual um analista se insere no ambiente de trabalho onde o sistema será usado, observa  o trabalho do dia-a-dia e anota as tarefas reais nas quais os participantes estão envolvidos.
Denota-se o valor desta técnica na ajuda prestada aos analistas para descobrir os requisitos implícitos de sistemas que refletem os processos reais, e não os formais no qual as pessoas estão envolvidas. 
A etnografia é particularmente eficaz para descobrir: 
  •          Requisitos derivados da maneira como as pessoas realmente trabalham ao invés da maneira pela qual as definições de processo dizem o que deveria fazer.
  •          Requisitos derivados da cooperação e do conhecimento das atividades de outras pessoas. 
A etnografia pode e dever ser combinada com a prototipação, pois informa o desenvolvimento do protótipo de tal forma que poucos ciclos de refinamento sejam necessários. 
Uma vantagem da etnografia é que ela pode revelar detalhes importantes do processo, que frequentemente são ignorados por outras técnicas, porém não é apropriada para obter os requisitos organizacionais e de domínio. Assim sendo, a etnografia não é uma abordagem completa para a elicitação de requisitos, então devendo ser usada como complemento de outra abordagens como, por exemplo, a de cenários. 
Os membros da equipe técnica trabalham com o cliente e os usuários para descobrir mais informações sobre o domínio da aplicação, serviços do novo sistema, desempenho e as restrições operacionais. 

Leia mais um pouco sobre Requisitos Funcionais!

:: Requisitos Funcionais:: 
 São declarações de serviços que o sistema DEVE fornecer, como o mesmo deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações, sendo que em muitas vezes também podem explicar como o sistema DEVE ou não fazer.
 Exemplo:  
  •  o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal.
  • o software deve emitir relatórios de compras a cada quinze dias.
  • os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.  
 I. Especificação dos Requisitos Funcionais utilizando Casos de Uso 
Para realizarmos a especificação desses requisitos podemos criar nossos próprios templates, nossas próprias regras ou podemos contar com os vários templates existente no mercado ou podemos contar com o apoio dosCasos de Uso e sua especificação, que segundo Sommerville (2011), são técnicas de descoberta de requisitos introduzida inicialmente no método Objectory (Jacobson et al., 1993), que se tornaram uma característica fundamental da linguagem de modelagem unificada (UML – do inglês Unified modeling language).   
Os casos de uso são documentos utilizados pelos Diagramas de Caso de Uso da UML e representarão as funcionalidades do sistema. 

Pense no seguinte cenário:

  
 O dono do salão de beleza “Glamour” solicitou um Sistema de Cabeleireiro para sua empresa de desenvolvimento “AllDesenvol”, mas inicialmente ele quer apenas poder controlar o cadastro dos seus clientesserviços fornecidos e os produtos que o futuramente começará a vender e os profissionais que realizarão os serviços. E disse também que quem manipulará essas informações no sistema é a secretária, ou seja, para cada uma das funcionalidades acima ela realizará o CRUD (ver definição). 
  Vamos verificar como modelar isso utilizando o diagrama de caso de uso na Figura 1 abaixo?  
 Figura 1 - Diagrama de Caso de Uso 


 Fonte: Autor
 Vamos entender o Diagrama:  
  •  A secretária, representada por um homem palito, é o Ator do sistema, ou seja, o responsável pela a interação com o sistema. Mas, um ator pode ser uma pessoa (papéis) ou outros sistemas.
  •  E os casos de uso, “Controlar Cliente”, “Controlar Produto”,, “Controlar Serviço” e “Manter Profissionais” estão representados por uma elipse, sendo essas as funcionalidades do sistema, ou seja, aquilo que o sistema DEVE fazer. 
 E para especificação desses requisitos podemos utilizar um template, chamado “Especificação de Requisitos de Software” clique aqui para visualizar. Este template é fornecido pelo RUP (Processo Unificado da Rational). 
 O RUP é baseado nos conceitos da UML (saiba mais no Aprofundando Conhecimento), foi desenvolvido nos laboratórios da Rational e posteriormente a Rational foi adquirida pela IBM.  
Quando nos referimos a este documento como um template é porque o usuário terá a opção de acrescentar ou retirar informações. Veja um novo exemplo de especificação criado a partir do modelo do RUP, clique aqui
 Nota: Criamos um documento de especificação para cada Caso de Uso aqui representado, neste nosso exemplo teríamos que criar 4 documentos.  
Links importantes:

  :: Requisitos não-funcionais ::
 São restrições aos serviços ou funções oferecidas pelo sistema, que incluem restrições de tempo, no processo de desenvolvimento e também restrições impostas por normas/leis. Os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo. 
São exemplos de requisitos não-funcionais:  
  • a base de dados deve ser protegida para acesso apenas de usuários autorizados.
  • o tempo de resposta do sistema não deve ultrapassar 30 segundos.
  • o software deve ser operacionalizado no sistema Linux.
  • o tempo de desenvolvimento não deve ultrapassar seis meses. 
II. Validação de requisitos
              É o processo pelo qual se verifica se os requisitos elicitados definem o sistema que o cliente realmente quer. A validação também é importante, uma vez que o custo para remover erros de requisitos é grande, quando descobertos tardiamente. 
Durante o processo de validação de requisitos, diferentes tipos de verificação devem ser efetuados com os requisitos no documento de requisitos. Essas verificações incluem: 
  1.     Validade - O sistema fornece as funções que melhor atendem as necessidades de todos os usuários?
  2.     Consistência - Existem conflitos de requisitos?
  3.     Completeza - Todas as funções necessárias foram incluídas?
  4.     Realismo - Os requisitos podem ser implementados com a tecnologia e orçamento disponíveis?
  5.     Verificabilidade - Os requisitos podem ser checados?  
Uma série de técnicas de validação podem ser usadas individualmente ou em conjunto, tais como:   
  1.     Revisões de requisitos - é feita uma análise manual sistemática dos requisitos;
  2.     Prototipação - um modelo executável do sistema é demonstrado para os usuários finais para checar os requisitos;
  3.     Geração de casos de teste - os requisitos devem ser testáveis, para tal deve- se desenvolver testes para os requisitos a fim de verificar a testabilidade.  
Aprofundando ConhecimentoAPROFUNDANDO CONHECIMENTO
Na década de 90, Booch, Rumbaugh e Jacobson, conhecido como os 3 amigos, motivaram para criar uma linguagem de modelagem unificada, unindo as melhores características dos métodos citados e criaram a UML, no laboratório da Ratinal, conforme dito acima. Veja o experimento.
Mas afinal o que é a UML?
É uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software (BOOCH, 2000). Segundo Bezerra (2007) é uma linguagem visual para modelar sistemas orientados a objetos. Independente tanto de linguagem de programação quanto de processo de desenvolvimento de SW. 
A UML possui 13 diagramas para apoiar no Processo de Desenvolvimento de Software, sendo estes divididos em Estruturais e Comportamentais. Saiba mais
 E que é a Orientação a Objetos?
Segundo Rumbaugh (1996) orientação a objeto trata-se de uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real, sendo o principal componente o objeto, que combina dados e comportamento.
 Histórico da linguagens orientadas a objetos:
  • 1966 – SIMULA (Kristen Nogaard, Noruega);
  • 1980 – SMALLTALK (Xerox);
  • 1986 – C++  (AT&T), SMALLTALK V , OBJECTIVE-C;
  • 1988 – EIFFEL (Meyer, França);
  • 1989 – Turbo Pascal 5.5 (Borland);
  • 1995 – JAVA;

Características da OO:
  • Reusabilidade: Reutilização de componentes de software e diminuição do tempo de desenvolvimento.
  • Manutebilidade: Mudanças bem localizadas, não acarretando propagações descontroladas.
  • Confiabilidade: O encapsulamento permite um maior controle e segurança às classes dos objetos.
  • Extensibilidade: Extensibilidade é a medida da facilidade em se adicionar novas funcionalidades (operações) a um componente de uma modelagem existente.

    Saiba mais>>