ACH2006_ProjetoDeSoftware_1

Prévia do material em texto

ACH2006 – ENGENHARIA DE SISTEMAS DE
INFORMAÇÃO I
PROJETO DE SOFTWARE I
Marcos Lordello Chaim
20 de outubro de 2023
Bacharelado em Sistemas de Informação | EACH - USP
O QUE É PROJETO DE SOFTWARE?
• Engloba várias atividades de desenvolvimento:
• Projeto arquitetural.
• Desenho (ou projeto) do módulos que compõem a arquitetura do
software.
• Projeto dos algoritmos utilizados no sistema.
• Para apoiar o projeto de software há alguns recursos:
• Padrões arquiteturais;
• Arquiteturas de referência;
• Linhas de produto;
• Arcabouços (Frameworks);
• Padrões de desenho ou de projeto (Design Patterns).
1/43
ARQUITETURA E DESENHO DE SOFTWARE
• A arquitetura de software mostra a estrutura do sistema e
oculta os detalhes de implementação, concentrando-se em
como os componentes do sistema interagem entre si.
• O desenho (design) de software, por outro lado, concentra-se
na implementação do sistema, muitas vezes entrando em
bastante detalhes.
2/43
PADRÕES NO DESENVOLVIMENTO DE SOFTWARE
• Padrão Arquitetural de Software: como os subsistemas são
conectados entre si para atender aos requisitos funcionais e
não funcionais da aplicação⇒ nível sistema
• Padrão de Desenho de Software (Software Design Pattern): uma
solução geral para uma família de problemas semelhantes⇒
nível módulo
3/43
NÍVEIS DE PROJETO DE SOFTWARE
4/43
ARQUITETURA DE SOFTWARE
• Sistemas grandes são sempre decompostos em subsistemas
que fornecem algum conjunto de serviços relacionados.
• O processo inicial de projeto, que consiste em identificar esses
subsistemas e estabelecer um arcabouço para o controle e a
comunicação de subsistemas, é denominado projeto de
arquitetura.
• Primeiro estágio no processo de projeto e representa uma
ligação crítica entre as fases de projeto e requisitos.
5/43
VANTAGENS DE EXPLICITAR A ARQUITETURA
• Comunicação de stakeholders.
• Análise de sistema.
• Reúso em Larga escala.
6/43
ARQUITETURA E REQUISITOS NÃO FUNCIONAIS
• Desempenho. Localizar operações críticas e minizar
comunicações. Isso pode significar o uso de componentes de
alta granularidade em detrimento dos de baixa granularidade.
• Proteção. Usar uma estrutura em camadas para a arquitetura
com os itens mais críticos protegidos por camadas mais
internas.
• Segurança. As operações relacionadas à segurança estejam
localizadas em um único subsistema ou em um pequeno
número de subsistemas.
• Disponibilidade. Incluir componentes redundantes e, assim que
possível, substituir e atualizar componentes sem parar o
sistema.
• Manutenção. Usar componentes de baixa granularidade e
autocontidos que possam ser prontamente mudados.
7/43
CONFLITOS ARQUITETURAIS
• O uso de componentes de alta granularidade aprimora o
desempenho e o uso de componentes de baixa granularidade
aprimora a facilidade de manutenção.
• Introduzir dados redundantes aprimora a disponibilidade mas
torna a segurança mais difícil.
• Se ambos forem requisitos de sistema importantes, alguma
solução eficaz deve ser encontrada.
8/43
ESTRUTURAÇÃO DO SISTEMA
• Um projeto de subsistema é uma decomposição abstrata de um
sistema em componentes de alta granularidade, cada um dos
quais podendo ser um sistema substancial e independente.
• Os diagramas de blocos são frequentemente usados para
descrever projetos de subsistemas em que cada caixa no
diagrama representa um subsistema.
9/43
DIAGRAMA DE BLOCOS: EXEMPLO ROBÔ
10/43
DECISÕES DE PROJETO DE ARQUITETURA
• Existe uma arquitetura genérica de aplicação que possa
funcionar como um modelo para o sistema que está sendo
projetado?
• Como o sistema será distribuído ao longo de vários
processadores?
• Qual ou quais estilos de arquitetura são apropriados para o
sistema?
• Qual será a abordagem fundamental usada para estruturar o
sistema?
11/43
DECISÕES DE PROJETO DE ARQUITETURA
• Como as unidades estruturais de um sistema serão
decompostas em módulos?
• Qual estratégia será usada para controlar a operação das
unidades no sistema?
• Como o projeto de arquitetura será validado?
• Como a arquitetura do sistema será documentada?
12/43
REÚSO
• Embora cada sistema seja único, frequentemente sistemas de
um mesmo domínio de aplicação possuem arquiteturas
similares que refletem os conceitos fundamentais de domínio.
• Linhas de produtos de aplicações são criadas com base em um
núcleo de arquitetura com variações que satisfazem os
requisitos específicos do cliente.
13/43
ESTILOS ARQUITETURAIS
• A arquitetura de um sistema de software pode ser baseada em
um modelo ou estilo arquitetural específico.
• Um estilo arquitetural é um padrão de organização de sistema,
como uma organização cliente-servidor ou uma arquitetura em
camadas.
• O conhecimento desses estilos, suas aplicações e seus pontos
fortes e fracos é importante.
• Contudo, as arquiteturas da maioria dos grandes sistemas não
estão de acordo com um único estilo.
• Em alguns casos, a arquitetura geral do sistema pode ser uma
arquitetura composta criada pela combinação de estilos
arquiteturais diferentes.
14/43
ESTILOS ARQUITETURAIS
• Três estilos organizacionais são amplamente utilizados:
• Estilo de repositório de dados compartilhados
• Estilo de serviços e servidores compartilhados
• Estilo de máquina abstrata ou estilo em camadas
15/43
MODELO DE REPOSITÓRIO
• Os subsistemas que constituem um sistema devem trocar
informações de modo que possam trabalhar juntos
eficientemente.
• Existem duas maneiras fundamentais pelas quais isso pode ser
feito.
• Todos os dados compartilhados são mantidos em um banco de
dados que pode ser acessado por todos os subsistemas. Um
modelo de sistema baseado em um banco de dados
compartilhado é algumas vezes denominado modelo de
repositório.
• Cada subsistema mantém seu próprio banco de dados. Os dados
são trocados com outros subsistemas por meio da passagem de
mensagens entre eles.
• Quando grande quantidade de dados são compartilhados, o
modelo de repositório é mais comumente empregado.
16/43
MODELO DE REPOSITÓRIO: EXEMPLO
17/43
VANTAGENS E DESVANTAGENS
1. É uma maneira eficiente de compartilhar grandes quantidades
de dados. Não há necessidade de transmitir dados
explicitamente de um subsistema para outro. Contudo, os
subsistemas devem estar de acordo com o modelo de dados do
repositório.
2. Os subsistemas que produzem dados não precisam saber como
esses dados são usados por outros subsistemas.
3. As atividades tais como backup, proteção, controle de acesso e
recuperação de erros são centralizadas. No entanto, não há
espaço para políticas específicas de gerenciamento.
4. O modelo de compartilhamento é visível por meio do esquema
do repositório. Contudo, pode ser difícil distribuir o repositório
por uma série de máquinas.
18/43
MODELO CLIENTE-SERVIDOR
• Modelo de sistema distribuído em que o sistema é organizado
como um conjunto de serviços e servidores e clientes
associados que acessam e usam os serviços.
• Os principais componentes desse modelo são:
1. Um conjunto de servidores que oferecem serviços para outros
subsistemas.
2. Um conjunto de clientes que solicitam os serviços oferecidos
pelos servidores.
3. Uma rede que permite aos clientes acessarem esses serviços. Isso
não é necessário quando ambos, clientes e servidores, podem ser
executados em uma única máquina.
19/43
MODELO CLIENTE-SERVIDOR: EXEMPLO
• Frameworks para clientes: React, Angular.
• Frameworks para servidores: Rails, Django, Node
• “SaaS” (software as a service): sistemas cliente-servidor
construídos usando HTTP e padrões e protocolos da Web.
20/43
VANTAGENS E DESVANTAGENS
• Vantagens
1. Distribuição de dados obtida diretamente.
2. Faz uso efetivo de sistemas em rede. Possivelmente hardware
mais barato.
3. Fácil adicionar ou atualizar servidores de maneira transparente.
• Desvantagens
1. Pode não haver um modelo de dados compartilhado. Troca de
informações pode ser ineficiente.
2. Gerenciamento redundante em cada servidor.
21/43
ARQUITETURA BASEADA EM MICROSSERVIÇOS
22/43
ARQUITETURA BASEADAEM MICROSSERVIÇOS
• Arquitetura cliente-servidor levada ao extremo.
• Um microsserviço é um serviço independente que executa
apenas um tipo de tarefa.
• É projetado especificamente para ser acessível e incorporado à
funcionalidade de qualquer outro serviço externo (talvez
mediante pagamento de uma taxa).
• Um sistema com arquitetura repositório não consegue ser micro.
• Não apenas devido ao seu tamanho, mas porque os seus
componentes não podem ser implementados de forma
independente, uma vez que partilham o acesso a bases de
dados.
23/43
DIRETRIZES PARA PROJETAR UM MICROSSERVIÇO
• Uma regra geral é que o escopo de um microsserviço deve
corresponder a um conjunto de operações estreitamente
relacionadas em um conjunto de recursos fortemente
integrados⇒ Alta Coesão!
• Pouca ou nenhuma dependência de outros subsistemas para
fazer realizar suas tarefas⇒ Baixo Acoplamento!
• Ou seja, deve-se utilizar esses dois princípios básicos de
qualquer projeto de software!
24/43
MODELO EM CAMADAS
• Organiza o sistema em camadas (ou máquinas abstratas), cada
uma das quais fornecendo um conjunto de serviços.
• Cada camada pode ser imaginada como uma máquina abstrata
cuja linguagem de máquina é definida pelos serviços oferecidos
pela camada.
• A abordagem em camadas apoia o desenvolvimento incremental
de sistemas. Desde que sua interface permaneça inalterada,
uma camada poderá ser substituída por outra equivalente.
• Quando a interface de uma camada muda, apenas a camada
adjacente é afetada.
25/43
MODELO EM CAMADAS: EXEMPLO
26/43
ESTILOS DE DECOMPOSIÇÃO MODULAR
• Depois que a organização geral do sistema foi escolhida, você
precisa tomar uma decisão sobre a abordagem a ser usada na
decomposição de subsistemas em módulos.
• Um subsistema é um sistema em si cuja operação não depende de
serviços fornecidos por outros subsistemas.
• Um módulo é normalmente um componente de sistema que
fornece um ou mais serviços para outros módulos. Não é
normalmente considerado um sistema independente.
• Existem duas estratégias principais na decomposição de
subsistemas em módulos:
• Decomposição orientada a objetos
• Pipeline orientado a funções
27/43
DECOMPOSIÇÃO ORIENTADA A OBJETOS
• Um modelo arquitetura orientada a objetos estrutura o sistema
em um conjunto de objetos não firmemente acoplados com
interfaces bem definidas.
• Os objetos chamam os serviços oferecidos por outros objetos.
• Uma decomposição orientada a objetos está relacionada a
classes de objetos, seus atributos e suas operações.
• Quando implementados, os objetos são criados a partir dessas
classes e algum modelo de controle é usado para coordenar as
operações de objetos.
28/43
MODELO DE OBJETOS: EXEMPLO
29/43
VANTAGENS E DESVANTAGENS
• Devido aos objetos não serem fortemente acoplados, a
implementação de objetos pode ser modificada sem afetar
outros objetos.
• Os objetos são muitas vezes representações de entidades do
mundo real e, assim, a estrutura do sistema é rapidamente
entendida.
• Linguagens de programação orientadas a objetos são
amplamente utilizadas.
* Para usar serviços, os objetos devem fazer referência explícita
ao nome e à interface de outros objetos. Se uma mudança for
necessária, o efeito dessa mudança deve ser avaliado.
* Entidades mais complexas podem ser difíceis de representar
como objetos.
30/43
PIPELINE ORIENTADO A FUNÇÕES
• Em um pipelining orientado a funções ou modelo de fluxo de
dados, as transformações funcionais processam suas entradas e
produzem saídas.
• Os dados fluem de uma para outra função e cada etapa do
processamento é implementada como uma transformação.
• Quando as transformações são representadas como processos
separados, esse modelo é algumas vezes chamado de estilo de
duto (pipe) e filtro, segundo a terminologia Unix.
• Quando as transformações são sequenciais com dados
processados em lotes, esse modelo é sequencial em lote que é
extensivamente utilizado em sistemas de processamento de
dados.
• Não adequado para sistemas interativos.
31/43
PIPELINE ORIENTADO A FUNÇÕES - EXEMPLO
32/43
VANTAGENS E DESVANTAGENS
• Apoia o reúso de transformações.
• É intuitivo, no sentido de que muitas pessoas pensam em seu
trabalho em termos de processamento de entrada e saída.
• A evolução do sistema pela adição de novas transformações é
geralmente direta.
• É simples de ser implementado tanto quanto um sistema
concorrente ou sequencial.
* Entretanto, requer um formato comum para a transferência de
dados que possa ser reconhecido por todas as transformações.
* Sistemas interativos são difíceis de escrever usando o modelo
de pipeling por causa da necessidade de uma sequência de
dados a ser processada.
33/43
ESTILOS DE CONTROLE
• Os modelos de estruturação estão relacionados a como um
sistema é decomposto em subsistemas.
• Para funcionar como um sistema, os subsistemas devem ser
controlados de maneira que seus serviços sejam entregues no
lugar certo e no tempo certo.
• Existem dois estilos genéricos de controle usados em sistemas
de software:
• Controle centralizado. Um subsistema tem responsabilidade geral
pelo controle e inicia e para outros sistemas.
• Controle baseado em eventos. Em vez de informações de controle
serem incorporadas a um subsistema, cada subsistema pode
responder a eventos gerados externamente. Esses eventos podem
vir de outros subsistemas ou do ambiente do sistema.
34/43
CONTROLE CENTRALIZADO
• Um subsistema é designado como controlador de sistema e tem
a responsabilidade pelo gerenciamento da execução de outros
subsistemas.
• Modelo chamada-retorno. Modelo top-down de sub-rotina em que
o controle começa no topo da hierarquia de sub-rotina e, através
de chamadas de sub-rotinas, passa para os níveis mais baixos na
árvore. Apenas aplicável para sistemas sequenciais.
• Modelo gerenciador. Aplicável a sistemas concorrentes. Um
componente do sistema controla o início, a parada e a
coordenação de outros processos do sistema. Um processo é um
subsistema ou módulo que pode ser executado paralelamente
com outros processos.
35/43
MODELO CHAMADA-RETORNO: EXEMPLO
36/43
MODELO GERENCIADOR: EXEMPLO
37/43
SISTEMAS ORIENTADOS A EVENTOS
• Os modelos orientados a eventos são regidos pelos eventos
gerados externamente.
• Editores em que eventos de interface com usuário significam
comandos de edição, sistema de produção baseados em regras
• Dois principais modelos orientados a eventos:
• Modelos de broadcast. Nesses modelos, um evento é transmitido
a todos os subsistemas. Qualquer subsistema programado para
manipular esse evento pode responder a ele.
• Modelos orientados a interrupções. Esses modelos são usados
exclusivamente em sistemas de tempo real nos quais interrupções
externas são detectadas por um tratador de interrupções. Estas
são, então, passadas para algum outro componente para
processamento.
38/43
MODELO broadcast
• Eficazes na integração de sistemas distribuídos em diferentes
computadores na rede.
• Subsistemas registram interesse em eventos específicos.
Quando esses eventos ocorrem, o controle é transferido para o
subsistema que pode tratar o evento.
• Política de controle não é incorporada ao tratador de eventos e
mensagens. Os subsistemas decidem de quais eventos
necessitam e o tratador de eventos e mensagens assegura que
esses eventos sejam enviados a eles.
• No entanto, subsistemas não sabem se ou quando os eventos
serão tratados.
39/43
MODELO broadcast: EXEMPLO
40/43
ORIENTADOS A INTERRUPÇÕES
• Usados em sistemas de tempo real em que uma resposta
imediata a algum evento é essencial.
• Há uma série de interrupções conhecidas com um tratador
definido para cada tipo.
• Cada tipo de interrupção está associado ao local de memória
em que o endereço de seu tratador está armazenado. Quando
uma interrupção de determinado tipo é recebida, uma chave de
hardware transfere o controle imediatamente para seu tratador.
• A vantagem desse modelo é que ela permite respostas muito
rápidas aos eventos. A desvantagem é a complexidadeda
programação e a dificuldade de validação.
41/43
ORIENTADOS A INTERRUPÇÕES: EXEMPLO
42/43
RESUMO
• Projeto de arquitetura:
• Vantagens de explicitação da arquitetura.
• Arquitetura e requisitos não-funcionais.
• Conflitos arquiteturais.
• Estruturação de sistemas:
• Diagrama de blocos.
• Estilos arquiteturais: repositório; cliente-servidor; camadas ou
máquina abstrata.
• Decomposição modular: modelo de objetos; pipeline.
• Estilos de controle: controle centralizado; chamada-retorno;
gerenciador; baseado em eventos; orientado a interrupções.
• Referência utilizadas: [1, 2, 3].
43/43
Armando Fox and David Patterson.
Engineering software as a service: An agile approach using
cloud computing second edition, 2.0b7.
https://drive.google.com/file/d/
19dqWms9qUQ2Bi8JfsBhC5Q6zDeJd0s5o/view, 2020.
[Online; accessed 25-September-2023].
Shari Lawrence Pfleeger.
Engenharia de Software: Teoria e prática.
Prentice-Hall, São Paulo, 2a. edition, 2004.
Ian Sommerville.
Engenharia de Software.
Pearson Addison-Wesley, São Paulo, 8a. edition, 2007.
43/43
https://drive.google.com/file/d/19dqWms9qUQ2Bi8JfsBhC5Q6zDeJd0s5o/view
https://drive.google.com/file/d/19dqWms9qUQ2Bi8JfsBhC5Q6zDeJd0s5o/view