38 Engenharia de Software Magazine – Arquitetura de Software

Arquitetura de Software

Desenvolvimento orientado para arquitetura

Antonio Mendes da Silva Filhoantoniom.silvafilho@gmail.com

Professor e consultor em área de tecnologia

da informação e comunicação com mais de 20

anos de experiência profissional, é autor dos

livros Arquitetura de Software e Programando

com XML, ambos pela Editora Campus/Else-

vier, tem mais de 30 artigos publicados em

eventos nacionais e internacionais, colunista

para Ciência e Tecnologia pela Revista Espaço

Acadêmico com mais de 60 artigos publicados,

tendo feitos palestras em eventos nacionais e

exterior. Foi Professor Visitante da University

of Texas at Dallas e da University of Ottawa.

Formado em Engenharia Elétrica pela Uni-

versidade de Pernambuco, com Mestrado em

Engenharia Elétrica pela Universidade Federal

da Paraíba (Campina Grande), Mestrado em

Engenharia da Computação pela University of

Waterloo e Doutor em Ciência da Computação

pela Univesidade Federal de Pernambuco.

Software, de modo genérico, é uma entidade que se encontra em quase constante estado de mudança. As

mudanças ocorrem por necessidade de corrigir erros existentes no software ou de adicionar novos recursos e fun-cionalidades. Igualmente, os sistemas computacionais (isto é, aqueles que têm software como um de seus elementos) também sofrem mudanças frequente-mente. Essa necessidade evolutiva do sistema de software o torna ‘não confi-ável’ e predisposto a defeitos, atraso na entrega e com custos acima do estimado. Concomitante com esses fatos, o cres-cimento em tamanho e complexidade dos sistemas de software exige que os profissionais da área raciocinem, proje-tem, codifiquem e se comuniquem por meio de componentes de software. Como resultado, qualquer concepção ou solu-ção de sistema passa então para o nível arquitetural, onde o foco recai sobre os componentes e relacionamentos entre eles num sistema de software.

Arquitetura de softwareQuase cinco décadas atrás software

constituía uma insignificante parte dos sistemas existentes e seu custo de desenvolvimento e manutenção eram desprezíveis. Para perceber isso, basta olharmos para a história da indústria do software (ver seção Links). Encontramos o uso do software numa ampla variedade de aplicações tais como sistemas de ma-nufatura, software científico, software embarcado, robótica e aplicações Web, dentre tantas. Paralelamente, observou-se o surgimento de várias técnicas de modelagem e projeto bem como de lin-guagens de programação. Perceba que o cenário existente, décadas atrás, mudou completamente.

Antigamente, os projetos de sistemas alocavam pequena parcela ao software. Os componentes de hardware, por outro lado, eram analisados e testados quase exaustivamente, o que permitia a pro-dução rápida de grandes quantidades de subsistemas e implicava em raros erros de

Edição 01 – Engenharia de Software Magazine 39

PROJETO

projetos. Entretanto, a facilidade de mo-dificar o software, comparativamente ao hardware, tem servido como motivador para seu uso. Além disso, a intensificação do uso do software numa larga variedade de aplicações o fez crescer em tamanho e complexidade. Isto tornou proibitivo analisá-lo e testá-lo exaustivamente, além de impactar no custo de manutenção.

Um reflexo dessa situação é que as téc-nicas de abstração utilizadas até o final da década de 1980 (como decomposição modular, linguagens de programação de alto nível e tipos de dados abstratos) já não são mais suficientes para lidar com essa necessidade.

Diferentemente do uso de técnicas que empregam algoritmos e estruturas de dados e das linguagens de programação que implementam tais estruturas, o cres-cimento dos sistemas de software deman-da notações para conectar componentes (módulos) e descrever mecanismos de interação, além de técnicas para geren-ciar configurações e controlar versões. A Tabela 1 apresenta o contexto da ar-quitetura de software. Na programação estruturada, é feito uso de estruturas de seqüência, decisões e repetições como ‘padrões’ de controle nos programas. Já a ocultação de informações é um recurso do paradigma orientado a objetos que permite ao programador, por exemplo, ocultar dados tornando-os seguros de qualquer alteração acidental. Além disso, na programação orientada a objetos, da-dos e funções podem ser ‘encapsulados’ numa entidade denominada objeto, o que resulta em mais simplicidade e facilidade na manutenção de programas. Por outro lado, os estilos arquiteturais capturam o ‘padrão’ de organização dos componen-tes de software num programa, caracte-rizando a forma na qual os componentes comunicam-se entre si.

Perceba que a categorização, apresenta-da na Tabela 1, teve o objetivo de capturar uma visão geral de abordagens aplicadas a sistemas de software. Nada impede, por exemplo, o uso da programação estru-turada em sistemas de grande porte ou da ênfase de um estilo arquitetural num sistema de pequeno porte. Entretanto, essa prática não é comum.

Note que à medida que tamanho e com-plexidade dos sistemas de software au-mentam, o problema de projeto extrapola as estruturas de dados e algoritmos de

Abordagem Foco Padrões

Programação estruturada Sistemas de pequeno porte Estruturas de controle

Abstração e modularização Sistemas de médio porteEncapsulamento e ocultação de

informações

Componentes e conectores Sistemas de grande porte Estilos arquiteturais

Tabela 1. Contexto da arquitetura de software.

Categorias arquiteturais Representações de projeto Restrições

Arquitetura ClássicaModelos, desenhos, planos, elevações e

perspectivas

Padrão de circulação, acústica, iluminação e

ventilação

Arquitetura de Software Modelos para diferentes papéis, múltiplas visões Desempenho, confiabilidade, escalonamento e

manutenibilidade

Tabela 2. Comparação de aspectos arquiteturais.

computação. Ou seja, projetar a arquite-tura (ou estrutura geral) do sistema emer-ge como um problema novo. Questões arquiteturais englobam organização e estrutura geral de controle, protocolos de comunicação, sincronização, alocação de funcionalidade a componentes e seleção de alternativas de projeto. Por exemplo, nos sistemas Web, uma solução que tem sido empregada faz uso de múltiplas camadas separando componentes clien-te, servidores de aplicações, servidores Web e outras aplicações (que possam ter acesso a esse sistema). Essa estruturação em camadas objetiva facilitar a alocação da funcionalidade aos componentes. O uso de camadas oferece suporte à flexi-bilidade e portabilidade, o que resulta em facilidade de manutenção. Outro aspecto a destacar da arquitetura em camadas é o uso de interfaces padrões visando faci-litar reuso e manutenção. Interfaces bem definidas encapsulam componentes (com funcionalidades definidas) já testados, prática que permite o reuso e também auxilia na manutenção, já que toda e qualquer alteração necessária estaria confinada àquele componente.

Importância da Arquitetura de software

Todos esses fatores compreendem o projeto no nível arquitetural e estão diretamente relacionados com a orga-nização do sistema e, portanto, afetam os atributos de qualidade (também chamados de requisitos não funcionais) como desempenho, portabilidade, con-fiabilidade, disponibilidade, entre ou-tros. Se fizermos uma comparação entre

arquitetura de software (caracterizada, por exemplo, pelo estilo em camadas) e arquitetura ‘clássica’ (relativa à constru-ção de edificações), podemos observar que o projeto arquitetural é determinante para o sucesso do sistema.

A Tabela 2 destaca aspectos da re-presentação de projeto que captura elementos característicos da arquite-tura enquanto que as restrições estão associadas a atributos de qualidade e, portanto, servem como determinantes nas decisões do projeto arquitetural. Por exemplo, embora o uso de múltiplas camadas facilite a manutenção de um sistema de software, também contribui para degradar o desempenho do sistema. Uma tática tem sido reduzir o nível de acoplamento entre componentes para não comprometer o desempenho do sistema. Dessa forma, se adotarmos uma redução no nível de acoplamento dos compo-nentes, eles terão menor necessidade de comunicação entre si, o que resulta num melhor desempenho.

Hoje em dia, os processos de engenharia de software requerem o projeto arquite-tural de software. Por quê?

• É importante poder reconhecer as estruturas comuns existentes de modo que arquitetos de software (ou enge-nheiros de software realizando o papel de arquiteto de software – conforme Tabela 3) possam entender as relações existentes nos sistemas em uso e utilizar esse conhecimento no desenvolvimento de novos sistemas.

