Trabalho de Formatura

Fernando Augusto de Carvalho
nUSP: 3286436
facarvalho@gmail.com

Supervisor: Flávio Soares Corrêa da Silva
fcs@ime.usp.br

São Paulo, 05 de dezembro de 2005

Introdução

O objetivo desta monografia é descrever parte da minha experiência de trabalho na empresa Touch Tecnologia e Informática, como estagiário durante o período de setembro de 2004 até a data de conclusão deste documento. Nas atividades realizadas no estágio, muitos sistemas estão envolvidos, assim como diversas tecnologias são utilizadas. Portanto para melhor descrever minha experiência, optei por focar em um sistema específico, o BaseLineSystem (ou BLS), que engloba a maioria do conteúdo aprendido.

Pretendo descrever os aspectos técnicos abordados, e relacioná-los com o conteúdo do curso de Bacharelado em Ciência da Computação do Instituto de Matemática da Universidade de São Paulo (IME-USP) [1]. Uma parte subjetiva também será apresentada, relatando minhas experiências pessoais durante este período.

Primeira Parte

A Empresa

A Touch Tecnologia e Informática é uma empresa recente, e foi fundada para desenvolver sistemas para o grupo Diagnósticos da América.

A Diagnósticos da América é a maior empresa de medicina diagnóstica da América Latina. Em constante crescimento, diversos laboratórios e hospitais integram o grupo: Delboni Auriemo, Lavoisier, Club DA, Bronstein, Lâmina e Santa Casa - Estes, atuam em 11 cidades, nos estados de São Paulo, Rio de Janeiro, Paraná e Minas Gerais. Estruturada em 148 unidades e três Núcleos Técnicos Operacionais, atende 15 mil clientes por dia e processa, diariamente, com precisão, segurança e agilidade, cerca de 80 mil exames de análises clínicas. [2]

Este sucesso e crescimento constante faz com que a Touch Tecnologia esteja cada vez mais presente, e seja cada vez mais necessária no processo de automação dos procedimentos do Diagnósticos da América. Diversos alunos do IME trabalham ou já passaram pela Touch, que a cada dia mostra mais maturidade e excelência na formação de profissionais da área de computação e engenharia de software.

O Projeto:

Motivação

Ao final do ano de 2004, a gerência de configuração da Touch Tecnologia estava em reformulação para adequação um novo processo de desenvolvimento baseado no RUP [3]. Algumas ferramentas de mercado, como o CVS [4] e o Cruisecontrol [5], começavam a tomar parte na implantação deste novo processo. Entretanto, existiam algumas atividades que não possuíam ferramentas para facilitar sua execução. Dentre essas atividades, existe o controle das bibliotecas utilizadas pelos sistemas em desenvolvimento e o controle de suas dependências (versões de bibliotecas utilizadas e sistemas dependentes).

O controle dos sistemas e de suas dependências é fundamental para um processo de desenvolvimento estável e planejado, além de permitir uma estrutura de sistema mais clara e consistente. Este controle poderia ser facilitado através de uma ferramenta capaz de automatizar e auxiliar essas atividades. Como no mercado não havia qualquer opção de ferramenta que se adequasse às necessidades da empresa, a Touch optou por desenvolver uma ferramenta interna, o BLS.

Tecnologias

O BaseLineSystem é um projeto que foi idealizado e desenvolvido inteiramente pela Touch Tecnologia. Logo nas primeiras versões do documento de visão, era evidente que este sistema deveria ser altamente flexível, adaptável e extensível. Isto tanto no ponto de vista do projeto como sistema, quanto para o processo de desenvolvimento e testes. E de fato, esta necessidade se mostra cada vez mais evidente com o seu uso diário, onde novos "casos de uso" surgem constantemente.

A linguagem de programação utilizada foi a linguagem Java (versão 1.4) [6], e as tecnologias utilizadas foram:

Tecnologias e Ferramentas utilizadas

Tecnologias desenvolvidas

Background

Para entender o BaseLineSystem, devemos antes conhecer alguns detalhes do processo de desenvolvimento de um sistema.

O CVS

