Conceitos de Programação e Arquitectura de Software (I)

Introdução

Hoje em dia a complexidade dos sistemas de software, exige a sua concepção e desenvolvimento obedeçam a regras criteriosas, à utilização das tecnologias e técnicas mais adequadas e à aplicação de boas práticas.

Um dos pontos chave para atingir o objectivo de criar bons sistemas é a Arquitectura de Software.

Mas o que é isso da Arquitectura de Software? E as técnicas? E as boas práticas?

O objectivo desta série de artigos é dar resposta a estas e muito mais perguntas, sistematizando, de forma clara e sucinta, um conjunto de conceitos base sobre arquitectura e desenvolvimento de software, para novos programadores.

O artigo foca-se na Programação Orientada a Objectos (POO) e os exemplos apresentados foram desenvolvidos na linguagem C#, da plataforma Microsoft .NET, mas os conceitos são aplicáveis a qualquer outra tecnologia ou linguagem.

Conteúdo

• 1. Arquitectura de Software
  • 1.1. O que é a Arquitectura de Software?
  • 1.2. Porque é importante a Arquitectura de Software?
  • 1.3. Quais os objectivos da Arquitectura de Software?
  • 1.4. Arquitecturas por camadas
    • 1.4.1. O que é a arquitectura de 2 camadas (2-tier)?
    • 1.4.2. O que é a arquitectura de 3 camadas (3-tier)?
    • 1.4.3. O que é a Data Access Layer (DAL)?
    • 1.4.4. O que é a Business Logic Layer (BLL ou BL)?
    • 1.4.5. O que é a Presentation Layer (PL ou UI)?
  • 1.5. Algumas Arquitecturas populares
    • 1.5.1. O que é a Arquitectura MVC?
    • 1.5.2. O que é a Arquitectura SOA?
• Referências

1. Arquitectura de Software

1.1. O que é a Arquitectura de Software?

A Arquitectura de Software corresponde ao processo de de criar uma solução estruturada que responda a todos os requisitos técnicos e operacionais do sistema. Consiste na estrutura, ou estruturas de alto nível do sistema, às regras, procedimentos heurísticos e padrões para criar tais estruturas e à documentação dessas estruturas.

“As estruturas do sistema compreendem elementos de software, as propriedades desses elementos, visíveis do exterior e as relações entre eles. A arquitectura preocupa-se com a parte pública dos interfaces, os detalhes privados dos elementos de software – aqueles que dizem respeito apenas à implementação – não são arquitecturais.”
-- Bass, Clements e Kazman
”Software Arquitecture in Practice” (3ª edição)

A arquitectura de software NÃO É um conjunto ou uma pilha de tecnologias (entenda-se aqui tecnologias como as ferramentas, técnicas e APIs usadas para construir o sistema).

No mundo da programação, quando alguém pergunta como vamos arquitectar uma dada aplicação, muitas vezes dizemos, por exemplo, que vamos construir um sistema baseado em “ASP.NET MVC 4, com uma camada de serviços WCF, em cima duma framework e os dados são guardados numa BD do SQL Server”. Isto é uma pilha de tecnologias, mas não nos descreve como vai ser o sistema. É como se perguntássemos qual a arquitectura de um edifício e nos dissessem que é feito com tijolos, cimento e que vão ser usadas betoneiras e colheres de pedreiro para o construir.

1.2. Porque é importante a Arquitectura de Software?

A arquitectura de um sistema define as grandes decisões a serem tomadas.

Primeiro temos que identificar os requisitos do sistema, que pode ser de diferentes tipos.

Como podemos ver, nem todos os requisitos são compatíveis entre si. Então, temos que tomar decisões que garantam que o sistema está equilibrado - que corresponde aos objectivos para que foi desenhado, dentro do ambiente onde vai ser executado.

Em resumo, a arquitectura de software é importante porque:

• Controla a complexidade
• Força a aplicação das melhores práticas
• Dá consistência e uniformidade
• Aumenta a previsibilidade
• Permite a reutilização

1.3. Quais os objectivos da Arquitectura de Software?

