Princípios e Conceitos de Software(v2)

Apresentação em tema: "Princípios e Conceitos de Software(v2)"— Transcrição da apresentação:

1 Princípios e Conceitos de Software(v2)
Compreender os fundamentos de projeto de software

2 Agenda Conceitos de Projetos. Projeto Modular Efetivo.
Heurísticas de Projeto para Modularidade efetiva.

3 Conceitos de Projetos Abstração Refinamento Modularidade
Arquitetura de Software Hierarquia de Controle Particionamento estrutural Estrutura de dados Procedimento de Software Ocultamento da informação

4 Abstração Quando consideramos uma solução modular para qualquer problema, muitos níveis de abstração pode ser levantados. No nível mais alto de abstração, uma solução é enunciada em termos amplos usando a linguagem de ambiente do problema. Nos níveis mais baixos de abstração, uma orientação procedimental é adotada.

5 Refinamento Um programa é desenvolvimento pelo refinamento sucessivo de níveis de detalhes procedimentais. Refinamento é na verdade um processo de elaboração. Começamos com um enunciado da função(ou descrição da informação) que é definida em alto nível de abstração. Isto é, o enunciado descreve a função ou informação conceitualmente, mas não fornece qualquer informação sobre o funcionamento interno da função ou a estrutura interna da informação. O refinamento leva o projetista a elaborar o enunciado original, fornecendo mais e mais detalhes à medida que cada refinamento(elaboração) ocorre.

6 Abstração e Refinamento
Abstração e refinamento são conceitos complementares. A abstração permite ao projetista especificar procedimentos e dados e ainda suprimir detalhes de baixo nível. O refinamento ajuda o projetista a revelar detalhes de baixo nível à proporção que o projeto progride. Ambos os conceitos ajudam o projetista a criar um modelo completo de projeto à medida que o projeto evolui.

7 Modularidade Isto é o software é dividido em partes nomeados separadamente e endereçaveis, frequentemento chamados de módulos, que são integrados para satisfazer os requisitos do problema.

8 Hierarquia de Controle
Hierarquia de controle, também chamada estrutura de programa, representa a organização dos componentes de programa(módulos) e implica uma hierarquia de controle.

9 Particionamento estrutural
Se o estilo arquitetural de um sistema hierárquico, as estruturas do programas podem ser particionadas tanto horizontalmente quanto verticalmente. Particionamento horizontal, define ramos separados da hierarquia modular para cada função principal do programa Particionamento vertical, sugere que o controle(tomada de decisão) e o trabalho sejam distribuídos de maneira descendente na estrutura do programa. Os módulos de nível alto devem desempenhar funções de controle e fazer pouco trabalho de processamento real. Módulos que se situam abaixo na estrutura devem ser os trabalhadores, realizando todas as tarefas de entrada, de computação e de saída.

10 Estrutura de Dados Estrutura de Dados é uma representação do relacionamento lógico entre elementos de dados individuais. Como a estrutura da informação vai invariavelmente afetar o projeto procedimental final, a estrutura de dados é tão importante quanto a estrutura do programa para a representação da arquitetura de software. A estrutura de dados determina a organização, os métodos de acesso, o grau de associatividade e as alternativas de processamento da informação.

11 Procedimento de Software
O procedimento de software focaliza os detalhes de processamento de cada módulo individualmente. O procedimento deve fornecer uma especificação precisa do processamento, incluindo sequencia de eventos, pontos exatos de decisão, operações repetitivas e até organização e estrutura de dados.

12 Ocultamento da Informação
Ocultamento implica que efetiva modularidade pode ser conseguida pela definição de um conjunto de módulos independentes que informam uns aos outros apenas o necessário para realizar uma função do software.

13 Abstração X Ocultamento
Abstração ajuda a definir as entidades procedimentais(ou informacionais) que constituem o software. Ocultamento define e impõe restrições de acesso, tanto a detalhes de processamento dentro de um módulo quanto a qualquer estrutura de dados local usada pelo módulo.

