Tags: , , | Categories: Fundamentos da Ciência da Computação, Math Posted by Rafael on 11/12/2012 20:29 | Comentários (0)

Retomando as atividades no blog, começo com um post bem descontraído. 

Considerando a expressão do título, 3 + 1 = 10, como você reage? O que você acha do resultado? Está correto ou errado? A resposta é: depende da base.

O que isso siginifica? Bem, vamos começar do começo. Quando aprendemos a contar números e a somá-los, aprendemos que temos 10 algarismos diferentes, são eles: 0, 1, 2, 3, 4, 5, 6, 7, 8 e 9, correto? Logo, se somarmos 1 + 1 o resultado é 2. Ótimo!

Numa definição mais vertical, o conjunto de algarismos 0, 1, 2, 3, 4, 5, 6, 7, 8 e 9 compõem uma base matemática decimal. Por quê? Porque temos 10 números (ou algarismos ou caracteres) diferentes.

Mecanicamente, a soma funciona como um odômetro (ou hodômetro, como quiser) veicular, como o objeto a seguir:

Aprendemos que, depois do número 9, vem o número 10, porque na base decimal temos apenas 10 algarismos diferentes. Vamos imaginar que o odômetro abaixo rodará 21 km. Consideremos que se trata de um carro zero, ou seja, o odômetro está zerado, assim:

Ao começar a viagem, logo o primeiro quilômetro é atingido e o odômetro o marca...

Por quê se vai de 0 (zero) para 1 (um)? Porque, na base decimal, o algarismo 1 (um) vem logo a seguir do algarismo (ou dígito) 0 (zero). Isto posto, vamos continuar nossa viagem... O segundo quilômetro chega...

O terceiro...

O quarto...

O quinto...

O sexto...

O sétimo...

O oitavo...

O nono...

Opa!!! E agora?!?! Não existe, na base 10 (ou decimal) algarismo depois do número 9!!! O que fazemos??? Simples! Incrementamos o próximo contador à esquerta e voltamos o contador atual para 0 (zero). Essa operação resulta no próximo número depois do 9, na base decimal, que é 10!

Simples, não?!

Continuando nossa viagem... Vem o décimo primeiro quilômetro...

O décimo segundo...

O décimo terceiro...

O décimo quarto...

O décimo quinto...

O décimo sexto...

O décimo sétimo...

O décimo oitavo...

O décimo nono...

Como não há algarismo (ou dígito) após o 9 (nove), na base 10, incrementamos o algarismo da esquerda e zeramos o atual. Assim, temos o 20 (vinte)...

O vigésimo primeiro e assim por diante...

Legal! Como já sabemos (mais do que "de cor e salteado", rs) como funciona o incremento de sequencias numéricas na base 10 (ou decimal), vamos deixar a brincadeira mais divertida! Vamos pensar numa base com apenas 2 (dois) algarismos (ou dígitos): a base binária, que por sua vez, possui apenas dois algarismos (ou dígitos), o 0 (zero) e o 1 (um).

Sabemos que o mecanismo de incrementação é o mesmo. Então, se zerarmos o odômetro, temos:

Incrementando, temos o primeiro quiilômetro...

Agora, para o segundo, como a nossa base é binária, incrementamos o algarismo (ou dígito) da esquerda e zeramos o atual, seguinte o mesmo mecanismo aplicado antes...

Uau! 10?! Sim! O número 10 na base binária é o mesmo que 2 na base decimal! Impressionante, não?! Vamos continuar? Se incrementarmos a seqüência, sempre utilizando o mesmo mecanismo, temos o terceiro quilômetro, que representa o número 3 na base decimal...

Continuando, temos o quarto quilômetro na base binária...

100 na base binária é o mesmo que 4 na base decimal! Bacana, não?! Bom, agora vamos fazer mais um ensaio. Consideremos uma base formada por 4 algarismos (0, 1, 2 e 3), ok? Vamos incrementar a seqüência a partir do 0 (zero) até chegarmos na equação do início desse texto? Legal, vamos lá! Vamos zerar o nosso odômetro:

Incrementando (ou somando) sempre uma unidade, temos...

Incrementando mais uma unidade, temos...

Mais uma vez, temos...

Legal! Chegamos onde queríamos! Temos registrado em nosso odômetro o número 3 (três), correto? Como estamos trabalhando na base 4 (quatro) ou quartenária, como quiser, temos como opções apenas os números 0, 1, 2 e 3. Aplicando o mesmo algoritmo de incrementação, temos...

