AgileAndArt

The Art Improving Agile Software Development

Browsing Posts published by Daniel Cukier

This article is originally published in the ACM Digital Library for the ONWARD ’11 Proceedings of the 10th SIGPLAN symposium on New ideas, new paradigms, and reflections on programming and software. I’d like to specially thank the co-author and friend Joe Yoder and Richard P. Gabriel for all patience and good advices with this work.

PLoP Portland História

Em agosto de 1993, Kent Beck e Grady Booch patrocinaram um retiro na montanha, onde um grupo de pessoas chegou a um consenso sobre os fundamentos em padrões de software. Ward Cunningham, Ralph Johnson, Ken Auer, Hal Hildebrand, Grady Booch, Kent Beck e Jim Coplien se basearam fortemente nas ideias de Alexander e suas próprias experiências, formando um casamento entre objetos e padrões. O grupo concordou que estávamos prontos para construir, sobre as fundações do trabalho de Erich Gamma sobre padrões orientados a objetos, e usar esses padrões da mesma forma que Christopher Alexander usa seus padrões para planejamento urbano e construções arquitetônicas. O encontro do grupo se deu ao lado (side) de um monte (hill), daí o nome Hillside.

Desde então, o Hillside Group se tornou uma organização educacional sem fins lucrativos, que patrocinou e ajudou a organizar várias conferências (Plop Conference, EuroPlop, ChiliPlop, KoalaPlop, Mensore PLoP, SugarloafPLoP, e UP97), além de ter sido responsável pela edição e publicação da série de livros “Pattern Languages Of Program Design”.

A conferência

Os eventos do PLoP são encontros bastante diferentes das conferências tradicionais que estamos acostumados. Normalmente, quando vamos a uma conferência, ficamos quase o dia todo assistindo palestras, normalmente ministradas por pessoas com bastante experiência. Nesses eventos, temos poucas oportunidades de conhecer e conversar com os outros. Isso até acontece, mas quase sempre de forma rápida e superficial.

Já no PLoP, a interação entre os participantes é bastante intensa e rica. Normalmente o evento dura 3 dias,Lunchtime durante os quais você realmente conhece as pessoas que estão lá. As refeições e o hotel já fazem parte do pacote do preço da conferência, então você acaba tomando café, almoçando e jantando com esse grupo. Como consequência disso, temos a oportunidade de manter conversas longas e produtivas com os participantes.

Além das refeições fartas e deliciosas, o PLoP também inclui várias dinâmicas e jogos em grupos (games), cujo objetivo é aproximar os participantes, motivando e estreitando as relações pessoas entre todos. Os jogos são sempre divertidos, engraçados, tornando o ambiente mais seguro, informal e, principalmente criativo. Pode parecer um detalhe, mas esses jogos são fundamentais para o sucesso e

PLoP Portland

qualidade do evento.

Design Patterns (Padrões de projeto) – meio óbvio né… :-) Os assuntos que discutimos são quase sempre relacionados com desenvolvimento de software, com foco principal em padrões. Poucos desenvolvedores se dão conta, mas boa parte do que conhecemos sobre técnicas e boas práticas em desenvolvimento de software vieram de alguma maneira da comunidade de padrões. Apenas para citar alguns exemplos:

Submissão dos artigos

Para participar do PLoP, é preciso submeter para a conferência, alguns meses antes, uma proposta de artigo. Se o seu artigo estiver num nível que considerado adequado pelos avaliadores, você é aceito para o chamado processo de shepherding. O termo shepherd em inglês significa pastor – a ideia é que você será conduzido por um “mestre” no processo de escrita do seu artigo. Para cada autor, são escolhidos 1 ou 2 shepherds, que lerão o artigo atentamente e farão várias sugestões de melhoria.

