sexta-feira, outubro 10, 2008

Arquitetura de Software: O que é e como documentar

Resolvi escrever esse aartigo explicando brevemente o que é arquitetura de software depois de uma dúvida na lista de discussões UML Brasil. A dúvida acabava por confundir um pouco arquitetura de software APENAS como sendo o diagrama de classes de design. Antes fosse só isso... os arquitetos de software teriam muito mais tranquilidade... rs.

Vamos começar pela definição teórica clássica do IEEE no seu guia de recomendações IEEE 1471 (e que também se encontra no livro "Software Architecture in Practice, 2nd Edition"): "A arquitetura de um sistema de software é a estrutura ou estruturas do sistema, que contempla elementos de software, as propriedades visíveis externamente desses elementos e o relacionamento entre eles".

É claro que essa definição precisa ser detalhada, pois senão ficamos na mesma :-) .

Quando se fala de estruturas estamos falando de estruturas estáticas e dinâmicas. As estruturas dinâmicas definem como o sistema atua em tempo de execução, portanto apenas um diagrama de classes não resolveria esse ponto.

Quando falamos em propriedades externamente visíveis estamos falando das interações de um elemento ou um sistema com o seu ambiente externo. Pode ser os fluxos de informação de entrada e saída, a forma como o elemento responde aos estímulos externos e o contrato (a interface) desse elemento.

Outra definição importante, que encontramos no excelente livro "Software Systems Architecture: Working with stakeholders using viewpoints and perspectives", é a de que a arquitetura de software deve ser dirigida pelas necessidades dos envolvidos do projeto: clientes, usuários, departamento de TI, suporte, produção, operação, etc. A arquitetura de software não pode ser pensada sem o contexto dos stakeholders. Isso pode parecer óbvio, mas muitos sistemas por aí são feitos sem a devida atenção às necessidades dos envolvidos. Já vi muita gente escolhendo uma determinada arquitetura por ser a onda do momento, sem se perguntar profundamente se aquilo atenderia as necessidades do negócio. Resumindo: Arquiteturas devem ser criadas apenas para atender às necessidades dos stakeholders. Uma boa arquitetura é aquela que atende com sucesso os objetivos e necessidades de seus stakeholders.

Outra definição interessante, vinda do RUP, é a de que a arquitetura de software é um conjunto de decisões cruciais que restringem considerações de design e programação e que possuem um alto impacto para serem revertidas. Por exemplo, se for definido que o sistema será feito em JEE usando um framework Struts 2 então os desenvolvedores não poderão simplesmente desenvolver parte do sistema usando o Spring MVC. Além disso, mudar de Struts 2 para o Spring MVC, por exemplo, traria um alto impacto para a camada web da aplicação.

Além disso, é papel do arquiteto esclarecer as motivações por trás da escolha de determinados elementos arquiteturais em detrimento de outros. Também realizar análises "buy vc. build", isto é, comprar ou utilizar um componente open source ao invés de construí-lo do zero. Ou construir algo do zero considerando que no mercado existe já algo pronto para uso.

O arquiteto também deve enfatizar e focar nos atributos de qualidade do sistema, os chamados requisitos não-funcionais. Deve verificar necessidades vindas dos stakeholders relacionadas a performance, escalabilidade, manutenibilidade, segurança, internacionalização entre outras.

Para se ter uma idéia das várias "áreas" às quais um arquiteto deve endereçar, podemos recorrer novamente ao livro "Software Systems Architecture". O princípio inicial definido pelos autores é que "não é possível capturas as necessidades funcionais e as propriedades de qualidade de um sistema complexo em um único modelo compreensível". A partir daí é que surge a necessidade do que eles chamam de Visões e Perspectivas. O RUP possui o 4+1 View Model. O IEEE define até mais alguns. Algumas dessas Visões: Informacional, Concorrência, Desenvolvimento, Implantação, Operacional e Funcional. Já algumas das perspectivas importantes são: Segurança, Performance e Escalabilidade, Disponibilidade e Resiliência, Evolução, Acessibilidade, Internacionalização, Localização, Regulamentação e Usabilidade.

Agora pode surgir uma dúvida que é comum: devemos documentar essas coisas? Onde as documentamos?

É claro que não existe uma resposta genérica. Como tudo na Engenharia de Software... depende! Um sistema super simples não terá necessidade de documentação alguma. Um sistema super complexo (como o de um satélite ou de um Boeing) terá necessidade de uma documentação mais extensa.

Porém, para os casos em que estamos mais acostumados a trabalhar (sistemas e aplicações empresariais e corporativas) é recomendável ter, no mínimo, um "documento de arquitetura de software". Ele nem precisa ser um documento Word propriamente dito. Pode ser uma página de Wiki, uma folha A4, uma cartolina, etc.

Eu recomendo que esse documento seja sucinto e que tenha somente informações essenciais como:

- Elementos e componentes principais do sistema.
- Camadas do sistema.
- Mecanismos arquiteturais necessários ao sistema.
- Tecnologias escolhidas para resolver cada camada e mecanismo e a motivação por trás dessas escolhas.
- Componentes comprados ou open source que serão usados e como essa decisão foi realizada.
- Descrição dos principais design patterns utilizados e o porquê da escolha.
- Definição de como será feito o acesso a sistemas externos e/ou legados.

