Arquitetura do software

Continuando com a série de postagens sobre arquitetura, agora vamos tocar no assunto principal, que é a arquitetura do software. E ai eu já começo com uma opinião pessoal forte: esse é um dos conceitos mais mal entendidos dentro da engenharia de software. Já vi de tudo, desde “segue um diagrama com a arquitetura do sistema proposto…”, e o que se segue é um simples diagrama de blocos mostrando uma hierarquia de blocos, que podem ser qualquer coisa. Até um exagero de diagramas UML que acabam por confundir mais que ajudar, mostrando até detalhes tecnológicos e de implementação.

http://news.illinois.edu/news/07/0119ispace.html Uma metáfora interessante é a da arquitetura de construções civis, temos muitas lições a aprender de lá, e felizmente muitas já foram incorporadas aos nossos conceitos. Como é o processo de desenvolvimento da arquitetura, e para que ela serve? Antes de mais nada, o arquiteto é um elicitador de requisitos: conversa com todo mundo, tenta entender as necessidades de cada um dos usuários (stakeholders), e dai tenta montar uma solução que atenda a todos, obedecendo às restrições externas (não-funcionais) de segurança, topografia do terreno, financeira, etc. Encurtando a conversa, em seguida o arquiteto busca soluções já existentes (em revistas e em sitios especializados na internet), vai mostrando ao cliente (cliente deve ser entendido como um papel no processo, normalmente é um grupo que inclui marido, esposa, filhos, sogra, colaboradores, papagaio, cachorro…) e vai refinando a ideia, e em seguida materializa uma solução possivel para o problema. Que, depois de apresentada ao cliente, iterada, refinada  e aprovada, é transformada num conjunto de diagramas e documentos, que contêm a história do projeto desde o primeiro dia, os requisitos principais com os não-funcionais incluidos, as soluções existentes aprovadas pelo cliente, e finalmente um conjunto de diagramas descritos na linguagem universal própria da área, apresentados ao cliente na forma de desenhos em computador (que podem ser impressos). Primeira dúvida: qual o nível de detalhes a que o arquiteto deve descer? Lembrem-se de que em seguida, o projeto arquitetural vai ser passado a um engenheiro (escritório de engenharia) que vai incluir as soluções tecnológicas para a construção (colunas, lajes, ferragem, tipo de massa e material, etc.) atendendo ao especificado. E finalmente, essas soluções de engenharia serão passadas à equipe de implementação, constituida pelo mestre-de-obras e sua equipe de profissionais: pedreiros, serventes, azulejistas, eletricistas, bombeiros, pintores, etc. Portanto, o arquiteto tem que apresentar suas soluções sem avançar demais na parte tecnológica da construção, que são detalhes a serem tratados pelo engenheiro. Mas, nada impede que um ou outro detalhe a mais seja incluido pelo arquiteto, para ajudar no entendimento (a figura acima é um sketch ou esboço arquitetural, vejam o site aqui).

Temos que ser espertos e aproveitar o que for interessante de outras áreas, ao invés de ficarmos tentando reinventar a roda. Aproveitando a metáfora, pode-ser ver claramente que existem muitas interseções e muitos passos podem ser aproveitados na arquitetura de software. Isso já avançou tanto, que hoje temos o conceito de framework arquitetural como o framework de Zachman e o TOGAF, que são guias para descrição de arquiteturas de software, e serão objeto de outra postagem mais adiante. Mas, e dai? Afinal, o que é a arquitetura, não é a mesma coisa que design do software? Sim, arquitetura do software é design em suas fases iniciais e que, como na nossa metáfora, pode descer a algum nível de detalhe mais fino. Extraindo do livro objeto da postagem Arquitetando o software, definição atribuida a Grady Booch: “All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” Para mim, esta conceituação é perfeita, e suficiente para um bom entendedor. A arquitetura deve definir estrutura, comportamento em alto nível focado nos elementos principais da arquitetura, sendo uma solução de compromisso e que atenda aos requisitos dos stakeholders sem perder de vista o ambiente externo e o escopo que não deve ser ultrapassado, documentando as decisões tomadas com base em critérios técnicos e econômicos. Eventualmente, uma arquitetura pode ser aderente a um estilo arquitetural (sim, existe isso em arquitetura de software, veremos nos frameworks em breve).

