Você está na página 1de 1

Mais Blogue seguinte» Criar blogue Iniciar sessão

Blog do FARIDE TI
Bem vindo(a) a este Blog! Este espaço é para trocarmos conhecimentos sobre boas práticas de
desenvolvimento web focadas em: Engenharia de Software, Métodos Ágeis, Padrões Web, Acessibilidade,
Desenvolvimento, AOO (Análise Orientada a Objeto), Design Patterns e SEO.

quinta-feira, 18 de março de 2010 Inscreva-se


No Silver Bullet (Sem Bala de Prata): Essência e
Acidentes da Engenharia de Software Postagens
O artigo "No Silver Bullet" ("Sem Bala de Prata" ou "Não há
Comentários
Bala de Prata"), escrito por Frederick P. Brooks, Jr, em 1986, discute
sob diversos pontos de vista os problemas e dificuldades encontradas
nos processos de engenharia de software. É incrível como, apesar de Seguidores
ter sido escrito na década de 1980, este texto ainda seja tão atual!

O autor começa seu texto comparando o software ao lobisomem,


dizendo que, de todos os monstros que preenchem os pesadelos de
nosso folclore, nenhum nos aterroriza mais que lobisomens, porque
eles inesperadamente se transformam do familiar ao horrível. Assim,
procuram-se balas de prata que possam magicamente fazê-los
descansar. O projeto de software familiar, pelo menos do ponto de
vista do gerente não técnico, tem algo desta personagem; ele é
normalmente inocente e honesto, mas capaz de se tornar um monstro
de prazos deficientes, orçamentos estourados e produtos falhos.
Surgem então súplicas desesperadas por uma bala de prata – algo
que faça os custos de software cair tão rapidamente quanto os custos Arquivo do blog
de hardware de computador.
► 2013 (1)

► 2011 (2)
Isto Precisa Ser Ouvido?—Dificuldades Essenciais
▼ 2010 (17)
Não há balas de prata em vista, e a própria natureza do software
torna improvável de que haverá alguma. Ou seja, nenhuma invenção ► Outubro (6)
irá fazer pela produtividade, confiança e simplicidade do software o
► Maio (4)
que eletrônicos, transistores e integração em alta escala fizeram pelo
hardware de computador. ► Abril (6)

Primeiro, deve-se observar que a anomalia não é que o progresso do ▼ Março (1)
software seja tão lento, mas que o progresso do hardware de
No Silver Bullet (Sem Bala de
computador seja tão rápido. Em nenhuma outra tecnologia alguém
pode escolher ganhos tanto em melhoria de desempenho quanto em Prata): Essência e A...
custos reduzidos.

Segundo, para ver qual taxa de progresso se pode esperar na ► 2009 (12)
tecnologia de software, devemos examinar as dificuldades daquela
tecnologia. Seguindo Aristóteles, o autor as divide em:

Essência: as dificuldades inerentes na natureza do software.


Acidentes: dificuldades que afetam a produção do software, mas
não são inerentes à sua natureza.
FABRÍCIO OLMO ARID E
A essência de uma entidade do software é a construção de conceitos
engrenados: conjuntos de dados, relacionamentos entre itens de Analista de Sistemas com pós
dados, algoritmos e chamadas de funções. Esta essência é tão
graduado em MIT em Engenharia
abstrata que uma construção conceitual é a mesma sob muitas
representações diferentes. Portanto, é altamente precisa e rica em de Software com Dot Net pelo
detalhes. O autor acredita que a parte mais difícil na construção do Instituto Infnet. Gosto das áreas
software seja a especificação, o projeto e o teste desta construção exatas e, também, de escrever.
conceitual, e não o trabalho de representá-lo e testar a fidelidade da
Tenho 2 blogs: - Blog do Faride -
representação.
posts na área de desenvolvimento
A construção de um software será sempre difícil. Não há nenhuma de software:
bala de prata inerente. Seguem as propriedades inerentes desta http://fabricioaride.blogspot.com -
essência irredutível dos sistemas de software modernos:
Reflexões Refletidas:
Complexidade: as entidades do software talvez sejam mais http://reflexoesrefletidas.blogspot.
complexas para seu tamanho que qualquer outra construção humana com
porque duas partes não são similares (pelo menos acima do nível de
Visualizar meu perfil completo
especificação). Se elas forem similares, criamos as duas partes em
uma sub-rotina – aberta ou fechada. Neste aspecto, sistemas de
software diferem profundamente de computadores, prédios ou
automóveis, onde elementos repetidos abundam.

O escalonamento de uma entidade de software não é meramente a


repetição dos mesmos elementos em tamanhos maiores, mas
necessariamente um aumento no número de elementos diferentes. Na
maioria dos casos, os elementos interagem entre si de forma não
linear, e a complexidade do todo cresce muito mais que linearmente.

A complexidade do software é uma propriedade essencial, não


acidental. Por isso, descrições de uma entidade de software que
abstraem sua complexidade sempre abstraem sua essência.

Muitos dos problemas clássicos no desenvolvimento de produtos de


software derivam desta complexidade essencial e seu aumento não
linear de tamanho. Da complexidade surge dificuldade de
comunicação entre os membros da equipe, o que leva a falhas no
produto, custos exacerbados e atrasos nos prazos estabelecidos. Da
complexidade surge dificuldade de enumerar, muito menos entender
todos os estados do programa e a origem da deficiência. Da
complexidade da função vem dificuldade de chamar a função, o que
torna os programas difíceis de usar. Da complexidade de estrutura
surge dificuldade de estender os programas com novas funções sem
criar efeitos colaterais. Da complexidade de estrutura surgem estados
invisíveis que constituem furos de segurança.

Não somente problemas técnicos, mas também de gerência surgem


da complexidade. Isto dificulta a visão global, além de impedir a
integridade conceitual. Torna difícil encontrar e controlar todos os
pontos deficientes. Cria uma carga tremenda de aprendizagem e
entendimento, o que torna a rotatividade de pessoal um desastre.

Conformidade: Einstein argumentava que deve haver explicações


simplificadas da natureza, porque Deus não é excêntrico ou arbitrário.
Porém, nenhuma fé conforta o engenheiro de software. Grande parte
da complexidade que ele tem que dominar é de caráter arbitrário,
forçada sem uma razão exata por muitas instituições humanas e
sistemas para os quais suas interfaces devem se adaptar. Diferem de
interface para interface e de tempo para tempo, não devido à
necessidade, mas somente porque foram projetados por diferentes
pessoas, em vez de Deus. Em muitos casos, o software deve se
adaptar porque é novo e entrou em cena recentemente. Em outros,
porque é percebido como o mais adaptável. Mas, em todos os casos,
grande parte da complexidade surge da conformidade com outras
interfaces; esta complexidade não pode ser simplificada por qualquer
re-projeto isolado do software.

Mutabilidade: a entidade do software está constantemente sujeita às


pressões por mudanças.
O software, dentro de um sistema, pode ser modificado mais
facilmente – é puramente objeto intelectual, infinitamente maleável.
Todo software de sucesso sofre mudança. Como o produto de software
é feito para ser útil, as pessoas o testam em seu limite ou além do
domínio original. As pressões por função estendida vêm
principalmente dos usuários que apreciam a função básica e inventam
novos usos para a mesma.

Um software de sucesso sobrevive além da vida normal do veículo de


máquina para o qual é primeiramente escrito. Novos computadores,
discos, displays, impressoras surgem e o software deve ser adaptável
a estes dispositivos.

Em suma, o produto de software é incorporado a uma matriz cultural


de aplicações, usuários, leis e veículos de máquina, que estão em
constante mudança e suas mudanças, inexoravelmente, forçam
mudanças no produto de software.

Invisibilidade: o autor defende que o software é invisível e


invisualizável. Abstrações geométricas são ferramentas poderosas,
mas a realidade do software não está incorporada inerentemente ao
espaço. Por isso, não possui uma representação geométrica como, por
exemplo, uma região possui mapas. Assim que tentamos diagramar a
estrutura do software, descobrimos que ela não possui um, mas
muitos gráficos superpostos. Os diversos gráficos podem representar
o relacionamento entre fluxo de controle, fluxo de dados, camadas de
dependência, seqüência de tempo e name-space.

Estes gráficos normalmente não são planos, nem hierárquicos. De


fato, uma das formas de estabelecer um controle conceitual sobre tal
estrutura é forçar o corte de vínculo até que um ou mais gráficos se
tornem hierárquicos.

Apesar do progresso em restringir e simplificar as estruturas do


software, elas permanecem inerentemente invisualizáveis e, por isso,
não permitem à mente usar algumas de suas ferramentas mais
poderosas. Esta carência não somente impede o processo de projeto
dentro de uma mente, mas também dificulta bastante a comunicação
entre mentes.

Progressos do Passado Resolveram Dificuldades Acidentais

O autor defende que, ao examinarmos as três etapas no


desenvolvimento da tecnologia de software que foram mais produtivas
no passado, descobrimos que cada uma atacou uma dificuldade
diferente na construção do software, mas que aquelas dificuldades
foram acidentais, não essenciais.

Linguagens de alto nível: a linha mais poderosa para a


produtividade, confiança, simplicidade e inteligibilidade do software foi
o uso das linguagens de alto nível na programação. A linguagem de
alto nível livra um programa de muitas das suas complexidades
acidentais. Seu maior benefício é fornecer todas as construções que o
programador imagina no programa abstrato. E o desenvolvimento da
linguagem se aproxima cada vez mais da sofisticação dos usuários.

Divisão do tempo (time-sharing): a divisão do tempo trouxe


melhorias principalmente na produtividade dos programadores e na
qualidade de seu produto, mas não tanto quanto as trazidas pelas
linguagens de alto nível. A divisão de tempo preserva o imediatismo
e, por isso, permite manter uma visão geral da complexidade.

Ambientes de programação unificada: Unix e Interlisp, os


primeiros ambientes de programação integrada que chegaram a um
uso abrangente, melhoraram a produtividade pois atacaram as
dificuldades acidentais que resultam do uso de programas individuais
em conjunto, através do fornecimento de bibliotecas integradas,
formatos de arquivo unificados, filtros, entre outros. Como resultado,
estruturas conceituais que, em princípio, poderiam chamar, alimentar
e usar uma outra, podem fazê-lo facilmente na prática.

Esperanças para a Prata

O autor chama o leitor para refletir sobre os desenvolvimentos


técnicos que são avançados como potenciais balas de prata. Quais
problemas eles visam – problemas de essência, ou as dificuldades
acidentais permanentes? Eles oferecem avanços revolucionários, ou
incrementais?

Programação orientada a objeto: o autor mantém mais esperança


em programação orientada a objeto do que em qualquer outra
novidade técnica atual. Mesmo assim, defende que tais avanços não
fazem mais do que remover todas as dificuldades acidentais de
expressão do projeto. A complexidade do projeto por si só é essencial
e estes ataques não trazem nenhuma mudança na mesma.
Inteligência artificial: muitas pessoas esperam avanços na inteligência
artificial para prover o progresso revolucionário que proporcionará
ganhos na ordem de magnitude em produtividade e qualidade de
software. Mas o autor não. Para verificar o porquê, ele dissecar o que
se entende por “Inteligência Artificial”.

D.L. Parnas esclareceu o caos terminológico: [4]

“Duas definições diferentes de IA estão em uso comum atualmente.


IA-1: o uso de computadores para resolver problemas que
anteriormente puderam ser resolvidos somente pela aplicação da
inteligência humana. IA-2: o uso de um conjunto específico de
técnicas de programação conhecidas como heurística ou programação
baseada em regras. Nesta abordagem, experts humanos são
estudados para determinar o que a heurística ou regras eles utilizam
para resolver problemas... O programa é projetado para resolver um
problema da forma que os humanos o resolveriam.”

“A primeira definição possui um significado deslizante... Algo pode se


encaixar na definição da IA-1 atualmente, mas uma vez que vemos
como o programa trabalha e entende o problema, não pensaremos
mais nele como IA... Infelizmente não posso identificar um corpo de
tecnologia que seja único para este campo... A maioria do trabalho é
específica do problema e é necessária alguma abstração ou
criatividade para verificar como transferi-la.”

O autor concorda com esta crítica. Por exemplo, as técnicas usadas


para reconhecimento de fala parecem ter pouco em comum com
aquelas usadas para reconhecimento de imagem e ambas são
diferentes daquelas usadas em sistemas experts. O difícil na
construção do software é decidir o que alguém quer dizer, não
dizendo. Nenhuma facilidade de expressão pode trazer mais que
ganhos marginais.

Sistemas expert: de acordo com o autor, a parte mais avançada da


arte da inteligência artificial, e a mais aplicada, é a tecnologia para
construir sistemas expert. Um sistema expert é um programa que
contém uma máquina de inferência generalizada e uma base de regra,
tem dados de entrada e suposições, explora as inferências deriváveis
da base de regra, fornece conclusões e avisos, além de oferecer
explicações sobre os resultados re-traçando o raciocínio para o
usuário.

O poder destes sistemas vem das bases de conhecimento cada vez


mais ricas, que refletem o mundo real com mais precisão. O autor crê
que o avanço mais importante oferecido pela tecnologia seja a
separação entre a complexidade da aplicação e o programa. Esta
tecnologia pode ser aplicada à engenharia de software de diversas
formas, como: sugestões sobre diferentes regras, avisos sobre
estratégias de teste, alertar sobre as freqüências de tipos de bug e
oferecer dicas de otimização.

A maior contribuição dos sistemas experts será colocar a serviço do


programador inexperiente a experiência e a sabedoria acumulada dos
melhores programadores. E esta contribuição não é pequena. A
lacuna entre a melhor prática de engenharia de software e a prática
média é muito grande – talvez maior que em qualquer outra disciplina
de engenharia. Uma ferramenta que dissemine boas práticas é
importante.

Programação “Automática”: o autor cita Parnas: “Em suma, a


programação automática tem sempre sido mais um eufemismo para a
programação com uma linguagem de alto nível do que os recursos
atualmente disponíveis ao programador.” E conclui que é difícil ver
como esta técnica generaliza para o mundo mais extenso do sistema
de software ordinário, onde casos com propriedades nítidas são
exceções. E também é difícil imaginar como este progresso na
generalização pode ocorrer.

Programação gráfica: o autor diz que, às vezes, o teórico justifica a


abordagem por considerar fluxogramas o meio de projeto de
programa ideal por fornecerem facilidades poderosas para construí-lo.
Mas defende que nada convincente ainda surgiu destes esforços e crê
que não surgirá, pois vê o fluxograma como uma abstração muito
pobre da estrutura do software e as telas da época eram muito
pequenas, em pixels, para mostrar tanto o escopo quanto a resolução
de qualquer diagrama de software detalhado. E conclui que, mais
fundamentalmente, é muito difícil visualizar o software.

Verificação do programa: o autor não acredita em grandes mágicas


em produtividade com este recurso. A verificação do programa é um
conceito poderoso, mas não promete poupar tanto trabalho. Embora
verificação possa reduzir a carga de teste de programa, não pode
eliminá-la. Indo além, mesmo uma verificação perfeita do programa
pode somente confirmar que o programa atende às suas
especificações. A parte mais difícil da tarefa de software é chegar a
uma especificação completa e muito da essência de um programa é,
na verdade, debugar a especificação.

Ambientes e ferramentas: o autor diz que editores inteligentes


específicos de linguagem são desenvolvimentos ainda não utilizados
amplamente na prática, mas prometem principalmente resolver
problemas de sintaxe e erros simples de semântica. Talvez o maior
ganho dos ambientes de programação ainda seja o uso de sistemas
de banco de dados integrados para acompanhamento dos inúmeros
detalhes que devem ser recuperados apropriadamente pelo
programador individual e mantidos atualizados para um grupo de
colaboradores em um sistema único. O autor conclui que este trabalho
é válido e trará frutos em produtividade e confiança. Mas, pela sua
própria natureza, o retorno deve ser marginal.

Estações de Trabalho: o autor diz que as estações de trabalho cada


vez mais poderosas são bem vindas, mas não podemos esperar
progressos mágicos a partir delas.

Ataques Promissores na Essência Conceitual

De acordo com o autor, embora nenhum progresso tecnológico


prometa trazer resultados mágicos com os quais somos tão familiares
na área de hardware, há a abundância de bons trabalhos e a
promessa de um progresso, se não espetacular, estável. Todos os
ataques tecnológicos sobre os acidentes do processo de software são
fundamentalmente limitados pela equação de produtividade:

tempo_de_tarefa = ∑ (freqüência) x (tempo)

Se os componentes conceituais da tarefa agora estão tomando a


maioria do tempo, nenhuma atividade sobre os componentes da
tarefa que são meramente a expressão dos conceitos pode trazer
altos ganhos de produtividade. Por isso o autor defende que devemos
considerar aqueles ataques que indicam a essência do problema de
software, a formulação destas estruturas conceituais complexas.
Felizmente, alguns desses ataques são muito promissores.

Comprar versus construir: a solução mais radical possível para a


construção do software é não construí-lo completamente.

Todos os dias isto se torna mais fácil, já que cada vez mais
vendedores oferecem mais e melhores produtos de software para uma
variedade vertiginosa de aplicações. Enquanto os engenheiros de
software têm trabalhado na metodologia de produção, a revolução do
computador pessoal criou não um, mas muitos mercados de massa
para o software. Fontes mais especializadas oferecem produtos de
muito poderosos, e ferramentas de software e ambientes podem ser
comprados de prateleira.

Qualquer um destes produtos é mais barato que construir um novo.


Mesmo a um custo de cem mil dólares, o preço de compra do
software é equivalente ao salário anual de somente um programador.
A entrega é imediata e tais produtos tendem a ser muito melhor
documentados e mantidos que o software feito em casa.

O autor defende que o desenvolvimento do mercado de massa seja a


tendência na engenharia de software. O custo do software tem
sempre sido de desenvolvimento, não de replicação. Dividir este custo
mesmo entre alguns usuários corta radicalmente o custo por usuário.
Outra forma de olhar para isto é que o uso de n cópias de um sistema
de software multiplica efetivamente a produtividade de seus
desenvolvedores por n.

Muitos usuários agora operam seus próprios computadores


diariamente, utilizando diversas aplicações sem nunca ter escrito um
programa. De fato, muitos desses usuários não podem escrever novos
programas para as suas máquinas, mas são adeptos da solução de
novos problemas com os mesmos.

O autor ainda defende que a estratégia de produtividade de software


mais poderosa para muitas organizações seja equipar os
trabalhadores intelectuais sem conhecimentos de computador com
computadores pessoais e programas de escrita, desenho, arquivo e
planilha. A mesma estratégia, executada com pacotes matemáticos e
estatísticos e alguns recursos simples de programação, funcionará
para centenas de cientistas de laboratório.

Refinamento de requisitos e prototipagem rápida: a parte mais


difícil na construção de um sistema de software é decidir
precisamente o que construir. Nenhuma outra parte do trabalho
conceitual é tão difícil quanto estabelecer requisitos técnicos
detalhados, incluindo todas as interfaces para pessoas, máquinas e
outros sistemas de software. Nenhuma outra parte do trabalho
prejudica o sistema resultante caso seja feita incorretamente.
Nenhuma outra parte é tão difícil de corrigir mais tarde.

Portanto, as funções mais importantes que o construtor de software


desenvolve para o cliente são a extração e o refinamento iterativos
dos requisitos do produto. A verdade é que o cliente não sabe o que
quer. O cliente normalmente não sabe quais questões precisam ser
respondidas, e ele nunca pensou no problema com o detalhamento
necessário para a especificação. Nem mesmo a simples resposta “Faça
o novo sistema de software funcionar como o nosso velho sistema de
processamento de informação manual” é na verdade tão simples. Ele
nunca quer exatamente aquilo. Além disso, sistemas de software
complexos são coisas que agem, movem e trabalham. É difícil de
imaginar a dinâmica esta ação. Desta forma, no planejamento de
qualquer atividade de projeto de software, é necessário permitir uma
iteração extensiva entre o cliente e o projetista como parte da
definição do sistema.

O autor ainda afirma que é realmente impossível para um cliente,


mesmo trabalhando com um engenheiro de software, especificar
completa, precisa e corretamente os requisitos exatos de um produto
de software moderno antes de testar algumas versões do produto.

Portanto, um dos esforços tecnológicos atuais mais promissores e que


ataca a essência do problema de software, e não os acidentes, é o
desenvolvimento de abordagens e ferramentas para prototipagem
rápida de sistemas, uma vez que a prototipagem é parte da
especificação iterativa de requisitos. Um sistema de protótipo de
software simula as interfaces importantes e desempenha as principais
funções do sistema pretendido. Os protótipos normalmente
desempenham as principais tarefas da aplicação, mas não tentam
tratar as tarefas excepcionais, responder corretamente a entradas
inválidas ou abortar de forma limpa. O propósito do protótipo é tornar
real a estrutura conceitual especificada, para que o cliente possa
testá-la em termos de consistência e usabilidade.

O autor diz que muito do procedimento atual de aquisição de software


repousa sobre a suposição de que se pode especificar um sistema
satisfatório antecipadamente, receber propostas para sua construção,
construí-lo e instalá-lo. E defende que esta suposição é
essencialmente incorreta, e que muitos problemas na aquisição de
software surgem desta ilusão. Por isso, não podem ser corrigidos sem
uma revisão fundamental – que prevê o desenvolvimento iterativo e a
especificação de protótipos e produtos.

O desenvolvimento incremental evolui o software, não constrói. E o


autor nos convida a transformar a natureza e a complexidade do
estudo em matérias vivas, em vez de trabalhos mortos do homem. E
diz que o cérebro sozinho é intrincado além de mapeamento,
poderoso além da imitação, rico em diversidade, auto-protetor e auto-
renovador. O segredo é que o cérebro é evoluído, não construído, e da
mesma forma deve ocorrer com sistemas de software.

O autor ainda descreve a experiência de desenvolvimento incremental


obtida no Software Engineering Laboratory, onde ministrava aulas, e
defende que os mesmos benefícios obtidos em seus pequenos
projetos podem ser obtidos em grandes projetos.

Grandes projetistas: o autor defende que a questão central de como


melhorar os centros de software está nas pessoas. Podemos ter bons
projetos seguindo boas práticas, que podem ser pensadas. Ressalta
que os programadores fazem parte da camada mais inteligente da
população, desta forma podem aprender boas práticas. Por isso, o
grande impulso é propagar boas práticas modernas. Novos currículos,
nova literatura, novas organizações a fim de elevar o nível de nossa
prática de ruim para bom. Excelentes projetos vêm de excelentes
projetistas. A construção do software é um processo criativo. Uma
metodologia sólida pode capacitar e libertar a mente criativa. Muitos
estudos mostram que projetistas muito melhores produzem estruturas
que são mais velozes, menores, simples, limpas e com menos esforço.

Segundo o autor, um pequeno retrospecto mostra que, embora muitos


sistemas de software bons e úteis tenham sido projetados por
comitês, e construídos como parte de projetos multi-partes, os
sistemas de software que realmente empolgaram e incitaram fãs
apaixonados são produtos de uma ou poucas grandes mentes
projetistas. Por isso, embora apóie fortemente os esforços de
transferência de tecnologia e desenvolvimento dos programas de
estudos em andamento, o autor pensa que o esforço mais importante
a se realizar seja desenvolvermos maneiras de formar grandes
projetistas.

Nenhuma organização de software pode ignorar este desafio, Bons


gerentes, ainda que sejam escassos, não são tão escassos como bons
projetistas. Grandes projetistas e grandes gerentes também são muito
raros. A maioria das organizações faz esforços consideráveis para
encontrar e cultivar grandes gerentes, mas o autor não conhece, ao
menos na época, nenhuma que faça um esforço igual para encontrar e
desenvolver grandes projetistas, de quem a excelência técnica dos
produtos irá ultimamente depender.

A proposta do autor é que cada organização de software deve


determinar e proclamar que grandes projetistas são tão importantes
para o seu sucesso quanto grandes gerentes e, similarmente, nutri-los
e recompensá-los. Não somente salário, mas gratificações de
reconhecimento – tamanho do escritório, mobiliários, equipamento
técnico pessoal, fundos para viagens e pessoal de apoio. E sugere
alguns passos para que as organizações desenvolvam grandes
projetistas:

Identificar os melhores projetistas o mais cedo possível. Os


melhores nem sempre são os mais experientes.
Atribuir um mentor de carreira para ser responsável pelo
desenvolvimento de cada profissional identificado e montar
cuidadosamente um plano de carreira.
Criar e manter um plano de desenvolvimento de carreira para o
profissional, incluindo cuidadosamente aprendizagens selecionadas
com os melhores projetistas do mercado, educação formal avançada e
pequenos cursos, todos intercalados com projetos individuais e
exercícios de liderança técnica.
Dar oportunidades para os projetistas em crescimento interagirem e
criarem estímulos.

Postado por Fabrício Olmo Aride às 15:43

Marcadores: Engenharia de Software

Nenhum comentário:

Postar um comentário

Digite seu comentário...

Comentar como: Selecionar perf

Publicar Visualizar

Postagem mais recente Página inicial Postagem mais antiga

Assinar: Postar comentários (Atom)