• O entendimento das arquiteturas per-mite aos engenheiros tomarem decisões sobre alternativas de projeto.

40 Engenharia de Software Magazine – Arquitetura de Software

• Uma especificação arquitetural é essencial para analisar e descrever propriedades de um sistema complexo, permitindo o engenheiro ter uma visão geral completa do sistema.

• O conhecimento de notações para des-crever arquiteturas permite engenheiros comunicarem novos projetos e decisões arquiteturais tomadas a outros membros da equipe.

Cabe destacar que, para que haja o en-tendimento da arquitetura, faz-se neces-sário ao engenheiro de software conhecer os estilos arquiteturais existentes, confor-me apresentado adiante. As propriedades de cada arquitetura, portanto, são depen-dentes do estilo arquitetural adotado. Por exemplo, o uso de uma notação padrão como a UML ajuda na representação de componentes e compartilhamento de informações do projeto.

Esses aspectos servem como indica-dores de uma maturidade inicial de engenharia de software. Outros aspectos compreendem uso e reuso de soluções existentes no desenvolvimento de novos sistemas. Para tanto, a prototipagem tem sido usada em projetos de natureza ino-vadora (bem antes da implementação ou aceitação de um produto acontecer).

Além disso, o aumento da complexi-dade e quantidade de requisitos dos sistemas dificulta cada vez mais atender às restrições de orçamento e cronograma. Atualmente, empresas têm procurado in-corporar estratégia de reuso de software, enfatizando o reuso centrado na arquite-tura para obter melhores resultados no desenvolvimento de sistemas. Note que a arquitetura de software serve como uma estrutura através da qual se tem o entendimento dos componentes de um sistema e de seus inter-relacionamentos. Em outras palavras, ela define a estrutura do sistema, de modo consistente para

implementações, já que está diretamente relacionada aos atributos de qualidade como confiabilidade e desempenho. A organização dos componentes num sis-tema de software impacta sobre a quali-dade apresentada por ele. Por exemplo, a adoção de uma arquitetura em camadas serve para modularizar o sistema bem como facilitar modificações. Entretanto, um número elevado de camadas (4 ou 5) pode degradar o desempenho do sistema se houver um elevado grau de acopla-mento entre os componentes.

Diversos benefícios decorrem da in-corporação da arquitetura de software como ‘elemento norteador’ do processo de desenvolvimento de software. Cabe destacar que a arquitetura pode:

• Prover suporte ao reuso – seus com-ponentes definidos e testados podem ser reaproveitados em novas aplicações.

• Servir de base à estimação de custos e gerência do projeto – a existência de uma arquitetura bem definida permite ao gerente de projeto adequadamente alocar tarefas de, por exemplo, implementação de componentes e melhor estimar o tem-po e tamanho de equipe necessária para realização de um projeto.

• Servir de base para análise da con-sistência e dependência – o arquiteto de software pode verificar se a arquitetura de software adotada suporta os atributos de qualidade desejados de modo consis-tente e avaliar o nível de dependência dos atributos de qualidade em relação à arquitetura. Para tanto, ele faz a análise arquitetural que verifica o suporte ofere-cido pela arquitetura a um conjunto de atributos de qualidade (como desempe-nho, portabilidade e confiabilidade).

• Ser utilizada para determinar atribu-tos de qualidade do sistema – o arquiteto de software faz a análise arquitetural a fim de determinar os atributos de quali-dade. Trata-se de um processo iterativo.

• Atuar como uma estrutura para atender os requisitos do sistema – a ar-quitetura ajuda a definir os requisitos funcionais, que compreendem o con-junto de funcionalidades do sistema de software, e requisitos não funcionais (ou atributos de qualidade) que determinam as características visíveis ao usuário como desempenho e confiabilidade.

Uma questão que você deve estar se fazendo é: Por que apenas recentemente houve o foco na arquitetura de software?

A resposta é simples: economia e reuso.Anteriormente não havia forte ênfase

na disciplina de engenharia de software, fato este ocorreu com o amadurecimento desta nova área ao longo de toda a déca-da de 1990. Tudo motivou o surgimento de um novo profissional: o arquiteto de software.

Habilidades do Arquiteto de software