Muito bem professor, mas afinal de contas, quais os diagramas da UML, por exemplo, que podem ser usados numa especificação da arquitetura? Eu diria que qualquer diagrama pode ser usado, desde que se mantenha o nível de detalhe compativel com o nível de abstração que se deseja descrever. Certamente diagramas de contexto com casos de uso são úteis, e algum detalhamento dos casos de uso utilizando diagrama de atividades ou descrição textual, mantendo o foco no nivel de detalhe adequado ao nível de abstração. E o banco de dados? Claro, deve ser contemplado com um diagrama de conceitos principais em alto nível, que posteriormente vão ser refinados em detalhes e implementados como tabelas relacionais ou suas extensões para acomodar o conceito de objetos. E um diagrama de sequência, caberia nesse nivel de descrição? Sim, caberia, mas sem detalhes, mostrando apenas colaborações de nível mais alto. E o diagrama de deployment (distribuição) deve ser usado? Sem dúvida sim, deve também. Lembrem-se sempre de que a  decisão sobre o que incluir ou não deve estar sempre atrelada ao nível de detalhe da abstração que está sendo objeto em determinado instante. Não avancem para o nivel de detalhe seguinte, porque ai começa a misturada e a consequente confusão. Em breve mais sobre arquitetura de software, vou falar um pouco sobre os frameworks e focar no de Zachman que é o que conhecemos melhor.

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com)

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com:
Publicado em Arquitetura de software, Carreira, Educação, Engenharia de Software
2 comentários em “Arquitetura do software
  1. Fabricio Maia (96) disse:

    Ótimo artigo Zé, alias, os três últimos foram muito bons e bem alinhados com minha vida profissional, ☺

    Deixe-me dar uma opinião saindo um pouco dos conceitos teóricos e entrando um pouco na seara do mercado, pois o que tenho visto como sendo esperado dos “arquitetos” varia bastante de empresa para empresa (já no job description).

    Uma das consequências desta época em que o emprego vai atrás de você é conseguir saber com antecedência o que o mercado está procurando. Durante o período em que estava procurando uma oportunidade melhor no mercado participei de alguns processos para o cargo de arquiteto, e notei que tanto a função a ser desempenhada pelo profissional, quando o salário que se desejava pagar variavam demais… De certa forma houve uma “banalização” do termo arquiteto de software.

    Concordo que o papel de arquiteto pode ter suas variações. No meu próprio caso, já fui “arquiteto de sistemas”, no qual havia um foco estritamente técnico (design patterns, componentes, linguagem, algoritmos, etc.), “arquiteto de soluções”, onde tinha que participar de reuniões com clientes e eventualmente orientá-los a pedir o que queriam corretamente (e apresentar a solução técnica no nível de detalhe do anterior), e ultimamente de “arquiteto de integrações”, onde basicamente sou responsável por definir integrações entre diversos sistemas, seguindo normas e padrões como o TMForum. Mas em todas elas, sempre fui obrigado que ter um conhecimento técnico bem fundamentado e do negócio que estava discutindo, pois o papel exige que você atue como um líder técnico, ditando a forma como o projeto será conduzido.

    O que notei é que algumas empresas querem arquitetos que “jogam nas 11”, participando desde a fase de concepção e levantamento de requisitos até o desenvolvimento e testes, ou seja, um exército de um homem só, hehe

    Abraços Zé.

    • olá, fabricio. de fato, varia demais mesmo. acompanho as propostas de emprego, e de vez em quando dou olhada em curriculos de pessoas que se denominam arquiteto de software. as diferenças são enormes, não existe um padrão de conhecimento e experiência que possa ser tomado como base. lá fora, as exigências são muito maiores, é dificil ser contratado como arquiteto, embora haja muita procura. aqui no Brasil, há mesmo uma banalização, existem arquitetos e arquitetos, incluidos ai os que se auto-intitulam arquiteto de software. abraço,

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: