Estratégias de Layering

Estratégias de Layering Existem várias técnicas para decompor os sistemas de software. O layering é um exemplo e é descrito neste artigo. Estas técnicas pretendem responder a duas grandes preocupações. Por um lado, a maior parte dos sistemas são demasiado complexos para poderem ser compreendidos na sua globalidade. Por outro, são necessárias diferentes perspectivas de um sistema para responder a cada tipo de destinatários. O layering tem sido adoptado em muitos sistemas de software e é proposto por muitos textos, ou mesmo pelo Rational Unified Process (RUP). No entanto, o layering é frequentemente mal compreendido e aplicado de forma incorrecta. O que é o layering? O termo layer (nível ou camada) refere-se à aplicação de um padrão de arquitectura geralmente conhecido pela designação de padrão Layers. Um padrão representa uma solução para um problema comum que existe num contexto particular. O Quadro 1 fornece uma ideia global do padrão Layers. Contexto Problema Solução Quadro 1. Ideia global do Padrão Layers. Padrão Layers Um sistema que precisa de decomposição Um sistema que é demasiado complexo para compreender na sua totalidade Um sistema que é difícil de manter Um sistema cujos elementos menos estáveis não estão isolados Um sistema cujos elementos mais reutilizáveis são difíceis de identificar Um sistema que vai ser construído por diferentes equipas, possivelmente com diferentes aptidões Estrutura do sistema em diferentes layers Um dos exemplos mais familiares de layering é o modelo OSI de sete níveis, definido pela International Organization for Standardization (ISO). Este modelo, apresentado na Figura 1, define um conjunto de protocolos de rede. Cada nível concentra-se num aspecto específico de comunicação e cria antecipadamente as condições necessárias para o nível imediatamente abaixo dele. O modelo de sete níveis OSI utiliza uma estratégia de layering baseado em responsabilidade. Ou seja, cada nível tem uma responsabilidade particular. Esta estratégia é descrita mais adiante neste artigo.

Figura 1. Modelo de sete níveis OSI (layering baseado em responsabilidade) A Figura 2 mostra outro exemplo de layering baseado em responsabilidade. O nível Presentation Logic contém elementos responsáveis pela disponibilização de alguma forma de apresentação a um ser humano por exemplo, um elemento na interface com o utilizador. O nível Business Logic contém elementos responsáveis pela realização de algum tipo de processamento de negócio e pela aplicação das regras de negócio. O nível Data Access Logic contém elementos responsáveis pelo fornecimento de acesso a uma fonte de informação por exemplo, uma base de dados relacional. Convém sublinhar que os níveis podem ser modelados de várias formas, tal como descrito mais adiante neste artigo. Por agora, iremos representar explicitamente um nível utilizando uma solução UML com um «nível» estereótipo. Figura 2. Layering baseado em responsabilidade.

Os níveis apresentados neste exemplo particular de layering baseado em responsabilidade são designados frequentemente por tiers, um conceito familiar no desenvolvimento de sistemas distribuídos, onde podemos encontrar sistemas 2-tier, 3-tier e n-tier. Um aspecto importante da Figura 2 é o sentido das dependências mostradas, dado que implica uma certa regra, que é uma característica dos sistemas com níveis. Um elemento de um determinado nível só pode aceder a elementos desse mesmo nível, ou de níveis inferiores. Apesar de uma notificação de evento poder resultar numa mensagem de um elemento de um nível que é enviada para um elemento de um nível superior, não existe nenhuma dependência explícita nessa direcção. No exemplo apresentado, os elementos do nível Business Logic não podem aceder a elementos do nível Presentation Logic. De igual modo, os elementos do nível Data Access Logic não acedem a elementos do nível Business Logic. Esta estrutura é designada frequentemente pela sigla DAG (Directed Acyclic Graph). É direccionada na medida em que as dependências são unidireccionais e é acíclica porque um caminho de dependências nunca é circular. Convém chamar a atenção para a importância de se ser preciso quanto ao significado de cada nível quando se define uma estratégia de layering, de forma a colocar correctamente os elementos no nível apropriado. O fracasso em atribuir correctamente um elemento ao nível apropriado diminuirá o valor da aplicação da estratégia. Na medida em que cada estratégia de layering é apresentada com maior detalhe mais à frente, serão fornecidas nessa altura algumas orientações gerais sobre o significado de cada nível. Modelação dos níveis À medida que investigamos diferentes estratégias de layering, torna-se claro que convém comunicar cada estratégia utilizando modelos específicos (e, consequentemente, elementos UML específicos). Um modelo representa uma descrição completa de um sistema a partir de uma determinada perspectiva. A Figura 3 mostra um exemplo de quatro modelos, representando diferentes perspectivas do sistema considerado: Modelo de Casos de Utilização refere-se aos requisitos do sistema Modelo de Análise refere-se à análise dos requisitos de sistema Modelo de Desenho refere-se ao desenho do sistema Modelo de Implementação refere-se à implementação do sistema Figura 3. Quatro modelos representando um refinamento gradual