14 Projeto Modular Efetivo
Todos os conceitos fundamentais de projeto descrito anteriormente servem para induzir projetos modulares. Um projeto modular reduz a complexidade, facilita a modificação(um aspecto critico da manutenibilidade de software) e resulta em implementação mais fácil pelo incentivo ao desenvolvimento paralelo de diferentes partes de um sistema. Alguns conceitos usados em Projeto Modular. Independência Funcional Coesão Acoplamento

15 Independência funcional
O conceito de independência funcional é uma decorrência direta da modularidade dos conceitos de abstração e ocultamento funcional A independência funcional é conseguida pelo desenvolvimento de módulos com função de “finalidade única” e uma “aversão” a interação excessiva com outros módulos.

16 Independência funcional
Dito de outro modo, queremos projetar software de maneira que cada módulo cuide de uma subfunção específica dos requisitos e tenha uma interface simples quando visto de outras partes da estrutura do programa. Módulos independentes são mais fáceis de manter(e testar) porque os efeitos secundários causados por modificação de projeto ou código são limitados, a propagação de erros é reduzida e os módulos reusáveis são possíveis.

17 Independência funcional
Para resumir, independência funcional é a chave para um bom projeto, e o projeto é a chave da qualidade de software. Independência é medida usando dois critérios qualitativos: coesão e acoplamento.

18 Coesão Um modulo coeso realiza uma única tarefa dentro de um procedimento de software, requerendo pouca interação com procedimentos que estão sendo realizados em outras partes de um programa. Um módulo coeso deveria (idealmente) fazer apenas uma coisa. Altamente coeso: Excelente. Baixa coesão: Problemas

19 Acoplamento Acoplamento é uma medida da interconexão entre módulos numa estrutura de software. O acoplamento depende da complexidade da interface entre módulos, do ponto em que é feita entrada ou referência a um módulo e que dados passam através da interface. Em projeto de software, lutamos por acoplamento mais baixo possível. Conectividade simples entre módulos resulta em software bem mais fácil de entender e menos propenso a “efeito de propagação” que acontece quando erros que ocorrem em um lugar se propagam por todo o sistema.

20 Heurísticas de Projeto para Modularidade efetiva
A estrutura do programa pode ser manipulada de acordo com o seguinte conjunto de heurísticas: (Heurística, popularmente falando, trata-se de um método não comprovado cientificamente, ou seja, não tem confirmação matemática. Portanto, uma decisão tomada por experiência na função, intuição, bom senso ou outra forma que não seja confirmada por um método matemático, trata-se de confirmação heurística)

21 Heurísticas de Projeto para Modularidade efetiva
1. Avalie a “primeira iteração” da estrutura do programa para reduzir o acoplamento e melhorar a coesão: Uma vez desenvolvida a estrutura do programa, os módulos podem ser explodidos ou implodidos com o objetivo de melhorar a independência modular. Um módulo explodido transforma-se em dois ou mais módulos na estrutura final do programa. Um módulo implodido é o resultado da combinação do processamento implícito em dois ou mais módulos.

22 Heurísticas de Projeto para Modularidade efetiva
2. Avalie as interfaces do módulo para reduzir a complexidade e redundância e aperfeiçoar a consistência: A complexidade de interface de um módulo é uma causa importante de erros de software. Interfaces devem ser projetadas para passar informação de modo simples e devem ser consistentes com a função do módulo.

23 Heurísticas de Projeto para Modularidade efetiva
3. Defina módulos cuja função seja previsível, mas evite módulos que são excessivamente restritivos. Um módulo que restringe o processamento a uma única subfunção exibe alta coesão e é visto favoravelmente por um projetista.

24 Heurísticas de Projeto para Modularidade efetiva
4. Procure obter módulos “de entrada controlada” evitando “conexões patológicas”. Um software é mais fácil de entender e consequentemente mais fácil de manter quando as interfaces de módulos são restritas e controladas. Conexão patológica refere-se a desvios ou referências no meio de um módulo.

25 Bibliografia Pressman Capitulo 10.