Agora, a expressão do início do post faz sentido, não? 3 + 1 = 10? Depende da base! Se for na base quartenária (ou base 4) sim, 3 + 1 = 10!

Era isso!

 

Tags: , | Posted by Rafael on 30/06/2011 01:45 | Comentários (2)

Olá pessoal!

Hoje gostaria de compartilhar com vocês, através de um rápido post, como definir qual versão do Microsoft Visual Studio será invocada através do atalho Menu Iniciar >> Executar >> devenv.

Muitos que desenvolvem utilizando o Microsoft Visual Studio, têm mais de uma versão da IDE instalada na máquina, por quaisquer motivos. E, a cada instalação do Microsoft Visual Studio, ao invocarmos o executável devenv através do prompt de comando do Windows, a última instalação do Microsoft Visual Studio efetuada é invocada.

Mas, afinal de contas, porque isso acontece? Não deveria invocar a versão mais atual? Não. Durante a instalação do Microsoft Visual Studio, o registro devenv.exe é atualizado com a versão da instalação. Ou seja, se você utiliza o Microsoft Visual Studio 2010 para desenvolver suas aplicação, e por algum motivo - necessidade de manutenção num projeto antigo, por exemplo, precisar instalar o Microsoft Visual Studio 2005, toda vez que você invocar o executável devenv.exe, o Microsoft Visual Studio 2005 será invocado, ao invés do Microsoft Visual Studio 2010.

Para alterar a versão padrão do Microsoft Visual Studio, acesse o Registro do Microsoft Windows - Menu Iniciar >> Executar >> regedit. Acesse o registro Computador >> HKEY_LOCAL_MACHINE >> SOFTWARE >> Microsoft >> Windows >> CurrentVersion >> App Paths >> devenv.exe, edite o registro "(Padrão)". Se você instalou o Microsoft Visual Studio 2008 por último, por exemplo, o registro deve estar da seguinte maneira:

 

  • C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe

 

Para invocar o Microsoft Visual Studio 2010 ao invés do Microsoft Visual Studio 2008, altere a versão do Microsoft Visual Studio de 9.0 para 10.0. O registro ficará assim:

 

  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

 

Clique em Ok, e encerre o Editor de Registros do Microsoft Windows.

Pronto!

Agora ao executar devenv através do prompt de comando do Microsoft Windows, o Visual Studio 2010 será invocado, ao invés do Microsoft Visual Studio 2008. O mesmo vale para o Microsoft Visual Studio 2005. Para que o Microsoft Visual Studio 2005 seja invocado, basta alterar a versão no registro para 8.0.

É isso! 

Até a próxima!

Tags: , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 15/05/2011 09:22 | Comentários (5)

Olá pessoal!

Eu gostaria de compartilhar com vocês, nesse pequeno post, na diferença entre Requisito e Requerimento.

Requisito é a necessidade, ou seja, o problema a ser resolvido. Já Requerimento é o pedido formal de uma solução de um determinado problema, para um determinado Requisito. Simplificando, o artefato nasce como Requisito e depois da análise vira um Requerimento.

É comum que as empresas considerem apenas o termo Requisito para ambos os estados (ou momentos) do artefato. Porém, se algum dia você encontrar alguém se referindo a um Requerimento, considere que o Requisito já foi analisado e refinado, transformou-se em Requerimento, ou pedido, para posterior definição da solução do problema ou requisição. O Requerimento pode conter uma proposta de solução, ou não.

Pra quem não sabia, fica aí a dica.

Por hoje é só!

Até a próxima!

Tags: , | Categories: Padrões de Projeto Posted by Rafael on 12/05/2011 02:07 | Comentários (1)

Olá pessoal!

Hoje vamos falar um pouco sobre um padrão de criação bem simples, o padrão Prototype. Esse padrão tem como objetivo criar um "clone", ou seja, uma cópia, de um determinado objeto. Segue abaixo a definição do nosso livro base:

"Especificar os tipos de objetos a serem criados usando uma instância-protótipo e criar novos objetos pela cópia desse protótipo." [GAMMA, 2009].

