UNIVERSIDADE ESTADUAL DA PARAÍBA CENTRO DE CIÊNCIAS EXATAS E SOCIAIS APLICADAS CAMPUS VII GOVERNADOR ANTÔNIO MARIZ CURSO DE LICENCIATURA EM COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE ESTADUAL DA PARAÍBA CENTRO DE CIÊNCIAS EXATAS E SOCIAIS APLICADAS CAMPUS VII GOVERNADOR ANTÔNIO MARIZ CURSO DE LICENCIATURA EM COMPUTAÇÃO LUIZ GUSTAVO LIMA DA ROCHA DESENVOLVENDO UM SOFTWARE FRONT-END PARA A FERRAMENTA TC NO LINUX COMO UMA PROPOSTA DE USO DE QUALIDADE DE SERVIÇO DA INTERNET NAS ESCOLAS Patos PB 2016

2 LUIZ GUSTAVO LIMA DA ROCHA DESENVOLVENDO UM SOFTWARE FRONT-END PARA A FERRAMENTA TC NO LINUX COMO UMA PROPOSTA DE USO DE QUALIDADE DE SERVIÇO DA INTERNET NAS ESCOLAS Pré-projeto apresentado na Disciplina de Trabalho de Conclusão de Curso como requisito básico para a apresentação do Trabalho de Conclusão de Curso do Curso de Licenciatura em Computação da Universidade Estadual da Paraíba - Campus VII. Orientador: Wellington Candeia de Araújo Patos - PB 2016

3 É expressamente proibida a comercialização deste documento, tanto na forma impressa como eletrônica. Sua reprodução total ou parcial é permitida exclusivamente para fins acadêmicos e científicos, desde que na reprodução figure a identificação do autor, título, instituição e ano da dissertação. R672d Rocha, Luiz Gustavo Lima da Desenvolvendo um software Front-end para a ferramenta TC no Linux com uma proposta de uso de qualidade de serviço da internet nas escolas [manuscrito] / Luiz Gustavo Lima da Rocha p. : il. color. Digitado. Trabalho de Conclusão de Curso (Graduação em Computação) - Universidade Estadual da Paraíba, Centro de Ciências Exatas e Sociais Aplicadas, "Orientação: Prof. Dr. Wellington Candeia de Araujo, CCEA". 1. Desenvolvimento de software. 2. TC Linux. 3. Qualidade de internet. 4. Informática na escola. I. Título. 21. ed. CDD 005.3

4

5 RESUMO Problemas de congestionamento de tráfego, atraso e variações de atraso em uma rede de computadores esta relacionada ao aumento de usuários e aplicativos. Para atenuar esse problema, pode ser usado o Linux com a ferramenta TC(Traffic Control), mas o uso dessa ferramenta é complexa e de difícil manutenção. O objetivo desse trabalho é propor uma ferramenta de fácil utilização via interface gráfica e que manipule a ferramenta TC de forma transparente. Sendo este trabalho de classificação como experimental, no qual foi verificada a eficácia de alguns conceitos abordados na solução de um problema real, como por exemplo, a utilização do processo de desenvolvimento easyprocess e o uso qualidade de serviço na rede por meio dos algoritmos de enfileiramento. Concluindo o projeto com o desenvolvimento da ferramenta e realizando os testes de velocidade, antes e depois da execução do software, garantindo que cada usuário tenha uma largura justa da banda da internet, atendendo assim aos objetivos propostos nesse trabalho. Palavras-chave: Desenvolvimento, TC, Linux, Qualidade de serviço.

6 ABSTRACT Traffic congestion, delay and delay variations in a computer network is related to the increase of users and applications. To mitigate this problem, you can use Linux with the TC (Traffic Control) tool, but the use of this tool is complex and difficult to maintain. The objective of this work is to propose a easy tool to use via graphical interface and manipulate the TC tool transparently. Since this work has experimental classification, in which efficacy of some concepts discussed in the solution to a real problem was checked, for example, the use of development process named easyprocess and the use of quality of service in the network by means of queuing algorithms. Finishing the project with the tool development and performing speed tests, before and after the software implementation, ensuring that each user has a fair width of the internet band, thus meeting the objectives proposed in this work. Keywords: Development, TC, Linux, Quality of Service.

7 LISTA DE ILUSTRAÇÕES LISTA DE FIGURAS Figura 01 - Processo em cascata...21 Figura 02 - Processo Espiral...23 Figura 03 - Estrutura do ambiente...52 Figura 04 - Hierarquia das classes...53 Figura 05 - Teste de Velocidade no speedtest.net...60 Figura 06 - Teste de velocidade de download no gnome-system-monitor...60 Figura 07 - Teste de velocidade de upload no gnome-system-monitor...60 Figura 08 - Teste de velocidade de downoad 64Kbps no gnome-system-monitor...61 Figura 09 - Teste de velocidade de upload 32Kbps no gnome-system-monitor...61 Figura 10 - Teste de download e upload no gnome-system-monitor com velocidade limitada em 64Kbps/32Kbps...61 Figura 11 - Teste de velocidade de downoad 512Kbps no gnome-system-monitor...62 Figura 12 - Teste de velocidade de upload 256Kbps no gnome-system-monitor...62 Figura 13 - Teste de download e upload no gnome-system-monitor com velocidade limitada em 512Kbps/256Kbps...62 Figura 14 - Medição de velocidade de saída do servidor para o cliente no speedometer com velocidade limitada em 64Kbps...63 Figura 15 - Medição de velocidade de saída do servidor para o provedor de internet no speedometer com velocidade limitada em 256Kbps...64 Figura 16 - Medição de velocidade de saída do servidor para o provedor de internet e para o cliente utilizando o speedometer com velocidade limitada em 512Kbps/256Kbps...64 Figura 17 - Teste de Velocidade no speedtest.net...65 Figura 18 - Tela do software com regra inserida...65 Figura 19 - Regras executadas pela ferramenta tc na interface eth Figura 20 - Regras executadas pela ferramenta tc na interface eth LISTA DE QUADROS Quadro 01 Tabela de Precedência...34

8 LISTA DE ABREVIATURAS E SIGLAS AF Assured Forwarding BA Behavior Aggregate BE Best Effort CASE Computer-Aided Software Engineenring CBQ Class Based Queue CRC Class-Responsibility-Colaborator DFD Diagrama de Fluxo de Dados DiffServ Differentiated Services DS Differentiated Services DSCP DiffServ Code Point DSMARK Differentiated Service Marker EF Expedited Forwarding FIFO First In First Out GRED Generic Randon Early Detection HTB Hierarchical Token Bucket IETF Internet Enginnering Task Force IP Internet Protocol KIS keep it simple MTU Maximum Transmission Unit NAT Network Address Translation OMT Object-Modeling Technique OOSE Object-Oriented Software Engenharia PHB Per Hop Behavior PRIO Priority Queuing qdisc Queuing Disciplines QoS Quality of Service RED Random Early Detection RSVP Resource reservation Protocol RUP Rational Unified Process SFQ Stochastic Fair Queuing SLA Service Level Agreements TAA Tabela de Alocação de Atividades TAOS Task and Action Oriented System TBF Token Bucket Filter tc Traffic Control TCP/IP Transmission Control Protocol Internet Protocol TOS Type Of Service UFCG Universidade Federal de Campina Grande UML Unified Modeling Language VQ Virtual Queue XP Extreme Programming YP easyprocess

9 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS GERAL ESPECÍFICOS JUSTIFICATIVA REVISÃO TEÓRICA ENGENHARIA DE SOFTWARE PROCESSOS DE SOFTWARE Processo em Cascata Processo Evolutivo Métodos Ágeis Processo Unificado Processo Extreme Programming Processo easyprocess QUALITY OF SERVICE Métodos de implementação Ferramenta Iptables Ferramenta TC Algoritmos FIFO - First In First Out SFQ - Stochastic Fair Queueing TBF - Token Bucket Filter RED - Random Early Detection GRED - Generic Randon Early Detection DSMARK - Differentiated Service Marker PRIO - Priority Queuing CBQ - Class Based Queue HTB - Hierarchical Token Bucket CARACTERIZAÇÃO DO OBJETO DE ESTUDO METODOLOGIA RESULTADOS DO TRABALHO CONCLUSÃO BIBLIOGRAFIA...69 APÊNDICE A - DOCUMENTO DE VISÃO...71 APÊNDICE B - MODELO DA TAREFA...73 APÊNDICE C - USER STORIES E TESTE DE ACEITAÇÃO...75 APÊNDICE D - PROTÓTIPO DA INTERFACE...79 APÊNDICE E - PROJETO ARQUITETURAL...81 APÊNDICE F - MODELO LÓGICO DE DADOS...82 APÊNDICE G - PLANO DE RELEASE...83 APÊNDICE H - PLANO DE ITERAÇÃO...84

10 9 1 INTRODUÇÃO A necessidade de proteger informações sigilosas do Departamento de Defesa dos Estados Unidos durante a Guerra Fria fez surgir a primeira rede de computadores (ARPANET). Com a diminuição da tensão entre EUA e URSS, diversas universidades americanas ingressaram na rede, o que possibilitou aos pesquisadores e alunos aperfeiçoar os estudos já realizados. Na década de 70 surge o protocolo TCP/IP (Transmission Control Protocol Internet Protocol / Protocolo de Controle de Transmissão Protocolo Interconexão) com objetivo de unificar os diferentes métodos utilizados na rede. Na época da criação do TCP/IP não foram previstos problemas ocasionados pelo aumento do número de usuários e aplicações, tais como, congestionamento de tráfego, atraso e variação de atraso. De acordo com Stato (2009, p.187) esses problemas podem em determinadas ocasiões trazer insucessos à implementação de alguns serviços que necessitam de estabilidade de tráfego, onde um simples download pode ocupar a banda de uma conexão prejudicando todo o tráfego disponível. Para atenuar estes problemas da rede se pode implementar um método de qualidade de serviço (QoS - Quality of Service) com a finalidade de estabilizar e dar preferência aos serviços fundamentais. Assim, Gomes e Saturnino (2006, p.37) definem que a qualidade de serviço tem a intenção de garantir, bem como diferenciar, os serviços de Internet permitindo uma garantia do serviço e um controle baseado em políticas para controlar o desempenho da rede IP, tais como alocação de recursos, descarte de pacotes, alocação dos pacotes em filas de espera, etc. Há vários métodos de implementação de QoS, cada um possui características específicas de escopo, modelo de controle e garantia de transmissão. Contudo, o método que será abordado neste estudo é o de Serviços Diferenciados (DiffServ) levando em consideração que este método pode ser implementado numa nuvem virtual DiffServ através do sistema operacional Linux, reduzindo assim seu custo. A ferramenta que será utilizada no Linux para executar o QoS é o tc (Traffic Control) que possui vários algoritmos de enfileiramento. Tendo em vista que a utilização de algoritmos é complexa para maioria dos usuários, a pesquisa propõe o uso de uma interface gráfica amigável. A inclusão digital é uma realidade em grande parte das escolas públicas do

11 10 país, porém o planejamento dos recursos nos laboratórios, como por exemplo, acesso à internet, é ineficiente, pois as conexões não possuem gerenciamento para disponibilizar uma qualidade de serviço. Por exemplo, um aluno ao fazer um download pode consumir toda a banda de conexão disponível para o laboratório, deixando o acesso de outros usuários prejudicado. Com intenção de amenizar tais problemas este estudo apresenta uma proposta de implementação de QoS através de um Frond-End que execute a ferramenta tc sem o conhecimento aprofundado do usuário, beneficiando o uso da internet.

12 11 2 OBJETIVOS A dificuldade na utilização de ferramentas que manipule o controle de tráfego no kernel do Linux, se encontra em seu ambiente de execução, pois são linhas de comandos executados no shell e com extensas opções de parâmetros. A proposta para resolver esse problema é criar um software gráfico amigável, ou seja, que execute esses comandos sem que o usuário final saiba de todos os parâmetros necessários para seu funcionamento. Esse software deve conter somente opções básicas que compõem o controle de banda como nome da interface de rede, endereço de rede, quantidade de banda reservada para determinada faixa ou endereço de rede. O software receberá os dados que o administrador da rede informou através da interface, onde a mesma executará os comandos que fará a aplicação das regras propriamente ditas no sistema operacional. Diante do exposto indaga-se: Qual seriam os benefícios que uma ferramenta Frond-End pode trazer para usuários (alunos e professores) de laboratórios em escolas? 2.1 GERAL O objetivo deste trabalho é propor uma ferramenta que forneça uma qualidade de serviço nas escolas com base no modelo de serviços diferenciados utilizando o sistema operacional Linux. 2.2 ESPECÍFICOS Para o alcance do objetivo geral do trabalho foram definidos os seguintes objetivos específicos, que permitam um QoS com uso de um controle de banda e priorização dos serviços essenciais dentro de uma rede: aplicar regras de QoS via interface gráfica; controlar a banda consumida por dispositivo na rede ou faixa de ip; priorizar serviços em todo ambiente da rede que tenha como saída o gateway Linux.

13 12 3 JUSTIFICATIVA O uso de qualidade de serviço em um roteador que forneça internet para uma rede local é de grande necessidade para uma entidade que possua uma conexão de baixa velocidade e não tenha recursos financeiros para aumentar o mesmo. Pois, o seu limite pode ser consumido por um único usuário da rede, deixando outros usuários quase sem recursos para utilizar algum serviço na internet. Mesmo que a conexão tenha seu tamanho aumentado, haverá uma hora que o seu consumo chegará ao máximo, provocando congestionamento no tráfego da internet. Para resolver tal situação a baixo custo, podemos usar o Linux com a ferramenta traffic control (tc) construindo um script para tal propósito. Mas a construção de regras de QoS utilizando a ferramenta tc é uma tarefa difícil para um usuário, uma vez que a sintaxe é complexa. A construção de regras com o tc se assemelha a escrita de um algoritmo em uma linguagem de programação. Diante da dificuldade apresentada a construção de uma ferramenta que facilite a implementação do QoS, será de grande contribuição para os usuários nas escolas, melhorando assim a qualidade do tráfego disponível, pois, cada dispositivo terá uma parcela justa da banda com a possibilidade de tomar por empréstimo a banda do dispositivo que não esteja usando a internet.

14 13 4 REVISÃO TEÓRICA 4.1 ENGENHARIA DE SOFTWARE Na necessidade de se construir softwares mais complexos e que tenha respostas rápidas e precisas e ao mesmo tempo com menor custo, foi criada há mais ou menos 40 anos a Engenharia de Software com o objetivo de apoiar as atividades de desenvolvimento de um software através de implantações de métodos, processos e ferramentas. Assim, a disciplina de Engenharia de Software proporciona atribuições de qualidade e produtividade no desenvolvimento de software. Segundo Hirama (2011, p.7), afirma que: A Engenharia de Software abrange ferramentas de apoio para atividades, métodos para orientar a realização das atividades, processo para definir as atividades e os produtos e a qualidade do processo e de produtos de software. Dessa maneira o desenvolvimento de software pode obter produtos com qualidade e produtividade. Os métodos além de padronizar os trabalhos durante desenvolvimento do produto e facilitar a manutenção do mesmo, também fornecem um canal de comunicação entre os membros da equipe. Os métodos de abordagem mais utilizadas são a Estruturada e a Orientada a Objetos, sendo o último o que tem maior aceitação devido a utilização da notação UML (Unified Modeling Language). Os processos estabelecem o caminho das atividades que devem ser feitas para alcançar os objetos do software. Atividades essas de engenharia que envolvem a Engenharia de Sistema, que tem por finalidade compreender os requisitos em alto nível de um sistema computacional e as necessidades de negócio do cliente; atividade de Análise que procura entender e detalhar os requisitos do sistema; a atividade de Projeto que estabelece uma arquitetura para o software; atividade de Codificação que produzirá o software conforme os requisitos acordados na engenharia de sistema e a atividade de Testes que tem a finalidade de descobrir erros no sistema. O processo mais usado em projetos de desenvolvimento de software é o Cascata, mais existem outros como o Modelo V, RUP (Rational Unified Process) e o XP (Extreme Programming). As ferramentas CASE (Computer-Aided Software Engineenring) apareceram nas atividades de desenvolvimento, tanto nos processos como nos métodos, para

