Avaliação da Teoria de SistemasNormalizados na Implementação de SI

Evolutivos

André Filipe Saraiva Varela(Licenciado em Engenharia Informática e de Computadores)

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Júri

Presidente A definirOrientador Prof. Doutor Carlos Nuno da Cruz Ribeiro

Co-Orientador Prof. Doutor André Ferreira Ferrão Couto e VasconcelosCo-Orientador Empresarial Eng. Gonçalo Caseiro

Vogal Prof. António Manuel Ferreira Rito da Silva

Julho 2011

AbstractNowadays, there are increasingly volatile environments on enterprises. As these organizations faceeven faster changes in terms of markets, stakeholders, technologies and products, these require everincreasing levels of evolvability in order to respond quickly. Additionally, there are more mechanismsto ensure quality than before; services and products, and their distribution are now more tailored to theneeds of customers, which usually increase the complexity of Information Systems.

Nevertheless, the current Information Systems follow strictly the customers’ requirements, leadingto multiple dependencies. Whenever it’s needed to change/add business objectives, it becomes veryhard to modify these systems, increasing the risk of having to develop a new system (considering aworst case).

This dissertation goal is to evaluate if the Normalized Systems theory allows organizations to deliverfast and effective changes, as well as increase the complexity of the Information Systems (e.g. increasenumber of functionalities, requirements and interfaces) - making them agile and evolutionary.

The proposed methodology consists in applying Normalized Systems theory in the developmentof an E-Voting System. Initially, in conformity with the theory of Normalized Systems, the mappingof business processes relevant to the voting process was done; after this step, a Normalized E-VotingSystem was implemented, based on this mapping. Afterwards, by using another system (similar to theone developed) it was possible to prove the usefulness of the theory in the development of evolutionaryinformation systems, through the analysis of some quantitative software evaluation metrics (applied toboth).

i

Keywords:Normalized Systems theoryComplexityChangeAgilityEvolutionInformation SystemElectronic Voting

ii

ResumoActualmente, verifica-se que o ambiente das empresas é altamente volátil. À medida que as empre-sas enfrentam uma mudança cada vez mais rápida em termos de mercados, stakeholders, tecnologiase produtos, estas requerem níveis de capacidade evolutiva cada vez mais altos para poder responderrapidamente a estas mudanças. Para além disto, existem mais controlos de qualidade do que antes, osbens e serviços são comercializados a um maior e crescente número de mercados internacionais, tendosempre em atenção as preferências do cliente, o que implica o aumento da complexidade dos Sistemasde Informação.

Contudo, a realidade é que os sistemas actuais são bastante fiéis ao que é pedido pelos clientes, oque faz com que tenham bastantes dependências. Quando é necessário mudar/adicionar objectivos denegócio torna-se, por vezes, complicado proceder a alterações em sistemas com muitas dependências,existindo o risco de ser necessário o desenvolvimento de um novo sistema (no pior caso).

O grande objectivo deste trabalho é avaliar se a teoria de Sistemas Normalizados permite às or-ganizações, agir rápido e eficientemente à mudança e ao aumento da complexidade dos seus SI (e.g.aumento do número de funcionalidades, requisitos e interfaces) - tornando-as ágeis e evolutivas.

A metodologia proposta consiste em aplicar a teoria de Sistemas Normalizados no desenvolvimentode um Sistema de Voto Electrónico. Inicialmente, foi efectuado o mapeamento dos processos de negócio,respectivos ao processo de votação, nos elementos descritos na teoria; e de seguida, implementado oSistema de Voto Electrónico Normalizado, com base nesse mapeamento. Através da utilização de umoutro sistema similar ao desenvolvido, foi possível comprovar, posteriormente, a utilidade da teoria nodesenvolvimento de SI evolutivos, através da análise quantitativa de algumas métricas de avaliação desoftware, aplicadas aos dois sistemas.

iii

Palavras-Chave:Teoria de Sistemas NormalizadosComplexidadeMudançaAgilidadeEvoluçãoSistema de InformaçãoVoto Electrónico

iv

AgradecimentosGostaria de agradecer ao Professor André Vasconcelos pela orientação dada ao longo da realizaçãodesta dissertação, pela sua persistência, disponibilidade, espírito crítico e foco na melhoria contínua nodecorrer desta investigação.

Do lado empresarial, gostaria de agradecer à Engenheira Fátima Carrão e aos Engenheiros, João Ri-cardo Vasconcelos e Gonçalo Caseiro, pelo acompanhamento, disponibilidade e ajuda prestada, sempreque necessitava.

À AMA, pela cedência de um espaço físico, agradável, para a realização do trabalho de Mestrado.A todos os colegas com quem trabalhei, em especial o Tiago Vieira, Pedro Vicente, Rui Silva, Pedro

Jacinto e António Tomé, que ao longo do curso, e especialmente nesta última fase, me auxiliaram comsugestões, informações, ideias ou palavras de incentivo.

À Associação de Estudantes e ao aluno André Brioso por me fornecerem os alicerces necessários demodo a conseguir testar e avaliar o meu sistema.

Ao Luís Crato, João Santos, Liliana Veríssimo, Sónia Ferreira, Débora André, Rita Olivença, RoxanneGarrana e Fernando Saraiva por estarem sempre presentes na minha vida.

E por último, mas definitivamente não menos importante, deixo um agradecimento e dedicatória es-pecial à minha família, em especial à minha mãe - Maria Alice Nunes Saraiva Varela, ao meu pai - NunoPaulo de Jesus Varela - e à minha irmã - Patrícia Alexandra Saraiva Varela, por terem sempre acreditadoem mim e pelo apoio constante ao longo de todo este tempo, sem o qual dificilmente conseguiria su-perar os desafios que vão surgindo no dia-a-dia.

Julho 2011André Filipe Saraiva Varela

v

Em memória dos meus avós,Francisco Saraiva, Ivone Saraiva e Elisabete Varela.

vi

Conteúdo

Abstract i

Resumo iii

Agradecimentos v

Notações xi

Lista de Figuras xiv

Lista de Tabelas xv

Lista de Programas xvii

Acrónimos xix

1 Introdução 11.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Hipóteses de Investigação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Metodologia de Investigação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

I Estudo do Problema

2 Estado-da-Arte 72.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Inflexibilidade dos Sistemas de Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Manutenção Correctiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Manutenção de Melhoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Métricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Teoria dos Sistemas Normalizados 133.1 Aplicação da Teoria no Desenvolvimento de Sistemas de Informação . . . . . . . . . . . . 133.2 Mapeamento de Processos de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Vantagens de Sistemas Normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Desvantagens de Sistemas Normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

vii

4 Caso de Estudo 19

4.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Recenseamento Eleitoral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.2 Processo de Votação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.3 Contagem dos Votos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.4 Divulgação dos Votos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Votação Electrónica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Experiências em Território Nacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Casos de Estudo - Sistemas Electrónicos Estrangeiros . . . . . . . . . . . . . . . . . . . . . 26

4.4.1 Caso do Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4.2 Caso da Estónia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Resumo dos Sistemas Analisados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.6 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

II Resposta ao Problema

5 Solução Proposta 35

5.1 Modelo da Teoria de Sistemas Normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Mapeamento dos Processos de Negócio em Fluxos de Negócio . . . . . . . . . . . . . . . . 36

5.3 Desenho do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Fluxos de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.1 Inscrição do Utilizador no Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.2 Autenticação do Utilizador no Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4.3 Inscrição do Eleitor no Caderno Eleitoral . . . . . . . . . . . . . . . . . . . . . . . . 41

5.4.4 Validação do Eleitor no Caderno Eleitoral . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4.5 Criação de um Boletim de Voto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4.6 Realização do Voto pelo Eleitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4.7 Processar cada Voto recebido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.8 Calcular os Resultados da Eleição . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.9 Iniciar/Encerrar a Urna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.5 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Implementação 49

6.1 Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.1 Camada: Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.2 Camada: Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.3 Camada: Workflows - Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.4 Camada: Workflows - Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.5 Camada: Workflows - Tasks - FunctionalTasks . . . . . . . . . . . . . . . . . . . . . . . 54

6.1.6 Camada: Workflows - Tasks - IOTasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1.7 Camada: Workflows - Tasks - SupportTasks . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1.8 Camada: Workflows - Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.1.9 Camada: Workflows - Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2 Exemplos de Código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

viii

7 Validação 617.1 Avaliação do Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.2 Validação da Teoria de Sistemas Normalizados . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.2.1 Métrica: Tempo de Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.2.2 Métrica: Tempo de Conclusão do Teste . . . . . . . . . . . . . . . . . . . . . . . . . 647.2.3 Métricas: Número de Linhas de Código Acrescentadas / Número de Métodos

Criados / Número de Classes Criadas . . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.4 Métrica: Acoplamentos Adicionados entre Módulos . . . . . . . . . . . . . . . . . . 677.2.5 Métrica: Número de Erros Cometidos . . . . . . . . . . . . . . . . . . . . . . . . . . 687.2.6 Métrica: Complexidade Ciclomática . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.2.7 Discussão de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.3 Discussão Geral dos Resultados Atingidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

III Observações Finais

8 Conclusões 738.1 Conclusões Principais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.2 Análise de Contributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.2.1 SVE Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.2.2 Modelo Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.3 Limitações do Trabalho Realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9 Trabalho Futuro 779.1 Protótipo de SVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9.1.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.1.2 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779.1.3 Transacções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789.1.4 Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.2 Teoria de Sistemas Normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789.2.1 Mapeamento Processos de Negócio nos Elementos da Teoria de Sistemas Normal-

izados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789.2.2 Normalização de Arquitecturas de Sistemas de Informação . . . . . . . . . . . . . 789.2.3 Comparação da teoria de SN com outras Teorias . . . . . . . . . . . . . . . . . . . . 79

IV Referências

Bibliografia 85

V Anexos

10 Anexos 8910.1 Fases do Protocolo de Voto do Prótotipo Auxiliar Utilizado . . . . . . . . . . . . . . . . . . 8910.2 Testes para a Validação da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.3 Modelo de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10.3.1 Authentication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.3.2 Electoral Notebook Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9910.3.3 Vote Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

ix

10.3.4 Ballot Box Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10710.4 Evoluções das Abstrações e Metodologias para o Desenvolvimento de Software . . . . . . 111

x

NotaçõesEnquanto lê esta dissertação, o leitor vai-se aperceber de que existem outras estruturas para além dohabitual texto, figuras e tabelas. Estas novas estruturas têm como objectivo melhorar a organização dasideias expressas neste trabalho. Deste modo, para uma melhor compreensão da dissertação, são expli-cadas nesta secção estas estruturas.

DefiniçãoPor exemplo, sempre que um conceito importante ou relevante precisa ser definido, uma caixa

cinzenta com o conceito em destaque, a negrito, é apresentada. A seguinte definição funciona comoum exemplo:

Uma definição é uma passagem, geralmente em prosa, descrevendo o significado de uma palavra oufrase.

Contudo, nem todas as definições são apresentadas desta maneira e desse modo não é errado repre-sentar alguns conceitos fora dessas caixas. Estas estruturas serão usadas apenas em situações relevantesonde a definição merece destaque em relação ao texto normal.

Fragmento de CódigoSempre que for necessário ilustrar uma ideia ou exemplo usando fragmentos de código, a linguagem

de programação usada será o C#, tal como se exemplifica de seguida:

Programa 1: HelloWorld.cs

1 ...2 public static void main(String args[]) {3 System.Windows.Forms.MessageBox.Show("Hellow World!");

4 }5 ...

O Programa 1 representa um fragmento de código do ficheiro HelloWorld.cs. Contudo, as reticências(...) antes e depois do código ilustram que o código apresentado corresponde apenas a um fragmentode todo o ficheiro. Os números das linhas apresentadas, podem não corresponder às actuais no ficheiro,servindo apenas como referência.

Mapeamento de Processos de Negócio em FluxosO mapeamento dos processos de negócio, realizado no capítulo 5 desta dissertação, tem por base a

representação usada no capítulo 8 do livro de Sistemas Normalizados [1]. Esta representação, apesarde semelhante com um diagrama de estados, está longe de estar formalizada e desse modo convém serexplicada.

Em cada fluxo são representados tanto Elementos de Acção, tabela 3.2 - definição 15, que especificamacções com a forma de caixas amarelas; como o estado resultante (círculos pretos) de cada uma dessasacções.

xi

Eis um exemplo:

Figura 1: Exemplo do mapeamento entre processos de negócio e fluxos de negócio.

Este exemplo apresenta todas as acções que operam sobre um único Elemento de Dados com ciclode vida, tabela 3.2 - definição 14. Após a criação da instância, esta toma o estado de CREATED. Deseguida é executada uma Action 1 sobre essa instância, desde que ela esteja no estado CREATED. Apósa execução de uma acção, podem existir, ou não, vários caminhos resultantes, sobre os quais a instânciapode prosseguir, sendo que neste caso são somente dois: Action 1 Not Realized ou Action 1 Realized.

Agora que estas novas estruturas foram apresentadas, esperamos que o leitor consiga ler e entenderas ideias expostas nesta dissertação.

xii

Lista de Figuras1 Exemplo do mapeamento entre processos de negócio e fluxos de negócio. . . . . . . . . . xii

1.1 Etapas do método Action Research (imagem retirada de [6]) . . . . . . . . . . . . . . . . . . 31.2 Estrutura da dissertação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4.1 Casos de uso: fases do processo de voto em Portugal . . . . . . . . . . . . . . . . . . . . . 204.2 Actores que interagem com o sistema eleitoral português . . . . . . . . . . . . . . . . . . . 204.3 Processo de identificação e inscrição do eleitor antes de votar . . . . . . . . . . . . . . . . . 224.4 Processo de voto após identificação e inscrição do eleitor . . . . . . . . . . . . . . . . . . . 224.5 Processo de contagem dos votos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.6 Experiências de voto electrónico em Portugal . . . . . . . . . . . . . . . . . . . . . . . . . . 254.7 Arquitectura do SVE da Estónia (imagem retirada de [45]) . . . . . . . . . . . . . . . . . . 28

5.1 Modelo da arquitectura de SN - todos os elementos correspondem a classes abstractas. . . 365.2 Casos de uso referentes a cada módulo do sistema. . . . . . . . . . . . . . . . . . . . . . . . 385.3 Diagrama de componentes do SVE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Fluxo de negócio: inscrição do utilizador no sistema - ClientFlow. . . . . . . . . . . . . . . 405.5 Fluxo de negócio: autenticação do utilizador no sistema - AuthenticationFlow. . . . . . . . 415.6 Fluxo de negócio: inscrição do eleitor no caderno eleitoral - ElectorFlow. . . . . . . . . . . 425.7 Fluxo de negócio: validação do eleitor no caderno eleitoral - ValidationFlow. . . . . . . . . 425.8 Fluxo de negócio: criação de um boletim de voto - BallotFlow. . . . . . . . . . . . . . . . . 435.9 Fluxo de negócio: realização do voto pelo eleitor - VoteFlow. . . . . . . . . . . . . . . . . . 445.10 Fluxo de negócio: processar cada voto recebido - ProcessVoteFlow. . . . . . . . . . . . . . . 455.11 Fluxo de negócio: calcular os resultados da eleição - ResultFlow. . . . . . . . . . . . . . . . 465.12 Fluxo de negócio: iniciar/encerrar a urna - BallotBoxFlow. . . . . . . . . . . . . . . . . . . 47

6.1 Vista Módulo: decomposição do SVE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Vista Módulo: utilização dos módulos do SVE. . . . . . . . . . . . . . . . . . . . . . . . . . 506.3 Vista Módulo: decomposição de cada módulo. . . . . . . . . . . . . . . . . . . . . . . . . . 516.4 Diagrama de classes em UML representando Data Elements. . . . . . . . . . . . . . . . . . 526.5 Exemplo de uma das interfaces do SVE: registo de novo User. . . . . . . . . . . . . . . . . 526.6 Diagrama de classes em UML representando Action Elements. . . . . . . . . . . . . . . . . 536.7 Diagrama de classes em UML representando Connector Elements. . . . . . . . . . . . . . . . 546.8 Diagrama de classes em UML representando Functional Tasks. . . . . . . . . . . . . . . . . 546.9 Diagrama de classes em UML representando IO Tasks. . . . . . . . . . . . . . . . . . . . . . 556.10 Diagrama de classes em UML representando Support Tasks. . . . . . . . . . . . . . . . . . . 556.11 Exemplo da execução da Tarefa de Suporte - SupportTask-Print - no AuthenticationServer. . 556.12 Exemplo em XML do resultado da execução da Tarefa de Suporte - SupportTask-Save - no

AuthenticationServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.13 Diagrama de classes em UML representando Views. . . . . . . . . . . . . . . . . . . . . . . 566.14 Diagrama de classes em UML representando Workflows. . . . . . . . . . . . . . . . . . . . . 57

xiii

6.15 Vista Módulo: utilização/camadas de cada módulo. . . . . . . . . . . . . . . . . . . . . . . 57

7.1 Gráfico: desvantagens do SVE na opinião dos utilizadores. . . . . . . . . . . . . . . . . . . 617.2 Exemplo de uma das interfaces do SVE: escolha da opção de voto pretendida. . . . . . . . 627.3 Gráfico: vantagens do SVE na opinião dos utilizadores. . . . . . . . . . . . . . . . . . . . . 627.4 Resultado das eleições para a direcção da AEIST. . . . . . . . . . . . . . . . . . . . . . . . . 637.5 Gráfico de validação: tempo de análise do teste. . . . . . . . . . . . . . . . . . . . . . . . . 657.6 Gráfico de validação: tempo de conclusão do teste. . . . . . . . . . . . . . . . . . . . . . . . 657.7 Gráfico de validação: número de linhas de código acrescentadas. . . . . . . . . . . . . . . 667.8 Gráfico de validação: número de métodos criados. . . . . . . . . . . . . . . . . . . . . . . . 667.9 Gráfico de validação: número de classes criadas. . . . . . . . . . . . . . . . . . . . . . . . . 677.10 Gráfico de validação: acoplamentos adicionados entre módulos. . . . . . . . . . . . . . . . 677.11 Gráfico de validação: número de erros cometidos. . . . . . . . . . . . . . . . . . . . . . . . 687.12 Gráfico de validação: complexidade ciclomática. . . . . . . . . . . . . . . . . . . . . . . . . 68

10.1 Fases do Protocolo de Voto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.2 Validação: interface de confirmação de voto. . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.3 Modelo de domínio: Authentication Server - Data Elements . . . . . . . . . . . . . . . . . . . 9510.4 Modelo de domínio: Authentication Server - Workflow Elements . . . . . . . . . . . . . . . . 9510.5 Modelo de domínio: Authentication Server - Action Elements . . . . . . . . . . . . . . . . . . 9610.6 Modelo de domínio: Authentication Server - Connector Elements . . . . . . . . . . . . . . . . 9710.7 Modelo de domínio: Authentication Server - IO Tasks . . . . . . . . . . . . . . . . . . . . . . 9710.8 Modelo de domínio: Authentication Server - Support Tasks . . . . . . . . . . . . . . . . . . . 9710.9 Modelo de domínio: Authentication Server - Functional Tasks . . . . . . . . . . . . . . . . . . 9810.10Modelo de domínio: Electoral Notebook Server - Data Elements . . . . . . . . . . . . . . . . . 9910.11Modelo de domínio: Electoral Notebook Server - Workflow Elements . . . . . . . . . . . . . . 9910.12Modelo de domínio: Electoral Notebook Server - Action Elements . . . . . . . . . . . . . . . . 10010.13Modelo de domínio: Electoral Notebook Server - Connector Elements . . . . . . . . . . . . . . 10110.14Modelo de domínio: Electoral Notebook Server - IO Tasks . . . . . . . . . . . . . . . . . . . . 10110.15Modelo de domínio: Electoral Notebook Server - Support Tasks . . . . . . . . . . . . . . . . . 10110.16Modelo de domínio: Electoral Notebook Server - Functional Tasks . . . . . . . . . . . . . . . . 10210.17Modelo de domínio: Vote Server - Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . 10310.18Modelo de domínio: Vote Server - Workflow Elements . . . . . . . . . . . . . . . . . . . . . . 10310.19Modelo de domínio: Vote Server - Action Elements . . . . . . . . . . . . . . . . . . . . . . . . 10410.20Modelo de domínio: Vote Server - Connector Elements . . . . . . . . . . . . . . . . . . . . . . 10510.21Modelo de domínio: Vote Server - IO Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10510.22Modelo de domínio: Vote Server - Functional Tasks . . . . . . . . . . . . . . . . . . . . . . . . 10610.23Modelo de domínio: Vote Server - Support Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 10710.24Modelo de domínio: Ballot Box Server - Data Elements . . . . . . . . . . . . . . . . . . . . . . 10710.25Modelo de domínio: Ballot Box Server - Connector Elements . . . . . . . . . . . . . . . . . . . 10810.26Modelo de domínio: Ballot Box Server - IO Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 10810.27Modelo de domínio: Ballot Box Server - Action Elements . . . . . . . . . . . . . . . . . . . . . 10910.28Modelo de domínio: Ballot Box Server - Functional Tasks . . . . . . . . . . . . . . . . . . . . 11010.29Modelo de domínio: Ballot Box Server - Workflow Elements . . . . . . . . . . . . . . . . . . . 11110.30Modelo de domínio: Ballot Box Server - Support Tasks . . . . . . . . . . . . . . . . . . . . . . 111

xiv

Lista de Tabelas3.1 Teoremas da teoria de SN (retirados de [25]) . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Definições da teoria de SN (retiradas de [26]) . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Características dos sistemas de voto em cada país . . . . . . . . . . . . . . . . . . . . . . . 31

5.1 Mapeamento dos processos de negócio, relativos ao voto, em fluxos de negócio. . . . . . . 37

10.1 Evoluções que se verificaram tanto ao nível das abstrações na programação, como ao níveldas metodologias para o desenvolvimento de software . . . . . . . . . . . . . . . . . . . . 112

xv

Lista de Programas1 HelloWorld.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi6.1 ClientElement.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2 FirstClientWorkflow.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3 CreateClientAction.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.4 FunctionalTask_CreateClient.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6010.1 Validação: ClientElement.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.2 Validação: EnvelopeElement.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.3 Validação: ShowConfirmationVoteConnector.cs . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.4 Validação: IOTask_ShowConfirmationVote.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.5 Validação: FifthVoteWorkflow.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.6 Validação: FunctionalTask_LoginFlow.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.7 Validação: EnvelopeWorkflow.cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

xvii

Acrónimos

AEIST Associação dos Estudantes do Instituto Supe-rior Técnico

AMA Agência para a Modernização Administrativa

DRE Direct-Recording Electronic

OO Orientado a Objectos

SI Sistema de InformaçãoSN Sistemas NormalizadosSTAPE Secretariado Técnico dos Assuntos para o Pro-