O Concurrent Versions System é o repositório dos arquivos fonte de um projeto, associado a um sistema de controle de versão. É ele quem gerencia as múltiplas versões de uma mesma unidade de informação (como por exemplo, uma classe ou arquivo de configuração), que pode ser trabalhada por diversas pessoas. Mudanças nestes documentos são identificadas com o incremento de um número, e com uma associação à pessoa responsável pela mudança.

Versões de um sistema

Uma versão de um sistema seria como uma "foto" dele em um dado instante. Versões diferentes distinguem sistemas diferentes seja por causa das funcionalidades, da interface ou qualquer coisa que torne necessária esta distinção. Normalmente quando se conclui uma primeira ou nova etapa do desenvolvimento e obtém-se um sistema estável com novas ou diferentes características, é comum definir uma nova versão.

Após a implantação de uma versão de um sistema, normalmente inicia-se um esforço de criação de uma nova versão deste sistema, na qual funcionalidades serão incluídas, erros corrigidos, e alterações significativas de arquitetura podem ser feito.
Este desenvolvimento ocorre em paralelo aos esforços de manutenção da versão já implantada, em produção. O RUP básico aborda o desenvolvimento de uma versão até a sua implantação.

O desenvolvimento de uma nova versão é gerenciado como um novo projeto, independente do primeiro. A nova versão do sistema é construída sobre a primeira, porém é independente em termos de requisitos, arquitetura e implementação.

Branchs de desenvolvimento e baselines

Um mesmo sistema pode ser objeto de vários projetos, notadamente nos casos de manutenção e desenvolvimento de novas versões.

Projeto 1: desenvolvimento da versão 1 do Sistema X
Projeto 2: manutenção da versão 1 do Sistema X (algumas manutenções da versão 1 devem ser contempladas na versão 2)
Projeto 3: desenvolvimento da versão 2 do Sistema X

O CVS permite que você isole mudanças em uma linha de desenvolvimento separada, conhecida como branch. Quando se altera um arquivo em um branch, esta mudança não ocorre no branch principal ou em outros branches. Mais tarde você pode mover mudanças de um branch para outro.

Na figura acima, chamamos a linha de desenvolvimento de cima de branch HEAD. É nela que acontece o desenvolvimento do Sistema X.

O que chamamos de Projeto 1 é o desenvolvimento até ser definida o momento de fechamento da primeira versão (v1.0). Neste momento, uma prática usual é iniciar outra linha de desenvolvimento paralela ao branch HEAD, chamada branch 01, por exemplo. A idéia é clonar o estado do sistema no momento em que a versão é fechada, e a partir daí surgem dois projetos diferentes. Quem estiver trabalhando no projeto 2 estará fazendo manutenção na versão 1.0, enquanto outros desenvolvedores estarão implementando as novas funcionalidades que virão na versão 2, no projeto 3. Assim, as correções serão feitas na versão 1.0 do sistema, teoricamente estável, possibilitando o lançamento de patches de correção aos usuários. Isto sem afetar o desenvolvimento da nova versão do sistema.

Quando o branch 01 tiver completado alguma versão de correção, podemos copiá-las ao branch HEAD e utilizá-las no desenvolvimento da versão 2. A este processo damos o nome de merge.

Denominamos baseline uma versão fechada em um branch.

Dependências

Dentro de um projeto de desenvolvimento de um sistema de grande porte, há atividades que não são de desenvolvimento de software; são de naturezas diversas como: aquisição de componentes (hardware, software), preparação de infra-estrutura, normalização de informações e parametrização, treinamento e etc.

Essas atividades, segundo o RUP, podem ser incluídas no contexto de algum sistema. No entanto, elas podem ser tão grandes e complexas que são melhores gerenciadas separadamente.
Nestas situações criamos projetos que não correspondem a um sistema específico, mas dos quais o projeto maior depende, fundamentalmente em relação a cronograma e alocação de recursos.

Projeto 1: desenvolvimento do Sistema A; depende dos Projetos 1.1, 1.2, 1.3 e 1.4
Projeto 1.1: desenvolvimento do Sistema A1
Projeto 1.2: desenvolvimento dos Sistemas A2 e C; isto ocorre, por exemplo, em casos em que, ao desenvolver A2, é detectado um subsistema genérico C, que pode ser reutilizado em outro sistema, mas que é desenvolvido no mesmo projeto de A2.
Projeto 1.3: desenvolvimento do Sistema B
Projeto 1.4: atividades genéricas não relacionadas ao um sistema específico
Projeto 2: desenvolvimento da nova versão do sistema D; neste caso o Projeto 1 não depende do projeto 2, pois o Sistema A utiliza uma versão já desenvolvida do Sistema D.