O principal objetivo da arquitectura de software é identificar os requisitos que afectam a estrutura do sistema. A arquitectura procura construir uma ponte entre os requisitos de negócio e os requisitos técnicos, através da compreensão dos Casos de Uso e da definição de formas de implementar esses casos de uso no software.

Lembrar que a arquitectura deve:

• Expor a estrutura do sistema, mas esconder os detalhes de implementação
• Identificar todos os casos de utilização e cenários
• Tentar dar resposta aos requisitos de vários intervenientes (stakeholders)
• Tratar dos requisitos funcionais e de qualidade

1.4. Arquitecturas por camadas

1.4.1. O que é a arquitectura de 2 camadas (2-tier)?

A arquitectura de 2 camadas refere-se ao modelo cliente/servidor, termo que começou a ser usado na década de 1980, referindo-se a computadores pessoais ligados em rede. O modelo cliente/servidor real começou a ganhar aceitação no final de 1980 e mais tarde foi adoptado para a programação Web.

Actualmente, na utilização da arquitectura de 2 camadas, os interfaces do utilizador (UI) (p.ex. todas as páginas Web, numa aplicação para Internet) são executados no cliente e a Base de Dados (BD) é armazenada no servidor. A lógica da aplicação pode ser executada no cliente ou no servidor. Portanto, neste caso, o UI vai aceder diretamente à BD. Os clientes também podem ser motores de processamento (e não de interface), que fornecem soluções para outros sistemas remotos ou locais.

Em qualquer dos casos, hoje em dia, o modelo de 2 camadas é preterido em relação ao modelo de 3 camadas. A vantagem de um sistema de 2 camadas é a sua simplicidade, mas a simplicidade tem o custo da escalabilidade. A arquitectura de 3 camadas (mais recente) introduz uma camada intermédia, para a lógica da aplicação.

1.4.2. O que é a arquitectura de 3 camadas (3-tier)?

A arquitetura de 3 camadas surgiu na década de 1990 com o intuito de superar as limitações da arquitetura de 2 camadas. Esta arquitectura tem sido intensivamente adoptada e aperfeiçoada pelos modernos projectistas e programadores de sistemas Web.

O modelo de 3 camadas é uma arquitetura cliente/servidor em que o UI, a lógica funcional, o armazenamento de dados e o acesso aos dados são desenvolvidos e mantidos como módulos independentes (algumas vezes até em plataformas distintas). O termo "três camadas" ou "três níveis" (3-layer), bem como o conceito de arquitecturas multi-camada, parece ter sido originado a partir do Software Rational.

A arquitetura de 3 camadas, classicamente, tem os seguintes níveis:

• Camada de apresentação ou de servidor Web: Interface do Utilizador, que exibe os dados para ou aceita inputs do utilizador (ver detalhes abaixo).
• Camada de Lógica de Negócio/Aplicação ou Servidor Aplicacional: Validação e aceitação dos dados antes de guardar na BD, processamentos, cálculos e todas as outras operações específicas do negócio/aplicação (ver detalhes abaixo).
• Camada de Dados ou Servidor BD: Simples operações de leitura e escrita de dados na BD ou em qualquer outro sistema de armazenamento (ver detalhes abaixo).

1.4.3. O que é a Data Access Layer (DAL)?

A Camada de Acesso a Dados (DAL) consiste principalmente num conjunto simples de código que efectua as interações básicas com a BD ou qualquer outro dispositivo de armazenamento de dados. Estas funcionalidades são muitas vezes referidos como CRUD (Create, Retrieve, Update, Delete).

A DAL deve ser genérica, simples, rápida e eficiente. Não deve incluir lógica de negócio/aplicação complexa. Muitos sistema têm longas e complexas Stored Procedures (SP), que são executadas para uma simples operação de leitura de dados. Estas SP contém, muitas vezes, lógica de negócio, lógica da aplicação e lógica de UI também. Se uma SP estiver a ficar muito longa, isso é sinal de que está a colocar a lógica de negócio na DAL.

1.4.4. O que é a Business Logic Layer (BLL ou BL)?