Além disso, algumas equipes podem sentir a necessidade de elaborar diagramas UML. Esses diagramas relacionados à arquitetura e ao design estarão no modelo de design (caso se use o RUP como processo de desenvolvimento). A equipe poderá usar diagramas de classe, de atividade, de sequencia, de estados, de componentes e de implantação para facilitar o entendimento visual dos elementos e de seus relacionamentos (conforme a definição de arquitetura de software feita pelo IEEE).

Reforçando e lembrando sempre que as atividades relacionadas à arquitetura são feitas de modo iterativo e incremental. Portanto, cuidado para não cair no modelo cascata e ficar durante longos períodos de tempo só escrevendo o documento de arquitetura. O bom e verdadeiro arquiteto é aquele que põe a mão na massa e prova com código e com testes que sua arquitetura realmente vai atender às necessidades de todos os stakeholders!!! Além disso, o arquiteto deve ser uma pessoa sociável e ir atrás dos stakeholders para validar suas decisões arquiteturais mais importantes.

Bom, essa é apenas uma pontinha introdutória sobre o assunto. Se alguém tiver mais dúvidas pode deixar um comentário nesse artigo!

10 Comentários:

At 5:40 PM, Blogger André Faria disse...

Muito bom Papo. O Papel de Arquiteto é mesmo muita vezes mal interpretado!

 
At 9:54 AM, Anonymous leonardo disse...

Olá Papo.Parabéns pelo blog.

Em relação a arquiteturas e arquitetos, existe uma vertente pregando que dentre todas as resposabilidades técnicas do arquiteto, o mesmo também deve atuar diretamente na gestão dos requisitos do projeto (talvez em conjunto com analistas de negócio e o próprio GP), porém sabemos que as características necessárias para gestão de requisitos muitas vezes são difícieis de se encontrar em arquitetos, que quase sempre tendem a se especializar em tecnologias e não tanto na questão administrativa do projeto.
Bom, de qualquer forma, o que você acha de adicionar-mos "Arquitetura de Software é ... negociar requisitos." como complemento da disciplina?

 
At 3:17 PM, Blogger Pedro Cavaléro disse...

Olá José Papo, muito bom o seu artigo!
Em relação ao que o leonardo comentou, eu fico me perguntando, se o arquiteto começa a negociar os requisitos, os analistas de sistemas começam a perder o emprego. Teríamos então os analistas de negócio, os arquitetos e os desenvolvedores. Acho q estamos passando um momento de dificuldade em compreender esses papéis.

 
At 7:26 PM, Anonymous leonardo disse...

Olá Pedro. Realmente não entendo porque você imaginou que estamos passando por um momento de dificuldade em compreender os papéis.
Vejo que você entendeu que o analista deveria ser removido da lista de colaboradores de um projeto, quando na verdade, o arquiteto não o substitui, e muito menos o analista de negócio.
Afinal de contas, quem melhor que o analista para projetar a solução em sistema? Talvez você concorde com a teoria evolucionista que diz ser o analista de negócio o próximo degrau de evolução do analista de sistema. Eu já acho que não, ou seja, "cada um no seu quadrado", porém acho sim muito importante a participação do arquiteto na negociação dos requisitos, afinal de contas, não seria ele o reponsável por "bolar" todo o suporte para o desenvolvimento?

 
At 12:40 PM, Blogger Rafael disse...

Olá Papo.
Você mencionou a lista UML Brasil. Não encontrei como me associar.
Poderia postar como?
Obrigado e parabéns pelo blog.

 
At 6:48 PM, Anonymous Aline - aline.ras@hotmail.com disse...

Olá Papo,

Trabalho na área de processos de uma empresa CMMI ML 3 e me identifico muito com os temas abordados no seu blog. Parabéns pelo seu trabalho!

Att,
Aline

 
At 11:49 AM, Blogger Amaro José disse...

Parabéns pelo post, estou assumindo a área de desenvolvimento de minha empresa, temos hoje 30 sistemas todos desenvolvido em DELPHI sem documentação meu primeiro desafio é documentar tudo, teria uma ferramenta para me indicar?


Obrigado,
a_loch@hotmail.com

 
At 2:20 PM, Anonymous André Filipe disse...

Papo, excelente artigo, parabéns desde já. Sou aluno do curso de engenharia de software, pela Universidade Federal de Goiás, queria saber se você tem algum exemplo de arquitetura de software para eu compreender melhor esse assunto.
andrefilipeb@gmail.com

Desde já obrigado.

 
At 9:56 AM, Blogger Márcia disse...

Este comentário foi removido pelo autor.

 
At 10:00 AM, Blogger Márcia disse...

Olá Papo. Parabéns pelo blog.

Acho muito importante o que o leonardo comentou, quanto a atuação da arquitetura na gestão de requisitos. Gostaria de entender se as atividades de requisitos independem da arquitetura ou em que momento existiria um negociação entre a áreas de negócio e de arquitetura dentro do RUP? Grata.

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas