Informações desejáveis sobre a arquitetura proposta

[Hugo Estevam Longo]

Pessoal, gostaria da opinião de vocês em relação ao tema descrito abaixo.

 

Onde trabalho temos o costume de criar um documento arquitetural com as definições arquiteturais de um projeto, em geral seguem as definições necessárias aos vários projetos existentes na empresa e que atenda a todas as necessidades, desde a segurança, regras de negócio, até a persistência dos dados. Essas definições nada mais são do que a descrição da Arquitetura proposta.
Vamos supor que um arquiteto de software foi contratado por uma determinada empresa para substituir outro arquiteto de software que saiu (pediu a conta, mandaram embora, faleceu, etc).
Deixando de lado o processo de desenvolvimento de software que a empresa segue (Cascata, Processo Unificado ou algum Método Ágil), que tipo de informação/documento o arquiteto gostaria de receber sobre o projeto que ele irá trabalhar?

O que temos produzido parte de um desenho que descreve a Arquitetura proposta em camadas e componentes. Logo após são abordados cada camada e componente listados na arquitetura entrando no mérito “O que é essa camada? E pra que serve? Porque foi aplicado esse Padrão? Porque essa tecnologia foi escolhida?”. Também são comentados quais são os objetivos e restrições arquiteturais e quais impactos eles tem na arquitetura “O controle de concorrência otimista ou pessimista? Por quê?”.

Enfim, apenas uma opinião do que vocês tem encontrado que julgam necessários ou não.
Obs.: Não citei a análise do código fonte porque neste contexto acredito que isso está implícito.

Obrigado,
At.
Hugo Estevam

[Luiz Carlos Faria]

Hugo,

Não chego a ser descrente com relação ao documento de arquitetura, nos projetos em que recebi um documento de arquitetura vi ou uma visão muito macro e minimalista demais, ou um material defasado.

A arquitetura evolui em conjunto com o projeto, faz parte do acompanhamento do projeto identificar padrões que possam ser incorporados à arquitetura. Geralmente as evoluções na arquitetura não são documentadas. 

Acho que o documento deve deixar explícito tudo aquilo que é implícito quanto à solução. Quais designs, padrões, principais mecanismos, frameworks são usados e onde estão sendo usados, configurados e aplicados. Quais as exceções, o seus motivadores. 

Acredito que o documento deva contextualizar o arquiteto e que sirva para contemplar todos os pontos da arquitetura. O nirvana de um documento de arquitetura seria aquele em que um desenvolvedor isolado pudesse desenvolver, sem a necessidade de acompanhamento ou direcionamento.

O nivel de detalhamento pode até ser superficial, presumindo conhecimentos prévios, mas para isso é preciso citar boas referências para ajudar no nivelamento.

Eu prefiro analisar o código, usando um documento como guia para aquilo que as vezes foge aos olhos. Olhando código se tem informação demais, o documento ajuda nessas horas.

_______________________________________________________________
Luiz Carlos Faria

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Thiago C. Santos]

Concordo com o Luiz e acho que documentos técnicos tem mais facilidade de ficar defasado do que uma especificação do sistema.

Em minha experiencia como desenvolvedor os documentos mais importante que eu vi quando tive que colocar a mão em um projeto já criado e em produção foram documentos de especificação técnica falando das funcionalidades do sistema, qual o seu real comportamento.

Att,

Thiago C. Santos

2012/12/11 Luiz Carlos Faria <luizcar...@gmail.com>

[Eric Lemes]

Hugo,

Muito boa dúvida.

Eu particularmente acho que todas as metodologias baseadas em projeto, pregam documentos "de projeto", mas existe muito pouca discussão sobre como criar e manter uma documentação técnica que seja "viva" junto com o software. Wikis são muito boas pra isso pois são formas colaborativas de documentar, mas vale criar a prática no time. Por exemplo, em metodologias "prescritivas" de software, ou seja, caso de uso, diagrama de classe em tempo de projeto, dificilmente conseguimos observar essas documentações sendo atualizadas depois que o projeto termina. 