15 14 oferecer maior produtividade e qualidade ao software. Então definimos Engenharia de software como sendo o uso dos princípios básicos da engenharia tradicional, com o fim de agregar confiança, eficiência e custo/benefício no produto. Segundo o Chaos Report de 2009 da empresa norte-americana Standish Group apud Hirama (2011, p.10), o percentual de sucesso dos projetos de software foi de 32%, de falha foi de 24% e de deficientes foi de 44%. E entre os deficientes estavam 45% acima do custo, 63% acima do prazo e 67% de expectativas atendidas. Onde sucesso entende-se por projeto entregue e falha significa projeto não concluído ou abandonado, ambos na viabilidade do cliente em relação a custo, atendimento e prazo. Hirama (2011, p.10) complementa que as causas pelas falhas e deficiências dos projetos estavam na má definição dos requisitos, incompletos ou alterados, na falta de preparo da gerência, na falta de conhecimento de tecnologia e problema de comunicação. O problema de comunicação não é só com o cliente, mas também com os próprios membros da equipe de desenvolvimento (gerentes, analistas, programadores, entre outros), que durante as atividades realizadas a comunicação entre eles é de grande importância. Para minimizar problemas de comunicação e de gerência é necessário a implantação de atividades de gerenciamento de projetos que devem dimensionar e estabelecer uma estratégia de produção adequada aos custos e prazos predefinidos. A principal saída dessa atividade é o plano de projeto que deve ser adotado para acompanhar e controlar o andamento do projeto, outros itens importantes no gerenciamento são a definição de cronograma e o plano de comunicação do projeto no qual possibilita administrar o fluxo de comunicação entre os membros do desenvolvimento e o cliente. Um dos pontos cruciais no sucesso ou fracasso de um projeto está no início dos trabalhos com a definição de requisitos. E é neste ponto que as especificações do software são elaboradas durante as atividades de Engenharia de Sistema, e posteriormente validadas nas atividades de Análise, que tem o objetivo de atender as necessidades de negócios e expectativas do cliente, onde os requisitos são levantados pela equipe de projeto em parceria com o cliente. Paula Filho (2003, p.87) faz a seguinte definição de Engenharia de Sistema: O conjunto de técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de um produto, afirma ainda que uma boa engenharia de requisitos é um

16 15 passo essencial para o desenvolvimento de um bom produto, [ ] Para garantir ainda mais a qualidade, os requisitos devem ser submetidos aos procedimentos de controle previstos no processo, e devem ser verificados através das atividades de Análise. Mas o que seriam esses requisitos? Requisitos de um sistema são condições necessárias para atingir certo objetivo com o intuito de resolver algum problema computacional a pedido do cliente, por exemplo, montar e/ou enviar um relatório. Sommerville (2007, p.79) faz duas explicações para esclarecer o termo requisito: na primeira ele fala que os requisitos de usuários são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais para declarações abstratas de alto nível, e na segunda define os requisitos de sistema como sendo uma definição formal e detalhada de uma função do sistema especificando o que o mesmo deve fazer. Para os requisitos de sistema temos ainda duas classificações que são os requisitos funcionais e não-funcionais. Onde os requisitos funcionais conhecidos também por requisitos comportamentais são definições de serviço de um sistema que determina o que o mesmo pode fazer ou que não deve fazer durante as entradas de informações específicas. Um exemplo de requisitos funcionais são as características das interfaces do produto ou os casos de uso que representam funcionalidades de um sistema, enquanto os requisitos não-funcionais são as limitações sobre esses serviços no qual são determinados aspectos que alcancem a qualidade desejada, como por exemplo, desempenho, tempo de resposta e outros; lembrando que os requisitos não-funcionais não estão relacionados somente ao sistema, mas também ao processo de desenvolvimento no qual alguma especificação de padrão de projeto ou de qualidade seja imposta devido a restrições de orçamento ou fatores externos, como segurança e privacidade. Segundo Paula Filho (2003, p.5), requisitos são características que definem os critérios de aceitação de um produto, e que essas características são divididas em: características funcionais, que representam os comportamentos que um programa ou sistema deve apresentar diante de certas ações de seus usuários, e características não-funcionais, que quantificam determinados aspectos do comportamento. A coleta desses requisitos se inicia durante as atividades de Engenharia de Sistema com a concepção, levantamento e elaboração realizadas junto ao

17 16 cliente/usuário. Na concepção se estabelece um entendimento básico do problema no início do projeto definindo o escopo que o produto se propõe a resolver e torna-se também uma comunicação preliminar entre o cliente e o desenvolvedor; nas atividades de levantamento que é fornecida uma lista de todos os requisitos funcionais e não-funcionais e são também realizadas em paralelo as atividades de elaboração que refinam as funções, restrições e especificações do produto, sendo formuladas com a interação do usuário final com a interface do sistema. Para resolver alguns problemas de conflitos de requisitos ou limitação de recursos de negócio durante as atividades de levantamento e elaboração de requisitos, o engenheiro de requisitos reajustará os termos de acordo com o cliente através do processo de negócio, identificando os possíveis riscos de custos e prazos de entrega do projeto. No decorrer dessas atividades é elaborado o documento de requisitos de software contendo todas as características que o sistema dispõe a fazer e informações detalhadas dos requisitos como funcionalidades, desempenho, restrições impostas pelo sistema, riscos do projetos e outros atributos que envolvam o sistema e/ou o projeto, ficando assim afirmado um acordo oficial do que os desenvolvedores devem fazer conforme as especificações aprovadas pelo cliente/usuário do sistema. Dependendo do processo de desenvolvimento utilizado a quantidade incluída de detalhes no documento de requisitos pode variar; um exemplo é o processo interativo cujo os detalhes e as resoluções de ambiguidade vão sendo inseridas durante cada etapa de interação no desenvolvimento do sistema. Deve ser definido no documento de requisitos de software quem são os usuários finais do sistema, no qual um ou mais usuários serão designados posteriormente a acompanhar o processo de desenvolvimento, como por exemplo, atividades de teste, de validação e de usabilidade, por serem capazes de definir requisitos do produto devido suas experiências em diversas áreas em que o produto será usado. Podendo ser inserido nesse documento o perfil do usuário com um conjunto de dados relacionado ao mesmo, denotando suas habilidades, limitações e outras características, por exemplo, canhoto ou destro, domínio de outra língua, conhecimento e tempo de uso de sistemas computacionais e entre outros aspectos relacionados ao uso do sistema. Para adequar a interação homem-máquina são realizados testes de

18 usabilidade que são ferramentas que atribuem qualidade na construção do produto, possibilitando o usuário a produzir com rapidez as tarefas no sistema, com menos erros e menor tempo de aprendizagem. Portanto a usabilidade do sistema são atributos que permitem a intuição do usuário com a interface gráfica, ou seja, são condições na qual um sistema acarreta uma maior facilidade de uso e aprendizagem. Silva Filho (2008, p.24) define o objetivo da usabilidade como sendo para: Identificar atributos da usabilidade e aspectos da interação humanocomputador que podem influenciar a facilidade de uso e aprendizagem de uma aplicação, os quais são determinantes para elevar o desempenho na realização de tarefas e grau de satisfação de usuários. A usabilidade pode determinar também o sucesso ou fracasso de um produto, sendo medido através da satisfação no uso do mesmo. Já os Objetivos de Usabilidade são um conjunto de metas que devem ser atingidas pelo sistema. As metas, mensuráveis, estão relacionadas à eficácia, eficiência, segurança, aprendizagem e memorização do sistema. Após ser definido os requisitos na Engenharia de Sistema é necessário refinalos para compreender melhor o problema e evitar futuramente o retrabalho nos artefatos desenvolvidos e consequentemente cumprindo os prazos e custos previstos. Esse refinamento de requisitos é o principal objetivo há ser realizado na atividade de Análise, compreendendo assim o domínio de informação (que são os dados vindos de usuários finais, de outros sistemas e de dispositivos externos) e o melhor entendimento dos requisitos funcionais e não-funcionais do software. Durante essa atividade são realizadas várias reuniões com o cliente com a intenção de extrair o máximo de informação sobre os requisitos do software. Para uma melhor comunicação pode-se usar representação, protótipos etc. Os métodos de análise mais conhecidos para criar as representações são: Estruturada e Orientada a Objetos. A análise estruturada busca representar as funções do software em modelos estáticos e dinâmicos, onde os modelos estáticos expõem as funções e os dados do software e os modelos dinâmicos mostram o comportamento do software. Um modelo estático muito usado é o Diagrama de Fluxo de Dados, também conhecido de DFD, que torna-se uma ferramenta de modelagem de sistema no qual as funções podem ser básicas ou complexas em relação aos dados manipulados pelo sistema. 17

19 18 Na análise orientada a objetos a base da modelagem são as classes e os objetos com os seguintes métodos mais conhecidos: Técnica de Modelagem de Objeto (do inglês Object-Modeling Technique - OMT) que se apoia nos modelos de objeto, modelo dinâmico e modelo funcional; Engenharia de Software Orientada a Objeto (do inglês Object-Oriented Software Engenharia - OOSE) no qual se fundamenta no conceito de caso de uso; o método proposto por Booch cujo é definido na integração entre microprocessos e um macroprocesso, onde os microprocessos identificam e especificam as classes e os objetos e o macroprocesso utiliza-se de processo tradicional; e por fim o UML que define um conjunto de modelos comportamentais (diagrama de caso de uso), estruturais (diagrama de classes de projeto) que é uma visão estática das definições de classes e de interação (diagrama de sequência) que é uma visão dinâmica de objetos (HIRAMA, 2011, p.75). Antes de iniciar as atividades de codificação é necessário planejar como será desenvolvido o software, para isso precisam ser definidos os módulos funcionais, o detalhamento dos algoritmos e as interfaces entre os módulos, estruturando o sistema e seus atributos com objetivo de estabelecer uma arquitetura de software. Essa atividade definida como Projeto que tem como foco a organização e tomada de decisões com base na estrutura que atenda os requisitos funcionais e não-funcionais do sistema. Para Larman (2005, p.34) a diferença entre as atividades de análise e a de projeto é que na análise enfatiza-se uma investigação do problema e dos requisitos em vez de uma solução, enquanto o projeto apresenta uma solução conceitual que satisfaça os requisitos. Os modelos de arquitetura existentes para documentar as decisões de projeto são: os estáticos de estrutura, que exibe os elementos principais do sistema desenvolvido como unidades separadas; os modelos dinâmicos de processo, que mostram que a estrutura do sistema está organizada em processos; modelo de interface, que estabelece as interfaces de subsistemas; os modelos de relacionamentos, que definem os relacionamentos entre os subsistemas; e os modelos de distribuição, que mostram a distribuição dos subsistemas entre os computadores. As estruturas de arquitetura de sistema mais usadas na atualidade são: o modelo cliente-servidor (indicado quando o sistema fornece um grupo de serviços a

20 clientes ou servidores); os modelos baseados em repositórios (apropriado quando os subsistemas compartilharem uma grande quantidade de dados); e os modelos em camadas, também denominado de modelo de máquina abstrata (usado para modelar as interfaces de subsistemas em camadas). Apos ser definido o modelo e a estrutura de arquitetura do sistema, o próximo passo é a simplificação do sistema em módulos. Segundo Hirama (2011, p.81) um modulo é um componente do sistema que fornece serviços para outro componente, mas não é normalmente considerado como um sistema separado, como é o caso de um subsistema. Essa decomposição geralmente é realizada em duas abordagens: decomposição orientada a objeto, no qual o sistema é decomposto em objetos, e pipelining orientada a funções sendo o sistema decomposto em módulos funcionais. Terminada a atividade de planejamento é iniciada a de codificação no qual a um processo de escrita de um programa denominado código-fonte, com base no projeto especificado nas atividades anteriores, resultando no objetivo principal que é o produto. Sendo o código-fonte traduzido por um compilador gerando um códigoobjeto a ser lincado posteriormente pelo compilador ou outra ferramenta, gerando o código executável. Existem diferentes maneiras de desenvolver software, podemos citar como exemplos: a programação básica em alguma determinada linguagem, programação de banco de dados, scripting, geração de códigos a partir de ferramentas CASE, etc. A atividade de teste é realizada desde o início das atividades de Engenharia de Sistema com a validação de requisitos e durante as atividades de análise com o refinamento dos requisitos evitando retrabalhos futuros, sendo executada também por outras etapas do processo de planejamento e desenvolvimento até o teste do software/produto, ou seja, as atividades de teste ocorrem em cada etapa do processo de software com o propósito de verificar e validar as especificações que foram negociadas com o cliente que se encontram no documento de visão. Sommerville (2007, p.341) define verificação e validação como não sendo a mesma coisa: o papel da verificação envolve verificar se o software está de acordo com suas especificações. Você deve verificar se ele atende aos requisitos funcionais e não-funcionais especificados. Validação, no entanto, é um processo mais geral. A finalidade da validação é assegurar que o sistema de software atenda as especificações do cliente. 19

21 20 Há dois tipos de teste que podem ser realizados durante estágios diferentes no processo de software: o teste de validação, que assegura as especificações desejadas pelo cliente e o teste de defeitos, no qual através de exames de saída do programa podem ser encontradas inconsistências entre o programa e suas especificações. No entanto, não existe barreira entre estes dois tipos de testes, pois durante os testes de validação pode ser encontrado defeito no sistema ou durante os testes de defeitos o programa pode se mostrar não atender os requisitos estabelecidos. Os testes devem ser conduzidos por meio de um plano de teste que é desenvolvido pelo gerente de projeto, engenheiros de software e especialistas em testes; já a sua execução é realizada pelos membros da equipe de desenvolvimento e o próprio usuário do sistema. Encontrado o defeito no sistema, seja ele de verificação ou validação, é necessária a correção para sua revalidação. Sendo preciso iniciar novos testes para assegurar que as mudanças não gerarão novos defeitos. 4.2 PROCESSOS DE SOFTWARE O dicionário Michaelis define processo como sendo uma série de ações sistemáticas visando a certo resultado. Na Engenharia de Software o processo está relacionado a um conjunto de atividades associadas para alcançar um objetivo durante o período do ciclo de vida de um produto, que se encontra entre a concepção e desativação de um software. Processos de Software estabelecem um plano para os membros da equipe de projeto, no decorrer das atividades de produção de um software, o que se foi decidido para atender aos objetivos do software. Pressman (2006, p.16) nos da importância do processo na elaboração de um produto ou sistema com a seguinte afirmação: o processo fornece estabilidade, controle e organização para uma atividade que pode, se deixada sem controle, torna-se bastante caótico. Há vários processos a serem adotados em um desenvolvimento dependendo do tipo de software a ser produzido, por exemplo, sistemas críticos é necessário em um processo bem estruturado. Um outro exemplo são os sistemas de negócios que utilizam-se de processos ágeis e flexíveis. Lembrando que existem atividades fundamentais no desenvolvimento do software, independente do processo, que são

