UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIENCIAS EXATAS E NATURAIS BACHARELADO CURSO DE SISTEMAS DE INFORMAC AO

AUTOMATICA SISTEMA PARA CORREC AO DE QUESTOES NAS PROVAS DE CONCURSOS DE PROGRAMAC AO

MARCOS KIRCHNER

BLUMENAU 2004 2004/II-08

MARCOS KIRCHNER

AUTOMATICA SISTEMA PARA CORREC AO DE QUESTOES NAS PROVAS DE CONCURSOS DE PROGRAMAC AO

Trabalho de Conclus ao de Curso submetido ` a Universidade Regional de Blumenau para a obten c ao dos cr editos na disciplina Trabalho de Conclus ao de Curso II do curso de Sistemas de Informa c ao Bacharelado. Prof. Jomi Fred H ubner Orientador

BLUMENAU 2004 2004/II-08

 AUTOMATICA SISTEMA PARA CORREC AO DE QUESTOES NAS PROVAS DE CONCURSOS DE PROGRAMAC AO

Por

MARCOS KIRCHNER

Trabalho aprovado para obten c ao dos cr editos na disciplina de Trabalho de Conclus ao de Curso II, pela banca examinadora formada por:

Presidente:

Prof. Jomi Fred H ubner Orientador, FURB

Membro:

Prof. Roberto Heinzle, FURB

Membro:

Prof. Alexander Roberto Valdameri, FURB

BLUMENAU 2004

AGRADECIMENTOS

Agrade co ao professor Jomi pela paci encia quando eu resolvi mudar o tema do meu
A trabalho, pela colabora c ao neste trabalho e por ter recomandado o uso do L TEX para

escrever esse texto. Aos meus pais que me ensinaram ou possibilitaram que eu aprendesse tudo que sei hoje. ` todos que de alguma forma contribu A ram com a realiza c ao deste.

RESUMO

Este trabalho apresenta um sistema de corre c ao automatizada a ser utilizado em provas de concursos de programa c ao. Um sistema desse g enero deve prover um ambiente seguro para executar c odigo arbitr ario enviado por qualquer programador, sem comprometer as informa c oes condenciais e a estabilidade do sistema. O sistema foi implementado em linguagem C#.NET e corrige programas nessa mesma linguagem, mas foi projetado o intuito de adi c ao de m odulos para outras linguagens. Palavras Chave: Competi c oes de programa c ao, Ambiente de execu c ao seguro, Sistema de corre c ao automatizada.

ABSTRACT

This work presents an online judge system to be used in programming contests. Such a system must provide a secure execution environment that can execute arbitrary code submitted by any programmer, without compromising condential informations or system stability. This systems been implemented in C#.NET language and can judge programs written in this same language, but has been projected with extensibility for new programming languages in mind. Key-Words: Programming contests, Secure execution environment, Online judge.

 LISTA DE ILUSTRAC OES

Figura 2.1 Intera c ao do .NET Framework com os componentes do sistema operacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figura 2.2 Estrutura de uma assembly. . . . . . . . . . . . . . . . . . . . . . 23 Figura 2.3 Vis ao simplicada da seguran ca de acesso do c odigo. . . . . . . . . 26 Figura 2.4 Grupos de c odigo de um n vel da pol tica de seguran ca. . . . . . . 27 Figura 2.5 Intera c ao dos componentes durante uma requisi c ao de in cio e naliza c ao de um servi co. . . . . . . . . . . . . . . . . . . . . . . . 32 Figura 3.1 Diagrama de casos de uso do sistema web. . . . . . . . . . . . . . . 36 Figura 3.2 Diagrama de casos de uso do sistema de corre c ao. . . . . . . . . . 37 Figura 3.3 Componentes do sistema. . . . . . . . . . . . . . . . . . . . . . . . 37 Figura 3.4 Diagrama de classes do componente Model. . . . . . . . . . . . . . 39 Figura 3.5 Diagrama de classes do componente ReportModel. . . . . . . . . . 40 Figura 3.6 Diagrama de classes do componente IDAL. . . . . . . . . . . . . . 41 Figura 3.7 Modelo conceitual do banco de dados. . . . . . . . . . . . . . . . . 42 Figura 3.8 Diagrama de classes do componente DALFactory. . . . . . . . . . 43 Figura 3.9 Diagrama de classes do componente BLL. . . . . . . . . . . . . . . 44 Figura 3.10 Diagrama de navega c ao do sistema web. . . . . . . . . . . . . . . . 45 Figura 3.11 Intera c ao dos componentes com o sistema web durante o envio de uma solu c ao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Figura 3.12 Diagrama de classes do componente JudgeServer. . . . . . . . . . 48

Figura 3.13 Intera c ao dos componentes do sistema de corre c ao durante a corre c ao de uma solu c ao. . . . . . . . . . . . . . . . . . . . . . . . 49

Figura 3.14 Rela c ao entre os processos e os Application Domains do sistema de corre c ao e do Wrapper. . . . . . . . . . . . . . . . . . . . . . . 56 Figura 3.15 Tela de cadastro de categorias. . . . . . . . . . . . . . . . . . . . . 59 Figura 3.16 Tela de cadastro de problemas. . . . . . . . . . . . . . . . . . . . . 60 Figura 3.17 Tela para indica c ao das categorias dos problemas. . . . . . . . . . 60 Figura 3.18 Tela de cadastro de conjuntos de entrada e sa da para avalia c ao. . 61 Figura 3.19 Tela de cadastro de categorias. . . . . . . . . . . . . . . . . . . . . 61 Figura 3.20 Tela para indica c ao dos problemas de uma competi c ao. . . . . . . 61 Figura 3.21 Tela de cadastro de usu arios. . . . . . . . . . . . . . . . . . . . . . 62 Figura 3.22 Tela com a lista de categorias. . . . . . . . . . . . . . . . . . . . . 62 Figura 3.23 Tela com a lista de problemas por categoria. . . . . . . . . . . . . 63 Figura 3.24 Tela com os detalhes do problema. . . . . . . . . . . . . . . . . . . 63 Figura 3.25 Tela com as competi c oes. . . . . . . . . . . . . . . . . . . . . . . . 64 Figura 3.26 Tela com os detalhes da competi c ao. . . . . . . . . . . . . . . . . . 64 Figura 3.27 Tela para submiss ao de programas. . . . . . . . . . . . . . . . . . 65 Figura 3.28 Tela com a lista das u ltimas submiss oes. . . . . . . . . . . . . . . 65

Figura 3.29 Resultados do sistema de corre c ao para os dois programas maliciosos submetidos a corre c ao. . . . . . . . . . . . . . . . . . . . . . . 67 Figura 3.30 Tela com as estat sticas dos problemas. . . . . . . . . . . . . . . . 67 Figura 3.31 Tela com ranking de autores. . . . . . . . . . . . . . . . . . . . . . 67

LISTA DE QUADROS

2.1 3.1 3.2 3.3 3.4

Exemplo de uso de seguran ca baseada em fun c oes. . . . . . . . . . . . . . . 24 Procedimento armazenado para listar as competi c oes de um usu ario. . . . . 51 C odigo para chamar o procedimento armazenado ContestsListByUser. . . . 52 Atributos e propriedades da classe CountryInfo. . . . . . . . . . . . . . . . 53 Congura c ao de seguran ca para a area restrita ao administrador do sistema web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5 3.6 3.7 3.8 3.9

C odigo para autentica c ao do usu ario no sistema web. . . . . . . . . . . . . 54 C odigo do servi co do Windows. . . . . . . . . . . . . . . . . . . . . . . . . 54 C odigo do m etodo Submission.SignalJudge() do componente BLL. . . . . . 55 Atributo para identica c ao do programa submetido para corre c ao. . . . . . 56 Rotina principal do programa Wrapper. . . . . . . . . . . . . . . . . . . . . 57

3.10 Rotina CreateAppDomain() do programa Wrapper. . . . . . . . . . . . . . 58 3.11 Programa malicioso que consome muito tempo de CPU. . . . . . . . . . . . 66 3.12 Programa malicioso que tenta acessar o disco. . . . . . . . . . . . . . . . . 66

LISTA DE TABELAS

3.1 3.2

Requisitos funcionais do sistema . . . . . . . . . . . . . . . . . . . . . . . . 34 Requisitos n ao funcionais do sistema . . . . . . . . . . . . . . . . . . . . . 35

LISTA DE ABREVIATURAS

ACM Association for Computing Machinery ACM ICPC Association for Computing Machinery (ACM) International Collegiate Programming Contest API Application Programming Interfaces ASP Active Server Pages CLR Common Language Runtime COM Component Object Model CSS Cascading Style Sheets DAAB Data Access Application Block DAL Data Access Logic DNS Domain Name System DOM Document Object Model GAC Global Assembly Cache GUID Globally Unique Identier HTML Hypertext Markup Language HTTP Hypertext Transport Protocol IDE Integrated Development Environment IIS Internet Information Services IOI International Olympiad in Informatics JIT just-in-time MER Modelo Entidade-Relacionamento

MSIL Microsoft Intermediate Language MVC Model-View-Controler PHP PHP: Hypertext Preprocessor SCM Service Control Manager SDK Software Development Kit SGBD Sistema Gerenciador de Banco de Dados SP Stored Procedure SQL Structured Query Language TI Tecnologia da Informa c ao UML Unied Modeling Language URL Uniform Resource Locator W3C World Wide Web Consortium XHTML Extensible Hypertext Markup Language XML Extensible Markup Language

 SUMARIO

1 Introdu c ao 1.1 1.2

16

Objetivos do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 19

2 Fundamenta c ao te orica 2.1

Competi c oes de programa c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1 2.2.2 2.2.3 2.3 2.4 Seguran ca de aplica c oes .NET . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Servi cos do Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Web standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Trabalhos correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34

3 Desenvolvimento do sistema 3.1 3.1.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4

Requisitos principais do problema a ser trabalhado . . . . . . . . . . . . . . . 34 Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Especica c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Componente Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Componente ReportModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Componente IDAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Componente DALFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.5 3.2.6 3.2.7 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.4 3.4.1

Componente BLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Componente Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Componente JudgeServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Implementa c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 T ecnicas e ferramentas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . 50 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Sistema web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Sistema de corre c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Operacionalidade da implementa c ao . . . . . . . . . . . . . . . . . . . . . . 59 Resultados e discuss ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Diculdades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 70

4 Conclus oes 4.1

Extens oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 72 74

Refer encias Bibliogr acas Ap endice A -- Cen arios dos casos de uso do sistema web

A.1 Use Case Autentica c ao usu ario . . . . . . . . . . . . . . . . . . . . . . . . . . 74 A.2 Use Case Cadastro de categorias . . . . . . . . . . . . . . . . . . . . . . . . . 74 A.3 Use Case Cadastro de problemas . . . . . . . . . . . . . . . . . . . . . . . . . 75 A.4 Use Case Cadastro usu ario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 A.5 Use Case Criar competi c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.6 Use Case Enviar solu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.7 Use Case Inscrever em competi c ao . . . . . . . . . . . . . . . . . . . . . . . . 77

A.8 Use Case Relat orio de estat sticas dos problemas . . . . . . . . . . . . . . . . 77 A.9 Use Case Visualizar problema . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.10 Use Case Visualizar ranking autores . . . . . . . . . . . . . . . . . . . . . . . 78 A.11 Use Case Visualizar relat orio submiss oes . . . . . . . . . . . . . . . . . . . . 78 Ap endice B -- Cen arios dos casos de uso do sistema de corre c ao 79

B.1 Use Case Corrigir programa . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Anexo A -- Permiss oes pr e-denidas do .NET 81

16

INTRODUC AO
Concursos de programa c ao s ao competi c oes organizadas por alguma entidade, onde

v arias equipes recebem um determinado n umero de problemas e devem resolv e-los escrevendo um programa. H a algumas boas raz oes para se participar desse tipo de concurso. As pessoas podem se divertir, ao mesmo tempo em que aprimoram suas habilidades de programa c ao e aumentam as perspectivas de trabalhos. Al em disso, alguns concursos como o TopCoder Challenge d ao pr emios em dinheiro (SKIENA; REVILLA, 2003, p. 345). O n umero de participantes em concursos e elevado. Na competi c ao da ACM de 2004, participaram 3150 times de 75 pa ses e 73 times avan caram para as nais mundiais (ASSOCIATION FOR COMPUTING MACHINERY, 2004). Os times normalmente recebem v arios problemas para serem solucionados e podem submeter um programa ` a corre c ao v arias vezes (pass vel de puni c ao para solu c oes incorretas). Durante as provas os times precisam de uma resposta r apida sobre a corre c ao do programa, para aprimorar a implementa c ao caso necess ario, ou direcionar seus esfor cos para a solu c ao de outro problema. Por em, e invi avel para a equipe organizadora da competi c ao receber e testar manualmente cada problema submetido. Para apresentar a resposta de uma submiss ao em tempo adequado, as competi c oes normalmente fazem uso de sistemas de corre c ao automatizados (juizes on-line). Segundo Manzoor (2004), a ACM utiliza um software chamado PC2 em suas competi c oes. Esse tipo de software parece simples ` a primeira vista. Ele deve compilar o programa fonte submetido, carregar o arquivo execut avel e passar para o programa os dados de entrada. Assim que o programa nalizar, a sa da do programa submetido deve ser comparada com a sa da esperada, para determinar se o programa submetido resolveu a quest ao corretamente. No entanto, h a riscos signicantes associados ` a execu c ao de c odigo arbitr ario: c odigo malicioso pode danicar os recursos computacionais, roubar informa c oes privativas, monitorar as atividades do usu ario ou conseguir acesso para disparar ataques futuros (STONY BROOK UNIVERSITY, 2002). Conforme ressaltado por Stack, Eide e Lepreau (2003), o ambiente de execu c ao deve ser seguro e robusto, n ao permitindo que um programa malicioso consuma excessivos recursos da m aquina. Recursos principais incluem tempo de processador, mem oria, tempo de disco e utiliza c ao da rede.

1.1 Objetivos do trabalho

17

Al em de serem utilizados em concursos de programa c ao, alguns softwares desse tipo, a notar (UNIVERSIDAD DE VALLADOLID, [2004?]) e (URAL STATE UNIVERSITY, [2004?]) est ao dispon veis na Internet para que qualquer pessoa possa, a t tulo de aprimorar habilidades de programa c ao, treinar para competi c oes ou divertir-se, resolver problemas e submet e-los para corre c ao. Os softwares conhecidos apresentam recursos de seguran ca para prote c ao contra c odigo malicioso, e normalmente compilam e executam, com poucas restri c oes, programas escritos em C, C++, Java ou Pascal. Al em disso, os softwares s ao criados para ambientes Unix / Linux. N ao se tem conhecimento de implementa c ao de um software similar que opere em ambiente Windows e/ou aceite submiss ao de programas escritos em linguagem C#. A proposta desse trabalho e a cria c ao de um sistema de corre c ao automatizada, com recursos de seguran ca similares aos sistemas existentes e que possa ser executado em ambiente Windows para compila c ao e execu c ao de c odigo escrito em C#. Ainda assim, o sistema deve apresentar uma arquitetura expans vel para que seja poss vel adicionar capacidade de compila c ao e execu c ao de c odigo escrito em outras linguagens. Para gerenciamento do sistema de corre c ao, prop oe-se um sistema de informa c ao em ambiente web que ser a respons avel pela parte do gerenciamento de usu arios, problemas dispon veis para corre c ao, competi c oes e pela gera c ao de relat orios diversos. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho e implementar um sistema que fa ca a corre c ao autom atica de quest oes em provas de concursos de programa c ao para programas escritos em linguagem C# .NET. Os objetivos espec cos do trabalho s ao: a) implementar um servi co do Windows que fa ca a corre c ao das quest oes submetidas para avalia c ao; b) projetar uma arquitetura expans vel de forma que possam ser adicionados m odulos para compila c ao de programas escritos em outras linguagens e a utiliza c ao de outros sistemas gerenciadores de banco de dados; c) criar um ambiente de execu c ao seguro, onde se possa executar c odigo arbitr ario enviado por qualquer programador, sem comprometer a seguran ca e estabilidade do sistema e do computador; d) utilizar as op c oes de seguran ca fornecidas pelo .NET Framework; e) criar uma interface web para o sistema.

1.2 Estrutura do trabalho

18

1.2 ESTRUTURA DO TRABALHO O cap tulo 2 apresenta a fundamenta c ao te orica sobre competi c oes de programa c ao, .NET e web standards. O desenvolvimento do trabalho, incluindo requisitos, especica c ao, implementa c ao de discuss ao dos resultados encontra-se no cap tulo 3. O cap tulo 4 apresenta as conclus oes obtidas e sugere extens oes do presente trabalho.

19

TEORICA FUNDAMENTAC AO
Este cap tulo apresenta fundamenta c ao te orica pertinente ao tema de estudo do

trabalho desenvolvido. A se c ao 2.1 apresenta de forma sucinta algumas competi c oes de programa c ao. A se c ao 2.2 versa sobre o .NET Framework e tecnologias ans, focando no aspecto de seguran ca que e fundamental para este trabalho (se c ao 2.2.1), e apresenta os conceitos do ASP.NET (se c ao 2.2.2) e servi cos do Windows (se c ao 2.2.3). Segue-se uma se c ao sobre web standards, utilizado no desenvolvimento do sistema web deste trabalho (se c ao 2.3) e naliza-se com uma se c ao sobre trabalhos correlatos (se c ao 2.4). 2.1 COMPETIC OES DE PROGRAMAC AO As tr es competi c oes de programa c ao mais importantes, segundo Skiena e Revilla (2003, p. 339), s ao a ACM International Collegiate Programming Contest (ACM ICPC), a International Olympiad in Informatics (IOI) e o TopCoder Challenge. A ACM ICPC e a maior competi c ao de programa c ao do mundo e e uma atividade da ACM que d a a oportunidade a alunos de faculdade de demonstrarem e agu carem sua capacidade de resolver problemas e habilidades em computa c ao (GUPTA, 2004). As equipes s ao formadas por tr es pessoas, e podem utilizar apenas um computador. A competi c ao dura cinco horas e cont em cerca de oito problemas. A equipe campe a e aquela que resolver corretamente o maior n umero de problemas. A IOI e uma competi c ao para estudantes do ensino m edio e seus objetivos s ao um tanto quanto diferentes dos da ACM ICPC. Os participantes desse evento normalmente n ao deniram a carreira que desejam seguir ainda. O evento procura estimular o interesse dos participantes na area de inform atica. J a o TopCoder Challenge e uma competi c ao aberta a todos os programadores. A maior atra c ao dessa competi c ao s ao pr emios em dinheiro. Al em disso, a companhia TopCoder usa as competi c oes para identicar programadores promissores e fornece essas informa c oes para seus clientes (SKIENA; REVILLA, 2003, p. 354).

2.2 .NET Framework

20

2.2 .NET FRAMEWORK O .NET Framework e, segundo Microsoft Corporation (2002b), uma das tecnologias centrais da plataforma .NET, e prov e a estrutura de tempo de compila c ao e tempo de execu c ao necess aria para criar e executar aplica c oes baseadas em .NET. Microsoft Corporation (2004b) explica que o .NET e uma nova plataforma computacional que simplica o desenvolvimento de aplicativos em ambientes distribu dos e que foi projetada para satisfazer os seguintes objetivos: a) prover um ambiente de programa c ao orientado a objetos consistente, independente se o c odigo e armazenado e executado localmente, executado localmente mas distribu do pela Internet ou executado remotamente; b) prover um ambiente de execu c ao que minimiza os conitos de distribui c ao e de vers oes de software; c) prover um ambiente de execu c ao que garanta a execu c ao segura de c odigo; d) prover um ambiente de execu c ao que elimine os problemas de desempenho de ambientes interpretados e linguagens de script; e) tornar a experi encia do desenvolvedor consistente atrav es dos v arios tipos de aplica c oes, como aplica c oes baseadas em Windows e na web ; f) utilizar padr oes da ind ustria para todas as formas de comunica c ao, garantindo que c odigo baseado no .NET Framework possa integrar com qualquer outro c odigo. O .NET Framework tem dois componentes principais: o Common Language Runtime (CLR) e a biblioteca de classes (MICROSOFT CORPORATION, 2004b). O CLR gerencia o c odigo em tempo de execu c ao e prov e os servi cos principais, como gerenciamento de mem oria e de linhas de execu c ao (Threads ), compila c ao e outros servi cos do sistema, al em de promover a seguran ca e robustez do c odigo. O c odigo compilado para execu c ao no CLR e chamado c odigo gerenciado (Managed code ), enquanto c odigo que n ao executa no CLR e chamado c odigo n ao-gerenciado (Unmanaged code ). A biblioteca de classes e uma cole c ao de c odigo pr e-escrito para executar uma grande variedade de tarefas, incluindo exibir janelas e formul arios, acessar os servi cos b asicos do Windows, ler e escrever em arquivos, acessar a rede e a Internet e acessar fontes de dados. A g. 2.1 mostra a rela c ao entre o CLR e a biblioteca de classes com as aplica c oes e com o sistema de um modo geral. Para que o CLR possa prover servi cos ao c odigo gerenciado, os compiladores devem

2.2 .NET Framework

21

emitir metadados, que descrevem os tipos, membros e refer encias no c odigo. O metadados e armazenado juntamente com o c odigo. O CLR utiliza o metadados para localizar e carregar classes, posicionar as inst ancias dos objetos na mem oria, resolver as invoca c oes de m etodos, gerar c odigo nativo, garantir a seguran ca e denir os limites do contexto de execu c ao.

Fonte: Microsoft Corporation (2004b). Figura 2.1 Intera c ao do .NET Framework com os componentes do sistema operacional.

O processo de execu c ao do c odigo gerenciado engloba as seguintes etapas (MICROSOFT CORPORATION, 2004b):

a) usar um compilador para converter o c odigo-fonte em Microsoft Intermediate Language (MSIL), que e um conjunto de instru c oes independentes da arquitetura da CPU e que pode ser ecientemente convertido em c odigo nativo. Quando um compilador produz c odigo MSIL tamb em e emitido o metadados; b) antes de ser executado, o c odigo MSIL deve passar por um compilador just-intime (JIT) para ser convertido em c odigo nativo, que e o c odigo especico para

2.2 .NET Framework

22

a arquitetura da CPU onde o programa e o compilador JIT est ao executando. odigo pode A compila c ao JIT leva em conta o fato de que alguma parte do c vir a n ao ser executada. Ao inv es de converter todo o c odigo MSIL em c odigo nativo, a convers ao e feita conforme necessidade e o c odigo nativo resultante e armazenado na mem oria para chamadas subseq uentes. Antes de ser compilado em c odigo nativo, o c odigo MSIL deve passar por um processo de verica c ao, que examina o c odigo MSIL e o metadados para descobrir se o c odigo e type c ao h a uma inspe c ao para determinar se o c odigo MSIL safe 1 . Durante a verica foi gerado corretamente. Se a verica c ao determinar que o c odigo n ao e type safe, uma exce c ao e gerada no momento da execu c ao; c) depois de ter passado pelo processo de compila c ao JIT e gera c ao de c odigo nativo, o c odigo pode ser executado. Cada m etodo do programa deve passar pelo processo de compila c ao JIT na primeira vez que e invocado. O processo de compila c ao JIT e execu c ao e repetido at e que o programa seja nalizado. Durante a execu c ao, o CLR prov e servi cos como identica c ao e destrui c ao de objetos sem refer encias (Garbage collection ), seguran ca, interoperabilidade com c odigo n aogerenciado, suporte a depura c ao entre v arias linguagens e um suporte avan cado a distribui c ao e controle de vers oes. Conforme Robinson et al. (2001), o c odigo MSIL resultante da compila c ao e armazenado em uma unidade l ogica chama assembly. Uma assembly e auto-descrit vel, e consiste do metadados que descreve a assembly, metadados que descrevem os tipos e m etodos, c odigo MSIL e recursos. Essas partes podem residir em um u nico arquivo ou espalhadas por v arios arquivos. No caso de uma assembly com mais de um arquivo, o metadados que descreve a assembly cont em refer encias para os demais arquivos, como ilustrado na g. 2.2. Durante a execu c ao, o CLR carrega as assemblies em um application domain. Application domains s ao uma unidade de processamento que o CLR emprega para prover isolamento entre as aplica c oes. Processos tem sido utilizados para isolar aplica c oes, sendo cada aplica c ao carregada em um processo separado (MICROSOFT CORPORATION, 2004b). Apesar de processos serem ideais para isolamento de aplica c oes, a comunica c ao e a troca de contexto entre processos e custosa em termos de desempenho. Robinson et al. (2001) explicam que o CLR divide um processo em m ultiplos application domains, o que permite isolar os componentes sem o impacto de desempenho associado com a comunica c ao entre processos.
1

C odigo que acessa apenas as regi oes de mem oria que e autorizado a acessar.

2.2 .NET Framework

23

Fonte: Robinson et al. (2001, p. 4867). Figura 2.2 Estrutura de uma assembly.

2.2.1 SEGURANC A DE APLICAC OES .NET O .NET Framework oferece recursos de seguran ca de c odigo e seguran ca de usu arios que ajudam a lidar com as preocupa c oes de seguran ca sobre c odigo m ovel (MICROSOFT c ao nossa), Seguran ca CORPORATION, 2004b). Segundo Watkins e Lange (2002, tradu baseada no c odigo [. . . ] e um recurso fundamental para permitir seguran ca sobre c odigo m ovel. C odigo m ovel pode ser acessado e executado por qualquer n umero de usu arios, desconhecidos durante o desenvolvimento.. As duas formas de seguran ca complementam uma a outra. Meier et al. (2003, tradu c ao nossa) explica que a seguran ca de usu arios responde a quest ao Quem e o usu ario e o que ele pode fazer?enquanto que a seguran ca de c odigo lida com De onde vem o c odigo, quem escreveu este c odigo e o que o c odigo pode fazer?. A implementa c ao de seguran ca de usu arios no .NET Framework e chamada de seguran ca baseada em fun c oes (Role-based security ), e a seguran ca de c odigo e chamada de seguran ca de acesso do c odigo (Code access security ). 2.2.1.1 SEGURANC A BASEADA EM FUNC OES A seguran ca baseada em fun c oes utiliza os conceitos de usu arios e fun c oes. Por exemplo, uma aplica c ao pode impor um valor limite para um caixa do banco processar uma

2.2 .NET Framework

24

transa c ao, e permitir que o gerente processe transa c oes de qualquer valor. A seguran ca baseada em fun c oes e implementada utilizando-se os objetos Principal e Identity (MEIER ario autenticado. O objeto et al., 2003). O objeto identity representa a identidade do usu principal representa o contexto de seguran ca da thread em execu c ao, e cont em um objeto identity e a deni c ao das fun c oes do usu ario. O .NET Framework exp oe um objeto chamado PrincipalPermission que permite especicar que uma classe/m etodo s o pode ser invocado por um usu ario e/ou por uma fun c ao espec cos. O quadro 2.1 demonstra um exemplo de uma classe que s o pode ser chamada por usu arios que fa cam parte da fun c ao Managers. [PrincipalPermission(SecurityAction.Demand, Role="Managers")] public sealed class OnlyManagersCanCallMe { }
Fonte: Meier et al. (2003). Quadro 2.1 Exemplo de uso de seguran ca baseada em fun c oes.

2.2.1.2 SEGURANC A DE ACESSO DO CODIGO Seguran ca de acesso do c odigo e um recurso do .NET Framework que gerencia o c odigo dependendo do n vel de conan ca no mesmo. O CLR come ca a executar o c odigo de uma assembly apenas se ele conar no c odigo o suciente para permitir sua execu c ao. Se o c odigo n ao for con avel o suciente para ser executado, ou se for executado mas tentar executar uma opera c ao para o qual n ao tem privil egios, uma exce c ao e gerada (ROBINSON et al., 2001). Segundo Meier et al. (2003), a seguran ca de acesso do c odigo consiste dos seguintes elementos: a) c odigo: todo c odigo gerenciado est a sujeito ` as pol ticas de seguran ca de acesso do c odigo. Quando uma assembly e carregada, recebe um conjunto de permiss oes que determinam que tipo de recursos pode acessar e quais opera c oes privilegiadas pode executar. O sistema de seguran ca usa evid encias para autenticar o c odigo e conceder permiss oes; b) evid encia: s ao as propriedades do c odigo utilizadas pelo CLR para conceder permiss oes. Evid encias relacionadas a localiza c ao incluem: (i) Uniform Resource Locator (URL) de origem; (ii) site de origem; (iii) diret orio da aplica c ao; (iv) zona de origem (computador local, intranet, internet). Evid encias relacionadas

