Princípios de Projeto de Software - parte 2

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Princípios de Projeto
Parte 2
Prof. Clayton Vieira Fraga Filho
site: www.claytonfraga.pro.br
e-mail: claytonfraga@gmail.com
1
Conceitos de Projeto
Arquitetura: é a estrutura que abrange os componentes do software, propriedades externamente visíveis desses componentes e as relações entre eles.
 É uma descrição em alto nível de abstração que permite uma visão completa do sistema.
Uma arquitetura é uma abstração de um sistema que suprime detalhes dos elementos que não afetam como eles são usados, como se relacionam, como interagem e como usam outros elementos.
2
Conceitos de Projeto
A arquitetura deve dar suporte à funcionalidade do sistema. Desta forma, o comportamento dinâmico do sistema deve ser considerado.
A arquitetura deve está em conformidade com a qualidade (requisitos não-funcionais).
No nível arquitetural, todos os detalhes de implementação devem ser escondidos.
Até o projeto arquitetônico, aspectos relacionados ao hardware e à plataforma de implementação ainda não foram tratados, já que a fase de análise pressupõe tecnologia perfeita. 
Arquitetura
3
Conceitos de Projeto
4
Conceitos de Projeto
 Modelos estruturais: representam a arquitetura como uma coleção organizada de componentes de programa;
 Modelos de arcabouço: buscam por um projeto estrutural que seja repetítivel (padrões), para tipos de aplicações similares;
 Modelos dinâmicos: tratam dos aspectos comportamentais da arquitetura de programa, indicando como a estrutura ou a configuração do sistema pode mudar ao receber eventos externos.
Arquitetura
5
Conceitos de Projeto
Módulos: conjuntos de componentes que fornecem e usam serviços de outros componentes do sistema; 
Módulos são compostos de outros componentes mais simples;
Sub-sistemas não dependem de serviços fornecidos por outros sub-sistemas. Eles comunicam-se entre si;
6
Conceitos de Projeto
Pressman define como: Elemento funcional de programa que incorpora lógica de processamento, estruturas de dados internas que são necessárias para implementar a lógica de processamento e uma interface que possibilita ao componente ser chamado e dados serem passados para ele.
Componente
A OMG define como: "parte modular, possível de ser implantada e substituível de um sistema que encapsula implementação e exibe conjunto de interfaces
7
Conceitos de Projeto
Componente = provedor de serviços
 O componente é uma entidade executável independente;
 O código-fonte não está disponível, de maneira que o componente não precisa ser compilado antes de ser usado com outros componentes do sistema;
 Os serviços oferecidos por um componente são disponibilizados por meio de uma interface, e todas a interações ocorrem por essa interface;
 A interface com o componente é expressa em termos de operações parametrizadas e seu estado interno nunca é exposto;
Pressman define que o verdadeiro significado do termo "componente" diferirá dependendo do ponto de vista do engenheiro de software que o usa. 
8
Conceitos de Projeto
Componente
9
Conceitos de Projeto
Módulos: conjuntos de elementos mantidos pela equipe de desenvolvimento que fornecem e usam serviços de outros elementos do software; 
Podem ser compostos de outros elementos mais simples (p.e: classes), ou componentes (provedores de serviços);
10
Modularização
11
Um módulo é uma unidade cujos elementos estruturais estão fortemente conectados entre si e (relativamente) fracamente conectados com elementos de outras unidades. 
(McClelland and Rumelhart, 1995)
São estruturalmente independentes mas que funcionam juntas.
Conceitos de Projeto
11
Granularidade dos módulos: A granularidade do artefato de software é um fator relevante que ajuda a definir o conceito de módulo.
 Uma instrução, por exemplo, tem um nível de granularidade menor, que uma função ou procedimento. 
 Uma biblioteca, que agrupa diversos funções e procedimentos tem uma granularidade maior.
12
Instruções
Função ou 
procedimento
Biblioteca
Programming 
in the Small
Programming 
in the Large
Conceitos de Projeto
Modularização
12
Submodularidade: módulos grandes e caros, além de difíceis de entender e modificar devido a sua estrutura monolítica;
Supermodularidade: infinidade de pequenos módulos com custo elevado devido a necessidade de integração entre módulos
Modularização
13
13
Projeto: Diretrizes de qualidade
 Um projeto deve exibir uma arquitetura que:
tenha sido criada por meio de estilos ou padrões arquiteturais reconhecíveis;
seja modularizada;
pode ser implementada de modo evolucionário, facilitando a implementação e o teste;
 Um projeto deve ser modular; o software deve ser logicamente particionado em elementos ou subsistemas.
 Um projeto deve conter representações distintas dos dados, arquitetura, interfaces e componentes.
14
 Um projeto deve levar a estruturas de dados e baseadas em padrões de dados reconhecíveis.
 Um projeto deve levar a componentes que exibam características funcionais independentes.
Projeto: Diretrizes de qualidade
15
 Um projeto de ser derivado por meio de um método passível de repetição que seja conduzido pela informação obtida durante a análise dos requisitos do software; 
 Um projeto deve ser representado usando uma notação que efetivamente comunique seu significado.
Projeto: Diretrizes de qualidade
16
 Abstração: - Quando consideramos uma solução modular para qualquer problema, muitos níveis de abstração podem ser colocados.
 No nível mais alto de abstração, uma solução é enunciada em termos amplos usando uma linguagem do ambiente do problema.
 Nos níveis mais baixos de abstração, uma descrição mais detalhada da solução é fornecida.
Modularidade e níveis de abstração
17
 Refinamento: - Um programa é desenvolvido pelo refinamento sucessivo de níveis de detalhes procedurais.
 É realizada a decomposição de um enunciado macroscópico de uma função(uma abstração procedural) passo a passo, até alcançar declarações em linguagem de programação.
Ex: Pseudocódigo  Java.
Modularidade e níveis de abstração
18
1º) Nível de Abstração:
Gravar dados do aluno
Modularidade e níveis de abstração
19
2º) Nível de Abstração: um algoritmo específico:
Pegar dados do aluno
Realizar conexão com o banco de dados
Inserir no Banco de Dados
Modularidade e níveis de abstração
20
3º) Nível de Abstração: um algoritmo detalhado:
public boolean salvar(Aluno pAluno) {
 Connection objConexao = FabricaConexao.getConexao();
 try {
 Statement objSTM = objConexao.createStatement();
 objSTM.execute("INSERT INTO aluno(id, nome, email, celular) VALUES('" + pAluno.getId() +
 "','" + pAluno.getNome() +
 "','" + pAluno.getEmail() +
 "','" + pAluno.getCelular() + "')");
 objSTM.close();
 return true;
 } catch (Exception erro) {
 String errorMsg = "Erro ao Persistir: " + erro.getMessage();
 JOptionPane.showMessageDialog(null, errorMsg, "Mensagem", JOptionPane.ERROR_MESSAGE);
 return false;
 }
}
Modularidade e níveis de abstração
21
Modularidade
 O software pode ser dividido em módulos, que são integrados para satisfazer aos requisitos do sistema.
É mais fácil de se resolver um problema complexo quando ele é dividido em partes administráveis.
22
Um bom projeto modular reduz a complexidade, facilita a mudança e resulta numa implementação mais fácil ao estimular o desenvolvimento paralelo de diversas partes de um sistema.
Ocultamento de informação
Independência funcional
 Coesão
 Acoplamento
Modularidade
23
Ocultamento de informação
Módulos devem ser especificados e projetados de tal forma que as informações (procedimentos e dados) contidas num módulo sejam inacessíveis a outros módulos que não tenham necessitam destas informações.
Reduz a ocorrência de “efeitos colaterais”
Limita o impacto global das decisões locais de projeto
Enfatiza comunicação através de interfaces controladas
Desencoraja o uso de dados globais
Leva ao encapsulamento - um atributo de projeto de alta qualidade
Resulta em qualidade de software
24
A independência funcional é conseguida desenvolvendo-se módulos
com função “de um só propósito" e "aversão" a interações excessivas com outros módulos. 
Um software com módulos independentes é mais fácil de ser desenvolvido e mais fácil de ser mantido.
A independência funcional de um módulo é medida usando-se dois critérios : coesão e acoplamento .
Independência funcional
25
Coesão - medida da unidade funcional relativa de um módulo.
Acoplamento - medida da interdependência relativa entre
os módulos.
Independência funcional
26
Acoplamento
27
Quanto menor o número de conexões entre os módulos, menor a chance do efeito cadeia (propagação);
 Deseja-se trocar um módulo com um mínimo de riscos de ter de trocar outro módulo;
Deseja-se que cada mudança do usuário afete o mínimo de módulos;
Enquanto estiver sendo realizada a manutenção de um módulo, não deve existir a necessidade de se preocupar com a codificação interna de nenhum outro módulo.
27
Coesão
28
A coesão de um módulo é o grau de relacionamento entre atividades que este realiza (métodos, responsabilidades)
 Quanto maior o grau de coesão melhor
 A coesão e o acoplamento estão inter relacionados, pois a coesão de um módulo geralmente determina o quanto ele será acoplado a outros módulos.
 Boa coesão é uma forma de minimizar acoplamento
28
Acoplamento
29
Exemplos de dependência entre componentes
Referências que um componente faz a outro. Ex. o componente A chama o componente B, de modo que o componente A depende de B para completar suas funções;
Quantidade de dados que são fornecidos de um componente a outro. Pode-se ter desde um parâmetro, o conteúdo de um vetor ou um bloco de dados. 
Grau de controle que um componente exerce sobre outro. Ex. A pode fornecer um indicador (flag) de controle para B.
30
Na decomposição do projeto, os componentes de um determinado nível aperfeiçoam os componentes do nível acima.
Níveis de Abstração: ajudam a entender o problema.
Níveis Superiores e mais abstratos ocultamos detalhes dos componentes funcionais e de dados.
Modularidade e níveis de abstração
31
Modularização
32
Um módulo ENCAPSULA seus componentes.
tipos
constantes
variáveis
procedures
functions
...
Módulo pode ser só uma procedure ou function (prog. in the small), ou pode conter diversos componentes agrupados e com um propósito em comum:
Para conseguir ter uma interface pequena, um módulo deixa poucos componentes visíveis para fora dele. Esses componentes são “exportados” pelo módulo. Os outros componentes permanecem “escondidos “ (hidden) dentro do módulo, sendo usados para ajudar na implementação dos componentes exportados.
32
Ocultamento de informação
Módulos devem ser especificados e projetados de tal forma que as informações (procedimentos e dados) contidas num módulo sejam inacessíveis a outros módulos que não necessitem destas informações.
Reduz a ocorrência de “efeitos colaterais”
Limita o impacto global das decisões locais de projeto
Enfatiza comunicação através de interfaces controladas
Desencoraja o uso de dados globais
Leva ao encapsulamento - um atributo de projeto de alta qualidade
Resulta em qualidade de software
33
33
Ocultamento de informação
Um subconjunto das propriedades do módulo é escolhido como parte pública, oficial, disponível para os clientes.
34
34
A independência funcional é conseguida desenvolvendo-se módulos com função “de um só propósito" e "aversão" a interações excessivas com outros módulos. 
Um software com módulos independentes é mais fácil de ser desenvolvido e mais fácil de ser mantido.
A independência funcional de um módulo é medida usando-se dois critérios estruturais: coesão e acoplamento .
Independência funcional
35
35
Coesão - medida da unidade funcional relativa de um módulo.
 	- “cola” que mantém os módulos juntos
Acoplamento - medida da interdependência relativa entre os módulos.
	- a “força” da conexão entre módulos
Independência funcional
36
36
 Cada módulo deve ser altamente coeso (highly cohesive)
– módulo é visto como "unidade"
– componentes internos a um módulo estão relacionados
 Módulos devem apresentar baixo acoplamento (low coupling)
– módulos possuem poucas interações com outros módulos
– podem ser compreendidos separadamente 
Independência funcional
37
37
Critérios de modularidade
38
Cinco critérios de avaliação da capacidade de um método de programação para atingir a modularidade e relatar a orientação a objeto são sugeridos (Bertrand Meyer):
 Decomposição modular (Decomposability);
 Composição modular (Composability);
 Facilidade de compreensão dos módulos (Understandability);
 Continuidade modular (Continuity);
 Proteção modular (Protection).
38
 Decomposição modular
