segunda-feira, 20 de fevereiro de 2017

COMEÇA HOJE A NOSSA SELEÇÃO PARA NOVOS INTEGRANTES !


Nossa seleção começa Hoje!.. E é muito simples: Basta instalar o aplicativo ChangeTrees disponível no GooglePlay, cadastrar-se, esperar a confirmação do cadastro, e seguir as instruções do jogo para a primeira missão: Documentos.

Resumo da Missão no Jogo: 
Primeiro Passo da Trilha de Seleção de Transcendentes do PET Computação: Documentos.

Você quer ser um Setter, um ser transcendente que deseja mudar o mundo com Educação Tutorial em Computação. Começe hoje enviando, até sexta 24 de fevereiro, os links de seus documentos em pdf para registro no Livro da Sabedoria do Grupo de Educação Tutorial de Computação: a) Currículo Lattes com foto, b) Histórico Escolar e c) RDM de 2016.2. Dia 27 de Fevereiro você receberá o Manual de Educação Tutorial com todas as dicas da Trilha de Seleção de Transcendentes de Computação.

quinta-feira, 13 de outubro de 2016

Recapitulando: Artefatos do Projeto de Software


Os vários subprodutos produzidos durante o processo de desenvolvimento de um software, são ditos artefatos de software. Os diagramas (casos de uso, classes, sequência), requisitos e documentos do projeto são artefatos do  desenvolvimento do software que ajudam a descrever a função, arquitetura e o design do software. Porém existem outros artefatos que estão relacionados com o processo de desenvolvimento, que podem variar de acordo com o processo adotado, como por exemplo planos de projeto, processos de negócios e avaliações de risco. O código do software, manuais, arquivos executáveis e módulos também são considerados artefatos de software.

Os artefatos são classificados de acordo com a sua função. As etapas do processo de desenvolvimento utiliza artefatos de entrada (gerados nas etapas anteriores) no inicio de cada etapa e produz, ao término, artefatos de saída que serão utilizados nas etapas seguintes. Nesse sentido, os modelos são necessários para padronizar os formatos e melhorar a comunicação entre os elementos presentes nas etapas do processo.

Vamos agora revisar três tipos de diagramas: casos de uso, classes e sequência.

Modelo: diagrama de casos de uso

Diagrama de casos de uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. Descrevem um cenário que mostra as funcionalidades do sistema do ponto de visto do usuário.

O cliente deve ver no diagrama de casos de uso as principais funcionalidades do sistema. O diagrama de Caso de Uso é representado por atores, casos de uso e relacionamentos entre estes elementos.

Você lembra o que significa as anotações <<include>> e <<extend>>?

<<include>> - Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para o caso de uso incluído.

<<extend>> - Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor para o caso de uso estendido.
 
 Modelos: diagrama de classes

Diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos

 

Modelos: diagrama de sequências

Diagrama de sequência mostra uma interação, que representa a sequência de mensagens entre instâncias de classes, componentes, subsistemas ou atores. Tempo flui para baixo no diagrama e mostra o fluxo de controle de um participante para outro.




Vamos praticar com o POSCOMP 2015 - Questão 67
A Empresa XYZ tem como missão desenvolver software com um alto padrão de qualidade. A empresa possui entre seus colaboradores uma pessoa responsável por analisar a consistência dos artefatos gerados na atividade de projeto de software, mais precisamente na construção dos diagramas de casos de uso, diagramas de classes e diagramas de sequência. O analista de qualidade recebeu os seguintes diagramas para analisá-los quanto à sua consistência.

Agora vamos aos diagramas!


Após análise, o analista de qualidade identificou que, no diagrama de sequência,

(A) o método capturar da classe InterfaceLogin não é consistente com o método apresentado na troca de mensagem.
(B) o objeto Usuario instanciado é órfão de uma classe.
(C) o objeto InterfaceLogin é órfão de uma classe e o método capturar da classe InterfaceLogin não é consistente com o método apresentado na troca de mensagens.
(D) o objeto Users é órfão de uma classe e o método validar da classe Usuarios não é consistente com o método apresentado na troca de mensagens.
(E) o objeto InterfaceLogin é órfão de uma classe e o método logar da classe Usuarios é consistente com o método apresentado na troca de mensagens.

Confira a resposta do nosso Guia do Poscomp 2015!

Por,
Gleyser Guimarães - Integrante do PET Computação

quinta-feira, 29 de setembro de 2016

Apresentação em parceria com o Pré-vestibular Solidário


O grupo PET Computação ao longos dos anos tem desenvolvido ações que buscam atrair novos alunos para o curso de ciência da computação na UFCG. O nosso objetivo é servir aos alunos atuais (graduandos) e potenciais (estudantes de ensinos fundamental e médio) do Curso de Ciência da Computação com uma experiência de educação tutorial inovadora composta de atividades integradas
de pesquisa, ensino e extensão e de práticas de liderança.