2.2 .NET Framework

25

ao autor do c odigo incluem: (i) strong name (uma forma de assinar digitalmente as assemblies usando uma chave privada); (ii) certicado digital X.509 da organiza c ao que publicou o c odigo; (iii) valor hash da assembly ; c) permiss oes: representam os direitos do c odigo de acessar recursos protegidos e executar opera c oes privilegiadas. Por exemplo, o c odigo deve ter a permiss ao FileIOPermission para acessar o sistema de arquivos, e RegistryPermission para acessar o registro do sistema operacional. Uma listagem das permiss oes pr edenidas do .NET Framework pode ser encontrada no anexo A; d) pol ticas: as pol ticas de seguran ca de acesso do c odigo s ao conguradas pelos administradores e determinam as permiss oes concedidas ` as assemblies. Essas pol ticas podem ser estabelecidas em quatro n veis: corpora ca o, m aquina, usu ario e a application domain. As pol ticas de seguran ca s ao mantidas em arquivos de congura c ao em formato Extensible Markup Language (XML); e) grupos de c odigo: cada n vel de pol tica de seguran ca cont em uma cole c ao hier arquica de grupos de c odigo. Os grupos de c odigo t em uma condi c ao de membro, que especicam quais assemblies fazem parte do grupo, e um conjunto de permiss oes, que cont em as permiss oes que ser ao concedidas a todas as assemblies cuja evid encias combinem com a condi c ao de membro do grupo. A g. 2.3 apresenta uma vis ao simplicada da seguran ca de acesso do c odigo. Primeiramente a assembly e carregada. O CLR coleta evid encias da assembly e as avalia contra a pol tica de seguran ca. A sa da dessa opera c ao e um ou mais conjuntos de permiss oes que denem as permiss oes concedidas para a assembly. Durante a execu c ao, o c odigo que acessa recursos ou realiza opera c oes privilegiadas faz uma demanda de permiss oes. Todas as classes do .NET Framework que acessam recursos protegidos exigem permiss oes adequadas. Por exemplo, a classe FileStream exige a permiss ao FileIOPermission, e a classe Registry exige a permiss ao RegistryPermission (MEIER et al., 2003). As pol ticas de seguran ca s ao avaliadas em cada n vel (corpora c ao, m aquina, usu ario, application domain ), e o conjunto de permiss oes que cada n vel concedeu e combinado usando uma opera c ao de intersec c ao. Uma intersec c ao garante, por exemplo, que um usu ario n ao possa conceder permiss oes adicionais que n ao foram concedidas pelo administrador da corpora c ao. Conforme Watkins e Lange (2002), cada n vel das pol ticas de seguran ca tem sua pr opria arvore de grupos de c odigo, que expressam as congura c oes de cada n vel. O conjunto de grupos de c odigo e organizado na forma de uma arvore. Sempre que a condi c ao

2.2 .NET Framework

26

de membro em um nodo da arvore for satisfeito, o conjunto de permiss oes daquele nodo e concedido ` a assembly e os nodos lhos s ao examinados. Caso a condi c ao de membro n ao seja satisfeita, o conjunto de permiss oes n ao e concedido e os nodos lhos n ao s ao examinados.

Fonte: Meier et al. (2003). Figura 2.3 Vis ao simplicada da seguran ca de acesso do c odigo.

A g. 2.4 ilustra os grupos de c odigo de um n vel da pol tica de seguran ca. Uma assembly com origem da URL www.monash.edu.au seria avaliada da seguinte maneira: O nodo ra z tem uma condi c ao de membro All code, que e satisfeita por qualquer c odigo. O conjunto de permiss oes (PSet, na gura) associado ao nodo, Nothingnesse caso, e concedido ` a assembly e a avalia c ao continua com os nodos lhos. O pr oximo nodo examinado exige que o c odigo seja carregado do computador local. Como essa condi c ao n ao e satisfeita, o conjunto de permiss oes desse nodo n ao e concedido, e qualquer nodo lho e ignorado. O nodo seguinte tem uma condi c ao de membro que exige que o c odigo seja carregado da Internet. Como essa condi c ao e verdadeira, o c odigo recebe o conjunto de permiss oes Internete a verica c ao prossegue com os nodos lhos. O c odigo n ao teve origem

2.2 .NET Framework

27

da URL www.microsoft.com, ent ao o conjundo de permiss oes MSPSetn ao e concedido. O conjunto de permiss oes MonashPSet e concedido pelo fato do c odigo ter origem da URL www.monash.edu.au. A condi c ao do nodo lho n ao e satisfeita, pois o c odigo n ao tem um strong name de m-Commerce. O u ltimo nodo a ser avaliado requer que o c odigo seja origin ario da intranet. Essa condi c ao n ao e satisfeira e as permiss oes n ao s ao concedidas. Todos os conjuntos de permiss oes concedidos dentro do mesmo n vel da pol tica de seguran ca s ao combinados usando uma opera c ao de uni ao. Ao nal do processo, as permiss oes da assembly s ao o resultado de permisso es {N othing, Internet, M onashP Set}.

Fonte: Watkins e Lange (2002). Figura 2.4 Grupos de c odigo de um n vel da pol tica de seguran ca.

2.2.2 ASP.NET O ASP.NET e uma plataforma de programa c ao constru da sobre o .NET Framework e utilizada para criar aplica c oes para web. O ASP.NET mant em o mesmo modelo de desenvolvimento do Active Server Pages (ASP) mas cont em muitas inova c oes que permitem f acil separa c ao da funcionalidade principal de uma aplica c ao e de sua apresenta c ao (MICROSOFT CORPORATION, 2002a; REILLY, 2002). Ao mesmo tempo que o ASP e poderoso e simples de usar, sua arquitetura apresenta alguns problemas, conforme notado por Butler e Caudill (2002):

2.2 .NET Framework

28

a) o c odigo ASP ca complicado muito facilmente, devido ` a mistura de c odigos de servidor e de cliente, e a forma desestruturada de desenvolver um programa; b) o ASP n ao apresenta um real modelo de componentes, o que exige a necessidade de se escrever c odigo para tudo que se deseja fazer; c) o c odigo do programa ca misturado com o c odigo de apresenta c ao, o que gera problemas quando programadores e designers trabalham juntos. Tamb em e dif cil suportar v arios tipos de clientes e internacionaliza c ao de aplica co es; d) a combina c ao ASP e Internet Information Services (IIS) n ao e sempre a plataforma mais con avel. A toler ancia a falhas do ASP e relativamente baixa e um programa mal escrito e ineciente pode facilmente prejudicar o desempenho de todo o servidor; e) colocar em produ c ao aplica c oes ASP que utilizam componentes Component Object Model (COM) e dif cil, visto que os componentes COM precisam ser registrados e s ao bloqueados pelo sistema operacional quando em uso. Gerenciar aplica c oes, especialmente aquelas que utilizam v arios servidores, tem se mostrado um grade desao. Mesmo que o ASP.NET apresente um modelo de desenvolvimento similar ao do uma nova plataforma que cont ASP, n ao constitui apenas uma nova vers ao. E em melhorias nos aspectos de seguran ca, escalabilidade e estabilidade (MICROSOFT CORPORATION, 2004b). Entre os v arios benef cios do ASP.NET e de sua nova arquitetura, Butler e Caudill (2002), Reilly (2002), Parihar et al. (2002) destacam: a) integra c ao com o .NET Framework ; b) o uso do CLR em tempo de execu c ao prov e uma s erie de servi cos para as aplica c oes; c) independ encia de linguagem, inclusive uso de v arias linguagens em uma mesma aplica c ao; d) c odigo compilado, oposto ao ASP que e interpretado.; e) melhor desempenho, devido ao c odigo compilado. Como todas aplica c oes .NET, o c odigo-fonte e compilado em c odigo intermedi ario, e a compila c ao para c odigo nativo ou bin ario d a-se no momento da execu c ao; f) um modelo de objetos rico para os desenvolvedores, simplicando o desenvolvimento e diminuindo a quantidade de c odigo necess ario nas p aginas; g) uso extensivo de componentes. Al em de v arios componentes embutidos na plataforma, e poss vel criar componentes personalizados, que podem ser substitu dos

2.2 .NET Framework

29

em tempo de execu c ao; h) possibilidade de utiliza c ao de toda a biblioteca de classes do .NET Framework em qualquer aplica c ao; i) a distribui c ao de aplica c oes simplicada, bastando copiar os programas e componentes para o local desejado; n ao h a necessidade de instala c ao ou registro de componentes; j) as congura c oes da aplica c ao cam todas em um arquivo XML, que pode ser facilmente estendido e modicado. Um dos componentes fundamentais do ASP.NET e o Web Form. Um Web Form e a p agina web que os usu arios visualizam no navegador, e e uma p agina din amica que pode acessar recursos do servidor (arquivos, banco de dados, etc). Para criar essas p aginas s ao utilizados controles do ASP.NET para criar os elementos de interface mais comuns. A possibilidade de se utilizar componentes embutidos na plataforma, ou de criar componentes personalizados simplica a codica c ao das p aginas (MICROSOFT CORPORATION, 2004b). Segundo Anderson et al. (2001, p. 150), um Web Form n ao difere muito de uma p agina web tradicional e tamb em e criado como resultado de uma requisi c ao Hypertext Transport Protocol (HTTP). O servidor cria a p agina, envia os dados para o cliente, fecha a conex ao HTTP e descarta qualquer informa c ao sobre a requisi c ao. Quando um Web Form e requisitado do servidor os componentes que formam aquela p agina s ao compilados em uma unidade (ANDERSON et al., 2001, p. 142). Os componentes podem ser: a) o arquivo .aspx sendo requisitado; b) classes contendo c odigo para aquela p agina; c) qualquer controle do usu ario utilizado pela p agina. No ASP.NET uma p agina e realmente um objeto execut avel que produz sa da Hypertext Markup Language (HTML), e tamb em um objeto derivado da classe pr e-denida Page, que, como qualquer outro objeto, tem uma s erie de est agios de processamento (inicializa c ao, processamento, limpeza). O ASP.NET e baseado em eventos. O modelo de eventos prim ario dos Web Forms e gerar eventos no cliente e process a-los no servidor. O processo gera uma nova requisi c ao HTTP para a mesma p agina para que a execu c ao ocorra no servidor. Esse processo e conhecido como viagem de ida e volta ao servidor (Server round-trip ). Como o mecanismo de comunica c ao HTTP e sem informa c ao de estado (Stateless ),

2.2 .NET Framework

30

o servidor n ao guarda nenhuma informa c ao sobre as requisi c oes anteriores do cliente. Isso signica que os valores dos campos de formul arios e o estado dos objetos instanciados pela p agina s ao perdidos. Para lidar com essa natureza, a arquitetura dos Web Forms utiliza um conceito chamado ViewState. O ViewState cont em o estado de todos os controles na p agina, e e mantido durante os server round-trips. 2.2.3 SERVIC OS DO WINDOWS Os servi cos do Windows (Windows Services ) s ao aplica c oes que executam como processos em segundo plano e podem ser iniciadas automaticamente quando o sistema operacional inicia. Estas aplica c oes s ao ideais para tarefas que n ao requerem intera c ao com em disso, podem ser criadas utilizando o usu ario (MICROSOFT CORPORATION, 2003). Al qualquer linguagem .NET, visto que a biblioteca de classe do .NET Framework cont em classes que possibilitam criar, instalar, implementar e gerenciar servi cos do Windows. Um servi co do Windows pode ser instalado em qualquer computador rodando Windows Server 2003, Windows XP, Windows 2000 ou Windows NT, e executa continuamente, at e que um usu ario o pare, ou at e que o computador seja desligado. Tarefas comuns realizadas por servi cos do Windows s ao o gerenciamento de conex oes de redes e monitoramento do acesso e utiliza c ao de recursos. Robinson et al. (2001) explica que tr es tipos de programas s ao necess arios para operar um servi co: o programa do servi co propriamente dito, um programa para controle do servi co e um programa de congura c ao do servi co. Al em desses programas, o Service Control Manager (SCM) exerce uma fun c ao muito importante. O SCM e uma parte do sistema operacional que se comunica diretamente com os servi cos e envia requisi c oes para que os servi cos sejam iniciados, parados, suspensos e reiniciados. O programa do servi co implementa a funcionalidade do servi co, e cont em tr es partes: uma fun c ao main (o ponto de in cio do programa), uma fun c ao service-main e um handler. A fun c ao main deve registrar junto ao SCM o ponto de entrada da fun c ao service-main de cada servi co existente no programa, de forma que o SCM possa chamar essa fun c ao quando o servi co deve ser iniciado. A fun c ao service-main implementa a funcionalidade do servi co e tem a responsabilidade de registrar um handler junto ao SCM. Este handler, por sua vez, e respons avel por tratar eventos gerados pelo SCM. Eventos gerados pelo SCM incluem parar, suspender, reiniciar o servi co ou executar alguma a c ao personalizada.

2.3 Web standards

31

O programa de controle de servi co permite que o estado de um servi co seja conodigos de controle aos servi cos, trolado. Este programa interage com o SCM para enviar c cujo handler deve reagir aos eventos. Tamb em pode-se descobrir o estado atual de cada servi co. Um servi co n ao pode simplesmente ser copiado para um servidor, pois precisam de congura c oes especiais no registro do sistema operacional. Esse e o prop osito do programa de congura c ao do servi co. Um servi co pode ser congurado para iniciar de forma autom atica, manual, ou n ao iniciar. Tamb em deve ser congurado de forma a ser executado sob o contexto de seguran ca de uma conta de usu ario, e o sistema operacional deve ser informado de quais outros servi cos cada servi co depende. Al em dessas congura c oes, um programa de congura c ao de servi co pode ser usado para mudar os par ametros de congura c ao ou para remover o servi co. O .NET Framework prov e um namespace chamado System.ServiceProcess, que cont em classes necess arias para implementar as tr es partes de um servi co: a) para implementar um programa de servi co extende-se, por meio de heran ca, a classe ServiceBase ; b) usa-se a classe ServiceController para implementar um programa de controle de servi co; c) as classes ServiceProcessInstaller e ServiceInstaller s ao usadas para instalar e congurar os servi cos. O diagrama de seq u encia da g. 2.5 ilustra a intera c ao entre o SCM, o servi co implementado, a classe ServiceBase e os m etodos nativos da Application Programming Interfaces (API) do sistema operacional quando o servi co e iniciado e nalizado. 2.3 WEB STANDARDS Web standards e um conjunto de especica c oes desenvolvidas pelo World Wide Web Consortium (W3C) para resolver v arios dos problemas relacionados ao desenvolvimento para Internet. Zeldman (2003) cita, entre outros: (i) custos elevados de desenvolvimento e atualiza c ao de sites; (ii) custos elevados com hospedagem, devido ` a enorme quantidade de c odigo nas p aginas; (iii) incompatibilidade entre diferentes vers oes do mesmo navegador; (iv) incompatibilidade entre navegadores diferentes. A padroniza c ao e uma quest ao importante em qualquer area. Os navegadores da web nalmente est ao suportando padr oes, ent ao faz sentido utiliz a-los corretamente.

2.3 Web standards

32

Fonte: Robinson et al. (2001, p. 1033). Figura 2.5 Intera c ao dos componentes durante uma requisi c ao de in cio e naliza c ao de um servi co.

Conforme Zeldman (2003, p. 536), os web standards resolvem estes problemas dividindo qualquer p agina da web em tr es componentes: a) estrutura: a estrutura de uma p agina e representada por uma linguagem de marca c ao que cont em texto formatado de acordo com seu signicado estrutural. As linguagens de marca c ao utilizadas com web standards s ao Extensible Hypertext Markup Language (XHTML) e XML; b) apresenta c ao: linguagens de apresenta c ao (Cascading Style Sheets (CSS) 1 e 2) formatam a p agina, controlando a tipograa, posicionamento dos elementos, cores, etc; c) comportamento: Um modelo de objetos padr ao (Document Object Model (DOM)) e uma vers ao padronizada de JavaScript (ECMAScript ) permitem que sejam criados comportamentos e efeitos que funcionam em diferentes plataformas e navegadores.

2.4 Trabalhos correlatos

33

Alguns benef cios do uso de web standards, segundo Zeldman (2003, p. 423) incluem: redu c ao de custos; suporte a m ultiplos navegadores e plataformas; suporte a dispositivos n ao tradicionais, como telefones celulares, computadores de m ao, leitores de escrita Braille e leitores de tela; separa c ao do estilo da estrutura e comportamento; uso de marca c ao baseada em XML; garantia de funcionalidade em navegadores e dispositivos que ainda n ao foram criados ou mesmo imaginados. 2.4 TRABALHOS CORRELATOS A Universidade de Valladolid (UNIVERSIDAD DE VALLADOLID, [2004?]) e a Universidade do Estado de Ural (URAL STATE UNIVERSITY, [2004?]) apresentam um sistema de juiz on-line para corre c ao de problemas em concursos de programa c ao. Ambos os sistemas rodam em plataforma Linux e aceitam programas escritos em C, C++, Java e Pascal, al em de apresentarem um vasto conjunto de problemas que podem ser resolvidos e submetidos para corre c ao. Os usu arios podem submeter os programas por e-mail ou pelo site. e sistema desenvolvido em linguagem PHP: Hypertext PreO BOCA (SILVA, 2003) processor (PHP) pela PUC-SP e utilizado para controlar uma competi c ao de programa c ao. O software em si n ao faz corre c ao dos programas, mas serve como uma interface para as equipes enviarem seus programas, receberem as respostas das corre c oes e tamb em se comunicarem com os ju zes. O Bees (STACK; EIDE; LEPREAU, 2003) e um ambiente de execu c ao seguro e ex vel para executar c odigo m ovel escrito em Java. C odigos m oveis possibilitam que usu arios executem programas arbitr arios em m aquinas remotas, mas normalmente n ao podem fazer algo muito u til sem um rico ambiente de execu c ao, e nenhum administrador instalaria tal ambiente se n ao houver um completo controle sobre os recursos consumidos e acessados pelo c odigo remoto. O Bees trabalha com um mecanismo de autentica c ao e autoriza c ao ex veis que permite que os usu arios denam o processamento e os protocolos usados para comunicar com m aquinas remotas, ao mesmo tempo em que permite que os administradores especiquem as formas de comunica c ao e os recursos que podem ser utilizados em tais m aquinas.

34

DESENVOLVIMENTO DO SISTEMA
Este cap tulo detalha inicialmente os requisitos do sistema desenvolvido (se c ao 3.1),

a especica c ao do sistema (se c ao 3.2), a implementa c ao, ilustra o sistema em funcionamento (se c ao 3.3) e apresenta os resultados obtidos (se c ao 3.4). 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO A tab. 3.1 apresenta os requisitos funcionais do sistema desenvolvido. Os requisitos n ao funcionais do sistema s ao apresentados na tab. 3.2.
Tabela 3.1 Requisitos funcionais do sistema

No

Requisito

RF01 O sistema web deve permitir cadastro e altera c ao de dados dos usu arios; RF02 O sistema web deve manter um banco de dados com os problemas que o sistema pode resolver, organizados por categoria; RF03 Os usu arios podem enviar o c odigo-fonte com a solu c ao de qualquer problema apresentado para que seja corrigido; RF04 O sistema web deve mostrar aos usu arios relat orios com informa c oes sobre os programas submetidos para corre c ao, com informa c oes sobre o resultado da corre c ao (solu c ao correta, erro de compila c ao, solu c ao incorreta); RF05 Os usu arios podem receber por e-mail o resultado dos problemas submetidos para corre c ao; RF06 O sistema web deve gerar um ranking de usu arios de acordo com o n umero de problemas corretamente resolvidos; RF07 O sistema web deve gerar relat orios estat sticos com a quantidade de solu c oes corretas e incorretas apresentadas para cada problema cadastrado; RF08 O administrador do sistema pode cadastrar, alterar e excluir categorias de problemas dispon veis para corre c ao autom atica; RF09 O administrador do sistema pode cadastrar, alterar e excluir os problemas dispon veis para corre c ao autom atica; RF10 O administrador pode criar competi c oes, especicando um conjunto de problemas e um per odo de tempo para cada competi c ao; RF11 Os usu arios e o administrador do sistema podem efetuar logon no sistema informando credenciais (login e senha).

3.1 Requisitos principais do problema a ser trabalhado

35

Tabela 3.2 Requisitos n ao funcionais do sistema

No

Requisito

RNF01 Os problemas submetidos para corre c ao devem ter no c odigo-fonte a identica c ao do usu ario, do problema e opcionalmente da competi c ao; RNF02 O sistema de corre c ao deve prover um ambiente seguro, garantindo que os programas enviados pelos usu arios n ao executar ao fun c oes indesejadas ou que possam comprometer a seguran ca ou estabilidade do sistema; RNF03 Os programas dos usu arios t em um limite de uso de tempo de processador e mem oria, espec cos para cada problema e denidos pelo administrador; RNF04 O sistema deve compilar os programas submetidos usando o compilador de C# dispon vel com o .NET Framework SDK; RNF05 O sistema dever a executar em Windows 2000 Server ou Windows Server 2003, com .NET Framework 1.1 ou 2.0; RNF06 O u nico custo de software aceit avel para execu c ao do sistema e a licen ca do sistema operacional; RNF07 O sistema dever a ser extens vel, permitido adi c ao de m odulos para compila c ao de c odigos-fonte escritos em outra linguagem; RNF08 O sistema web dever a usar web standards, e ser compat vel com qualquer navegador moderno; RNF09 O sistema web dever a ter uma se c ao de ajuda explicando como a avalia c ao autom atica funciona, a quais restri c oes os programas estar ao sujeitos e algumas instru c oes de como os programas devem ser escritos para poderem ser avaliados por este sistema; RNF10 O sistema de corre c ao n ao precisa estar executando para o usu ario poder enviar um programa; nesse caso a corre c ao ser a postergada at e o servi co ser iniciado; RNF11 Todo o acesso ao banco de dados deve ser feito atrav es de procedimentos armazenados; RNF12 As conex oes ao banco de dados devem utilizar seguran ca integrada do Windows

3.2 Especica ca o

36

3.1.1 DIAGRAMAS DE CASOS DE USO A g. 3.1 apresenta um modelo do sistema web atrav es de um diagrama de casos de uso. A especica c ao dos cen arios encontra-se no ap endice A.

Figura 3.1 Diagrama de casos de uso do sistema web.

A g. 3.2 apresenta um modelo do sistema de corre c ao atrav es de um diagrama de casos de uso. A especica c ao dos cen arios encontra-se no ap endice B. 3.2 ESPECIFICAC AO A especica c ao do sistema foi feita utilizando-se a nota c ao Unied Modeling Language (UML). Segundo Object Management Group (2004, tradu c ao nossa), UML ea forma com que o mundo modela n ao apenas a estrutura, o comportamento e a arquitetura das aplica c oes, mas tamb em os processos de neg ocios e estruturas de dados. Para modelagem da estrutura de dados foi utilizado o Modelo Entidade-Relacionamento (MER).

3.2 Especica ca o

37

Figura 3.2 Diagrama de casos de uso do sistema de corre c ao.

A ferramenta utilizada para especica c ao e modelagem de dados foi o Sybase PowerDesigner. O PowerDesigner combina modelagem de aplica c oes atrav es de UML, t ecnicas de modelagem de processos de neg ocio e t ecnicas tradicionais de modelagem de banco de dados. Mais informa c oes podem ser encontradas em (SYBASE INC., 2004).

Figura 3.3 Componentes do sistema.

O sistema est a dividido em v arios componentes, conforme ilustrado na g. 3.3. A arquitetura foi inspirada em um padr ao de projeto (Design Pattern ) conhecido como Model-View-Controler (MVC). Esse padr ao adiciona uma camada intermedi aria que separa a l ogica que controla o estado e o comportamento da interface com o usu ario da

3.2 Especica ca o

38

l ogica que controla como os dados s ao adquiridos e processados. O componente Model c ao 3.2.2) implementam a parte Model desse (se c ao 3.2.1) e o componente ReportModel (se padr ao. A parte View e implementada pelo componente Web (se c ao 3.2.6) e o Controller e implementado pelos componentes BLL (se c ao 3.2.5) e JudgeServer (se c ao 3.2.7). Al em desses, os componentes DALFactory (se c ao 3.2.4) e IDAL (se c ao 3.2.3) representam uma camada de persist encia. As sub-se c oes seguintes apresentam em maiores detalhes cada componente. 3.2.1 COMPONENTE MODEL O componente Model cont em as entidades de neg ocio da aplica c ao. As entidades de neg ocio armazenam dados utilizados para representar entidades de neg ocio do mundo real, como produtos ou pedidos. Existem v arias formas de representar essas entidades em uma aplica c ao por exemplo, XML, DataSets ou classes de orienta c ao a objetos personalizadas (CROCKER; OLSEN; JEZIERSKI, 2002). Neste trabalho as entidades de neg ocio foram implementadas na forma de classes personalizadas. A g. 3.4 apresenta o diagrama de classes do componente Model. No diagrama est ao representadas as classes e seus relacionamentos, juntamente com os atributos de cada classe. Os m etodos construtores e as propriedades get e set para os atributos n ao est ao representados. A classe CategoryInfo representa uma categoria de problemas dispon vel no sistema. Os problemas s ao representados pela classe ProblemInfo. Dessa classe, os atributos maxUserCPU, maxKernelCPU e maxMemory representam, respectivamente, a quantidade m axima de tempo de processador em modo de usu ario, em modo privilegiado e a quantidade m axima de mem oria que um programa pode consumir. Cada problema agrega um conjunto de entrada e sa da (representados pela classe IOSetInfo ) de exemplo, e pelo menos um conjunto de avalia c ao. Os dados de um usu ario s ao representados pela classe UserInfo. O atributo userSubmitID, no formato de um Globally Unique Identier (GUID), e utilizado para identicar o usu ario quando um programa e submetido. Um exemplo de GUID pode ser encontrado no quadro 3.8. A classe ContestInfo representa as competi c oes, que agregam v arios usu arios e v arios problemas. Cada programa enviado para corre c ao e representado pela classe SubmissionInfo. Uma submiss ao est a relacionada a um usu ario, a um problema e opcionalmente a uma competi c ao. Uma linguagem de programa c ao (classe LanguageInfo ) tamb em est a associada a uma submiss ao. O atributo assembly da classe LanguageInfo indica a assembly em que o m odulo da linguagem de

3.2 Especica ca o

39

programa c ao est a localizado, e o atributo type representa o nome completo da classe.

Figura 3.4 Diagrama de classes do componente Model.

3.2.2 COMPONENTE REPORTMODEL O componente ReportModel e uma extens ao do componente Model e cont em classes utilizadas na gera c ao de relat orios e estat sticas. A g. 3.5 ilustra o diagrama de classes do componente ReportModel. Cada classe desse componente agrega uma entidade de neg ocio e cont em algumas informa c oes estat sticas. A classe StatsReportInfo agrega uma inst ancia da classe ProblemInfo e cont em informa c oes de quantas solu c oes foram apresentadas para o problema, quantas est ao corretas, quantas s ao inv alidas e quantos usu arios resolveram o problema. A classe AuthorRankInfo cont em informa c oes de quantas solu c oes um usu ario apresentou para corre c ao, quantas est ao corretas, quantas s ao inv alidas e quantos problemas esse usu ario resolveu. A classe CategoryListInfo agrega

3.2 Especica ca o

40

uma categoria e guarda informa c oes do n umero de problemas dessa categoria, e quantos desses problemas foram resolvidos pelo usu ario autenticado no momento. De forma similar, a classe ProblemListInfo agrega um problema, e cont em dados de quantos usu arios resolveram o problema, e se o usu ario autenticado conseguiu resolv e-lo.

Figura 3.5 Diagrama de classes do componente ReportModel.

Optou-se por separar essas classes do componente Model pelo fato de estas n ao constituirem realmente entidades de neg ocio e apresentarem informa c oes redundantes. A raz ao da cria c ao dessas classes para relat orio e o desempenho. Dessa forma utiliza-se os recursos de sumariza c ao de dados do Sistema Gerenciador de Banco de Dados (SGBD) e evita-se a cria c ao de v arias inst ancias de objetos apenas para sumarizar dados. 3.2.3 COMPONENTE IDAL O componente IDAL cont em as interfaces para os componentes de l ogica de acesso a ocio dados1 . Componentes DAL recuparam dados e gravam os dados das entidades de neg na base de dados (CROCKER; OLSEN; JEZIERSKI, 2002). c oes que cada classe de um As interfaces2 do componente IDAL denem as opera
Data Access Logic (DAL) Uma interface dene um contrato. Uma classe ou estrutura que implementa uma interface deve aderir ao seu contrato (MICROSOFT CORPORATION, 2004b).
2 1

3.2 Especica ca o

41

componente DAL deve ter. Dessa forma podem-se implementar diferentes componentes cos para acesso ` a diferentes tipos de fontes de dados. Fontes de dados incluem SGBD, servi de diret orio, arquivos texto, arquivos XML, arquivos de dados propriet arios, entre outros.

Figura 3.6 Diagrama de classes do componente IDAL.

A g. 3.6 representa o diagrama de classes desse componente. Nessa gura, a interface IUser dene as opera c oes de persist encia relativas a usu arios. A opera c ao ListUsers() retorna uma lista de objetos UserInfo. A opera c ao LogOn() retorna o c odigo de identica c ao de um usu ario se as credenciais fornecidas (login e senha) forem v alidas. A opera c ao GetUser() retorna um objeto UserInfo a partir do c odigo de identica c ao do usu ario, enquanto a opera c ao GetUserBySubmitID() retorna um objeto UserInfo a partir do identicador de submiss ao de um usu ario (no formato de um GUID). As opera c oes Insert(), Update() e Delete() recebem como par ametro um objeto UserInfo e respectivamente, inserem, atualizam ou excluem os dados da fonte de dados. De forma similar, as interfaces IProblem, ICountry, ISubmission, ICategory, IContest, IReports e ILanguage denem as opera c oes de persist encia relativas a problemas, pa ses, submiss oes, categorias,

3.2 Especica ca o

42

competi c oes, relat orios e linguagens de programa c ao respectivamente. Neste trabalho implementou-se um componente DAL espec co para acesso aos SGBD Microsoft SQL Server 2000 e Microsoft MSDE 2.0. A g. 3.7 ilustra o modelo conceitual do banco de dados para esse sistema, gerado com base nas classes da g. 3.4.

Figura 3.7 Modelo conceitual do banco de dados.

3.2.4 COMPONENTE DALFACTORY O componente DALFactory implementa uma varia c ao do padr ao de projeto Abstract Factory para cria c ao do componente DAL a ser utilizado na aplica c ao.

3.2 Especica ca o

43

Segundo Gamma et al. (1996), o padr ao Abstract Factory prov e uma interface para criar fam lias de objetos relacionados ou dependentes sem especicar suas classes concretas. Como a Factory encapsula a responsabilidade e o processo de criar objetos concretos, isola os clientes das classes de implementa c ao. Clientes manipulam inst ancias atrav es das interfaces abstratas. Nesse contexto, as interfaces do componente IDAL s ao os produtos abstratos e as classs do componente DAL para MSDE correspondem ao produtos concretos. O componenente DALFactory implementa as fun c oes da f abrica abstrata e da f abrica concreta. Conforme ilustra diagrama de classes (g. 3.8), esse componente cont em apenas uma classe, com m etodos est aticos para instanciar cada uma das classes de acesso a dados denidas pelas interfaces do componente IDAL.

Figura 3.8 Diagrama de classes do componente DALFactory.

3.2.5 COMPONENTE BLL O componente BLL implementa as regras de neg ocio mais comuns do sistema, usadas pelos componentes Web e JudgeServer. A g. 3.9 ilustra o diagrama de classes desse componente. Nenhuma parte da aplica c ao acessa a camada de dados diretamente. Elas o fazem utilizando-se deste componente, o que garante uma manuten c ao simplicada das regras de neg ocio. A classe Validator cont em regras de valida c ao de dados. A classe User cont em opera c oes que implementam as regras associadas a opera co es com usu arios. A opera c ao ValidateCommom() implementa regras para valida c ao de dados que s ao comuns ` as opera c oes Insert() e Update(). Outras classes tamb em implementam uma opera c ao ValidateCommom() que t em prop ositos semelhantes em suas respectivas classes. A classe

3.2 Especica ca o

44

Figura 3.9 Diagrama de classes do componente BLL.

Problem implementa ainda uma opera c ao ValidateIOSet() para valida c ao dos conjuntos de entrada e sa da associados ao problema. A classe Submission implementa opera c oes relativas aos programas submetidos para corre c ao. As opera c oes UpdateStatus(), UpdateIdentications() e UpdateResouceUsage() s ao utilizadas para atualizar o status de uma submiss ao, atualizar as identica c oes (usu ario, problema e competi c ao) e atualizar os recursos consumidos pelo programa (tempo de processador e quantidade de mem oria), respectivamente. A opera c ao JudgeStatus() retorna o status atual do sistema de corre c ao (parado, executando), e a opera c ao SignalJudge() e utilizada quando o sistema web faz uma submiss ao para sinalizar ao sistema que corre c ao que um novo programa deve ser corrigido. As classes Contest, Category, Reports, Language e Country implementam as regras para opera c oes relacionadas a competi c oes, categorias, relat orios, linguagens de

3.2 Especica ca o

45

programa c ao e pa ses, nessa ordem. N ao est ao inclu das nesse componente as regras muito espec cas do sistema de corre c ao. Essas regras foram inclu das na modelagem do sistema de corre c ao, apresentada na se c ao 3.2.7. 3.2.6 COMPONENTE WEB O componente Web cont em a l ogica de apresenta c ao do sistema web. A g. 3.10 apresenta um diagrama com as possibilidades de navega c ao desse sistema.

Figura 3.10 Diagrama de navega c ao do sistema web.

O diagrama de seq u encia da g. 3.11 ilustra a intera c ao dos componentes durante o envio de uma solu c ao. Quando o usu ario solicita a p agina, o sistema web recupera a lista de linguagens de programa c ao dispon veis atrav es do m etodo ListLanguages() da classe Language do componente BLL. A p agina solicita para a classe BLL.Submission o status do

3.2 Especica ca o

46

Figura 3.11 Intera c ao dos componentes com o sistema web durante o envio de uma solu c ao.

3.2 Especica ca o

47

sistema de corre c ao. Em seguida a p agina e exibida para que o usu ario preencha os dados. Quando o usu ario preenche os dados, e criada uma inst ancia da classe SubmissionInfo do componente Model, passada para o m etodo Submit() da classe Submission. Esse m etodo invoca no mesmo objeto o m etodo VerifySourcesPath() para vericar se o arquivo de congura c ao da aplica c oes indica em que diret orio os programas fontes enviados devem feita uma solicita ser salvos. E c ao ` a classe Factory do componente DALFactory para a cria c ao de uma inst ancia do objeto Submission do componente de acesso a dados, atrav es do m etodo CreateSubmission(). Esse m etodo verica no arquivo de congura c ao qual componente de acesso a dados deve ser utilizado (VerifyAssemblyPath() ), chama o m etodo CreateInstance(), que ir a carregar a assembly (LoadAssembly() ) e instanciar a classe. A classe Submission do componente BLL invoca ent ao o m etodo Submit() do componente de acesso a dados para persistir as informa c oes da submiss ao. Por m, e invocado o m etodo SignalJudge() para sinalizar ao sistema de corre c ao a exist encia de um novo programa a ser corrigido. 3.2.7 COMPONENTE JUDGESERVER O componente JudgeServer implementa a funcionalidade do sistema de corre c ao automatizado. A g. 3.12 apresenta o diagrama de classes desse componente. A classe Judge cont em alguns m etodos p ublicos que ser ao invocados pelo servi co do Windows. O m etodo Start(), Stop() e JudgeRequest() s ao invocados, respectivamente, quando o servi co do Windows solicita que o sistema de corre c ao seja iniciado, nalizado e quando h a uma nova submiss ao para ser avaliada. O m etodo MailResults() envia um email com o resultado da corre c ao do programa para o usu ario. Os demais m etodos s ao explicados juntamente com o diagrama de seq u encia da g. 3.13. O atributo judgingThread e uma refer encia para a thread principal do sistema. O atributo event e usado para sincroniza c ao entre threads e o atributo exit e uma ag que indica quando o sistema est a em processo de naliza c ao. Os atributos p, processOut e processErr representam, respectivamente, uma refer encia a um novo processo criado para executar o programa do usu ario, a sa da padr ao desse processo e a sa da de erros desse processo. Os atributos listener e portNumber s ao usados para abrir uma porta TCP no sistema de corre c ao. e um contador de quantos programas est ao prontos para ser O atributo requestsPending avaliados. A interface ILanguageModule dene um contrato para os m odulos de linguagens de programa c ao. Essa interface dene m etodos que os m odulos de linguagem de pro-

3.2 Especica ca o

48

grama c ao devem implementar para compilar o programa, vericar a seguran ca3 , ler as identica c oes4 do programa e denir como o programa compilado deve ser carregado. A classe DotNetLanguageModule e uma classe abstrata que implementa as opera c oes SafeVerication(), GetIdentications() e CreateProcessStartInfo(), que s ao comuns a todos os programas compilados na plataforma .NET. Isso simplica a implementa c ao de m odulos para compila c ao de outras linguagens .NET, pois e preciso apenas sobrescrever o m edoto Compile(). No caso da implementa c ao de uma linguagem independente do .NET Framework deve-se implementar todas as opera c oes da interface. A classe CSharpLanguageModule implementa o m odulo para compila c ao em linguagem C#.

Figura 3.12 Diagrama de classes do componente JudgeServer.

A intera c ao dos componentes durante o processo de avalia c ao de uma submiss ao e exibida no diagrama de seq u encia da g. 3.13. O m etodo WaitForSubmissions() da classe Judge implementa o loop principal do sistema. Quando o sistema web notica o sistema de corre c ao da exist encia de uma nova submiss ao, o m etodo JudgeSubmission() e
3 4

Apenas a seguran ca que n ao pode ser vericada em tempo de execu c ao. Identica c ao do usu ario, do programa e opcionalmente da competi c ao.

3.2 Especica ca o

49

Figura 3.13 Intera c ao dos componentes do sistema de corre c ao durante a corre c ao de uma solu c ao.

3.3 Implementa ca o

50

criada uma inst invocado para iniciar o processo de corre c ao. E ancia do m odulo de linguagem de programa c ao espec co para essa submiss ao. No diagrama, foi utilizado o m odulo para C#.NET. Ao m odulo da linguagem e solicitado que compile o programa, recupere as identica c oes se existirem (identica c ao do usu ario, competi c ao e do problema), verique se o programa usa alguma classe ou fun c ao potencialmente perigosa e que crie um objeto ProcessStartInfo. O objeto ProcessStartInfo cont em as informa c oes de como um processo deve ser iniciado. Em seguida, a classe Judge invoca o m etodo StartMonitorProcess(), que vai iniciar um novo processo para execu c ao do programa do usu ario e monitorar sua execu c ao. O m etodo WrapperListener() abre uma porta TCP que ca aguardando uma sinaliza c ao. O programa do usu ario e carregado para execu c ao dentro de um Wrapper (programa que empacotaoutro programa). Esse Wrapper vai criar um novo Application Domain e carregar o programa do usu ario para executar dentro dele. Quando o programa do usu ario naliza, a classe Judge recebe uma sinaliza c ao atrav es da porta TCP. O sistema de corre c ao vai ent ao ler a sa da do programa (ReadOutput() ), vericar a sa da de erros (ReadError() ), obter a quantidade de recursos utilizados (GetPerfData() ), vericar se o programa n ao excedeu a quantidade m axima de tempo de processador e mem oria permitidos (MaxCPUExceeded() e MaxMemoryExceeded() ), e vericar se a resposta gerada e correta (VerifyAnswer() ). 3.3 IMPLEMENTAC AO Esta se c ao apresenta detalhes sobre a implementa c ao do sistema proposto. Suas subse c oes apresentam as ferramentas utilizadas para o desenvolvimento (se c ao 3.3.1), o banco de dados (se c ao 3.3.2), os componentes (se c ao 3.3.3), o sistema web (se c ao 3.3.4), o sistema de corre c ao (se c ao 3.3.5) e dois estudos de caso do sistema em funcionamento (se c ao 3.3.6). 3.3.1 TECNICAS E FERRAMENTAS UTILIZADAS O sistema web foi desenvolvido utilizando tecnologia ASP.NET para c odigo do servidor, e tecnologias compat veis com web standards (XHTML, CSS) para c odigo cliente. Para o sistema de corre c ao, foi implementado um servi co do Windows que utiliza o componente JudgeServer (apresentado na se c ao 3.2.7). Ambos os sistemas foram implementados em plataforma .NET, utilizando-se a linguagem C#.NET. A ferramenta utilizada para codica c ao foi o VisualStudio .NET. O

3.3 Implementa ca o

51

VisualStudio e uma Integrated Development Environment (IDE) para desenvolvimento de aplica c oes em .NET. 3.3.2 BANCO DE DADOS O SGBD utilizado foi o Microsoft MSDE 2.0. O MSDE e uma vers ao de menor porte, por em compat vel com o Microsoft SQL Server. Isso assegura que o mesmo componente DAL utilizado para acesso ao MSDE pode ser utilizado para acesso ao SQL Server, sem nenhuma modica c ao. Optou-se pela utiliza c ao do SGBD Microsoft MSDE 2.0 por ser de distribui c ao gratuita, de forma que tem-se dispon vel todo o poder de processamento e recursos de um SGBD de grande porte, sem o custo associado as licensas. A forma de acesso ao SGBD foi a utiliza c ao de Stored Procedure (SP). Segundo Microsoft Corporation (2004c), uma SP e um grupo de comandos Structured Query Language (SQL) que cam armazanados no servidor e s ao compilados e executados como uma unidade. SP s ao similares a procedimentos em linguagens de programa c ao, de forma que podem ter par ametros, executar opera c oes e chamar outras SP e retornar valores para a rotina que a chamou. Entre as vantagens de utiliza c ao de SP est ao: a) permitem programa c ao modular; b) permitem uma execu c ao mais r apida, pois o c odigo e compilado e otimizado apenas na primeira execu c ao; c) reduzem o tr afego da rede, pelo fato de a aplica c ao enviar menos c odigo SQL para o servidor; d) servem como mecanismo de seguran ca, pois podem ser concedidas permiss oes de executar para a SP, mas n ao permiss oes de acesso as tabelas base. CREATE PROCEDURE ContestsListByUser @UserID INT AS SET NOCOUNT ON SELECT c.ContestID, c.StartAt, c.EndAt, c.Visibility FROM Contests c INNER JOIN ContestsUsers cu ON c.ContestID = cu.ContestID WHERE cu.UserID = @UserID ORDER BY StartAt DESC
Quadro 3.1 Procedimento armazenado para listar as competi c oes de um usu ario.