22 corriqueiras, como: as especificações, projetos, implementação, validação e evolução do software, podendo ser apoiadas por ferramentas CASE Processo em Cascata O processo em Cascata, também conhecido como Waterfall Model, é um modelo clássico que foi muito usado entre as décadas de 1970 e 1980 em projetos de grande porte, composto de um conjunto de atividades (Engenharia de Sistema, Análise, Projeto, Codificação, Testes e Manutenção). Suas principais características são: seguir uma disciplina de sequência das atividades, ou seja, precisa ser respeitada uma sequência lógica de desenvolvimento; a atividade seguinte não deve ser iniciada sem que a anterior tenha sido encerrada, garantindo assim uma segurança para a realização dessa atividade; e o cliente/usuário somente deverá ser incluído no início e no fim do processo. O processo em cascata pode ser visto na Figura 01. Engenharia de Sistema Figura 01 - Processo em cascata Análise Projeto Codificação Teste Manutenção Fonte: Elaborado pelo autor A etapa de Engenharia de Sistema tem por propósito compreender as necessidades de negócios do cliente e os requisitos definidos em alto nível, tendo como saída o documento de Especificação de Sistema. Na atividade de Análise os requisitos de software são definidos detalhadamente evitando erros de assimilação do que o cliente pediu durante as negociações. O documento de saída desta atividade é uma Especificação de Requisitos de Software. No Projeto de software são determinados detalhes de procedimento, a

23 22 arquitetura do software, a estrutura de dados e a interface, gerando as Especificações de Projetos. A atividade de Codificação ou Implementação consiste na transformação dos requisitos acordados nas atividades de Engenharia de Sistema e Análise em código de máquina. A saída desta atividade é o produto em si e a Listagem de Programas. Nas atividades de Teste busca-se descobrir defeitos no software, seja esses erros de aspecto estrutural ou lógicos, gerando relatórios de teste para a etapa seguinte. Na manutenção são feitos os reparos no software com relação aos defeitos encontrados ou mudanças no programa decorrentes as novas necessidades de negócios. Além dos Relatórios de Manutenção são realizadas mudanças no Documento de Especificações do Sistema. Podemos ver que esse modelo tem como um dos pontos fortes a geração de documentos no decorrer de todas as atividades. Já seu ponto fraco se encontra nas mudanças do software, pois essas só serão executadas na etapa final das atividades Processo Evolutivo O Processo Cascata não adequa-se as novas mudanças exigidas pelo mercado, por ser um processo desenvolvido linearmente e sequencialmente e por focar-se na entrega de um sistema completo somente no final de todo processo. Para atender a esse mercado que cada vez exige mais em qualidade e produtividade surgiram os processos ágeis. Um dos primeiros processos ágeis que surgiram foi o Evolutivo conhecido também por processo Espiral, modelo nascido da necessidade de alteração dos requisitos de negócios durante o processo de desenvolvimento do software, das pressões por prazos mais curtos de entrega e da concorrência de mercado. Para isso esse modelo desenvolve e incrementa gradualmente os requisitos do produto em subpartes, ou seja, o modelo Evolutivo é iterativo sendo produzido em série de versões incrementais do software. A cada incremento será entregue uma versão do software ao cliente para ser avaliada, melhorando assim a qualidade final do software.

24 23 Figura 02 - Processo Espiral Planejamento Comunicação do cliente Análise de risco Avaliação do cliente Engenharia Fonte: Adaptado de (HIRAMA, 2011, p.32) Na Figura 02 é observado que o Processo Espiral se inicia do centro em sentido horário e a cada volta concluída corresponde a uma iteração que é terminada com a avaliação do cliente, iniciando-se a próxima com a entrega da versão incrementada do software. Nas iterações avançadas teremos versões mais completas do software. As principais características desse modelo são: agregação de novos recursos na medida que as necessidades vão sendo descobertas, diminuição dos riscos antes do incio do desenvolvimento com a análise de riscos verificando a viabilidade do projeto a cada progressão e o envolvimento do cliente no início e no final de cada iteração. Um ponto fraco no Processo Evolutivo é a dificuldade em saber se o número de iterações pode ser prevista e controlada, tornando um pouco imprecisos os custos, os prazos e os recursos estimados no início do projeto. O ponto forte está na melhoria da qualidade do produto. Construção e entrega Métodos Ágeis Práticas que envolvem iteração, evolução, planejamento adaptativo e entrega incremental em desenvolvimento de software são atitudes aplicadas aos métodos ágeis. Essas práticas foram propostas na década de 1980 e início da década 1990 com objetivo de evitar o overhead (qualquer processamento ou armazenamento em excesso) em projetos de pequeno porte durante o uso de processos tradicionais utilizados naquela época. Ao utilizar o Processo Cascata, por exemplo, em projetos

25 de pequeno e médio porte, o overhead ocorre no planejamento e na documentação do sistema, ou seja, a maior parte do tempo gasto no projeto acontecerá na preparação e planejamento do projeto e na elaboração dos documentos do que no desenvolvimento do programa e em correções. Sommerville(2007, p.262) descreve os métodos ágeis como sendo: Uma abordagem interativa para especificação, desenvolvimento e entrega de software, e foram criados principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Assim os métodos ágeis proporcionam uma entrega mais rápida ao cliente, já que podem sugerir novas alterações a serem incluídas nas próximas iterações. Além de serem baseados em noções de desenvolvimento e entrega incrementais, os métodos ágeis compartilham os seguintes princípios: envolvimento do cliente, entrega incremental, pessoas (habilidades devem ser reconhecidas e exploradas), aceitação de mudanças, e manter a simplicidade. Os métodos ágeis só são apropriados para o desenvolvimento de sistemas de pequenas e médias empresas, não devem ser usados em sistema de larga escala com equipes de desenvolvimento em lugares diferentes e iterações complexas com outros sistemas, pois poderá dificultar seu gerenciamento, muito menos no desenvolvimento de sistemas críticos nas quais necessitem de uma análise detalhada dos requisitos que envolvam a segurança dos mesmos Processo Unificado Para métodos orientados a objetos foi proposto o Processo Unificado com adoção da notação de modelagem UML, tendo como principais características: a centralização na arquitetura (fases e fluxos de trabalho), de ser dirigida por casos de uso (é um método para especificar uma função do software na perspectiva de visão do usuário) e de ser iterativo e incremental. Um processo derivado do Processo Unificado desenvolvido pela IBM/Rational é o RUP (Rational Unified Process). As fases do Processo Unificado são: a Concepção no qual é responsável pela definição e visão inicial do sistema do aspecto de negócios do cliente; a Elaboração, fase em que são especificados em detalhes com a utilização do UML os casos de usos e a arquitetura do sistema (elementos estruturais e comportamentais), também

26 25 é desenvolvido um projeto detalhado das atividades e recursos requeridos para realização da fase de construção; onde é produzida literalmente a versão operacional do produto contendo todos os casos de uso acordados durante a fase de Concepção; e, por fim, temos a fase de transição na qual o produto é colocado em execução para um grupo de usuários a procura de correções e sugestões de melhorias, gerando um produto final a ser usado por um número maior de usuários. O Objetivo das fases é formar divisões gerenciais para atingir metas bem definidas. Os fluxos de trabalho são atividades divididas em conjunto de tarefas realizadas de acordo com o plano de iteração, resultando na entrega do produto trabalhado que são produzidas durante a conclusão bem-sucedida dessas tarefas. Os fluxos no Processo Unificado são: Requisitos (levantamento e análise de negócio), Análise e Projeto (detalhamento dos requisitos e arquitetura), Implementação (codificação) e Teste. Um das vantagens do Processo Unificado em relação ao Processo Evolutivo é de se desprender das fases com os fluxos de trabalho que podem ser ativados em todos os estágios do processo. Uma outra vantagem está na organização, pois é mais fácil reconhecer as ordens de execução e os limites das atividades (início e fim), ou seja, devido o processo ser considerado um modelo híbrido do ponto de vista dinâmico (fase) e estático (fluxos de trabalho) estas atividades são mais diferenciadas do que no Processo Cascata onde estas duas perspectivas de visão se confundem em uma forma única Processo Extreme Programming Um dos processos mais conhecidos e usados entre os métodos ágeis, o Extreme Programming ou simplesmente XP usa uma aproximação do modelo orientado a objeto em seu desenvolvimento com práticas de desenvolvimento iterativo e o máximo envolvimento do cliente no processo, passando a ser parte integrante da equipe. As atividades que sustentam o conjunto de regras e as boas práticas de desenvolvimento no processo XP são: planejamento, projeto, codificação e teste. A atividade de planejamento inicia-se com a criação de história dos usuários (que são os requisitos expressos em cenários), onde cada história é escrita pelo cliente e dada um valor de prioridade conforme o plano de negócio ou de função

27 26 para serem avaliadas pelos membros da equipe XP em relação aos custos e tempo de desenvolvimento. É importante ressaltar que novas histórias podem ser introduzidas pelo cliente a qualquer momento, podendo também subdividir uma história ou alterar seu valor de prioridade ou elimina-las. As histórias são agrupadas de acordo com o compromisso básico para o desenvolvimento da versão (data de entrega ou outros motivos de projetos) podendo ser todas as histórias implementadas imediatamente ou priorizar implementação das histórias com maior valor ou de maior risco. Na atividade de projeto no XP adota-se o princípio KIS (keep it simple mantenha a simplicidade) implementando as histórias como estão escritas, para isso são usados os cartões CRC (Class-Responsibility-Colaborator) como um meio de refletir sobre o software no contexto orientado a objeto, identificando e organizando as classes orientadas a objeto. Quando é encontrado um problema de projeto é criado de imediato um protótipo operacional, denominado também de solução de ponta, que implementa e avalia a parte do projeto problemático com a intenção de diminuir os riscos quando a implementação da versão do software realmente for iniciada. Lembrando que o projeto ocorre tanto antes quanto depois da codificação. Uma outra técnica que pode ser usada no projeto XP é a refabricação, que aperfeiçoa a estrutura interna do código ou projeto sem alterar o comportamento externo, ou seja, simplifica o projeto interno minimizando possíveis erros. Durante as atividades de codificação é recomendado que duas pessoas trabalhem juntas em um mesmo computador, também conhecida como programação em pares; pode fornecer soluções mais rápidas para problemas encontrados nos testes unitários. Os testes unitários acontecem antes da implementação do código com o estudo de cada uma das histórias a serem incrementadas no software. Apos o código ser finalizado pelos pares de programadores haverá a integração do trabalho dos outros, podendo ser realizada por uma equipe de integração ou pares de programadores diariamente. Além dos testes unitários citados acima são realizados também os testes de integração e validação do sistema, podendo ser feitos todos os dias. Um outro teste é feito pelo cliente chamado de teste de aceitação com o objetivo de evidenciar as características e funcionalidades implementadas na versão do software que foram especificadas nas histórias dos usuários. O XP é indicado para desenvolvimento de aplicações de pequeno porte, como

28 software de vendas e aplicações voltadas para ambiente web, não sendo indicado para sistemas complexos de grande porte ou críticos Processo easyprocess O easyprocess foi idealizado pela professora Drª Francilene Procópio Garcia da Universidade Federal de Campina Grande (UFCG) que é apresentado no tutorial PET/UFCG (2007), com o propósito de se utilizar as melhores práticas de desenvolvimento de software no ambiente acadêmico ou que seja usado em projetos de pequeno e médio porte em empresas. O YP, como também é conhecido o easyprocess, é apoiado pelas boas práticas do XP, RUP e Agile Modeling, tornando-se um processo simplificado, iterativo e incremental. O YP foi desenvolvido por três grupos de estudos, sendo dividido para os processos XP, RUP e Agile Modeling, com o objetivo de se extrair o melhor desses processos. As atividades do processo YP se iniciam pela definição de papeis onde são divididas as tarefas entre os membros da equipe de desenvolvimento, lembrando que o cliente e o usuário também são membro desta equipe, pois a presença ativa dos dois é de grande importância para o sucesso do produto final. É recomendada a existência de cinco papeis: cliente, usuário, gerente, desenvolvedor e testador. Podendo uma pessoa exercer vários papéis em determinada parte do processo, mas deve-se evitar o acúmulo de papéis para que não haja uma sobrecarga de responsabilidade sobre essa pessoa e que a produtividade dessa não seja comprometida. As principais responsabilidades do cliente são: definir os requisitos do sistema, priorizar as funcionalidades, ajudar na elaboração do plano de releases, explicitar os testes de aceitação, identificar o perfil do usuário, identificar os objetivos de usabilidade, validar o projeto arquitetural e ser ativo no processo de desenvolvimento do sistema. A responsabilidade para o usuário (que é quem utilizará o sistema pronto e pode ser o próprio cliente) é de: ajudar a definir os testes de aceitação, ajudar a identificar os objetivos de usabilidade, validar o protótipo da interface e avaliar continuamente a interface do sistema. O gerente é responsável por gerenciar e coordenar as atividades de desenvolvimento, possuindo as seguintes competências: conduzir os planejamentos

29 28 e as ações dos desenvolvedores, elaborar o plano de desenvolvimento (release e iteração), avaliar sistematicamente os riscos descobertos, gerenciar configurações, coletar e analisar métricas, alocar testadores, presidir as reuniões de acompanhamento, resolver conflitos internos e tornar a documentação do projeto atualizado e acessível. Além de modelar os requisitos do sistema, codificar e fazer os testes relativos ao código produzido, o desenvolvedor tem as seguintes responsabilidades: levantar os requisitos funcionais e não funcionais, auxiliar o gerente na elaboração de um plano de desenvolvimento, analisar e modelar a tarefa, gerar um protótipo da interface, identificar os objetivos de usabilidade, gerar testes de unidade, elaborar o projeto arquitetural, construir o modelo lógico de dados e manter a integração contínua de código. O testador é responsável por efetuar as seguintes funções: revisar o código de outro desenvolvedor, elaborar testes sobre o código gerado pelos outros desenvolvedores, refatoramento de código, gerar testes de aceitação definidos pelo cliente, elaborar o material para realizar os testes de usabilidade e realizar os testes de usabilidade junto com o usuário. Após a definição de papeis é realizada a primeira conversa com o cliente, onde são reunidas as informações iniciais sobre o sistema com o objetivo de se entender melhor o escopo do problema. O desenvolvedor nesse momento deve obter a maior quantidade de informações possível sobre o sistema, informações essas relacionadas a funcionalidades do sistema (requisitos funcionais e não funcionais), ao perfil do usuário, aos testes de aceitação e aos objetivos usabilidade. No término da conversa a equipe de desenvolvimento deve compreender bem o escopo do problema, saber quais são os requisitos funcionais e não funcionais, conhecer o perfil dos usuários e saber quais as dificuldades e riscos envolve o projeto. O Documento de Visão é um artefato criado logo após o término da conversa com o cliente, com finalidade de conter as ideias gerais a respeito do que o sistema pretende fazer, documentando suas características gerais (requisitos, perfil de usuário, objetivo de usabilidade, entre outros) para ser validado junto com o cliente, fechando assim o acordo de negócio entre o cliente e desenvolvedor. O próximo passo após o entendimento da ideia geral a respeito do problema proposto pelo cliente é a de inicialização que tem o conjunto de 5 atividades que