Ao lermos a imensa documentação disponível sobre este tema, percebemos que nem todos os autores concordam com o que é a Camada de Lógica de Negócio (BL). Em muitos casos é apenas uma ponte entre a Camada de Apresentação e a Camada de Dados, sem qualquer função adicional que não seja passar dados de uma lado para o outro. No entanto, nada nos impede de alterar a abordagem a este tipo de BL. Mas a mudança deve ser feita como e quando se sentir confortável de que o método a aplicar é flexível o suficiente para suportar o crescimento do sistema. Existem muitas maneiras excelentes de implementar a BL, mas tenha cuidado ao selecioná-las, pois podem complicar em excesso um sistema simples. É um equilíbrio que é preciso encontrar com base na sua experiência.

Como recomendação geral, deve decidir como mapear os dados das tabelas para Entidades de Negócio (classes) correctamente definidas. As entidades de negócio devem levar em consideração os vários tipos de requisitos e funcionamento do sistema. Pode-se usar uma abordagem de definir uma entidade separada para cada tabela da BD (a maioria dos ORMs levam a isto), mas recomenda-se a criação de entidades que permitam encapsular as exigências funcionais e de UI da aplicação, que podem ser autónomas ou, por exemplo, agregar várias entidades relacionadas com as tabelas da BD.

1.4.5. O que é a Presentation Layer (PL ou UI)?

A Camada de Apresentação ou Interface com o Utilizador (UI), como o nome indica, interage directamente com o utilizador. Tipicamente é constituída por um ambiente gráfico composto por variados objectos (controlos) que permitem ao utilizador interagir com o sistema, quer através da introdução e visualização de dados, quer através da realização de acções e introdução de comandos.

1.5. Algumas Arquitecturas populares

1.5.1. O que é a Arquitectura MVC?

A arquitetura Model-View-Controller (MVC) separa a modelagem do domínio, a apresentação e as ações baseadas nos inputs do utilizador (lógica de apresentação) em três classes distintas.

Infelizmente, a popularidade deste modelo resultou em alguns usos defeituosos. Cada tecnologia (Java, ASP.NET, etc.) definiu-o da sua própria maneira, fazendo com que seja difícil de entender. Em particular, o termo "controlador" tem sido usado para significar coisas diferentes em contextos diferentes. As definições abaixo estão o mais próximo possível da tecnologia ASP.NET MVC.

• Model: conjunto de classes que criam um modelo do sistema, usado para apresentar os dados ao utilizador. Podemos ter entidades de negócio, coleções, DataSets, etc.
• View: ficheiro de página Web (HTML, Javascript) que se encarrega de implementar o UI.
• Controller: classe que recebe os pedidos e eventos despoletados pelas acções do utilizador na View.

Num sistema distribuído de n camadas, a arquitetura MVC tem o papel vital de organizar a Camada de Apresentação.

Recomenda-se a consulta do artigo “ASP.NET MVC vs ASP.NET Web Forms – Porquê o MVC?” para maior detalhe nos conceitos desta arquitectura.

1.5.2. O que é a Arquitectura SOA?

A Arquitetura Orientada a Serviços (SOA) é  um modelo de programação em que as funcionalidades das aplicações são disponibilizadas como serviços, que utilizam o paradigma pedido/resposta para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.

A SOA é essencialmente uma coleção de serviços, que comunicam uns com os outros e com os sistemas clientes. A comunicação pode envolver a simples passagem de dados ou pode envolver dois ou mais serviços na coordenação de alguma atividade.

Com o desenvolvimento das aplicações baseadas em Web, a utilização de Web Services tornou-se popular, tendo-se assistido a uma proliferação dos sistemas SOA. Todavia há que salientar que um serviço não é necessariamente um web service, nem tem que estar relacionado com a Web.

A SOA pode ser ainda usada como o conceito para conectar vários sistemas de prestação de serviços. Esta arquitectura tem um grande quinhão de participação no futuro do mundo das TI.

Referências

- MSDN Patterns & Practices
- Microsoft Application Architecture Guide
- Code Project - Introduction to Object Oriented Programming Concepts (OOP) and More
- Learn Visual Studio.NET - Application Architecture Fundamentals