Quando um projeto depende de um sistema, ele depende de algum versão (baseline) deste sistema, em algum branch.

O BaseLineSystem

O BLS foi projetado para gerenciar as dependências dos sistemas e auxiliar o processo de desenvolvimento de um projeto. Todos os sistemas seriam cadastrados juntamente com suas dependências. Para cada baseline gerada, seria enviado o arquivo binário desta baseline. O BLS seria então capaz de gerar um arquivo contendo todas as dependências de um certo projeto. Gerentes de configuração poderiam gerenciar as dependências de um branch em desenvolvimento até o fechamento de uma baseline.

Em sua primeira versão, o BLS assumia que uma baseline fazia parte da história do sistema, e portanto que nunca poderiam ser alteradas ou removidas após criadas. Como veremos adiante, apesar de parecer teoricamente correto, isto não funcionou na prática. O BLS hoje é bem mais flexível, e permite que baselines tenham suas informações (dependências, por exemplo) alteradas ou removidas.

Vejamos agora alguma das funcionalidades e características do BLS:

Tipos de dependências e o grafo de dependência

As dependências são tratadas de forma diferente no desenvolvimento de um projeto, conforme a sua natureza. Por exemplo, um sistema pode depender de uma biblioteca apenas para realizar testes, ou então apenas para o processo de compilação.

O BLS distingue cinco tipos de dependência entre sistemas:

1) Associação: Uma dependência de associação indica um sistema necessário ao funcionamento do projeto.
2) Agregação: Uma dependência de agregação é um caso especial da de associação. A agregação indica o relacionamento entre os sistemas do tipo “partes-todo”.
3) Ant: Indica uma dependência de sistema necessário para executar as tarefas Ant.
4) Teste: Dependência de sistema utilizado apenas para testes.
5) Opcional: Dependência opcional.

As dependências são cadastradas em um branch de desenvolvimento. Quando uma baseline é fechada, ela possui as mesmas dependências que o branch possuía naquele momento. Futuras alterações nas dependências do branch não alteram as dependências das baselines pertencentes a ele.

A representação interna da estrutura destes relacionamentos é um grafo orientado, onde um nó pode ser tanto uma baseline quanto um branch. Cada aresta possui um tipo de dependência e é orientada do nó dependente ao nó dependido.

Diagrama UML de classes do pacote br.com.touchtec.grafos

O padrão Visitor

O padrão comportamental de design Visitor foi utilizado na na implementação do pacote comum de grafos da Touch Tecnologia. Este padrão permite representar uma operação a ser realizada sobre elementos de uma estrutura de objetos, e permite definir novas operações sem alterar as classes dos elementos em que ele opera.

As interfaces de NoVisitor e ArcoVisitor são responsáveis pelo controle de uma busca no grafo de dependências. Devem determinar se a busca está concluída ou não. Qualquer efeito colateral à visita é permitida, com exceção a mudanças na estrutura de arcos e nós do grafo, a fins de garantir consistência da busca.

Por exemplo, para implementar a verificação por inconsistência circular extendemos a interface NoVisitor na classe VerificadorInconistenciaCircular. Seu construtor recebe o nó de partida, no caso um BaselineBean. À partir dele, visitamos cada uma de suas dependências (novos nós), e a cada uma verificamos se ela depende do nó inicial. Se depender, isto significa que partimos de um nó e alcançamos alguém que depende dele, ou seja, foi encontrada uma inconsistência de dependência circular. Em cada visita também é guardado um registro das visitas, para mostrar ao usuário o caminho que gera esta inconsistência circular.

Consequências:

Alguns dos benefícios do padrão Visitor são:

1. Visitor permite adicionar novas operações facilmente. Você pode definir uma nova operação sobre uma estrutura de objetos simplesmente adicionando um novo Visitor. Em contraste, se você espalhar funcionalidades em muitas classes, então você deve alterar cada classe para definir a nova operação.
2. Um Visitor reúne operações relacionadas e separa a não-relacionadas. Comportamento relacionado não é espalhado nas classes que definem a estrutura de objetos; é localizado em um Visitor. Conjuntos não-relacionados de comportamento são particionados em suas próprias subclasses de Visitor. Isto simplifica tanto as classes que definem os elementos e os algoritmos definidos nos visitors. Qualquer estrutura de dados específicas para um algoritmo pode ser escondida no Visitor.
3. Adicionar nova classe de ElementoConcreto é difícil. O padrão Visitor faz com que seja difícil adicionar classes de elementos ns quais ele opera. Cada novo elemento faz com que surja uma nova operação abstrata no Visitor e uma operação correspondente em todas as classes concretas de Visitors.
   Então a consideração chave em se aplicar o padrão é se é preferível mudar o algoritmo aplicado em cada objeto da estrutura, ou as próprias classes dos objetos que compõem esta estrutura.
4. Visitando através da hierarquia de classes. Um iterador pode visitar objetos em uma estrutura na medida em que caminha por eles chamando suas operações. Mas um iterador não pode trabalhar através de estrutura de objetos com diferentes tipos de elementos. Visitor não tem esta restrição. Ele pode visitar objetos que não possuem uma classe pai em comum. Você pode adicionar qualquer tipo de objeto a uma interface Visitor.
5. Acumulando estados. Visitors podem acumular estado à medida em que vão visitando cada elemento da estrutura de objetos. Sem um Visitor, este estado teria que ser passado como um argumento extra às operações de percorrer o grafo, ou então apareceriam como variáveis globais.
6. Quebrando encapsulamento. O padrão assume que as interfaces dos elementos concretos são poderosas o suficientes para permitir que os Visitors façam os seus serviços. Como resultado, ele geralmente força você a prover operações publicas que acessam os estados interno dos elementos, o que pode comprometer seus encapsulamentos.

O Arquivo de dependências

Geração do arquivo de dependências do próprio BLS.

A geração de um arquivo de dependências permite que o ambiente de desenvolvimento de um projeto esteja sempre atualizado. O arquivo é organizado conforme a categorização das dependências, e é gerado conforme as necessidades. É possível gerar arquivos escolhendo os tipos de dependências a serem baixadas, assim como a quantidade de níveis a se buscar no grafo de dependências.

A verificação por inconsistências

Quando adicionamos uma dependência a um branch ou baseline, podemos estar gerando inconsistências no grafo de dependências dos sistemas. Isto significaria que um ou mais sistemas teriam suas dependências cadastradas de maneira ilegal, levando a um cenário incorreto de desenvolvimento.

O BLS não permite adições que geram inconsistências, e possui mecanismos de busca no grafo de dependências para detectá-las.

Esta figura faz parte do cenário de testes para adição e remoção de baselines. Os sistemas são representados por letras, e em sua linha de desenvolvimento marcamos com uma bolinha a representação de uma baseline. As setas em preto indicam dependência de qualquer tipo, já existentes no cenário de cada teste.

Os testes realizados são numerados, e atuam sobre as classes de negócio responsáveis pelo gerenciamento de dependências da seguinte maneira:

[1] Adição Inconsistente: Esta adição tornaria o sistema A inconsistente. Por um caminho no grafo, podemos sair da primeira baseline do sistema A e voltar nela mesma. Uma baseline não pode depender dela mesma.
[2] Adição Inconsistente: Adicionando a dependência 2 tornaríamos o sistema D inconsistente, Ele já dependia da baseline 2 do sistema A, e por D -> B -> C -> A alcançamos a baseline 1 de A. Um sistema não pode alcançar duas versões diferentes de outro sistema.
[3] Adição Inconsistente: A adição [3] é similar à adição número [1]. Se ela for adicionada, uma baseline do sistema A depende de outra baseline dele mesmo.
[4] Adição Inconsistente: A adição da dependência [4] do sistema A para o sistema E gera inconsistência no sistema B. Repare que de B podemos alcançar duas versões distintas do sistema E.

[5] Adição Não-inconsistente: A adição da dependência [5] não deixa nenhum sistema inconsistente, e portanto é uma adição que pode ser feita.
[6] Remoção: Remoção de dependência é sempre permitida. Não há como gerar inconsistências realizando esta operação.

BLS alertando o usuário sobre as inconsistências encontradas.

