Engenharia de Software
Processo de desenvolvimento
Modelagem do sistema
Arquiteturas
Atingindo qualidade de software
Rodrigo M A Almeida
Processo de desenvolvimento
Processo de desenvolvimento
•
Existem diversas ferramentas para modelar,
avaliar e escolher uma arquitetura
–
Design patterns: soluções genéricas para problemas de
baixo-nível
–
Convenções de Design: coleção de padrões que auxiliam
na definição de uma atividade
Processo de desenvolvimento
•
Geralmente não existe um modelo de referência
para o sistema em desenvolvimento
•
Existem algumas soluções genéricas, conhecidas
como arquiteturas de software
– Focar em apenas uma arquitetura pode trazer problemas
– Fazer um bom projeto esta relacionado em selecionar, adaptar e integrar diversos estilos de arquiteturas para produzir o
Processo de desenvolvimento
•
Projetar a arquitetura de um software é um
processo iterativo
•
O documento final (Software Architecture
Modelagem do sistema
•
Porque modelar o sistema
– Entender o sistema
– Determinar a possibilidade de reutilização de módulos de outros sistemas
– Apresentar a "planta-baixa" para o sistema a ser construido – Imaginar detalhes sobre a evolução do sistema
– Analizar dependências
Modelagem do sistema
•
Alguns problemas no projeto não possuem solução
pronta
–
Os projetistas devem decompor o sistema para isolar os
problemas principais
•
Alguns modelos para decompor o projeto:
–
Funcional
–
Orientado às caracteristicas
–
Orientado à informação
–
Orientado aos processos
Modelagem do sistema
•
Funcional
–
Separar as funcionalidades/requerimentos em módulos
–
Começar com as funcionalidades que estão listadas na
ficha de requerimentos
–
Se necessários separar as funcionalidades em módulos
para facilitar a implementação
Modelagem do sistema
•
Orientado à funcionalidade
–
Atribuir funcionalidades/responsabilidade à cada um
dos módulos
–
O projeto de alto nível descreve o sistema em questões
de serviço e da coleção de funcionalidades
Modelagem do sistema
•
Orientado à informação
–
Foco em como os dados serão tratados pelos módulos
–
O projeto de alto nivel descreve as estruturas de dados
–
O projeto de baixo nível descreve
•
Como os dados estão distribuidos nos módulos
Modelagem do sistema
•
Orientado à processo
–
Divide o sistema em diversos processos concorentes
–
Projeto de alto nível
•
Identifica os principais processos do sistema
•
Atribui tarefas para os processos
•
Explica como os processos são coordenados
Modelagem do sistema
•
Orientado à eventos
–
Foca nos eventos que o sistema tem que atender e atribui
responabilidade do antendimento para diferentes módulo
–
O progeto de alto nível apresenta as entradas esperadas
–
O projeto de baixo nível decompõe o sistema em estados e
descreve como os eventos modificam o estado atual do
Modelagem do sistema
•
Um projeto é
modular
quando cada atividade do
sistema é feita por apenas um módulo, e as
entradas e saídas são bem definidas
•
Um software é
bem definido
quando a interface é
acertiva e especifica precisamente o
Modelagem do sistema
- Visualização
•
Entre os modos de visualização do sitema
os mais comuns são:
–
Decomposição
–
Dependencias
–
Generalizações
–
Execução
–
Implementação
–
Entrada/Saída
Modelagem do sistema
- Visualização
•
Decomposição
–
A vista da decomposição apresenta o sistema
como unidades programáveis
–
É geralmente hierárquica
Modelagem do sistema
- Visualização
•
Dependências
–
Mostra a interdependências entre as unidades
do software
–
É muito útil no planejamento do projeto
Modelagem do sistema
- Visualização
•
Generalização
–
Mostra partes do software que são
generalizações ou especializações de outras
–
É importante quando se projeta um software
Modelagem do sistema
- Visualização
•
Execução
–
É feita com o uso de fluxogramas, mostrando os
componentes e conexões entre esses em
"run-time"
–
Cada componente é uma entidade distinta,
geralmente um processo separado.
–
Uma conexão é um mecanismo de interconexão
como um canal de comunicação, região de
Modelagem do sistema
- Visualização
•
Implementação
–
Mapeia cada unidade com os respectivos
arquivos de código que contém a
implementação do módulo
–
Auxilia o programador a encontrar as
Modelagem do sistema
- Visualização
•
Entrada/Saída
–
Este diagrama mapeia os recursos, conexões e
componentes de interface do sistema
Modelagem do sistema
- Visualização
•
Tarefas
–
Separa o projeto em taferas a serem
implementadas de modo que possam ser
dividas entre a equipe
Arquiteturas
•
Cano-Filtro
•
Cliente-servidor
•
Ponto-à-ponto
•
Repositório
Arquiteturas
•
Cano-Filtro
–
O "cano" são os dados
–
O "filtro" são as transformações de informação
Arquiteturas
•
Vantages
– O projetista pode compreender o efeito de todo o sistema na entrada e saída, como a composição dos filtros
– Os filtros podem ser reutilizados facilmente em outros sistemas – Evolução do sistema é simples
– Permitir a execução simultânea de filtros
•
Desvantagem
– Incentiva o processamento em lote
Arquiteturas
•
Cliente-Servidor
–
O servidor possui serviços
–
O cliente apenas faz requisições
Arquitetura
•
Ponto-à-ponto
–
Cada componente age como um cliente e um
servidor para os outros pontos.
–
Qualquer componente pode iniciar uma
solicitação de qualquer outro componente
–
Caracteristicas
• Escalona muito bem
• Aumenta a capacidade do sistema • Alta tolerância à falhas
Arquiteturas
•
Os componentes interagem enviando
mensagens e reagindo à enventos
– O componente pode se inscrever para receber uma dada informação
– Quando outro componente anuncia um evento, todos os assinantes são avisados
•
Caracteristicas
– Sistema de fácil evolução e personalização.
– Fácil de reutilizar componentes de outros sistemas controlados por eventos.
– Necessita de repositório compartilhado de componentes para compartilhar dados persistentes.
Arquiteturas
•
Repositório
–
Dois componentes
• Um central
• Uma coleção de outros componentes que acessam o central para obter informações, atualizar dados etc.
–
Definindo quem pode falar
• Banco de dados tradicional: cada transação aciona um processo
• Quadro negro: O sistema central controla o acionamento do processo
Arquiteturas
•
Maior vantagem: abertura
– Pode ser disponibilizada para diversos programadores ao mesmo tempo
Arquiteturas
•
Camadas
– Cada camada provê recurso para a camada superior e utiliza das funções da camada inferior.
– Uma ponte pode permite que uma camada fure essa hierarquia. – O projeto deve contemplar protocolos explicando como um par de
camadas irá se comunicar
•
Vantagens
– Alto nível de abstração High levels of abstraction
– Relativamente simples de modificar/adicionar camadas
•
Desvantagens
– Nem sempre é simples de estruturar o sistema em camadas (NOT!)
Arquiteturas
Arquiteturas
•
Combinações
– Arquiteturas reais raramente se baseiam em um único estilo – Os tipos de arquitetura podem ser combinadas de várias
maneiras
• Use estilos diferentes em camadas diferentes (por exemplo, a arquitetura cliente-servidor no sistema geral com
componente de servidor decomposto em camadas)
• Estilos diferentes para modelar componentes diferentes ou tipos de interação
Atingindo qualidade de
software
•
Em geral busca se obter através do projeto
as seguintes caractristicas
– Modificabilidade – Performance – Segurança – Confiabilidade – Robustez
Atingindo qualidade de
software - Modificabilidade
•
O projeto deve ser facil de mudar
•
Numa mudança deve-se classificar as
unidades em
– Afetadas diretamente: acomodam as mudanças requisitadas – Afetadas indiretamente: as responsabilidades não mudam, mas
devem ser revisadas para continuar funcionando com as unidades modificadas
Atingindo qualidade de
software - Modificabilidade
•
Táticas para minimizar o número de unidades
afetadas por uma mudança:
– Antecipar as mudanças esperadas: Identificar as decisões de design que são mais propensos a mudar, e encapsular cada um em sua unidade de software próprio
– Coesão: Quanto mais coesas, menor a chance de que uma mudança de requisito altere muitos objetos
Atingindo qualidade de
software - Performance
•
Entre os pontos importantes temos:
– Tempo de resposta
Atingindo qualidade de
software - Performance
•
Táticas para melhorar o desempenho
incluem:
–
Melhorar a utilização dos recursos
–
Gerenciar a alocação de recursos de forma mais
eficaz
•
First-come/first-served: Os pedidos são
processados na ordem em que são recebidos
•
Prioridade explícita: Os pedidos são processados
em ordem de suas prioridades atribuídas
•
Primeiros primeiro prazo: Os pedidos são
processados em ordem de seus prazos iminentes
Atingindo qualidade de
software - Segurança
•
Duas principais características para a segurança
temos a imunidade e a resiliência
–
Imunidade: a capacidade de frustrar uma tentativa
de ataque
–
A arquitetura incentiva a imunidade por:
• Assegurando que todos os elementos de segurança estão incluídos no desenho
• Minimizar falhas de segurança exploráveis
–
Resiliência: capacidade de recuperar rapidamente e
facilmente de um ataque
• A arquitetura incentiva resiliência por:
• Segmentar funcionalidades para conter ataques
Atingindo qualidade de
software - Confiabilidade
•
Um sistema é confiável se desempenha as
suas funções necessárias corretamente sob
condições assumidas
–
É o software internamente livre de erros?
•
Uma falta é o resultado de erro humano,
em comparação com uma falha, que é uma
degeneração do comportamento
especificado
Atingindo qualidade de
software - Confiabilidade
•
Detecção de falhas passiva: esperar até que a
falha ocorrer durante a execução
•
Detecção de falhas ativa: verificar periodicamente
se há sintomas ou tentar prever quando irão
ocorrer falhas
•
Exceções: situações que fazem com que o sistema
se desvie do seu comportamento desejado
•
Exceções típicas incluem:
– Deixar de prestar um serviço
– Prestação do serviço errado
– Dados corrompidos
– Violação de um sistema
Atingindo qualidade de
software - Confiabilidade
•
Programação com N-versões
–
Dois times implementam separadamente a
mesma funcionalidade utilizando técnicas
diferentes
–
A chance de uma falha acontecer com os dois
sistemas é menor
Atingindo qualidade de
software - Robustez
•
Um sistema é robusto, se inclui mecanismos para acomodar
ou se recuperando de problemas no ambiente ou em outra
unidade
•
A desconfiança mútua: cada unidade de software assume
que as outras unidades contêm falhas
•
Táticas de robustez diferem das táticas de confiabilidade
•
Táticas de recuperação são semelhantes:
–
Reverter para estado checkpoint
–
Abortar uma transação
–
Iniciar uma unidade de backup
–
Fornecer serviço reduzido
–
Corrigir os sintomas e continuar o processamento
Atingindo qualidade de
software - Usabilidade
•
Usabilidade reflete a facilidade com que um
usuário é capaz de operar o sistema
Atingindo qualidade de
software - $$$
•
Deve-se sempre levar em conta questões financeiras no
desenvolvimento de um software
–
Comprar vs. Fazer
• Tempo x Dinheiro • Confiabilidade
• Componentes prontos introduzem barreiras • Ficar na mão do fornecedor
–
Desenvolvimento inicial vs Manutenção
• Modificabilidade salva gastos com manutenção mas aumenta complexidade e atrasa o projeto