Desenvolve-se um novo projeto, uma nova documentação e a vida segue. Pra quem mantém produto isso é péssimo. Alguém precisa pegar esses pedaços de documentação e consolidar numa documentação do produto ou do software que seja gerida em conjunto com o ciclo de vida da aplicação.

Sobre o "como" documentar.... em arquitetura de soluções acho que diagrama de componentes ajuda muito. Basicamente representar quais são os componentes: web services, windows services, fila MQ, processo windows service, aplicação web, quais bases de dados acessam o que precisa ter deploy na mesma máquina o que pode ter deploy em máquina diferente. Onde trabalho usamos um diagrama proprietário pra isso. Gosto de diagrama de sequencia pra solução também, principalmente no nível funcional. É interessante pra representar a troca de mensagens (falo de integrações mesmo) entre diferentes sistemas, deixar claro o que é síncrono o que é assíncrono e como a conversa entre os sistemas será estabelecida.

Sobre arquitetura "de software" pra mim acho que o ideal está em diagramas de classes e seqüência. Como documentar todo o sistema, todas as implementações é algo bastante complexo, coloco uma documentação no estilo de principais abstrações utilizadas na arquitetura como um bom meio termo. Segui essa idéia baseado no livro do GoF num projeto que trabalhei e gostei do resultado. Documentávamos em wikis as principais abstrações do software em diagramas de seqüência e classes junto com um descritivo de como o developer deve pensar quando for implementar algo baseado naquela abstração.

Mas além disso, acho que é meio complexo essa coisa do arquiteto de software pensar na arquitetura "fora" do projeto. Acho que a arquitetura de software é bem mais produtiva num processo de imersão mesmo, troca de conhecimento. É muito difícil "ditar" ou "impor" um estilo arquitetural numa equipe. Fica aquela coisa do comentarista de futebol. O cara fica na tribuna de honra dizendo como o técnico e os jogadores tem que jogar o jogo, mas nunca entre em campo pra levar vaia da torcida.

Aliás acho que o grande desafio de arquitetura está nisso. Eu vejo o arquiteto como um grande influenciador. A grande maioria das coisas que ele concebe, não será ele quem implementará em sua totalidade, por isso é importante sempre manter o contexto em mente e ter o skill da equipe como um balisador, além do processo de vender idéia, disseminar conhecimento e aprender com a equipe. Pior do que uma arquitetura simples ou tosca bem implementada é uma arquitetura extremamente rebuscada mal implementada.

Abraço,

Eric

2012/12/11 Hugo Estevam Longo <hugoes...@gmail.com>

--

[Luciano Azevedo]

Já eu acho que a documentação do código tem que ser o código. Se as classes e métodos tem seus nomes corretos, com um o outro comentário em um ponto mais complexo. Se as partes foram bem feitas, não tem porque uma documentação estática. abre-se a solution e gera um diagrama de classes, no máximo um de dependências e pronto. Documento de arquitetura só serve pra te dar a arquitetura da solução mesmo,ponto de vista bem macro. De resto documentação só para o usuário o que o Sistema faz e como.

[ ]´s

Luciano Azevedo

[Hugo Estevam Longo]

 

@Luiz

 

Concordo contigo, realmente é as evoluções na arquitetura são difíceis de serem documentadas. Acredito que seja importante, por isso estou tentando encontrar um método mais suave para esse processo.

 

At.

Hugo Estevam

[Hugo Estevam Longo]

@Thiago

 

Em relação a defasagem, não acredito que um documento arquitetural tenha mais facilidade de ficar defasado do que a especificação do sistema. Entendo que a arquitetura é aquela parte do software que é dificil de mudar, logo muda com bem menos frequencia do que o sistema e sua especificação.

 