cesso EleitoralSVE Sistema Voto Electrónico

TIC Tecnologia de Informação e Comunicação

UML Unified Modeling Language

VE Voto Electrónico

XML eXtensible Markup Language

xix

”O que importa é partir, não é chegar.”- Miguel Torga

xx

1Introdução

”Other people look at things that are andask themselves

how they possibly could have been done.I see things that are not

and ask myself why they haven’t been done.”- Robert F. Kennedy

1.1 Enquadramento

As organizações modernas são responsáveis pela produção dos mais avançados serviços e produtos,procurando, constantemente, novas oportunidades de negócio. Isto deve-se aos SI, que se tornaramvitais para a eficiência da maioria das organizações.

Contudo, verificam-se alguns problemas na manutenção desses SI. Tal como dita a lei de MannyLehman [2, 3], a adição de novas funcionalidades no SI, torna-se cada vez mais complexa, e por suavez, mais dispendiosa com o passar do tempo, o que dificulta a vida das organizações que pretendemresponder, rapidamente, à mudança e ao aumento da complexidade.

Esta dificuldade resulta do elevado número de dependências que os SI possuem. Desse modo, mu-dar ou adicionar objectivos de negócio é uma tarefa complicada que exige muito esforço e tempo, ex-istindo, em último caso, o risco de ser necessário desenvolver um novo sistema [4].

Os SI devem suportar organizações que se comportam como empresas ágeis. Só desta maneira, asorganizações podem agir, rapidamente, tanto à mudança como ao aumento da complexidade. Assimsendo, é necessário a existência de mecanismos que consigam diminuir a dimensão deste problema daactualidade. A teoria estudada neste trabalho - teoria de SN - surge para endereçar este problema.

1.2 Definição do Problema

O problema que a dissertação aborda é subsumível à seguinte questão:

• Será que a aplicação da teoria de Sistemas Normalizados no desenvolvimento de Sistemas de Informação,permite efectuar mudanças e aumentar a complexidade do sistema, com esforço e tempo reduzidos, na fase demanutenção?

Esta questão é subdividida em duas questões mais específicas:

1

1. Será possível aplicar as características da teoria de SN no desenvolvimento de um SI?2. Com base nesse desenvolvimento, será possível alterar/adicionar funcionalidades ao SI, com es-

forço e tempo menores, em comparação com outro sistema não normalizado?

O esforço pode ser entendido como a dificuldade em executar uma dada tarefa, na fase de manutençãode SI. Por exemplo, na realização de uma tarefa podem ser obtidos erros, muitas vezes associados adependências no SI, que dificultam a realização de mudanças. Nestes casos o esforço de realizar umadada tarefa é maior, dado que temos de desfazer algumas dependências, para a incluir.

1.2.1 Hipóteses de Investigação

Com base nas questões formuladas no capítulo anterior ( 1.2), de forma a auxiliar a investigação re-alizada, estruturou-se um conjunto de hipóteses de investigação com o intuito de guiar e auxiliar arealização da presente dissertação [5].

As hipóteses de investigação consideradas são as seguintes:

H1. É possível aplicar as características da teoria de SN no desenvolvimento de um SI;H2. É possível mudar/adicionar funcionalidades ao SI desenvolvido, com esforço e tempo inferiores,

em comparação com outro sistema não normalizado.

Todas as hipóteses endereçam a macro questão definida no capítulo 1.2.

No caso da questão 1) esta é endereçada pela hipótese de investigação H1, remetendo-se ambas paraas características, da teoria de SN, descritas no capítulo 3.1. A questão 2) é endereçada pela hipóteseH2, estando focada no esforço e tempo da manutenção de um SI.

1.3 Objectivos

Os SI devem suportar organizações que se comportam como empresas ágeis. Assim, o grande objectivodeste trabalho centra-se em encontrar uma solução que permita, às organizações, agir de forma rápidae eficiente à mudança e ao aumento da complexidade dos seus SI - tornando-as ágeis e evolutivas.

De modo a cumprir este objectivo, pretende-se aprofundar os conhecimentos sobre a teoria de SNe aplicá-los num caso de estudo, de forma a avaliar o potencial da mesma na concepção de SI evolu-tivos. O âmbito do caso de estudo é o Voto Electrónico, e assim sendo, será efectuado o mapeamento dosprocessos de negócio, respectivos ao processo de votação, nos elementos descritos na teoria; e imple-mentado um SVE normalizado, com base nesse mapeamento. Através da utilização de um outro SVEsimilar ao desenvolvido, será possível avaliar a utilidade da teoria, através da análise quantitativa dealgumas métricas de avaliação de software, aplicadas aos dois sistemas.

Não entram no âmbito desta dissertação, questões relacionadas com a temática da segurança ou comparticularidades específicas de um SVE (ex. interface agradável e apelativa); avaliações feitas à teoriade SN, baseadas noutros casos de estudo (outros âmbitos); o estudo de outras teorias que tornem os SIevolutivos; ou a análise de métricas sem ser as de software.

1.4 Metodologia de Investigação

Numa investigação científica deve recorrer-se a um procedimento de modo a atingir a solução. Ométodo usado nesta investigação foi o Action Research [6].

2

Este método permite responder às preocupações das pessoas para um problema imediato - a acção- e aprender com o processo, aumentando o conhecimento na comunidade científica - a pesquisa. Oinvestigador é considerado como um membro da organização, pois envolve-se na mesma [7].

Esta metodologia pode ser descrita por um processo cíclico constituído por cinco fases, que se en-contram representadas na figura 1.1.

Figura 1.1: Etapas do método Action Research (imagem retirada de [6])

O processo define-se da seguinte maneira: inicialmente, investigou-se e estabeleceu-se o problema deinvestigação que causa o desejo de mudança - Diagnosing. De seguida, foram investigadas e planeadas asacções para resolver esses problemas - Action Planning - sendo investigado o estado da arte relacionadocom os problemas de manutenção que contribuem para a não evolução dos SI, a teoria de SN e SVE; eelaborado uma possível solução para mitigar o problema identificado. Terminada essa tarefa executam-se as acções definidas no passo anterior - Action Taking, ou seja, realiza-se a implementação da soluçãoproposta. De seguida, é necessário avaliar se as acções realizadas resolveram os problemas - Evaluation,e neste trabalho esta componente refere-se à avaliação do SVE normalizado desenvolvido com basenum outro SVE. Apesar de estar, formalmente, posicionada na última fase do ciclo, a fase de SpecifyingLearning normalmente ocorre em paralelo com todo o processo e serve para especificar o conhecimentoresultante de cada fase, correspondendo à escrita da dissertação.

Outras iterações ao ciclo e, obviamente, ao trabalho realizado, podem ser efectuadas, sendo apresen-tados, no capítulo 9, alguns caminhos possíveis para as iniciar.

1.5 Organização do Documento

Tal como apresentado na figura 1.2, esta dissertação está dividida em nove capítulos, oito deles contidosem três parte lógicas: Estudo do Problema, Resposta ao Problema e Observações Finais.

Figura 1.2: Estrutura da dissertação.

3

Para além destas três partes, existe o capítulo da Introdução. Inicialmente, é efectuada a contextual-ização da área de aplicação do trabalho ( 1.1 e 1.3) e o problema que esta endereça ( 1.2), bem como ashipóteses de investigação ( 1.2.1) e a metodologia de investigação utilizada ( 1.4).

A parte de Estudo do Problema descreve os conceitos teóricos deste trabalho de Mestrado: Estado daArte, Teoria de Sistemas Normalizados e Caso de Estudo, no âmbito do VE. O capítulo de Estado da Arte ( 2)retrata tanto os problemas dos SI actuais, que dificultam tanto a sua agilidade como a evolução dosmesmos, como algumas métricas para avaliação de software. De seguida, é apresentada a Teoria de Sis-temas Normalizados ( 3), que é a base da solução apresentada por este trabalho. Por fim, são identificadosalguns aspectos importantes de SVE, dado ser nesse âmbito que teoria de SN será aplicada - capítuloCaso de Estudo ( 4).

A parte de Resposta ao Problema diz respeito à Solução Proposta ( 5), à sua Implementação ( 6) e à respec-tiva Validação ( 7). No capítulo da Solução Proposta, uma solução para resolver o problema é apresentada.O capítulo da Implementação descreve todo o desenvolvimento do protótipo, de acordo com a soluçãoproposta. Depois de desenvolvido o protótipo, é realizada a correspondente validação no capítulo daValidação, onde será avaliado o potencial da teoria de SN.

Finalmente, a parte de Observações Finais é composta por dois capítulos: Conclusões ( 8) e TrabalhoFuturo ( 9). No capítulo de Conclusões, algumas conclusões sobre o trabalho realizado são apresentadas,assim como, as principais contribuições e limitações. De seguida, no capítulo de Trabalho Futuro, sãoapresentadas algumas linhas possíveis de serem seguidas, no futuro, de modo a expandir este trabalho.

4

IEstudo doProblema

2Estado-da-Arte

”Knowledge is of two kinds:we know a subject ourselves,

or we know where we can find information upon it.”- Samuel Johnson

O objectivo deste trabalho de investigação é avaliar se a teoria de SN, aplicada no desenvolvimentode SI, permite agir rápida e eficientemente à mudança e ao aumento de complexidade. Estes dois fac-tores são os responsáveis pela falta de agilidade e flexibilidade que os SI actuais enfrentam na fase demanutenção. Este capítulo começa por enquadrar este problema, que atinge muitos SI actuais. Deseguida, são abordadas métricas de avaliação de software. Estas vão ser aplicadas, com o intuito demedir a facilidade de manutenção do software, na fase de validação da solução proposta, por forma aavaliar a utilidade da aplicação da teoria de SN no desenvolvimento de SI susceptíveis a mudanças e aoaumento da complexidade.

2.1 Contexto

As organizações modernas são responsáveis pela produção dos mais avançados serviços e produtosalguma vez produzidos. Estas organizações pesquisam novas oportunidades de negócio para integrarnos seus serviços e produtos e tentam responder, rapidamente, às mesmas. Isto deve-se aos SI, que setornaram vitais para a eficiência da maioria das organizações.

Laudon define um SI de duas perspectivas [8]:

• De uma perspectiva técnica, um SI recolhe, armazena e dissemina a informação recolhida do am-biente da organização e de operações internas para suportar funções organizacionais, e de apoioà decisão, comunicação, coordenação, controlo, análise e visualização. Os SI transformam dadosem informação útil através de três actividades básicas: input, processamento, output;

• De uma perspectiva de negócio, um SI providencia a solução para um problema ou desafio comque a empresa se depara e representa a combinação de elementos de gestão, organização e tec-nologia. A gestão envolve questões relacionadas com a liderança, estratégia e comportamento degestão. A tecnologia consiste no hardware, software, dados e rede/telecomunicações. Por fim, aorganização envolve questões relacionadas com a hierarquia da organização, especialidades fun-cionais, processos de negócio, cultura e grupos de interesses políticos.

Devido aos SI, as organizações passaram a lidar com [9]:

• Maior intensidade de informação;• Integração de informação estruturada com semi-estruturada e não estruturada;

7

• Maior integração intra-organizacional;• Maior integração inter-organizacional;• Maior suporte à decisão;• Maior necessidade de ter informação disponível em tempo-real;

Como resultado destas evoluções, as organizações estão cada vez mais dependentes dos seus SI.Uma mudança organizacional implica uma mudança no SI e vice-versa, uma mudança no SI, afecta osprocessos de negócio da organização.

2.2 Inflexibilidade dos Sistemas de Informação

Guy Fitzgerald refere que a manutenção de sistemas depois de implementados, absorve grandes quan-tidades de tempo e esforço [10]. Um estudo realizado por Boehm [11], refere que cerca de 70% docusto global do software é gasto na manutenção do mesmo, sendo que apenas 30% está disponívelpara o desenvolvimento de novos sistemas. A manutenção é geralmente decomposta em duas com-ponentes: trabalho correctivo e trabalho de melhoria [11], embora alguns autores tenham identificadotrês ou mesmo quatro categorias [12, 13]. O trabalho correctivo é aquele que é necessário realizar parao sistema estar de acordo com as especificações originais, ou seja, trabalho de reparação para superaros problemas de desenho e erros de implementação. O trabalho de melhoria consiste em realizar mu-danças no sistema, sempre que forem alterados os requisitos do cliente. Alguns estudos revelam que amanutenção correctiva apenas corresponde a uma pequena porção do total dos custos de manutenção,variando entre 2% e 12% [14].

Muitas tentativas têm sido feitas para reduzir os custos da manutenção, nomeadamente [10, 15]:

• O desenvolvimento de novas técnicas de engenharia de software que permitem desenvolver mel-hores desenhos e construções de programas (alguns exemplos encontram-se em Anexo, na tabela10.1);

• O aparecimento de novas métricas de software, métodos de inspecção e técnicas de garantia dequalidade do software.

2.2.1 Manutenção Correctiva

A manutenção correctiva apenas representa uma pequena proporção de toda a manutenção. Este tipo demanutenção surge quando as especificações dos requisitos do sistema não correspondem, verdadeira-mente, aos requisitos que o cliente pretende. Este problema advém, na maioria das vezes, da documen-tação [10]. Esta é, quase sempre, descritiva, particularmente, a especificação dos requisitos do cliente. Alinguagem natural, com descrições do tipo narrativo, não é a melhor maneira de especificar um processode forma não ambígua, visto que as descrições não sendo concisas nem precisas, são geralmente longas,não-estruturadas e repetitivas.

Contudo, algumas tentativas têm sido realizadas para tentar resolver o problema, das quais se desta-cam as técnicas gráficas para representar o processo de análise de requisitos [10]. Estas técnicas melho-ram a comunicação entre cliente-programador, embora não eliminem este problema.

2.2.2 Manutenção de Melhoria

Os dois desafios considerados cruciais para uma empresa ser ágil são o aumento da complexidade emudança [9].

8

2.2.2.1 Lei do Aumento da Complexidade

A lei do aumento da complexidade foi proposta por Manny Lehman. A lei foi formulada da seguintemaneira [2, 3]:

• "As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increasesunless work is done to maintain or reduce it."

Manny Lehman formulou esta lei no início de 1970. Esta lei refere que a adição de novas funcional-idades torna-se cada vez mais complexa, e, por sua vez, mais dispendiosa com o passar do tempo.Tal situação dificulta a vida das organizações, que pretendem responder rapidamente à mudança e aoaumento da complexidade.

Apesar da lei de Lehman nunca ter sido formalmente provada existem, alguns indicadores de queo processo de deterioração mencionado, de facto, existe. Primeiro, apesar do software não padecer dedegradação física (desgaste natural) podemos observar que os sistemas antigos são constantemente sub-stituídos por outros mais recentes e que, inclusivamente, nada adicionam em termos de funcionalidade[9]. A razão para a substituição pode estar relacionada com a tecnologia de software ou hardware se en-contrar obsoleta (ex. linguagem de programação já não é suportada, ou já não existem programadoresdisponíveis.). Contudo, esta situação pode dever-se também à lei de Lehman sobre o aumento da com-plexidade. A evolução de um SI não será drasticamente degradada com uma simples ou pequena mu-dança, mas caso sejam aplicadas várias mudanças já será, tornando cada vez mais elevado o custo derealizar uma mudança adicional. Segundo, vários especialistas referem que a manutenção dos sistemasse torna mais difícil com o passar do tempo [2, 16, 17]. Terceiro, outros investigadores têm tentadodescrever os sintomas associados com a deterioração dos sistemas em maior detalhe, embora ainda nãoexista uma precisa descrição desses sintomas [9].

2.2.2.2 Complexidade

Este crescente nível de complexidade deve-se à existência de mais controlos de qualidade do que antiga-mente, os bens e serviços são comercializados num maior e crescente número de mercados interna-cionais e a tomada de decisão é baseada num maior volume de informação do que nunca.

Os produtos e serviços, assim como a sua distribuição, são cada vez mais personalizados, consoanteas preferências do cliente, o que resulta num crescente número de variações de produtos. Não obstante, amaneira como as organizações e os seus processos de produção estão estruturados, também contribuempara o aumento da complexidade.

É impensável que uma empresa possa subsistir com uma estrutura simples e satisfazer todos os seusobjectivos de negócio [9]. Por exemplo, é compreensível que uma empresa ágil, atenta ao seu meioambiente, reagindo rapidamente a oportunidades, monitorizando a eficiência dos processos de negócioactuais, efectuando investigação e desenvolvimento de forma inovadora para desenvolver novos produ-tos, cumprindo as normas impostas por auditorias, sendo capaz de rapidamente encontrar capacidadesdentro e fora da organização, reportando medidas financeiras com uma precisão sem precedentes e fi-nalmente, operando de forma fiável em relação às operações críticas para a missão da organização, tenhaque saber gerir toda a complexidade inerente. Ao mesmo tempo, a distribuição dos bens passou a serfeita com recurso a mais do que um meio ou canal para multicanal, o que cria a complexidade adicionalda comunicação transversal aos diferentes canais de interacção de uma maneira consistente.

9

2.2.2.3 Mudança

No altamente volátil ambiente actual, a capacidade de mudança está, rapidamente, a tornar-se a carac-terística mais desejada para as organizações. Todas as médias e grandes empresas estão dependentes deSI críticos para a sua missão.

À medida que as empresas enfrentam uma mudança cada vez mais rápida em termos de mercados,stakeholders, tecnologias e produtos, estas requerem níveis de capacidade evolutiva cada vez mais altospara poder responder rapidamente a estas mudanças. Estes níveis são cada vez mais importantes, umavez que a sobrevivência das organizações encontra-se cada vez mais dependente da rapidez com que seconseguem adaptar à mudança, que é, num contexto alargado, imprevisível e incontrolável [9].

2.2.2.4 Mudanças Antecipadas

As necessidades de negócio dependem das circunstâncias externas actuais, e o cliente pode exigir quealguns requisitos sejam alterados ou incrementados no sistema, apesar dos custos em termos de tempoe esforço. Uma possibilidade para minimizar este problema é tentar prever as mudanças que podem vira acontecer no futuro. Land refere que a etapa de Análise de Flexibilidade deve ser adicionada ao processode desenvolvimento dos sistemas [18]. Esta etapa descreve a identificação das principais áreas de mu-danças possíveis que devem ser tomadas em consideração na fase de desenho de sistemas, de modo apermitir a realização das mesmas de forma relativamente fácil no futuro. Este tipo de análise torna ossistemas mais flexíveis e reduz os custos de manutenção [10]. Na prática é impossível prever todas asmudanças possíveis de acontecer, contudo, será bastante benéfico se algumas forem identificadas.

Land refere que as cinco grandes categorias de mudanças futuras são [18]:

• Mudanças na tecnologia disponível;• Mudanças nos requisitos;• Mudanças devido a factores económicos ou externos (ambiente externo);• Mudanças nas atitudes, expectativas, gostos ou opiniões;• Mudanças dentro da organização;

O estudo [19] realizado por Sutton sobre mudanças em vários sistemas, concluiu que as mesmas sedividem em três grupos: ambientais, técnicas e organizacionais. Mudanças de ambiente correspondema influências externas na organização, nomeadamente, legislação do governo e dependências de agên-cias externas (ex. fornecedores). Mudanças organizacionais referem-se às influências da política, daestratégia, da estrutura organizacional, dos procedimentos/processos, das restrições financeiras, etc. Asmudanças técnicas são causadas pelo desenvolvimento de hardware, software, comunicações e o ambientetécnico no geral.

Estes resultados denotam alguns problemas. Primeiro, nem sempre é possível atribuir uma mudançaapenas a uma categoria específica, e segundo, algumas categorias estão sobrepostas. Contudo, verificou-se que 70% das mudanças que ocorreram, correspondiam a factores organizacionais [19].

O estudo também examinou os componentes do sistema que necessitavam ser alterados para supor-tar as mudanças, nomeadamente:

• Hardware;• Software;• Interface;• Dados;• Processamento dos dados;

10

Os dois últimos componentes foram os mais susceptíveis a sofrerem alterações. Assim sendo, devemter uma atenção especial, de modo a tornar o SI flexível.

A etapa de Análise de Flexibilidade deve ser adicionada como etapa no processo de desenvolvimentode SI, antes da etapa do desenho dos sistemas. Nesta etapa, devem ser examinadas todas as possíveismudanças em termos da organização, negócio e ambiente que podem acontecer no sistema, em curto,médio e longo tempo. Esta tarefa devia ser realizada por uma equipa especialista, que devia incluirmembros da gestão estratégica, funcional e de negócio. Quando os potenciais cenários de mudanças sãoidentificados, o impacto ou efeito que eles podem ter no sistema deve ser avaliado. Com base nisto, épossível calcular a probabilidade da ocorrência de cada cenário [10].

2.3 Métricas

De acordo com [7], a medição é o processo pelo qual números ou símbolos são atribuídos a entidadesdo mundo real, de forma a caracterizar os seus atributos através de regras claramente definidas. Assim,a medição requer entidades (objectos alvo de interesse), atributos (características das entidades), regrase escalas para atribuir valores aos atributos.

Uma métrica corresponde a uma interpretação quantitativa da realidade, tendo por base medidasobserváveis da arquitectura [7].

Segundo [7, 20, 21] as métricas, genericamente, podem ser classificadas (quanto à forma de obtenção)em:

• Métricas directas, em que as actividades de medição envolvem directamente um atributo arqui-tectural - e.g. número de linhas de código (no caso das Arquitecturas de Software;

• Métricas Indirectas, definidas como combinações de outras medidas - e.g.: densidade de defeitosde um módulo = Nº de defeitos / dimensão do módulo, assim como a qualidade (relaciona-se com a quantidade de defeitos/bugs no software), funcionalidade, eficiência, complexidade emanutenção do software;

• Medições preditivas, definidas à custa de modelos matemáticos que, em conjunto com procedi-mentos de previsão, permitem estimar qualidades desconhecidas da arquitectura - ex. previsão doesforço para desenvolver software a partir da medida da sua funcionalidade (Pontos por Função).

De seguida, são abordadas métricas de avaliação de software. Algumas serão utilizadas na fase devalidação da solução proposta, para medir a facilidade de manutenção do software, de forma a avaliar autilidade da teoria de SN.

2.3.1 Métricas de Software

A aplicação de métricas de software permite analisar a qualidade e produtividade tanto do processo(desenvolvimento e manutenção), como do produto final. A partir destas, é possível a realização deuma actividade fundamental, do processo de gestão de projectos, que é o planeamento. O planeamentotorna possível identificar a quantidade de esforço, o custo e as actividades que serão necessárias para odesenvolvimento e manutenção de projectos [20].

Nos últimos anos, ao nível da engenharia de software, têm vindo a ser definidas várias métricas. Emseguida apresentam-se algumas das métricas directas de software mais referenciadas na literatura.

11

2.3.1.1 Métricas directas

De forma a medir a funcionalidade do software, Albrecht e Gaffney [22] introduziram a métrica Pon-tos por Função (PF). Os PF são computados considerando as entradas/saídas e os dados internamentemanipulados. O valor resultante da métrica PF é obtido aplicando um factor de correlação que temem consideração catorze características do sistema (performance, recuperação de dados, etc.). Os PFsão normalmente usados para medir várias características de qualidade, incluindo dimensão, produ-tividade, complexidade e funcionalidade [7].

O número de linhas de código é uma das métricas mais antigas e usadas para medir a dimensão[20]. Embora esta métrica possa parecer simples, existe discordância sobre o que constitui uma linhade código. Para a maioria dos investigadores, a medida de linhas de código não deveria contar linhasde comentário e linhas em branco, uma vez que estas servem para a documentação do programa enão afecta a sua funcionalidade. Um outro problema é que este sistema de medida está fortementeassociado à linguagem de programação utilizada, dificultando a comparação com outros projectos quenão utilizem a mesma linguagem. Este tipo de medida é mais utilizado para a obtenção de informaçõesreferentes ao projecto, do que para estimativas.

McCabe propôs a métrica de complexidade ciclomática, tendo em consideração que, quanto maior onúmero de caminhos do sistema, mais complexo é o seu fluxo de controlo [23]. Esta métrica contabilizao número de caminhos possíveis a partir do ponto de início até ao ponto de saída do sistema, cujas suascombinações lineares indicam todos os caminhos possíveis do programa.

Existem ainda outras métricas directas como o custo do desenvolvimento e manutenção do software,a quantidade de tempo (horas/minutos) que o programador demora para concluir uma determinadafuncionalidade ou tarefa (esforço) e o total de erros registados durante um determinado período detempo [20, 21].

Com o aparecimento dos paradigmas OO, novos conceitos e abstrações surgiram como classes, méto-dos, herança, polimorfismo, entre outros que não eram medidos pelas métricas existentes. Deste modosurgiram novas métricas, tais como:

• Contagem do número total de métodos por classe [24];• Contagem do número total de classes do sistema [24];• Métodos por classe ponderados. Este método mede a complexidade de uma classe individual.

Soma cada método da classe considerando a sua complexidade [7];• Profundidade da árvore de herança de uma classe é definida como a profundidade máxima de

cada classe, a partir da classe raiz até às classes terminais [7];• Acoplamento entre objectos corresponde ao número de classes, não herdadas, com que uma dada

classe se relaciona [24]. Esta métrica é prejudicial ao desenho modular e impede a reutilização.

2.4 Sumário

Este capítulo contextualizou o problema da inflexibilidade dos SI actuais, que dificulta a resposta rápidada empresa tanto à mudança como ao aumento da complexidade dos seus SI. De seguida, abordaram-sealgumas métricas directas de avaliação de software.

12

3Teoria dos Sistemas

Normalizados”As an evolving program is continually changed,

its complexity, reflecting deteriorating structure, increasesunless work is done to maintain or reduce it.”

- Manny Lehman

De modo a cumprir com o objectivo deste trabalho de Mestrado, pretende-se aprofundar os conheci-mentos sobre a teoria de SN e aplicá-los num caso de estudo, de modo a avaliar o potencial da mesmana concepção de SI evolutivos.

Inicialmente, neste capítulo, são enumerados os vários conceitos inerentes à teoria, de seguida é de-scrito o modo de mapear processos de negócio e por fim, são apresentadas as vantagens e desvantagensda teoria de SN.

3.1 Aplicação da Teoria no Desenvolvimento de Sistemas de Informação

A teoria de SN engloba algumas características para o desenho, desenvolvimento e manutenção de SI, eo sistema deve [25, 26, 15, 27]:

• Estar organizado em função de cinco Elementos de alto nível: Dados, Acções, Workflow, Conectorese Triggers (tabela 3.2);

• Suportar quatro teoremas: Separação de preocupações, Transparência da versão de dados, Transparên-cia da versão de acções e Separação de estados (tabela 3.1);

• Basear-se no conceito da modularidade, para facilitar a ocultação da informação e permitir a sep-aração de preocupações do sistema.

Estas características têm como função principal permitir que um SI possa suportar um conjunto demudanças antecipadas (definição 20 da tabela 3.2).

13

ObjectivoSeparação de preocupações1 Teorema 1: Uma entidade de acção apenas

pode conter uma simples tarefa em SN.Transparência da versão de dados2 Teorema 2: Entidades de dados que são re-

cebidas por input ou produzidas por outputpor entidades de acção, têm de apresentartransparência de versões em SN.

Transparência da versão de acções3 Teorema 3: Entidades de acção que são invo-cadas por outras entidades de acção, têm deapresentar transparência de versões em SN.

Separação de estados4 Teorema 4: A chamada, a uma entidade deacção feita por outra entidade de acção emSN, necessita que o estado seja guardado.

Tabela 3.1: Teoremas da teoria de SN (retirados de [25])

Parnas, Clements e Weiss em 1972 publicaram um artigo [28] acerca da modularidade em engenhariade software. Tendo em conta que a capacidade de mudança é considerada importante para um bomdesenho, Parnas sugere a ocultação de informação: "Detalhes do sistema que são susceptíveis a mudar devemser os segredos de módulos separados; as únicas assunções que devem aparecer na interface entre módulos sãoaquelas que são consideradas como pouco prováveis a mudarem. Cada estrutura de dados é usada em um únicomódulo; esta pode ser directamente acedida por um ou mais programas dentro desse módulo mas não por programasfora dele. Qualquer outro programa que requeira informação armazenada nas estruturas de um módulo tem de aobter invocando programas pertencentes a esse módulo.".

Esta característica requer que o programador estime a probabilidade de mudanças que possam ocor-rer no futuro e derive a estrutura modular do sistema de acordo com elas - mudanças antecipadas5;sugerindo também, o uso da abstração [9] e do encapsulamento, por forma a lidar com a mudança nosmódulos.

O conceito de encapsulamento está intimamente ligado com o conceito de abstração. A disponibiliza-ção, para o exterior, das operações essenciais de uma entidade, é considerada de abstração, sendo que,os detalhes dessas operações são encapsulados, visíveis apenas à própria entidade.

Este encapsulamento deve ser aplicado aos vários Elementos (tabela 3.2), nomeadamente [25]:

• Encapsulamento de Dados– Métodos Get/Set para manter transparência da versão dados;– Tarefas de Suporte devem ser implementadas ao nível da entidade de Dados e não ao nível

da versão da entidade de Dados;• Encapsulamento de Acções

– Um Elemento de Acção tem apenas uma Tarefa Funcional;– Argumentos e parâmetros devem ser Elementos de Dados encapsulados;– Workflows têm de estar separados dos Elementos de Acção;– Encapsulamento de Tarefas: Um Elemento de Acção pode ter várias versões (polimorfismo),

mas isso não pode afectar outras acções que chamem este Elemento de Acção;

1Este teorema expressa a necessidade de separação de tarefas para separar preocupações.2Este teorema expressa a necessidade de encapsulamento das entidades de dados.3Este teorema expressa a necessidade de encapsulamento das entidades de acção.4Este teorema expressa a necessidade de definir estados de acção, para isolar tarefas atómicas e para obter separação de estados.5Estas mudanças já tinham sido identificadas no capítulo 2.2.2.4.

14

• Encapsulamento do Workflow– Workflow não pode conter Tarefas Funcionais (são consideradas como factores de mudança);

– Cada acção do Workflow tem de ser guardada;

• Encapsulamento do Conector– Sistemas externos podem interagir com Elementos de Dados mas o estado tem de ser guardado;

• Encapsulamento do Trigger– O Elemento Trigger tem de controlar diferentes estados, e verificar se um Elemento de Acção

tem de ser iniciado;

A teoria de SN baseia-se no conceito da modularidade para desenvolver SI [15], pois um móduloagrupa funcionalidades semelhantes e respeita o princípio da caixa negra - uma caixa negra pode servista apenas em termos do seu input e output, sem conhecimento sobre o seu funcionamento interno.Um bom sistema modelar está associado a um fraco acoplamento e forte coesão.

A aplicação destes princípios permite a estabilidade/evolução de um SI, caso contrário faz com quecontenha efeitos combinatórios.

O conceito de estabilidade dos SN refere que a quantidade de impactos causada por uma mudançanão pode estar relacionada com o tamanho do sistema, e deve-se manter constante à medida que osistema cresce.

Mudanças que ocorram devido a uma mudança inicial podem ser denominadas de efeitos combi-natórios, e devem ser eliminadas da estrutura do sistema para obter a estabilidade.

A teoria dos sistemas normalizados não deve ser vista como uma nova metodologia, mas sim comouma técnica, pois apenas descreve em detalhe o alto nível de desenho em que uma arquitectura desoftware deve ser construída. Esta técnica é altamente compatível com outras técnicas e metodologias(nomeadamente metodologias orientadas para o produto, e para os processos) e pretende apenas re-stringir a maneira de desenhar/implementar os sistemas (algumas delas têm muita liberdade de de-senho, o que provoca estruturas com efeitos combinatórios) [29].

3.2 Mapeamento de Processos de Negócio

Os SI, de organizações modernas, estão principalmente focados na automatização de processos de negó-cio. A eficiência destes processos de negócio automatizados tornou-se crucial para o sucesso continuadode qualquer organização.

De seguida, é descrita a forma como cada Elemento da teoria de SN é mapeado [1], por forma asuportar o fluxo de um processo de negócio.

Um fluxo representa um processo de negócio que opera num único Elemento de Dados com ciclo devida. É constituído por múltiplas acções que se executam sobre o Elemento de Dados alvo.

Elementos de Dados: Cada fluxo está associado a um e apenas um único Elemento de Dados. EsteElemento de Dados é o objecto com ciclo de vida do fluxo. Todas as instâncias deste Elemento de Dadospassam por este fluxo e possuem um atributo estado que é actualizado após cada operação do fluxo.Deste modo, o estado da instância está disponível para o mundo exterior - tudo isto realizado com fracoacoplamento entre operações.

Elementos de Acção: Cada operação no fluxo consiste num único Elemento de Acção.

Distinguem-se os seguintes tipos de Elementos de Acção em fluxos de processos de negócio:

15

• Acções Standard: o SI realiza uma acção concreta.• Acções Ponte: o SI cria outro tipo de Elemento de Dados, com ciclo de vida, que irá ser processado

no seu próprio fluxo.• Acções Manuais: um utilizador humano é necessário para realizar a acção, e para definir o estado

do Elemento de Dados, com ciclo de vida, através de uma interface de utilizador.• Acções Externas: outro processo, possivelmente pertencente a outro SI, é que executa a acção, e

que define o estado do Elemento de Dados com ciclo de vida.

Cada Elemento de Acção é constituído por uma única Tarefa Funcional. Tal Tarefa identifica umElemento de Acção específico que opera num único Elemento de Dados, um Elemento de Dados comoparâmetro, um estado inicial ou de Trigger, um estado de sucesso e um estado de falha, o qual permiteque o fluxo ramifique do caminho "normal".

Elementos de Trigger: Um Elemento Trigger implica a existência de um temporizador. Um Tempo-rizador representa uma restrição de tempo operando num único Elemento de Dados com ciclo de vida.Tal temporizador pode especificar um Elemento de Acção ou Workflow para ser executado caso o tem-porizador expire, e/ou um novo estado que necessite de ser configurado numa instância do Elementode Dados para o qual o temporizador expirou.

Elementos de Workflow: Um Elemento de Workflow é responsável pela execução do fluxo de todasas instâncias de Elementos de Dados com ciclo de vida.

3.3 Vantagens de Sistemas Normalizados

Os SN alcançam uma série de vantagens, nomeadamente [29]:

• A fase de testes e debug encontra-se simplificada. Com um sistema por módulos torna-se mais fácilencontrar um bug - por exemplo, um Elemento de Acção (do elemento Workflow) só tem uma TarefaFuncional, o que implica que o bug seja imediatamente localizado. Em caso de testes, podemosseparar várias equipas de teste, cada uma para o seu módulo em específico;

• Melhorias na performance (os módulos evitam a existência de threads ou recursos de memórialocked, em todo o sistema, por muito tempo);

• Cada mudança (definição 20 da tabela 3.2) pode ser efectuada com um impacto limitado;• Permite o aumento de complexidade, sem comprometer o resto do sistema (sem degradar as es-

truturas existentes);• Algumas implicações em termos de gestão de projecto:

– Permite estimar, eficazmente, o tempo e orçamento requeridos para tarefas de manutençãoe implementação - o esforço de construir um workflow ou uma outra tarefa semelhante vaiser praticamente o mesmo, quanto mais normalizada e estruturada estiver a arquitectura desoftware;

– Diminuição do risco no desenvolvimento da aplicação - não existe um grande esforço deintegração - efeitos combinatórios - os quais estão tipicamente associados a riscos futuros nosistema;

– Reutilização - todos os sistemas são estruturados e modulares e dessa forma é possível areutilização de algumas dessas estruturas noutros projectos;

– Diferentes equipas podem trabalhar em paralelo em diferentes módulos.

16

3.4 Desvantagens de Sistemas Normalizados

Existem, porém, algumas limitações na teoria, especificamente [30]:

• A teoria de SN pretende diminuir o número de efeitos combinatórios, mas eles irão sempre exis-tir. A implementação de uma acção pode invocar uma acção de baixo nível que contenha efeitoscombinatórios;

• O modelo avançado de SI pode não ser o melhor para expressar todos os requisitos imagináveisdo cliente mas, os autores do livro consideram que o modelo avançado de SI serve perfeitamente,dadas as experiências que já efectuaram;

• As mudanças antecipadas propostas apenas consideram a adição e não modificações ou remoções.As modificações podem ser realizadas através de adições e remoções. Quando Elementos de Da-dos e Elementos de Acção não estão em uso, devido a remoções no sistema, são arquivados peloGarbage Collector;

• Na teoria de SN, a gama de mudanças antecipadas possíveis estão limitadas a mudanças em ter-mos dos Elementos de Dados, Acção, Workflow, Conector e Trigger. Se estas mudanças não foremmapeadas de alguma maneira, todas as mudanças possíveis têm de ser endereçadas resultandoem milhares de mudanças possíveis. Deste modo, não será possível melhorar o desenho de umsistema tendo em conta este número de mudanças possíveis.

3.5 Sumário

Neste capítulo são aprofundados os conhecimentos sobre a teoria de SN, com o propósito de aplicá-losno desenvolvimento de um SVE. Primeiro, foram enumerados os vários conceitos inerentes à teoria, deseguida, foi descrito o modo de mapear processos de negócio e por fim, apresentadas as vantagens edesvantagens da teoria de SN.

17

Definição 11: Um Modelo Avançado de um SI, independente de qualquer ambiente tecnológico específico,pode ser representado pelas seguintes primitivas:

• Elementos de Dados• Elementos de Acção• Elementos de Workflow• Elementos Conectores• Elementos de Trigger

Definição 12: Uma Tarefa Funcional é uma tarefa que efectua uma operação funcional específica num SI.Definição 13: Uma Tarefa de Suporte, é uma tarefa genérica que realiza uma preocupação transversal numSI.Definição 14: Um Elemento de Dados representa um conjunto de atributos ou campos de dados, incluindoligações para outros Elementos de Dados, e podem conter Tarefas de Suporte.Definição 15: Um Elemento de Acção representa uma única Tarefa Funcional encapsulada a um dadonível modular e pode conter Tarefas de Suporte. Nota: Um Elemento de Acção necessita de suportar eencapsular múltiplas versões da sua única Tarefa Funcional. Portanto, diz-se que um Elemento de Acçãopode ter múltiplas implementações, cada uma disponibilizando a mesma funcionalidade.Definição 16: Uma implementação de um Elemento de Acção é uma entidade de software que contém umaversão da Tarefa Funcional.Definição 17: Um Elemento de Workflow representa uma sequência de Elementos de Acção, que são chama-dos de forma a manterem um estado.Definição 18: Um Elemento Conector representa uma Tarefa de Input e/ou Output de um SI. Isto incluí o IOhomem-máquina, tal como funcionalidades de interface de utilizador (gráficas), mas também IO máquina-máquina com aplicações externas ou dispositivos.Definição 19: Definição 19 Um Elemento Trigger representa a activação de um Elemento de Acção ouWorkflow numa base periódica, e é portanto baseado no tempo.Definição 20: Para o modelo avançado de SI, define-se o conjunto seguinte de mudanças antecipadas6:

• Um campo de dados adicional;• Um Elemento de Dados adicional;• Um Elemento de Acção adicional, o que pode implicar:

– um Elemento de Acção tendo um Elemento de Dados específico como input, ou produzindo-ocomo output;

• Uma versão adicional da Tarefa Funcional de um Elemento de Acção, ou qualquer uma das Tarefasde Suporte, o que pode implicar:

– o uso de uma tecnologia externa adicional;– o upgrade mandatário da versão;

• Uma Acção adicional num Elemento de Workflow;• Um Elemento de Workflow adicional;• Um Elemento Conector adicional;• Um Elemento de Trigger adicional;

Tabela 3.2: Definições da teoria de SN (retiradas de [26])

18

4Caso de Estudo

”Experiment adds to knowledge, Credulity leads to error.”- Provérbio árabe

Esta investigação é realizada em contexto empresarial, nomeadamente em parceria com a AMA1, queficou encarregue desde 2007, da promoção do desenvolvimento de serviços de VE em Portugal [31].

Contudo, verifica-se uma indecisão quanto à modalidade do SVE a desenvolver - presencial (votonuma urna electrónica) ou não-presencial (ATM (Automatic Teller Machine), Internet, SMS (Short MessageService), telefone). Este facto deve-se, não só a barreiras políticas, mas também a problemas de segurança- confidencialidade, privacidade, não-coercibilidade e autenticação do votante - inerentes a sistemasdeste tipo.

Esta indecisão contribuiu para a aplicação prática da teoria de SN no âmbito do VE, sendo importantedesenvolver um sistema que possa transitar, no futuro, entre diferentes modalidades de voto, com omínimo de alterações na sua estrutura.

Esta secção começa por contextualizar o processo de voto português, antes de abordar o VE, istoporque o processo de voto em papel serve de ponto de partida para qualquer SVE. De seguida, sãoabordadas algumas experiências realizadas em torno deste tema e descritos os processos de voto doBrasil e da Estónia. Por fim, são resumidas as principais características dos sistemas de voto apresenta-dos.

Este caso de estudo é o alicerce essencial para a validação da teoria neste trabalho de investigação.

4.1 Contexto

Nesta secção aborda-se o sistema presencial de voto, em papel, de Portugal. Inicialmente, são descritostodos os processos comuns aos vários tipos de eleições.

O acto de votar possibilita a cada cidadão intervir em variados assuntos governamentais2 que têmgrande impacto na sua vida. Assim sendo, o voto possibilita a eleição de diferentes representantes daNação [32], nomeadamente:

• Presidente da República (representante máximo da Nação);• Legislativas (os representantes na Assembleia da República);• Legislativas Regionais (tanto para o governo regional dos Açores como para o governo regional

da Madeira);

1O endereço url do site da AMA é http://www.ama.pt/2Assuntos esses relacionados com educação, saúde, ambiente, cultura, segurança, entre outros.

19

• Autárquicas (os representantes nos Municípios e nas Freguesias)• Europeias (escolha dos representantes nacionais no Parlamento Europeu)• Referendos nacionais e locais;

O processo de voto engloba quatro fases bem distintas:

1. Recenseamento eleitoral;2. Processo de votação (validação e voto do eleitor);3. Contagem dos votos;4. Divulgação dos votos.

Na figura 4.1 encontram-se os casos de uso correspondentes aos quatro processos de voto.

Figura 4.1: Casos de uso: fases do processo de voto em Portugal

São utilizados também vários actores, figura 4.2, que interagem com o sistema. No sistema eleitoralPortuguês destacam-se seguintes actores:

Figura 4.2: Actores que interagem com o sistema eleitoral português

• Eleitor - todo o cidadão que esteja em condições legais para participar no processo eleitoral;• Membro da mesa de eleição - constituído por cinco eleitores que executam e dirigem as operações

de votação e de apuramento parcial dos votos. A mesa é composta por um presidente, pelo seu

20

suplente, um secretário e dois escrutinadores;

De seguida, encontra-se uma análise mais detalhada das fases de votação e de contagem dos votos,visto que o protótipo a desenvolver vai incidir, principalmente, nessas mesmas fases. As outras fasessão também abordadas, mas numa análise mais abrangente.

4.1.1 Recenseamento Eleitoral

O recenseamento eleitoral é um direito constitucional fundamental que garante a participação políticados cidadãos através da votação em eleições e referendos [33].

O principal objectivo do recenseamento é criar os cadernos eleitorais, com a lista de todos os cidadãosrecenseados, para serem usados durante as eleições ou referendos, com o intuito de identificar e assi-nalar o eleitor que vota.

O novo regime jurídico do recenseamento eleitoral instituiu um conjunto de medidas que pretendemsimplificar todo o processo de recenseamento. Todos os cidadãos com 18 anos, detentores de cartão decidadão e residentes em Portugal, passam a estar automaticamente inscritos no recenseamento eleitoral[34].

4.1.2 Processo de Votação

Os cidadãos elegíveis para votar variam de acordo com as eleições anunciadas anteriormente, mas épossível traçar dois grupos gerais de eleitores: residentes no território nacional e os residentes no es-trangeiro [35].

O processo de votação3 engloba a autenticação do eleitor, a sua inscrição no caderno eleitoral e opreenchimento do boletim de voto [36]. Estes processos estão descritos nos diagramas de actividade4.3 e 4.4.

Voto Nulo

Será considerado voto nulo [36] o boletim de voto:

1. No qual tenha sido assinalado mais do que um quadrado ou quando haja dúvidas sobre qual oquadrado assinalado;

2. No qual tenha sido assinalado o quadrado correspondente a uma lista que tenha desistido daseleições ou não tenha sido admitida;

3. No qual tenha sido feito qualquer corte, desenho, rasura ou quando tenha sido escrita qualquerpalavra;

4. Oriundo do voto antecipado, quando o boletim não chega à mesa de voto nas condições legal-mente previstas.

3É possível ainda votar antecipadamente [36] em Portugal.

21

Figura 4.3: Processo de identificação e inscrição do eleitor antes de votar

Figura 4.4: Processo de voto após identificação e inscrição do eleitor

Voto em Branco

Será considerado voto em branco [36] o boletim de voto que não tenha sido objecto de qualquer tipode marca.

22

4.1.3 Contagem dos Votos

O processo de contagem dos votos começa logo após o fecho das urnas, em cada assembleia de voto,sendo indispensável para obter os resultados finais das eleições [36].

O processo de contagem de votos está descrito no diagrama de actividade 4.5.

4.1.4 Divulgação dos Votos

No final das operações de votação e contagem dos votos, é indispensável que o presidente da mesacomunique com a máxima celeridade, pelos meios localmente determinados, os resultados obtidos narespectiva assembleia/secção de voto.

A celeridade e o rigor desta comunicação permitirá efectuar o escrutínio provisório, organizado peloSTAPE, através do qual o país é informado, no próprio dia da eleição, do evoluir dos resultados eleitorais[36].

4.2 Votação Electrónica

Apesar das experiências de VE, em eleições políticas [37], serem realizadas há mais de 30 anos, e cerca de25 países realizarem esta experimentação, a sua utilização é actualmente muito restrita, sendo que, em2009, somente quatro países - Brasil, Índia, Estónia e Venezuela - é que utilizavam a votação electrónicade modo extensivo a nível nacional e em todos os locais [31, 38].

Destes países, só na Estónia a votação pode ser feita pela internet, no entanto, o máximo de eleitoresa votar pela Internet foi de apenas 9,5% em 2009 [39]. Os outros países exigem a votação em máquinasinstaladas em assembleias de voto, não permitindo o voto em mobilidade.

Os problemas de segurança inerentes a SVE levaram vários países a atrasar, suspender e até mesmoabandonar a introdução desses sistemas [37]. O caso mais elucidativo ocorreu na Holanda onde, depoisde um crescimento progressivo ao longo de mais de 30 anos, um grupo de cidadãos holandeses - We doNot Trust Computers - demonstrou num programa televisivo, em 2006, que era possível, em menos de 5minutos, alterar os resultados das eleições. Face a estes acontecimentos a Holanda, em 2007, encomen-dou um estudo, onde se concluiu que a votação por via electrónica apresentava falhas, no momento,incontornáveis, no plano da segurança dos dados.

4.3 Experiências em Território Nacional

A figura 4.6 mostra, por ordem cronológica, todas as experiências de voto electrónico realizadas emPortugal.

Em território nacional registaram-se quatro experiências de VE entre as eleições autárquicas de 1997e as legislativas de 2005 [37, 38].

A primeira experiência piloto foi realizada nas eleições autárquicas de 1997, para várias assembleiasde voto de uma freguesia de Lisboa, pelo STAPE. O sistema era composto por uma máquina de VE epor uma urna electrónica de controlo.

A máquina de voto, desenvolvida por uma empresa portuguesa, possuía:

• Um ecrã táctil onde aparecia o boletim de voto e onde era exercida a votação;

23

Figura 4.5: Processo de contagem dos votos

24

Figura 4.6: Experiências de voto electrónico em Portugal

• Um leitor de cartões electrónicos - smart card. Este cartão era dado a cada eleitor, vazio de votos,sendo utilizado para o armazenamento pessoal do voto;

• Uma interface de telecomunicações que permanecia desligada durante a votação, servindo paradepois comunicar os resultados ao centro de escrutínio;

O voto, efectuado na máquina de votação, era registado no cartão e guardado na máquina. Deseguida, podia ser colocado numa urna electrónica de controlo, sendo lido, registado na memória damesma e apagado (dando possibilidade de outro votante poder exercer o seu direito de voto). Destaforma, o sistema permitia a utilização de dois processos de contagem da votação independentes, um naprópria máquina de voto e outro numa urna electrónica.

A segunda experiência-piloto de voto electrónico foi também realizada pelo STAPE nas eleiçõesautárquicas de 2001. Nestas eleições, realizaram-se experiências-piloto para as assembleias de voto deuma freguesia do distrito de Lisboa e outra do distrito do Porto.

A máquina de voto foi essencialmente a mesma de 1997, com melhorias que foram entretanto real-izadas. Desta vez o sistema e o software foram disponibilizados para auditorias.

Nas eleições Europeias de 2004, terceira experiência-piloto, foram testadas três tecnologias difer-entes de votação electrónica, em assembleias de voto de 9 freguesias de diferentes concelhos das váriasregiões do continente. As soluções tecnológicas vieram de dois fornecedores multinacionais Indra eUnisys e de um consórcio nacional Multicert/PT Inovação [37].

Estes sistemas consistiam numa máquina de voto com ecrã táctil onde era possível votar, depois deinserido um cartão electrónico fornecido pelo presidente da assembleia de voto, e que era devolvido aeste depois da votação [40].

No sistema da Indra as máquinas de voto eram urnas electrónicas independentes, que contabilizavamvotos. Neste sistema, o smart card não guardava o voto nem podia ser novamente utilizado, registandoapenas que já tinha sido usado para votar. Após o fecho das votações, cada máquina transmitia o totalde votos ao centro de contagem. Este sistema permitia visualizar a impressão em papel do registo dovoto.

As máquinas de voto da Unisys eram semelhantes às máquinas da Indra, com a particularidade deque, após o fecho das votações ocorria uma recolha de votos de cada equipamento de votação paraum sistema central na assembleia, que de seguida transmitia os resultados para o centro de contagem.Neste sistema era utilizado a PEB (Personal Electronic Ballot - chave de votação pessoal), que autorizava avotação do eleitor na máquina, desencadeando a visualização dos ecrãs de votação. No fim da votação

25

cada PEB podia ser usada por outro eleitor, desde que regenerada.

O sistema da Multicert/PT Inovação tinha um caderno eleitoral único e central, pois o objectivo destasmáquinas era permitir, no futuro, a mobilidade do votante. Neste sistema, as máquinas de voto regis-tavam o voto no i-button e não eram urnas electrónicas, sendo a urna electrónica independente e ficandona mesa da assembleia de voto. No final da votação era impresso um talão comprovativo que o eleitorpodia apenas visualizar por breves momentos. O eleitor para concluir o seu processo de votação, tinhade descarregar o seu voto na urna electrónica, através do i-button. De seguida o i-button era imediata-mente regenerado, ficando pronto a ser usado por outro eleitor.

Nas eleições legislativas de 2005, quarta experiência-piloto, foram utilizadas as plataformas de votoanteriores, as quais foram melhoradas em aspectos pontuais, incluindo a utilização de tecnologias desuporte à votação de cidadãos com necessidades especiais. Esta experiência-piloto foi utilizada em as-sembleias de voto de quatro freguesias. Realizou-se, também, uma experiência de votação pela Internet,fornecida pela empresa portuguesa Novabase, para os eleitores recenseados no estrangeiro, dos quaisapenas 3% participaram. O processo consistia:

• Os eleitores recebiam uma carta em casa que incluía um código de acesso (uma chave alfanuméricaaleatória) que servia para identificação na plataforma Web de votação;

• Após introdução do código de utilizador na plataforma Web, o eleitor volta a identificar-se uti-lizando o seu número de eleitor (motivos de segurança);

• O eleitor vota;• O voto é depositado numa base de dados certificada digitalmente;

Apesar destas tentativas o governo português, em 16 de Maio de 2008, decidiu suspender a votaçãoelectrónica [38].

Em relação aos sistemas experimentados em Portugal, André Zúquete e Paulo Ferreira, no relatóriorealizado nas Eleições Autárquicas de 2004, referem que "A mais-valia dos sistemas em consideração, quandocomparada com a solução actual (i.e., tradicional, baseada em papel) é muito reduzida, uma vez que se limita (...)a apresentar uma interface (...) agradável ao votante e (...) a diminuição do tempo de apuramento dos resultados.Nenhum destes aspectos nos parece justificar o investimento, por mais reduzido que seja, nas tecnologias em causa.Com efeito, na nossa opinião, uma solução de cariz informático justifica-se se permitir a mobilidade do votante"[41].

4.4 Casos de Estudo - Sistemas Electrónicos Estrangeiros

Depois da análise do caso português seguem-se outras análises, nomeadamente do Brasil (primeiro paísa efectuar VE presencial) e da Estónia (primeiro país a efectuar votação electrónica não-presencial). Aprimeira solução é baseada em hardware, com máquinas de voto - uma arquitectura DRE - e a outrautiliza um sistema de votação electrónica com recurso à Internet. Estes países utilizam o VE de modoextensivo a nível nacional e em todos os locais, servindo de base para a solução proposta por esta inves-tigação.

4.4.1 Caso do Brasil

Apesar do VE no Brasil ter surgido em 1996, só a partir de 2000 é que passou a ser exclusivamenterealizado nas urnas electrónicas [37]. Em 2010, votaram, electronicamente, mais de 106 milhões debrasileiros sendo utilizadas cerca de 450 mil urnas electrónicas 4.

4Informação consultada no dia 09/11/2010 do url:http://divulgacao.tse.gov.br/.

26

O SVE no Brasil consiste em máquinas de voto DRE que permitem aos eleitores manifestar a suaintenção de voto. Após o final do processo de votação, cada DRE gera os boletins de voto e toda ainformação auxiliar. A máquina é constituída por dois terminais, o terminal do mesário5 onde o eleitoré identificado e autorizado a votar e, em alguns modelos da urna, a sua identidade é verificada porbiometria [42]; e o terminal do eleitor onde é registado o voto.

O processo de votação resume-se nos seguintes passos [43]:

• Antes dos eleitores efectuarem o seu voto, as máquinas de voto são ligadas e é emitido em cadasecção eleitoral um relatório, que contém toda a identificação das suas urnas e comprova que nãoexistem votos registados;

• O eleitor desloca-se a uma mesa da assembleia de voto, munido do seu documento oficial deidentificação;

• O mesário recebe do eleitor o seu documento de identificação. Digita o seu número no terminal eno ecrã aparece o nome do eleitor, se ele pertencer à secção eleitoral e se estiver apto a votar;

• Se for um eleitor válido, o mesário autoriza-o a votar no terminal do eleitor correspondente (situadonuma cabina inviolável);

• O ecrã expõe a lista de candidatos;• O eleitor manifesta a sua intenção de voto. Este processo termina com um sinal sonoro prolongado

que é acompanhado da indicação da palavra FIM no ecrã da máquina;• A máquina electrónica grava a indicação de que o eleitor já votou;• Cada voto é depositado dentro de um cartão de memória contido na máquina de voto (garantindo

o sigilo do voto, pois o voto está assinado digitalmente pela máquina de voto, e cifrado);• Após o encerramento da urna os resultados são tornados públicos;• Os dados contidos nos cartões de memória são gravados numa unidade de armazenamento e

são levados até um ponto de transmissão, normalmente um cartório eleitoral, que transmite asinformações para o TRE (Tribunal Regional Eleitoral);

• É da responsabilidade do TRE conferir as assinaturas digitais, decifrar a mensagem cifrada e to-talizar os votos. Se a assinatura digital for válida, está garantido que aquele voto foi realizadonuma máquina electrónica específica de uma dada secção de voto; de seguida o voto é decifradosendo realizadas várias verificações de consistência do mesmo;

Do ponto de vista da comodidade e rapidez, este processo é considerado satisfatório. De facto, existempesquisas que provam que os eleitores confiam e estão satisfeitos com o sistema eleitoral brasileiro6.

As pessoas confiam nos resultados especialmente devido a [43]:

• Testes de segurança: em 2009 o TSE (Tribunal Superior Eleitoral) realizou testes públicos de segu-rança com o objectivo de aperfeiçoar o SVE. Nenhum especialista conseguiu violar os sistemas;

• Votação paralela realizada antes das eleições: alguns boletins de voto em papel são preenchidose colocados numa urna lacrada. O conteúdo dos boletins é colocado digitalmente nas urnas elec-trónicas com o objectivo de confrontar os resultados obtidos da urna, com os resultados obtidosna máquina;

O processo electrónico de votação possui vários mecanismos de segurança do voto [44]:

• Assinatura digital: cada voto é assinado digitalmente pela urna electrónica;• Criptografia: são usados algoritmos de chaves assimétricas7 para cifrar os votos (a chave pública

5O mesário é um membro da assembleia de voto.6Informação consultada no dia 27/10/2010 do url:http://www.conjur.com.br/2009-jan-16/pesquisa_revela_73_

entrevistados_confiam_justica_eleitoral.7Método de criptografia que utiliza um par de chaves: uma chave pública e uma chave privada. Quando algo é cifrado com a chave privada,

só consegue ser decifrado com a chave pública, e vice-versa.

27

cifra o voto);• Decriptografia: após o recebimento, o boletim de voto é :

– Validado quanto à compatibilidade da chave pública com a chave privada;

– Decifrado;

– Lido decifrado;

– Armazenado cifrado e decifrado;

• Registo digital do voto: consiste na inserção, de forma aleatória, do voto de cada eleitor, assinadodigitalmente pela urna electrónica, numa tabela com tamanho igual à quantidade de eleitores dasecção eleitoral;

4.4.2 Caso da Estónia

A Estónia começou o seu projecto de voto pela Internet em 2001 e foi posto em prática nas eleiçõeslocais de 2005. Nas eleições locais de 2009 votaram electronicamente apenas 9,5% dos eleitores quandoa disponibilização da votação electrónica já era de 100% [37, 39]. A Estónia tornou-se no primeiro paísa utilizar a votação não-presencial nas eleições.

Para votar pela Internet o votante precisa, para além do ID-card (cartão de identificação da Estónia)com os certificados (autenticação e de assinatura digital) e códigos válidos; um computador com umleitor de smart cards. Esse cartão, para além de possuir informação pessoal do cidadão, tem um certifi-cado de autenticação e outro de assinatura digital, constituindo um meio de autenticação electrónica eum instrumento para assinar documentos electrónicos.

A votação pode ocorrer, tanto pela Internet que é feita 4 a 13 dias antes do dia de votação e os eleitorespodem votar sucessivamente durante esse período, é o chamado voto reversível, contando apenas o úl-timo voto; como no próprio dia da eleição, presencialmente na assembleia de voto e nesse caso, o votopresencial é que será contabilizado.

A figura 4.7 representa o protocolo de voto na Estónia [45] (baseado no método do envelope8).

Figura 4.7: Arquitectura do SVE da Estónia (imagem retirada de [45])

Os vários componentes da figura 4.7 representam [45]:

8Esquema de duplo envelope (interior/exterior): Cada voto cifrado é colocado num envelope (envelope interior) e a assinatura digital(engloba o nome do eleitor e a sua morada) noutro envelope (envelope exterior). Por fim, o envelope interior é colocado dentro do envelopeexterior.

28

• Voter (Aplicação do Votante): corresponde à aplicação que o votante acede no seu PC. Envia o votoencriptado e assinado digitalmente para o Sistema Central, tendo acesso à chave pública;

• Central System (Sistema Central): recebe e processa os votos até a obtenção dos resultados finais;• Key Management (Gestão de Chaves): origina e gere os pares de chaves do sistema, são criadas

duas chaves para efeitos de corrupção - Criptografia assimétrica. A chave pública é integrada naaplicação do votante, enquanto a chave privada é entregue ao VCA (Vote Counting Application -Aplicação de Contagem de Votos);

• Auditing (Auditoria): o sistema de voto origina alguns logs durante diferentes etapas.

De seguida são analisados os componentes da figura 4.7 do Sistema Central [45]:

• Vote Forwarding Server (VFS): autentica o votante, por intermédio do ID-card, apresenta os can-didatos ao votante e recebe o voto encriptado e assinado digitalmente. Este voto é imediatamenteenviado para o VSS e a confirmação de recebimento é enviada para o votante;

• Vote Storage Server (VSS): recebe os votos provenientes de VFS e guarda-os. Antes da contagem dosvotos remove votos duplos, cancela votos por votantes inválidos e recebe/processa cancelamentosde voto. Finalmente, separa o envelope interior do exterior e envia-o para o VCA;

• Vote Counting Application (VCA): componente que recebe os votos encriptados. O VCA usa a chaveprivada do sistema, para obter os resultados da votação, decifrando os votos recebidos.

O processo de votação ocorre da seguinte forma [45]:

• O votante acede à sua aplicação no browser com o ID-card inserido no leitor de cartões, de modo aautenticar-se no sistema. Seguidamente, a aplicação comunica com o VFS;

• O VFS verifica se o eleitor é válido, procurando na lista dos eleitores válidos mas, se o eleitornão for válido, uma mensagem é enviada. De seguida, verifica se o eleitor já votou alguma vez(acedendo ao VSS), e por fim, acede à lista de candidatos e disponibiliza-a ao votante.

• O votante faz a sua escolha e a aplicação do votante pede para este confirmar (a aplicação ar-mazena a lista de candidatos);

• A aplicação cifra o voto com a chave pública e, de seguida, o voto é assinado digitalmente (baseadono método do envelope);

• O voto é enviado para o VFS que verifica se o voto está correcto e se a pessoa que se autenticou nosistema é a mesma que assinou digitalmente o voto;

• O VFS reenvia o voto para o VSS. Este verifica se a assinatura digital está correcta e adquire umcertificado, confirmando a validade da mesma, o qual é adicionado ao voto assinado. No fim, éenviada uma mensagem de confirmação ao VFS em como o voto foi bem recebido;

• O votante pode votar as vezes que pretender. Todos os votos são transmitidos do VFS para o VSS.

Existe um período no qual é possível cancelar o voto feito anteriormente [45]. Este é canceladoquando se efectua:

• Duplos votos: múltiplos votos pela Internet (contando apenas o último voto realizado);• Voto nas assembleias, em papel, depois de se ter votado electronicamente;

Depois de cancelados os votos duplos (automático), a lista de votantes é enviada para as unidadeseleitorais (este passo é fundamental para garantir que uma pessoa não vota duas vezes). Caso umvotante pretenda votar novamente, desta vez presencialmente em papel, dirige-se à assembleia de votopara votar, sendo registado a sua entrada numa lista de cancelamentos de voto. Posteriormente, estalista (que está assinada digitalmente) é enviada para o VSS que executa os cancelamentos.

Quando o período de cancelamento termina, as assinaturas digitais são removidas do voto encrip-tado e colocadas numa lista de votantes (voter list). Os votos cifrados são colocados num dispositivo de

29

armazenamento externo (CD por exemplo) para serem transportados para o VCA, onde os votos sãodecifrados com a chave privada, e posteriormente contabilizados.

Este processo electrónico de votação possui, à semelhança com o sistema do Brasil, vários mecanis-mos de segurança do voto [45]:

• Assinatura digital: cada voto possui a assinatura digital do eleitor;• Criptografia: são usados algoritmos de chaves assimétricas para cifrar os votos (a chave pública

cifra o voto);• Decriptografia: a partir do momento que um voto é cifrado com uma chave pública, apenas pode

ser decifrado com a correspondente chave privada;• Hash criptográfico9 ou message digest: Cada log regista o hash do voto em diferentes etapas.

4.5 Resumo dos Sistemas Analisados

Na tabela 4.1, são apresentadas algumas características dos sistemas de voto das eleições realizadaspelo Brasil, Estónia e Portugal [45, 36, 43].

No caso do Brasil o SVE foi importante, dada a população existente, para reduzir:

• Tempo para apurar resultados;• Fraude fiscal;• Custos associados ao papel, impressão e transporte.

No caso tanto da Estónia como de Portugal, não iria ser proveitoso a aquisição de um sistema deVE que partilhasse os mesmos objectivos que o do Brasil, visto que têm uma população reduzida, oque provoca baixos custos inerentes ao papel e tempos, relativamente rápidos, para apuramento deresultados.

4.6 Sumário

O sistema a implementar consiste num SVE, sendo que este capítulo descreve toda a informação rele-vante para o efeito. Primeiro, relatou-se o processo de voto português, antes de abordar o VE. Após essaacção, foram abordadas algumas experiências realizadas em torno deste tema e descritos os sistemas devoto do Brasil e da Estónia. Por fim, foram resumidas as principais características dos sistemas de votoapresentados.

9Um hash é uma sequência de bits geradas por um algoritmo de dispersão.

30

País

esB

rasi

lE

stón

iaPo

rtug

al

Car

acte

ríst

icas

Sist

emas

Con

fiabi

lidad

e(d

aspe

ssoa

s)M

uita

Pouc

aM

uita

Mob

ilida

dePr

esen

cial

Não

Pres

enci

ale

Pres

enci

alPr

esen

cial

Aut

entic

ação

Doc

umen

tode

iden

tifica

ção

Ass

inat

uras

digi

tais

B.I.+

Nºe

leito

rU

sabi

lidad

eSi

mpl

esTe

cnol

ogic

amen

teco

mpl

exoa

Sim

ples

Segu

ranç

a

Dem

ocra

cia

Gar

ante

Gar

ante

Gar

ante

Cor

recç

ãoG

aran

teb

Gar

ante

cG

aran

tePr

ivac

idad

eG

aran

ted

Não

Gar

ante

eG

aran

tef

Con

fiden

cial

idad

eG

aran

teg

Gar

ante+/-

hG

aran

tei

Não

-Coe

rcib

ilida

deG

aran

tej

Não

Gar

ante

kG

aran

tel

Ver

ifica

bilid

ade

Não

Gar

ante

Não

Gar

ante

Gar

ante

m

Tabe

la4.

1:C

arac

terí

stic

asdo

ssi

stem

asde

voto

emca

dapa

ís

a OSi

stem

ada

Est

ónia

éte

cnol

ogic

amen

teco

mpl

exo

pois

nece

ssita

deum

leito

rde

cart

ões,

dein

stal

ação

dedr

iver

s,et

c..

bD

evid

oà

crip

togr

afia

assi

mét

rica

eàs

valid

açõe

sda

assi

natu

radi

gita

l,da

urna

,no

voto

.c D

evid

oà

crip

togr

afia

assi

mét

rica

.d É

asse

gura

dapo

rgab

inet

esde

voto

sis

olad

ose Si

stem

are

aliz

ado

pela

Inte

rnet

.f A

priv

acid

ade

éas

segu

rada

porg

abin

etes

devo

tois

olad

ose

poru

rnas

fech

adas

.g A

confi

denc

ialid

ade

éas

segu

rada

porg

abin

etes

devo

tos

isol

ados

eo

voto

elec

trón

ico

não

tem

aid

entifi

caçã

odo

vota

nte.

h Éap

licad

aa

assi

natu

radi

gita

ldo

vota

nte

novo

toci

frad

oi O

voto

éan

ónim

o.j É

asse

gura

dapo

rgab

inet

esde

voto

isol

ados

.k Si

stem

are

aliz

ado

pela

Inte

rnet

.l É

asse

gura

dapo

rgab

inet

esde

voto

isol

ados

epo

rurn

asfe

chad

as.

mO

vota

nte

vêo

pres

iden

teda

mes

aco

loca

rose

uvo

tona

urna

.

31

IIResposta aoProblema

5Solução Proposta

”Any sufficiently advanced technology is indistinguishable from magic.”- Arthur C. Clarke

Neste capítulo é proposto um modelo que possuí algumas características definidas pela teoria de SN( 3.1) e cuja finalidade é permitir a implementação de SI evolutivos. De seguida, é realizado o mapea-mento dos processos de negócio associados ao VE, nos elementos representados no modelo proposto.O objectivo é que este mapeamento possa de seguida, ser implementado para ser possível avaliar se ateoria de SN garante SI ágeis, ou seja, susceptíveis a mudanças e ao aumento da complexidade de formaeficaz e rápida, sem degradar a estrutura existente.

5.1 Modelo da Teoria de Sistemas Normalizados

Antes de se realizar o mapeamento dos processos de negócio correspondentes ao processo de voto tradi-cional, foi necessário desenvolver um modelo, no qual assenta o Modelo Avançado de um SI, definidopela teoria de SN - definição 11 da tabela 3.2.

Como é visível na figura 5.1, estão representados os cinco elementos propostos mais três tipos detarefas, sendo que a representação destes elementos, nesta solução, tem por base a definição propostapela teoria de SN (tabela 3.2):

• Workflow Element: representa uma sequência de Elementos de Acção, Conectores e Triggers1, quesão chamados de forma a manterem um estado no Data Element sobre o qual operam - para garantira Separação de estados, teorema da tabela 3.1;

• Data Element: representa um conjunto de atributos ou campos de dados, incluindo ligações paraoutros Elementos de Dados, e podem conter tarefas de suporte. Este Elemento tem de estar en-capsulado (capítulo 3.1) para garantir a Transparência da versão de dados - teorema da tabela3.1;

• Action Element: representa uma única Tarefa Funcional, de modo a garantir o teorema da Separaçãode Preocupações (tabela 3.1), podendo conter várias Tarefas de Suporte. Este Elemento tem deestar encapsulado (capítulo 3.1) para garantir a Transparência da versão de acções - teorema databela 3.1;

• Trigger Element: representa a activação de um Elemento de Acção ou Workflow numa base per-iódica, e é portanto baseado no tempo;

• Connector Element: é constituído por uma Tarefa de IO;• IO Task: responsável pelo:

– IO homem-máquina, tal como funcionalidades de interface de utilizador (gráficas);

1O Elemento de Workflow não necessita de conter, obrigatoriamente, os três elementos especificados.

35

– IO máquina-máquina com aplicações externas ou dispositivos;• Support Task: realiza uma preocupação transversal no SI;• Functional Task: é responsável por garantir a funcionalidade de um SI.

Figura 5.1: Modelo da arquitectura de SN - todos os elementos correspondem a classes abstractas.

O objectivo deste modelo proposto é permitir a implementação de SI evolutivos, sendo que tentacumprir duas das três características que compõem a teoria de SN ( 3.1), pois encontra-se organizadode acordo com os cinco elementos de alto nível especificados - tabela 3.2 - e suporta os quatro teoremasda tabela 3.1. No entanto, este modelo não consegue representar a última característica da teoria -modularidade - sendo que a mesma será cumprida nas próximas secções.

5.2 Mapeamento dos Processos de Negócio em Fluxos de Negócio

Depois de explicado o modelo proposto, e antes de passarmos para pormenores de implementação,está na altura de descobrir um dos pontos fulcrais da teoria, que é a descoberta dos fluxos de negócio -correspondem aos Elementos de Workflow da figura 5.1 - que farão parte do sistema. Esta fase é muitoimportante, para se conseguir atingir a última característica que compõe a teoria de SN - Modularidadepara a ocultação da informação e separação de preocupações.

Para descobrirmos quais os fluxos necessários temos de nos restringir a um domínio de estudo. Nestadissertação, será realizado o mapeamento dos processos de negócio relativos ao processo de VE, demodo a desenvolver um SVE Normalizado. Como referido no capítulo 4, o processo de voto tradicional(em papel) está na origem de qualquer SVE, desse modo foi então realizado o mapeamento, explicadona secção 3.2, de dois dos quatro processos de negócio do voto tradicional, nomeadamente, a votação,que engloba três subprocessos, identificação do eleitor, a inscrição no caderno eleitoral do eleitor e opreenchimento do voto; e a contagem dos votos, nos elementos do modelo proposto - figura 5.1.

Cada um dos processos tradicionais descritos deram origem a novos processos de negócio, cadaum com o seu fluxo específico e referente a um único Elemento de Dados com ciclo de vida. Este

36

mapeamento está descrito na tabela 5.1.

Processo de Negócio Processo de Negócio do Fluxo de Negócio Elemento detradicional Sistema a Desenvolver Dados

Identificação do eleitorInscrição do utilizador no sistema ClientFlow - figura 5.4 ClientElement

Autenticação do utilizador no sistema AuthenticationFlow - figura 5.5 LoginElement

Validação do eleitorInscrição do eleitor no caderno eleitoral ElectorFlow - figura 5.6 ElectorElementValidação do eleitor no caderno eleitoral ValidationFlow - figura 5.7 ValidationElement

Preenchimento do votoCriação de um boletim de voto BallotFlow - figura 5.8 BallotElementRealização do voto pelo eleitor VoteFlow - figura 5.9 VoteElement

Contagem dos votosProcessar cada voto recebido ProcessVoteFlow - figura 5.10 VoteElement

Calcular os resultados da eleição ResultFlow - figura 5.11 ResultElementIniciar/encerrar a urna BallotBoxFlow - figura 5.12 BallotBoxElement

Tabela 5.1: Mapeamento dos processos de negócio, relativos ao voto, em fluxos de negócio.

É importante referir que a entidade VoteElement do fluxo ProcessVoteFlow não é a mesma do fluxoVoteFlow, sendo entidades independentes. Mais adiante, figura 5.10, iremos explicar o porquê destasituação.

5.3 Desenho do Sistema

Com base no mapeamento identificado, tabela 5.1, e antes de explicarmos em detalhe cada fluxo obtido,é importante identificar os SI (módulos) resultantes, pois, como já foi referido, um dos conceitos-chaveda teoria é a modularidade, referida no capítulo 3.1, que facilita a ocultação da informação e pretendeseparar as diferentes preocupações do sistema.

• Módulo de Autenticação - Authentication Server: engloba os processos de inscrição do utilizador nosistema e autenticação do utilizador no sistema, ClientFlow (figura 5.4) e AuthenticationFlow (figura5.5), respectivamente;

• Módulo do Caderno Eleitoral - Electoral Notebook Server: inclui a inscrição e validação do eleitor nocaderno eleitoral, ElectorFlow (figura 5.6) e ValidationFlow (figura 5.7), respectivamente;

• Módulo do Voto - Vote Server: possibilita a criação de um boletim de voto e o acto de votar, Ballot-Flow (figura 5.8) e VoteFlow (figura 5.9), respectivamente;

• Módulo da Urna - Ballot Box Server: tem a missão de processar cada voto recebido, do Módulodo Voto, de calcular os resultados da eleição e de iniciar/encerrar a urna de voto, ProcessVoteFlow(figura 5.10), ResultFlow (figura 5.11) e BallotBoxFlow (figura 5.12), respectivamente.

São expectáveis quatro actores na interacção com o sistema, respectivamente:

• Utilizador (User): qualquer pessoa que tente autenticar-se no sistema desenvolvido;• Administrador (Admin): tem permissões para iniciar/encerrar a contagem dos votos e para obser-

var os resultados da votação;• Cliente (Client): qualquer pessoa que se tente validar no caderno eleitoral, após estar autenticada

no sistema;• Eleitor (Elector): tem permissões para votar numa eleição específica, se estiver validado no caderno

eleitoral.

Na figura 5.2, apresentam-se os casos de uso divididos por cada módulo:

37

Figura 5.2: Casos de uso referentes a cada módulo do sistema.

38

Importa referir que os quatro módulos são independentes, e o único que executa fluxos de negóciofora do seu SI é o Vote Server, como especificado no diagrama de componentes da figura 5.3.

Figura 5.3: Diagrama de componentes do SVE.

Resta referir que o componente Vote Server apenas utiliza as realizações Validation, Authentication eProcessVote, disponibilizadas por ElectoralNotebook Server, Authentication Server e BallotBox Server, respec-tivamente.

5.4 Fluxos de Negócio

Nesta secção, vamos apresentar a descrição dos fluxos de processos de negócio encontrados no mapea-mento atrás descrito - tabela 5.1, e mapeá-los nos elementos de alto nível especificados pela teoria deSN.

Cada fluxo de negócio opera sobre uma única instância de dados com ciclo de vida e equivale a umElemento Workflow. Além disso, pode conter três entidades independentes, nomeadamente Elementosde Acção, Triggers ou Conectores; e o estado resultante da execução desses Elementos.

5.4.1 Inscrição do Utilizador no Sistema

Descrição

Este fluxo permite a inscrição de um User, de modo a que este possa autenticar-se no sistema. Paraefectuar a inscrição é necessário fornecer ao sistema um username e uma password.

Quem realiza o processo é um Admin e é necessário que o username inserido não exista à partida,caso contrário não é possível inscrever o User. Se o username escolhido puder ser usado, então um novoClient é guardado.

Elementos de Dados

São precisos dois Elementos de Dados, o ClientElement e ManagerElement para satisfazer este fluxode negócio, que opera no elemento com ciclo de vida - ClientElement. Uma instância de ClientElement é

39

criada por um Admin e atravessa vários Elementos de Acção descritos na figura 5.4, até o fluxo estarconcluído. Todas as instâncias de ClientElement atravessam este fluxo.

Fluxos

O diagrama de estados que retrata o fluxo ClientFlow, está representado na figura 5.4. Após a criaçãoda instância, com ciclo de vida, de ClientElement, o Admin preenche os campos de criação do registoapós ter-lhe sido apresentado a interface correspondente. Seguidamente, os campos preenchidos sãoassociados à instância criada, sendo validada essa mesma instância. Esta validação consiste em verificarse já existe algum Client no sistema com o mesmo username. Caso não exista, a instância ClientElementpode, finalmente, ser armazenada no ManagerElement.

A acção Show Register Interface to Client invoca um Elemento Conector, visto que é a responsávelpor apresentar uma interface ao utilizador, enquanto que a acção Fill Fields corresponde a uma acçãomanual, pois é o Admin que define o estado da instância com ciclo de vida. As restantes acções sãoStandard.

Figura 5.4: Fluxo de negócio: inscrição do utilizador no sistema - ClientFlow.

5.4.2 Autenticação do Utilizador no Sistema

Descrição

Este fluxo permite a autenticação de um User no sistema. Assume-se que é fornecido, no início, tantoo username como a password do utilizador a autenticar.

De seguida, verifica-se se as credenciais inseridas (username e password), correspondem a algum dosvários Clients existentes, caso contrário, não é possível autenticar o User. Caso as credenciais estejamcorrectas , então uma nova instância de LoginElement é adicionada ao Client.

Elementos de Dados

São precisos três Elementos de Dados, o LoginElement, o ClientElement e ManagerElement para satis-fazer este fluxo de negócio, que opera no elemento com ciclo de vida - LoginElement. Uma instância deLoginElement atravessa vários Elementos de Acção descritos na figura 5.5, até o fluxo estar concluído.Todas as instâncias de LoginElement atravessam este fluxo.

Fluxos

O diagrama de estados que retrata o fluxo AuthenticationFlow, está representado na figura 5.5. Todosos pedidos de autenticação devem ser guardados no sistema. Desse modo, e tal como o fluxo 5.5apresenta, a instância criada, com ciclo de vida, é imediatamente guardada no ManagerElement, podendoser simultaneamente inserida no Client respectivo, caso as credenciais inseridas estejam correctas. Para

40

isso, é preciso tentar obter o Client respectivo com base no username, e caso exista é necessário verificarse a password coincide com a armazenada no sistema.

Todas as acções são Standard.

Figura 5.5: Fluxo de negócio: autenticação do utilizador no sistema - AuthenticationFlow.

5.4.3 Inscrição do Eleitor no Caderno Eleitoral

Descrição

Este fluxo permite a adição de um Client no caderno eleitoral, de modo a permitir o voto. Paraefectuar a inscrição é necessário fornecer ao sistema um username.

Quem realiza o processo é um Admin, e é necessário que o username inserido não exista à partida,caso contrário, não é possível inscrever o Client. Se o username escolhido puder ser usado, então umnovo Elector é guardado.

Elementos de Dados

São precisos dois Elementos de Dados, o ElectorElement e o ManagerElement para satisfazer este fluxode negócio, que opera no elemento com ciclo de vida - ElectorElement. Uma instância de ElectorElementé criada por um Admin e atravessa vários Elementos de Acção descritos na figura 5.6, até o fluxo estarconcluído. Todas as instâncias de ElectorElement atravessam este fluxo.

Fluxos

O diagrama de estados que retrata o fluxo ElectorFlow, está representado na figura 5.6. Após a criaçãoda instância, com ciclo de vida, de ElectorElement, o Admin preenche o campo de criação do registo apóster-lhe sido apresentado a interface correspondente. Posteriormente, o campo preenchido é associado àinstância criada, sendo validada essa mesma instância. Esta validação consiste em verificar se já existealgum Elector no sistema com o mesmo username. Caso não exista, a instância Elector pode, finalmente,ser armazenada no ManagerElement.

Na inscrição do eleitor, no caderno eleitoral, é usada uma acção que invoca um Elemento Conector -Show Register Interface to Elector - e uma acção manual - Fill Fields. As restantes acções são Standard.

41

Figura 5.6: Fluxo de negócio: inscrição do eleitor no caderno eleitoral - ElectorFlow.

5.4.4 Validação do Eleitor no Caderno Eleitoral

Descrição

Este fluxo permite a validação de um Client com base no caderno eleitoral, de modo a verificar se omesmo tem permissões para votar ou não. Assume-se que o username do Client é fornecido no momentoda criação da instância de dados.

Inicialmente, verifica-se se a credencial inserida (username) pelo mesmo, corresponde a algum dosvários Electors existentes, caso contrário, não é possível validar o Client. Se a credencial estiver correcta,verifica-se se o Elector já votou, podendo votar se ainda não o tiver feito.

Elementos de Dados

São precisos três Elementos de dados, o ValidationElement, o ElectorElement e ManagerElement parasatisfazer este fluxo de negócio, que opera no elemento com ciclo de vida - ValidationElement. Umainstância de ValidationElement atravessa vários Elementos de Acção descritos na figura 5.7, até o fluxoestar concluído. Todas as instâncias de ValidationElement atravessam este fluxo.

Fluxos

O diagrama de estados que retrata o fluxo ValidationFlow, está representado na figura 5.7. Todos ospedidos de validação devem ser guardados no sistema. Desse modo, e tal como o fluxo 5.7 apresenta, ainstância, com ciclo de vida, criada é imediatamente guardada no ManagerElement. De seguida, tenta-seobter o Elector com base no username inserido pelo Client. Caso exista, é então verificado se já tinha sidomarcado, e neste caso isso significa que já teve permissões para votar. Caso não tenha sido, será entãomarcado, estando válido para votar.

Todas as acções inerentes a este fluxo são Standard.

Figura 5.7: Fluxo de negócio: validação do eleitor no caderno eleitoral - ValidationFlow.

42

5.4.5 Criação de um Boletim de Voto

Descrição

Este fluxo permite a criação de um Ballot, delimitando todas as opções possíveis de voto do sistema.Quem define essas opções é um Admin.

Elementos de Dados

São precisos dois Elementos de Dados, o BallotElement e ManagerElement para satisfazer este fluxode negócio, que opera no elemento com ciclo de vida - BallotElement. Uma instância de BallotElement écriada por um Admin e atravessa vários Elementos de Acção descritos na figura 5.8, até o fluxo estarconcluído. Todas as instâncias de BallotElement atravessam este fluxo.

Fluxos

O diagrama de estados que retrata o fluxo BallotFlow, está representado na figura 5.8. Após a criaçãoda instância, com ciclo de vida, de BallotElement, o Admin adiciona várias opções de voto após ter-lhesido apresentado a interface correspondente. Depois desta acção, as opções são associadas à instânciacriada, podendo esta, finalmente, ser armazenada no ManagerElement.

Neste fluxo é usada uma acção que invoca um Elemento Conector, - Show Ballot Interface to Client - euma acção manual - Select Options to Ballot, efectuada por um Admin. As restantes acções são Standard.

Figura 5.8: Fluxo de negócio: criação de um boletim de voto - BallotFlow.

5.4.6 Realização do Voto pelo Eleitor

Descrição

Este fluxo permite efectuar o voto de um Elector no sistema. Este processo é efectuado por umpossível Elector, que inicialmente tem de inserir as suas credenciais de acesso ao sistema, assim comoas credenciais que o identificam no caderno eleitoral. Caso estejam as duas certas, pode escolher a suaopção de voto, dentro das possíveis. Finalmente, o voto pode ser, efectivamente, guardado no sistema,sendo que é necessário criar uma cópia do mesmo antes de ser enviado para a urna.

Elementos de Dados

São precisos três Elementos de Dados, o VoteElement, o BallotElement e ManagerElement para satis-

43

fazer este fluxo de negócio, que opera no elemento com ciclo de vida - VoteElement. Uma instância deVoteElement é criada por um User e atravessa vários Elementos de Acção descritos na figura 5.9, até ofluxo estar concluído. Todas as instâncias de VoteElement atravessam este fluxo.

Fluxos

O diagrama de estados que retrata o fluxo VoteFlow, está representado na figura 5.9. Inicialmente,é pedido ao User para inserir tanto o seu username, como a sua password. Após essa inserção, é invo-cada uma acção LoginFlow que faz executar o fluxo AuthenticationFlow - figura 5.5. Se o User tiver ascredenciais correctas é lhe dada permissão para entrar no sistema, sendo que será pedido ao mesmo,que forneça agora o seu username, para verificar se de facto, já foi marcado no caderno eleitoral ou não.Depois é, novamente, invocada uma acção (ValidationFlow) que fará com que se execute um novo fluxo(ValidationFlow - figura 5.7). Caso o Client não tenha sido marcado, tem permissões para votar, contudo,antes de o fazer, o boletim de voto e as suas opções têm de lhe ser apresentado. Após a escolha daopção pretendida, a mesma é adicionada à instância de VoteElement, inicialmente criada, sendo inseridano ManagerElement logo de seguida. Por fim, o voto é copiado, para uma estrutura auxiliar, que seráenviada posteriormente, sendo reconhecida pelo fluxo ProcessVoteFlow - figura 5.10.

O fluxo da realização do voto pelo eleitor, figura 5.9, é o maior e mais complexo fluxo do sistema,que através das acções LoginFlow, ValidationFlow e VoteFlow, são invocados os fluxos AuthenticationFlow(figura 5.5), ValidationFlow (figura 5.7) e ProcessVoteFlow (figura 5.10), respectivamente. Estas acçõesdenominam-se como externas, visto que o estado do Elemento de Dados com ciclo de vida (VoteElement)é definido por um fluxo pertencente a outro SI. Para além deste tipo de acção, estão evidentes no fluxo,acções que invocam Elementos Conectores, tais como Show Login Interface to Client, Show Elector Interfaceto Client e Show Options to User; e acções manuais, nomeadamente, Fill Login Credentials, Fill ElectorCredentials e Choice Option. As acções restantes são Standard.

Figura 5.9: Fluxo de negócio: realização do voto pelo eleitor - VoteFlow.

44

5.4.7 Processar cada Voto recebido

Descrição

Este fluxo permite o processamento de cada estrutura auxiliar, recebida do fluxo VoteFlow, tendo afinalidade de a converter num VoteElement, para este ser manipulado no módulo da urna.

Elementos de Dados

São precisos dois Elementos de Dados, o VoteElement e BallotBoxElement para satisfazer este fluxo denegócio, que opera no elemento com ciclo de vida - VoteElement. Cada instância de VoteElement atravessaos vários Elementos de Acção descritos na figura 5.10, até o fluxo estar concluído.

Fluxos

O diagrama de estados que retrata o fluxo ProcessVoteFlow, está representado na figura 5.10. Apósa criação da instância, esta converte a estrutura auxiliar recebida, para um VoteElement. De seguida, énecessário verificar se a BallotBox ainda está disponível para receber votos. Se estiver, o VoteElement éadicionado ao BallotBoxElement.

As acções inseridas neste fluxo são Standard.

Figura 5.10: Fluxo de negócio: processar cada voto recebido - ProcessVoteFlow.

5.4.8 Calcular os Resultados da Eleição

Descrição

Este fluxo permite obter os resultados da eleição, por cada opção de voto possível.

Elementos de Dados

São precisos três Elementos de Dados, o ResultElement, VoteElement e BallotBoxElement para satisfazereste fluxo de negócio, que opera no elemento com ciclo de vida - ResultElement. Cada instância de Re-sultElement atravessa os vários Elementos de Acção descritos na figura 5.11, até o fluxo estar concluído.

Fluxos

O diagrama de estados que retrata o fluxo ResultFlow, está representado na figura 5.11. Após acriação da instância, esta é inicializada com uma das diferentes opções de voto, pertencentes às es-colhas dos Electors. Posteriormente, são contabilizados todos os votos que contêm essa opção, sendoposteriormente, guardado o resultado na instância ResultElement. Por sua vez, esta é armazenada noBallotBoxElement.

Os resultados da eleição, fluxo 5.11, são realizados única e exclusivamente por acções Standard.

45

Figura 5.11: Fluxo de negócio: calcular os resultados da eleição - ResultFlow.

5.4.9 Iniciar/Encerrar a Urna

Descrição

Este fluxo permite iniciar e encerrar a urna de voto, apresentando os resultados finais da eleição aoAdmin. A urna apenas pode receber votos caso se encontre disponível, caso contrário não são incluídosnovos votos.

Elementos de Dados

São precisos dois Elementos de Dados, o BallotBoxElement e ManagerElement para satisfazer este fluxode negócio, que opera no elemento com ciclo de vida - BallotBoxElement. Cada instância de BallotBoxEle-ment atravessa os vários Elementos de Acção descritos na figura 5.12, até o fluxo estar concluído.

Fluxos

O diagrama de estados que retrata o fluxo BallotBoxFlow, está representado na figura 5.12. Todosos pedidos de abertura de urna devem ser guardados no sistema. Desse modo, e tal como o fluxo 5.12apresenta, a instância, com ciclo de vida, criada é imediatamente guardada no ManagerElement. Deseguida, o Admin tem permissão para iniciar/encerrar a urna, após lhe ser apresentada a interface cor-respondente. Quando esta é encerrada, não pode receber mais votos, sendo realizada uma listagem dasopções de voto seleccionadas. Esta listagem é importante, pois para cada opção de voto irá ser execu-tado o fluxo ResultFlow para contagem dos mesmos. No final do fluxo, os resultados são apresentadosao Admin.

Neste fluxo existe uma acção ponte - Evaluate BallotBox - visto que é criado um outro tipo de Elementode Dados (ResultElement), com ciclo de vida, que é processado no seu próprio fluxo. Existem, de igualforma, Elementos Conectores, tais como Show BallotBox Activate Interface to Admin, Show BallotBox CloseInterface to Admin2 e Show Result Interface to Admin; e acções manuais, Activate BallotBox e Close BallotBox.As restantes acções são consideradas Standard.

2Só a partir daqui a urna pode começar a receber os votos.

46

Figura 5.12: Fluxo de negócio: iniciar/encerrar a urna - BallotBoxFlow.

5.5 Sumário

Este capítulo descreve uma possível solução para o desenvolvimento de um SVE normalizado. Inicial-mente, foi descrito o modelo no qual assentam os elementos definidos pela teoria de SN. Após estadescrição, foi realizado o mapeamento dos processos de negócio, associados ao voto, nos elementosdefinidos no modelo. Pretende-se que este mapeamento seja implementado, no próximo capítulo, porforma a avaliar se a teoria de SN garante SI evolutivos.

47

6Implementação

”The way to get started is to quit talking and begin doing.”- Walt Disney

Este capítulo descreve a implementação do protótipo de um SVE, baseado na solução proposta realizadano capítulo anterior. Funciona como uma prova de conceito, pois é através do mesmo que será possívelavaliar o potencial da teoria de SN.

O sistema proposto pretende ser a base de qualquer SVE, seja presencial ou não, e foi implemen-tado segundo uma abordagem faseada, de modo a permitir tanto desenvolvimento iterativo (iteraçãonas funcionalidades) como incremental (incremento de funcionalidade). A linguagem de programaçãoutilizada foi o C#, que se executa na Microsoft .NET Framework.

No início são abordados alguns aspectos relacionados com a arquitectura de software e de seguidaapresentados alguns fragmentos de código dos elementos mais importantes que constituem a teoria deSN.

6.1 Arquitectura de Software

A Arquitectura de Software não consegue ser descrita numa única vista, isto porque não se consegueendereçar todos os aspectos revelantes, referentes à arquitectura de software, em apenas um diagrama.Assim sendo, a Arquitectura de Software considera várias estruturas para o efeito. Essas estruturas,também conhecidas como estilos arquitecturais, estão agrupados em três principais tipos de vista [46]:

• Módulo: a decomposição em módulos de um sistema enumera as principais unidades de imple-mentação - módulos, bem como as relações entre si:

– Decomposição: útil para mostrar como é que as responsabilidades do sistema são divididaspor módulos, e como é que estes módulos são decompostos em submódulos;

– Utilização: este estilo pode ser usado para restringir a implementação da arquitectura, poisindica aos programadores o que podem e não podem usar durante a implementação de ummódulo;

– Generalização: útil para suportar extensão, evolução, reutilização e desenho OO. Os módulosdeste estilo capturam comportamento comum (módulos pai) e variante (módulos filho);

– Camadas: cada camada, caso forneça um conjunto de serviços coeso (pode ser feito um pro-grama inteiro usando apenas os serviços dessa camada) chama-se uma máquina virtual;

• Componente e Conector (C&C): este tipo de vista define modelos que consistem em elementos quetêm presença em tempo de execução (processos, objectos, clientes, servidores, bases de dados):

– Estilo fluxo de dados (DataStream) - canais e filtros;

49

– Estilo call-return - cliente/servidor;– Estilo call-return - peer-to-peer;– Estilo de dados partilhados - repositório;– Estilo publish-subscribe;– Estilo communicating processes;

• Alocação : este tipo de vista mostra como os elementos de software se relacionam com o seu ambi-ente:

– Estilo instalação;– Estilo implementação;– Estilo atribuição de trabalho;

Apesar destas serem as vistas mais usadas, nem todas são necessárias para representar uma Arqui-tectura de Software, sendo que neste trabalho apenas a vista módulo é usada.

Como já foi visto no capítulo 5.3, existem quatro módulos no sistema - figura 6.1:

Figura 6.1: Vista Módulo: decomposição do SVE.

A figura 6.2 é importante para restringir a implementação da arquitectura, pois o estilo de vistautilização indica o que se pode ou não usar durante a implementação de um módulo.

Figura 6.2: Vista Módulo: utilização dos módulos do SVE.

50

Cada um destes módulos encontra-se dividido em três camadas principais, figura 6.3, que se rela-cionam com o modelo proposto na figura 5.1:

• Core: encontram-se todos os Elementos de Dados, ou seja, as entidades do domínio;• Interface: todas as interfaces apresentadas estão armazenadas nesta camada;• Workflows: esta camada divide-se em mais sete camadas, cada uma com a respectiva função:

– Actions: contém todos os Elementos de Acção que compõem o sistema;– Connectors: armazena todos os Elementos Conectores;– Config: todas as configurações, definições e propriedades do sistema, encontram-se nesta ca-

mada;– Exceptions: inclui as excepções lançadas no protótipo;– Tasks: esta camada divide-se em mais três, nomeadamente:

* FunctionalTasks: são especificadas todas as Tarefas Funcionais inerentes ao sistema;

* IOTasks: engloba as tarefas de Input/Output;

* SupportTasks: agrega as Tarefas de Suporte, ou seja, as transversais ao sistema;

– Views: encontram-se todas as vistas utilizadas no sistema;– Workflows: especificam os fluxos existentes.

Entre camadas de uma aplicação deve haver uma interface bem definida que isole a camada superiordos detalhes de implementação das camadas inferiores. Uma Vista (View) é uma representação dosobjectos de domínio, devolvida pelas tarefas (Tasks) e é utilizada para disponibilizar informação àsoutras camadas.

Figura 6.3: Vista Módulo: decomposição de cada módulo.

De seguida vão ser explicados, genericamente, os elementos (figura 5.1) que existem em cada mó-dulo do SVE desenvolvido e as relações existentes; sendo que o Modelo de Domínio concreto, referentea esses elementos encontra-se em Anexo ( 10.3).

51

6.1.1 Camada: Core

Nesta camada encontram-se todos os Elementos de Dados. Existe sempre um ManagerElement que tema função de armazenar todos os Elementos de Dados com ciclo de vida. Na figura 6.4 está representadaa relação entre vários elementos.

Figura 6.4: Diagrama de classes em UML representando Data Elements.

Os elementos A e B são representativos e não correspondem a nenhuma classe em concreto, ape-nas servem como referência para todos os DataElements existentes. Como é visível na figura 6.4, oselementos A, B e Manager herdam de DataElement.

De notar, que tanto o A Element como o B Element, possuem uma variável de estado, neste caso daclasse String, de modo a ser possível guardar um dado estado, sempre que uma determinada acção éexecutada.

Como uma das características na teoria de SN é o encapsulamento, referido no capítulo 3.1, entãotodos os Elementos de Dados contêm, para além do estado, métodos Get/Set para a manipulação deatributos, de modo a manter a transparência da versão dados, um dos teoremas identificado na tabela3.1.

6.1.2 Camada: Interface

A parte gráfica do sistema está muito simples, sendo utilizadas WindowsForms para o efeito. Cada inter-face herda da classe Form.

Um exemplo de uma interface pode ser visto na figura 6.5.

Figura 6.5: Exemplo de uma das interfaces do SVE: registo de novo User.

As interfaces são responsáveis tanto por mandar executar os fluxos de negócio, anteriormente de-

52

scritos, como por apanhar as excepções lançadas no sistema, de modo a informar o User sobre o desfechoda execução do fluxo.

6.1.3 Camada: Workflows - Actions

Nesta camada encontram-se todos os Elementos de Acção, pertencentes ao módulo correspondente.Como é visível na figura 6.6, cada Elemento de Acção possui:

• Uma View: que tem de ser retornada com o resultado da acção executada;

• Uma Functional Task: é a tarefa que executa um procedimento funcional no sistema. As acções sópodem conter uma tarefa funcional para cumprir com o teorema de Separação de preocupações1,especificado na tabela 3.1;

• (Opcional) Um Conjunto de Support Tasks: tarefas que realizam uma acção transversal ao sistema.

Figura 6.6: Diagrama de classes em UML representando Action Elements.

Os elementos A, B e C são representativos e não correspondem a nenhuma classe em concreto, ape-nas servem como referência para todos os ActionElements existentes. Como é visível na figura 6.6, oselementos A, B e C herdam de ActionElement.

6.1.4 Camada: Workflows - Connectors

Nesta camada encontram-se todos os Elementos Conectores, pertencentes ao módulo correspondente.Como é visível na figura 6.7, cada Elemento Conector possui:

• Uma View: que tem de ser retornada com o resultado da acção executada;

• Uma IO Task: é a tarefa responsável pelo IO do sistema;

Os elementos A e B são representativos e não correspondem a nenhuma classe em concreto, apenasservem como referência para todos os ConnectorElements existentes. Como é visível na figura 6.7, oselementos A, B herdam de ConnectorElement.

1Este teorema possibilita, do mesmo modo, o cumprimento de outro teorema - Transparência da versão de acções.

53

Figura 6.7: Diagrama de classes em UML representando Connector Elements.

6.1.5 Camada: Workflows - Tasks - FunctionalTasks

É nesta camada que se concentra um dos pontos fulcrais de todo o SVE, ou seja, as tarefas funcionais.Estas conferem funcionalidade ao sistema, e são invocadas por Elemento de Acção. A figura 6.8 mostracomo as tarefas funcionais se encontram organizadas. Cada Functional Task está associada a uma vista,que tem de ser criada e retornada com o resultado da acção executada; e a pelo menos um Data Element,sobre o qual opera.

Figura 6.8: Diagrama de classes em UML representando Functional Tasks.

Os elementos A, B e C são representativos e não correspondem a nenhuma classe em concreto, ape-nas servem como referência para todas as FunctionalTasks existentes. Como é visível na figura 6.8, oselementos A, B e C herdam de FunctionalTask.

6.1.6 Camada: Workflows - Tasks - IOTasks

Estas tarefas são responsáveis por apresentar uma interface gráfica ao votante daí, na figura 6.9, estaremassociadas a um Windows Form. Tal como as tarefas funcionais, estas também têm de criar e retornaruma View. Todavia, neste caso não são retornados resultados nenhuns, dentro da View, pois apenas umainterface é apresentada ao User.

Os elementos A e B são representativos e não correspondem a nenhuma classe em concreto, apenas

54

Figura 6.9: Diagrama de classes em UML representando IO Tasks.

servem como referência para todas as IOTasks existentes. Como é visível na figura 6.9, os elementos Ae B herdam de IOTask.

6.1.7 Camada: Workflows - Tasks - SupportTasks

As Tarefas de Suporte estão associadas a acções transversais no sistema, aplicadas em DataElements,sendo que no SVE implementado apenas existem duas, nomeadamente, a SupportTask_Print e a Support-Task_Save, tal como se apresenta na figura 6.10.

Figura 6.10: Diagrama de classes em UML representando Support Tasks.

A Tarefa de Suporte Print existe para questões de debug, no decorrer de um fluxo de negócio - figura6.11, sendo guardado tanto o Elemento de Dados com ciclo de vida, como o seu estado actual. Sendoque a Tarefa Save é usada para garantir a persistência, neste caso para ficheiro, dos objectos com ciclo devida no SI - figura 6.12.

Figura 6.11: Exemplo da execução da Tarefa de Suporte - SupportTask-Print - no AuthenticationServer.

55

Figura 6.12: Exemplo em XML do resultado da execução da Tarefa de Suporte - SupportTask-Save - no AuthenticationServer.

Estes dois exemplos apresentados correspondem a uma inscrição de um utilizador no sistema e umaautenticação, bem sucedida, do mesmo.

6.1.8 Camada: Workflows - Views

As Views têm atributos e métodos Get/Set para a manipulação dos mesmos. Todas as vistas herdam deBaseView - figura 6.13. Tal como já foi referido, esta entidade serve para guardar informação provenienteda execução das tarefas funcionais, com o objectivo de apresentá-la a outras entidades.

Figura 6.13: Diagrama de classes em UML representando Views.

Os elementos A e B são representativos e não correspondem a nenhuma classe em concreto, apenasservem como referência para todas as Views existentes. Como é visível na figura 6.13, os elementos A eB herdam de BaseView.

6.1.9 Camada: Workflows - Workflows

Um fluxo de negócio é representado por uma instância de Workflow. Este opera sobre um DataElement,pode conter ActionElements, ConnectorElements e TriggerElements, e está associado a vistas, com o resul-tado de cada tarefa executada. As relações entre estes elementos e o Workflow estão especificadas nafigura 6.14.

São estas instâncias as responsáveis por garantir o teorema Separação de Estados da tabela 3.1, ondesempre que cada Elemento de Acção/Conector/Trigger é executado, o estado resultante é guardado nainstância de dados com ciclo de vida.

Os elementos A e B são representativos e não correspondem a nenhuma classe em concreto, apenasservem como referência para todos os Workflows existentes. Como é visível na figura 6.14, os elementos

56

Figura 6.14: Diagrama de classes em UML representando Workflows.

A e B herdam de WorkflowElement.

Com as dependências identificadas, é possível obter o estilo vista de utilização de cada componenteespecificado em cada módulo. Esta vista pode ser integrada com o estilo vista por camadas, sendoapresentado na figura 6.15, essa conjugação de vistas.

Figura 6.15: Vista Módulo: utilização/camadas de cada módulo.

6.2 Exemplos de Código

Agora que está explicado o desenho conceptual do SVE, vamos apresentar alguns fragmentos comcódigo para melhor se compreender como é que o mapeamento realizado anteriormente, foi efectiva-mente implementado.

57

Temos no programa 6.1, um exemplo de um Elemento de Dados, contendo apenas atributos e op-eradores de manipulação dos mesmos, tal como é referido na teoria de SN. Este elemento tem ciclo devida e como tal, terá de ter um fluxo associado - ClientFlow, que será executado por um Workflow.

Programa 6.1: ClientElement.cs

1 ...2 [Serializable]

3 public class ClientElement : Metamodel.DataElement

4 {

5 private String username;

6 private String password;

7 private List<LoginElement > logins;

8 private String state;

910 public ClientElement() {

11 this.logins = new List<LoginElement >();

12 }

1314 //Getters and setters

1516 public string Username

17 {

18 get { return username; }

19 set { username = value; }

20 }

2122 public string Password

23 {

24 get { return password; }

25 set { password = value; }

26 }

2728 public List<LoginElement > Logins

29 {

30 get { return logins; }

31 set { logins = value; }

32 }

3334 public void AddLoginList(LoginElement login)

35 {

36 this.logins.Add(login);

37 }

3839 public String State

40 {

41 get { return this.state; }

42 set { state = value; }

43 }

44 }

45 ...

O Elemento de Workflow que opera sobre o Elemento de dados enunciado acima, é o especificado noprograma 6.2. Quando este Workflow é executado, várias acções são executadas, sobre o Elemento deDados - Client, mas vamos ter especial atenção à acção CreateClientAction. Não convém esquecer, quesempre que uma acção é executada, o estado do Elemento de Dados com ciclo de vida é guardado, deacordo com o teorema da Separação de Estados da tabela 3.1, daí a existência da acção SetStateClientAc-tion sempre depois de cada acção realizada.

58

Programa 6.2: FirstClientWorkflow.cs

1 ...

2 public class FirstClientWorkflow : Metamodel.WorkflowElement <Object>

3 {

4 public FirstClientWorkflow()

5 {

6 }

78 public override void execute()

9 {

10 try

11 {

12 //To create a ballot instance

13 GetManagerView gmv = (GetManagerView)new GetManagerAction().execute();

14 ManagerElement me = gmv.ManagerElement;

1516 CreateClientView ccv = (CreateClientView)new CreateClientAction(me).execute

();

17 ClientElement ce = ccv.ClientElement;

1819 //STATE

20 new SetStateClientAction(me, properties.CREATED, ce, properties.

stringClientToLog).execute();

2122 //Show Register Interface to Client

23 new ShowRegisterInterfaceToClientConnector(me, ce).execute();

2425 //STATE

26 new SetStateClientAction(me, properties.REGISTERINTERFACESHOWED , ce,

properties.stringClientToLog).execute();

2728 }

29 catch (IOException ex)

30 {

31 throw new AuthenticationException(properties.IOException + " " + ex.

ToString());

32 }

33 }

34 }

35 ...

Quando a acção CreateClientAction é invocada, o fragmento de código do programa 6.3 é despole-tado. Como é visível este Elemento de Acção não define, directamente, o comportamento da instânciaClient, simplesmente invoca uma Tarefa Funcional e outra de Suporte, para serem executadas posteri-ormente. Esta última tarefa tem a finalidade de guardar a informação no ManagerElement, pois é este oresponsável pelo armazenamento das instâncias de dados com ciclo de vida. No fim irá devolver umaView - CreateClientView, após ter sido executado.

Programa 6.3: CreateClientAction.cs

1 ...

2 public class CreateClientAction : Metamodel.ActionElement <CreateClientView >

3 {

4 private ManagerElement me;

56 public CreateClientAction(ManagerElement me)

7 {

8 this.me = me;

9 this.setFunctionalTask(new FunctionalTask_CreateClient());

59

10 this.addSupportTask(new SupportTask_Save(me));

11 }

12 }

13 ...

Quando a tarefa do programa 6.3 é accionada, esta tem a função de executar um determinado pro-cedimento no SI, cujo resultado é armazenado numa View, aqui criada, para poder ser enviado aosoutros elementos, nomeadamente o de Acção e de Workflow, como se pode observar no programa 6.4.Esta tarefa tem a missão de criar um novo Client.

Programa 6.4: FunctionalTask_CreateClient.cs

1 ...

2 public class FunctionalTask_CreateClient : Metamodel.FunctionalTask <CreateClientView >

3 {

4 public FunctionalTask_CreateClient()

5 {

6 }

78 public override CreateClientView execute()

9 {

10 CreateClientView ccv = new CreateClientView();

11 ccv.ClientElement = new ClientElement();

12 return ccv;

13 }

14 }

15 ...

6.3 Sumário

Neste capítulo, foram apresentados os aspectos principais da implementação da solução proposta. Fun-ciona como uma prova de conceito, pois é através do mesmo que será possível avaliar o potencial dateoria de SN. Primeiro, foram abordados alguns aspectos relacionados com a arquitectura de software.De seguida, foram apresentados alguns fragmentos de código dos elementos mais importantes que con-stituem a teoria de SN.

60

7Validação

”The logic of validation allows us to movebetween the two limits of dogmatism and skepticism.”

- Paul Ricoeur

Agora que já foi explicada toda a solução proposta e correspondente implementação, chegou a alturade avaliar a teoria de SN para saber se, de facto, é a mais indicada para garantir uma eficiente e eficazmanutenção dos SI, de modo a resolver o problema de dissertação.

Inicialmente, e fugindo um pouco do contexto da validação, é apresentado um caso real onde oprotótipo foi utilizado. De seguida, foi necessário possuir um SVE similar ao desenvolvido, para validara teoria de SN. Esta validação consistiu em aplicar seis mudanças (testes), a cada um dos sistemas, demodo a obter conclusões baseadas em algumas métricas de software, que pretendem medir a facilidadede manutenção dos dois sistemas. Por fim, são descritas as principais conclusões obtidas.

7.1 Avaliação do Protótipo

O protótipo experimental foi aplicado, em Maio, nas eleições para a direcção da AEIST, não contandopara os resultados oficiais.

O sistema desenvolvido foi utilizado por 52 pessoas, sendo que todas manifestaram, com agrado, asua experimentação. Quando questionadas sobre quais os principais problemas do sistema, verificaram-se diferentes opiniões - figura 7.1.

Figura 7.1: Gráfico: desvantagens do SVE na opinião dos utilizadores.

61

Cerca de 23% (12 pessoas) dos inquiridos considera que o facto do SVE estar colocado na mesa ondese encontravam as urnas, faz com que não exista privacidade/anonimato do voto. Outros eleitores, 15%(8 pessoas), consideram como principal desvantagem, o sistema não contemplar nenhum mecanismode segurança. Os restantes, 62% (32 pessoas), apontam a interface rudimentar como principal pontonegativo do SVE - figura 7.2.

Figura 7.2: Exemplo de uma das interfaces do SVE: escolha da opção de voto pretendida.

De seguida, foi utilizada a mesma amostra populacional, para identificar as principais vantagens doSVE - figura 7.3.

Figura 7.3: Gráfico: vantagens do SVE na opinião dos utilizadores.

Cerca de metade da amostra, 58% (30 pessoas), considera que um SVE permite uma maior rapidezna obtenção dos resultados, sendo que a restante amostra divide-se tanto na simplicidade que o mesmopode trazer às vidas das pessoas - 29% (15 pessoas) -, como na importância que um sistema destes podeter para diminuir a abstenção - 13% (7 pessoas).

A figura 7.4 representa os resultados desta pequena experiência e, curiosamente, a lista que venceufoi, efectivamente, a A.

62

Figura 7.4: Resultado das eleições para a direcção da AEIST.

7.2 Validação da Teoria de Sistemas Normalizados

Para realizar esta validação foi necessário possuir um protótipo de SVE similar ao desenvolvido, paraobter algumas conclusões sobre a viabilidade e importância do uso da teoria de SN na manutençãode SI. Este protótipo foi desenvolvido por um aluno orientado pelo Professor Carlos Ribeiro - AndréBrioso - no âmbito da sua tese de Mestrado, tendo como único objectivo a garantia da verificabilidadedo voto [47]. Encontra-se em Anexo todas as fases que o protótipo, implementado pelo aluno, tem decontemplar - figura 10.1.

Em ambos os sistemas foram aplicadas algumas métricas directas, na execução de seis casos de teste,para posteriormente ser possível comparar os resultados obtidos. Das métricas identificadas no capítulo2.3.1, foram usadas aquelas que melhor se adequam a três características básicas, que pretendem avaliara facilidade de manutenção do software, respectivamente:

• Tempo para efectuar uma mudança: tempo de análise e tempo de conclusão de uma determinadatarefa;

• Quantidade de código adicionado: número de linhas de código acrescentadas, número de métodoscriados e número de classes criadas;

• Número de dependências verificadas com a mudança: acoplamentos adicionados entre módulos,número de erros cometidos e complexidade ciclomática.

Os testes realizados foram baseados em algumas mudanças antecipadas, definição 20 da tabela 3.2,que podem ocorrer num sistema:

• Adicionar um campo adicional: adição da data de nascimento no cliente que se autentica no sis-tema;

• Adicionar um novo Elemento de Dados: adicionar a entidade Envelope que agrega tanto o votocomo o votante;

• Adicionar um novo Elemento Conector: adição de uma nova interface no sistema, de confirmaçãode voto;

• Adicionar um novo Elemento de Acção: envio da entidade Envelope para a urna;• Mudar uma dada Tarefa Funcional: autenticação no sistema baseada nas credenciais do Google;• Adicionar um novo Elemento de Workflow: construção da entidade Envelope.

De seguida, explicam-se cada um dos testes realizados no SVE desenvolvido, em maior detalhe:

• Adicionar um campo adicional: este teste consistiu em adicionar no Elemento de Dados Client do

63

módulo AuthenticationServer, um campo correspondente à data de nascimento, tal como represen-tado no programa 10.1 dos Anexos;

• Adicionar um novo Elemento de Dados: adicionar a entidade Envelope que agrega tanto o votocomo a indicação do votante, no módulo VoteServer - programa 10.2 dos Anexos;

• Adicionar um novo Elemento Conector: adição de uma nova Interface no sistema, de confirmaçãode voto, no fluxo de VoteFlow do módulo VoteServer. Este teste implica a criação de uma nova Inter-face (figura 10.2), do Elemento Conector (programa 10.3) e da Tarefa de IO subjacente (programa10.4);

• Adicionar um novo Elemento de Acção: envio da entidade Envelope para o módulo BallotBoxServer.Este teste implica:

– A existência de duas acções independentes: criação do Envelope (StartWorkflowEnvelopeAc-tion) e cópia do mesmo (CopyEnvelopeAction), antes do envio. Cada uma destas acções, contémuma Tarefa Funcional e têm de ser adicionadas no fluxo VoteFlow - programa 10.5;

– A remoção de uma acção existente: CopyVote, visto que é a entidade Envelope que passa a serenviada para a urna.

• Mudar uma dada Tarefa Funcional: o fluxo VoteFlow usava a autenticação do módulo Authenti-cationServer, mas com a mudança de Tarefa, a mesma passou-se a realizar com as credenciais doGoogle (email e password) - programa 10.6;

• Adicionar um novo Elemento de Workflow: construção da entidade Envelope no módulo Vote-Server. Este fluxo engloba tanto a acção CreateEnvelopeAction como a acção PutEnvelopeInMan-agerListAction - programa 10.7.

De seguida são apresentados os vários resultados obtidos por cada métrica utilizada. O sistemaauxiliar é o SVE do aluno do Professor Carlos Ribeiro, enquanto o sistema desenvolvido é o resultantedeste trabalho de investigação.

7.2.1 Métrica: Tempo de Análise

Esta métrica compreende o período de tempo em que somos deparados com uma determinada mudança(teste), até ao início da realização da mesma. Basicamente, consiste em pensar nas tarefas que temos derealizar para conseguir cumprir o requisito do teste.

Como é visível na figura 7.5 este tempo, em cada teste, é, notoriamente, menor para o protótipodesenvolvido neste trabalho.

7.2.2 Métrica: Tempo de Conclusão do Teste

A métrica tempo de conclusão do teste foi contabilizada após o término do tempo de análise e até o teste estarcompletamente realizado.

À excepção do teste Adicionar um novo Elemento Conector, o sistema auxiliar demorou, praticamente,o dobro do tempo que o sistema desenvolvido, para terminar cada teste, como é visível na figura 7.6.Isto implica que, é mais rápido e eficiente realizar tarefas de manutenção num sistema normalizado, doque num que não o seja.

O SVE realizado demorou mais tempo a concluir o teste Adicionar um novo Elemento Conector, pois foipreciso criar uma nova Interface e um Elemento Conector com a sua respectiva Tarefa de IO.

64

Figura 7.5: Gráfico de validação: tempo de análise do teste.

Figura 7.6: Gráfico de validação: tempo de conclusão do teste.

65

7.2.3 Métricas: Número de Linhas de Código Acrescentadas / Número de Métodos Criados / Númerode Classes Criadas

Estas três métricas foram agrupadas visto que, tal como evidenciado nas figuras 7.7, 7.8 e 7.9, o sistemadesenvolvido contém maior número de linhas de código, métodos e classes adicionadas, em relação aosistema auxiliar, nomeadamente nos testes Adicionar um novo Elemento de Workflow, Adicionar um novoElemento de Acção e Adicionar um novo Elemento Conector. Isto deve-se ao facto de que para a concretizaçãode uma determinada acção do sistema, é necessária a criação de várias entidades subjacentes, tal comoespecificado no modelo utilizado para descrever as relações entre todos os elementos que compõem ateoria de SN - figura 5.1.

Figura 7.7: Gráfico de validação: número de linhas de código acrescentadas.

Figura 7.8: Gráfico de validação: número de métodos criados.

66

Figura 7.9: Gráfico de validação: número de classes criadas.

7.2.4 Métrica: Acoplamentos Adicionados entre Módulos

Um bom desenho está associado a um fraco acoplamento (fraca dependência entre módulos). Dessemodo, é importante quantificar como é que os dois sistemas se comportam em termos de acoplamentosentre módulos. Tal como evidenciado na figura 7.10, o sistema auxiliar contém um maior número deacoplamentos entre módulos. Estes acoplamentos estão associados a dependências no sistema, o quedificulta a manutenção.

Figura 7.10: Gráfico de validação: acoplamentos adicionados entre módulos.

No sistema desenvolvido, verificou-se uma dependência, no módulo BallotBoxServer, isto porque,o fluxo ProcessVoteFlow recebe um voto, antes de se executar, e com a existência do teste Adicionar umElemento de Acção, passou a receber também uma entidade Envelope. Foi necessário adicionar um con-strutor no fluxo ProcessVoteFlow, para este receber o Envelope e retirar a entidade Vote correspondente.

67

7.2.5 Métrica: Número de Erros Cometidos

Após a obtenção do número de erros cometidos durante a realização de cada teste, figura 7.11, é possívelverificar, para os testes executados, que o sistema desenvolvido obteve um menor número de erros,comparativamente ao sistema auxiliar.

Figura 7.11: Gráfico de validação: número de erros cometidos.

7.2.6 Métrica: Complexidade Ciclomática

A Complexidade ciclomática conta o número de caminhos possíveis a partir do ponto de início até aoponto de saída do programa, sendo que para efeitos deste teste, este métrica apenas contou os caminhospossíveis até à ao ponto de saída de cada teste realizado.

Na figura 7.12 é evidenciado que existe um maior número de caminhos possíveis, no sistema auxil-iar.

Figura 7.12: Gráfico de validação: complexidade ciclomática.

68

7.2.7 Discussão de Resultados

Através da análise dos gráficos, foi possível obter algumas conclusões interessantes. Contudo, antesde apresentarmos essas conclusões, é importante referir que o sistema auxiliar, do aluno André Brioso,foi desenvolvido com o propósito de garantir a verificabilidade de um SVE, não existindo a obrigato-riedade de desenvolver um sistema que seja ágil no futuro. Desse modo, deviam ser utilizados maisSVE, similares ao desenvolvido, para uma melhor validação.

Relativamente aos tempos apresentados, figuras 7.5 e 7.6, é possível observar que os tempos paraefectuar mudanças no sistema desenvolvido, são consideravelmente menores. Isto deve-se ao factodo sistema se encontrar mais organizado, com divisão de preocupações por módulos e com poucasdependências entre eles. O excesso de dependências entre módulos foi o motivo pelo qual o sistemaauxiliar obteve elevados tempos para a realização dos testes. Quando deparado com um teste, Briosotinha de pensar globalmente no seu sistema, nos efeitos que se iriam propagar com uma dada alteração,enquanto que no SVE desenvolvido verifica-se a vantagem de se pensar localmente em cada módulo,dada a estrutura modular do sistema.

Os acoplamentos dificultam a execução de tarefas de manutenção visto que são sinónimos de de-pendências e consequentemente, provocam efeitos combinatórios no sistema. O facto do sistema auxil-iar possuir um maior número de acoplamentos, testes Adicionar um novo Elemento de Acção e Mudar umadada Tarefa Funcional, exactamente nos mesmos testes onde possui maior número de erros e uma maiorcomplexidade ciclomática, pode implicar que quanto maior for o número de caminhos possíveis, maiorserá a probabilidade de adicionar dependências ao sistema. Consequentemente, maior a probabilidadede ocorrência de erros na fase de manutenção - o que implica maior esforço para executar mudanças noSI.

Um sistema normalizado implica a implementação de mais métodos e classes para a realização deuma dada acção, do que um sistema não normalizado. No entanto, e como foi possível verificar com ostempos apresentados, as tarefas de manutenção realizam-se mais rapidamente. Se o objectivo do pro-gramador for implementar rapidamente um sistema, então a teoria de SN não é a mais útil para resolvero problema. Porém, se o objectivo for concretizar um sistema que possa vir a ser modificado no futuro,então a teoria é extremamente útil, permitindo tanto a mudança como o aumento da complexidade,sem degradar as estruturas existentes, mesmo que implique o esforço adicional de se implementar umsistema com elevado número de métodos e classes.

7.3 Discussão Geral dos Resultados Atingidos

O SVE desenvolvido foi utilizado nas eleições para a direcção da AEIST, validando-se assim, a hipóteseH1 ( 1.2.1), visto que através do modelo desenvolvido (figura 5.1) e dos módulos descritos (capítulo5.3) - que representam as três características da teoria de SN (capítulo 3.1) -, foi possível desenvolverum SI.

Verifica-se que quanto maior o número de dependências maior será o esforço necessário para realizaruma mudança no SI, e consequentemente, maior será o tempo despendido para a executar. Deste modo,conclui-se que a teoria de SN é útil, pois evitando dependências ( 7.10) - efeitos combinatórios -, facilitauma evolução rápida dos SI.

Caso o sistema auxiliar fosse de grande escala, supõe-se um maior número de caminhos possíveis, epossivelmente mais acoplamentos - com base na Lei de Lehman (capítulo 2.2.2.1) - e erros obtidos. Oque implica um esforço maior e consequentemente, mais tempo para efectuar os testes. Enquanto que,dada a separação de funcionalidades, no sistema desenvolvido, o tempo e o esforço para realizar tarefas

69

de manutenção, seria praticamente o mesmo, qualquer que seja a sua escala - conceito de estabilidadedefendido pela teoria. Fica assim validada a hipótese H2 ( 1.2.1), sendo possível, com tempo e esforçoreduzidos, alterar/adicionar funcionalidade num SI normalizado, enquanto que sistemas não normal-izados, podem constituir um grande entrave tanto à mudança como ao aumento da complexidade.

7.4 Sumário

Este capítulo descreve a aplicação de alguns testes ao modelo de implementação proposto no capítulo6 e a um outro similar; e as conclusões obtidas sobre a eficiência e utilidade da teoria de SN na imple-mentação de SI.

70

IIIObservações Finais

8Conclusões

”A conclusion is the placewhere you got tired of thinking.”

- Arthur Block

Este trabalho enquadra-se numa área em activo desenvolvimento, com potencial de progresso paraalém da solução proposta, e está inserido nas preocupações actuais das organizações.

Este capítulo visa apresentar as principais conclusões obtidas, os contributos identificados e as limi-tações do trabalho realizado.

8.1 Conclusões Principais

Quanto maior o número de dependências maior será o esforço necessário para realizar uma mudança no SI, econsequentemente, maior será o tempo despendido para a executar.

Com base nos resultados obtidos no capítulo 7, pode-se afirmar que se um SI estiver organizado emfunção de cinco elementos de alto nível (tabela 3.2), suportar os quatro teoremas (tabela 3.1) e basear-se no conceito da modularidade, para a separação de preocupações1, então conseguirá suportar umconjunto de mudanças antecipadas (definição 20 da tabela 3.2), que lhe confere a capacidade evolutiva,ou seja, a capacidade de responder rápida e eficazmente à mudança e ao aumento da complexidade -tornando o SI ágil e estável. Assim sendo, foi cumprido o objectivo inicialmente traçado e encontrada aresposta para o problema desta dissertação:

• A aplicação da teoria de Sistemas Normalizados no desenvolvimento de Sistemas de Informação, permite efec-tuar mudanças e aumentar a complexidade do sistema, com esforço e tempo reduzidos, na fase de manutenção!

Deve-se aproveitar a teoria dos SN para criar e operar software, de modo a mitigar o efeito da lei deLehman. Caso contrário, existe a probabilidade das organizações terem de recomeçar os seus SI de raiz,visto que, pode ser complicado efectuar alterações em sistemas com muitas dependências.

8.2 Análise de Contributos

O contributo principal desta dissertação, que enriquece a comunidade científica, centra-se na aprovaçãode um método que evita problemas de manutenção nas organizações - Teoria de SN. A percepção da teo-

1 Estes três factores contribuem para a fraca dependência entre módulos e forte relação entre itens do mesmo módulo (fraco acoplamento eforte coesão).

73

ria numa organização pode alterar o modo como se pensam e constroem SI. Acredita-se que a aplicaçãoda mesma, possa conduzir a discussões mais ricas entre os engenheiros e os clientes que pretendem veros seus SI ágeis, flexíveis e evolutivos; e que assim se possam dar passos sólidos na construção de SI,constituindo casos de sucesso nas organizações em que são implantados.

Da solução apresentada (capítulo 5) e dos testes desenvolvidos (capítulo 7) extraem-se os restantescontributos:

• Construção de um modelo base para a implementação de qualquer SI, baseado nos elementos eteoremas definidos na teoria de SN - figura 5.1;

• Desenvolvimento de um SVE baseado no modelo proveniente da teoria de SN.

8.2.1 SVE Desenvolvido

A preocupação com a comodidade da população é, nos dias de hoje, um aspecto de crescente relevância,daí ter surgido um aumento de empresas e mecanismos que visam fornecer serviços mais rápidos, maiseficazes e mais eficientes, tendo em vista a automatização dos procedimentos realizados pelos cidadãos.

Um SVE automatiza o processo de voto em papel e verificada a indecisão que existe sobre a modali-dade de voto a realizar, desenvolveu-se um SVE normalizado que poderá transitar entre várias modali-dades de voto, com o mínimo de alterações na sua estrutura.

8.2.2 Modelo Desenvolvido

A aplicação deste modelo e do conceito da modularidade no desenvolvimento de SI, permite a obtençãode inúmeras vantagens, nomeadamente:

• Garantia da capacidade evolutiva das empresas;• Facilidade na realização de tarefas inerentes ao desenvolvimento de software e de gestão de pro-

jecto.

8.2.2.1 Garantia da Capacidade Evolutiva das Empresas

Os objectivos de uma empresa mudam consoante o negócio que se pretende. Mas existe um problema,os sistemas actuais são bastante restritos/fiéis ao que é pedido pelos clientes, o que faz com que ossistemas tenham bastantes dependências. Quando é necessário mudar/adicionar objectivos de negóciotorna-se, por vezes, complicado proceder a alterações em sistemas com muitas dependências, existindoo risco de ser necessário o desenvolvimento de um novo sistema (no pior caso) [4].

Contudo, através dos resultados obtidos foi possível concluir que a aplicação da teoria de SN, nodesenvolvimento de SI, resulta em sistemas modulares (com separação de preocupações), sem grandesdependências, que permitem a mudança/inclusão de funcionalidade, sem degradar as estruturas exis-tentes no sistema.

Deste modo, resolvem-se os problemas de manutenção que impedem as organizações de serem ágeise flexíveis.

8.2.2.2 Facilidade de Tarefas inerentes ao Desenvolvimento de Software e de Gestão de Projecto

A teoria permite obter grandes vantagens, relativamente ao processo de desenvolvimento de software,tais como:

74

• Desenho de um bom sistema, com forte coesão e fraco acoplamento;• Um sistema por módulos facilita a realização de testes e a procura de bugs. No caso de testes,

podemos separar várias equipas de teste, cada uma para o seu módulo em específico; e em casode erro numa determinada funcionalidade, o mesmo é facilmente identificado, dada a separaçãode preocupações por módulos e tarefas;

• Não existindo dependências, evita-se a existência de threads ou recursos de memória locked, emtodo o sistema, por muito tempo - melhorias na performance;

Quanto à gestão de projectos, verificam-se inúmeros benefícios para as organizações, nomeada-mente:

• É possível estimar, eficazmente, o tempo e orçamento requeridos para tarefas de manutenção eimplementação - o esforço de construir um workflow ou uma outra tarefa semelhante vai ser prati-camente o mesmo, quanto mais normalizada e estruturada estiver a arquitectura de software;

• Diminuição do risco no desenvolvimento da aplicação - não existindo um grande esforço de in-tegração, não se vão verificar efeitos combinatórios, os quais estão associados a riscos futuros nosistema;

• Reutilização - todos os sistemas são estruturados e modulares e dessa forma é possível a reutiliza-ção de algumas dessas estruturas noutros projectos;

• Diferentes equipas podem trabalhar em paralelo em diferentes módulos.

Ao fornecer estas contribuições espera-se que os engenheiros, e as equipas de desenvolvimento,tenham uma noção mais clara das vantagens de desenvolver SI baseados na teoria de SN.

8.3 Limitações do Trabalho Realizado

O grande foco deste trabalho foi o mapeamento dos processos de negócio relativos ao processo de voto,nos cinco elementos da teoria de SN (capítulo 5); e de seguida a sua implementação e validação. Con-tudo, e tal como referido no capítulo 7.3, reconhece-se que deviam ser incluídos vários SVE, similaresao desenvolvido, na validação da teoria para obter resultados mais precisos.

Apesar do trabalho ter sido construído e aplicado no âmbito do VE, é lógico que a teoria proposta temainda que ser aplicada a mais âmbitos. Este procedimento é necessário para generalizar a capacidadede aplicação dos conceitos da teoria a qualquer caso.

Seria interessante comparar a teoria de SN com outras teorias, padrões e estilos de Arquitecturasde Software, relacionados com a agilidade e manutenção de SI, não só para analisar o grau de eficácia eeficiência da teoria avaliada, mas também para averiguar se os mesmos possuem semelhanças com ascaracterísticas da teoria de SN ( 3.1).

75

De acordo com as principais conclusões e observações retiradas, pode-se concluir que a flexibilidade e aadaptabilidade são duas qualidades que devem ser consideradas dentro das organizações. Assim sendo,esta dissertação termina com a seguinte frase de Charles Darwin:

"It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive tochange."

76

9Trabalho Futuro”The best way to predict the future is to invent it.”

- Alan Kay

É de salientar que este trabalho cumpre com todos os requisitos propostos inicialmente, no entanto,em função da percepção da implementação e da avaliação que foi feita existem vários aspectos que po-dem ser melhorados ou até mesmo adicionados. Estes aspectos vão ser abordados nesta secção. Algunsrelacionam-se com o protótipo desenvolvido e outros com a própria teoria de SN.

9.1 Protótipo de SVE

O protótipo realizado cumpriu, na plenitude, os objectivos do trabalho permitindo avaliar a teoria deSN. Mas para ser aplicado num contexto real, existem diversos factores que têm de ser melhorados.

9.1.1 Interface

Um dos aspectos considerados como ponto negativo no protótipo desenvolvido e utilizado nas eleiçõespara a direcção da AEIST, foi a existência de uma interface muito simples - figura 7.2. Desse modo, umcaminho possível seria melhorar o aspecto da mesma.

É de realçar que neste trabalho não foi dada ênfase à interacção pessoa-máquina, mas sim ao estudoda viabilidade da teoria de SN. A vertente pessoa-máquina não pode, no entanto, ser desprezada e é,por isso, um dos aspectos a melhorar.

9.1.2 Segurança

No capítulo 4 é referido que um dos grandes problemas, que leva à pouca adesão dos países a SVE,são as fragilidades de segurança, no acto de voto. O âmbito do trabalho não considera aspectos desegurança, no entanto esta área devia ser estudada e incluída no sistema, caso o mesmo venha a serutilizado em contexto real.

9.1.2.1 Autenticação

Como só era esperado um protótipo de um SVE, que permitisse avaliar a teoria de SN, não foi dadagrande importância à autenticação utilizada para aceder ao sistema, estando baseada num simples user-

77

name e password. Em contexto real a autenticação deveria ser feita doutro modo, possivelmente atravésde autenticação biométrica [42].

9.1.3 Transacções

O conceito de transacção utiliza o seguinte padrão:

1. Começo da Transacção;2. Execução de várias manipulações de dados e consultas;3. Se não ocorrerem erros então a transacção faz commit e termina;4. Se ocorrerem erros então a transacção faz rollback e termina;

Deste modo, deveria ser utilizado o conceito de transacção no sistema, de modo a garantir que emcaso de falha, o mesmo não fique inconsistente. Entenda-se que esta inconsistência refere-se a Elementosde Dados com estados incorrectos. Por exemplo, no caso do fluxo VoteFlow, caso a autenticação seja bemsucedida mas a validação no caderno eleitoral não, devia acontecer rollback aos estados actualizados.

9.1.4 Validação

Era importante efectuar uma validação com mais SVE, para obter resultados mais exactos, e não apenasa um, até porque o âmbito do sistema usado era a segurança - verificabilidade do voto - e não a avaliaçãoda capacidade evolutiva do mesmo.

Não obstante, era importante, também, aplicar a teoria a outros âmbitos (não relacionados com oVE), de modo a obter resultados mais concretos e fidedignos sobre a eficácia e eficiência da teoria de SN.

9.2 Teoria de Sistemas Normalizados

9.2.1 Mapeamento Processos de Negócio nos Elementos da Teoria de Sistemas Normalizados

Os fluxos apresentados no capítulo 5.4 seguem a representação apresentada em [1], sendo semelhantesa diagramas de estado. Contudo, essa representação não está formalizada, sendo até sugerido em [48]a sua formalização.

9.2.2 Normalização de Arquitecturas de Sistemas de Informação

Este trabalho provou que a aplicação da teoria no desenvolvimento de um SI é importante para mini-mizar o número de dependências e atingir a estabilidade. Com o intuito de as minimizar, ainda mais,era interessante estender os conceitos principais da teoria de SN, às camadas superiores da ArquitecturaEmpresarial.

Por exemplo, utilizando o mecanismo de extensão da linguagem de modelação para ArquitecturasEmpresariais ArchiMate, era possível aplicar os Elementos e Teoremas da teoria, para garantir que amudança de um determinado business process, no futuro, não tenha repercussões relacionadas com otamanho da arquitectura, mantendo-se constante à medida que a mesma cresce.

Assim sendo, o objectivo desta extensão, seria eliminar as dependências do SI o quanto antes. Quantomais normalizada estiver a estrutura do SI, menos dependências vão existir, melhorando a sua capaci-dade evolutiva.

78

9.2.3 Comparação da teoria de SN com outras Teorias

Seria interessante comparar a teoria de SN com outras teorias relacionadas com a agilidade e manutençãode SI, de modo a encontrar a melhor solução para combater os problemas de manutenção descritos nocapítulo 2.

79

IVReferências

Bibliografia[1] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based on

Laws for Software Evolvability, chapter Production Lines for Business Processes. Koppa, 2009. ISBN:978-90-77160-008.

[2] L.A. Belady and M.M. Lehman. A model of large program development. IBM Systems Journal,pages 225–252, 1976.

[3] Meir M. Lehman and Juan F. Ramil. Rules and tools for software evolution planning and manage-ment. ANNALS OF SOFTWARE ENGINEERING, 11(1):15–44, 2001.

[4] M. M. Lehman. Programs, life cycles, and laws of software evolution. Proceedings of the IEEE,68(9):1060–1076, 1980.

[5] Robert K. Yin. Case Study Research: Design and Methods. Sage Publications, 2nd edition, 1994. ISBN0761925511.

[6] Richard L. Baskerville. Investigating information systems with action research. Journal Communi-cations of the AIS, Vol. 2, Outubro 1999.

[7] André Ferreira Ferrão Couto e Vasconcelos. Arquitecturas dos Sistemas de Informação: Representação eAvaliação. PhD thesis, Universidade Técnica de Lisboa - Instituto Superior Técnico, 2007.

[8] Kenneth Laudon and Jane Laudon. Management Information Systems: Managing the Digital Firm.Prentice Hall, 11th edition, 2009. ISBN-13: 978-0136078463.

[9] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based onLaws for Software Evolvability, chapter Information Systems for the Agile Enterprise. Koppa, 2009.ISBN: 978-90-77160-008.

[10] Guy Fitzgerald. Achieving flexible information systems: the case for improved analysis. Journal ofInformation Technology, Vol.5:5 – 11, 1990.

[11] B. W. Boehm. Software engineering. IEEE Transactions on Computing, pages 1226 – 1241, 1976.

[12] Bennett P. Lientz and E. Burton Swanson. Software Maintenance Management. Addison-Wesley, 1980.ISBN:0201042053.

[13] Stephen G. Eick, Todd L. Graves, Alan F. Karr, J.S. Marron, and Audris Mockus. Does code decay?assessing the evidence from change management data. IEEE Transactions on Software Engineering,Vol.27:1 – 12, 2001.

[14] James R. McKee. Maintenance as a function of design. In AFIPS National Computer Conference, pages187–193, 1984.

[15] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based onLaws for Software Evolvability, chapter Software Constructs to Achieve Modularity. Koppa, 2009.ISBN: 978-90-77160-008.

[16] L.A. Belady and M.M. Lehman. Programming system dynamics, or the meta-dynamics of systemsin maintenance and growth. Technical report, IBM T.J. Watson Research Center, 1971.

[17] M.M. Lehman and L.A. Belady. Program Evolution: Processes of Software Change. Academic Press,1985. ISBN 0-12-442440-6.

[18] Frank Land. Adapting to changing user requirements. Information & Management, 5(2):59 – 75, 1982.

83

[19] J. Sutton. Analysing the future requirements of computer systems. Technical report, WarwickUniversity, 1988.

[20] Marco Aurélio Cordeiro. Métricas de software. Jornal Bate Byte. [Online][Citação: 4 de Janeiro de2011], Website: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=88.

[21] Paulo Krieser. Métricas de software. [Online][Citação: 4 de Janeiro de 2011],Website: http://www.baguete.com.br/colunistas/colunas/51/paulo-krieser/28/04/2010/

metricas-de-software, 28 de Abril de 2010.[22] A. J. Albrecht and J. E. Gaffney. Software function, source lines of code and development effort

prediction: A software science validation. IEEE Transactions on Software Engineering, 9:639 – 648,1983.

[23] T.J. McCabe. A complexity measure. IEEE Transactions on Software Engineering, 2:308–320, 1976.[24] F. B. e Abreu and R. Carapuça. Candidate metrics for object-oriented software within a taxonomy

framework. Journal of Systems and Software, 26(1), 1994.[25] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based on

Laws for Software Evolvability, chapter Laws for Evolvable Software Architectures. Koppa, 2009.ISBN: 978-90-77160-008.

[26] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based onLaws for Software Evolvability, chapter Patterns for Evolvable Software Elements. Koppa, 2009. ISBN:978-90-77160-008.

[27] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Basedon Laws for Software Evolvability, chapter Methodologies for Software Development. Koppa, 2009.ISBN: 978-90-77160-008.

[28] D. L. Parnas, P. C. Clements, and D. M. Weiss. The modular structure of complex systems. In ICSE’84 Proceedings of the 7th international conference on Software engineering, pages 259–266, 1984.

[29] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based onLaws for Software Evolvability, chapter Software Factories for Information Systems. Koppa, 2009.ISBN: 978-90-77160-008.

[30] Herwig Mannaert and Jan Verelst. Normalized Systems - Re-creating Information Technology Based onLaws for Software Evolvability, chapter Reflections on Normalized Systems Theory. Koppa, 2009.ISBN: 978-90-77160-008.

[31] UMIC. O voto electrónico. [Online][Citação: 1 de Outubro de 2010], Website: http://www.votoelectronico.pt/.

[32] Portal do Eleitor. Votar pela primeira vez. [Online][Citação: 27 de Outubro de 2010], Website:http://www.portaldoeleitor.pt/Paginas/Votarpelaprimeiravez.aspx.

[33] Assembleia da República. Regime jurídico do recenseamento eleitoral, 1999. Lei n.º 13/99.[34] Portal do Eleitor. Regime jurídico do recenseamento. [Online][Citação: 19 de Outubro de 2010],

Website: http://www.portaldoeleitor.pt/Paginas/NovoRegimedoRecenseamentoEleitoral.

aspx.[35] Portal do Eleitor. Eleições e referendos. [Online][Citação: 28 de Outubro de 2010], Website: http:

//www.portaldoeleitor.pt/Paginas/TipoDeEleicoeseReferendos.aspx.[36] STAPE. Manual dos membros das mesas de voto. [Online][Citação: 29 de Outubro de 2010],

Website: http://www.stape.pt/eleiref/mesa.htm.[37] UMIC. Experiências de votação electrónica em eleições políticas no mundo. [Online][Citação:

20 de Setembro de 2010], Website: http://www.umic.pt/index.php?option=com_content&task=view&id=3113&Itemid=448.

