Análise e Design: Visão Geral

As finalidades da disciplina Análise e Design são:

• Transformar os requisitos em um design do sistema a ser criado.

• Desenvolver uma arquitetura sofisticada para o sistema.
• Adaptar o design para que corresponda ao ambiente de implementação, projetando-o
para fins de desempenho.

Definir uma Sugestão de Arquitetura

Finalidade

• Criar um esboço inicial da arquitetura do sistema

oDefinir um conjunto inicial de elementos significativos em termos de arquitetura que
servirá como base para a análise
o Definir um conjunto inicial de mecanismos de análise
o Definir a disposição em camadas e organização iniciais do sistema
o Definir as realizações de caso de uso que serão tratadas na iteração atual
• Identificar as classes de análise dos casos de uso significativos em termos de arquitetura
• Atualizar as realizações de caso de uso com as interações das classes de análise

1
Como Definir a Equipe

Essas atividades são melhor realizadas por uma equipe pequena composta por
participantes de várias funções. As questões que, em geral, são significativas em termos de
arquitetura incluem o desempenho, o escalonamento, a sincronização de processos e threads, e
a distribuição. A equipe deve também incluir membros que tenham experiência em domínio e
que possam identificar as principais abstrações. Além disso, a equipe deve ter experiência na
organização do modelo e na disposição em camadas. Ela precisará reunir todos esses threads
discrepantes em uma arquitetura coesa e coerente (embora preliminar).

Orientações de Trabalho

O trabalho é melhor realizado em várias sessões, talvez executado em alguns dias (ou
em semanas e meses, no caso de sistemas grandes).

Atividade: Análise Arquitetural

A análise arquitetural concentra-se em definir uma sugestão de arquitetura e restringir

as técnicas de arquitetura a serem utilizadas no sistema. Ela conta com a experiência obtida
com sistemas ou domínios de problema semelhantes para restringir e enfocar a arquitetura de
modo que o esforço não seja desperdiçado na 'redescoberta arquitetural'. Em sistemas nos
quais já existe uma arquitetura bem-definida, é possível omitir a análise arquitetural, que é
vantajosa principalmente quando se está desenvolvendo sistemas novos e inéditos.

2
 Desenvolver a Visão Geral da Arquitetura

A visão geral da arquitetura é criada no início do ciclo de vida de um projeto,

possivelmente já na fase de iniciação, visando facilitar o planejamento do sistema,
investigando e avaliando opções de arquitetura de nível superior. Busca, também, transmitir
para o patrocinador, às equipes de desenvolvimento e outros envolvidos, um entendimento
inicial da estrutura de nível superior do sistema desejado.
Basicamente, tem como finalidade:

• Identificar os recursos que podem ser relevantes para o projeto.

• Analisar os ajustes necessários e as lacunas existentes entre os recursos e os requisitos do
projeto.
• Decidir por basear ou não áreas do sistema nos recursos.
• Localizar e listar os recursos que podem ser reutilizados no projeto. Executar uma
avaliação preliminar para se certificar de que o suporte necessário está disponível.

Atividade: Analisar Casos de Uso

• Identificar as classes que realizam o fluxo de eventos de um caso de uso.
• Distribuir o comportamento do caso de uso entre essas classes utilizando realizações de
casos de uso.
• Identificar as responsabilidades, os atributos e as associações das classes.
• Observar a utilização dos mecanismos de arquitetura.

CONCEITOS

ARQUITETURA DE SOFTWARE

• 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." [Descrição da Arquitetura

3
 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 Visões de Arquitetura

Optamos por representar a arquitetura de software em várias visões de arquitetura.

Cada visão de 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 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" [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:

o A estrutura do modelo — os padrões organizacionais, por exemplo, a Padrões

de Arquitetura

