Conceitos: Arquitetura de Software
Tópicosl Introdução
l Descrição da Arquitetura ¡ Visões de Arquitetura
¡ Um Conjunto Típico de Visões e Arquitetura l Enfoque da Arquitetura
¡ Padrões de Arquitetura ¡ Estilo da Arquitetura ¡ Plantas da Arquitetura
¡ O Processo de Desenvolvimento da Arquitetura
Introdução
A arquitetura de software é um conceito de fácil compreensão e que a maioria dos engenheiros entende de modo intuitivo, especialmente quando se tem um pouco de experiência. No entanto, é difícil defini-lo com precisão. Em particular, é difícil desenhar uma linha bem definida entre o design e a arquitetura — a arquitetura é um aspecto do design que se concentra em alguns recursos específicos.
Em An Introduction to Software Architecture, David Garlan e Mary Shaw sugerem que a arquitetura de software é um nível de design voltado para questões que vão: "além dos algoritmos e das estruturas de dados da computação. A projeção e a especificação da estrutura geral do sistema emergem como um novo tipo de problema. As questões estruturais incluem organização total e estrutura de controle global;
protocolos de comunicação, sincronização e acesso a dados; atribuição de funcionalidade a elementos de design; distribuição física; composição de elementos de design; escalonamento e desempenho; e seleção entre as alternativas de design." [GAR93]
Há mais a arquiteturar do que apenas a estruturar. O artigo Working Group on Architecture da IEEE define a arquitetura como "o conceito de nível mais alto de um sistema em seu ambiente" [IEEE98]. Ele também abrange a "adequação" à integridade do sistema, às restrições econômicas, às preocupações estéticas e ao estilo. Ele não se limita a um enfoque interno, mas leva em consideração o sistema como um todo em seu ambiente de usuário e de desenvolvimento, ou seja, um enfoque externo.
No RUP, a arquitetura de um sistema de software (em um determinado ponto) é a organização ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com elementos
constituídos de componentes e interfaces sucessivamente menores.
Descrição da Arquitetura
Para falar e tirar conclusões sobre a arquitetura do software, primeiro defina uma representação de arquitetura, uma forma de descrever aspectos importantes de uma arquitetura. No RUP, essa descrição é capturada em Documento de Arquitetura de Software.
Visões de Arquitetura
arquitetura aborda um determinado conjunto de questões específicas dos envolvidos no processo de desenvolvimento: usuários finais, designers, gerentes, engenheiros de sistema, mantenedores, etc.
As visões capturam as principais decisões de design estruturais mostrando como a arquitetura de software é decomposta em componentes e como os componentes são ligados pelos conectores para gerar formulários úteis [PW92]. Essas alternativas de design devem estar associadas aos requisitos, tanto funcionais quanto suplementares, e a outras restrições. Essas alternativas, por sua vez, impõem restrições adicionais aos requisitos e às futuras decisões de design em um nível inferior.
Um Conjunto Típico de Visões de Arquitetura
A arquitetura é representada por uma série de visões de arquitetura diferentes, que, em sua essência, são fragmentos que ilustram os elementos "significativos em termos de arquitetura" dos modelos. No RUP, você parte de um conjunto típico de visões, denominado "modelo de visão 4+1" [KRU95]. Ele é composto pelas seguintes visões:
l A Visão de Casos de Uso, que contém casos de uso e cenários que abrangem comportamentos
significativos em termos de arquitetura, classes ou riscos técnicos. Ela é um subconjunto do modelo de casos de uso.
l A Visão Lógica, que contém as classes de design mais importantes e sua organização em pacotes e subsistemas, e a organização desses pacotes e subsistemas em camadas. Ela contém algumas realizações de caso de uso. É um subconjunto do modelo de design.
l A Visão de Implementação, que contém uma visão geral do modelo de implementação e sua
organização em termos de módulos em pacotes e camadas. A alocação de pacotes e classes (da Visão Lógica) nos pacotes e módulos da Visão de Implementação também é descrita. Ela é um subconjunto do modelo de implementação.
l A Visão de Processos, que contém a descrição das tarefas (processo e threads) envolvidas, suas interações e configurações, e a alocação dos objetos e classes de design em tarefas. Essa visão só precisará ser usada se o sistema tiver um grau significativo de simultaneidade. No RUP, ela é um subconjunto do modelo de design.
l A Visão de Implantação, que contém a descrição dos vários nós físicos da maior parte das
configurações comuns de plataforma e a alocação das tarefas (da Visão de Processos) nos nós físicos. Essa visão só precisará ser usada se o sistema estiver distribuído. Ela é um subconjunto do modelo de implantação.
As visões de arquitetura estão documentadas em um Documento de Arquitetura de Software. Você pode prever visões adicionais para expressar várias questões especiais: visão da interface do usuário, visão de segurança, visão de dados, e assim por diante. No caso dos sistemas simples, você pode omitir algumas das visões contidas no modelo de visão 4+1.
Enfoque da Arquitetura
Embora as visões acima possam representar todo o design de um sistema, a arquitetura se preocupa somente com alguns aspectos específicos:
l A estrutura do modelo — os padrões organizacionais, por exemplo, a divisão em camadas.
l Os elementos essenciais — os casos de uso críticos, as classes principais, os mecanismos comuns, etc., em oposição a todos os elementos presentes no modelo.
l Alguns cenários-chave mostrando os principais fluxos de controle em todo o sistema.
Basicamente, as visões de arquitetura são abstrações ou simplificações do design inteiro, em que as características importantes são ressaltadas, deixando os detalhes de lado. Essas características serão importantes quando os seguintes aspectos estiverem em discussão:
l Evolução do sistema — passagem para o próximo ciclo de desenvolvimento. l Reutilização da arquitetura, ou de partes dela, no contexto de uma linha de produto.
l Avaliação das qualidades suplementares, como desempenho, disponibilidade, portabilidade e segurança. l Atribuição do trabalho de desenvolvimento a equipes ou subcontratantes.
l Decisões sobre a inclusão dos componentes desenvolvidos internamente e adquiridos prontos para serem usados.
l Inserção em um sistema mais amplo.
Padrões de Arquitetura
Os padrões de arquitetura são formulários prontos que solucionam problemas arquiteturais recorrentes. Um framework de arquitetura ou uma infra-estrutura de arquitetura(middleware) é um conjunto de componentes em que você pode criar um determinado tipo de arquitetura. Várias das maiores dificuldades arquiteturais devem ser resolvidas no framework ou na infra-estrutura, geralmente, direcionadas a um domínio específico: comando e controle, departamento de informática, sistema de controle, etc.
Exemplos de Padrões de Arquitetura
[O BUS96] agrupa padrões de arquitetura de acordo com as características dos sistemas em que eles são mais aplicáveis, com uma categoria tratando das questões gerais de estruturação. A tabela a seguir mostra as categorias apresentadas em [BUS96] e os padrões nelas contidos.
Duas dessas categorias são apresentadas mais detalhadamente aqui, a fim de esclarecer essas idéias. Para obter uma abordagem completa, consulte [BUS96]. Os padrões são apresentados neste formulário amplamente utilizado:
l Nome do padrão l Contexto
l Problema
¡ Impõe a descrição de vários aspectos problemáticos que devem ser considerados l Solução ¡ Fundamentos ¡ Contexto resultante Categoria Padrão Estrutura Camadas Pipes e Filtros Quadro-negro Sistemas Distribuídos Broker
Sistemas Interativos Modelo-Visão-Controlador Apresentação-Abstração-Controle Sistemas Adaptáveis Reflexo
¡ Exemplos Nome do Padrão
Camadas
Contexto
Um sistema grande que requer decomposição. Problema
Um sistema que deve resolver as questões em diferentes níveis de abstração. Por exemplo: as questões de controle de hardware, as questões de serviços comuns e as questões específicas de domínio. Seria
extremamente indesejável escrever componentes verticais que lidem com essas questões em todos os níveis. Uma mesma questão deveria ser resolvida (possivelmente de maneira inconsistente) várias vezes em
diferentes componentes. Força
l As partes do sistema devem ser substituíveis
l As alterações efetuadas nos componentes não devem ser irregulares l Responsabilidades similares devem ser agrupadas juntas
l Tamanho dos componentes—componentes complexos talvez precisem ser decompostos Solução
Estruture os sistemas em grupos de componentes que formem camadas umas sobre as outras. Faça com que as camadas superiores utilizem os serviços somente das camadas abaixo (nunca das camadas acima). Tente não usar serviços que não sejam os da camada diretamente abaixo (não pule camadas, a menos que as camadas intermediárias somente adicionem componentes de acesso).
Exemplos:
Uma arquitetura estritamente em camadas estabelece que os elementos de design (classes, componentes, pacotes, subsistemas) usem somente os serviços da camada abaixo delas. Os serviços podem incluir tratamento de eventos, tratamento de erros, acesso a banco de dados, etc. Ela contém mecanismos mais palpáveis, em oposição às chamadas em nível de sistema operacional bruto documentadas na camada inferior.
2. Camadas de Sistema de Negócios
específicas de aplicativo e camadas horizontais de infra-estrutura. Observe que a meta é ter "chaminés" de negócios muito curtas e estimular a freqüência entre aplicativos. Do contrário, é provável que várias pessoas resolvam o mesmo problema, possivelmente de maneira diferente. Consulte Diretrizes: Divisão em Camadas para obter mais informações sobre este padrão. Nome do Padrão
Quadro-negro
Contexto
Um domínio em que nenhuma abordagem fechada (algorítmica) para resolver um problema é conhecida ou viável. Os exemplos são os sistemas de IA, o reconhecimento de voz e os sistemas de inspeção.
Problema
Vários agentes de resolução de problemas (agentes de conhecimento) devem cooperar para solucionar um problema que não pode ser resolvido por um só agente. Os resultados do trabalho de cada agente devem estar acessíveis a todos os outros agentes. Assim, eles poderão avaliar se podem ou não contribuir para encontrar uma solução e divulgar os resultados de seus trabalhos.
Força
l A seqüência em que os agentes de conhecimento podem contribuir para solucionar o problema não é determinista e talvez dependa das estratégias de solução de problemas l A colaboração de vários agentes (resultados ou soluções parciais) pode ter diferentes
representações
l Os agentes não sabem da existência de cada um dos outros agentes, mas podem avaliar as contribuições divulgadas de cada um deles
Solução
Uma série de agentes de conhecimento tem acesso a um armazenamento de dados compartilhados denominado Quadro-negro. O quadro-negro fornece uma interface para inspecionar e atualizar seu conteúdo. O módulo/objeto Controle ativa os agentes seguindo algumas estratégias. Após a ativação, um agente inspeciona esse quadro-negro para ver se ele pode contribuir na resolução do problema. Se o agente determinar que é possível contribuir, o objeto Controle permitirá que os agentes coloquem sua solução parcial (ou final) no quadro.
Este exemplo mostra a visão estrutural ou estática modelada através da UML. Ele será parte de uma colaboração parametrizada, que será restringida a parâmetros reais para instanciar o padrão.
Estilo da Arquitetura
Uma arquitetura de software, ou somente uma visão de arquitetura, pode ter um atributo chamado estilo de
arquitetura, que reduz o conjunto de formulários que podem ser escolhidos e impõe um determinado grau
de uniformidade à arquitetura. O estilo pode ser definido por um conjunto de padrões, ou pela escolha de componentes ou conectores específicos que funcionarão como os tijolos básicos da construção. Em um determinado sistema, alguns estilos podem ser capturados como parte da descrição da arquitetura em um
guia de estilo de arquitetura — parte de um documento de guia de design no RUP. O estilo desempenha um papel vital na compreensão e integridade da arquitetura.
Plantas da Arquitetura
A representação gráfica de uma visão de arquitetura é denominada planta da arquitetura. Nas várias visões descritas acima, as plantas são compostas pelos seguintes diagramas da Unified Modeling Language [UML99]:
l Visão lógica. Diagramas de classe, máquinas de estado e diagramas de objetos
l Visão de processos. Diagramas de classes e diagramas de objetos (tarefa abrangente — processos e threads)
l Visão de implementação. Diagrama de componentes l Visão de implantação. Diagramas de implantação
l Visão de casos de uso. Os diagramas de casos de uso representam casos de uso, atores e classes de design normais. Os diagramas de seqüências representam objetos de design e suas colaborações.
O Processo de Desenvolvimento da Arquitetura
No RUP, a arquitetura é basicamente um resultado do fluxo de trabalho Análise e Design. Como o projeto restabelece esse fluxo de trabalho a cada iteração, a arquitetura é desenvolvida, refinada e aprimorada. Como cada iteração inclui a integração e o teste, a arquitetura é bastante sofisticada pelo tempo que o
produto é liberado. Esta arquitetura é o enfoque principal das iterações da fase de elaboração. Ao final dessa fase, a arquitetura é normalmente analisada.
Copyright (c) 1987 - 2001 Rational Software Corporation