Perceba que o arquiteto de software tem um papel de suma importância para estratégia adotada pela empresa. Ele precisa ter profundo conhecimento do domínio, das tecnologias existentes e de processos de desenvolvimento de software. Uma síntese de um conjunto desejado de habilidades para um arqui-teto de software e das tarefas atribuídas a ele são apresentados na Tabela 3. Note que a prototipagem é uma tarefa comum onde o arquiteto desenvolve um protóti-po para ‘testar’ uma possível solução. Já a simulação pode ser empregada quando ele necessita avaliar o suporte oferecido a determinado atributo de qualidade como o desempenho. Por outro lado, a experimentação pode ocorrer quando o arquiteto precisa testar um novo compo-nente recém implementado.

Entendo o Estilo ArquiteturalO estilo arquitetural serve para carac-

terizar a arquitetura de software de um sistema, possibilitando a:

• Identificação de componentes – o arquiteto identifica quais os principais elementos que tem funcionalidades bem definidas como, um componente de ca-dastro de (informações de) usuários e um componente de autenticação de usuário numa aplicação Web.

• Identificação de mecanismos de inte-ração – a comunicação entre objetos por

Habilidades desejadas Tarefas atribuídas

Conhecimento do domínio e tecnologias relevantes Modelagem

Conhecimento de questões técnicas para desenvolvimento de sistemas Análise de compromisso e de viabilidade

Conhecimento de técnicas de levantamento de requisitos, e de métodos de modelagem e

desenvolvimento de sistemasPrototipagem, simulação e experimentação

Conhecimento das estratégias de negócios da empresa Análise de tendências tecnológicas

Conhecimento de processos, estratégias e produtos de empresas concorrentes ‘Evangelizador’ de novos arquitetos

Tabela 3. Habilidades e tarefas de um arquiteto de software.

Edição 01 – Engenharia de Software Magazine 41

PROJETO

meio da troca de mensagens constitui uma forma através da qual os componen-tes de software interagem entre si.

• Identificação de propriedades – o arquiteto pode analisar as propriedades oferecidas por cada estilo baseado na or-ganização dos componentes e nos meca-nismos de interação, conforme discutido abaixo.

O estilo arquitetural considera o sistema por completo, permitindo o engenheiro ou arquiteto de software determinar como o sistema está organizado, ca-racterizando os componentes e suas interações. Em outras palavras, ele determina uma estrutura para todos os componentes do sistema. O estilo arquitetural compreende o vocabulário de componentes e conectores, além da topologia empregada. Mas, você pode estar se questionando: Por que saber o estilo arquitetural é importante?

Os sistemas de grande porte exigem níveis de abstração mais elevados (justa-mente onde se têm os estilos) que servem de apoio à compreensão do projeto e comunicação entre os participantes do projeto. Ele é determinante no entendi-mento da organização de um sistema de software.

Mas, o que se ganha em saber o estilo arquitetural? Ele oferece:

• Suporte a atributos de qualidade (ou requisitos não funcionais);

• Diferenciação entre arquiteturas;• Menos esforço para entender um projeto;• Reuso de arquitetura e conhecimento

em novos projetos.

Conhecer o estilo arquitetural permite ao engenheiro antecipar, por meio da análise (arquitetural), o impacto que o es-

tilo (isto é a classe de organização do sis-tema) terá sobre atributos de qualidade. Adicionalmente, facilita a comunicação do projeto, além do reuso da arquitetura (da solução).

A caracterização e existência de estilos arquiteturais constituem sinais de ama-durecimento da engenharia de software, uma vez que permite ao engenheiro or-ganizar e expressar o conhecimento de um projeto de modo sistemático e útil. Note que uma forma de codificar conhe-cimento é dispor de um vocabulário de um conjunto de conceitos (terminologia, propriedades, restrições), estruturas (componentes e conectores) e padrões de uso existentes. Conectores são empre-gados na interação entre componentes como, tubo (pipe) no estilo tubos e filtros, e mensagens no estilo de objetos.

Exemplificando o estilo pipes (tubos) e filtros

O estilo arquitetural de tubos e filtros considera a existência de uma rede através da qual dados fluem de uma extremidade à outra. O fluxo de dados se dá através tubos e os dados sofrem transformações quando são processados nos filtros.