[38] Paula do Espírito Santo. A hipótese do voto electrónico em portugal: Comportamentos e atitudespolíticas. In Cidadania Digital. Livros LabCom, 2010. ISBN: 978-989-654-051-7.

84

[39] Vabariigi Valimiskomisjon. Statistics about internet voting in estonia. [Online][Citação: 29de Setembro de 2010], Website: http://www.vvk.ee/voting-methods-in-estonia/engindex/statistics.

[40] FEUP-Faculdade de Engenharia da Universidade do Porto. Auditoria ao projecto de voto elec-trónico - eleições legislativas de 20 de fevereiro de 2005. Technical report, 2005.

[41] André Ventura Zúquete and Paulo Jorge Pires Ferreira. Relatório de consultadoria - no âmbito doexperiência piloto de votação electrónica, 2004.

[42] TSE Tribunal Superior Eleitoral. Identificação segura. [Online][Citação: 7 de Novembro de 2010],Website: http://www.tse.gov.br/internet/urnaEletronica/identificacaoSegura.html.

[43] Tribunal Superior Eleitoral. Por dentro da urna. Technical report, 2010.[44] TSE Tribunal Superior Eleitoral. Registro digital do voto. [Online][Citação: 7 de Novembro de

2010], Website: http://www.tse.gov.br/internet/eleicoes/votoeletronico/reg_dig_voto.htm.