30 29 são: modelagem da tarefa, definição das User Stories (estória de uso) e Testes de Aceitação, geração do Protótipo da Interface, elaboração do Projeto Arquitetural e a construção de um Modelo Lógico de Dados (caso exista um banco de dados). Cada atividade deve ser executada na ordem apresentada acima, devido que a atividade seguinte depende do artefato gerado pelas atividades em execução. O modelo de tarefa tem o objetivo de entender a execução de uma tarefa pelo usuário ao interagir com a interface do sistema, e também, auxiliar no desenvolvimento do protótipo da interface e elaborar o roteiro de atividades para a realização dos testes de usabilidade. Sendo essa atividade auxiliada por uma ferramenta de formalismo TAOS (Task and Action Oriented System) na construção do modelo de tarefa. As atividades de User Stories e a elaboração dos Testes de Aceitação são realizadas pelo cliente que especificará as funcionalidades do sistema definindo assim o que o mesmo deve ter ou fazer, ou seja, o cliente deve definir e priorizar as User Stories para ordenar a implementação das funções do sistema e elaborar os Testes de Aceitação que serve de auxílio para o desenvolvedor analisar o modelo da tarefa. Para cada User Stories há, pelo menos, um Teste de Aceitação. A geração do protótipo da interface deve ser uma demonstração gráfica, não operacional, possibilitando a compreensão do cenário referente ao uso, aspectos de navegação, interação, operacional e estético do sistema. O projeto arquitetural especifica o funcionamento do sistema em um nível alto de abstração, sendo útil na demonstração de como partes do sistema interagem entre si ou com outro sistema. Ele deve ser estruturado na forma de um diagrama para que possa esclarecer as possíveis dependências e relacionamentos entre os módulos do sistema ou entre outros sistemas. Após a sua elaboração o cliente deve validar a arquitetura definida. A próxima etapa após a conclusão das atividades de inicialização é o planejamento do projeto que tem a finalidade de organizar e programar as atividades em um tempo determinado para o desenvolvimento do sistema. Sendo formado pelo plano de release e o plano de iteração, cujo o planejamento é geralmente dividido em 3 releases, cada um contendo 2 iterações de 2 semanas. O plano de release define o tempo dos releases, com as User Stories e os testes de aceitação incorporados em cada uma delas, e então é divido em iterações. Devemos ressaltar que o tempo de releases e iterações são fixos, já a quantidade

31 30 de User Stories é que varia. Por isso é que no início do planejamento é fixado o tempo para o desenvolvimento do projeto e com o cliente define o número de releases e iterações. No plano de iterações se quebram, se necessário, as User Stories em atividades menores e designa aos membros da equipe de desenvolvimento como responsáveis pela execução de cada tarefa. Essa escolha pode ser realizada com a ajuda da matriz de competência que mapeia as aptidões de cada membro e determina junto com o cliente o número e o tempo de releases e iterações que cada um tem para concluir os mesmos. O tutorial do YP recomenda o uso da Tabela de Alocação de Atividades (TAA), para listar todas as atividades e determinar o tempo de desenvolvimento de cada uma delas junto com seu responsável. A implementação do sistema ocorre durante as atividades fixadas no plano de iteração e sua principal saída é o código do sistema. O YP sugere algumas práticas para alcançar um bom resultado na implementação, como: integração contínua, boas práticas de codificação (como design simples, padrões de codificação, padrões de projeto e refatoramento), propriedade coletiva de código, teste e pequenos releases. Como a implementação está incorporada com a atividade de iteração seu tempo depende da duração destas atividades. Para algumas práticas é necessário que tenha um controle de versões para que se evite problemas de conflitos em partes do código alterado por outro membro da equipe. Os testes servem para assegurar que todos os requisitos do sistema foram implementados sem erros. Para garantir a qualidade do sistema e a satisfação do cliente/usuário é preciso testar o sistema sob diversas características (funcionalidade, carga, desempenho, usabilidade, controle de acesso, etc.), sendo que o YP recomenda a realização dos testes de unidade, de aceitação e de usabilidade. O êxito funcional do sistema depende da exaustiva bateria de testes realizadas sob as implementações associadas a suas respectivas user story. A reunião de acompanhamento objetiva avaliar cuidadosamente os resultados métricos alcançado deste o início da implementação até o instante atual e deve acontecer semanalmente. A equipe de desenvolvimento deve participar das reuniões, sendo essas reuniões coordenada pelo gerente de projeto. Durante as

32 31 reuniões são discutidas as situações vivenciadas a cada membro em volta de sua produtividade. Para avaliar os resultados são aconselhadas a utilização do Big Chart (análise quantitativa do projeto) e da Tabela de Alocação de Atividades (TAA). O YP recomenta que seja levantado durante a reunião as possíveis mudanças relativa ao projeto e uma análise de riscos, como também a necessidade clara de refatoramento do código. Essas reuniões servem para apontar falhas no andamento do projeto, minimizando os custos envolvidos no projeto tanto para a equipe de desenvolvimento com para o cliente. 4.3 QUALITY OF SERVICE QoS do inglês Quality of Service (qualidade de serviço) determina o tráfego de uma rede através de regras de prioridades e limites, melhorando a qualidade de serviços ou aplicações em um ambiente computacional. O uso do QoS é necessário em alguns serviços para garantir seu bom funcionamento em uma rede, evitando assim problemas como congestionamento e atrasos no tráfego desses serviços, problemas esses que podem ocasionar a perda de pacotes. Sousa (2005, p.13) define QoS como sendo algum método ou serviço que proporcione uma diferenciação de tráfego aplicando-se alguns parâmetros de qualidade de forma a oferecer garantias de desempenho à rede. De acordo com alguns autores os parâmetros de processo que mais afetam a transmissão de dados em serviço que necessita de estabilidade no tráfego são: Largura de banda (taxa máxima de transmissão de dados que suporta uma conexão), Atraso (tempo que um pacote leva para percorrer entre o emissor e o receptor), Jitter (é a variação do atraso entre pacotes distintos de uma transmissão) e Perdas (número de pacotes que não chegaram ao seu destino em um certo período de tempo). O modelo QoS padrão em uma rede TCP/IP (Transmission Control Protocol Internet Protocol / Protocolo de Controle de Transmissão Protocolo Interconexão) é o BE (Best Effort), conhecido também como método de melhor esforço, baseia-se em receber todos os fluxos de dados que foram enviados ao mesmo tempo e seja a compartilhar a uma largura de banda. Melhor explicando, o nosso tráfego é enviado

33 32 para a internet, e nos roteadores existentes que usam o algoritmo BE, a largura de banda é compartilhada entre todo o tráfego que chega. Em caso de congestionamento, os pacotes são descartados sem qualquer critério ou distinção, o que não garante na realidade que um determinado serviço seja bem-sucedido (STATO FILHO, 2009, p.189) Métodos de implementação Em um roteador com 2 interfaces de rede, uma para a internet outra para a rede interna, o QoS pode ser possível através da (re)transmissão de pacotes para a internet ou para a rede interna, ou através da rejeição ou atraso dos pacotes vindas da internet ou da rede interna. Sendo esses últimos o padrão usado no Linux limitando-se a descartar pacotes. É recomendado que o rodeador não execute nenhum serviço. Os métodos para implementação do QoS mais conhecidos são o IntServ (Serviços Integrados) e o DiffServ (Serviços Diferenciados). Esses métodos foram especificados pela IETF (Internet Enginnering Task Force) com o objetivo de regulamentar e criar um padrão de fornecimento de QoS. O IntServ é caracterizado pela reserva de recursos para um serviço, no qual essa alocação de recursos prepara o caminho para que o serviço trabalhe de forma eficiente. Basicamente, um serviço ou aplicação que necessite de garantias fará reservas individuais para guardar recursos e rotas antecipadamente, de forma que a aplicação, quando enviar os pacotes na rede, tenha um fluxo contínuo e a garantia do uso dos recursos, tais como banda, velocidade, etc (STATO FILHO, 2009, p.189). Os serviços Integrados são estruturados pelo RSVP (Resource reservation Protocol - Protocolo de Reserva de Recurso) e definidos pela RFC 1633; e os modelos de reserva utilizados são o serviço garantido e o serviço de carga controlada. Onde o serviço garantido assegura uma reserva de largura de banda, disponibilizando também uma proteção contra a perda de pacotes que se encontrarem nos limites do tráfego contratado, sendo destinado a aplicações em tempo real. Já o serviço de carga controlada é parecido com o serviço de melhor esforço tendo como garantia pouca perda de pacotes e um valor mínimo de atraso (jitter). O maior problema encontrado no IntServ é a sua limitação na escalabilidade,

34 33 não suportando redes de grande porte. Para resolver esse problema a IETF propôs uma arquitetura de serviços diferenciados (DiffServ) direcionados para disponibilizar QoS a internet (SOUSA, 2005, p.23). Ao contrário do IntServ, o DiffServ não faz reserva de recurso, ele faz a agregação de fluxo em classes chamadas de Behavior Aggregate (BA), possibilitando uma maior escalabilidade. Onde o pacote que for integrado a uma classe será marcado e classificado no campo conhecido como TOS (Type Of Service nas redes IPv4, atualmente o campo DSCP DiffServ Code Point), em seu cabeçalho IP. Essa marcação ocorre nos roteadores de borda, onde haverá um acordo entre os dois pontos determinando quais classes serão suportadas e a taxa de banda que estará livre, no caso de ser implantado em uma nuvem DiffServ, além dos roteadores de borda existem os roteadores de núcleo que serão responsáveis por escalonar e gerenciar as filas. O serviço DiffServ fornecido por uma rede por meio de um Contrato de Nível de Serviço (SLA Service Level Agreements) é chamado de Domínio DS e o procedimento realizado pelos roteadores de núcleo é denominado de comportamento de salto (PHB Per Hop Behavior) que classifica o tráfego para tratamento em fila. O PHB descreve como será o tratamento de encaminhamento que cada pacote receberá por router que passar. O campo marcado DSCP informa aos roteadores como mapear o tráfego para uma determinada classe. E cada classe terá um PHB específico (STATO FILHO, 2009, p.191). A arquitetura lógica DiffServ é formada pela concatenação de vários Domínios DS na qual os SLA s são negociados em cada um dos nós DS entre os domínios existentes. Para estabelecer uma SLA na qual são estabelecidos parâmetros de vazão, perdas e atrasos, os usuários não negociam diretamente com o domínio final (a não ser que sejam adjacentes), eles negociam com o mais próximo Domínio DS até chegar o domínio final. Essa arquitetura somente provê a diferenciação de serviços em única direção do fluxo, tornando os nós de borda, ora nós de ingresso ora de regresso, sendo portanto assimétrico (SOUSA, 2005, p.25). Existem atualmente dois tipos de PHB padronizado pela IETF para a implementação do DiffServ: o EF (Expedited Forwarding Encaminhamento Expresso) e o AF (Assured Forwarding Encaminhamento Assegurado). O PHB EF é usado em aplicações que necessitam de rapidez, transmissão

35 34 constante, segurança e uma taxa de erro mínima de transmissão, pois oferece baixa perda, baixo retardo, banda passante assegurada e baixa variação de retardo (jitter). Por padrão o PHB utiliza a classe EF com valor no campo DSCP. No PHB AF é assegurada a entrega de pacotes por prioridade com uma largura de banda garantida em quatro classes de transmissão e em três níveis de precedência de descarte (Drop Precedence), só que não oferece garantia enquanto ao atraso. Precedência de Descarte Quadro 01 Tabela de Precedência Classe AF1 Classe AF2 Classe AF3 Classe AF4 Binário Decimal Binário Decimal Binário Decimal Binário Decimal Baixa Media Alta Fonte: Adaptado de (STATO FILHO, 2009, p.271) Os três primeiros bits do DSCP identificam a classe e os três últimos identificam a precedência de descarte. Ainda podemos observar no Quadro 01 que se houver um congestionamento e tiver que descartar pacotes de uma mesma classe, o PHB AF dará precedência de descarte ao de maior valor Ferramenta Iptables O Iptables é uma ferramenta front-end que permite o controle das situações (chains) contidas nas tabelas do Netfilter. Neto(2004, p19) define o Netfilter como sendo um software agregado ao Kernel do Linux com a função de controlar o fluxo interno de dados. As tabelas padrões do Netfilter são: Filter, NAT(Network Address Translation) e Mangle. No qual cada uma delas policia regras direcionadas a seus objetivos básicos. A tabela Filter aplica-se a regras de filtro de pacotes, já a NAT as direciona e a tabela Mangle faz um tratamento de pacotes. Todas as tabelas contem situações de fluxo como saída, entrada, redirecionamento e etc, permitindo-os a realização de seus objetivos (NETO, 2004, p.19). As situações das tabelas padrões do Netfilter são apresentadas abaixo: Tabela Filter INPUT (pacote que entra no host), FORWARD (pacotes que são redirecionados ou encaminhados pelo kernel) e OUTPUT (pacote enviado do host);

36 35 Tabela NAT PREROUTING (pacote que está entrando no host antes de sofrer roteamento), OUTPUT (pacote emitidos pelo host com endereços alterados) e POSTROUTING (pacote que sai do host após o tratamento de roteamento); Tabela Mangle - PREROUTING (pacote modificado com tratamento especial antes de sofrer roteamento) e OUTPUT (pacote alterado localmente antes de sair do host). A manipulação das regras no Netfilter é feita através dos comandos do Iptables no qual essas regras podem ser inseridas, deletadas, editadas, etc. Os parâmetros genéricos do Iptables para se criar uma regra são definidos pela escolha da tabela a ser usada, do comando a ser usado (inserir, deletar, etc), da ação e do alvo. A opção de comandos são: -I (adiciona uma nova regra no início da lista), -A (adiciona uma nova regra no final da lista), -D (apaga uma regra específica), -L(lista regras existentes na lista), -P (altera a politica padrão), -F (remove todas as regras da lista), -R (substitui uma regra já existente), -Z (zera o contador de pacotes e bytes), -N (cria uma nova condição a uma tabela especificada), -E (renomeia uma condição criada pelo usuário) e -X(apaga uma condição criada pelo usuário). Já as ações especificam o protocolo (parâmetro -p), a interface de rede que entra ou sai o pacote (parâmetro -i ou -o, respectivamente), a origem (-s) ou o destino (-d) do pacote e o alvo (-j) a ser usado. Essas são as ações mais utilizadas no comando Iptables, outras ações podem ser vistas em seu manual de ajuda. Os alvos ou target aplicado as regras são: ACCEPT aceita a entrada/passagem do pacote pelo host; DROP bloqueia a entrada/passagem do pacote pelo host sem avisar a origem de seu descarte; REJECT rejeita o pacote, só que ao contrário do DROP há um retorno de erro ao host que o enviou; LOG cria um registro de log em um arquivo; RETURN retorna o processamento para a condição(chain) anterior; QUEUE carrega o programa a nível do usuário processando o fluxo referente ao mesmo; SNAT altera o endereço de origem dos host antes dos pacotes serem

37 36 roteados; DNAT altera o destino dos host; REDIRECT redireciona uma porta em conjunto com a opção --to-port; TOS prioriza a entrada ou saída de um pacote. Na expressão 4.1 temos um exemplo do comando iptables, onde a regra prioriza o tráfego de saída com destino a um serviço SSH. #Iptables -t mangle -A OUTPUT -o eth0 -p tcp dport 22 -j TOS set-tos 16 (4.1) Esta regra modifica o cabeçalho do pacote que está saindo do host alterando o valor de prioridade padrão 0 para o valor de espera miníma 16. O comando é formado pelos parâmetros -t mangle que determinam a tabela a ser manipulada, -A refere-se ao comando de inserção de regras no início da tabela; já as opções -o eth0 -p tcp dport 22 -j são um filtro de ações que um tráfego pode se aplicar sobre essa regra, ou seja, o pacote se será modificado se ele estiver saindo da interface de rede eth0 utilizando o protocolo tcp com destino a porta 22, a opção -j define o alvo que se encaixa nessa regra, e por último o alvo TOS set-tos 16 que modificará a prioridade do pacote Ferramenta TC O QoS pode ser implementado em roteadores que disponibilizem deste recurso ou em estações que proporcionem tal fim. Essa última opção podemos dar como exemplo o sistema operacional Linux que oferece uma disciplina de enfileiramento (qdisc Queuing Disciplines) em seu kernel manipulando o QoS através da ferramenta tc (Traffic Control) que faz parte do pacote iproute2. O qdisc controla o tráfego de saída de um determinado gateway. Os quatro elementos principais da ferramenta tc são: qdisc, classes, filters e policers. Esses elementos possibilitam o tratamento dos dados, limitando ou priorizando esses dados, tornando o tráfego da rede mais fluente para determinadas aplicações.