Outros modelos adicionais incluem: Modelo de Operação (deployment) refere-se aos aspectos de distribuição de um sistema Modelo de Dados refere-se aos aspectos persistentes de um sistema Estratégias de layering O layering pode basear-se em várias características. No entanto, esta secção vai abordar o layering com base em duas características: responsabilidade e reutilização. A representação de cada estratégia será considerada à medida que for abordada cada uma delas de forma mais detalhada. Layering baseado em responsabilidade A estratégia baseada em responsabilidade é provavelmente a estratégia de layering mais utilizada. Esta estratégia particular pode melhorar o desenvolvimento e a manutenção de um sistema, dado que as várias responsabilidades do sistema são isoladas umas das outras. Por exemplo (ver Figura 2), um sistema pode ser dividido em níveis com base nas seguintes responsabilidades: lógica de apresentação, lógica de negócio e lógica de acesso aos dados. Cada uma destas responsabilidades pode ser representada como um nível, como mostra a Figura 4, que apresenta algum conteúdo exemplo para cada nível. Neste caso, consideramos três conceitos num sistema de processamento de encomendas Cliente, Encomenda e Produto. Como exemplo, o conceito Cliente inclui o seguinte: Classe CustomerView é responsável pela lógica de apresentação associada a um cliente (por exemplo, a apresentação de um cliente na interface com o utilizador). Classe Customer é responsável pela lógica de negócio associada a um cliente (por exemplo, validação de detalhes do cliente). Classe CustomerData é responsável pela lógica de acesso aos dados associada a um cliente (por exemplo, tornar persistente o estado de um cliente). Figura 4. Níveis e conteúdo para um layering baseado em responsabilidade.

Esta estratégia particular de layering tem sido alvo de alguns mitos, pelo que convém falar dos mais frequentes. Mito 1 Os layers e os tiers são diferentes. Este mito é uma causa frequente de confusões. Na realidade, um tier é um layer, embora um layer baseado numa determinada estratégia baseada em responsabilidade. Esta confusão é ampliada ainda mais pelo facto do conceito de tiers poder ser aplicado de várias formas, como mostra o Quadro 2. Neste artigo, para evitar confusões e nos mantermos o mais fiéis possível ao original, traduzimos frequentemente layer por nível e deixámos sempre a palavra tier em inglês. Aplicação 2-tier 3-tier n-tier Quadro 2. Definições de Tier Layers (Tiers) Lógica de apresentação e lógica de negócio combinadas Lógica de acesso aos dados Lógica de apresentação Lógica de negócio Lógica de acesso aos dados Lógica de apresentação Lógica de negócio (distribuída) Lógica de acesso aos dados Mito 2 Os layers (tiers) implicam uma distribuição física. Outra confusão comum tem a ver com a ideia de que o layering lógico implica uma distribuição física. Consideremos, por exemplo, um layering 3-tier. Apesar de vários elementos residirem num dos layers, cada layer em particular pode ser aplicado de várias formas, como mostra o Quadro 3. Neste quadro são utilizados nomes empregue frequentemente para caracterizar uma distribuição física particular (por exemplo, thin client, ou cliente leve). Aplicação Sistema isolado Thin client Fat client Quadro 3. Aplicação de layering 3-tier. Layers Do lado do cliente Do lado do servidor Lógica de apresentação Lógica de negócio Lógica de acesso aos dados Lógica de apresentação Lógica de apresentação Lógica de negócio Lógica de negócio Lógica de acesso aos dados Lógica de acesso aos dados Também é possível que um único sistema possa adoptar mais do que uma estratégia de distribuição física, onde determinados elementos sejam classificados como exemplificativos de uma distribuição thin client e outros de uma distribuição fat client. Normalmente, a escolha baseia-se em requisitos não funcionais, nomeadamente o desempenho. Modelação dos níveis baseados em responsabilidade. Como veremos mais adiante, a aplicação desta estratégia poderá influenciar o modelo de desenho, o modelo de implementação e o modelo de operação (deployment). O modelo de desenho é normalmente estruturado utilizando uma de duas abordagens. A primeira abordagem mostra os elementos contidos dentro do nível. O resultado é apresentado na Figura 5, uma imagem de ecrã do Rational Rose que mostra: Classes de apresentação (CustomerView, OrderView e ProductView) residentes num pacote de Lógica de Apresentação. Classes de lógica de negócio (Customer, Order e Product) residentes num pacote de