[45] The National Election Committee. General description of the e-voting system. Technical report,2004.

[46] Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord,and Judith Stafford. Documenting Software Architectures: Views and Beyond. Addison Wesley, 2002.ISBN 0-201-70372-6.

[47] Carlos Ribeiro. Towards trustworthy internet elections. (Artigo em conclusão em Outubro), 2010.[48] Dieter Van Nuffel, Herwig Mannaert, Carlos De Backer, and Jan Verelst. Deriving normalized

systems elements from business process models. In Fourth International Conference on Software Engi-neering Advances, 2009.

[49] Ivar Jacobson, Grady Booch, and James Rumbaugh. Unified software development process. Addison-Wesley, 1999. ISBN: 0-201-57169-2.

[50] David Garlan and Dewayne E. Perry. Introduction to the special issue on software architecture.Journal IEEE Transactions on Software Engineering, Vol. 21:269–274, Abril 1995.

85

VAnexos

10Anexos

10.1 Fases do Protocolo de Voto do Prótotipo Auxiliar Utilizado

Figura 10.1: Fases do Protocolo de Voto.

10.2 Testes para a Validação da Solução

Nesta secção são apresentados alguns fragmentos de código usados para a validação da teoria de SN,assim como, um exemplo de uma interface desenvolvida.