38 37 Os escalonadores são os principais componentes do controle de tráfego do Linux, onde são conhecidos como qdisc (queueing discipline), ou disciplina de enfileiramento, cujo próprio nome faz menção à sua funcionalidade de tratar a ordem em que os pacotes em sua entrada devem aparecer em sua saída (SANTOS, 2010, p.31). No Linux a duas categorias para dividir os vários tipos de fila no qdisc: classful e o classless. As classful são capazes de passar a ter outros elementos internamente como classes, filtros e outros qdisc, permitindo que contenham subclasses e que o administrador possa defini-las; enquanto a classless não permite a adição de outros elementos, assim não é permitido o conteúdo de classes definidas pelo administrador. Os escalonadores classless contidos no kernel do Linux são: FIFO First In First Out (pacotes - PFIFO e byte BFIFO); SFQ Stochastic Fair Queuing; TBF Token Bucket Filter; RED Random Early Detection; GRED Generic Randon Early Detection; DSMARK Differentiated Service Marker. Os escalonadores GRED e DSMARK são classificados também como classful. Para os escalonadores classful demos: PRIO Priority Queuing; CBQ Class Based Queue; HTB Hierarchical Token Bucket. As classes são elementos responsáveis por fazer um tratamento diferenciado a um específico fluxo de dados, classificando os pacotes e dividindo o tráfego. Stato Filho (2009, p.196) afirma que: Classes são responsáveis por classificar os pacotes, é a forma como vamos controlar o tráfego, dividir as partes que deveram ser usadas por determinados pacotes. Ela é associada ao qdisc, pois para a manipulação dos pacotes, temos que ter um qdisc e escolher que tipo de qdisc que estaremos usando, e então, se for o caso, criaremos classes para trabalhar com a qdisc.

39 As classes são organizadas em árvores nos escalonadores do tipo classful, podendo se ramificar em outras classes denominadas de filhas, e quando essas classes filhas não possuírem outras filhas, então serão nomeadas de folha. Santos (2010, p.32) explica que: Quando uma nova classe é criada, um escalonador do tipo FIFO é imediatamente associado a ela, mas se para essa classe for criada uma outra classe como filha, esse escalonador será automaticamente removido, passando a existir apenas na nova classe folha, o ponto final da hierarquia. Filtros são responsáveis por identificar, classificar e distribuir o pacote para dentro de um enfileiramento qdisc classful, isso é feito com um auxílio de um classificador que tem a função de identificar padrões nos pacotes e fluxos para subsequentemente fazer a separação em classes. No tc os filtros mais conhecidos para fazer o controle de tráfego são: o u32, considerado o principal filtro por identificar os padrões em qualquer parte de um pacote IP, o route que toma como base as rotas de origem e destino de um pacote, o fw onde seu parecer é baseado em marcações prévias do netfilter(modulo agregado ao kernel do linux para tratar um determinado fluxo de dados de uma rede) e o TCINDEX baseia nas marcações de identificação preparativas de um escalonador DSMARK. A ainda outros como protocol, parent, prio, rsvp e handle. O policiamento está associado aos filtros delimitando o tráfego anteriormente definido, ou seja, é o mecanismo para o qual o tráfego não ultrapasse o consumo de banda destinado a ele. No policiamento são determinadas regras que se apliquem a determinados valores de uma classe, se um pacote infringir essa regra, poderá ser dropado (negado), reclassificado ou permitido. Seu uso é muito comum na entrada de roteadores de borda, evitando o consumo de banda dentro do domínio DiffServ. Quanto ocorre um aumento de volume de tráfego superior ao valor limite determinado em uma classe, é chamado de overlimit. As ações para ser aplicadas a um filtro que se encontra em overlimit podem ser: Drop - no qual os pacotes serão descartados; Reclassify - onde os pacotes excedentes são direcionados para o tráfego da classe padrão (o de melhor esforço); Continue permite que os pacotes sejam testados por outros filtros, mas não pelo filtro que o parou por exceder o limite, permitindo assim que estes pacotes sejam classificados; 38

40 Pass - faz com que os filtros continuem a classificar os pacotes normalmente. 39 O comando para manipularmos as qdisc, classes e filtros utilizando a ferramenta tc obedece o seguinte estrutura padrão: tc [ format ] [ objeto ] [ opção ] [ dispositivo ] [ parâmetro ] (4.2) No qual o format no comando tc é -s de statistics ou -d de details ou -r de raw. Para os objetos no comando tc são utilizados qdisc, class e filter, podendo esses objetos serem executados com as opções add (adicionar), change (alterar), del (deletar) e show (visualizar). O dispositivo é a interface de rede utilizada: wlan0, eth0, ppp0, etc. A sintaxe de policiamento para ser adicionada dentro do comando tc filter é: police [ regra TBF ] [ações] (4.3) Onde as regras TBF (Token Bucket Filter) poderão utilizar dos parâmetros rate, burst, buffer, maxburst, mtu, minburst e mpu. Vamos a um exemplo utilizando o comando tc qdisc para o algoritmo HTB visto na expressão 4.4: #tc qdisc add dev eth0 root handle 1:0 htb (4.4) Estamos adicionando uma disciplina de enfileiramento no dispositivo eth0, onde root significa que é a qdisc raiz, ou seja, no caso de trabalhar com escalonadores do tipo classful essa seria a primeira qdisc (processo-pai) para posteriormente adicionar outras qdisc (processos-filhos) e classes (classes-filha). O handle é um identificador, que por obrigação deve conter o valor 0 em seu final se for a raiz. E htb indica qual o algoritmo a ser usado. Para criar classes-filha da classe-principal exemplificada acima, devemos usar o comando tc class. Veja os exemplos: #tc class add dev eth0 parent 1:0 classid 1:10 htb rate 128kbps (4.5)

41 #tc class add dev eth0 parent 1:0 classid 1:20 htb rate 256kbps (4.6) 40 Podemos observar que são criadas duas classes-filhas parentes da primeira classe 1:0, sinalizadas pelo parâmetro parent, e identificadas com o parâmetro classid com banda garantida de 128 e 256 kbps. Como mencionado anteriormente, podemos adicionar outros qdisc em enfileiramento do tipo classful. Esses qdisc-filhos são associadas as classes-filhas, vamos criar um exemplo com base nos comandos executados acima: #tc qdisc add dev eth0 parent 1:10 handle 10: pfifo limit 10 (4.7) O tc permite a omissão do 0 na identificação do qdisc como podemos ver na expressão 4.7. Para concluirmos nossos exemplos sobre o uso da ferramenta tc, falta somente filtrar os pacotes com o uso do comando tc filter: #tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst flowid 1:10 (4.8) Com o classificador u32 é verificado o protocolo ip na interface eth0 em busca de pacotes que tenham o seu destino o ip e colocamos na classe 1:10 com o parâmetro flowid. Para usarmos o policiamento dentro do filtro devemos usar as regras TBF. Veja um exemplo adicionando as regras de policiamento na expressão 4.8: #tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst police rate 1000kbit burst 60kbit drop flowid 1:10 (4.9) Os pacotes serão enviados para a classe 1:10 deste que não ultrapassem o limite de rate 1000kbit e o burst 60kbit. Caso ocorra, esses pacotes serão descartados.

42 Algoritmos FIFO - First In First Out FIFO (primeiro a entrar, primeiro a sair) é um mecanismo padrão de escalonamento. Tem como função o armazenamento e encaminhamento do fluxo que forem chegando da rede. Tendo como prioridade a sua ordem de chegada, onde os primeiros pacotes que chegarem na fila serão transmitidos primeiro (SANTOS, 2010, p.20). Veja exemplos do comando tc sendo executado em um terminal Linux na expressão 4.10: #tc qdisc add dev eth0 root pfifo limit 10 (4.10) #tc -s qdisc show dev eth0 (4.11) No qual o retorno de saída no terminal para o comando 4.11 é: qdisc pfifo_fast 8001: root refcnt 2 limit 10p Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Podemos observar que se deletarmos a regra, anteriormente adicionada, com o comando 4.12: #tc qdisc del dev eth0 root pfifo (4.12) Verificamos novamente com o a opção show usando a expressão 4.11 teremos o seguinte resultado: qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Confirmando assim que o algoritmo FIFO é realmente o escalonador nativo do

43 42 Linux, como Stato Filho (2009, p.201) menciona SFQ - Stochastic Fair Queueing Stato Filho (2009, p.217) define o algoritmo SFQ (Stochastic Fair Queuing) como sendo um algoritmo baseado no Fair Queuing proposto por John Nagle em Ele foi projetado para assegurar que cada fluxo tenha acesso à rede de modo justo, impedindo que certos tráfegos não consumissem mais do que sua quota de largura de banda. Schulz (2007, p.34) nos oferece uma explicação melhor desse algoritmo: O algoritmo SFQ possibilita oferecer um enfileiramento justo, através de pouco processamento e de exatidão satisfatória. O algoritmo controla as conexões simultâneas através do controle de fluxo, e evita que uma única fila utilize todos os recursos da transmissão e comprometa as outras filas. Com base no recálculo de sua tabela de hashing, as colisões são evitadas e todas as filas são atendidas. O parâmetro perturb define o tempo onde os enfileiramentos são reavaliados. Ou seja, o algoritmo SFQ garante que cada conexão tenha direito a uma fatia justa da banda total através de técnicas estáticas de controle, evitando assim que uma conexão rápida se aposse totalmente da fila de transmissão e deixe as outras conexões ociosas. O funcionamento desse controle é executado da seguinte maneira, as conexões entrantes são classificadas por uma função chamada de hash e são distribuídas em algumas filas, para em seguida uma outra função, conhecido como Round Robin, oferte a cada rodada do SFQ uma chance a cada fila de transmitir um pacote para a interface de saída. Os parâmetros usados pelo SFQ são: perturb: indica em quantos segundos a função hash deve ser recalculada; quantum: quantos bytes devem ser enviados antes da próxima fila entre no algoritmo. Veja um exemplo do algoritmo SFQ na expressão 4.13: #tc qdisc add dev eth0 root sfq perturb 10 (4.13)

44 TBF - Token Bucket Filter Este algoritmo consegue controlar a taxa máxima de processamento de pacotes e seu funcionamento se dá através dos Buckets (buffer onde é colocado o Token) e Tokens (tipo de pacote que enche o buffer a uma taxa de velocidade) (STATO FILHO, 2009, p.211). O filtro de balde de fichas (tradução de Token Bucket Filter) é descrito por Schulz (2007, p.33) como sendo: Responsável por definir atrasos na entrega de pacotes por meio de taxas definidas para as interfaces de rede, assim adequando-se a situação previamente planejada. Para que isso ocorra, os valores do dispositivo de rede são analisados e definidos valores para a vazão do mesmo, existe a possibilidade de pequenas adições de pacotes, conhecidas como rajadas e definidas pelo parâmetro peakrate que será discutido a frente nos exemplos testados. Implementar um controle de taxa de envio ou um controle de serviço de pacotes por meio de contagem de número de pacotes ou bytes que vão sendo enviados, requer um uso complexo de timers e medições para funcionar de forma correta. Uma alternativa é gerar tokens a uma determinada taxa, e enviar os pacotes ou bytes apenas se um token estiver disponível. Então é criado um buffer, que se vai enchendo com tokens, a uma determinada taxa. Assim que houver tokens no bucket e pacotes na fila escolhe-se um token e mandam-se os pacotes. O bucket vai-se enchendo com tokens de acordo com uma determinada taxa; se os tokens não forem utilizados, o bucket pode encher completamente, sendo os tokens guardados até serem utilizados. Senão, o bucket nunca poderá encher (GOMES e SATURNINO, 2006, p.51). A relação token-pacote de um para um não pode ser usada como padrão, pois na grande maioria os pacotes são de tamanhos diferentes, sendo necessário o pacote ter mais de um token. Parâmetros do TBF: limit/ latency: limit é a quantidade de bytes que podem aguardar na fila e latency é o tempo máximo que um pacote deve esperar; burst/ buffer/ maxburst: tamanho do bucket em bytes; mpu: minimum packet unit, unidade mínima de pacote; rate: velocidade com que os tokens chegam ao bucket, ou seja, tamanho médio de transmissão;

45 44 peakrate: autoriza o bucket a se esvaziar, a um determinado tamanho, tão logo exista tokens disponíveis para pacotes que estão chegando; mtu/ minburst: o tamanho do MTU (Maximum Transmission Unit - unidade máxima de transmissão). Um exemplo substituindo o padrão pfifo: #tc qdisc add dev eth0 root tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1 mbit minburst 1540 (4.14) Um outro exemplo do uso do TBF como um qdisc-filho para tratamento de um qdisc classful: #tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1 mbit minburst 1540 (4.15) RED - Random Early Detection O algoritmo RED tem função de controle de fila, no qual o objetivo é de prevenir alguns fenômenos associados ao tipo de tratamento relacionado ao congestionamento. Respondendo mais rápido aos fluxos que ocasionam esse problema, o RED não espera que ocorra um congestionamento, antes de ocorrer, o algoritmo já trata o descarte de pacotes de forma equilibrada entre todas as filas e fluxos (STATO FILHO, 2009, p.223). Gomes e Saturnino (2006, p.69) dá a seguinte explicação desse algoritmo: Seus parâmetros são: Ele realiza a tarefa calculando continuamente o tamanho médio da fila e comparando-a com dois valores, um valor mínimo e um valor máximo. Se o tamanho médio da fila estiver abaixo do valor mínimo então nenhum pacote será descartado. Se a média estiver acima do valor máximo então todos os pacotes que chegarem serão descartados. Se a média estiver entre os dois valores então os pacotes são descartados baseados no cálculo da probabilidade obtido do tamanho médio da fila. Por outras palavras, conforme o tamanho médio da fila se aproxima do valor máximo, mais pacotes são descartados. min: tamanho médio da fila, no qual se toma o início de uma probabilidade

46 45 de descarte. O valor tem que ser em torno de um terço do valor da máxima probabilidade de descarte; max: tamanho médio da fila com a probabilidade máxima de descarte; probability: probabilidade máxima de descarte, com o valor especificado em número de ponto flutuante de 0.00 a 1.00; avpkt: tamanho médio do pacote em bytes. O valor ideal é 1000; burst: determina a velocidade que o tamanho médio da fila é influenciado pelo tamanho real. Valor recomentado 2*min+max/3*avpkt; limit: tamanho real da fila em bytes. Deve ser superior ao tamanho max+burst, sendo o valor recomentado 8*max; bandwidth: tamanho médio da fila depois de algum tempo inativa. Geralmente o valor utilizado é o tamanho da banda da interface. Uso opcional; ecn: pode ser utilizado para marca ou dropar pacotes, notificando os hosts que excederem sua taxa de largura de banda disponível. Veja um exemplo do tc usando o algoritmo RED: #tc qdisc add dev eth0 root red limit min max avpkt 1000 burst 20 probability 0.02 bandwidth 512 ecn (4.16) GRED - Generic Randon Early Detection Enquanto o RED possui apenas uma fila para tratar e descartar os pacotes, o GRED tem 16 filas virtuais que trabalham com parâmetros específicos em cada uma delas. O GRED é implementado para utilizar a família de PHB's AF do DiffServ (STATO FILHO, 2009, p.227). Stato Filho ainda conclui que o algoritmo GRED utiliza o classificador tc_index que por meio de suas especificações faz com que o algoritmo recupere o valor de alguns bits do campo e coloca os pacotes em uma das filas VQ (Virtual Queue). Para utilizar o GRED com o comando tc é preciso primeiro criar a fila principal com parâmetros genéricos e depois configurar as filas virtuais com um segundo comando.