Lógica de Negócio. Classes de lógica de acesso aos dados (CustomerData, OrderData e ProductData) residentes num pacote de Lógica de Acesso aos Dados. Figura 5. Elementos contidos dentro de níveis. A segunda abordagem incorpora o conceito de componente de negócio (neste caso, Customer, Order e Product) como cidadão de primeira classe, onde os principais elementos de preocupação são os conceitos relacionados com o domínio suportados pelo sistema. Por exemplo, o conceito Customer pode ter elementos associados de lógica de apresentação, lógica de negócio e lógica de acesso aos dados. Esta forma de pensar resulta na estrutura de modelo apresentada na Figura 6. Neste exemplo, o layering está envolvido nos nomes dos elementos. Por exemplo, todas as classes View (como a CustomerView) envolvem um nível de lógica de apresentação. Por sua vez, todas as classes Data (como a CustomerData) envolvem um nível de lógica de acesso aos dados. Os nomes de classes não qualificadas (como a Customer) envolvem um nível de lógica de negócio.

Figura 6. Layering implícito dentro de cada pacote de componente de negócio. O layering também pode ser representado explicitamente dentro de cada pacote que representa um componente de negócio, como mostra a Figura 7. Esta estruturação é preferível quando existem vários elementos envolvidos em cada nível de um dado componente de negócio. Apesar de só o pacote de componente de negócio Customer ter sido expandido neste exemplo, os pacotes Order e Product apresentariam uma estrutura similar.

Figura 7. Layering explícito dentro de um pacote de componente de negócio. Uma estratégia de layering baseada em responsabilidade influencia normalmente o modelo de implementação, além do modelo de desenho, quando existe a necessidade de partir fisicamente os elementos que implementam cada responsabilidade. Por exemplo, consideremos um sistema que apresenta uma distribuição física do tipo thin client. Convém identificar as unidades de implementação necessárias para suportar a execução num cliente e as que são necessárias para suportar a execução no servidor. Neste exemplo, os elementos do nível da lógica de apresentação residem numa aplicação que é implementada num cliente. Os elementos do nível da lógica de negócio e do nível da lógica de dados residem noutra aplicação que é implementada num servidor. Este cenário implica um modelo de implementação como mostra a Figura 8 que apresenta uma imagem do Rational Rose e um diagrama de componentes com os elementos da aplicação que está implementada no cliente. Neste exemplo, existe uma correspondência entre uma classe no modelo de desenho e um componente UML no modelo de implementação. No entanto, convém sublinhar que essa correspondência depende normalmente da tecnologia de implementação utilizada.

Figura 8. Layering implícito dentro do modelo de implementação. De forma similar, uma estratégia de layering baseada em responsabilidade também pode influenciar o modelo de operação (deployment) quando existe a necessidade de descrever a distribuição física das responsabilidades. Na Figura 9, utilizando o exemplo anterior, podemos ver que foram definidos seis nós. Cada um dos três nós Client alberga um processo ClientApplication. O nó FrontEndServer alberga um processo LoadBalancer que é responsável pela distribuição dos pedidos dos clientes para um dos dois nós Server. Cada nó Server alberga um processo ServerApplication. Figura 9. Este modelo de operação (deployment) descreve a distribuição física das responsabilidades.

Modelação baseada em reutilização Outra forma de layering normalmente utilizada é a que se baseia na reutilização. Esta estratégia é particularmente relevante para as organizações que têm um objectivo identificável para a reutilização de componentes ao longo da organização. O impacto da utilização desta estratégia de layering reside no facto da reutilização de componentes ser altamente visível, dado que os componentes são agrupados explicitamente de acordo com o seu nível de reutilização. A Figura 10 mostra um exemplo de layering deste tipo e podemos ver três níveis: Base, Business-Specific e Application-Specific. O nível Base contém os elementos que podem ser aplicados ao longo da organização (por exemplo, Math). Estes elementos serão reutilizados de forma generalizada. O nível Business-Specific contém os elementos que aplicáveis a uma organização particular, mas são independentes da aplicação (como o Address Book). Estes elementos serão reutilizados em aplicações dentro da mesma organização. O nível Application-Specific contém os elementos aplicáveis a um projecto ou aplicação particulares (como o Personal Organizer). Estes elementos são os menos reutilizáveis. Figura 10. Exemplo de layering baseado na reutilização. Podemos concluir que os elementos do nível Base são os mais reutilizáveis, enquanto que os elementos do nível Application-Specific são mais específicos de um projecto e, consequentemente, menos reutilizáveis. Modelação dos níveis baseados em reutilização. A aplicação de uma estratégia de reutilização influencia principalmente o modelo de desenho. A estrutura de um modelo de desenho que incorpore layering baseado em reutilização é fácil de conceber. A Figura 11 mostra uma dessas estruturas, com base no exemplo da Figura 10.