Meeting room Esse processo dura em torno de dois ou três meses. Durante esse tempo, você troca várias mensagens com os shepherds, mandando novas versões melhoradas do artigo. No meu caso, foram 4 iterações. O artigo que eu escrevi era sobre quatro novos padrões para introduzir novas ideias. Minha ideia era adicionar novos padrões ao catálogo original da Linda Rising e Mary Lynn Manns (livro Fearless Change). O artigo era uma evolução da minha tese de mestrado.

Ninguém melhor do que as próprias Linda e Mary Lynn para me ajudarem a escrever esses padrões, por isso elas foram escolhidas como minhas shepherds. A ajuda que obtive delas foi incrível, o que me possibilitou ter um artigo num nível adequado para ser aceito para a conferência. Após o processo de shepherding, você precisa enviar o artigo novamente para avaliação. Novamente, os avaliadores lêem o artigo e decidem se ele é adequado para ser trabalhado na conferência, num processo que eles chamam de Writers Workshop.

Writers Workshop

Writers Workshop O “carro chefe” das conferências PLoP são o que chamamos de Writers Workshop (Oficina dos Escritores). O conceito surgiu em comunidades de poetas, que se encontravam frequentemente para debater e aprimorar suas poesias. A dinâmica do Writers Workshop consiste na troca de experiência entre vários autores. Quem trouxe essa ideia para o mundo da computação foi o cientista Richard P. Gabriel. Ele escreveu um livro sobre o assunto, descrevendo detalhadamente como conduzir a oficina.

Funciona basicamente assim: vários autores de artigos formam um grupo (normalmente de umas 10 pessoas). Durante os três dias do PLoP, esse grupo se encontra várias vezes. Em cada encontro eles escolhem um dos artigos para aprimorar. O autor do artigo deve obrigatoriamente estar presente, mas seu papel é apenas de ouvinte. Os outros fazem comentários, dando sugestões positivas e práticas de como melhorar o artigo. O autor anota essas considerações, para posteriormente aplicá-las a uma nova versão do artigo.

Writers Workshop

Uma regra importante na oficina é a de que o artigo tem que falar por si só, ou seja, o autor não pode ficar dando explicações para os outros de coisas que deveriam estar claras no artigo. Se posteriormente alguém for ler o seu artigo, você não estará presente para dar suas explicações. Por isso, é importante que todas as ideias que você quer transmitir estejam claras no artigo.

No final, o resultado extremamente satisfatório. O objetivo da comunidade de padrões é criar uma vasta literatura sobre soluções de problemas, que se mostraram eficazes em alguns contextos e que podem servir de guia para que outros apliquem as mesmas soluções e obtenham sucesso em seus projetos. Normalmente um padrão não é algo cabulosamente complicado, mas sim coisas simples, porém muito poderosas se aplicadas corretamente. Um fator importante que torna um padrão poderoso é a forma como ele é documentado. Autores de padrões devem tomar o cuidado de documentar muito bem um novo padrão, de maneira que ele seja amplamente compreendido. O Writers Workshop é fundamental para que texto final de um padrão seja lapidado ao extremo, tornando conciso, objetivo, prático e eficaz.

Minha participação

Man in the mirror

Nesse ano, eu participei do PLoP como autor de um artigo junto com o Professor Fabio Kon. O líder do meu grupo no Writers Workshop foi o próprio Richard Gabriel, ou seja, o cara que inventou a oficina! Foi uma surpresa maravilhosa tê-lo como um dos conselheiros para o meu artigo. Além do Richard, outros 6 autores faziam parte do grupo e ouvi comentários extremamente positivos e importantes para melhorar o artigo.

Para aqueles que tiverem interesse, podem ler a versão preliminar do artigo aqui. Durante os próximos meses, trabalharei para incorporar as sugestões obtidas na oficina de escritores. Essa nova versão será enviada para os organizadores da conferência, que farão uma avaliação final e, caso o artigo esteja satisfatório, será publicado na biblioteca digital da ACM.

Veja outras fotos do PLoP 2011