47 46 Os parâmetros para a fila principal são: DPs: o número de filas virtuais; default: identifica a fila-padrão; grio: indica o meio de compartilhamento de buffer usado pelas filas virtuais. Já os parâmetros para as filas virtuais são os mesmos do RED com o acréscimo de dp que identifica a fila virtual e prio que da prioridade a fila virtual. Um exemplo do GRED para fila principal: #tc qdisc add dev eth0 root gred setup DPs 3 dafault 3 grio (4.17) Agora podemos configurar as filas virtuais. Veja um exemplo para a fila 1: #tc qdisc change dev eth0 root gred limit 60kb min 15kb max 45kb burst 20 avpkt 1000 bandwidth 10Mbit DP 1 probability 0.02 prio 2 (4.18) DSMARK - Differentiated Service Marker O DSMARK é um algoritmo QoS com capacidade para trabalhar com Differentiated Services (DiffServ ou DS). Diferente dos outros algoritmos, o DSMARK não é capaz de gerenciar filas e nem priorizar serviços, seu principal objetivo é marcar ou remarcar os pacotes no campo DS (STATO FILHO, 2009, p.227). Parâmetros do DSMARK: indices: é o tamanho da tabela interna que define o número de classes (n- 1); default_index: é o índice padrão, onde serão colocados os pacotes que não pertencem a nenhuma outra classe; set_tc_index: deve ser fixado para o uso do classificador tcindex; mask: valor da máscara que já está no pacote; value: novo valor.

48 47 Exemplo do qdisk DSMARK: #tc qdisc add dev eth0 handle 1:0 root dsmark indice 10 (4.19) PRIO - Priority Queuing O algoritmo PRIO (fila de prioridade), também conhecido por PQ, trabalha com um mecanismo de priorização de filas em quatro níveis (alta, média, normal e baixa). Por padrão o PRIO já tem três classes filhas geradas automaticamente para diferenciar o tráfego e o padrão qdisc dessas classes é o pfifo, sendo necessário somente adicionar os filtros para especificar a qual classe se deseja enviar. Couto (2007, p.34) descreve como esse mecanismo funciona: O enfileiramento por prioridade garante que pacotes, com prioridade mais alta, serão encaminhados mais rapidamente que os de baixa prioridade. Bastante útil quando existe um tráfego de uma aplicação crítica na rede. Assim, é dada a prioridade maior para o tráfego proveniente dessa aplicação em detrimento das outras. O mecanismo funciona criando filas com prioridades diferentes armazenando em buffers. Os pacotes que estiverem na fila de prioridade máxima serão processados, enviados e somente depois que a fila estiver vazia, as filas com prioridades menores serão atendidas. Ele conclui ainda que isso garante uma rápida entrega de pacotes para aplicações de missão crítica, mas pode levar a uma situação de starvation (inanição) nas filas de menor prioridade. Caso a fila de prioridade máxima nunca seja esvaziada, as filas de menor prioridade nunca serão atendidas. A distribuição dos pacotes nas filas podem ser realizadas de duas formas, o administrador cria um filtro informando para qual fila será enviada ou o próprio algoritmo decide, se não for especificado nenhum filtro, qual fila o pacote será encaminhado através da verificação do TC_PRIO (STATO FILHO, 2009, p.227). Parâmetros do PRIO: bands: número de bandas criadas. Por padrão 3; priomap: se não houver um filtro de classificação criado pelo administrador, a qdisc PRIO olha então a prioridade TC_PRIO (baseado nas flags TOS) para decidir como enfileirar o tráfego. Padrão 3. Se criarmos o qdisc PRIO com o comando:

49 #tc qdisc add dev eth0 handle 1:0 root prio (4.20) 48 resultado: E for feita uma consulta da qdisc e de suas classes, teremos o seguinte #tc qdisc show dev eth0 (4.21) qdisc prio 1: root refcnt 2 bands 3 priomap #tc class show dev eth0 (4.22) class prio 1:1 parent 1: class prio 1:2 parent 1: class prio 1:3 parent 1: Um exemplo de como podemos classificar essas filas: #tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip protocol 60xff flowid 1:1 (4.23) #tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 match ip protocol 170xff flowid 1:2 (4.24) #tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip protocol 10xff flowid 1:3 (4.25) Ou podemos criar qdisc-filhas para essas classes: #tc qdisc add dev eth0 parent 1:1 handle 10: pfifo (4.26) #tc qdisc add dev eth0 parent 1:2 handle 20: sfq (4.27) #tc qdisc add dev eth0 parent 1:3 handle 10: tbf rate 20kbit buffer 1600 limit 3000 (4.28) CBQ - Class Based Queue O CBQ é um qdisc com suporte a classes, pode ser usado como qdisc ou como uma classe, no qual pode ser adicionado a si mesmo como disciplina de fila. É considerado o mecanismo mais complexo na atualidade. Sendo o primeiro

50 mecanismo a fornecer garantias efetivas de banda e ser mais justo que o PRIO, o algoritmo perde a capacidade de fornecer priorização total para tráfegos de tempo real. Introduziu o escalonador (round-robin) baseado em contagem de bytes, com a intenção de resolver os problemas relacionados à falta de recursos para algumas filas no algoritmo PRIO (SANTANA, 2006, p.71). Couto (2007, p. 35) explica esse mecanismo: Nesse mecanismo, é possível a criação de classes (filas) onde o tráfego categorizado é armazenado para o futuro encaminhamento. Cada fila é servida com atendimento em round-robin numa sequência pré-definida. Assim podemos definir quantos bytes serão processados por fila em cada ciclo e as aplicações que têm seu tráfego destinado para cada fila, comportam-se como se aquela fila fosse sua banda total. Dessa forma temos um meio de comunicação virtual exclusivo para cada aplicação e todas serão atendidas a cada ciclo. A complexidade desse algoritmo se dá porque seu mecanismo de retardo de pacotes opera de acordo com as condições do ambiente de inatividade da interface de rede a ser escolhida. O algoritmo agrupa valores de tempo entre pedidos de dados, e por base de médias de inatividade é capaz de informar o nível de congestionamento. Esse cenário oferece resultados nem sempre precisos e de pouca aceitação para um controle justo de banda (HUBERT apud SCHULZ, 2007, p.34). As filas são organizadas de forma hierárquica, onde no topo da hierarquia se encontra a fila raiz que define a quantidade total de banda disponível. As outras filas são adicionadas sob a fila raiz, cada uma delas pode receber parte da largura de banda da fila raiz e podem ser configuradas para pedir emprestada a largura de banda da fila pai. Parâmetros para esse algoritmo: bandwidth (qdisc): informação obrigatória, na qual é especificada a largura da banda da interface física no momento da criação da qdisc root; bandwidth (class): é usado para determinar a maxidle e offtime que só é calculado ao especificar maxburst ou minburst; handle: nome para a qdisc; parent: informa qual qdisc está associada; avpkt: tamanho médio de um pacote em bytes; cell: tempo de transmissão de um pacote, determinando sua 49

51 50 granularidade. Valor padrão usado é 8; classid: nome da classe; allot: quantia enviada de um pacote em bytes, relacionada a avpkt, para uma fila qdisc a ser processada. Mínimo é de 3/2 avpkt; maxburst: informa o número de pacotes que é usado para calcular o maxidle (valor máximo de rajada para envio); minburst: calcula o tempo do idle; rate: taxa máxima que esta classe pode enviar; weight: limita o uso da banda, forçando a classe enviar em taxas préfixadas, auxiliando o balanceamento de envio de pacotes através do processo Weighted Round Robin. Valor geralmente usado é de rate/10; prio: prioridade do pacote. Quanto menor o valor, maior a prioridade; mpu: valor para cálculo do tempo de transmissão de um pacote. Padrão é 0; bounded: significa que a classe não pedirá emprestada a banda para outra classe; isolated: não empresta banda para nenhuma classe. Vamos ver um exemplo onde teremos uma qdisc principal, uma classeprincipal e duas subclasses: #tc qdisc add dev eth0 root handle 1: cbq bandwidth 100Mbit (4.29) #tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 5Mbit weigth 0.5Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bouend (4.30) #tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 100Mbit rate 3Mbit weigth 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 (4.31) #tc class add dev eth0 parent 1:1 classid 1:20 cbq bandwidth 100Mbit rate 2Mbit weigth 0.2Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 (4.32) No primeiro comando é criada a qdisc principal, o segundo cria a classe-

52 51 principal que não empresta banda para ninguém e nos dois comandos seguintes são criadas sub-classes que estarão limitadas pela banda da classe-principal. Agora devemos criar qdisc para esses sub-classes para a organização dentro das filas: #tc qdisc add dev eth0 parent 1:10 handle 10: sfq (4.33) #tc qdisc add dev eth0 parent 1:20 handle 20: sfq (4.34) Com as filas prontas, devemos filtrar e enviar o tráfego para as classes ou sub-classes desejadas. Um exemplo utilizando filtros para a porta de origem 80 e 21: #tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 80 0xffff flowid 1:10 (4.35) #tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport 21 0xffff flowid 1:20 (4.36) HTB - Hierarchical Token Bucket Criado por Martin Devera Aka Devik, o HTB (balde de fichas hierárquica) foi incluído no kernel do Linux aparte da versão onde implementa um escalonador classful para o controle de fluxo de dados, compartilhando em filas hierárquica a largura de banda do enlace. Esse mecanismo veio com o intuito de substituir o CBQ, por ser de fácil de assimilação, intuitivo e rápido. Tanto o CBQ quanto o HTB ajudam a controlar o uso da largura de banda no tráfego de saída em um link. Ambos permitem usar um link físico para simular vários links lentos e enviar diferentes tipos de tráfego em diferentes links virtuais. Em ambos casos, tem de especificar como dividir o link físico em links simulados e decidir como cada pacote será enviado em cada link virtual (DEVIK e COHEN, 2002). Rocha (2009, p.37) faz um resumo do principal objetivo desse algoritmo, que é distribuir os recursos do enlace de forma a garantira largura de banda mínima para uma classe quando ocorrer um congestionamento na rede. Quando forem utilizados menos recursos, a largura de banda restante é distribuída entre as outras classes.

53 52 A distribuição de recursos é feita pelos parâmetros rate e ceil, onde o rate define a taxa fixa de transmissão (banda garantida) e ceil faz uma solicitação de empréstimo de banda a classe-pai, o empréstimo só será atendido se o recurso estiver disponível, ou seja, outra classe-filha não estiver usando. Os parâmetros para o uso do algoritmo HTB são: default: especifica a classe padrão. O tráfego que não estiver associado a uma classe específica será direcionado para a classe padrão; rate: velocidade mínima e garantida de transmissão de um pacote; ceil: velocidade máxima que a classe pode transmitir, se a classe superior disponibilizar o recurso; burst: tamanho máximo de bytes que pode ser acumulado para rajadas (ceil); cburst: tamanho máximo de bytes que pode ser enviado na taxa da interface caso não haja limite imposto pela classe-pai; priority: ordenamento das classes. O Valor 0 tem prioridade máxima. Vamos a um exemplo de uso do algoritmo HTB, lembrando que a limitação das taxas de transmissão são realizadas no tráfego que sai da interface de rede, tomando base a Figura 03. Figura 03 - Estrutura do ambiente Fonte: Elaborado pelo Autor Para o exemplo da Figura 03 a banda de conexão disponível para o download e para o upload é de 1Mbit cada. Já a distribuição para a rede interna, que é fornecida pela interface eth1, ficou da seguinte forma: PC1 - o download é de 510Kbit e o upload é de 512Kbit, PC2 - o download e o upload é de 256Kbit e PC3 - o download e o upload é de 256Kbit. Somente PC1 e PC2 pediram emprestado

54 53 banda para a classe superior e todas as classes terão a mesma prioridade. Criaremos uma qdisc principal, uma classe-principal é quatro classes-filha. Lembrando que a uma destas classes-filha vai ser a padrão, onde o tráfego que não estiver associado a uma classe será direcionada para ela. Iremos também adicionar a essas classes-filhas o algoritmo SFQ para que exista uma distribuição justa em cada classe-filha. Podemos ver o modelo hierárquico desse exemplo na Figura 04: Figura 04 - Hierarquia das classes Qdisc Principal 1: root qdisc Classe Principal 1:1 Link 1Mbit Classes Filha 1:10 PC1 510Kbit 1:20 PC2 256Kbit 1:30 PC3 256Kbit 1:40 Padrão 2Kbit Qdisc Filhas 100: SFQ 200: SFQ 300: SFQ 400: SFQ Fonte: Adaptado de (STATO FILHO, 2009, p. 240) Os comandos para a interface de download (eth1) são: #tc qdisc add dev eth1 root handle 1: htb default 40 (4.37) Para a criação da qdisc principal HTB com a classe 40 como padrão. #tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1024kbit (4.38) É criada a classe principal com o tamanho da banda de conexão fornecido pelo provedor de internet. #tc class add dev eth1 parent 1:1 classid 1:10 htb rate 510kbit ceil 1024kbit prio 1 (4.39) #tc class add dev eth1 parent 1:1 classid 1:20 htb rate 256kbit ceil 1024kbit prio 1 (4.40)

55 54 #tc class add dev eth1 parent 1:1 classid 1:30 htb rate 256kbit ceil 256kbit prio 1 (4.41) #tc class add dev eth1 parent 1:1 classid 1:40 htb rate 2kbit ceil 2kbit prio 1 (4.42) São adicionadas as classes-filha com suas respectivas prioridades e taxas de transmissão. A ideia da classe padrão com uma taxa tão baixa é que se um outro computador, além dos três, entrar na rede, mal vai receber fluxo de dados. #tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 (4.43) #tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10 (4.44) #tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10 (4.45) #tc qdisc add dev eth1 parent 1:40 handle 40: sfq perturb 10 (4.46) Como mencionado anteriormente, são adicionados algoritmos SFQ nas classes-filha para um fluxo de dados mais justo nas próprias classes. #tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst flowid 1:10 (4.47) #tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst flowid 1:20 (4.48) #tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst flowid 1:30 (4.49) E por fim, são criadas as regras para filtrar e encaminhar o tráfego para as classes correspondentes. Para o upload na interface eth0 temos uma pequena diferença na hora de filtrar os pacotes que sairão dessa interface. Devido o uso do NAT (Network Address Translation), técnica de mascaramento, para fazer o gateway no Linux e que o algoritmo HTB só faz controle do tráfego que sai, devemos fazer o filtro dos pacotes com a ferramenta Iptables. Pois o comando tc filter com o classificador u32 não funciona nessas condições. Nós temos duas maneiras de utilizarmos o iptables para marcar os pacotes que serão enfileirados em suas respectivas classes. A primeira é classificando os

56 55 pacotes e setando para as classes determinadas com o parâmetro CLASSIFY e a segunda e marcando o pacote com o MARK. Nesse último devemos trabalhar com o filtro da ferramenta tc. Veja um exemplo utilizando o parâmetro CLASSIFY do iptables. #iptables -t mangle -A FORWARD -s j CLASSIFY set-class 1:10 (4.50) Para utilizar o parâmetro MARK é necessário o filtro da ferramenta tc para encaminhar para uma classe determinada. Veja um exemplo: #tc filter add dev eth0 parent 1:0 protocol ip handle 10 fw classid 1:10 (4.51) #iptables -t mangle -A FORWARD -s j MARK set-mark 10 (4.52) Então para a interface da internet (eth0), onde os pacotes vêm de origem da interface eth1, o upload, os comandos ficam da seguinte forma: #tc qdisc add dev eth0 root handle 1: htb (4.53) #tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1024kbit (4.54) #tc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit ceil 1024kbit prio 1 (4.55) #tc class add dev eth0 parent 1:1 classid 1:20 htb rate 256kbit ceil 1024kbit prio 1 (4.56) #tc class add dev eth0 parent 1:1 classid 1:30 htb rate 256kbit ceil 256kbit prio 1 (4.57) Criação da qdisc principal sem a opção de uma classe padrão e das classes principais e filhas. #tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 (4.58) #tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 (4.59) #tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 (4.60)

57 56 Criação da qdisc SFQ para as classes-filha. #tc filter add dev eth0 parent 1:0 protocol ip handle 10 fw classid 1:10 (4.61) #tc filter add dev eth0 parent 1:0 protocol ip handle 20 fw classid 1:20 (4.62) #tc filter add dev eth0 parent 1:0 protocol ip handle 30 fw classid 1:30 (4.63) Filtro direcionado os pacotes marcados para suas respectivas classes. #iptables -t mangle -A FORWARD -o eth0 -s j MARK setmark 10 (4.64) #iptables -t mangle -A FORWARD -o eth0 -s j MARK setmark 20 (4.65) #iptables -t mangle -A FORWARD -o eth0 -s j MARK setmark 30 (4.66) Ferramenta iptables faz a marcação dos pacotes que atravessam o gateway com destino de saída a interface eth0, no qual será direcionado pelo filtro já comentado acima.

58 57 5 CARACTERIZAÇÃO DO OBJETO DE ESTUDO Como visto na seção acima, podemos observar que a tarefa de construir um script, via linha de comando, para implementar um controle de tráfego utilizando a ferramenta tc é trabalhosa e complexa. Com base nessa afirmação o software proposto nesse trabalho tem como principal característica uma interface mais enxuta e de fácil utilização, que possa controlar o tráfego e priorizar serviços com poucas informações inseridas nele, ou seja, facilitar a execução e criação de regras de controle de tráfego. Um outro atributo é o acesso remoto através de um navegador, onde poderá ser realizada a entrada de dados em um outro computador em rede que tiver permissão de acesso. O hardware necessário para executar o software é qualquer processador Pentium IV ou equivalente de 2.6GHz ou superior, com 1GB de memória RAM recomendada e duas placas de rede para o gateway. Já os requisitos de software para executar o programa são: sistema operacional Linux com o kernel ou maior, tc, iptable e o java jdk 6 ou superior. Lembrando que o usuário deve possuir um breve conhecimento na área de redes de computadores e S.O. Linux.

59 58 6 METODOLOGIA A presente pesquisa se classifica como estudo bibliográfico, utilizada para apresentar toda a parte conceitual da pesquisa, numa seleção das abordagens de diversos autores sobre os temas tratados. A pesquisa classifica-se ainda como sendo experimental, para verificar a eficácia da utilização de alguns dos conceitos abordados neste trabalho na solução de um problema real. Sendo a pesquisa classificada como estudo bibliográfica, foi feito o levantamento e obtenção do material. Pois a pesquisa bibliográfica procura explicar um problema a partir de referências teóricas publicadas em artigos, livros, dissertações e teses (BERVIAN; CERVO; SILVA, 2007, p.60). A coleta de dados ocorreu com o uso de software que registram o comportamento do ambiente antes e depois de aplicar a solução proposta pelo trabalho, com o objetivo de provar na prática os conceitos abordados pelo tema. Já o método de análise dos dados coletados foi estático obtido de forma empírica, sendo do tipo quantitativa. que: Para a análise dos dados na pesquisa experimental, Gil (2002, p.101) afirma O procedimento básico adotado na análise estatística nas pesquisas experimentais consiste no teste da diferença entre as médias.[...]a Estatística dispõe de inúmeros testes de significância. A utilização de cada um deles depende de conhecimentos prévios acerca da extensão, distribuição e qualidade dos dados. Por isso, convém que todo o processo de análise estatística seja planejado antes de conduzir o experimento. Foi adotado o processo easyprocess para implementar o desenvolvimento da aplicação, e como visto em seções anteriores o YP é voltado para projetos de pequeno e médio porte e por ter seu alicece em métodos ágeis. As atividades realizadas no processo YP foram: definições de papel, conversa com o cliente, modelagem da tarefa, definição das User Stories (estória de uso) e Testes de Aceitação, geração do Protótipo da Interface, elaboração do Projeto Arquitetural e a construção de um Modelo Lógico de Dado, além do planejamento com o plano de release e iterações e implementação. As saídas de cada etapa realizada no processo YP se encontram nos apêndices de A ao H desse trabalho, esses artefatos são: o documento de visão (onde foram acordados os requisitos funcionais e não-funcionais, junto com o perfil

60 59 do usuário), modelagem da tarefa, User Stories, protótipo da interface, projeto arquitetural e o modelo lógico de dados. Para facilitar a instalação e uso da aplicação foi determinado no documento de visão que o software será executado em um servidor container embutido para o possível acesso remoto e seu banco de dados também será embutido. Os softwares escolhidos foram o jetty para servidor container e o h2 da google para gerenciamento do banco de dados sql. Eliminando assim o trabalho de instalação de programas adicionais e facilitando sua implementação. Para o desenvolvimento do software foi utilizado o Eclipse para a codificação da linguagem java, o Aptana Studio 3 para trabalhar com a linguagem html e o bluegriffon para a visualização previa do código html. Ambas as ferramentas são softwares livres. Foram usados na camada que se comunica com o banco de dados os padrões de projetos Query Object e Composite Pattern, no qual o código fonte foi feito uma adaptação da linguagem php para a linguagem java. O código fonte original se encontra no livro de DALL'OGILIO (2009). Os aplicativos utilizados para se medir os testes de velocidade no servidor foram o bmon e o speedometer, já no computador cliente foi utilizado o gnomesystem-monitor e o site speedtest.net. Para a execução do download na máquina do cliente foi adotado o gerenciador wget baixando a imagem do Linux no site do Debian, já para o upload utilizou-se o dropbox. As configurações de hardware e software nos computadores para teste de velocidade foram as seguintes: no servidor processador Intel Celeron de 2.6GHz com 512MB de memória RAM e duas placas de rede 10/100 Mbs, o sistema operacional executado foi o Linux Debian 7.1 com as ferramentas tc, iptables e openjdk 6 (versão jdk) instaladas a parte de seus repositores; na máquina cliente o processador é um Intel Atom 1.6GHz com 1GB de memória RAM, com o Linux Ubuntu versão LTS instalado. A velocidade fornecida pelo provedor de internet é de 1Mbs de download e 0.5Mbs de upload. Sendo que os dados que foram coletados nas duas máquinas, tanto no servidor como no cliente, foram limitados em duas velocidades de banda: a primeira de 64Kbps para download e 32Kbps de upload e a segunda de 512Kbps/256Kbps para download e upload respectivamente.

61 60 7 RESULTADOS DO TRABALHO Para comprovar que o objetivo desse trabalho foi alcançado, realizaram-se vários testes de velocidade, antes e depois da execução do software desenvolvido. Os testes realizados na máquina cliente antes da execução do software, ou seja, sem o controle de tráfego, podem ser observados nas imagens abaixo (Figura 05 a Figura 07): Figura 05 Teste de Velocidade no speedtest.net Fonte: Elaborado pelo Autor Figura 06 Teste de velocidade de download no gnome-system-monitor Fonte: Elaborado pelo Autor Figura 07 Teste de velocidade de upload no gnome-system-monitor Fonte: Elaborado pelo Autor

62 61 No primeiro teste foi determinada a velocidade de 64Kbps/32Kbps para o ip da máquina alvo. Sendo que os testes de velocidade de download e upload foram realizados separadamente evitando alguns problemas de atraso e jitter dos pacotes com o upload em seu máximo uso de banda, comprovando a estabilidade do algoritmo de enfileiramento HTB. Posteriormente foi feito o teste de velocidade de download e upload concorrentemente, como podemos ver na Figura 08 a Figura 10. Figura 08 Teste de velocidade de downoad 64Kbps no gnome-system-monitor Fonte: Elaborado pelo Autor Figura 09 Teste de velocidade de upload 32Kbps no gnome-system-monitor Fonte: Elaborado pelo Autor Figura 10 Teste de download e upload no gnome-system-monitor com velocidade limitada em 64Kbps/32Kbps Fonte: Elaborado pelo Autor Um segundo teste foi realizado na máquina cliente com velocidade limitada em 512Kbps para download e 256Kbps para upload. Seguindo a mesma ordem de testes realizado no teste anterior. Veja os testes na Figura 11 a Figura 13.

63 Figura 11 Teste de velocidade de downoad 512Kbps no gnome-system-monitor 62 Fonte: Elaborado pelo Autor Figura 12 Teste de velocidade de upload 256Kbps no gnome-system-monitor Fonte: Elaborado pelo Autor Figura 13 Teste de download e upload no gnome-system-monitor com velocidade limitada em 512Kbps/256Kbps Fonte: Elaborado pelo Autor Observando os gráficos encontramos variações no fluxo de dados transmitido, tanto no recebido como no enviado. Essas variações ocorrem em razão de o QoS ter sido implementado nas nuvens, ou seja, ele se encontra somente em um roteador de borda. Em consequência disso o controle de fluxo só ocorrerá nas saídas do roteador, não podendo ser feito controle direto dos pacotes entrantes. Isso é explicado por que o fluxo downstream medido no cliente não varia tanto quanto o upstream. É observado ainda que existe uma variação de download na limitação de 64Kbps, enquanto na velocidade de download de 512Kbps isso não acontece, esse fato ocorre devido o tamanho da largura de banda na limitação de 64Kbps ser muito pequeno, lotando rapidamente a fila de espera do algoritmo de controle. Já para as

64 63 velocidades de upload, o fluxo de transmissão de saída medido no cliente, percebemos que os valores variam muito chegando até passar do valor limitado. Isso acontece porque o controle de tráfego é gerenciado na saída do servidor e não na saída da máquina cliente, provocando rajadas de pacotes enviadas pelo cliente e descarte de pacotes, no caso das filas estarem cheias, efetuada pelo servidor. Para resolver o problema de controle de upstream vinda do cliente em direção ao servidor, ou melhor explicando os pacotes que entram no roteador, foi necessária a marcação dos pacotes que entram na interface de rede do roteador, com auxílio da ferramenta iptable, para posteriormente serem gerenciados na interface que sairão esses pacotes. No qual o servidor de roteamento de teste contém duas interfaces de rede uma conectada ao provedor de internet eth0 e outra do lado da rede interna eth1. No Linux as interfaces são renomeadas conforme o tipo ou classes de hardware das placas utilizadas, por exemplo, se as placas forem do tipo wireless a renomeação será wlanx. Já o nosso caso as placas são do tipo ethernet. Durante os testes de velocidade realizados na máquina cliente foram medidas as velocidades de upstream nas duas interfaces de rede do servidor, como podemos ver nas figuras 14 a 16 as variações de velocidades são mínimas. Teste de velocidade de download no cliente com medição de velocidade no servidor na interface eth1, sentido de fluxo servidor/cliente: Figura 14 Medição de velocidade de saída do servidor para o cliente no speedometer com velocidade limitada em 64Kbps Fonte: Elaborado pelo Autor Teste de velocidade de upload no cliente com medição de velocidade na interface eth0, no qual os pacotes foram marcados ao entrarem pela interface eth1 para serem tratados na eth0, sendo o sentido do trafego cliente/servidor:

65 Figura 15 Medição de velocidade de saída do servidor para o provedor de internet no speedometer com velocidade limitada em 256Kbps 64 Fonte: Elaborado pelo Autor No teste de velocidade simultânea de download e upload no cliente, as medições de velocidade foram realizadas nas duas interfaces do servidor: Figura 16 Medição de velocidade de saída do servidor para o provedor de internet e para o cliente utilizando o speedometer com velocidade limitada em 512Kbps/256Kbps Fonte: Elaborado pelo Autor E a última medição foi realizada na máquina cliente utilizando o site speedtest com a banda de tráfego limitada em 512Kbps/256Kbps.

66 65 Figura 17 Teste de Velocidade no speedtest.net Fonte: Elaborado pelo Autor Além dos testes de velocidade para confirmar que o software está executando os comandos do tc e do iptable corretamente, também foi verificada no terminal do Linux a inserção das regras com auxílio das próprias ferramentas. Figura 18 Tela do software com regra inserida Fonte: Elaborado pelo Autor A Figura 18 mostra o software desenvolvido com uma entrada de informações delimitando a velocidade de tráfego do host para 512 Kbps no download e 256Kbps para upload. Com o comando tc podemos verificar as regras em execução na interface eth1 e eth0.

67 66 Figura 19 Regras executadas pela ferramenta tc na interface eth1 Fonte: Elaborado pelo Autor Figura 20 Regras executadas pela ferramenta tc na interface eth0 Fonte: Elaborado pelo Autor Como dito anteriormente o trafego de upload do cliente só será controlado na interface que está ligada a rede do provedor de internet através do comando iptables marcado os pacotes que entram no roteador pelo lado do cliente. Com o comando iptables -v -n -t mangle -L é listado todas as chains da tabela mangle, visto na Figura 20.

68 67 8 CONCLUSÃO Esse trabalho surgiu a partir de um problema observado durante a disciplina de Estágio Supervisionado II e IV, no qual é exigido a prática do ensino em escolas públicas. E durante essa atividade realizada no laboratório de informática foi observado que a largura de banda de acesso à internet era consumida totalmente pelos alunos daquela instituição que se encontravam no laboratório. A situação se dá pelo fato de que o tamanho da largura de banda disponível para as escolas públicas serem de baixa velocidade ou incompatíveis em relação ao número de máquinas/velocidade. Há duas soluções para esse problema, a primeira é aumentando a largura de banda da internet, porém as escolas estão parcialmente impossibilitadas, pois dependem do governo estadual ou municipal para adquirir esse benefício. Uma outra questão a se observar é que uma boa velocidade não garante que o consumo total da mesma não será utilizado por um único usuário. A segunda solução é implantar um roteador com controle de tráfego, proposta apresentada nesse trabalho, utilizando uma máquina modesta como servidor, possibilitando uma melhor distribuição do serviço de internet. O software escolhido para controlar o trafego foi o tc, contida na maioria das distribuições Linux, mas seu uso requer um bom conhecimento em algoritmo de enfileiramento tornando a construção do script uma tarefa trabalhosa e complexa. Com base nessa questão foi desenvolvido um software que gerencie o tc com uma interface web, sendo simplificado através de inserção dos parâmetros básicos para sua execução. O desenvolvimento do software foi necessário, pois outros programas existes para tal finalidade como o HTB-tools e o WebHTB não atende os requisitos estabelecidos nesse trabalho, como facilidade de uso. O estudo apresentado na fundamentação teórica foi fundamental para o conhecimento detalhado da ferramenta tc e colocar em prática o processo YP para o desenvolvimento do software, atendendo os objetivos proposto. Entretanto, o programa ainda não está completo. Durante as atividades de desenvolvimento foram detectados alguns problemas como: um único membro na equipe, e sem a divisão de tarefas a sobrecarga foi inevitável. Em consequência disso o projeto teve seu tempo de execução ultrapassado e o software inacabado, onde foi comprometido o

69 68 planejamento e a implementação, faltando a execução do plano de release e de iteração que seriam os testes de aceitação, em consequência disto a implementação não ficou completa conforme o acordado no documento de visão, faltando na aplicação o tratamento de entrada de dados e um guia de ajuda. Um outro problema detectado foi na complexa implementação ao adicionar o endereço IP automaticamente para ser inseridas as regras de controle de tráfego sobre ele, sem comprometer a qualidade do uso do serviço de internet, pois um número grande de endereços provocaria um gargalo no tamanho da banda ajustado para cada endereço com base no tamanho oferecido pelo provedor de internet. Alterações e implementações a ser resolvidas pelos problemas encontrados nesse trabalho poderão ser realizados em futuros projeto de trabalhos de conclusão de curso.