Nesse sentido, em parceira com o Pré-vestibular solidário da UFCG, o grupo PET Computação realizou palestra sobre as carreiras e sobre o curso de computação. A atividade contou com a colaboração do aluno de graduação Gabriel Vinha, que proferiu a palestra para os alunos participantes. 

O objetivo da atividade foi despertar o interesse por computação e apresentar as oportunidades das carreiras na computação. Foram realizadas atividades de computação desplugada para apresentar conceitos de computação.

Esperamos ver muitos desses rostinhos em breve no nosso curso! 

Por, 
Gleyser Guimarães - Integrante do PET Computação



sexta-feira, 16 de setembro de 2016

Introdução ao Processamento Digital de Imagens



O Processamento Digital de Imagens pode ser entendido como um processo de computação onde a entrada e a saída são imagens, se estendendo desde a captura de uma imagem até a sua exibição em um dispositivo de saída. É um assunto extremamente complexo e de natureza inerentemente multidisciplinar, englobando fundamentos e conceitos de diversas áreas do conhecimento, como álgebra, óptica, física do estado sólido, teoria dos grafos, estatística, redes neurais, inteligência artificial, percepção visual, ciência cognitiva e etc.. O objetivo deste texto não é detalhar esse processo, mas sim trazer alguns conceitos fundamentais da construção de imagens, que podem servir como base introdutória para quem está começando a se aventurar com o tema.


Tudo o que enxergamos é luz!

Luz é radiação eletromagnética, e como tal, comporta-se como onda, definida por uma frequência e um comprimento de onda. O sistema visual humano consegue capturar uma minúscula faixa desse espectro (aproximadamente de 400 a 770 nm), a qual denominamos luz visível. Dentro da luz visível, o olho percebe comprimentos de onda distintos como cores distintas.
Espectro eletromagnético, com foco na luz visível

A radiação eletromagnética penetra no olho através de um buraquinho na íris chamado de pupila, passa por uma estrutura translúcida chamada de cristalino, que por ação muscular se deforma para focalizar essa luz, e finalmente atinge uma camada interna posterior chamada de retina, que possui fotossensores conhecidos como cones, que convertem a radiação em sinapses elétricas que são transmitidas para o cérebro interpretar e nos dar essa ilusória sensação de que percebemos tudo o que miramos.

Os principais instrumentos utilizados para capturar imagens a serem processadas por um computador são as câmeras, que funcionam basicamente como imitações do olho humano. O obturador da câmera funciona de forma análoga à íris, controlando a quantidade de luz que entra. Assim como o cristalino, a lente serve para focalizar a luz, dando nitidez às imagens formadas. E o filme ou sensor digital funciona como a retina, ressignificando pura radiação em algo que faça sentido.

Comparativo entre uma câmera fotográfica e o olho humano


Modelos cromáticos

Emissores de luz são percebidos pelo sistema visual a partir da combinação de proporção variável das faixas correspondentes às sensações das cores vermelho, verde e azul, gerando todas as cores percebidas pelo olho humano. Esse processo, denominado aditivo, inspirou a criação do modelo cromático RGB (Red, Green, Blue). Vermelho, verde e azul são consideradas cores primárias nesse modelo. A combinação binária em igual intensidade dessas cores produz ciano, magenta e amarelo, consideradas cores secundárias. E a combinação balanceada entre as três cores gera o branco.
Objetos que não são emissores de luz são vistos a partir da radiação que os mesmos refletem. Objetos de determinada pigmentação refletem uma parte do espectro visível e absorvem a outra. Existe um outro modelo cromático baseado na absorção de luz, o CMY (Cyan, Magenta, Yellow), onde as cores primárias são obtidas a partir da absorção de uma cor principal da luz branca incidente. Ciano é obtido com a absorção do vermelho, magenta com a absorção do verde e amarelo com a absorção do azul. Quando vermelho, verde e azul são absorvidos, temos o preto.
Modelos cromáticos RGB e CMYK

A formação de imagens em dispositivos que emitem luz, como televisores, monitores ou projetores, se dá com um processo que mistura RGB em proporção variada. Já dispositivos de impressão utilizam o modelo CMY. Como a tecnologia empregada nos pigmentos utilizados nos toners e cartuchos não produzem um preto puro, faz-se necessário o acréscimo de um quarto pigmento, formando assim o modelo CMYK (Cyan, Magenta, Yellow, Black).

Existem ainda diversos outros tipos de modelagem digital em função de outros atributos da percepção cromática humana, como por exemplo os focados em saturação, intensidade, matiz e etc..


Modelagem Digital

