Diretrizes:  Divisão em Camadas

Tópicos

• Abordagens Comuns da Divisão em Camadas
• Diretrizes da Divisão em Camadas
• Padrões de Particionamento

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 problemas e do espaço da solução:

• Em geral, há apenas uma única camada específica de aplicativo.
• 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.
• Espaços de soluções que sejam suportados por produtos de middleware e nos quais o software de sistema complexo desempenhe um papel predominante 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:

• A camada superior, camada de aplicativo, contém serviços específicos de aplicativo.
• A camada seguinte, camada específica de negócios, contém componentes específicos de negócios, usados em diversos aplicativos.
• 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.
• A camada inferior, camada de software de sistema, contém componentes como sistemas operacionais, bancos de dados, interfaces para hardware específico, etc.

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:

• Visibilidade. Os subsistemas só podem depender de subsistemas na mesma camada e na camada inferior seguinte.
• 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.
• Generalidade. Elementos abstratos do modelo costumam ser inseridos em camadas inferiores no modelo. Se não forem específicos da implementação, é provável que fiquem próximos das camadas intermediárias.
• 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:

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:

• Organização do usuário. Os subsistemas podem ser organizados em linhas que espelhem 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.
• Áreas de competência e/ou habilidades. Os subsistemas podem ser organizados para particionar responsabilidades de partes do modelo entre diferentes grupos 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 de 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 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.
• 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.

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

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process