70 69 9 BIBLIOGRAFIA BERVIAN, Pedro Alcino; CERVO, Amado Luiz; SILVA, Roberto da. Metodologia cientifica. Ed 6. São Paulo: Pearson Prentice Hall, COUTO, André Rios. Controle de uso de banda garantindo QoS baseado em Diffserv usando FreeBSD. Salvador, Disponível em: < Acesso em: 23 mai. 2014, 15:03:39. DALL'OGILIO, Pablo. PHP: Programando com orientação a objetos. Ed 2. São Paulo: Novatec Editora, DEVIK, Martin Devera Aka; COHEN, Don. Manual de regras de enfileiramento HTB Linux - guia do usuário. Tradução Carlos Virgílio Beltrão Lessa Disponível em: < Acesso em: 21 jun. 2014, 12:03:43. GIL, Antônio Carlos, Como elaborar projetos de pesquisa. 4. Ed. São Paulo: Atlas GOMES, Nuno Miguel Vieira; SATURNINO, Renato André Norte. QoS na Vídeo- Difusão sobre IPv6. Leiria, Portugal, Disponível em: < Acesso em: 30 mai. 2014, 21:37:00. HIRAMA, Kechi. Engenharia de Software: qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, LARMAN, Craig. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman companhia editora, NETO, Urubatan. Dominando Linux Firewall Iptables. 1. ed. Rio de Janeiro: Editora Ciência Moderna Ltda, PAULA FILHO, Wilson de Pádua. Engenharia de Software Fundamentos, Métodos e Padrões. 2. ed. Rio de Janeiro: LTC Livros Técnicos e Científicos Editora S.A., PET/UFCG. EasYProcess: Um Processo de Desenvolvimento de Software. Apostila, Disponível em: < %20Completo%20-%20% pdf>. Acesso em: 16 jan. 2014, 21:34:00. PRESSMAN, Roger S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, ROCHA, Lucio Agostinho. WebLab SOA no Domínio de Redes de Computadores para Experimentos DiffServ. Uberlândia, MG, Disponível em: <

71 70 %C3%ADnio.pdf>. Acesso em: 16 jun. 2014, 21:23:52. SANTANA, Sílvio Fernando Lima de. Proposta de Referência para Projetos de Qualidade de Serviço (QoS) em Redes Corporativas. Salvador, Disponível em: < 50/Publico/Dissertacao%20Silvio%20Santana%202006%20texto%20completo.pdf>. Acesso em: 15 jun. 2014, 14:24:35. SANTOS, Aldir Lopes dos. Controle de Banda em Redes TCP/IP Utilizando o Linux. Lavras, MG, Disponível em: < AldirSantos.pdf>. Acesso em: 21 mai. 2014, 14:44:16. SCHULZ, Cleiton. Controle de Banda Aplicando Qualidade de Serviço no Sistema Operacional Linux. Joinville, Disponível em: < option=com_phocadownload&view=category&download=28: controle-debanda-aplicando-qualidade-de-servio-no-sistema-operacional-linux-cleitonschulz&id=13:redes-de-computadores&itemid=89>. Acesso em: 28 mai. 2014, 15:40:00. SILVA FILHO, Antonio Mendes da. Usabilidade de Software: A Importância da Usabilidade no Desenvolvimento de Sistemas Interativos. Revista Engenharia de Software Magazine, Brasil, Ano 1, Ed. 05, p , SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson Addison- Wesley, SOUSA, Nathan Franklin Saraiva de. Implantação de Controle de Banda para otimização do uso de rede de computadores através de QoS. Teresina, PI, Disponível em: < Acesso em: 18 mai. 2014, 20:27:00. STATO FILHO, André. Linux Controle de Redes. Florianópolis: Visual Book, UOL. Dicionario Michaelis. Editora Melhoramentos Ltda, Disponível em: < Acesso em: 30 nov. 2013, 20:30:00.

72 71 APÊNDICE A - DOCUMENTO DE VISÃO Nos últimos tempos o governo federal disponibilizou laboratório de informática com acesso a internet para as escolas públicas estaduais e municipais, com o objetivo de cumprir com o Plano Nacional da Educação em introduzir a inclusão digital. O laboratório de informática em conjunto com a rede mundial de computadores disponibilizou mais uma ferramenta auxilio na educação, mas foi observado pelos alunos de licenciatura em Computação da UEPB durante os estágios supervisionado uma lentidão no acesso ao conteúdo na internet, que podem ser provenientes de um mal gerenciamento de recursos ou gerenciamento nenhum deixando esse serviço com qualidade muito ruim. Uma solução gratuita seria a utilização de ferramentas de controle de banda e QOS como HTB e Iptables encontrado no sistema operacional Linux que também são gratuito. A dificuldade na utilização dessas ferramentas se encontra em seu ambiente de execução, pois são linhas de comandos executados no shell e com extensas opções de parâmetros. A proposta para resolver esse problema é criar um software gráfico amigável, ou seja, que execute esses comandos sem que o usuário final saiba de todos os parâmetros necessários para seu funcionamento. Esse software deve conter somente opções básicas que compõem o controle de banda como nome da interface de rede, endereço de rede, quantidade de banda reservada para determinado faixa ou endereço de rede, com inserção manual ou automática. Mas essa automatização pode ser uma dificuldade no desenvolvimento desse software, pois deve-se criar um agente de monitoramento de ingressão de maquinas para tal função. Requisitos funcionais Adicionamento de regras para controle de banda por IP ou faixa de IP; Adicionamento automático de IP em uma faixa de IP determinada pelo usuário; Adicionamento de regras para melhoria de serviços (QOS). Requisitos não-funcionais Interface Web (Servidor container embutido - Jetty);

73 72 Login para utilização do sistema; Banco de dados h2 da google; Utilização de padrões de projeto (Query Object e Composite Pattern). Perfil do Usuário Qualquer pessoa que possua um pouco de conhecimento em redes de computadores e do sistema operacional Linux. Objetivos de Usabilidade Objetivo Mensuração Possuir tela simples Observar dificuldade de uso da interface. Manter clareza na estrutura Número de ações incorretas, erros repetitivos e consulta à ajuda Ser atrativo ao usuário Satisfação do usuário ao utilizar o sistema. Reduzir o numero de erros Número de tarefas concluída corretamente. Disponibilizar Informações Facilitar o encontro de ajuda desejada.

74 73 APÊNDICE B - MODELO DA TAREFA Modelo da Tarefa: Utilizar Sistema Modelo da Tarefa: Autenticação do Sistema Modelo da Tarefa: Seleção da Interface de Rede (Internet) Modela da Tarefa: Classe e Subclasses

75 74 Modelo da Tarefa: Classe Principal (Adição e Edição) Modelo da Tarefa: Subclasses (Adição e Edição) Modelo da Tarefa: QoS por IP (Adição e Edição) Modelo da Tarefa: QoS por Faixa de IP (Adição e Edição) Modelo da Tarefa: Prioridade de Serviços (Adição e Edição)

76 75 APÊNDICE C - USER STORIES E TESTE DE ACEITAÇÃO US01 Estudar JSP(Jetty), javadb(derby), HTB, os padrões de projeto (Query Object e Composite Pattern) e shell script no linux. Gerar exemplos como resultados. Estimativa inicial: 14h TA1.1 Verificar se os exemplos satisfazem o uso das tecnologias citadas no projeto. US02 Implementar a funcionalidade de seleção da interface de internet Estimativa inicial: 7h TA2.1 Selecionar uma interface com ou sem velocidade de upload e salvar (Seleção salva com sucesso) TA2.2 Fazer nenhum seleção com ou sem velocidade de upload e salvar (Mensagem pedindo para selecionar um interface) US03 Implementar a funcionalidade de cadastrar classes de banda Estimativa inicial: 30h TA3.1 Adicionar uma classe principal com todos os dados corretos (Classe adicionada com sucesso) TA3.2 Adicionar uma classe principal sem informa todos os campos obrigatórios (A classe não deve ser adicionada e retornar um erro) TA3.3 Adicionar uma classe principal com o nome ou interface já adicionada (A classe não deve ser adicionada e retornar um erro) TA3.4 Modificar uma ou mais informação na classe principal já adicionada ( Modificação efetuada com sucesso) TA3.5 Modificar uma ou mais informação na classe principal já adicionada com o nome ou interface iguais a outra classe ( Modificação não efetuada com sucesso e retornar um erro) TA3.6 Remover uma classe principal (Emitir uma mensagem que tudo associada a essa classe serão removidas e Remoção efetuada com sucesso) TA3.7 Adicionar uma subclasse com todos os dados corretos (Subclasse adicionada com sucesso) TA3.8 Adicionar uma subclasse sem informa todos os campos obrigatórios (A subclasse não deve ser adicionada e retornar um erro)

77 76 TA3.9 Adicionar uma subclasse com o nome já adicionada (A subclasse não deve ser adicionada e retornar um erro) TA3.10 Adicionar uma subclasse com a informação de download/upload maior que a da classe principal pertencente (A subclasse não deve ser adicionada e retornar um erro) TA3.11 Adicionar duas ou mais subclasses pertencentes a uma classe principal com a soma das velocidades de download/upload maior que a da classe principal (A subclasse que ultrapassar o valor não deve ser adicionada e retornar um erro) TA3.12 Modificar uma ou mais informação na subclasse já adicionada, sem ultrapassar o valor de download/upload se for informada um outro valor para o campo( Modificação efetuada com sucesso) TA.3.13 Modificar o nome da subclasse já adicionada que seja igual a outra subclasse, sem ultrapassar o valor de download/upload se for informada um outro valor para o campo( Modificação não efetuada com sucesso e retornar um erro) TA3.14 Modificar a informação de donwload/upload e que esse ultrapasse o valor da soma das subclasses associadas a classe principal ( Modificação não efetuada com sucesso e retornar o erro) TA3.15 Remover uma subclasse (Emitir uma mensagem que tudo associada a essa subclasse serão removidas e Remoção efetuada com sucesso) US04 Implementar o QoS por IP Estimativa inicial: 24h TA4.1 Adicionar um IP com todos os dados corretos (IP adicionado com sucesso) TA4.2 Adicionar um IP sem informa todos os campos obrigatórios (O IP não deve ser adicionado e retornar um erro) TA4.3 Adicionar um IP já adicionada anteriormente (O IP não deve ser adicionado e retornar um erro) TA4.4 Adicionar um IP com a velocidade de download maior que a da classe ou subclasse pertencente (O IP não deve ser adicionado e retornar um erro) TA4.5 Adicionar dois ou mais IP pertencentes a uma classe ou subclasse com a soma das velocidades de download maior que a da classe ou

78 77 subclasse (O IP que ultrapassar o valor não deve ser adicionado e retornar um erro) TA4.6 Modificar uma ou mais informação no IP já adicionado, sem ultrapassar o valor de download se for informado um outro valor para o campo ( Modificação efetuada com sucesso) TA4.7 Modificar o endereço de IP no IP já adicionado que seja igual ao endereço IP de outro IP, sem ultrapassar o valor de download se for informado um outro valor para o campo ( Modificação não efetuada com sucesso e retornar um erro) TA4.8 Modificar a informação de donwload e que esse ultrapasse o valor da soma dos IP ou faixa de IP associados a classe ou subclasse ( Modificação não efetuada com sucesso e retornar o erro) TA4.9 Remover um IP (Remoção efetuada com sucesso) TA4.10 Reiniciar o Serviço (Reiniciar as regras de QoS) US05 Implementar o QoS por Faixa de IP Estimativa inicial: 24h TA5.1 Adicionar uma faixa de IP com todos os dados corretos (A faixa de IP adicionada com sucesso) TA5.2 Adicionar uma faixa de IP sem informa todos os campos obrigatórios (A faixa de IP não deve ser adicionada e retornar um erro) TA5.3 Adicionar uma faixa de IP já adicionada anteriormente (A faixa de IP não deve ser adicionada e retornar um erro) TA5.4 Adicionar uma faixa de IP com a velocidade de download maior que a da classe ou subclasse pertencente (A faixa de IP não deve ser adicionada e retornar um erro) TA5.5 Adicionar duas ou mais faixa de IP pertencentes a uma classe ou subclasse com a soma das velocidades de download maior que a da classe ou subclasse (A faixa de IP que ultrapassar o valor não deve ser adicionada e retornar um erro) TA5.6 Modificar uma ou mais informação na faixa de IP já adicionada, sem ultrapassar o valor de download se for informado um outro valor para o campo ( Modificação efetuada com sucesso) TA5.7 Modificar o endereço de faixa de IP na faixa de IP já adicionada que seja igual ao endereço de faixa de outra faixa de IP já inserida, sem

79 78 ultrapassar o valor de download se for informado um outro valor para o campo ( Modificação não efetuada com sucesso e retorna o erro) TA5.8 Modificar a informação de donwload e que esse ultrapasse o valor da soma dos IP ou das faixas de IP associados a classe ou subclasse ( Modificação não efetuada com sucesso e retornar o erro) TA5.9 Remover uma faixa de IP (Remoção efetuada com sucesso) TA5.10 Reiniciar o Serviço (Reiniciar as regras de QoS) US06 Implementar prioridade em serviços no Qos Estimativa inicial: 14h TA6.1 Ativar e salvar (Ativação salva com sucesso) TA6.2 Desativar e salvar (Desativação salva com sucesso) TA6.3 Adicionar uma regra de prioridade com todos os dados corretos (Regra adicionada com sucesso) TA6.4 Adicionar uma regra de prioridade sem informa todos os campos obrigatórios (A regra não deve ser adicionada e retornar um erro) TA6.5 Adicionar uma regra de prioridade com o mesmo protocolo e porta já adicionada anteriormente (A regra não deve ser adicionada e retornar um erro) TA6.6 Modificar uma ou mais informação na regra já adicionada ( Modificação efetuada com sucesso) TA6.7 Modificar o protocolo e porta na regra já adicionada que seja igual em outra regra( Modificação não efetuada com sucesso e retornar um erro) TA6.8 Remover uma regra de prioridade (Remoção efetuada com sucesso) TA6.9 Reiniciar o Serviço (Reiniciar as regras de QoS) US07 Incluir funcionalidade de login Estimativa inicial: 5h TA7.1 Acessar o sistema a partir de um login valido (Autentica feita com sucesso) TA7.2 Acessar o sistema a partir de um login invalido (Mensagem de erro) US08 Elaborar ajuda Estimativa inicial: 8h TA8.1 Verificar se todas as telas tem ajudas necessárias no auxilio da tarefa

80 79 APÊNDICE D - PROTÓTIPO DA INTERFACE Protótipo da Interface: Acesso ao Sistema Protótipo da Interface: Seleção da Interface de Rede (Internet) Protótipo da Interface: Classes e Subclasses

81 80 Protótipo da Interface: QoS por IP Protótipo da Interface: QoS por Faixa de IP Protótipo da Interface: Prioridade de Serviços

82 81 APÊNDICE E - PROJETO ARQUITETURAL Servidor Jetty Navegador Servlet JSP Web Container Shell Tc e iptables Máquina do Cliente JavaBean Classes Java Projeto Arquitetural do Sistema Banco de Dados Descrição do Projeto Arquitetural O projeto obedece o padrão de n-camadas, constituído pela camada de apresentação, de aplicação e pela camada de persistência de dados. A interface usa um navegador de onde é exibida paginas HTML geradas pelo servidor JETTY, servidor de web container que sera embutido no sistema, podendo ser aplicada em ambientes de intranet ou internet. A logica da aplicação, como o acesso ao banco de dados que utilizara os padrões de projeto Query Object e Composite Pattern e a execução dos comandos tc e iptables no shell do linux, sera implementada em componentes JavaBeans. Na camada de persistência de dados sera usado APIs JDBC (Java Database Connectivity) e SQL (Structured Query Language) do banco de dados relacional h2 da google que também sera embutido no sistema.

83 82 APÊNDICE F - MODELO LÓGICO DE DADOS Modelo Lógico de Dados