O tubo provê uma forma unidirecional do fluxo de dados uma vez que ele atua como uma espécie de ‘condutor’ para o fluxo de dados entre a fonte até um destino. O exem-plo mais comumente conhecido do estilo tubos e filtros é aquele usado no sistema operacional Unix, isto é: who | sort

A linha de comando acima executa o co-mando who (uma única vez) e encaminha sua saída ao programa sort, conforme ilustrado na Figura 1. O resultado da execução do programa who é uma lista

de todos os usuários que se encontram conectados (a um servidor específico) naquele momento, enquanto que o pro-grama sort ordena essa lista de usuários em ordem alfabética (de login).

Outro exemplo compreende a arqui-tetura básica de um compilador como ilustrado na Figura 2. Observe que cada etapa do processo de compilação é reali-zada separadamente por um componente (ou seja, um filtro).

Um compilador tem duas funções bási-cas: análise e síntese. A função de análise é implementada por três componentes: analisadores léxico, sintático e semân-tico. Já a função de síntese compreende os componentes de otimização e geração de código. Observe que essa arquitetura oferece suporte à portabilidade e reuso.

Entretanto, essa arquitetura evoluiu com a introdução de um componente ge-rador intermediário de código, conforme ilustrado na Figura 3, a fim de tornar a arquitetura do compilador ‘mais portá-vel’ a várias plataformas com o objetivo de reduzir custos no desenvolvimento de diferentes produtos, ou seja, compilado-res para diferentes plataformas.

Uma nova evolução da arquitetura de compiladores a fim de atender a necessi-dade de integração (do compilador) com outras ferramentas, tais como editor e depurador, resultou na arquitetura mos-trada na Figura 4.

É importante salientar que a evolução da arquitetura de compilador foi resul-tado, principalmente, da necessidade de dar suporte ao requisito de portabilidade. Nesse sentido, pode-se destacar como vantagens:

• Problema ou sistema pode ser decom-posto de forma hierárquica;

Figura 1. Exemplo do estilo arquitetural de tubos e filtros

42 Engenharia de Software Magazine – Arquitetura de Software

Figura 2. Arquitetura básica de um compilador (seguindo estilo arquitetural de tubos e filtros)

Figura 3. Evolução inicial da arquitetura de um compilador.

Figura 4. Nova evolução da arquitetura de um compilador.

Edição 01 – Engenharia de Software Magazine 43

PROJETO

• Função do sistema é vista como com-posição de filtros;

• Facilidade de reuso, manutenção e extensão, que emprega abordagem caixa preta, onde cada componente tem funcionalidade e interface bem definida, facilitando alterações nos mesmos;

• Desempenho pode ser incrementado através do processamento paralelo de filtros, já que a ativação e uso do com-ponente ocorre com o fluxo de dados, permitindo que componentes com funcionalidades independentes sejam executados de forma concorrente.

Apesar das vantagens acima apontadas, o estilo de tubos e filtros coloca ênfase no modo ‘batch’, tornando difícil seu uso em aplicações interativas e em situações que exija ordenação de filtros. Outra questão técnica a ser observada é a possibilidade de haver deadlock com o uso de buffers finitos (para armazenamento temporário de dados). Esse estilo arquitetural tem sido empregado em razão das vantagens anteriormente destacadas.

Exemplos de outros estilos arquiteturais compreendem:

• Camadas – a arquitetura do sistema de software é organizada num conjunto de camadas, oferecendo maior flexibilidade e suporte a portabilidade. A identificação do nível de abstração nem sempre é evi-dente e perde-se desempenho à medida que o número de camadas cresce. Exem-plo desse estilo compreende os sistemas Web de múltiplas camadas que separa cliente, servidores de aplicação, servido-res Web e outros clientes Web.

• Objetos – essa arquitetura combina dados com funções numa única entidade (objeto), facilitando a decomposição do problema, manutenção e reuso. É comum utilizar a arquitetura orientada a objetos em sistemas de informação como siste-mas de consulta e empréstimos online de bibliotecas de instituições de ensino que dispõem de componentes de cadastro de usuários e componentes de autenticação de usuários. Note que componentes similares existem em outros sistemas de informações, tais como sites de conteúdos (jornais e revistas) que exigem cadastro e autenticação de qualquer usuário antes de disponibilizar o conteúdo.