O quadro 3.1 mostra a SP utilizada para listar as competi c oes que um usu ario est a

3.3 Implementa ca o

52

inscrito. Para aux lio ao desenvolvimento do componente de acesso a dados (DAL), utilizouse o Microsoft Data Access Application Block (DAAB). O DAAB e um componente gerenciado5 que exp oe classes com m etodos para auxiliar na execu c ao de comandos em um servidor de banco de dados Microsoft SQL Server de uma forma robusta e eciente (MICROSOFT CORPORATION, 2004a). O DAAB encapsula as opera c oes de criar uma conex ao ao banco de dados, criar uma transa c ao, criar um comando, criar os par ametros para as SP e executar o comando em uma u nica chamada. O quadro 3.2 exemplica a chamada a SP ContestsListByUser passando o valor 1para o par ametro @UserID. SqlDataReader dr = SqlHelper.ExecuteReader(SqlHelper.CONN STRING, "ContestsListByUser", new object[] { user.UserID })
Quadro 3.2 C odigo para chamar o procedimento armazenado ContestsListByUser.

3.3.3 COMPONENTES O esqueleto das classes para cria c ao dos componentes foi gerado pelo Sybase PowerDesigner. Al em dos atributos e m etodos presentes nos diagramas de classes, as classes ao um implementantam tamb em m etodos construtores6 e propriedades. Propriedades s recurso da linguagem C# que implementam as opera c oes get e set para os atributos. O quadro 3.3 representa os atributos e propriedades da classe CountryInfo do componente Model. Cada componente foi compilado em uma assembly separada e instalado no Global Assembly Cache (GAC). O GAC e uma area para instala c ao de assemblies compartilhadas por v arias aplica c oes (MICROSOFT CORPORATION, 2004b). 3.3.4 SISTEMA WEB O sistema web e um sistema de informa c ao que implementa o gerenciamento de usu arios, problemas e competi c oes. Este e dividido em dois grupos de acesso: o administrador pode gerenciar as categorias, os problemas e as competi c oes dispon veis no sistema.
5 6

Componente .NET. M etodo chamado automaticamente na inicializa c ao de uma classe.

3.3 Implementa ca o

53

#region Attributes private byte countryID; private string name; #endregion #region Properties public byte CountryID { get { return countryID; } } public string Name { get { return name; } } #endregion
Quadro 3.3 Atributos e propriedades da classe CountryInfo.

Os usu arios podem manter seu cadastro, inscreverem-se em competi c oes p ublicas, visualizar os problemas e as estat sticas e enviarem suas solu c oes. A se c ao 3.3.6 demonstra o sistema em funcionamento nesses dois n veis. Para proteger a area restrita ao administrador do sistema foram utilizados os recursos de seguran ca existentes no .NET. O c odigo do quadro 3.4 foi adicionado ao arquivo de congura c ao do sistema web 7 . Esse c odigo congura o sistema de seguran ca para permitir orio admin. que apenas o usu ario identicado pelo nome 18 possa acessar o diret <location path="admin"> <system.web> <authorization> <allow users="1"/> <deny users="*"/> </authorization> </system.web> </location>

Quadro 3.4 Congura c ao de seguran ca para a area restrita ao administrador do sistema web.

Para que o sistema de seguran ca saiba o nome dos usu arios, o valor deve ser informado no momento da autentica c ao do usu ario. O quadro 3.5 exibe o c odigo que autentica o usu ario e informa ao sistema de seguran ca o nome. Optou-se por informar ao sistema de seguran ca o c odigo do usu ario ao inv es do
7 8

Web.cong. C odigo do usu ario administrador.

3.3 Implementa ca o

54

FormsAuthentication.SetAuthCookie(ui.UserID.ToString(), false);
Quadro 3.5 C odigo para autentica c ao do usu ario no sistema web.

nome. O sistema de seguran ca disponibiliza uma propriedade User em todas as p aginas ASP.NET. Utilizando-se a senten ca User.Identity.Name, pode-se recuperar o nome do usu ario autenticado. Nessa implementa c ao, tal senten ca recupera o c odigo do usu ario, que e posteriormente usado para acesso ao banco de dados para recuperar as informa c oes necess arias. 3.3.5 SISTEMA DE CORREC AO O sistema de corre c ao automatizado consiste de um servi co do Windows, que instancia e inicia o componente JudgeServer e um Wrapper. O quadro 3.6 ilustra os m etodos do servi co do Windows. O m etodo OnlineJudge() e o construtor da classe do servi co, e cria uma nova inst ancia da classe Judge, do componente JudgeServer. Os m etodos OnStart(), OnStop() e OnCustomCommand() tratam as requisi c oes de inicializa c ao, naliza c ao e execu c ao de a c oes personalizadas que s ao enviadas pelo SCM. private Judge judgeServer; public OnlineJudge() { judgeServer = new Judge(); } protected override void OnStart(string[] args) { judgeServer.Start(); } protected override void OnStop() { judgeServer.Stop(); } protected override void OnCustomCommand(int command) { if (command == 128) //128 e flag p/ sinalizar judge judgeServer.JudgeRequest(); }
Quadro 3.6 C odigo do servi co do Windows.

O m etodo Submission.SignalJudge() do componente BLL (exibido no quadro 3.7

3.3 Implementa ca o

55

e especicado na se c ao 3.2.5) e executado quando um usu ario faz uma submiss ao pelo sistema web e envia ao servi co de corre c ao uma requisi c ao para executar uma a c ao personalisada. A a c ao personalizada denida nesse servi co invoca o m etodo JudgeRequest() da classe Judge, fazendo com que o sistema esteja ciente de uma nova submiss ao e inicie o processo de execu c ao, caso n ao esteja corrigindo outra submiss ao no momento. public class Submission { . . . private void SignalJudge() { ServiceController judgeService = new ServiceController("OnlineJudgeService"); try { judgeService.ExecuteCommand(128); //128 e flag p/ sinalizar judge } catch {} } . . . }
Quadro 3.7 C odigo do m etodo Submission.SignalJudge() do componente BLL.

Ao receber a notica c ao de que existe uma nova submiss ao, o sistema de corre c ao ent acessa o banco de dados para recuperar informa c oes sobre a submiss ao. E ao criada uma inst ancia do m odulo de compila c ao espec co para a linguagem de programa c ao que o usu ario escolheu no momento da submiss ao da solu c ao. Esse m odulo vai fazer a compila c ao do codigo-fonte, vericar se o programa tem identica c oes do usu ario, do problema e da competi c ao e vericar se o programa n ao tenta executar nenhuma a c ao potencialmente perigosa. Para o m odulo de corre c ao de programas em linguagem C#, a forma de identica c ao utilizada foi atrav es de atributos. Atributos s ao declara c oes descritivas que fazem uma anota c ao nos elementos do programa (MICROSOFT CORPORATION, 2004b). O quadro 3.8 exemplica um atributo com a identica c ao do usu ario, do problema e da competi c ao. A vantagem da utiliza c ao de atributos no lugar de coment arios no c odigo-fonte e que a infra estrutura do .NET Framework reconhece e prov e f acil acesso ` as informa c oes denidas em atributos. A verica c ao de seguran ca para programas em C# n ao limita o uso de qualquer

3.3 Implementa ca o

56

[assembly: OnlineJudgeIdentification( UserID="B63C5208-813A-468F-9E6F-7C58ABBB10A7", ProblemID=2, ContestID=5)]

Quadro 3.8 Atributo para identica c ao do programa submetido para corre c ao.

classe ou m etodo, visto que o sistema de seguran ca verica em tempo de execu c ao se o programa tem permiss oes para utilizar as classes. Como o programa do usu ario recebe permiss oes bem restritas, as opera c oes privilegiadas n ao ser ao executadas. No entanto, um m odulo de compila c ao para uma linguagem que n ao suporte seguran ca em tempo de execu c ao dever a limitar o uso de classes e m etodos restritos, potencialmente varrendo o c odigo-fonte. O m etodo StartMonitorProcess() da classe Judge e o respons avel por iniciar o processo com o Wrapper para corre c ao e monitor a-lo. O uso do Wrapper se fez necess ario a partir de uma limita c ao encontrada, descrita na se c ao 3.4.1. O papel do Wrapper e iniciar o programa do usu ario dentro do mesmo processo do Wrapper, em um Application Domain separado. A g. 3.14 representa os processos e os Application Domains existentes quando o Wrapper e o programa do usu ario est ao carregados. Quando o programa do usu ario termina, o Wrapper avisa o sistema que corre c ao, que pode ent ao ler a quantidade de recursos utilizados.

Figura 3.14 Rela c ao entre os processos e os Application Domains do sistema de corre c ao e do Wrapper.

Conseguir a sincronia ideal entre o sistema de corre c ao e o Wrapper foi complicado e exigiu muito trabalho de remodelagem. V arias dessas diculdades est ao descritas na se c ao 3.4.1. Depois que o Wrapper foi iniciado, o sistema de corre c ao inicia uma thread para ler a sa da padr ao do programa, uma para ler a sa da de erros, abre uma porta TCP para

3.3 Implementa ca o

57

receber a sinaliza c ao de que o programa do usu ario acabou e nalmente envia as entradas secretas para o programa do usu ario resolver o problema. O quadro 3.9 mostra o c odigo mais signicativo do programa Wrapper. Primeiro e invocado o m etodo CreateAppDomain() (c odigo no quadro 3.10) para criar e congurar as op c oes de seguran ca de um novo Application Domain. Esse Application Domain e congurado de forma que a u nica permiss ao para seus programas seja de execu c ao. Nenhum acesso a recursos (sistema de arquivos, registro, bancos de dados) e permitido. O programa do usu ario e ent ao colocado para executar dentro desse Application Domain. Ao t ermino da execu c ao do programa, o Application Domain e descarregado e o Wrapper invoca o m etodo ComunicaJudge() para informar ao sistema de corre c ao que o programa do usu ario terminou e agora e hora de ler a quantidade de recursos utilizados. class Wrapper { . . . public static void Main(string[] args) { . . . AppDomain executeDomain = CreateAppDomain(); try { executeDomain.ExecuteAssembly(programName); } catch (SecurityException) { Console.Error.Write("securityError"); } catch (Exception ex) { Console.Error.Write(ex.Message); } finally { AppDomain.Unload(executeDomain); } ComunicaJudge(); . . . } . . . }
Quadro 3.9 Rotina principal do programa Wrapper.

3.3 Implementa ca o

58

class Wrapper { . . . private static AppDomain CreateAppDomain() { // cria Application Domain AppDomain executeDomain = AppDomain.CreateDomain("executeDomain"); // cria um n vel de pol tica de seguran ca PolicyLevel domainPolicy = PolicyLevel.CreateAppDomainLevel(); // cria um conjunto de permiss~ ao vazio // e adiciona permiss~ ao SecurityPermission.Execution PermissionSet permSet = new PermissionSet(PermissionState.None); permSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution)); // atribui esse conjunto de permiss~ ao ao grupo de c odigo raiz domainPolicy.RootCodeGroup.PolicyStatement = new PolicyStatement(permSet, PolicyStatementAttribute.LevelFinal); // define pol tica seguran ca desse Application Domain executeDomain.SetAppDomainPolicy(domainPolicy); return executeDomain; } }
Quadro 3.10 Rotina CreateAppDomain() do programa Wrapper.

Enquanto o Wrapper est a executando o programa do usu ario, o sistema de corre c ao ca monitorando os recursos utilizados em intervalos regulares. Se for detectado que o programa do usu ario consumiu muitos recursos, ele e nalizado imediatamente, antes do seu t ermino natural. Quando os programas dos usu arios terminam dentro do limite aceit avel de tempo, o sistema de corre c ao l e a sa da que eles geraram e compara com a sa da esperada. Com base nessa compara c ao e feita a avalia c ao se o programa e correto ou n ao. O uso de um Wrapper introduz um overhead ao sistema, e os recursos consumidos pelo Wrapper s ao deduzidos na hora da avalia c ao do uso excessivo de recursos.

3.3 Implementa ca o

59

3.3.6 OPERACIONALIDADE DA IMPLEMENTAC AO Esta se c ao apresenta dois estudos de caso do sistema em funcionamento. O primeiro deles apresenta as funcionalidades dispon veis para o administrador. O segundo apresenta o sistema dispon vel para os demais usu arios. DO SISTEMA 3.3.6.1 FUNCIONALIDADES PARA ADMINISTRAC AO As funcionalidades para administra c ao do sistema est ao isoladas no diret orio /adminda aplica c ao web, e podem ser acessadas apenas pelo usu ario administrador. As funcionalidades dispon veis s ao gerenciamento de categorias, problemas e competi c oes. A g. 3.15 exibe a tela para cadastro de categorias. A g. 3.16 mostra a tela de cadastro de problemas e a g. 3.17 a tela para indicar a quais categorias um problema pertence. Um problema pode pertencer a v arias categorias. Al em da entrada e sa da de exemplo, um problema pode ter um ou mais conjuntos de entrada e sa da de avalia c ao. A tela para cadastro de conjuntos de avalia c ao e exibida na g. 3.18. No caso de um problema ter mais de um conjunto de avalia c ao, o programa do usu ario e executado mais de uma vez.

Figura 3.15 Tela de cadastro de categorias.

A g. 3.19 mostra a tela para cadastro de competi c oes, e a g. 3.20 mostra a tela para indicar quais problemas fazem parte dessa competi c ao. Como a competi c ao foi especicada como p ublica, n ao e necess ario indicar os usu arios dessa competi c ao. 3.3.6.2 FUNCIONALIDADES PARA USUARIOS DO SISTEMA Esta se c ao apresenta as funcionalidades dispon veis para os usu arios do sistema. A g. 3.21 apresenta a tela para cadastro de usu arios. Para visualizar os problemas dispon veis para corre c ao, o usu ario entra antes na

3.3 Implementa ca o

60

Figura 3.16 Tela de cadastro de problemas.

Figura 3.17 Tela para indica c ao das categorias dos problemas.

3.3 Implementa ca o

61

Figura 3.18 Tela de cadastro de conjuntos de entrada e sa da para avalia c ao.

Figura 3.19 Tela de cadastro de categorias.

Figura 3.20 Tela para indica c ao dos problemas de uma competi c ao.

3.3 Implementa ca o

62

Figura 3.21 Tela de cadastro de usu arios.

lista de categorias (g. 3.22). Essa lista mostra o nome da categoria, o n umero de problemas na categoria e o n umero de problemas que o usu ario j a resolveu nessa categoria.

Figura 3.22 Tela com a lista de categorias.

A g. 3.23 mostra os problemas dispon veis em cada categoria, com uma indica c ao de quantos usu arios resolveram cada problema e quais foram resolvidos pelo usu ario. A tela com os detalhes do problema e exibida na g. 3.24. A tela da g. 3.25 mostra as competi c oes que o usu ario est a inscrito e as competi c oes em que ele pode se inscrever. O link inscrever s o aparece para usu arios autenticados. Os detalhes da competi c ao s ao exibidos na tela da g. 3.26. Como a competi c ao ainda n ao

3.3 Implementa ca o

63

Figura 3.23 Tela com a lista de problemas por categoria.

Figura 3.24 Tela com os detalhes do problema.

3.3 Implementa ca o

64

iniciou, a lista de problemas dessa competi c ao n ao est a vis vel.

Figura 3.25 Tela com as competi c oes.

Figura 3.26 Tela com os detalhes da competi c ao.

A tela g. 3.27 e usada para submeter programas para corre c ao. O usu ario pode escolher se deseja receber um e-mail com o resultado da corre c ao. O sistema s o enviar a o e-mail se o usu ario estiver autenticado no momento da submiss ao, ou se o sistema encontrar a identica c ao do usu ario no programa submetido. A g. 3.28 exibe a tela com a lista das u ltimas submiss oes que o sistema recebeu. Nessa tela pode-se ver que a u ltima submiss ao enviada (SubmissionID 67) foi considerada correta. Para ilustrar exemplos de programas maliciosos, foram enviados os programas do quadro 3.11 e do quadro 3.12. O primeiro deles e um loop innito, que sem recursos de prote c ao consumiria excessivo tempo de processador. O segundo programa tenta apagar o arquivo do device driver para o processador Pentium III no diret orio do sistema operacional. A g. 3.29 mostra os resultados do sistema de corre c ao para esse dois programas

3.3 Implementa ca o

65

Figura 3.27 Tela para submiss ao de programas.

Figura 3.28 Tela com a lista das u ltimas submiss oes.

3.4 Resultados e discuss ao

66

using Kirchner.TCC.OnlineJudgeIdentification; [assembly: OnlineJudgeIdentification(ProblemID=1)]

class Teste { public static void Main() { while(true); } }

Quadro 3.11 Programa malicioso que consome muito tempo de CPU.

using Kirchner.TCC.OnlineJudgeIdentification; [assembly: OnlineJudgeIdentification(ProblemID=1)]

class Teste { public static void Main() { File.Delete(@"C:\WINDOWS\system32\drivers\p3.sys"); } }

Quadro 3.12 Programa malicioso que tenta acessar o disco.

maliciosos. O programa com loop innito e o SubmissionID 73. Esse programa recebeu a avalia c ao Limite de tempo excedido(TL) e foi nalizado, depois de consumir pouco mais tempo de processador do que o permitido para esse problema. O programa que tenta acessar disco (SubmissionID 76) recebeu a avalia c ao Fun c ao restrita(RF). Durante a execu c ao, esse programa gerou uma exce c ao de seguran ca e foi nalizado. A g. 3.30 mostra a tela com as estat sticas das submiss oes para cada problema cadastrado, e a tela da g. 3.31 mostra o ranking dos autores cadastrados no sistema. 3.4 RESULTADOS E DISCUSSAO O sistema de corre c ao implementado e similar em termos de funcionalidade aos existentes na Universidade de Valladolid (UNIVERSIDAD DE VALLADOLID, [2004?]) e na ca Universidade do Estado de Ural (URAL STATE UNIVERSITY, [2004?]), com a diferen que executa em sistema operacional Windows e aceita programas em linguagem C#. Esses sistemas apresentam um conjunto de problemas a serem resolvidos, podem criar competi c oes, gerenciam usu arios e apresentam estat sticas sobre os problemas e usu arios

3.4 Resultados e discuss ao

67

Figura 3.29 Resultados do sistema de corre c ao para os dois programas maliciosos submetidos a corre c ao.

Figura 3.30 Tela com as estat sticas dos problemas.

Figura 3.31 Tela com ranking de autores.

3.4 Resultados e discuss ao

68

cadastrados. Uma diferen ca entre esses sistemas e que eles aceitam envio de solu c oes por e-mail, al em do site. O sistema web apresenta funcionalidades similares ao BOCA, utilizado para gerenciar competi c oes. Como n ao foi projetado unicamente para gerenciar competi c oes, esse sistema web n ao apresenta, por exemplo, recursos para comunica c ao com os ju zes. No entanto, pode gerenciar usu arios, problemas e competi c oes. O sistema de corre c ao constitui um ambiente seguro para execu c ao de c odigo arbitr ario, recurso existente no Bees. O Bees apresenta mecanismos mais avan cados para gerenciamento de uso de recursos do c odigo m ovel do que o sistema implementado. No entanto, o sistema de corre c ao apresenta recursos que garantem que um programa n ao poder a danicar a m aquina local, nem consumir excessivos recursos computacionais. Para extens ao do sistema e adi c ao de m odulos para compila c ao em outras linguagens de programa c ao, deve-se implementar um componente que extenda a classe DotNetLanguageModule, para linguagens .NET, ou implemente a interface ILanguageModule no caso de uma linguagem que n ao execute na plataforma .NET. Essa classe e interface est ao ilustrados no diagrama de classes da g. 3.12. O m etodo Compile() deve compilar o c odigo-fonte do usu ario e retornar as mensagens de erros do compilador quando existentes. O m etodo SafeVerication() deve garantir que o programa seja seguro para execu c ao, quando a seguran ca n ao pode ser vericada em tempo de execu c ao. O m etodo GetIdentications() deve retornar as identica c oes do usu ario, do programa e da competi c ao, e o m etodo CreateProcessStartInfo() deve retornar um objeto do tipo ProcessStartInfo, com os par ametros de como o programa deve ser inicializado. Para incorporar o m odulo ao sistema, deve-se adicionar um registro ` a tabela Languages. Os campos Name, Assembly e Type s ao, respectivamente, o nome da linguagem de programa c ao que aparece para o usu ario, o nome da assembly com o m odulo para compila c ao e o nome completo da classe, incluindo namespace, que implementa as opera c oes. 3.4.1 DIFICULDADES ENCONTRADAS A maior parte do trabalho transcorreu sem problemas. Foram encontradas algumas pequenas diculdades na etapa de especica c ao, devido ` a pouca experi encia com modelagem UML. A maior fonte de problemas foi realmente a implementa c ao do sistema de corre ca o. A primeira diculdade foi conseguir ler as informa c oes da quantidade de recursos (proces-

3.4 Resultados e discuss ao

69

sador e mem oria) utilizados pelo programa do usu ario. Ler as informa c oes e simples, pois a classe Process da biblioteca de classes do .NET Framework cont em m etodos para obter essas informa c oes. As informa c oes apenas est ao dispon veis enquanto o processo est a em execu c ao, no entanto, o sistema de corre c ao precisa saber quanto recurso foi consumido ao m da execu c ao do programa do usu ario. A melhor solu c ao encontrada foi a utiliza c ao de um Wrapper. Outra solu c ao analisada seria de iniciar o programa do usu ario dentro do mesmo processo que executa o sistema de corre c ao. No entanto, isso tornaria invi avel obter as informa c oes de recursos utilizados. A uso de um Wrapper introduziu problemas adicionais. Surge a necessidade de sincroniza c ao e comunica c ao do sistema de corre c ao com o Wrapper. A solu c ao menos custosa em termos de desempenho seria utilizar a sa da de erros para comunica c ao. Essa op c ao consumiu poucos recursos, mas apresentava problemas de funcionamento. Com grande freq u encia, ambos os processos (sistema de corre c ao e Wrapper ) cavam bloqueados. A solu c ao adotada e que funcionou muito bem, por em consome mais recursos, ea comunica c ao atrav es do protocolo TCP. Antes de iniciar o Wrapper, o sistema de corre c ao abre uma porta TCP e ca aguardando um sinal para prosseguir com suas atividades. Teve-se diculdade de redirecionamento da entrada e sa da padr ao do programa do usu ario. A vantagem de utilizar entrada e sa da padr ao e que o programa submetido ` a corre c ao n ao precisa ter nenhum tratamento especial para receber as informa c oes. O programa pode simplesmente ler os dados do teclado e escrever na tela com as rotinas que a linguagem de programa c ao disponibiliza. Ainda assim, essa e a forma com que os sistemas de juiz online pesquisados (se c ao 2.4) funcionam. A classe Process oferece recursos para redirecionar a entrada e sa da padr ao de um processo. A diculdade existente e que o processo e na verdade o Wrapper, e o programa do usu ario e iniciado dentro desse mesmo processo, em um Application Domain a parte. V arias solu c oes foram pesquisadas, e desenvolveu-se um mecanismo de sincroniza c ao entre o sistema de corre c ao e o Wrapper. O mecanismo funcionava bem apenas quando o sistema executava no depurador. Esse mecanismo foi incrementado fazendo com que um dos programas esperasse de 1 a 2 segundos em determinadas situa c oes, para o outro programa concluir alguma atividade. Dessa forma conseguiu-se uma solu c ao funcional, por em muito pouco eciente em termos de tempo utilizado. Na solu c ao nal conseguiuse eliminar a necessidade de esperas, sendo o u nico mecanismo de sincroniza c ao ainda existente o uso de uma conex ao TCP para comunica c ao.

70

CONCLUSOES
Este trabalho alcan cou na ntegra seu objetivo inicial, que e o de implementar um

sistema de corre c ao autom atica para provas de concursos de programa c ao, que execute em ambiente Windows e aceite programas escritos em linguagem C#.NET. A arquitetura de seguran ca do .NET Framework demonstrou-se muito robusta, e seu uso facilitou a implementa c ao de um ambiente seguro. O ambiente de desenvolvimento agilizou o processo de codica c ao, e o depurador integrado foi de grande valia para sanar os erros do sistema de corre c ao. Al em da possibilidade de estabelecer um concurso de programa c ao local ou via internet, a implementa c ao serve como refer encia de um sistema orientado a objetos, dividido em v arias camadas e possibilidade de extens ao para uso de outros SGBD e outras linguagens de programa c ao. Outrosim, serve como um estudo de caso de implementa ca o das op c oes de seguran ca da plataforma .NET. Algumas limita c oes existentes: a) requer Windows 2000 Server ou Windows Server 2003; b) requer o .NET Framework SDK; apenas o runtime n ao e suciente; c) a corre c ao de programas n ao e t ao eciente, devido ao overhead da cria c ao de processos e comunica c ao entre eles; a corre c ao de 50 programas com pouco c odigo demorou cerca de 3 minutos. 4.1 EXTENSOES Sugere-se como extens ao desse trabalho a implementa c ao de m odulos para outras linguagens .NET, e tamb em para as linguagens C, C++, Java e Pascal. Essas quatro linguagens est ao dispon veis para uso nos sistemas pesquisados e contemplam muitos usu arios. Aprimorar o sistema para aceitar submiss oes por e-mail e um recurso interessante, e presente em ambos os sistemas de corre c ao pesquisados. Tamb em, a modica c ao do processo de corre c ao, possibilitando corre c ao simult anea de v arios programas e melhorando o tempo de resposta quando muitos programas esperam para serem corrigidos. O

4.1 Extens oes

71

estudo de alguma t ecnica que possa eliminar o uso do Wrapper e do uso de comunica c ao via TCP pode trazer signicativos benef cios de desempenho.

72

REFERENCIAS BIBLIOGRAFICAS

ANDERSON, Richard et al. Professional ASP.NET. Chicago: Wrox Press, 2001. ASSOCIATION FOR COMPUTING MACHINERY. The ACM-ICPC International Collegiate Programming Contest Web Site sponsored by IBM. 2004. Dispon vel em: <http://icpc.baylor.edu/icp>. Acesso em: 25 ago. 2004. BUTLER, Jason; CAUDILL, Tony. ASP.NET Database Programming Weekend Crash Course. New York: Hungry Minds, 2002. CROCKER, Angela; OLSEN, Andy; JEZIERSKI, Edward. Designing Data Tier Components and Passing Data Through Tiers. Estados Unidos, 2002. GAMMA, Erich et al. Design Patterns: Elements of reusable object-oriented software. Reading, Massachusetts: Addison-Wesley, 1996. GUPTA, Phalguni. ACM ICPC at IIT Kanpur: 14 - 15 December, 2004. 2004. Dispon vel em: <http://www.acmsolver.org/?itemid=6>. Acesso em: 31 jul. 2004. MANZOOR, Shahriar. Common Mistakes in Online and Real-time Contests. 2004. Dispon vel em: <http://www.acmsolver.org/?itemid=>. Acesso em: 31 jul. 2004. MEIER, J.D. et al. Improving Web Application Security: Threats and countermeasures. Estados Unidos, 2003. Dispon vel em: <http://download.microsoft.com/download/d/8/c/d8c02f31-64af-438c-a9f4-e31acb8e3333/Threats Countermeasures.pd>. Acesso em: 16 out. 2004. MICROSOFT CORPORATION. Developing Microsoft ASP.NET Web Applications Using Visual Studio .NET. Estados Unidos, 2002. Apostila do curso. MICROSOFT CORPORATION. Programming with C#. Estados Unidos, 2002. Apostila do curso. MICROSOFT CORPORATION. Data Access Application Block. Estados Unidos, 2004. Manual de software. MICROSOFT CORPORATION. Microsoft .NET Framework SDK Documentation. Redmond, 2004. Manual de software. MICROSOFT CORPORATION. SQL Server Books Online. Estados Unidos, 2004. Manual de software. MICROSOFT CORPORATION. Mcad/mcsd self-paced training kit: Developing xml web services and server components with microsoft visual basic .net and microsoft c# .net. In: . Redmond: Microsoft Press, 2003. cap. 2.

Refer encias Bibliogr acas

73

OBJECT MANAGEMENT GROUP. UML Resource Page. 2004. Dispon vel em: <http://www.uml.org>. Acesso em: 20 nov. 2004. PARIHAR, Mridula et al. ASP.NET Bible. New York: Hungry Minds, 2002. REILLY, Douglas J. Designing microsoft asp.net applications. In: Microsoft Press, 2002. cap. 1. . Redmond:

ROBINSON, Simon et al. Professional C#. Chicago: Wrox Press, 2001. SILVA, Ulisses Furquim Freire da. BOCA - Sistema de Submiss ao. 2003. Dispon vel em: <http://maratona.ime.usp.br/manualBOCA.pd>. Acesso em: 02 ago. 2004. SKIENA, Steven S.; REVILLA, Miguel A. Programming Challenges: The programming contest training manual. New York: Springer, 2003. STACK, Tim; EIDE, Eric; LEPREAU, Jay. Bees: A secure, resource-controlled, javabased execution environment. In: IEEE CONFERENCE ON OPEN ARCHITECTURES AND NETWORK PROGRAMMING, 6., 2003, San Francisco. Proceedings... Piscataway: IEEE Press, 2003. p. 97106. STONY BROOK UNIVERSITY. Secure Mobile Code Execution Environment. 2002. Dispon vel em: <http://seclab.cs.sunysb.edu/seclab1/research/projects/ca-mcc.ht>. Acesso em: 03 ago. 2004. SYBASE INC. PowerDesigner. 2004. Dispon vel em: <http://www.sybase.com/products/developmentintegration/powerdesigne>. Acesso em: 20 nov. 2004. UNIVERSIDAD DE VALLADOLID. Online Judge - Problem Set Archive. [2004?]. Dispon vel em: <http://online-judge.uva.es/problemset>. Acesso em: 01 ago. 2004. URAL STATE UNIVERSITY. Problem Set Archive with Online Judge System. [2004?]. Dispon vel em: <http://acm.timus.ru/default.asp>. Acesso em: 01 ago. 2004. WATKINS, Demien; LANGE, Sebastian. An Overview of Security in the .NET Framework. 2002. Dispon vel em: <http://msdn.microsoft.com/library/en-us/dnnetsec/html/netframesecover.as>. Acesso em: 17 out. 2004. ZELDMAN, Jerey. Designing with web standards. Indianapolis: New Riders, 2003.

74

APENDICE A -- CENARIOS DOS CASOS DE USO DO SISTEMA WEB

USUARIO A.1 USE CASE AUTENTICAC AO Cen ario principal a)Usu ario digita login e senha; b)Sistema compara credenciais fornecidas com o banco de dados; c)Sistema autentica usu ario (efetua login). Cen arios alternativos Usu ario informou login ou senha inv alidos: a)Informa usu ario que login ou senha s ao inv alidos. A.2 USE CASE CADASTRO DE CATEGORIAS Precondi c oes a)Usu ario deve estar autenticado como administrador Cen ario principal a)Administrador dene nome para categoria; b)Sistema web guarda as informa c oes e informa que o cadastro teve sucesso. Cen arios alternativos Administrador preencheu campos com dados inv alidos: a)Informa administrador sobre quais dados s ao inv alidos e solicita corre c ao.

A.3 Use Case Cadastro de problemas

75

A.3 USE CASE CADASTRO DE PROBLEMAS Precondi c oes a)Usu ario deve estar autenticado como administrador Cen ario principal a)Administrador dene nome para o problema; b)Administrador escolhe categoria para o problema; c)Administrador informa descri c ao completa do problema; d)Administrador informa entradas e sa das de exemplo, que ser ao exibidas a todos os usu arios para ilustrar o formato dos dados que o programa ir a receber, e o formato dos dados que o programa dever a gerar; e)Administrador informa entradas e sa das secretas, que ser ao utilizadas pelo sistema de corre c ao para vericar se o programa resolve corretamente o problema; f)Administrador informa a quantidade m axima de tempo de processador (em ms) e a quantidade m axima de mem oria (em bytes) que o programa sendo corrigido pode utilizar; g)Sistema web guarda as informa c oes e informa que o cadastro teve sucesso. Cen arios alternativos Administrador preencheu campos com dados inv alidos: a)Informa administrador sobre quais dados s ao inv alidos e solicita corre c ao. A.4 USE CASE CADASTRO USUARIO Cen ario principal a)Usu ario acessa sistema web; b)Usu ario informa dados solicitados (nome, e-mail, data nascimento, cidade, estado, pa s, n vel de escolaridade, tempo de experi encia com programa c ao, login, senha); c)Sistema guarda informa c oes no banco de dados; d)Sistema autentica usu ario (efetua login). Cen arios alternativos Usu ario preencheu campos com dados inv alidos: a)Informa usu ario sobre quais dados s ao inv alidos e solicita corre c ao.

A.5 Use Case Criar competi co es

76

Usu ario escolheu um login j a existente: a)Informa usu ario que login j a existe e solicita altera c ao. A.5 USE CASE CRIAR COMPETIC OES Precondi c oes a)Usu ario deve estar autenticado como administrador Cen ario principal a)Administrador dene data/hora inicial e nal para a competi c ao; b)Administrador dene se a competi c ao e p ublica ou privativa; c)Administrador dene quais usu arios ir ao participar dessa competi c ao; d)Administrador dene quais problemas ser ao utilizados nessa competi c ao; e)Sistema web guarda as informa c oes e informa que o cadastro teve sucesso. Cen arios alternativos Administrador preencheu campos com dados inv alidos: a)Informa administrador sobre quais dados s ao inv alidos e solicita corre c ao. Administrador n ao informou usu arios no caso de uma competi c ao privativa: a)Informa administrador que em competi c oes privativas e obrigat orio especicar usu arios e solicita corre c ao. A.6 USE CASE ENVIAR SOLUC AO Cen ario principal a)Sistema web pede para usu ario especicar qual o arquivo que cont em o c odigofonte da solu c ao que o usu ario deseja enviar; b)Usu ario escolhe se quer receber resultados da corre c ao por e-mail; c)Usu ario escolhe linguagem de programa c ao que a solu c ao foi escrita; d)Navegador do usu ario faz upload do arquivo para servidor web; e)Sistema web recebe o arquivo e o encaminha ao sistema de corre c ao autom atica; f)Sistema web avisa usu ario que arquivo foi recebido com sucesso e o programa ser a analisado. Cen arios alternativos Erro no envio do arquivo:

A.7 Use Case Inscrever em competi ca o

77

a)Sistema notica usu ario da ocorr encia de um erro ao fazer upload do arquivo para o servidor, e mostra os detalhes do erro. A.7 USE CASE INSCREVER EM COMPETIC AO Precondi c oes a)Usu ario deve estar autenticado. Cen ario principal a)Sistema apresenta p/ usu ario as competi c oes p ublicas que ainda n ao iniciaram, juntamente com a data/hora de in cio e m; b)Usuario informa qual competi c ao ele deseja se inscrever; c)Sistema registra que usu ario est a inscrito na competi c ao escolhida e notica sucesso. A.8 USE CASE RELATORIO DE ESTAT ISTICAS DOS PROBLEMAS Cen ario principal a)Usu ario solicita relat orio de submiss oes; b)Sistema web busca no banco de dados a lista de problemas existentes, juntamente com o n umero de solu c oes apresentadas, o n umero de solu c oes corretas, o n umero de solu c oes inv alidas e o n umero de usu arios que resolveram cada problema; c)Sistema web apresenta dados em formato de um relat orio p/ internet. A.9 USE CASE VISUALIZAR PROBLEMA Cen ario principal a)Usu ario solicita categorias de problemas; b)Sistema web busca no banco de dados informa c oes sobre as categorias e quantos problemas existem em cada uma delas; c)Se o usu ario estiver autenticado, ser a mostrado tamb em o n umero de problemas que o usu ario j a resolver nessa categoria; d)Sistema web apresenta a lista de categorias; e)Usu ario escolhe categoria; f)Sistema web busca no banco de dados a lista de problemas da categoria escolhida, e o n umero de usu arios que j a conseguiram resolver cada problema;

A.10 Use Case Visualizar ranking autores

78

g)Se o usu ario estiver autenticado, ser a mostrado tamb em quais problemas o usu ario j a conseguiu resolver; h)Sistema web apresenta a lista de problemas; i)Usu ario escolhe problema que deseja visualizar; j)Sistema web busca no banco de dados a descri c ao e entradas e sa das de exemplo para o problema escolhido; k)Sistema web apresenta os detalhes do problema. A.10 USE CASE VISUALIZAR RANKING AUTORES Cen ario principal a)Usu ario solicita ranking de autores; b)Sistema web busca no banco de dados informa c oes sobre os autores e quantos problemas cada um conseguiu resolver; c)Sistema web apresenta dados em formato de um relat orio p/ internet. A.11 USE CASE VISUALIZAR RELATORIO SUBMISSOES Precondi c oes a)Usu ario deve estar autenticado. Cen ario principal a)Usu ario solicita relat orio de submiss oes; b)Sistema web busca no banco de dados os problemas que j a foram submetidos por esse usu ario, com detalhes sobre cada submiss ao (data/hora, identica ca o do problema, resultado do problema - correto, erro de compila c ao, resultado incorreto, etc -, tempo de execu c ao, quantidade de mem oria utilizada); c)Sistema web apresenta dados em formato de um relat orio p/ internet.

79

APENDICE B -- CENARIOS DOS CASOS DE USO DO SISTEMA DE CORREC AO

B.1 USE CASE CORRIGIR PROGRAMA Cen ario principal a)Sistema de corre c ao recebe c odigo-fonte enviado pelo sistema web; b)Sistema de corre c ao compila o c odigo-fonte do programa, gerando uma .NET Assembly (em formato DLL); c)Sistema de corre c ao carrega programa compilado em ambiente de execu c ao seguro; d)Sistema de corre c ao verica se o programa carregado tem identica c ao do usu ario e do problema sendo resolvido; e)Sistema de corre c ao verica se o programa carregado tem informa c oes da competi c ao que o usu ario est a participando; f)Sistema de corre c ao inicia o programa fornecido pelo usu ario, e fornece os dados de entrada secretos como par ametro; g)Sistema de corre c ao compara a sa da gerada pelo programa com a sa da esperada para os dados fornecidos; h)Sistema de corre c ao atualiza o banco de dados com as informa c oes sobre a corre c ao do programa; i)Sistema de corre c ao envia um e-mail para o usu ario, informando do resultado da corre c ao do programa. Caso aplic avel ser ao enviadas mensagens adicionais (ex: mensagens de erro do compilador em caso de problemas na compila c ao do programa). Cen arios alternativos Erro de compila c ao:

B.1 Use Case Corrigir programa

80

a)Retorna etapa 8 do uxo principal. Programa sem identica c ao de usu ario ou do problema: a)Descarta o programa compilado; b)Atualiza banco de dados informando que o programa foi ignorado; Identica c ao do usu ario ou do problema inv alida: a)Descarta o programa compilado; b)Atualiza banco de dados informando que o programa foi ignorado; Usu ario enviou um problema para uma competi c ao inexistente, que ele n ao esteja participando, que n ao tenha iniciado ainda ou j a tenha sido nalizada: a)Descarta o programa compilado; b)Atualiza banco de dados informando que o programa foi ignorado; c)Executa etapa 9 do uxo principal. Programa excedeu tempo de execu c ao ou quantidade de mem oria permitidos: a)Retorna a etapa 8 do uxo principal.

81

ANEXO A -- PERMISSOES PRE-DEFINIDAS DO .NET

Permiss ao DirectoryServicesPermission DNSPermission EndpointPermission EnvironmentPermission EventLogPermission FileDialogPermission FileIOPermission IsolatedStorageFilePermission IsolatedStoragePermission MessageQueuePermission OdbcPermission OleDbPermission OraclePermission PerformanceCounterPermission PrincipalPermission

Descri ca o Requerida para acessar o Active Directory. Requerida para acessar servidores Domain Name System (DNS). Dene um ponto de conex ao autorizado por um objeto SocketPermission. Controla leitura e escrita ` as vari aveis de ambiente. Requirea para acessar o log de eventos do sistema. Permito acesso de leitura a arquivos que o usu ario especicou em uma caixa de di alogo de arquivos. Controla acesso aos arquivos e arvores de diret orios. Controla o uso do sistema de arquivos virtual da aplica c ao. Requerida para acessar a area de armazenamento privado de uma aplica c ao. Requerida para acessar as las de mensagens do Microsoft Message Queuing. Requerida para usar o provedor de dados ADO.NET ODBC. Requerida para usar o provedor de dados ADO.NET OLE DB. Requerida para usar o provedor de dados ADO.NET Oracle. Requerida para acessar os contadores de desempenho do sistema. Usada para restringir o acesso a classes e m etodos com base na identidade do usu ario.

Anexo A -- Permiss oes pr e-denidas do .NET

82

PrintingPermission ReectionPermission RegistryPermission SecurityPermission ServiceControllerPermission SocketPermission SqlClientPermission UIPermission WebPermission

Requerida para acessar impressoras. Controla o acesso ao metadados das assemblies. Controla o acesso ` as chaves do registro do sistema. Esta permiss ao controla o uso da infra estrutura de seguran ca. Pode ser usado para restringir o acesso ao SCM. Pode ser usado para restringir a habilidade de criar ou aceitar conex oes em um protocolo. Pode ser usado para restringir o acesso a fonte de dados SQL Server. Pode ser usada para restringir acesso a area de transfer encia e para restringir o uso de janelas na aplica c ao. Pode ser usado para controlar o acesso a recursos da internet.