Uma imagem monocromática (com um único comprimento de onda), é uma função contínua f(x,y), onde x e y são coordenadas de um plano e o valor de f no ponto (x,y) é a intensidade de luz.
Como se sabe, computadores não representam números reais, apenas uma quantidade finita de valores binários, logo, para representar uma imagem digitalmente é preciso discretizar a função. Para isso, cria-se uma matriz finita de pontos. Cada ponto nesta grade bidimensional é chamado de pixel.

Representação de uma imagem digital monocromática

A intensidade de luz de cada pixel pode ser decomposta pelo produto da quantidade de luz emitida no ponto pela quantidade de luz refletida no ponto. Levando assim à equação:

f(x,y) = e(x,y) * r(x,y)

com 0 ≤ e(x,y) < ∞ e 0 ≤ r(x,y) ≤ 1, onde e(x,y) depende da fonte de iluminação e r(x,y) das características da superfície do objeto.

Já uma imagem colorida no modelo RGB pode ser representado como uma terna, onde cada termo é a intensidade de uma das cores. Uma imagem colorida é entendida então como a composição de três imagens monocromáticas:

f(x,y) = fR(x,y) + fG(x,y) + fB(x,y)

onde fR(x,y), fG(x,y) e fB(x,y) são as intensidades de luz dos canais vermelho, verde e azul respectivamente.
Canais monocromáticos de uma imagem e o resultado da sua composição


Amostragem e Quantização

Conforme supracitado, para uma imagem ser computacionalmente representada, faz-se necessária a sua discretização tanto em quantidade de pontos no plano quanto em nível de luminosidade desses pontos. Chamamos de amostragem o processo de discretização dos pontos, e de quantização o processo de discretização da luminosidade. Em geral a amostragem é feita em pontos igualmente espaçados, dispostos em uma matriz M x N, cada ponto quantizado em níveis de intensidade de luz que variam entre {0, 1,  2, …, L-1} sendo L o total de níveis de intensidade, que é usualmente relacionado a potências de 2 (L = 2l).

Naturalmente os processos de amostragem e quantização suprimem informação da imagem real, sendo assim sua qualidade diretamente dependente dos valores de M, N e l. e quanto maiores forem esses valores, maior será o número de bits necessários para representar a imagem. Para uma imagem monocromática de dimensão M x N, o número de bits será dado por:

b = M * N * l
Influência da amostragem e da quantização na qualidade de uma imagem digital:
(Superior Esquerda) 800 x 600 pixels/ 256 níveis de intensidade;
(Superior Direita) 40 x 30 pixels/ 256 níveis de intensidade;
(Inferior Esquerda) 800 x 600 pixels/ 2 níveis de intensidade;
(Inferior Direita) 40 x 30 pixels/ 2 níveis de intensidade.

Para representar uma imagem colorida seguindo o modelo RGB utiliza-se 3 canais de cor, com quantidade de níveis geralmente idêntica. O número de bits necessários para representar a imagem será portanto:

b = M * N * (lR + lG + lB)


Percebam que com l = 8 poderemos representar um total de 28 * 28 * 28 = 256 * 256 * 256 = 16.777.216 cores distintas (o olho humano só consegue perceber cerca de 10.000.000).


Por, Laybson Plismenn - Integrante do PET Computação

terça-feira, 13 de setembro de 2016

Técnicas de recuperação em Banco de Dados


Um banco de dados (sua abreviatura é BD, em inglês DB - database) é uma entidade na qual é possível armazenar dados de maneira estruturada e com a menor redundância possível. Estes dados devem poder ser utilizados por programas, e/ou por diferentes usuários. Assim, a noção básica de dados é acoplada geralmente a uma rede, a fim de reunir conjuntamente estas informações. Fala-se, geralmente, de sistema de informação para designar toda a estrutura que reúne os meios organizados para poder compartilhar dados. Um BD permite colocar dados à disposição de usuários para uma consulta, uma introdução ou uma atualização. Um BD pode ser local, utilizável em uma máquina por um usuário, ou repartido, significa que as informações são armazenadas em máquinas distantes e acessíveis por rede. Mas, o que fazer quando os dados do BD sofrem alguma alteração indesejada? Quais procedimentos podemos tomar para recuperação em caso de falhas?





ALGORITMOS DE RECUPERAÇÃO


A recuperação de falhas existe para garantir as propriedades de atomicidade e durabilidade de transações. O sistema de recuperação(restauração) de falhas é responsável pela restauração do banco de dados para um estado – o que havia antes da ocorrência de uma falha. Os tipos de falhas tratáveis por um sistema de recuperação de falhas:


  • Falha de transação → SGBD entra em ação;
    • Erro lógico: a transação não pode mais continuar devido a alguma condição adversa interna;
    • Erro do sistema: uma transação não pode mais continuar porque o sistema entrou num estado inadequado.


  • Queda de sistema: perda de conteúdo volátil → continua-se com a base em meio não volátil;
    • Falha de disco: perda parcial ou total do conteúdo não volátil:  sistemas de backup.