Man in the mirror Leaves on the floor PLoP Dinner PLoP Dinner PLoP Dinner PLoP Dinner PLoP Dinner PLoP Dinner Breakfast Breakfast PLoP Portland PLoP Portland Breakfast PLoP Portland Breakfast Games Games Games Games Cleaning the window Ralph Johnson Ralph Johnson PLoP Portland PLoP Portland PLoP Portland PLoP Portland Audience Richard Gabriel Writers Workshop Meeting room Hot Chocolate Hot Chocolate Lunchtime Lunchtime Games Writers Workshop Portland Halloween PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland PLoP Portland Retrospective Portland Skyline Portland Skyline

OOPSLA

Em 1985, um grupo de 4 pioneiros em programação orientada a objetos decidiu organizar nos EUA uma conferência sobre programação de sistemas orientados a objetos. No grupo estavam Adele Goldberg, Tom Love, David Smith, and Allen Wirfs-Brock, e a conferência foi chamada de OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications). A primeira OOPSLA aconteceu no Hotel Marriott, em Portland, Oregon, em novembro de 1986. Cerca de 600 pessoas participaram, 50 artigos foram apresentados e os participantes ouviram sobre Smalltalk, Lisp, Flavors, CommonLoops, Emerald, Trellis/Owl, Mach, Prolog, ABCL/1, prototypes, e programação concorrente e distribuída de pessoas como Danny Bobrow, Gregor Kiczales, Rick Rashid, Andrew Black, Dave Ungar, Henry Lieberman, Ralph Johnson, Dan Ingalls, Ward Cunningham, Kent Beck, Ivar Jacobson e Bertrand Meyer.

