iMasters

Nosso objetivo aqui é tentar ajudar a esclarecer a diferença dessas formas utilizando um exemplo prático.

As associações representam o equivalente mais próximo dos relacionamentos utilizados no modelo Entidade-Relacionamento, ou seja, seu objetivo é definir a maneira como as classes estão unidas e se relacionam entre si, compartilhando informações - (Guedes, 2006, p. 72)

Vejamos dois relacionamentos para entender melhor as nomenclaturas:

Figura 01 - Todo-Parte

Os relacionamentos Todo-Parte acima são representado por:

• Pedido (Objeto-Todo) e ItemPedido (Objeto-Parte)
• Time (Objeto-Todo) e Atleta (Objeto-Parte)

Na Agregação, a existência do Objeto-Parte faz sentido, mesmo não existindo o Objeto-Todo. Vejamos o exemplo Time-Atleta:

Figura 02 - Agregação

Um time é formado por atletas, ou seja, os atletas são parte integrante de um time, mas os atletas existem independentemente de um time existir. Nesse caso, chamamos esse relacionamento de AGREGAÇÃO.

Já a Composição é uma agregação mais forte; nela, a existência do Objeto-Parte NÃO faz sentido se o Objeto-Todo não existir. Vejamos o exemplo Pedido-ItemPedido:

Figura 03 - Composição

Nesse caso, um pedido é composto por um ou vários itens, mas um produto NÃO é item de um pedido se não existe pedido. Assim, chamamos esse relacionamento de COMPOSIÇÃO.

Conclusão

Essas são as formas de se representar o relacionamento entre os objetos das classes do tipo part-of, em que a agregação é representada por um diamante branco, sempre do lado do "Objeto-Todo", e a composição é representada por um diamante negro, também desenhado do lado do "Objeto-Todo".

• Bibliografia:

Nesse momento, surgem perguntas errôneas, como por exemplo: "qual é a melhor linguagem de programação?". Vamos discutir mais adiante qual seria a melhor pergunta, antes de encontrar a melhor resposta. O dilema que vivemos hoje em cada projeto foi vivido também nos primórdios da energia elétrica. Veja:

Por volta de 1890, foi anunciado um prêmio para aquele que conseguisse implementar um sistema de distribuição elétrica eficiente. Dentre os inventores que perseguiram a implementação perfeita estavam Thomas Edson e George Westinghouse, juntamente com Nikola Tesla.

Edson propunha o método de transmissão por corrente contínua, no qual em cada quarteirão haveria uma subestação elétrica para manter a tensão elétrica até os pontos necessários. Por outro lado, Tesla e Westinghouse propunham a transmissão por corrente alternada, onde a corrente era elevada a altas tensões para poder ser transmitida a distâncias muito maiores, e a cada subestação a tensão era convertida novamente.

Edson era muito famoso por suas inúmeras invenções, em especial a lâmpada. Ele não era um cientista, antes, era altamente experimental; anotava tudo o que fazia e tinha como meta criar um pequeno invento a cada 10 dias e um grande invento a cada seis meses.

Já Tesla, que era apoiado por Westinghouse, estudou nas melhores universidades e era conhecido pelos seus métodos inovadores e ousados; ele anotava somente o necessário; chegou a trabalhar com Edson quando fora para os EUA, porém isso não perdurou.

Edson, pressionado pelos seus clientes quanto à mudança para corrente alternada, empreendeu diversas campanhas publicitárias para tentar convencer a população de que a corrente alternada era um risco, e não uma solução. Em meio a essa guerra travada, Westinghouse propôs a Edson uma parceria, para que juntos pudessem construir o melhor meio de transmissão; Edson sequer o respondeu.

A dupla Westinghouse e Tesla ganhou a licitação para apresentação na feira de Chicago e, devido a isso, Edson proibiu a utilização das suas lâmpadas, levando Tesla à implementação de uma nova lâmpada para utilizar na apresentação - que foi um sucesso: toda a cidade iluminada e a premiação das Cataratas do Niágara garantida a eles. A corrente alternada se popularizou, sendo um método de transmissão utilizado no sistema elétrico conhecido nos nossos dias.

Podemos ver semelhanças entre o que houve na guerra elétrica com o que vivemos nos dias de hoje, estamos em meio a uma corrida para o melhor desenvolvimento, as melhores tecnologias e os melhores métodos que propiciem o desenvolvimento em custo, tempo e qualidade satisfatórios. Afinal, qual é a melhor linguagem? Qual o melhor método de desenvolvimento de software?

Acho que não existe uma resposta única para cada pergunta. Creio que as linguagens que temos à disposição e as metodologias que podemos usar para implementar softwares devem ser utilizadas no momento oportuno. É uma questão de estratégia, muito mais do que um assunto de preferências pessoais. Ou seja, não há melhores e piores, mas sim o mais adequado.

Encontramos no mercado de TI profissionais com estilos como Edson e Tesla: percebe-se que Edson tinha uma metodologia parecida com o Scrum, no que condiz às metas de implementação; por outro lado, ele era altamente documental. Já Tesla era simplista, documentava o necessário e tinha  seu foco voltado para resultados. Ambos foram gênios que fizeram grandes descobertas na História, mas o que fica muito explícito na "guerra elétrica" foi o ego: Edson sabia que a corrente contínua não era ideal para a necessidade, mas, por ele ser "o grande Edson", não quis "dar o braço a torcer"; não foi o seu jeito de trabalhar que o levou à derrota, nem mesmo o seu conhecimento, e sim o ego. Por outro lado, as decisões ousadas por parte de Westinghouse e Tesla foram decisivas para o sucesso do projeto.

Para vermos a mesma guerra que foi travada entre Edson e Tesla/Westinghouse, basta acessarmos grupos de discussão sobre Gerência de Projetos, Engenharia de Software e Linguagem de Programação; encontraremos inúmeros "Edsons" e "Teslas" discutindo se devem aplicar Agilidade em tudo, ou usar .Net para todos os projetos, e outras discussões como essas, que não levam a nenhum lugar concreto e raramente servem para outra coisa se não expor uma opinião pessoal.

E então surgem as perguntas... "E se o ambiente for Linux? Vou forçar Mono para manter .Net  ou implementaria com Java? Será que não preciso conhecer o todo para implementar as partes?

Se for implementar uma baleia, eu não preciso saber de toda a baleia? E se eu implementar só a nadadeira, no final não correria o risco de ter uma nadadeira de golfinho para colocar em uma baleia?

Será que a mesma regra realmente pode ser sempre aplicada? Até onde nosso objetivo é fazer um bom projeto, ou será que queremos apenas fazer um bom nome? Acredito que se o projeto for bem feito, consequentemente o nome do profissional será "bem feito" também.

Até onde nosso objetivo é a solução ideal, e até onde ele é apenas a nossa opinião? É preciso refletir sobre isso.

artigo publicado originalmente no iMasters, por Bruno Carlos Alves

Por conta disso e contando com a falta de profissionais web presentes no big bang da rede mundial, ainda hoje vemos as mais variadas disciplinas brigando, se apaixonando, se casando e até mesmo construindo um lar real para o incontável número de informações que passam rapidamente pelas telas dos computadores.

Com essa constante adaptação, nós podemos ver desfilando livremente pelo Team das agências e empresas de TI as mais variadas formações profissionais.

Estas acabam contribuindo para os novos desafios promovidos pela web, dentro da arquitetura de informação, e ajustando todo o compasso, até então mal utilizado, da forma a comunicação.

Nesse emaranhado de novidades e de "nascimentos", muita coisa mudou e se adaptou às novas exigências do mercado digital, cada vez mais presente e ativo.

Ainda no contexto de evolução contínua, podemos ver as áreas que cuidam da experiência e do resultado durante a navegação, encontrando e somando expertise para trazer uma melhor e mais fiel experiência para o internauta.

O resultado dessa multidisciplinaridade em equipe é a geração de bons trabalhos digitais que repercutem diretamente em retorno para a empresa, atingindo um quase equilíbrio entre cliente e usuários satisfeitos.