Diferente dos documentos técnicos de especificação o documento arquitetural que temos produzido mostra apenas um exemplo de como um cadastro, uma exceção, uma visão devem ser feitos, é uma maneira de descrever superficialmente sem entrar no mérito de como desenvolver as regras de negócio, mas sim onde desenvolver.

 

Estou em busca de outras maneiras, que fujam do exemplo que citamos e que seja eficiente.

 

At.

Hugo Estevam

[Hugo Estevam Longo]

@Eric

 

A ideia do Wiki como uma ferramenta colaborativa parece ser o ideal. Como a arquitetura evolui juntamente com o projeto me parece que é a melhor forma de documentar/informar objetivos e restrições da arquitetura, podendo inclusive encaixar no contexto de arquitetura evolucionária por exemplo, construindo isso colaborativamente com os demais membros da equipe.

 

Em relação ao que deve conter nesse Wiki, acredito que vá existir uma grande divergência entre os membros deste grupo. Eu acredito muito na representação dos componentes seja em diagrama ou não, como disseste auxilia bastante o entendimento de deploy da aplicação. Posso descobrir tudo isso sem um diagrama? Posso, mas acho que não é o caminho mais fácil. Também gosto do diagrama de sequencia, procuro colocar nem que seja um unico diagrama na descrição da arquitetura, quando vejo algo desse tipo me parece mais fácil entender como ocorre a troca de mensagens entre as camadas do sistema e entre outros sistemas. Sei que muita gente não gosta de UML, por N motivos que fogem da discussão, mas o diagrama de sequencia eu acredito que vale a pena.

 

Concordo com relação ao arquiteto não poder pensar na arquitetura "fora" do projeto, o exemplo do comentarista de futebol foi perfeito.

 

Obrigado pela contribuição.

 

Um abraço

At.

Hugo Estevam

[Priscila Mayumi Sato]

Eu gostei da idéia de wiki.

Realmente gosto de pensar que a documentação do código é o próprio código, mas uma wiki falando de tópicos mais abrangentes e sobre a estrutura parece bacana.

[Hugo Estevam Longo]

@Luciano,

 

Eu até concordo contigo em relação a análise do código, até citei na post que nem levava isso em consideração porque acho que é implícito.

 

Mas, por exemplo, uma das coisas que você não vai descobrir analisando o código é porque alguém usou SOAP ao invés de REST. Isso poderia ser fácilmente descoberto se fosse descrito num documento arquitetural. Lá o responsável poderia justificar/exemplificar a escolha e até mesmo estabelecer uma restrição: "Foi escolhido SOAP porque no presente cenário é necessário fazer a propagação de Certificados Digitais a sistemas adjacentes, fato que RESTful não atente."

 

Note que mesmo sendo uma descrição macro, quem pegar o trem andando vai saber que não pode mudar por simplesmente achar que é melhor.

 

At.

Hugo Estevam

[Mário Meyrelles]

+1 pelo wiki

+1 pelo diagrama de sequência

Acho que arquitetura geralmente dá pra desenhar em alguns papéis e depois formalizar em alguma ferramenta.

Para funcionários novos que precisam aprender uma arquitetura nova, acredito quer uma apresentação, uma desenho e algum demonstrando a sequência dos fatos é bacana. Por exemplo, um cara que nunca trabalhou com MVVM vai precisar de várias dicas e exemplos para poder entender a arquitetura. Documentar a arquitetura é uma coisa. Outra coisa é torná-la clara para o homer simpson.

2012/12/12 Priscila Mayumi Sato <mayum...@gmail.com>

[Luciano Azevedo]

Concordo Hugo. E foi o que eu disse. O DA serve para esses pontos.

[Luciano Azevedo]

Mário, entendo que pela falta de opções do mercado atual nos vemos forçados a sermos mais que líderes, tutores. Mas meu DA não pode ensinar MVVM. Só pode dizer que uso e como uso. Eu, saindo aqui do papel de arquiteto, posso até ajudar o Homer, mas nesse momento não vou ser arquiteto.