• Invocação implícita – diferentemente do estilo baseado em objetos, no qual um componente invoca outro diretamente

por meio da passagem de mensagens, a invocação implícita requer que compo-nentes interessados em receber ou divul-gar eventos se registrem para receber ou enviar. Um exemplo de sistema empre-gando mensagens são listas de notícias e fórum que possuem componentes de registro de novos usuários acoplados ao componente de autenticação. Perceba que esse tipo de sistema apenas permite que o usuário tenha acesso ao conteúdo se este for devidamente autenticado e registrado.

• (Sistemas orientados a) Eventos – trata-se de um estilo no qual os componentes podem ser objetos ou processos e a

interface define os eventos de entrada e saída permitidos. Conectores são implementados através do ‘binding’ evento-procedimento. Assim, eventos são registrados junto com eventos e os componentes interagem entre si atra-vés do envio de eventos. Dessa forma, quando um evento é recebido, o(s) procedimento(s) associado(s) a este even-to é(são) invocado(s). Um interessante exemplo deste estilo são jogos online, como discutido na seção seguinte.

• Quadro negro (ou Blackboard) – esse estilo faz uso de um repositório central de dados circundado por um conjunto de componentes (ou células) de informações.

Figura 5. Combinação de estilos.

Figura 6. Jogo Connect4.

44 Engenharia de Software Magazine – Arquitetura de Software

Figura 7. Arquitetura do Connect4

Esses componentes contêm informações necessárias à solução de problemas. Os dados da solução de problemas são man-tidos na base de dados compartilhada (o repositório), o qual é denominado de quadro negro. O exemple mais comum desse estilo é um sistema especialista.

• Combinação de estilos – Outros sistemas, na prática, combinam estilos arquiteturais resultando numa heteroge-neidade, como ilustrado na Figura 5, que agrega o estilo de objetos e camadas.

Exemplificando o estilo combinado de objetos e eventos

Jogos online e de computador têm se tornado comuns atualmente com a popularidade da Internet. Costuma-se categorizar os jogos em:

• Baseados na vez – são jogos nos quais cada ação é baseada na vez do jogador como jogo da velha e xadrez.

• Baseados em eventos – são jogos onde eventos podem ocorrer em qualquer instante e estes ditam o ritmo do jogo. Exemplos compreendem simuladores de vôo e corridas de carro.

Por exemplo, quando os jogos são dis-ponibilizados na Internet, costuma-se denominá-los de jogos online ou jogos para Internet, possibilitando ao usuário jogar contra a máquina (computador).

Um exemplo desse tipo de jogo de com-putador é o Connect4 que tem como meta para cada jogador conectar quatro peças da mesma cor, verticalmente, ho-rizontalmente ou diagonalmente. Cada jogador deve depositar uma peça na parte superior da coluna selecionada e esta cai até preencher a lacuna inferior da coluna (selecionada), conforme ilustrado na Figura 6. Note que o quadro contém 7 colunas e 6 linhas, um indicador de status do jogo e um seletor manual (utilizado para selecionar a coluna na qual uma peça será depositada).

A arquitetura de software dessa aplica-ção é apresentada na Figura 7. O compo-nente jogador computacional (que dispõe de recursos de inteligência artificial para simular um jogador humano) contém uma classe Connect4State que trata a maioria das requisições para verificar se algum jogador venceu o jogo, e também dispõe de mecanismo para atualizar o es-tado do jogo após uma jogada do jogador computacional.

O componente (máquina) de inferência contém uma classe para tratar as jogadas feitas pelos jogadores bem como deter-minar a melhor jogada para o jogador computacional.

O componente de interface de usuário contém uma classe que carrega os arqui-vos de imagem e áudio, trata as requisi-

ções feitas através do mouse e invoca um método que checa se houve vitória, derro-ta ou empate, além de fazer a atualização da interface gráfica. Um possível estado final desse jogo é mostrado na Figura 8, onde na terceira linha há um conjunto de quatro peças na cor azul, indicando que o computador completou primeiro a conexão de quatro peças na mesma cor (a cor do usuário humano é vermelha).