Atividades Realizadas

Treinamento e outros Projetos

Até estar apto a trabalhar no BLS, passei por diversas atividades na empresa, onde cada vez mais fui agregando conhecimento sobre as tecnologias utilizadas e processos de desenvolvimento como um todo. Nos primeiros meses, participei do programa de treinamento de estagiários da Touch Tecnologia e concomitantemente participei do desenvolvimento de um sistema que a Touch desenvolve para a empresa NuttyBavarian. Durante este período, aprendi muito sobre os processos que envolvem o desenvolvimento de um projeto, tais como documentação (casos de uso, visão, requisitos, diagramas de classe e sequência), cronogramas, implementação, testes, padrões de design, configurações de ambientes, implantação de sistemas.

Após esta etapa, fui alocado para projetos que envolviam problemas como centralização de imagens de exames especializados, monitoramento das funções de um servidor Weblogic, testes de carga para web, novos requisitos para os sites www.delboniauriemo.com.br e www.lavoisier.com.br, dentre outros.

BLS novos requisitos

Contexto: Até então o BLS havia acabado de fechar a sua primeira versão de desenvolvimento, porém nunca havia sido utilizado. Sua documentação impecável e clareza de código fizeram com que ele fosse escolhido para servir de sistema-modelo para os métodos de desenvolvimento da empresa. No entanto, ao tentar utilizá-lo na prática, diversos novos requisitos surgiram prontamente. Seus desenvolvedores originais já estavam alocados em outros projetos, e não podiam atender tais requisitos.

Neste momento me tornei o responsável pela implementação dos novos requisitos e da manutenção do sistema até que ele se tornasse operacional. Nesta seção pretendo descrever os problemas encontrados, e as soluções adotadas para resolvê-los

.
Responsabilidades envolvidas em cada alteração

As alterações e implementações de novos requisitos do BLS envolviam seguir certos passos de desenvolvimento. Cada passagem pelo diagrama acima é uma iteração no processo, mas nem sempre a ordem foi respeitada. Muitas vezes os detalhes de implementação, por exemplo, faziam necessárias as alterações nos diagramas UML. Outras vezes, a necessidade de que a nova versão do sistema entrasse logo em produção faziam com que a documentação fosse deixada para mais tarde. Na prática, muitas vezes não é possível respeitar a teoria do modelo ideal de desenvolvimento.

Problema: Permitir a adição de binários de sistemas externos após fechamento de baselines.

Este problema surgiu quando percebemos que, ao cadastrar um sistema externo, nem sempre tinhamos o arquivo pronto em mãos. Era necessário poder alterar uma baseline para incluir ou alterar o arquivo dela a qualquer momento.

Este problema, apesar de simples, exigiu o aprendizado de todo o funcionamento do sistema. O aprendizado incluiu configurações do ambiente de desenvolvimento, de produção e de testes. Ainda, aprender os detalhes de implementação na camada web, de negócio e particularidade do framework de testes, aprimorar o conhecimento de componentes como Struts, Ant, Hibernate, dentre outros.

Para a implementação em particular, foi necessário aprofundar o conhecimento sobre os mecanismos de Stream de Arquivos, Servlets, e o sistema de transação de arquivos e como ele atua sobre o FileSystem.

Problema: Possibilitar a alteração de nomes de baselines.

Como o BLS se apoiava no conceito de que baselines são imutáveis, era impossível alterar qualquer informação de uma baseline. O sistema estava muito rigoroso! O processo de cadastro não estava flexível, e um erro ou desatenção ao cadastrar dados no BLS não parecia ser muito tolerado. O banco de dados ficaria"sujo" com tais erros. Este novo requisito permitiria ao gerente de configuração mudar, por exemplo, o nome de uma baseline juntamente com seu arquivo, e portanto assim ajustá-la conforme a necessidade.

Esta iteração foi a mais simples de todas.

Problema: Possibilitar remoção de baseline/branch/sistema.

Conforme o BLS foi sendo utilizado, fazia-se necessário o desenvolvimento da remoção da baselines, ou branchs ou sistemas. Isto porque, como em qualquer sistema de cadastro, erros acontecem, e mudanças imprevistas surgem. Este problema já saía da trivialidade, e aqui os conceitos utilizados na implementação batiam de frente com os novos requisitos.

Um sistema possui um ou mais branchs. Cada branch possui zero ou mais baselines. Para apagar uma baseline, bastava que ninguém dependesse dela. Para apagar um branch, bastava que ninguém dependesse de nenhuma baseline deste branch. E por fim, para apagar um sistema, era necessário que ninguém dependesse de nenhuma baseline de nenhum de seus branchs.

Pro exemplo, esta etapa envolveu adaptar o sistema de transação sobre arquivos. Se estamos apagando um sistema, e estamos apagando a terceira baseline dele e ocorre um erro. Como voltar atrás se já apagamos o arquivo? Particularidades do próprio FileSystem também dificultaram esta tarefa.

No que diz respeito a entidades, os mecanismos do Hibernate juntamente com o uso do XDoclet e Ant facilitaram muito a tarefa de implementação.

Problema: O sistema deve ser capaz de gerar o arquivo de dependências trazendo todas as dependências de primeiro nível, e podendo ignorar certos tipos de dependências dos demais níveis.

Para poder começar a utilizar o BLS ainda faltava mais uma alteração. O arquivo de dependências não diferenciava tipos de dependências. Como faríamos para dividir as dependências em sua pasta correta no workspace? Ainda, nem sempre precisávamos de todos os niveis de dependência, ou então precisávamos só de alguns tipos de dependência.

Nesta iteração foi implementado uma maneira mais flexível na obtenção do arquivo de dependências de um projeto, com filtros de níveis na árvore de dependências e filtros para tipos de dependência.

Problema: O sistema deve ser capaz de adicionar ou remover dependência de baseline (novas inconsistências)

O BLS estava finalmente em uso. Mas ainda, havia um ponto que poderia fazer dele uma ferramenta mais ágil. Permitir poderes plenos a quem fosse o gerente de configuração projeto, e portanto, poder adicionar ou remover dependências a baselines.

Esta iteração foi a maior e mais trabalhosa de todas. Novas dependências em baselines exigiram novas verificações por inconsistências, novas maneiras de percorrer o grafo. Na apresentação, novos maneiras de mostrar inconsistências e novas telas tiveram de ser implementadas. (Ver ítem "Verificação por inconsistências")

Segunda Parte

Objetivos, Desafios e Frustrações

Tudo começou quando eu cursava Engenharia Mecânica e tive uma aula de programação. Eu simplesmente adorei aquela matéria, e percebi que eu gostava muito de computação. Quando entrei na USP eu comecei a trabalhar com alguns amigos, desenvolvendo pequenos sistemas e jogos para a Internet. A satisfação de ver seu próprio trabalho sendo utilizado e reconhecido é muito grande. Percebi que eu gostava de desenvolver sistemas. Algumas decepções me ensinaram valiosas lições sobre o mercado. Quando entrei na Touch, me deparei com o novo mundo e uma nova visão de todo o processo de desenvolvimento de sistemas. A vontade de aprender novas tecnologias mais poderosas e robustas, os novos conceitos e tudo mais envolvido tomaram conta de mim. É muito bom poder dizer que hoje eu gosto muito do que faço. Meu objetivo é seguir neste ramo indefinidamente.

Só depois do estágio, meu curso no IME, até então levado com certa indiferença começou a fazer muito mais sentido, e as matérias começaram a se mostrar mais úteis na vida prática. Mas a carga horária acabou ficando um tanto quanto pesada. Por um lado é muito bom poder estudar matérias na faculdade que te dão uma boa base formal para o trabalho, mas ao mesmo tempo, é muito ruim você não ter tempo para se dedicar totalmente a nenhum dos dois. Uma frustração é não ter dado tanta atenção ao curso antes. O desafio foi correr atrás do prejuízo e conseguir conciliar as duas atividades.

Lista das disciplinas cursadas no BCC mais relevantes para o estágio