Os

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
Microkernel
Duas dessas categorias são apresentadas mais detalhadamente aqui, a fim de esclarecer essas
idéias. Para obter uma abordagem completa, consulte [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

• As partes do sistema devem ser substituíveis

4
 • As alterações efetuadas nos componentes não devem ser irregulares
• Responsabilidades similares devem ser agrupadas juntas
• 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:

1. Camadas Genéricas

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

5
 O diagrama acima mostra um outro exemplo de divisão em camadas, onde há camadas
verticais 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.

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

• 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

6
 • A colaboração de vários agentes (resultados ou soluções parciais) pode ter diferentes
representações

• 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.

Exemplo:

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 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 [O Processo de Desenvolvimento da Arquitetura

No RUP, a arquitetura é basicamente um resultado do

7
Abordagens Comuns da Divisão em Camadas

A divisão em camadas representa um agrupamento ordenado de funcionalidades, sendo

que: (a) a funcionalidade específica de aplicativo está localizada nas camadas superiores,
(b) a funcionalidade que abrange os domínios de aplicativos se encontra nas camadas
intermediárias e (c) a funcionalidade específica do ambiente de implantação está nas
camadas inferiores.

O número e a composição das camadas dependem da complexidade do domínio do

problema e do espaço para solução:

o Em geral, há apenas uma única camada específica de aplicativo.

o Nos domínios em que sistemas anteriores foram desenvolvidos ou sistemas de
grande porte são compostos de sistemas interoperacionais menores, há uma grande
necessidade de compartilhar as informações entre as equipes de design.
Conseqüentemente, para maior clareza, é provável que a camada específica de negócios
exista parcialmente e esteja estruturada em várias camadas.
o Os espaços para solução que são suportados por produtos de middleware e nos
quais o software de sistema complexo desempenha um papel importante terão camadas
inferiores bem desenvolvidas, talvez com várias camadas de middleware e software de
sistema.

Os subsistemas devem ser organizados em camadas com subsistemas específicos de

aplicativo localizados nas camadas superiores da arquitetura, subsistemas específicos de
operação e hardware nas camadas inferiores da arquitetura, e serviços para fins genéricos
nas camadas de middleware.

Veja a seguir um exemplo de arquitetura com quatro camadas:

o A camada superior, camada de aplicativo, contém serviços específicos de

aplicativo.
o A camada seguinte (camada específica de negócios) contém componentes
específicos de negócios, usados em diversos aplicativos.
o A camada de middleware contém componentes como construtores GUI,
interfaces para sistemas de gerenciamento de banco de dados, serviços de sistemas
operacionais que não dependem de plataforma e componentes OLE, como planilhas e
editores de diagramas.
o A camada inferior (camada de software de sistema) contém componentes
como sistemas operacionais, bancos de dados, interfaces para hardware específico, etc.

8
 Uma estrutura dividida em camadas, desde o nível mais genérico de funcionalidade
até os níveis mais específicos de funcionalidade.

Diretrizes da Divisão em Camadas

A divisão em camadas permite um particionamento lógico de subsistemas em

diversos conjuntos, com determinadas regras sobre como estabelecer relacionamentos entre
camadas. Essa divisão permite restringir dependências entre subsistemas, fazendo com que
o sistema seja acoplado mais livremente e, dessa forma, mantido com mais facilidade.

Os critérios para agrupar subsistemas seguem alguns padrões:

o Visibilidade. Os subsistemas só podem depender de subsistemas na mesma

camada e na camada inferior seguinte.
o Volatilidade.
Nas camadas superiores, insira elementos que variam quando os
requisitos de usuário são alterados.
Nas camadas inferiores, insira elementos que variam quando a
plataforma de implementação (hardware, idioma, sistema operacional, banco de
dados, etc.) é alterada.
Entre essas camadas, insira elementos que geralmente se aplicam a
diversos tipos de sistemas e ambientes de implementação.
Acrescente camadas quando partições adicionais nessas categorias
amplas ajudarem a organizar o modelo.
o Generalidade. Elementos abstratos do modelo costumam ser inseridos em
camadas inferiores no modelo. Se não forem específicos da implementação, ficarão
geralmente próximos das camadas intermediárias.
o Número de Camadas. Para um sistema pequeno, três camadas são suficientes.
Para um sistema complexo, cinco a sete camadas costumam ser suficientes. Para
qualquer grau de complexidade, o uso de mais de dez camadas deve ser visto com
suspeita, que deverá aumentar com o número de camadas. Algumas regras práticas são
apresentadas abaixo:

9
 Número de Classes Número de Camadas
0 - 10 A divisão em camadas não é necessária

10 - 50 2 camadas
25 - 150 3 camadas
100 - 1000 4 camadas

Subsistemas e pacotes em uma camada específica devem depender apenas de

subsistemas na mesma camada e na camada inferior seguinte. Se essa restrição de
dependências não for obedecida, a arquitetura será deteriorada e o sistema se tornará frágil
e de difícil manutenção.

As exceções incluem casos em que os subsistemas precisam de acesso direto a

serviços de camadas inferiores: convém tomar uma decisão consciente sobre como lidar
com serviços primitivos necessários em todo o sistema, como imprimir, enviar mensagens,
etc. Não compensa restringir mensagens a camadas inferiores, se a solução for implementar
acessos de chamadas nas camadas intermediárias.

Padrões de Particionamento

Nas camadas superiores do sistema, partições adicionais podem ajudar a organizar o

modelo. As seguintes diretrizes para particionamento apresentam questões distintas a serem
consideradas:

o Organização do usuário. Os subsistemas podem ser organizados em linhas

que refletem a organização da funcionalidade na organização de negócios (por exemplo,
o particionamento ocorre em linhas de departamentos). Em geral, esse particionamento
ocorre no início do design porque um modelo de empresa existente possui uma estrutura
altamente particionada no nível da organização. Esse padrão de organização costuma
afetar somente as poucas camadas superiores de serviços específicos de aplicativo e
normalmente desaparece à medida que o design evolui.
O particionamento em linhas da organização do usuário pode ser um
ótimo ponto de partida para o modelo.
A estrutura da organização do usuário não é estável durante muito
tempo (devido à reorganização de negócios) nem é uma base satisfatória a longo
prazo para o particionamento do sistema. A organização interna do sistema deve
permitir que ele se desenvolva e seja mantido independentemente da organização do
negócio que ele suporta.
o Áreas de competência e/ou habilidades. É possível organizar subsistemas de
modo que particionem responsabilidades de partes do modelo entre grupos distintos da
organização de desenvolvimento. Em geral, isso ocorre nas camadas intermediárias e
inferiores do sistema e reflete a necessidade de especialização de habilidades durante o
desenvolvimento e o suporte da tecnologia de infra-estrutura complexa. Alguns
exemplos desse tipo de tecnologia são o gerenciamento de distribuição e rede, o
gerenciamento de banco de dados, o gerenciamento de comunicação, o controle de
processos, etc. O particionamento em linhas de competência também pode ocorrer nas
camadas superiores, nas quais é necessária uma competência especial no domínio do
problema para entender e suportar a funcionalidade básica de negócios. Alguns

10
 exemplos incluem gerenciamento de chamadas de telecomunicações, negociação de
valores mobiliários, processamento de indenizações de seguro, controle de tráfego aéreo,
etc.
o Distribuição do sistema. Em qualquer uma das camadas do sistema, é
possível particioná-las "horizontalmente" para refletir a distribuição física da
funcionalidade.
O particionamento para refletir a distribuição pode ajudar a visualizar a
comunicação de rede que ocorrerá assim que o sistema for executado.
No entanto, esse particionamento também pode dificultar a realização
de mudanças no sistema, se o Modelo de Implantação for alterado de forma
significativa.
o Áreas de sigilo. Alguns aplicativos, principalmente aqueles que exigem
autorização de segurança especial para serem desenvolvidos e/ou suportados, requerem
partições adicionais nas linhas de privilégio de acesso à segurança. O software que
controla o acesso a áreas de sigilo deve ser desenvolvido e mantido por pessoal
autorizado. Se o número de pessoas no projeto com esse conhecimento for limitado, a
funcionalidade que exige autorização especial deverá ser particionada em subsistemas
que serão desenvolvidos sem depender de outros subsistemas, sendo as interfaces para as
áreas de sigilo o único aspecto visível desses subsistemas.
o Áreas de variabilidade. A funcionalidade que tende a ser opcional e, portanto,
liberada apenas em algumas variantes do sistema, deve ser organizada em subsistemas
independentes que são desenvolvidos e apresentados sem depender da funcionalidade
obrigatória do sistema.

ARQUITETO DE SOFTWARE

O papel arquiteto de software lidera e coordena as atividades e os artefatos técnicos no

decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada visão de
arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses
principais agrupamentos. Portanto, comparado aos outros papéis, a visão do arquiteto de
software é ampla, e não detalhada.

11
 Equipe

"O arquiteto ideal deve ser uma pessoa erudita, um matemático,

familiarizado com estudos históricos, um estudioso aplicado de filosofia,
conhecedor de música, que não desconheça medicina, detentor de saber
jurídico e familiarizado com astronomia e cálculos astronômicos." - Vitruvius,
há aproximadamente 25 anos a.C.

Em resumo, o arquiteto de software deve ter grande conhecimento geral, possuir

maturidade, visão e profunda experiência que permita identificar problemas rapidamente e dar
opiniões sensatas e criteriosas na falta de informações completas. Mais especificamente, o
arquiteto de software ou os membros da equipe de arquitetura devem combinar as seguintes
habilidades:

• Experiência no domínio do problema, conhecendo totalmente os requisitos, e no

domínio de engenharia de software. Se há uma equipe, essas qualidades podem se achar
distribuídas entre os seus membros, mas deve existir pelo menos um arquiteto de software
que ofereça a visão global do projeto.
• Liderança para conduzir o esforço técnico entre as várias equipes, tomar decisões
importantes sob pressão e fazer com que essas decisões sejam cumpridas à risca. Para
melhor eficiência, o arquiteto de software e o gerente de projeto devem trabalhar juntos,
com o arquiteto de software responsável pelas questões técnicas e o gerente de projeto
cuidando dos assuntos administrativos. O arquiteto de software deve ter poder para tomar
decisões técnicas.
• Comunicação para conquistar confiança, persuadir, motivar e servir como mentor. O
arquiteto de software não pode liderar por decreto, mas somente com o consentimento dos
outros membros da equipe do projeto. Para desempenhar seu papel com eficiência, o
arquiteto de software deve conquistar o respeito da equipe do projeto, do gerente do
projeto, do cliente, da comunidade de usuários e da equipe de gerenciamento.
• Orientação por metas e Proatividade com enfoque inexorável nos resultados. O
arquiteto de software é a força técnica orientadora existente por trás do projeto, não um
visionário ou sonhador. A carreira de um arquiteto de software bem-sucedido consiste em

12
uma longa série de decisões insatisfatórias, tomadas com incerteza e sob pressão. Somente
aqueles que se concentram em fazer o que deve ser feito terão êxito nesse ambiente do
projeto.

13