Os algoritmos de recuperação de falhas podem ser de dois tipos:
  • Ações tomadas durante o processamento normal da transação a fim de garantir informações suficientes para permitir a recuperação de falhas;
  • Ações tomadas em seguida à falha, recuperando o conteúdo do banco de dados para um estado que assegure sua consistência e a atomicidade e durabilidade das transações.


Vamos então conhecer o primeiro tipo:


Modificações Adiadas do BD
Também chamadas de NO-UNDO/REDO. Nesta técnica, somente o valor novo do item de dado que sofreu alteração é necessário ser guardado no registro de log, pois:


  • Somente escalonamentos seriais estão sendo considerados;
  • As escritas são realizadas após a efetivação parcial da transação;
  • No caso de falhas:
    • Antes das escritas no BD: os registros no log serão ignorados (o valor antigo do item de dado permanecerá).
    • Após as escritas no BD: executa-se operações de REDO.
Exemplo:



Alterações feitas no BD:

Procedimento de recuperação em caso de falhas, que resultem em perda de informação no armazenamento volátil:


  • REDO(Ti): Refazer Ti → define o valor de todos os itens de dados atualizados pela transação Ti para os novos valores (operação idempotente);
  • Uma transação Ti deverá ser refeita, se e somente se, o sistema de recuperação encontrar os registros  <Ti, start> e <Ti, commit> no log.
                                         


Ações para o exemplo anterior:
  • Nenhuma ação REDO é necessária;
  • É necessário realizar REDO(T0), uma vez que há um <T0 commit> registrado;
  • Realizar REDO(T0) seguido de REDO(T1), uma vez que <T0 commit> e <T1 commit> estão presentes no log.
Vamos conhecer agora o segundo tipo:
Modificações Imediatas do BD
Também chamadas de UNDO e NO-REDO. Esta técnica permite que as modificações no banco de dados sejam realizadas enquanto as transações ainda estão num estado ativo. As escritas emitidas por transações ativas são chamadas de modificações não-efetivadas. Neste esquema de modificação de BD, o log deverá armazenar o valor antigo e o valor novo oriundos das operações de write.


Execução de uma transação:
  • Um registro <Ti, start> antes da transação Ti iniciar sua execução;
  • Toda operação write(X) de Ti é precedida pela escrita de um novo registro no log;
  • Quando Ti é parcialmente efetivada, um registro <Ti, commit> deve ser escrito no log.


Exemplo:


Alterações no BD:

                                



Procedimentos de recuperação em caso de falhas, que resultem em perda de informação no armazenamento volátil:
  • UNDO(Ti): Desfazer Ti → retorna aos valores antigos todos os itens de dados atualizados pela transação Ti;
  • REDO(Ti): Refazer Ti → ajusta os valores de todos os itens de dados atualizados pela transação Ti para os novos valores.


Após a falha, o sistema de recuperação consulta o log para determinar quais transação precisam ser desfeitas e quais precisam ser refeitas:
  • A transação Ti tem que ser desfeita se o log contiver o registro <Ti start>, mas não possuir o registro <Ti commit>;
  • A transação Ti tem que ser refeita se o log contiver tanto o registro <Ti start> quanto o registro <Ti commit>.
Ações para o exemplo anterior:
  • UNDO (T0): B é restaurado para 2000 e A para 1000;
  • UNDO (T1) e REDO (T0): C é restaurado para 700, e então, A e B retornam aos valores 950 e 2050, respectivamente.
  • REDO (T0) and REDO (T1): Os valores de A, B e C na conta, após esses procedimentos, são 950, 2050 e 600, respectivamente.



REUNINDO A INFORMAÇÃO



O primeiro processo exposto (com REDO e NO-UNDO) vai adiando as gravações no Banco de Dados (BD) até que haja um commit com sucesso. Ou seja, só grava as alterações após o commit. Para refazer (REDO), uma entrada no log para gravação deve incluir o novo valor do item gravado. Todas as operações de escrita (write_item) das transações confirmadas devem ser refeitas, a partir do log na ordem em que foram gravadas, utilizando o procedimento REDO. As transações que estavam ativas e não chegaram ao commit são efetivamente canceladas e devem ser submetidas novamente.


No segundo processo (com UNDO e NO-REDO), assim que você realiza WRITE, os dados são escritos no BD sem a necessidade de um commit parcial. Ou seja, os dados são gravados antes do commit. Quando ocorre um erro na gravação, o BD realiza UNDO em todos os WRITE efetuados após um commit com sucesso. Não há necessidade de refazer operações se a técnica de recuperação garantir que todas as atualizações de uma transação sejam registradas no banco de dados em disco antes do commit da transação.




Por,
Kaio Oliveira - Integrante do PET Computação