Disciplina	Nome	Comentários
MAC110	Introdução à Computação	Foi onde solidifiquei os fundamentos básicos de programação e tive o primeiro contato com a linguagem C.
MAC122	Princípios de Desenvolvimento de Algoritmos	Praticamente continuando MAC110, me ensinou novos conceitos, não mais tão básicos.
MAC323	Estrutura de Dados	Uma disciplina imprescindível. O conhecimento dos fundamentos de estrutura de dados é totalmente fundamental em muitas partes da implementação.
MAC211	Laboratório de Programação	Primeiro contato com UNIX e expressões regulares.
MAC242	Laboratório de Programação II	Meu primeiro contato com Java e programação orientada a objetos e Perl.
MAC426	Sistemas de Banco de Dados	Aprendi fundamentos de modelagem de banco de dados e da linguagem SQL.
MAC332	Engenharia de Software	Me deu a base do processos de desenvolvimento de software. Extremamente relevante para o estágio.
MAC328	Algoritmos em Grafos	Muito importante na participação do BLS
MAC413	Tópicos de Programação Orientada a Objetos	Aprendi muito com os Design Patterns, e com as atividades de modelagem de sistemas.

Interação com membros da equipe que tenham agido como mentores do trabalho

Em todo o processo, sempre tive o apoio de toda a equipe da Touch. Mas os grandes mentores de meu trabalho foram o Rodrigo Couto e Paulo Tamaki, que estavam sempre prontos a sanar qualquer possível dúvida e me ensinar o que fosse necessário. Foram eles os primeiros desenvolvedores, e "pais" do BLS.

Diferenças notadas entre a forma de cooperação com colegas do BCC nas tarefas em grupo das disciplinas e a forma de trabalho conjunto na empresa

Em matéria de cooperação posso dizer que não há muita diferença na maneira de realizar uma tarefa com colegas do BCC e na empresa. Talvez porque muitas pessoas da empresa sejam também do BCC.

Observações sobre a aplicação de conceitos estudados nos cursos no contexto prático de aplicações reais

Fica muito destacado para mim a importância do pensamento formal que aprendemos a ter no curso, com a aplicação real encontradas na empresa. Por exemplo, uma boa implementação vai gerar menos esforços de correções, maior facilidade de manutenção e muitas vezes, melhor desempenho do algoritmo.

Se o aluno fosse continuar atuando na área em que exerceu o estágio, que passos tomaria para aprimorar os conhecimentos técnicos/metodológicos/comerciais/científicos/etc relevantes para esta atividade?

Pretendo sim continuar atuando nesta área em que exerci o estágio. Para aprimorar o conhecimentos, acho importante a realização de cursos profissionalizantes, a leitura constante de literatura relacionada, e estar constantemente atualizado com informações de novas tecnologias e métodos de desenvolvimento.

Referências

[1] Instituto de Matemática e Estatística da USP
http://www.ime.usp.br

[2] Diagnósticos da América
http://www.diagnosticosdaamerica.com.br

[3] Rational Unified Process
http://en.wikipedia.org/wiki/Rational_Unified_Process

[4] CVS
http://en.wikipedia.org/wiki/Concurrent_Versions_System

[5] Cruisecontrol
http://cruisecontrol.sourceforge.net/

[6] Java 2 Platform, Enterprise Edition (J2EE)
http://java.sun.com/j2ee

[7] The Apache Struts Web Application Framework
http://jakarta.apache.org/struts

[8] The Apache Ant Project
http://ant.apache.org

[9] XML / XSL
http://xml.apache.org/

[10] JUnit
http://www.junit.org

[11] Jakarta Tomcat
http://jakarta.apache.org/tomcat

[12] Design Patterns - Elements of Reusable Object-Oriented Software
Editora Addison-Wesley : Erich Gamma, Richard Helm, Ralph Johnson , John Vlissides

Agradecimentos

Gostaria de agradecer primeiramente aos meus pais por sempre me apoiarem e acreditarem em mim. Aos meus irmãos e toda minha família. Aos meus colegas de BCC, que foram ótimos companheiros nesta jornada. Aos colegas da Touch, em especial Rodrigo Couto e Paulo Tamaki pela orientação. Ao meu chefe Ricardo Auriemo. Ao meu Tricolor querido do coração, que me trouxe tanta alegria este ano. E abraços especiais aos amigos Marcão, Dzik, Sergio, Té, Telles, Rogério, Varas, Dubs e outros todos que me ajudaram nos momentos de descontração (esse ano foi puxado!). Ao time de futebol e handebol do IME. Aos amigos Pedro, Maitê e Karen. E por fim, a todos do Intersítios. Obrigado.

sf