Um dos diversos cenários que podemos aplicar o padrão Prototype é quando necessitamos guardar o estado de um objeto, em determinados pontos de execução de um processamento, por exemplo. Na maioria das vezes, é mais interessante criarmos "clones", ou cópias, de um objeto em determinado momento, do que criar a instância manualmente.

A estrutura do padrão Prototype é a seguinte:

Estrutura do Padrão Prototype

O padrão Prototype pode ser implementado em conjunto com os padrões AbstractFactory, Composite e Decorator. Estudaremos em breve sobre os dois últimos padrões citados.

No código de exemplo, criaremos uma classe abstrata chamada Ave que implementa a interface ICloneable, e uma classe concreta Calopsita que herda de Ave. O projeto completo pode ser baixado aqui: Prototype.zip (20,74 kb)

Segue o código implementado junto com a classe de teste:

Classe Ave.cs

Classe Calopsita.cs

Classe Teste

O resultado:

Resultado

Repare que o nome dos dois objetos é o mesmo, porém o código hash é diferente, ou seja, são objetos do mesmo tipo e com as mesmas características, porém, são objetos distintos.

Esse é o padrão Prototype, muito simples e fácil de entender e utilizar.

Até a próxima!

 

 

Referência Bibliográfica

GAMMA, Erich, Padrões de Projeto, Porto Alegre: Bookman, 2009.

Tags: , , | Categories: Padrões de Projeto Posted by Rafael on 07/05/2011 17:06 | Comentários (0)

Olá pessoal!

Hoje vamos falar um pouco sobre um padrão muito utilizado e, de igual modo, simples: o padrão Singleton.

Esse padrão tem como objetivo "garantir que uma classe tenha somente uma instância e fornecer um ponto de acesso global para a mesma". [GAMMA, 2000].

Em algumas situações precisamos garantir que apenas uma instância de uma determinada classe seja criada no contexto do sistema. São os casos de fazermos uso de propriedades específicas de configuração comuns à toda aplicação, utilização de um Proxy qualquer existente na sua empresa, que seja utilizado para integração dos sistemas, por exemplo.

Por se tratar de um padrão muito simples, vamos direto para a representação da sua estrutura, e logo em seguida para uma implementação de exemplo.

A estrutura do padrão Singleton é a seguinte:

Estrutura Singleton

Para que exista uma instância única na aplicação, precisamos criar um construtor privado na classe Singleton, uma variável estática, e implementarmos a lógica para criação da instância e o seu retorno. O código abaixo exemplifica isso:

Aqui está o projeto completo: Singleton.zip (20,92 kb)

Ao executar o projeto, se você inserir um breakpoint no método obterInstancia da classe ProxyConnectionDB e ir passo-a-passo, notará que ele cria a instância apenas na primeira execução (variável con1), pois a classe nunca foi utilizada. Porém, na segunda chamada (variável con2) o objeto já existe, e sua instância é retornada, sem criar uma nova instância.

O exemplo acima implementa o padrão Singleton pois tem um contrutor privado, e um método que cria e/ou retorna a instância da classe, que será acessada por um único ponto na aplicação.

Alguns padrões podem ser implementados usando Singleton. É o caso dos padrões Prototype, AbstractyFactory e Builder. Já conhecemos o padrão AbstractyFactory, e veremos os padrões Prototype e Builder em breve.

É isso!

Até a próxima!

 

 

Referência Bibliográfica

GAMMA, Erich, Padrões de Projeto, Porto Alegre: Bookman, 2009.

Tags: , , | Categories: Metodologia de Desenvolvimento Ágil Posted by Rafael on 06/05/2011 22:41 | Comentários (6)

Olá pessoal!

Nesse post comentarei sobre as principais vantagens e benefícios gerados a partir da adoção de processos baseados em metodologias ágeis, por qualquer empresa de Tecnologia da Informação.

"Metodologias ágeis têm sido apontadas como uma alternativa às abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas também como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situações em que os requisitos do sistema são estáveis e requisitos futuros são previsíveis. Entretanto, em projetos em que há muitas mudanças, em que os requisitos são passíveis de alterações, onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, não pode haver requisitos estáticos, necessitando então de metodologias ágeis. Além disso, o ambiente das organizações é dinâmico, não permitindo então que os requisitos sejam estáticos." [SOARES, 2011].

