Arquitetura de
Software
José Jorge
Dias
3
Em pequenos projetos, a equipe de
desenvolvimento consegue criar uma
representação mental sobre a estrutura do produto
a ser desenvolvido
◦ Estrutura de dados e algoritmos são os mais importantes
Na medida em que o tamanho do software
aumenta, fica mais difícil de entender este produto
◦ Temos mais partes para gerenciar
◦ É mais complexo de se entender
◦ Mais riscos envolvidos
◦ Engenheiros de software buscam abstrações para melhor entender o software em construção
O objetivo é possibilitar o entendimento
Funcionais Não funcionais 5
Diferentes Requisitos
Disponibilidade Segurança Manutenabilidade Tolerância a falhas Usabilidade Desempenho Escalabilidade ReusabilidadePapel da arquitetura
Ponte entre requisitos e código [Garlan, 2000]
Requisitos
Código Arquitetura
Diante de tal complexidade, é preciso
pensar melhor no sistema
◦ Criar componentes
◦ Modularizarmos as nossas estruturas
Objetivos
◦ Organizar a estrutura do nosso software ◦ Satisfazer os requisitos não funcionais
Como garantir disponibilidade por exemplo? Como garantir segurança?
“Arquitetura de Software de um programa consiste na estrutura do sistema, que compreendem (i)
elementos de software, (ii)
propriedades externamente
visíveis destes elementos e (iii) os
relacionamentos entre eles.”
[Bass et al., 2003]
Algumas atividades
◦ Selecionar meio de armazenamento que será utilizado
◦ Definir tecnologias a serem utilizadas ◦ Definir ambiente de produção
◦ Definir o estilo arquitetura do sistema (camadas?) ◦ Definir padrões de projeto
◦ Documentar a arquitetura
No início...
Sistemas Monolíticos
GUI Lógica Dado s Divisão da aplicação em camadas:
◦ Alto grau de escalabilidade, flexibilidade, alta coesão, baixo acoplamento, ...
Dois tipos de camadas:
◦ Camada Física (Tier) ◦ Camada Lógica (Layer)
Representado pela parte física ou estrutural
dos componentes de infra-estrutura da arquitetura que vão desde o hardware, o sistema operacional, os serviços, até os servidores
Tipos de arquiteturas com camadas físicas:
◦ 2 camadas ◦ 3 camadas ◦ N camadas
Também conhecido como cliente-servidor
Cliente com executável e regras de negócio
e Servidor com banco de dados.
2 Camadas
Entre o lado cliente e o lado servidor entrou
um servidor de aplicação onde ficam todas as regras de negócio compartilhadas para os clientes
Amplamente utilizado por sistemas Web
Utilizada para aplicações que exigem um
alto grau de distribuição de seus componentes internos
Padrão arquitetural que serve para organizar e
separar as responsabilidades dos componentes internos de uma aplicação
A arquitetura em camadas prevê que cada
camada deve prover serviços para a camada diretamente superior
Provê independência entre as camadas que as
compõe
Exemplo:
Camadas Lógicas (Layer)
Apresentação Negócio
Dados
Alta coesão
Responsável por conter as interfaces dos
usuários e as regras inerentes a qualquer componente visual, regras de validação de entrada de dados
A camada de apresentação deve fazer uso
dos serviços oferecidos pela camada imediatamente inferior a ele.
◦ Exemplo: Camada de apresentação acessa serviços da camada de negócio
A camada de negócio contempla a
implementação da lógica do negócio que do sistema
É núcleo do sistema e contém todas as
classes inerentes ao domínio da aplicação:
◦ as classes básicas do negócio, ◦ as classes coleções de negócio e ◦ a Fachada do sistema
Também utiliza os serviços da camada
inferior (dados)
Negócio
Responsável por conter toda a lógica para
acesso aos dados, seja via banco de dados, arquivos texto ou XML
Os serviços providos pela camada de dados
são utilizados pelas classes coleções de
negócio, que são pertencentes à camada de negócio
As coleções de negócios realizam operações
de inserção, edição, exclusão e consulta das instâncias das classes básicas de negócio
Um padrão de projeto é uma estrutura
recorrente no projeto de software orientado a objetos. Pelo fato de ser recorrente, vale a pena que seja documentada e estudada.
Basicamente cada padrão de projeto
resolve um problema já conhecido e enfrentado em projetos de software
Padrões de Projeto
Apresentação
Exemplo
Considerando que a arquitetura foi projetada
em camadas: apresentação, negócio e dados
A comunicação entre Apresentação e Negócio
ficariam mais ou menos como mostra a figura
Podemos diminuir o acoplamento e simplificar o
acesso a camada de negócio?
Padrões de Projeto
Apresentaçã o Apresentaçã o Negócio Negócio Dados Dados Tela X Controlador A Controlador B Controlador C Negócio Tela Y Facade (Fachada)
Aplicando o padrão Facade ao nosso projeto teríamos:
Padrões de Projeto
Tela X Controlador A Controlador B Controlador C Tela Y Apresentação Negócio Fachada Agora como conseguimos isolar a camada de dados? Como isolar a lógica da tecnologia de persistência? Como flexibilizar esta camada de dados?
◦ Se quisermos mudar, futuramente, o SGBD, por exemplo
Padrões de Projeto
CadastroCliente Controlador A SGBD Possui o código para acessar o SGBD Camada de Dados Camada de Negócio DAO (Data Access Object)
◦ é um padrão de projetos desenvolvido para melhorar a forma como trabalhamos com abstração de banco de dados
◦ Separa internamente seu código, fazendo com que a parte lógica e as regras de negócio fiquem isoladas de toda persistência com o banco de
dados
Padrões de Projeto
CadastroCliente Controlador A SGBD Possui o código para acessar o SGBD Camada de Dados Camada de Negócio ClienteDAOMySQL Será que precisamos de várias fachadas ou
uma só? No sistema, precisa ter mais de um objeto do tipo Fachada rodando?
E no caso dos DAOs? Precisamos conectar
várias vezes ao Banco de dados?
Como garantir então que teremos apenas
uma instância de objeto rodando no sistema nestes casos?
Singleton
◦Ele é usado quando for necessária a existência de apenas uma instância de uma classe
public class ClasseSingleton {
private static ClasseSingleton instance; private ClasseSingleton() { }
public static ClasseSingleton getInstance() {
if (instance == null) instance=new Singleton();
return instance; } } Uso: ClasseSingleton cs = ClasseSingleton.getInstance();
Padrões de Projeto
Visões da arquitetura
Clientes diferentes apresentam diferentes
Modelos
Um modelo de sistema é uma
abstração do
sistema
em estudo
O modelo deve
simplificar a realidade
,
realçando as características mais
importantes
Existem diferentes
tipos de modelo,
cada um
enfatizando
um aspecto
(Ex:
interface,
arquitetura, BD, etc)
Análise e Modelos
Vantagens de usar um modelo
◦
Documentar
decisões
◦
Entender
melhor o sistema
◦
Guiar
a implementação
e outras
disciplinas do ciclo de vida
Janela para o sistema em uma perspectiva
particular que serve como comunicação entre os envolvidos no sistema, expressa geralmente em texto e/ou diagramas UML
No RUP, as visões arquiteturais são
conhecidas por Modelo de Visão
Arquitetural 4+1, sendo todas elas dirigidas
pela visão de caso de uso
Responsável pela organização conceitual do
software em termos de camadas, subsistemas,
pacotes, frameworks, classes e interfaces mais importantes
Responsável pela instalação física dos processos e componentes nos nós de processamento e a
configuração física da rede entre os nós
Visão de Deployment
(Implantação)
Neste modelo todo o sistema é organizado para
identificarmos sua estrutura, por exemplo: pacotes java, componentes, arquivos JAR e EAR, etc.
Responsável por mapear os processos e as threads, suas responsabilidades, colaborações e a alocação dos elementos da visão lógica
Responsável por dirigir
as quatro visões
Ter uma arquitetura bem definida é um
fator crítico de sucesso de um projeto de
software
A arquitetura guia a implementação do
sistema
A arquitetura atende os requisitos
funcionais impactantes e os requisitos não funcionais
38
39