Embora o entendimento da necessidade de integração de disciplina seja uma realidade em constante desenvolvimento, ainda existem alguns ângulos do processo que ficam perdidos. Um deles é a interpretação dos protótipos dos arquitetos de informação.

Já que os autores se originam de diversas áreas e também pelo fato de a profissão ainda estar se consolidando em muitos ambientes de desenvolvimento web (quer seja agência ou consultoria), são criadas especificações com estilos muito particulares, que, ao serem apresentadas para a equipe, geram um entendimento deficiente que poderá se converter em resultados menos claros, equipe estressada e descontentamento geral.

Redigi algumas linhas sobre especificações geradas pelo trabalho da arquitetura da informação. Não entendam como regra básica, pois muita coisa ainda está se adaptando, mas com alguns princípios poderemos fazer produtos que sejam claros e de boa interpretação para os envolvidos no processo.

Para que serve uma especificação de AI?

Sitemaps, fluxo de transações, wireframes, métricas de performance, plano de implementação, matriz de escopo e o que mais sua imaginação puder lembrar servem para uma única e exclusiva função: orientar.

Mas orientar quem?

1. Cliente: orientar para entenda a dimensão, as premissas, a organização de informações e os fluxos que o projeto dele comporta;
2. Gerente de Projeto: orientar no escopo e nos prazos do projeto;
3. Designers: orientar no que diz respeito à localização dos blocos de informações de cada tela; 
4. Desenvolvedores: orientar como será o fluxo da navegação em cada seção.

Check list em que vale a pena dar uma conferida

Para que sua especificação seja interpretada de forma correta por todas as pontas do projeto (cliente/equipe), é importante verificar se ele está cobrindo a maioria das sugestões abaixo:

• Cada projeto pode receber um tipo de protótipo. Projetos em que o design de interação fale mais alto, como hotsites e portais promocionais, devem ter um wire mais aberto (sem detalhamentos que engessem os criativos) e tudo deve ser extremamente conversado com a equipe, pois juntos vão criar uma melhor experiência para o produto/serviço que será ofertado.
• Projetos mais complexos como e-commerces devem conter, pela quantidade de UX e controle de vocabulário, uma arquitetura mais detalhada e gerar protótipos navegáveis.
• Extranets ou intranets, onde a encontrabilidade é um fator fundamental, devem ter seus wireframes construídos juntamente com os desenvolvedores do projeto (analistas e programadores) para que não seja criado um ambiente implementável apenas com linguagens alienígenas ou pertencentes a um futuro distante.
• Nem sempre o protótipo conseguirá cobrir as espectativas e os entendimentos da equipe e/ou do cliente, portanto temos que usar todas as outras possibilidades de especificações como sitegramas, vocabulários controlados e a própria especificação funcional das telas.
• O wireframe tem a intenção de ajudar o designer a estruturar o site ou o sistema, e não ensinar o design como fazer o seu layout. Se você é um arquiteto que antes era designer, cuidado com os super protótipos. Tenha modos e respeite a linha de ação da disciplina que você não mais professa.
• Wireframe por default, e para melhor entendimento do conceito de "protótipo", não tem cor e nem imagens. Porém não sejamos xiitas demais! Se o cliente tem dificuldade de abstrair o protótipo para a realidade dele, pense com carinho na possibilidade de inserir imagens que estejam contextualizadas com o negócio dele.
• Se existem telas que são complicadas até para você, arquiteto de informações, imagina para o cliente ou para a equipe - que certamente não ficou lendo e decorando as 10 heurísticas do Nielsen. Seja um bom AI e explique bem cada passo desse fluxo de forma clara para todos que estão envolvidos com o projeto. A equipe contribui muito no processo de criação. Fale com as demais áreas e você verá que além do entendimento global haverá algumas boas idéias que você pode, antes de finalizar a especificação, integrar na sua arquitetura. Não seja muito introspectivo, converse!

Não esqueça que especificações de Arquitetura da Informação não são diários particulares de suas experiências no projeto, e sim livros que se tornarão best-sellers para todas as pessoas que trabalham na construção do website ou sistema web. Oriente-se!

artigo publicado originalmente no iMasters, por Isis Ferrera