Um projeto nunca é igual a outro projeto, e quanto maior a empresa, maior a diversificação de projetos, em relação a tamanho, escopo, requisitos, custo e prazo. Ao longo dos últimos anos, tenho atuado em projetos dos ramos bancário, securitário e previdenciário, e, todos eles possuíam características diferentes. Uns demandaram uma formalização e um planejamento intensos, enquanto outros, nem tanto. Um dos grandes problemas enfrentados foi ter que passar por todo o processo de desenvolvimento padrão, preenchendo muitos artefatos, muitas das vezes, desnecessários para o projeto. 

Muitas empresas acreditam que ser ágil é o mesmo que ser informal. E isso não é verdade. Ser ágil, dentre outras características, é ser formal apenas nos momentos os quais a formalidade é necessária, dando fluência ao projeto.

Empresas do ramo bancário, por exemplo, têm como um dos principais requisitos para terem o direito de ofertar seus papéis na Bolsa de Valores de Nova York, a adesão à Lei Sarbanes-Oxley, ou SOX, que estabelece a confecção de diversos artefatos, definindo um processo para o desenvolvimento de produtos de software. O que algumas empresas não sabem, é que é possível atender aos requisitos da SOX dentro de um processo baseado numa metodologia ágil, gerando apenas os artefatos que são realmente necessários e importantes, para que o projeto não seja afetado pelo excesso de documento a serem criados, sem necessidade.

Uma grande preocupação das empresas é o número de horas extras geradas em cada projeto. Esse, sem sombra de dúvida, é um assunto que gera muito estresse para o projeto, e conseqüentemente a todos os stakeholders. O fato gerador desse desconforto no decorrer do projeto, na maioria das vezes, é a dificuldade de se planejar um projeto como um todo. O grau de assertividade de um planejamento de 120 dias certamente é menor do que um de 15 dias. Metodologias ágeis estabelecem entregas semanais, quinzenais ou mensais (às vezes bimestrais e até semestrais, mas a ocorrência é bem pequena em relação aos demais prazos), o que facilita muito o planejamento. 

"a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as pessoas." [SOARES, 2011].

É fato que, se temos um problema menor, podemos atuar pontualmente e sermos mais assertivos em relação aos prazos e custos. Com isso, diminuímos a ocorrência de horas extras e sobrecarga de pessoal em fases críticas do projeto.

Outro grande problema presente enfrentado pelas empresas quanto à utilização de processos baseados em metodologias não ágeis de desenvolvimento de software é entrega única, apenas ao final do projeto. Em alguns casos, o pior acontece. O cliente vira pra você e diz: “Mas não foi isso que eu pedi!”. Esse cenário é, sem dúvida, um dos mais críticos para um projeto, pois tempo, dinheiro, expectativa, confiabilidade “foram para o ralo”. 

"Entregas freqüentes visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo e melhora as avaliações do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente." [SOARES, 2011].

Se adotarmos a técnica de entregas freqüentes, o risco de esse cenário acontecer tende a zero, pois a cada entrega, recebemos um feedback do cliente sobre o entregado, facilitando assim, ajustarmos as pendências para convergir às expectativas do cliente.

"Para prevenir a degradação da qualidade devido a entregas muito curtas, dá-se alta ênfase a testes do produto ao longo do ciclo de vida. Métodos ágeis requerem testes de integração ao longo do processo de desenvolvimento. Automação dos testes é importante para que as "builds" diárias passem por testes de regressão." [ABRANTES, 2011].

Outro benefício que a adoção de entregas menores e mais freqüentes traz para o projeto é a sobrecarga de testes dos requisitos classificados como críticos, ou de alta complexidade. Durante o planejamento do projeto, os requisitos são classificados segundo sua complexidade e criticidade. É uma boa prática de desenvolvimento baseado em metodologias ágeis a implementação dos requisitos de maior complexidade, pois, a cada nova entrega, todos os requisitos são retestados, o que diminui exponencialmente o risco de não conformidade com a especificação dos mesmos.

A cooperação e interação entre cliente e equipe de desenvolvimento do projeto também é um ponto forte nos processos de desenvolvimento baseados em metodologias ágeis.

"Interação aberta e com proximidade entre os vários stakeholders (especialmente entre cliente e desenvolvedores); o cliente deve tomar parte ativa no processo de desenvolvimento e prover opinião de forma regular e freqüente." [ABRANTES, 2011].

Quando o cliente faz parte do projeto, interagindo com a equipe, dando opinião e agindo realmente como parte integrante do projeto, alguns problemas enfrentados hoje por algumas empresas "caem por terra". Alguns usuários muitas das vezes mal explicam o que querem, aprovam as especificações dos requisitos às vezes sem se preocupar muito em ler todo o documento, pensando que o que não está escrito, está implícito, largando a equipe do projeto durante todo o desenvolvimento, retornando apenas no período de homologação. Essa atitude é muito freqüente em empresas que adotam apenas a forma não ágil de desenvolvimento. A metodologia ágil prega que o cliente precisa estar junto, participar, interagir, registrar feedbacks, ou seja, fazer parte do projeto.

"Todo dia, é feita uma reunião de 15 minutos onde o time expõe à gerência o que será feito no próximo dia, e nestas reuniões os gerentes podem levantar os fatores de impedimento, e o progresso geral do desenvolvimento." [SANTOS, 2011].

Outra característica muito importante dos métodos ágeis é a realização de rápidas reuniões diárias, onde são expostos de maneira pontual quais são as tarefas a serem executadas no próximo dia, o que ajuda a guiar a atenção e foco da equipe para o que realmente é importante naquele momento, ou seja, o sprint atual, fazendo o que é importante e necessário agora, e postergando o que pode ser postergado, sem causar impacto para o projeto. Algumas empresas realizam reuniões com o mesmo objetivo, porém, para tratar questões de tarefas de semanas ou meses, o que aumenta muito o escopo da reunião, prejudicando a tomada de decisões, ocupando grande parte do tempo e com foco menos pontual, o que dificulta a resolução dos problemas.

"Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas." [BECK, 2011].

A única certeza que temos quando começamos um projeto é a de que os requisitos serão alterados. Muitas equipes têm uma resistência enorme às alterações de requisitos ao final do projeto, principalmente pelo custo e esforço enormes necessários para a realização da mudança. Em métodos ágeis esse custo e esforço tende a ser menor, o que facilita muito a vida de todos os envolvidos no projeto. 

"Lei do foco, ou da concentração: menos é mais" e "Lei do progresso: podemos criar mais com menos" [KOCH, 2009].

Uma das técnicas, ou teorias, aplicadas em métodos ágeis (largamente aplicado na administração de empresas e auto-ajuda) é o Princípio de Paretto, também conhecimento como Princípio 80/20, que prega basicamente que podemos atingir 80% dos resultados esperados focando em apenas 20% das tarefas. Essa explanação parece muito simplista, mas quando aplicada à realidade de uma empresa, no que concerne o desenvolvimento de aplicativos com métodos ágeis, faz todo sentido. Ao invés de gastarmos uma grande parte do tempo fazendo planejamentos enormes, criando artefatos gigantescos sem necessidade, vamos direto ao foco, separando as atividades por risco e complexidade, o que facilita a compreensão de cada parte do problema, mantendo o foco no que é realmente importante, gerando os resultados esperados com muito menos esforço e desperdício de tempo e dinheiro.

Esses são os principais pontos que uma empresa deve levar em consideração para a adoção de um processo de desenvolvimento de software baseado em métodos ágeis. Sem dúvida, é interessante para qualquer tipo de empresa que faz uso da tecnologia da informação, para condução do seu negócio, fazer uso de métodos ágeis para o desenvolvimento de seus softwares.

Mais informações em http://agilemanifesto.org/

Até a próxima!

 

 

Referências Bibliográficas

SOARES, Michel Dos Santos Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software, disponível em http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf em 04/05/2011.

ABRANTES, José Fortuna e Guilherme Horta Travassos Caracterização de Métodos Ágeis de Desenvolvimento de Software, disponível em http://reuse.cos.ufrj.br/wdra2007/images/artigos/30188.pdf em 04/05/2011.

SANTOS, Rogério Guaraci Dos e Giulian Dalton Luz Métodos Ágeis, disponível em http://www.ime.usp.br/~gdaltonl/ageis/ageis_6pp.pdf em 04/05/2011.

BECK, Kent Manifesto Ágil, disponível em http://manifestoagil.com.br/principios.html em 04/05/2011.

KOCH, Richard, O Estilo 80/20, Rio de Janeiro: Sextante, 2009.

Tags: , | Categories: C#, Linguagem de Programação Posted by Rafael on 12/04/2011 18:27 | Comentários (0)

Olá pessoal,

Vejam só que notícia bacana para aqueles que programam em C#: http://tirania.org/blog/archive/2011/Apr-06.html

Enjoy it, Cool

Até mais!

Tags: | Categories: Pessoal Posted by Rafael on 28/03/2011 23:11 | Comentários (0)

Olá pessoal!

Gostaria de compartilhar com vocês sobre um tema muito interessante, o Princípio de Paretto, também conhecido como Princípio 80/20.

De forma bem sucinta, esse princípio prega que podemos conseguir 80% dos resultados focando em apenas 20% das tarefas. Esse princípio foi largamente difundido no mundo dos negócios, porém já há algum tempo tem sido aplicado à vida pessoal, e também, como não poderia ser diferente, no mundo da tecnologia da informação.

Indico fortemente que estudem um pouco mais sobre esse princípio. O livro O Estilo 80/20, de Richard Koch, é ótimo. Não estou ganhando qualquer centavo por essa indicação, nem muito menos pretendo que isso aconteça. Estou apenas fazendo uma recomendação como leitor muito satisfeito com o conteúdo do livro.

Boa leitura!

Mais informações em http://pt.wikipedia.org/wiki/Princ%C3%ADpio_de_Pareto

Até a próxima!

Tags: , , , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 25/02/2011 05:39 | Comentários (0)

Olá pessoal!

Hoje eu gostaria de compartilhar com vocês uma dúvida muito simples, porém interessante na minha opinião, que surgiu durante a confecção de um Diagrama de Use Case em UML 2.0. Eu uso o astah, um aplicatico muito bacana, e o que é melhor, free! O astah, assim como qualquer ferramenta de modelagem UML 2.0, possui dois tipos de Use Case: O Use Case de Sistema e o de Negócio, que são representados pelos seguintes objetos:

Pesquisei um pouco sobre e encontrei uma ótima definição:

"Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

  • A business use case is described in technology-free terminology which treats system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process Mapping is another method for this level of business description.
  • A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, "create voucher") and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor's actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined."

Fonte: http://en.wikipedia.org/wiki/Use_Case#Business_vs._System_Use_Cases

É uma dica muito simples, mas que eu achei interessante compartilhar com vocês.

Até a próxima!

Tags: , , | Categories: C#, Linguagem de Programação Posted by Rafael on 11/01/2011 19:03 | Comentários (1)

Olá pessoal!

Falaremos hoje sobre operadores C#, em especial sobre os operadores shift, << e >> . A função desses operadores é deslocar bits para a esquerda ( << ) ou para a direita ( >> ), que podem ser utilizados apenas em operações com variáveis do tipo inteiro, pois, não existem números reais na base 2 (binários), apenas números inteiros.

Para entender melhor, vamos falar um pouco sobre números binários e inteiros.

Consideremos a seguinte tabela:

Essa é uma tabela para facilitar a representação de números inteiros em binários. Na linha superior (em azul) temos o expoente da base. Como a base que iremos trabalhar é binária, ou seja, base 2, a linha amarela representa o resultado da potenciação entre a base 2 e seus expoentes. Assim, temos 20 = 1, 21 = 2, 22 = 4, 23 = 8, ..., 210 = 1024, ..., e assim por diante (limitei até o expoente 10 apenas para facilitar a exemplificação).

Muito bem, agora, vamos representar o número inteiro 100 em binário. Na linha amarela, partimos sempre da esquerda para a direita, até encontrar o primeiro número menor ou igual ao número que queremos representar, que nosso caso é o inteiro 100.

Localizamos que o número 64 é o primeiro número menor ou igual a 100, da esquerda para a direita. Assim, “ligamos” o flag, ou seja, inserimos o número 1, da seguinte maneira:

Feito isso, partimos para o segundo bit. Devemos ter em mente o quanto resta para chegarmos a 100 inteiros. A conta é bem simples: se já “ligamos” o 64, a subtração entre 100 e 64 é igual a 36. A partir de agora, localizamos o primeiro número menor ou igual a 36, a partir da primeira célula à direita do flag que representa 64, que é 32.

Como 32 é menor ou igual a 36, ativamos também essa célula, ficando assim:

Legal, agora nos restam 4 inteiros (100 – 64 – 32 = 4). Dando seqüência, como 16 não é menor ou igual a 4, inserimos um 0, ou seja, “desligamos” o flag da célula 16, assim:

Da mesma maneira, fazemos com a célula 8, pois 8 não é menor ou igual a 4, ficando assim:

Como 4 é menor ou igual a 4, “ligamos” o flag, da seguinte maneira:

Como chegamos a 100 inteiros, completamos as células restantes à direita com 0, assim:

Temos agora o número inteiro 100 representado em binário como 1100100.

Muito bom! Agora que já sabemos como representar inteiros em binários de uma forma fácil, vamos entender como os operadores shift trabalham.

Basicamente, como dito anteriormente, o operador shift << desloca um bit à esquerda, inserindo um 0 (zero) na célula vazia, e o operador >> desloca um bit à direita, desconsiderando o bit que “sai” do range. Vamos exemplificar com um Console Application em C#, bem simples, junto com a nossa tabela de conversão.

Consideremos o seguinte Console Application:

namespace Blog.Operadores.Shift

{

    class Program

    {

        static void Main(string[] args)

        {

            try

            {

                Console.WriteLine("Insira um número inteiro:");

 

                int inteiro = 0;

                Int32.TryParse(Console.ReadLine(), out inteiro);

 

                Console.WriteLine("Número inteiro escolhido: " + inteiro.ToString());

 

                Console.WriteLine("");

 

                Console.WriteLine("Quantos bits você deseja deslocar?");

 

                int qtdeBits = 0;

                Int32.TryParse(Console.ReadLine(), out qtdeBits);

 

                Console.WriteLine("Bits a deslocar: " + qtdeBits.ToString());

 

                Console.WriteLine("");

 

                Console.WriteLine("À esquerda ou à direita? Digite << para à esquerda e >> para à direita:");

 

                string comando = Console.ReadLine();

 

                if (comando.Trim() != "<<" && comando.Trim() != ">>")

                {

                    throw new Exception("Comando inválido! Você deve escolher entre << e >>");

                }

 

                switch (comando.Trim())

                {

                    case "<<":

                        Console.WriteLine("Bit deslocado à esquerda");

                        inteiro = inteiro << qtdeBits; // forma simplificada: inteiro <<= qtdeBits;

                        break;

                    case ">>":

                        Console.WriteLine("Bit deslocado à direita");

                        inteiro = inteiro >> qtdeBits; // forma simplificada: inteiro >>= qtdeBits;

                        break;

                    default:

                        break;

                }

 

                Console.WriteLine("");

                Console.WriteLine("Resultado: " + inteiro.ToString());

            }

            catch (Exception ex)

            {

                Console.WriteLine("");

                Console.ForegroundColor = ConsoleColor.Red;

                Console.WriteLine("ERRO: " + ex.Message);

            }

            finally

            {

                Console.ResetColor();

                Console.ReadKey();

            }

        }

    }

}

Se preferir, faça o download do projeto aqui: Blog.Operadores.Shift.zip (19,21 kb)

Note os dois comentários // forma simplificada no código. Podemos escrever tanto assim x = x << y quanto x <<= y ou então x = x >> y quanto x >>= y. A segunda opção é a forma simplificada do comando. Muda apenas a sintaxe, o resultado é o mesmo.

Ao executarmos o aplicativo, temos a seguinte tela:

Para seguir o nosso exemplo, vamos inserir o número 100.

Vamos deslocar apenas 1 bit à esquerda.

Na tabela, podemos ver como pode ser feito manualmente:

Todos os bits são deslocados 1 (uma) casa para a esquerda, e a célula vaga é preenchida com 0 (zero).

Assim, temos o número inteiro 200 como resultado. Agora vamos executar novamente o aplicativo, porém, agora deslocando 1 bit à direita.

Na tabela:

Obtemos como resultado 50 inteiros.

Logo, podemos notar que, se deslocarmos 1 bit à esquerda, multiplicamos o número por 2, e se deslocar à direita, dividimos também por 2. Agora, porque por 2? A resposta é bem simples, como estamos trabalhando com binários, ou seja, base 2, o deslocamento de bits multiplica ou divide o valor pela base, que é 2.

Agora, se deslocarmos 3 bits à direita de 100, temos como resultado 12. Você pode me perguntar: porque não 12,5? A resposta também é simples: porque não existem números reais por representação de bits, ou seja, o resultado 12,5 é truncado, ficando apenas 12.

Vamos ver na tabela:

E na aplicação:

É isso aí.

Até a próxima!