Programa 10.1: Validação: ClientElement.cs

1 ...2 [Serializable]3 public class ClientElement : Metamodel.DataElement

4 {

5 private String username;

6 private String password;

7 private List<LoginElement > logins;

8 private DateTime dateBorn;

9 private String state;

1011 public ClientElement() {

12 this.logins = new List<LoginElement >();

13 }

1415 ...

1617 public DateTime DateBorn

89

18 {

19 get { return dateBorn; }

20 set { dateBorn = value; }

21 }

22 ...

23 }

24 ...

Programa 10.2: Validação: EnvelopeElement.cs

1 ...

2 [Serializable()]

3 public class EnvelopeElement : Metamodel.DataElement , CommonTypes.EnvelopeInterface

4 {

5 private CommonTypes.VoteInterface vote;

6 private string voter;

7 private string state;

89 public EnvelopeElement() { }

1011 public EnvelopeElement(CommonTypes.VoteInterface vote, String voter) {

12 this.vote = vote;

13 this.voter = voter;

14 }

1516 //Getters and setters

1718 public CommonTypes.VoteInterface Vote

19 {

20 get { return vote; }

21 set { vote = value; }

22 }

2324 public string Voter

25 {

26 get { return voter; }

27 set { voter = value; }

28 }

2930 public String State

31 {

32 get { return this.state; }

33 set { state = value; }

34 }

35 }

