Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011
UML Linguagem Unificada de Modelagem Projeto de Software
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
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
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
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
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
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
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
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
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
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
Qualidade de um bom Projeto
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
Qualidade em Software Qualidade está relacionada a atributos: funcionalidade, usabilidade, confiabilidade, desempenho, generalidade. Ronaldo C. Oliveira 15
Qualidade em Software Funcionalidade Atendimento dos RFs Atendimentos dos RNFs Usabilidade Utilização, Estética Mensagens de erro Auxílio Ronaldo C. Oliveira 16
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
Qualidade em Software Generalidade Extensibilidade Reparabilidade Adaptabilidade Configurabilidade Ronaldo C. Oliveira 18
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
Conceitos Aplicados ao Projeto Abstração Arquitetura Esqueleto do software Independência Funcional Ocultamento de informação Ronaldo C. Oliveira 20
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
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
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
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
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
Conceitos Aplicados ao Projeto Coesão + Acoplamento Qualidade de Software Ronaldo C. Oliveira 26
Conceitos Aplicados ao Projeto Refatoração/refabricação Padrões Arquitetura Design Idiomas Ronaldo C. Oliveira 27
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
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
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
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
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
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
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
Padrões de Arquitetura: Cliente-Servidor Ronaldo C. Oliveira 35
Padrões de Arquitetura Cliente-Servidor Facilidades Distribuição Escalabilidade Evolução independente Ronaldo C. Oliveira 36
Padrões de Arquitetura Cliente-Servidor Dificuldades Complexidade de implementação Proteção Gerenciamento Desempenho dependente da carga da rede Ronaldo C. Oliveira 37
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
Padrões de Arquitetura Camadas Facilidades Apoio ao desenvolvimento incremental/evolucionário Evolução Portabilidade Ronaldo C. Oliveira 39
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
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
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
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
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
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
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
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
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