A combinação estilo arquitetural orien-tado para eventos e objetos permite a decomposição de um sistema em termos de objetos (componentes de inferência, componente de interface gráfica e com-ponente jogador computacional) que são mais independentes além de possibilitar que atividades de computação e coor-denação (de eventos) sejam realizadas separadamente. Há ainda a facilidade de reuso e manutenção, já que novos objetos podem ser facilmente adicionados. Essa característica, e interfaces bem definidas, facilitam ainda a integração.

O mecanismo de invocação é não determinístico (isto é, ocorre de forma aleatória) uma vez que considera a re-cepção de eventos. Adicionalmente, os componentes têm seus dados preserva-dos de qualquer modificação acidental já que essas informações são encapsu-ladas em objetos, facilitando também a integração.

Edição 01 – Engenharia de Software Magazine 45

PROJETO

Figura 8. Possível estado final do jogo Connect4

Importância do ReusoÉ importante perceber de tudo o que foi

apresentado e discutido que um modelo arquitetural oferece suporte ao reuso de várias formas. Por exemplo, pode se ter arquiteturas reusáveis que forneçam a organização e o modelo de coordenação, permitindo seu uso em diversos siste-mas. Além disso, podem-se reutilizar componentes, já testados, em mais de um sistema. Disso tudo, o mais importante é o reuso do conhecimento que tem im-pacto direto na definição da arquitetura de software candidata à solução de um problema (ou sistema).

A ampla variedade de plataformas e utilitários, juntamente com a pressão do mercado para reduzir o tempo de entrega de produtos de software e elevar a produtividade, faz com que o reuso seja apontado como uma das chaves de sucesso para empresas.

O reuso de artefatos (ou componentes) é possível quando o projeto arquitetural está incorporado e orienta o processo de desenvolvimento de software. Isto, como discutido, permite antever os atributos de qualidade que o sistema suporta e também administrar o cronograma de execução do projeto. Portanto, impac-tando positivamente o reuso e economia do sistema.

O quadro apresentado na Tabela 4

sumariza as principais características da arquitetura de software e pontos im-portantes na capacitação e reciclagem de engenheiros e arquitetos de software.

ConclusãoEmbora arquitetura de software seja

um tema relevante no contexto atual para desenvolvimento de sistemas de software que têm seu foco no reuso e, portanto, consideram tanto o aspecto econômico quanto a produtividade, sua incorpora-ção nos processos de desenvolvimento de software tem sido observada apenas em empresas de grande porte e em poucas de médio porte. Entretanto, esse cenário começa a mudar dada a crescente necessi-dade de integração de sistemas a qual tem

Características de arquitetura de software Uso prático da arquitetura de software

Constitui um artefato reutilizávelComo um arquiteto de software pode organizar o projeto e

código de um sistema

Dispõe de mecanismos de interconexão Como um arquiteto avalia e implanta arquiteturas de software em sistemas

Oferece um vocabulário de projeto e separa funcionalidadesComo um arquiteto de software atua no processo de

desenvolvimento de software

Vincula o projeto a atributos de qualidadeComo um arquiteto avalia a qualidade do código baseada

em métricas de produto

Suporta o desenvolvimento baseado em componentes e

linha de produto (quando os requisitos são considerados

para uma família de sistemas)

Como usar arquitetura como parâmetro para reduzir custos de

manutenção e amortizar custos de desenvolvimento

Tabela 4. Características e uso prático da arquitetura de software

a arquitetura de software como premissa. Assim, o fator econômico tem sido e será o determinante da sobrevivência da em-presas de software. Novas estratégias de desenvolvimento de sistemas devem ser para o reuso e com reuso (de componentes de software) e o pilar principal dessas estratégias é a arquitetura de software. Há, portanto, uma necessidade premente de formação de capital humano com tais qualificações.

História da Indústria de Software

www.softwarehistory.org

An introduction to software architecture

http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/

intro_softarch.html

SEI’s Software Architecture Technology Initiative

www.sei.cmu.edu/architecture/sat_init.html

Worldwide Institute of Software Architects

www.wwisa.org/wwisamain/index.htm

The Software Architecture Portal

http://www.softwarearchitectureportal.org/

Links