36 ...

Figura 10.2: Validação: interface de confirmação de voto.

90

Programa 10.3: Validação: ShowConfirmationVoteConnector.cs

1 ...2 public class ShowConfirmationVoteConnector : Metamodel.ConnectorElement <

ShowConfirmationVoteView >

3 {

4 private ManagerElement me;

5 private VoteElement ve;

6 private String optionVote;

78 public ShowConfirmationVoteConnector(ManagerElement me, VoteElement ve, String

optionVote)

9 {

10 this.me = me;

11 this.ve = ve;

12 this.optionVote = optionVote;

13 this.setIOTask(new IOTask_ShowConfirmationVote(me, ve, optionVote));

14 }

15 }

16 ...

Programa 10.4: Validação: IOTask_ShowConfirmationVote.cs

1 ...2 public class IOTask_ShowConfirmationVote : Metamodel.IOTask<ShowConfirmationVoteView >

3 {

4 private ManagerElement me;

5 private VoteElement ve;

6 private String optionVote;

78 public IOTask_ShowConfirmationVote(ManagerElement me, VoteElement ve, String optionVote

)

9 {

10 this.me = me;

11 this.ve = ve;

12 this.optionVote = optionVote;

13 }

1415 public override ShowConfirmationVoteView execute()

16 {

17 ShowConfirmationVoteView scvv = new ShowConfirmationVoteView();

1819 //Create a windows form

20 new ConfirmationVote(me, ve, optionVote).Show();

2122 return scvv;

23 }

24 }

25 ...

Programa 10.5: Validação: FifthVoteWorkflow.cs

1 ...2 public class FifthVoteWorkflow : Metamodel.WorkflowElement <Object>

3 {

4 private String voter;

5 private ManagerElement me;

6 private VoteElement ve;

7 private String optionVote;

8

91

9 public FifthVoteWorkflow(ManagerElement me, VoteElement ve, String optionVote , String

voter)

10 {

11 this.voter = voter;

12 this.me = me;

13 this.ve = ve;

14 this.optionVote = optionVote;

15 }

1617 public override void execute()

18 {

19 try

20 {

21 //STATE

22 new SetStateVoteAction(me, properties.OPTIONCHOSEN , ve, properties.stringToLogVote)

.execute();

2324 //Associate option to vote

25 new AssociateOptionToVoteAction(optionVote , ve).execute();

2627 //STATE

28 new SetStateVoteAction(me, properties.OPTIONASSOCIATED , ve, properties.

stringToLogVote).execute();

2930 //Put vote in manager list

31 new PutVoteInManagerListAction(me, ve).execute();

3233 //STATE

34 new SetStateVoteAction(me, properties.VOTEADDEDINMANAGERLIST , ve, properties.

stringToLogVote).execute();

3536 //Start Workflow Creation Envelope and obtain it

37 StartWorkflowEnvelopeView swev = (StartWorkflowEnvelopeView)new

StartWorkflowEnvelopeAction(me, voter, ve).execute();

38 EnvelopeElement ee = swev.EnvelopeElement;

3940 //STATE

41 new SetStateVoteAction(me, properties.ENVELOPECREATED , ee, properties.

stringToLogVote).execute();

4243 //Copy Envelope before send it

44 CommonTypes.EnvelopeView envelope = (CommonTypes.EnvelopeView)new

CopyEnvelopeAction(ee).execute();

4546 //STATE

47 new SetStateVoteAction(me, properties.ENVELOPECOPIED , ee, properties.

stringToLogVote).execute();

4849 try

50 {

51 //Vote Flow

52 new VoteFlowAction(envelope).execute();

53 }

54 catch (ServerException)

55 {

56 throw new VoteException(properties.ServerException);

57 }

58 catch (SocketException)

59 {

60 throw new VoteException(properties.SocketException);

61 }

92

62 catch (BallotBoxServer.BallotBoxException ex)

63 {

64 throw new VoteException(ex.field);

65 }

6667 //STATE

68 new SetStateVoteAction(me, properties.SENT, ve, properties.stringToLogVote).execute

();

69 }

70 catch (IOException ex)

71 {

72 throw new VoteException(properties.IOException + " " + ex.ToString());

73 }

74 }

75 }

76 ...

Programa 10.6: Validação: FunctionalTask_LoginFlow.cs

1 ...2 public class FunctionalTask_LoginFlow : Metamodel.FunctionalTask <LoginFlowView >

3 {

4 private CommonTypes.CredentialsView cred;

56 public FunctionalTask_LoginFlow(CommonTypes.CredentialsView cred)

7 {

8 this.cred = cred;

9 }

101112 public override LoginFlowView execute()

13 {

14 //Net Remote

1516 try

17 {

18 string sreq = "https://www.google.com/accounts/ClientLogin?accountType=

HOSTED_OR_GOOGLE&Email=" + this.cred.Username + "&Passwd=" + this.cred.Password

+ "&service=analytics&source=test-test-v1";

19 HttpWebRequest req = (HttpWebRequest)WebRequest.Create(sreq);

20 HttpWebResponse res = (HttpWebResponse)req.GetResponse();

21 }

22 catch (Exception)

23 {

24 throw new GoogleException();

25 }

2627 LoginFlowView lfv = new LoginFlowView();

28 return lfv;

29 }

30 }

31 ...

Programa 10.7: Validação: EnvelopeWorkflow.cs

1 ...2 public class EnvelopeWorkflow : Metamodel.WorkflowElement <Object>

3 {

4 private CommonTypes.VoteInterface vote;

5 private String voter;

93

678 public EnvelopeWorkflow(CommonTypes.VoteInterface vote, String voter)

9 {

10 this.vote = vote;

11 this.voter = voter;

12 }

1314 public override void execute()

15 {

1617 //To create a vote instance

18 GetManagerView gmv = (GetManagerView)new GetManagerAction().execute();

19 ManagerElement me = gmv.ManagerElement;

2021 CreateEnvelopeView cev = (CreateEnvelopeView)new CreateEnvelopeAction(me, vote, voter

).execute();

22 EnvelopeElement ee = cev.EnvelopeElement;

2324 //STATE

25 new SetStateEnvelopeAction(me, properties.CREATED, ee, properties.stringToLogEnvelope

).execute();

2627 //Put Envelope in Manager

28 new PutEnvelopeInManagerListAction(me, ee).execute();

2930 //STATE

31 new SetStateEnvelopeAction(me, properties.ENVELOPESAVED , ee, properties.

stringToLogEnvelope).execute();

3233 }

34 }

35 ...

10.3 Modelo de Domínio

Nesta secção é detalhado o Modelo de Domínio de cada módulo do SVE desenvolvido e referente aoselementos descritos na teoria de SN.

10.3.1 Authentication Server

94

Figura 10.3: Modelo de domínio: Authentication Server - Data Elements

Figura 10.4: Modelo de domínio: Authentication Server - Workflow Elements

95

Figura 10.5: Modelo de domínio: Authentication Server - Action Elements

96

Figura 10.6: Modelo de domínio: Authentication Server - Connector Elements

Figura 10.7: Modelo de domínio: Authentication Server - IO Tasks

Figura 10.8: Modelo de domínio: Authentication Server - Support Tasks

97

Figura 10.9: Modelo de domínio: Authentication Server - Functional Tasks98

10.3.2 Electoral Notebook Server

Figura 10.10: Modelo de domínio: Electoral Notebook Server - Data Elements

Figura 10.11: Modelo de domínio: Electoral Notebook Server - Workflow Elements

99

Figura 10.12: Modelo de domínio: Electoral Notebook Server - Action Elements

100

Figura 10.13: Modelo de domínio: Electoral Notebook Server - Connector Elements

Figura 10.14: Modelo de domínio: Electoral Notebook Server - IO Tasks

Figura 10.15: Modelo de domínio: Electoral Notebook Server - Support Tasks

101

Figura 10.16: Modelo de domínio: Electoral Notebook Server - Functional Tasks

102

10.3.3 Vote Server

Figura 10.17: Modelo de domínio: Vote Server - Data Elements

Figura 10.18: Modelo de domínio: Vote Server - Workflow Elements

103

Figura 10.19: Modelo de domínio: Vote Server - Action Elements

104

Figura 10.20: Modelo de domínio: Vote Server - Connector Elements

Figura 10.21: Modelo de domínio: Vote Server - IO Tasks

105

Figura 10.22: Modelo de domínio: Vote Server - Functional Tasks106

Figura 10.23: Modelo de domínio: Vote Server - Support Tasks

10.3.4 Ballot Box Server

Figura 10.24: Modelo de domínio: Ballot Box Server - Data Elements

107

Figura 10.25: Modelo de domínio: Ballot Box Server - Connector Elements

Figura 10.26: Modelo de domínio: Ballot Box Server - IO Tasks

108

Figura 10.27: Modelo de domínio: Ballot Box Server - Action Elements109

Figura 10.28: Modelo de domínio: Ballot Box Server - Functional Tasks

110

Figura 10.29: Modelo de domínio: Ballot Box Server - Workflow Elements

Figura 10.30: Modelo de domínio: Ballot Box Server - Support Tasks

10.4 Evoluções das Abstrações e Metodologias para o Desenvolvimento de Soft-ware

Nesta secção são descritas as evoluções tanto ao nível das abstrações na programação, como ao níveldas metodologias para o desenvolvimento de software.

111

Mecanism

osD

escrição

Evoluções

Abstrações

Básicas

deProgram

açãoProgram

açãoE

struturadaFunções

eprocedim

entosque

agregamvariáveis

ein-

struções(Pascal,C

,etc.).Program

açãoO

rientadaa

Objectos

Aprincipal

abstraçãointroduzida

foio

conceitode

classe.Program

açãoO

rientadaa

Aspectos

Oobjectivo

étentarm

odularizaroscross-cutting

con-cerns

dispersosportodo

osistem

a.

Derivada

porAgregação

a

Bibliotecas

ePacotes

Agregação

nasua

forma

mais

básica.D

esenvolvimento

Baseado

emC

omponentes

Um

componente

éconstituído

porfunções

ouobjec-

tose

podeconter

outroscom

ponentes.C

omponentes

sãom

óduloscom

múltiplas

interfaces.SO

A(A

rquitecturasO

rientadasa

Serviços)O

sserviços

sãocom

postospor

funçõesou

classese

podemtam

bémconter

componentes.

Os

serviços,providenciando

funcionalidade,efectuamcham

adasa

outrosserviços.

Metodologias b

Geração

Estruturada

Perspectivado

ProdutoA

bstraçõesbaseadas

emhierarquias

defunções

epro-

cedimentos.

Perspectivado

Processoc

Om

odelodom

inantede

processofoio

modelo

decas-

cata

Geração

OO

Perspectivado

ProcessoSurgiram

odesenvolvim

entoIterativo,o

modelo

Es-

piraleo

ProcessoU

nificado.U

ML

Linguagem

/notaçãopara

modelação

conceptual.Perspectiva

doProduto

Abstrações

como

classese

objectos.Conceito

deher-

ançae

ocultaçãode

informação.

Recentes

Desenvolvim

entoágil

As

metodologias

ágeispretendem

responderà

mu-

dançacom

aentrega

desoftw

arede

valorresultando

emvantagem

competitiva

parao

cliente.A

rquitecturade

Software

dR

efere-seao

desenhode

altonívelde

software.

Arquitectura

Em

presarialFoco

nodesenho

dealto

nível,na

integraçãode

SIe

narelação

entreo

negócioe

asIC

T(E

xemplos:

Framew

orkde

Zachm

ane

TOG

AF).

CM

MI(C

apabilityM

aturityM

odelIntegration)M

odelode

referênciaque

contémpráticas

quepreten-

demdeterm

inaraqualidade

deum

sistema

ouproduto

noseu

desenvolvimento

como

nasua

manutenção.

Tabela10.1:

Evoluções

quese

verificaramtanto

aoníveldas

abstraçõesna

programação,com

oao

níveldasm

etodologiaspara

odesenvolvim

entode

software

aSãoconsiderados

abstraçõesde

software

queapontam

paraa

agregaçãode

pedaçosde

software

escritospordiferentes

programadores.

bUm

am

etodologiaé

uma

abordagemregularde

planeamento,análise,desenho,construção

eevolução

deSI[27]

cJacobson,Booch

eR

umbaugh

referemque

umprocesso

dedesenvolvim

entoé

adefinição

doconjunto

completo

deactividades

necessáriaspara

transformaros

requisitosdos

utilizadoresnum

conjuntoconsistente

deartefactos

querepresentem

oproduto

desoftw

aree,m

aistarde,perm

itatransform

arasm

udançasnesses

mesm

osrequisitos

emnovos,consistentes

artefactos.[49]dG

arlane

Perrydefinem

arquitecturacom

o"a

estruturados

componentes

deum

sistema/program

a,oseu

inter-relacionamento,e

osprincípios

eguidelines

quegerem

oseu

desenhoe

evoluçãoao

longodo

tempo.[50]".

112