39
Divisão de um problema maior em subproblemas com soluções individuais.
Critérios de modularidade
39
Composição modular
40
Módulos podem ser combinados para produzir novos sistemas de software;
Ex: Biblioteca de sub-rotinas (procedimentos e funções) e componentes.
Critérios de modularidade
40
Facilidade de compreensão dos módulos
41
Módulos podem ser entendidos em separado pelo leitor humano, sem ter que verificar outros.
Critérios de modularidade
41
Continuidade modular
42
O projeto satisfaz este critério se uma alteração na especificação do problema gera alteração em um só módulo
Mudança na especificação
Mudança no programa
Critérios de modularidade
42
Proteção modular
43
Em condição anormal de execução, o problema fica confinado a este módulo ou no máximo em módulos vizinhos
Erros em tempo de execução
Falhas de hardware
Entradas erradas
Dados corrompidos
Falta de recursos necessários
Critérios de modularidade
43
Princípios
44
Princípios a serem seguidos para assegurar a modularidade.
 Mapeamento direto;
 Poucas interfaces;
 Interfaces pequenas e explícitas;
 Esconder informações
44
Princípios
45
Mapeamento direto
A estrutura modular de um sistema de software deve continuar a ser compatível com qualquer estrutura modular com o domínio do problema
Qualquer sistema de software é feito para atender necessidades de alguns domínios de problema. Se você tiver um bom modelo para descrever esse domínio, vai achar que é desejável manter uma clara correspondência (mapeamento) entre a estrutura do solução, conforme previsto pelo software, bem como a estrutura do problema, como descrito pelo modelo. Daí o primeira regra: 
45
Princípios
46
 Poucas interfaces
Essa regra limita o número total de canais de comunicação entre módulos em uma arquitetura de software:
A comunicação pode ocorrer entre os módulos em uma variedade de maneiras. Os módulos podem chamar uns aos outros (se eles são os procedimentos), partes de estruturas de dados, etc.
Cada módulo deve se comunicar com o mínimo possível de módulos.
46
Princípios
47
 Poucas interfaces
Se um software é composto de n módulos, então o número de conexões entre módulos deve permanecer muito mais próximo do mínimo mostrado como (A) na figura, que do máximo, , mostrado como (B).
47
Princípios
48
 Poucas interfaces
Esta regra segue os critérios continuidade e de proteção modular :
se existem muitas relações entre os módulos, então o efeito de uma mudança ou de um erro pode propagar-se a um grande número de módulos. 
Também está ligada à modularidade, facilidade de compreensão dos módulos decomposição modular.
48
Princípios
49
 Poucas interfaces
A figura (A) mostra um exemplo do número mínimo de conexões (n-1), em uma estrutura extremamente centralizada: um módulo “controlador", todos os outros se comunicam com ele. 
Existem estruturas com responsabilidades melhor definidas como em (C), que tem quase o mesmo número de links. Neste esquema, cada módulo só se comunica com seus dois vizinhos mais próximos, mas não há nenhuma autoridade central. Tal estilo de design é um pouco surpreendente a princípio, uma vez que não se conforma com o modelo tradicional de design orientado à sub-rotinas. 
49
Princípios
50
 Poucas interfaces
No caso (A), existem 7 módulos, e 6 conexões, assim como no caso (C).
No caso (B), existem 6 módulos, portanto 15 conexões.
Considere que:
O custo de desenvolvimento por módulo é de
8 U.M.
O custo de integração (custo da conexão) entre 2 módulos é de 4 U.M.
Temos:
Custo total de (A) = 7 × 8 + 6 × 4 = 80 U.M
Custo total de (B) = 6 × 8 + 15 × 4 = 108 U.M
50
Princípios
51
Interfaces pequenas e explícitas
Interfaces pequenas e explícitas ou "acoplamento fraco" diz respeito ao tamanho das conexões entre módulos ao invés de seus números:
Se dois módulos se comunicam, eles devem trocar o mínimo possível de informações (acoplamento por dados)
51
Princípios
52
Ocultamento de informação
Os dados de um módulo só devem ser acessado a partir da interface.
Parte pública
Parte privada
52
Princípios de Projeto
Parte 2
Prof. Clayton Vieira Fraga Filho
site: www.claytonfraga.pro.br
e-mail: claytonfraga@gmail.com
ENG10508 – Projeto de Sistemas de Software
53