Figura 11. Modelo de desenho incorporando um layering baseado em reutilização. Outras estratégias de layering O objective deste artigo consiste em dar apenas uma ideia das diferentes estratégias de layering existentes. Como exemplo, recorremos às duas estratégias que são utilizadas de forma mais alargada. No entanto, poderão ser adoptadas outras abordagens para estratégias considerem características como a segurança, posse e aptidões. Layering multi-dimensional As estratégias descritas atrás também podem ser combinadas para criar novas estratégias de layering. O exemplo da Figura 12 mostra dois dos níveis baseados em reutilização do exemplo anterior (específico da aplicação e específico do negócio) e três níveis (tiers) baseados em responsabilidade (lógica de apresentação, lógica de negócio e lógica de acesso aos dados). As dependências presentes na estratégia de layering baseada em reutilização resultam normalmente de dependências entre elementos dos níveis de lógica de negócio, como mostra a Figura 12, onde podemos ver a dependência entre PersonalOrganizer e AddressBook.

Figura 12. Layering multi-dimensional. Modelação dos níveis multi-dimensionais. Neste caso, consideramos a representação dos aspectos multi-dimensionais do layering num modelo de desenho bidimensional. Também consideramos uma estrutura onde é incorporado o conceito de componente de negócio. Figura 13. Modelo de desenho incorporando layering multi-dimensional. A adopção de uma estratégia de layering multi-dimensional requer que seja identificada uma estratégia principal. No nosso exemplo, a estratégia de layering principal baseia-se em reutilização. O modelo de desenho é organizado primeiro com base nessa estratégia, fornecendo os níveis Application-Specific, Business-Specific e Base. Cada um destes níveis é depois organizado pelos elementos que residem em cada um deles. Por Exemplo, a Figura 13 mostra o nível Business-Specific a conter os elementos Address Book e Calculator. Cada um dos elementos é ainda organizado posteriormente com base numa estratégia secundária: layering baseado em responsabilidade. Por exemplo, o pacote Address Book contém os três níveis Presentation Logic, Business Logic e Data Access Logic. Cada um

destes níveis contém então quaisquer elementos que residem neste nível: O nível de lógica de apresentação contém a classe AddressBookView. O nível de lógica de negócio contém a classe AddressBook. O nível de lógica de acesso aos dados contém a classe AddressBookData. Conclusão Uma das decisões mais importantes que um arquitecto tem de tomar prende-se com a escolha de uma estratégia de layering apropriada, uma vez que esta última irá ter uma grande influência na estrutura dos modelos produzidos. No entanto, o mais significativo tem a ver com o facto das vantagens de negócio como a capacidade/facilidade de manutenção e a reutilização poderem ser suportadas directamente pela estratégia de layering escolhida. Por exemplo, à medida que são desenvolvidos mais sistemas com capacidade/facilidade de manutenção, as diferentes responsabilidades do sistema devem ser isoladas umas das outras através da adopção de uma estratégia de layering baseada em responsabilidade. De igual modo, os elementos de sistema reutilizáveis podem ser identificados claramente utilizando uma estratégia de layering baseada na reutilização. Bibliografia Buschmann, Frank, et al. A System of Patterns. 1996. New York: John Wiley & Sons. ISBN 0-471-95869-7. Edwards, Jeri. 3-Tier Client/Server at Work. 1999. New York: John Wiley & Sons. ISBN 0-471-31502-8. Eeles, Peter, and Oliver Sims. Building Business Objects. 1998. New York: John Wiley & Sons. ISBN 0-471-19176-0. Herzum, Peter, and Oliver Sims. The Business Component Factory. 2000. New York: John Wiley & Sons. Jacobson, Ivar, et al. Software Reuse. 1997. Reading, Massachusetts: Addison-Wesley. ISBN 0-201-92476-5. Vlissides, John, James Coplien, and Norman Kerth. Pattern Languages of Program Design 2. 1996. Reading, Massachusetts: Addison-Wesley. ISBN 0-201-89527-7. Baseado no white paper Layering Sttrattegies, de Petter Eelles; IBM-Rational. Tel: (+351) 239 497 230 / 2 Fax: (+351) 239 497 231 E-mail: tim@engenharia-software.com Internet: www.engenharia-software.com