Essa gama enorme de tópicos e pesquisadores definiu o tom da conferência, que se tornou forum para alguns dos principais desenvolvimentos de software das últimas duas décadas. Foi na OOPSLA que nasceram coisas como cartões CRC, CLOS, Padrões de Projeto (Design Patterns, Self, métodos ágeis, arquiteturas orientadas a serviço (SOA), wikis, UML, TDD, refatoração, Java, compilação dinâmica, programação orientada a aspectos, só para citar algumas delas. Nem sempre falando sobre objetos, mas nunca deixando o assunto de lado, a conferência cresceu de 600 para 2500 participantes no seu pico, sendo ainda forte com cerca de 1300 pessoas mesmo depois do surgimento de uma série de conferências sobre padrões, Eclipse, EclipseCon, Agile e AOSD.

No final dos anos 90 – com o sucesso de Smalltalk e Java nos negócios e C++ na engenharia – OO se tornou amplamente adotada e a OOPSLA mudou de uma conferência que trabalhava para tornar OO prático e compreensível para trabalhar nos problemas do mundo sempre mutante da computação, tanto na inventando novas técnicas e tecnologias quanto melhorando e expandindo teorias. O que permaneceu foi a paixão por inovação e o hábito de criar comunidades.

Onward!

No começo dos anos 2000, algumas pessoas da OOPSLA sentiram que a conferência se beneficiaria muito se fosse criada uma nova trilha de publicação de artigos focados em ideias inovadoras além de OO, e em formatos de artigos que normalmente não seriam aceitos na OOPSLA. Nasce então a Onward!, coordenada por Richard Gabriel. Onward! foi a primeira conferência patrocinada pela ACM a dar voz a “artigos ideias” no âmbito da aceitação acadêmica. Muitas outras conferências seguiram esse modelo depois.

SPLASH

Na metade dos anos 2000, ficou claro que a estrutura de organização da OOPSLA e Onward jutas precisavam ser refatoradas, não apenas para que ambas existissem ao mesmo tempo, mas também para fornecer a possibilidade de incluir novas trilhas de artigos, mantendo a conferência nova e moderna. Depois de vários debates entre as comunidades, ficou finalmente decidido criar um guarda-chuvas de conferências: assim nasceu a SPLASH, a conferência da ACM em Sistemas, Programação, Linguages e Aplicações: Software para a Humanidade.

Desde 2010, a SPLASH tem mantido e administrado a OOPSLA, Onward! e uma variedade de outros eventos, como o Simpósio de Educadores, Workshop de Experiências, Painéis, etc. OOPSLA é hoje “apenas” a trilha técnica de artigos de pesquisa de alta-qualidade, que foi desde o início o coração desse conferência. Ao mesmo tempo, a OOSPLA aumentou o escopo de tópicos muito além de OO, aceitando hoje uma enorme variedade de artigos relacionados a programação. Ao criar a SPLASH como um guarda-chuvas de conferências, a comunidade pode agora sustentar novas trilhas de artigos que eventualmente não cabem na OOPSLA, mas que ainda sim são relacionados. Assim, permite-se o espaço para inovação, assim como aconteceu com a Onward!

E eu com isso?

Esse ano (2011), eu terei o privilégio de participar da SPLASH pela primeira vez (algo que eu já gostaria de ter feito há bastante tempo :-)

A SPLASH tem um programa de Estudantes Voluntários, onde nós, estudantes, podemos participar da conferência de graça em troca de algumas horas de trabalho para ajudar na organização. Eu me inscrevi nesse programa de estudantes voluntários e fui aceito.

Além disso, eu tive dois artigos aceitos: um na Onward! e outro na PLoP (outra conferência que faz parte do guarda-chuvas da SPLASH). Para esses dois artigos, participarei do que eles chamam de Writers Workshop (Workshop de Escritores). O objetivo é trabalhar durante várias horas junto com os maiores (acreditem, são os maiores mesmo!) especialistas da área e anotar sugestões de melhorias para os artigos, que posteriormente farão parte das publicações científicas da conferência. Acima de tudo, é uma oportunidade maravilhosa de aprender muito e conhecer muita gente legal.

Depois que os artigos ficarem prontos (e bem melhorados após os comentários das pessoas na conferência) eu publico aqui nesse Blog.

Próximos passos

Ao longo da próxima semana, farei (na medida do possível :-) alguns posts aqui nesse blog contando um pouco mais sobre essa conferência incrível. Farei, como de costume, várias fotos e, talvez, alguns vídeos. Dessa forma, consigo compartilhar um pouquinho dessa experiência quem não pôde ir desta vez!

Venha fazer doutorado e mestrado no IME-USP!!! Veja as informações abaixo:

As inscrições para o mestrado em  Ciência da Computação no IME/USP (campus de São Paulo, capital) vão até 31 de outubro de 2011 (data de postagem dos documentos). As inscrições para o doutorado são aceitas em fluxo contínuo.

PÓS-GRADUAÇÃO no IME-USP
DOUTORADO E MESTRADO EM CIÊNCIA DA COMPUTAÇÃO
UNIVERSIDADE DE SÃO PAULO

Informações gerais sobre o programa de pós-graduação:

http://www.ime.usp.br/dcc/posgrad

Informações sobre o processo seletivo podem ser encontradas em:

http://www.ime.usp.br/dcc/posgrad/selecao

As principais áreas de pesquisa do Departamento de Ciência da
Computação do IME-USP são as seguintes:

* Banco de Dados
* Bioinformática
* Combinatória
* Computação em Nuvem e Serviços Web
* Computação Gráfica
* Computação Paralela
* Computação Musical
* Criptografia
* Engenharia de Software
* Inteligência Artificial
* Lógica Computacional
* Otimização Combinatória
* Otimização Contínua
* Pesquisa Operacional
* Processamento de Imagens
* Reconhecimento de Padrões
* Redes de Computadores
* Sistemas Distribuídos
* Sistemas Colaborativos
* Sistemas Tutores Inteligentes
* Software Livre
* Teoria dos Autômatos
* Teoria dos Grafos
* Visão Computacional

Para mais informações, entrem em contato com a secretaria de pós-graduação:

Telefone: (+55 11) 3091-6122
Fax: (+55 11) 3091-6200
E-mail: cpg@ime.usp.br

Há quase 1 ano, eu publiquei aqui um artigo prevendo como seria a evolução do Facebook e do Orkut no Brasil. O artigo mostrava que em quase todos os países do mundo o Facebook desbancou o Orkut e o Brasil era um dos poucos lugares onde o Orkut ainda dominava. Eu fiz a seguinte previsão no final do artigo:

"Vou dar um chute para a virada acontecer: setembro de 2011."

Pois bem, acabamos de passar setembro e chegou a hora da verdade. Vejam o gráfico:

Parece que em julho de 2011 o Facebook ultrapassou o Orkut. Se olharmos o gráfico mais de perto, considerando apenas o último ano, observem:

Parece que houve uma pequena recuperação do Orkut nas últimas semanas, mas não acho que isso seja significativo. Se vocês repararem bem no primeiro gráfico, todo final de ano existe um pico de utilização do Orkut (não sei bem porque, mas isso ocorre). Vamos continuar observando, mas acho que ficou claro que o Facebook vai continuar aumentando a vantagem. Sabemos também que o Google lançou recentemente o Google+, possível novo concorrente para o Facebook. Ainda é muito cedo para saber se o Google+ vai realmente ser páreo para o Face. Olhando no trends, ele ainda não faz nem cócegas!

MiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilEduardo GuerraFabio KonMiniPLoP Brasil
MiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilMiniPLoP Brasil
MiniPLoP BrasilMiniPLoP BrasilJoe Yoder and Brian FooteMiniPLoP BrasilMiniPLoP BrasilMiniPLoP Brasil
MiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilMiniPLoP BrasilMiniPLoP Brasil

MiniPLoP Brasil, a set on Flickr.

It was a great event! For more information about miniPLoP, check the event website: http://www.miniplop.ita.br/Apresentacao.html

Acabei de voltar de uma exposição lindíssima que está acontecendo no SESC Vila Mariana em São Paulo. O nome é “Pedaços da Terra“. Vale muito a pena dar uma conferida! Parece que ela foi feita especialmente (mas não somente) para um público como nós, Geeks, que temos tecnologia correndo nas veias. Vocês vão se surpreender com o que verão lá.

Exposição com cunho lúdico-didático que proporcionará o estímulo à consciência crítica em relação às práticas de sustentabilidade com um foco específico sobre o reino mineral, com vistas à preservação do meio ambiente e dos recursos naturais. Através de informações e conceitos relativos ao impacto ambiental da extração de recursos minerais para a elaboração de equipamentos tecnológicos eletro-eletrônicos, Pedaços da Terra pretende aproximar o público do processo de manufatura desses equipamentos, que envolve um ciclo de produção desde a extração do minério até o produto final. Desse modo, este projeto pretende fornecer informações e conceitos sobre a importância do consumo consciente (+ qualidade / – quantidade), a reutilização de equipamentos tecnológicos e o encaminhamento para reciclagem, tendo como objetivo minimizar os impactos ambientais.

No módulo Retrato do Planeta, uma tabela periódica interativa destaca os elementos químicos que compõem os equipamentos eletrônicos. Nos mosaico de matérias primas, curiosidades da geologia e dos minérios. Ainda neste módulo, mapas gigantes ilustram para o público as principais fontes de riquezas minerais e a exploração delas pelo mercado tecnológico.

Fiz um vídeo convite de 6 minutos, dando uma palhinha do que vocês verão lá. Confiram!

Nesse vídeo eu mostro as principais vantagens do uso de Injeção de Dependência e Testes com Dublês (Stubs, Mocks, Fake Objects, Spy, Dummy Objects).

Vídeo

Slides

Transcrição

Injeção de Dependência e Testes com Dublês

  1. Conteúdo• Exemplo• Injeção de Dependência (DI)• Testes com Dublês (Doubles)
  2. Exemplo
  3. Continuando o Exemplo• Criando interface
  4. Dependência• PhoneLister depende da interface e da implementação• Como depender somente da interface?
  5. Idéia Básica – Injeção Injeção Framework Injeção de Dependência
  6. Tipos de Injeção• Injeção Por Construtor
  7. XML
  8. Usando na aplicação
  9. Fábrica de Objetos• Singleton – Instância única compartilhada do objeto – Uso padrão, mais comum – Objetos de serviço sem estado (stateless)• Protótipos – Cada chamada cria um novo objeto• Escopos de Objetos Customizados – Objetos armazenados fora do controle do container (ex: request, session em uma aplicação Web)
  10. Fábrica de Objetos
  11. Vantagens de usar Injeção de Dependência• Ajuda a escrever código que é fácil de testar: é só criar objetos e atribuir as propriedades desejadas usando os setters• Facilita boas práticas de programação: uso de interfaces no lugar de classes• Não envasivo: o código do sistema depende o mínimo possível da API do Framework• Dependências são explícitas e evidentes• Como os componentes não precisam procurar colaboradores em tempo de execução, o código fica mais fácil de escrever e manter
  12. Frameworks para todas as linguagens• Java – Spring, PicoContainer, HiveMind• PHP – DIContainer• .NET – Spring.NET, PicoContainer.NET• Python – PyContainer, Spring Python• Ruby – Needle• Perl – IOC Module• Flex – Flicc• mais em http://en.wikipedia.org/wiki/Dependency_injection
  13. DI – Linha do Tempo
  14. Construtor ou Setter?• Construtor com parâmetros deixa claro o que é preciso para criar o objeto• Usando construtor evita campos imutáveis de serem alterados• Cuidado: construtores com muitos parâmetros podem ser um indicativo de objeto com responsabilidades demais• Construtor é ruim se tiver parâmetros simples como Strings: com setter você cria um método que identifica o que a string significa• Receita geral: comece com construtor e mude para setter se a coisa ficar complicada demais
  15. Testes com Dublês (Doubles) DoubleDummy Stub Spy Mock FakeObject
  16. Dummy Object• Objetos que nunca são usados, só servem para preencher parâmetros
  17. Stub• Provê alguns dados estáticos que serão usados nos testes• Não funciona para outras coisas além do que está no teste
  18. Spy• Muito parecido com Stub, mas com a diferença de que “grava” algumas coisas
  19. O que são Mock Objects? Years later, Mock objects are still quite controversial, often misused and sometimes misunderstood. “Pintside Thoughts: Mock Objects History” —Tim McKinnon
  20. O que são Mock Objects?• Cada pessoa entende de um jeito diferente• Terminologia ambígua• Ficou famoso inicialmente na comunidade JAVA & TDD Comportamento Estado testa interação entre testa o resultado dessas objetos interações
  21. Código Mock
  22. Fake Object• Têm uma implementação completa, mas simples• Não vai para produção• Exemplo: banco de dados em memória 23
  23. Mocks nas Linguagens• Java – EasyMock, JMock, Mockito• Ruby – Mocha, RSpec?• .NET – NMock, Rhino Mocks• Perl – Test::MockObjects• C++ – Google Mocks• PHP – Simple Test for PHP
  24. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Preenche parâmetros
  25. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Preenche dados para parâmetros os testes
  26. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Preenche dados para dados eparâmetros os testes grava
  27. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Preenche dados para dados e comporta-parâmetros os testes grava mentos
  28. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Implemen- Preenche dados para dados e comporta- taçãoparâmetros os testes grava mentos +simples
  29. QuizDublês + Injeção de Dependência = Testes
  30. Referências
    http://www.springframework.org/documentation
    http://martinfowler.com/articles/injection.html
    http://martinfowler.com/articles/mocksArentStubs.html
    http://xunitpatterns.com/
    Anil Hemrajani, Agile Java Development with Spring, Hibernate and Eclipse
MiniPLoP

MiniPLoP 2011

Software developers have long observed that certain patterns recur and endure across different applications and systems. The growing interest in Design Patterns, Architectural Patterns, Analysis Patterns, Pedagogical Patterns, and so on, represents an effort to catalog and better communicate knowledge, providing handbooks of proven solutions to common problems.

MiniPLoP brings together researchers, educators, and practitioners whose interests span a remarkably broad range of topics and who share an interest in exploring the power of the pattern form. MiniPLoP invites you to add your expertise to the growing corpus of patterns. MiniPLoP focuses on improving the expression of patterns. You will have the opportunity to refine and extend your patterns with the help from knowledgeable and sympathetic fellow pattern enthusiasts. You will also be able to discuss applications of patterns in industry and academia.

Highlights of the conference include an international tutorial, an introduction to pattern writing, an international keynote, and the writer’s workshops.

This version of MiniPLoP has the goal to encourage the beginners in the pattern world and to put together the Latin-american pattern community. The MiniPLoP program will accept submissions for the Writers’ Workshop (WW) track. The papers should document patterns and pattern languages and they will be workshopped in the traditional PLoP format.

Visit the event website

General Chairs

Eduardo Martins Guerra (ITA, Brasil)

Fabio Kon (IME/USP, Brasil)

Program Co-chairs

Claudio Sant’Anna (UFBA, Brasil)

Joseph W. Yoder (U. Illinois/The Refactory, Inc, USA)

Local Organization

Allan Machado da Silva (ITA, Brasil)

Carlos Eduardo Moreira dos Santos (IME/USP, Brasil)

Daniel Cukier (IME/USP, Brasil)

José Roberto Campos Perillo (ITA, Brasil)

Jefferson de Oliveira Silva (ITA, Brasil)

Program Committee

Ademar Aguiar (INESC Porto/University of Porto, Portugal)

Brian Foote (Industrial Logic, Inc, USA)

Eduardo Guerra (ITA, Brazil)

Filipe Correia (Porto University, Portugal)

Gustavo H. Rossi (Lifia/UNLP, Argentina)

Hugo Sereno Ferreira (INESC Porto/University of Porto, Portugal)

Jerffeson Teixeira de Souza (UECE, Brazil)

Linda Rising (Independent Consultant, USA)

Lise Hvatum (Schlumberger, USA)

Tiago Massoni (DSC/UFCG, Brazil)

Rebecca Wirfs-Brock (Wirfs-Brock Associates, USA)

Richard Gabriel (IBM Research, USA)

Roberta Coelho (DIMAp/UFRN, Brazil)

Rohit Gueyi (DSC/UFCG, Brazil)

Rosana Braga (ICMC/USP, Brazil)

Rossana Andrade (DC/UFC, Brazil)

Sergio Soares (CIn/UFPE, Brazil)

Uirá Kulesza (DIMAP/UFRN, Brazil)

Additional Shepherds

Daniel Cukier (IME/USP, Brasil)

Jefferson de Oliveira Silva (ITA, Brasil)

Tarciane Andrade (UECE, Brasil)

 
Utilizando a Linguagem Ubíqua criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design – MDD). A idéia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo. Só aparece no modelo aquilo que está no negócio.

Em um time que cria software temos de um lado os especialistas de negócio e de outro os desenvolvedores e arquitetos. Num processo ágil defendido pelo MDD a criação do modelo abstrato deve ser feita em grupo, com todas as pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modelers). Se os programadores não se sentirem responsáveis pelo modelo ou não entenderem como o modelo funciona, então o modelo não terá relação alguma com o software produzido por essas pessoas.

O processo de maturação de um sistema desenvolvido usando MDD deve ser contínuo. O modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

Switch to our mobile site