Engenharia de Software

Transcrição

1 Prof. M.Sc. Ronaldo C. de Oliveira FACOM

2 UML Linguagem Unificada de Modelagem Projeto de Software

3 Introdução O que é projeto em software? O termo projeto é um tanto ambíguo. Conjunto de modelos relacionados a um artefato (design). Proposta formal para um artefato (project). Ambos os significados têm sentido no contexto de software. Ronaldo C. Oliveira 3

4 Introdução O que é projeto em software? O projeto é a fase em que o engenheiro de software modela computacionalmente os RFs e RNFs. É a fase em que o engenheiro organiza o sistema em subsistemas para melhor atacar o problema. Ronaldo C. Oliveira 4

5 Introdução O que é projeto em software? É a fase em que o engenheiro expressa o como fazer. O projeto compreende um conjunto de atividades que precede as atividades de geração de código e testes. Ronaldo C. Oliveira 5

6 Introdução O que é projeto em software? O projeto envolve modelos sobre Modelo de Dados, Arquitetura, Protótipos de Interfaces, Componentes, Distribuição. Projeto de Algoritmos Ronaldo C. Oliveira 6

7 Modelo de Dados Influencia atributos como tempo de resposta e robustez. Permeia diferentes níveis Estrutura de dados de componentes Bases de Dados (a partir do DER) Armazém de Dados (facilita a mineração de dados) Ronaldo C. Oliveira 7

8 Modelo de Arquitetura Representa a estrutura do software e o relacionamento entre seus elementos. A arquitetura de um software é baseada na informação sobre o domínio da aplicação, na modelagem da estrutura do sistema (Diagrama de Classes), em padrões arquiteturais. Ronaldo C. Oliveira 8

9 Modelo de Interfaces Modela como os dados transitando intra-sistema e inter-sistema. Esse modelo contempla interface com o usuário, interfaces internas (componentes do sistema), interfaces externas (outros sistemas, rede, dispositivos). Ronaldo C. Oliveira 9

10 Modelo de Componentes Descreve detalhes internos dos componentes do software. Representa a interação entre os componentes. Example by U.Ottawa SEG 4210: Advanced Software Design and Reengineering Ronaldo C. Oliveira 10

11 Modelo de Distribuição Representa como os subsistemas / funcionalidades do software serão alocados no ambiente físico. Example by U.Ottawa SEG 4210: Advanced Software Design and Reengineering Ronaldo C. Oliveira 11

12 Projeto de Algoritmos Dependendo da necessidade do sistema o analista pode especificar um determinado algoritmo que ele quer o desenvolvedor utilize: Exemplo: algoritmo de calculo e validação do número de CPF e o número de CNPJ Ronaldo C. Oliveira 12

13 Qualidade de um bom Projeto

14 Projeto em Software Os modelos apresentados englobam a fase de projeto. Essa fase determina a qualidade do software. Atendimento dos RNFs. Ronaldo C. Oliveira 14

15 Qualidade em Software Qualidade está relacionada a atributos: funcionalidade, usabilidade, confiabilidade, desempenho, generalidade. Ronaldo C. Oliveira 15

16 Qualidade em Software Funcionalidade Atendimento dos RFs Atendimentos dos RNFs Usabilidade Utilização, Estética Mensagens de erro Auxílio Ronaldo C. Oliveira 16

17 Qualidade em Software Confiabilidade Consistência de resultados Segurança e Proteção Recuperação de falhas Desempenho Consumo de recursos Tempo de resposta Ronaldo C. Oliveira 17

18 Qualidade em Software Generalidade Extensibilidade Reparabilidade Adaptabilidade Configurabilidade Ronaldo C. Oliveira 18

19 Qualidade em Software A qualidade em software está relacionada à boa aplicação (boas práticas) de conceitos bem conhecidos em. Alguns desses conceitos são apresentados a seguir. Ronaldo C. Oliveira 19

20 Conceitos Aplicados ao Projeto Abstração Arquitetura Esqueleto do software Independência Funcional Ocultamento de informação Ronaldo C. Oliveira 20

21 Conceitos Aplicados ao Projeto Independência Funcional Conceito relacionado à interdependência dos módulos (programas) de um sistema. Boa decisão de projeto: módulos independentes. Por quê?! Ronaldo C. Oliveira 21

22 Conceitos Aplicados ao Projeto Independência Funcional Facilidades entendimento implementação reutilização teste modificação detecção de falha rastreamento Ronaldo C. Oliveira 22

23 Conceitos Aplicados ao Projeto Independência Funcional Relacionada com Coesão o quanto um determinado módulo ou método executa somente o objetivo previsto para aquele módulo ou método, ou seja, tem um papel bem definido e coerente dentro do sistema. Acoplamento o quanto um determinado módulo ou método é independente de outros módulos ou métodos. Ronaldo C. Oliveira 23

24 Conceitos Aplicados ao Projeto Independência Funcional: coesão Trata da coerência entre as atividades realizadas por uma módulo. Tipos: Funcional Sequencial Comunicação Procedural Temporal Lógica Coincidente Ronaldo C. Oliveira 24

25 Conceitos Aplicados ao Projeto Independência Funcional: Acoplamento Está relacionado com o grau de interdependência de um módulo em outro. Tipos: Conteúdo Comum Controle Dados Sem acoplamento Ronaldo C. Oliveira 25

26 Conceitos Aplicados ao Projeto Coesão + Acoplamento Qualidade de Software Ronaldo C. Oliveira 26

27 Conceitos Aplicados ao Projeto Refatoração/refabricação Padrões Arquitetura Design Idiomas Ronaldo C. Oliveira 27

28 Refatoração Técnica de reorganização que simplifica o projeto (ou código) de um componente sem mudar nada sua função ou comportamento Quando um software é refatorado, o projeto existente é examinado em termos de redundância, elementos de projetos não utilizados, algoritmos ineficientes, estruturas de dados mal construídas ou qualquer outra falha no projeto O resultado será um software mais fácil de integrar, testar e manter. Ronaldo C. Oliveira 28

29 Padrões de Arquitetura Softwares de mesmo domínio de aplicação guardam similaridades quanto à organização de seus módulos. Essa similaridade é denominada padrões de arquitetura. Ronaldo C. Oliveira 29

30 Padrões de Arquitetura Repositório Uma base de dados é utilizada para centralizar os dados da aplicação. Todos os componentes acessam a BD para realizar suas atividades. Ronaldo C. Oliveira 30

31 Padrões de Arquitetura Repositório Facilidades Compartilhamento de dados simples. Modelo de dados único. Independência entre os subsistemas do sistema quanto aos dados. Funções de segurança, proteção em único lugar. Ronaldo C. Oliveira 31

32 Padrões de Arquitetura Repositório Dificuldades Os subsistemas podem ter diferentes necessidades quanto ao modelo de dados. O desempenho pode ser afetado pelo modelo dados único. A evolução de um subsitema demanda análise de impacto nos demais. Os subsistemas podem ter necessidades diferentes quanto a segurança e proteção. Ronaldo C. Oliveira 32

33 Padrões de Arquitetura Repositório Variante Cada subsistema possui seu próprio repositório. Os subsistemas trocam mensagens entre si. Ronaldo C. Oliveira 33

34 Padrões de Arquitetura Cliente-Servidor A aplicação é organizada entre provedores (servidores) e consumidores (clientes) de serviços. Em geral, uma rede é utilizada como meio de comunicação. Ronaldo C. Oliveira 34

35 Padrões de Arquitetura: Cliente-Servidor Ronaldo C. Oliveira 35

36 Padrões de Arquitetura Cliente-Servidor Facilidades Distribuição Escalabilidade Evolução independente Ronaldo C. Oliveira 36

37 Padrões de Arquitetura Cliente-Servidor Dificuldades Complexidade de implementação Proteção Gerenciamento Desempenho dependente da carga da rede Ronaldo C. Oliveira 37

38 Padrões de Arquitetura Camadas A aplicação é organizada em diferentes camadas. Cada camada (também conhecida como máquina abstrata oferece serviços para as camadas adjacentes. Ronaldo C. Oliveira 38

39 Padrões de Arquitetura Camadas Facilidades Apoio ao desenvolvimento incremental/evolucionário Evolução Portabilidade Ronaldo C. Oliveira 39

40 Padrões de Arquitetura Camadas Dificuldades Estruturação rígida da aplicação uma camada pode oferecer serviços não utilizado por TODAS as camadas superiores. Desempenho Ronaldo C. Oliveira 40

41 Padrões de Arquitetura Referência Descreve a organização de classes de domínio de aplicação. Representa as características que a aplicação deveria possuir. Serve como gabarito para discussão sobre a arquitetura da aplicação. Ronaldo C. Oliveira 41

42 Padrões de Design Decomposição Modular Consiste em organizar os elementos (módulos) que compõem os subsistemas. Duas abordagens: orientada a objetos pipelining Ronaldo C. Oliveira 42

43 Padrões de Design Modelos de Controle Representa o fluxo de controle entre os elementos (subsistemas/módulos) da aplicação. Isto é, modela o acionamento dos subsistemas/módulos da aplicação. Duas abordagens: centralizado eventos Ronaldo C. Oliveira 43

44 Padrões de Design Modelo de Controle Centralizado Um elemento é o responsável por gerenciar a execução dos demais. Eventos baseados em valores de variáveis internas. Ronaldo C. Oliveira 44

45 Padrões de Design Modelo de Controle Centralizado Duas abordagens: Chamada-Retorno acionamento explícito sem preempção Gerente acionamento baseado em varredura com preempção Ronaldo C. Oliveira 45

46 Padrões de Design Modelo de Controle Baseado em Eventos O acionamento dos elementos da aplicação é baseado em eventos externos. Exemplos: clique do mouse; gatilho (vide SGBD); objetos ativos. Ronaldo C. Oliveira 46

47 Padrões de Design Modelo de Controle Baseado em Eventos Duas abordagens: Broadcast executado por um comando emitido pelo usuário Interrupção executa automaticamente através de um processo interno do sistema Ronaldo C. Oliveira 47

48 Padrões de Idioma Qual o padrão de codificação a ser utilizado? nomes (variáveis, funções) identação escrita Como documentar o código? variáveis funções Geração automática de documentação Ronaldo C. Oliveira 48