O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Projeto de Software

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 57 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Anúncio

Semelhante a Projeto de Software (20)

Anúncio

Projeto de Software

  1. 1. Projeto do Software Wagner Zaparoli wzaparoli@gmail.com
  2. 2. Projeto do Software 2 Agenda
  3. 3. Projeto do Software 3 Fundamentos
  4. 4. Projeto do Software 4 Definição Atividade do ciclo de vida da engenharia de software na qual os requisitos são analisados com o objetivo de produzir uma descrição da estrutura interna do software que sirva de base à Construção Arquitetura do software que apresenta a decomposição e organização do software em componentes e a interface entre esses componentes Processo Resultado
  5. 5. Projeto do Software 5 Escopo Arquitetura Interfaces Estrutura de Dados Análise Projeto Construção ...... Projeto Componentes
  6. 6. Projeto do Software 6 Importância Projeto é o único modo que se pode traduzir precisamente os requisitos Projeto serve como base para todas as etapas posteriores do ciclo de vida Projeto dá alma à qualidade do software
  7. 7. Projeto do Software 7 Competências O projeto deve implementar todos os requisitos contidos no modelo de análise O projeto deve ser um guia inteligível para os codificadores e testadores O projeto deve fornecer um quadro completo do software, focalizando aspectos informacionais, funcionais e comportamentais
  8. 8. Projeto do Software 8 Princípios Básicos O projeto não deve reinventar a roda (padrões) O projeto deve exibir uniformidade e integração O projeto deve ser avaliado quanto à qualidade, à medida que é criado O projeto deve ser estruturado para permitir modificações Projeto não é codificação
  9. 9. Projeto do Software 9 Conceitos Abstração: transformação do mundo real em modelos Refinamento: decompor um enunciado macroscópico de função em enunciados menores Modularidade: conceito de divisão do software em componentes, cada um com um objetivo, que quando integrados satisfazem os requisitos do problema Ocultamento: técnica pela qual um componente torna inacessível a outro, suas informações e comportamento Coesão: técnica que torna um componente independente ou pouco dependente de outros, através de sua especialização Acoplamento: medida da interconexão entre componentes numa estrutura de software
  10. 10. Projeto do Software 10 Modelo – Abordagem Estruturada Projeto de Dados Projeto Arquitetural Projeto da Interface Projeto de Componentes
  11. 11. Projeto do Software 11 Modelo – Abordagem OO Projeto de Subsistemas Projeto de Classes e Objetos Projeto de Mensagens Projeto de Responsabilidades
  12. 12. Projeto do Software 12 Processo
  13. 13. Projeto do Software 13 Processo – OOD 1 Particionar modelo de análise 2 Identificar a concorrência 3 Alocar subsistemas4 Desenvolver o projeto para interface 5 Escolher a estratégia para a gestão de dados 6 Definir esquema de colaborações 7 Definir o projeto do objeto
  14. 14. Projeto do Software 14 Particionar o Modelo Definir coleções de classes, relacionamentos e comportamentos coesivos, a serem empacotados como um subsistema* *Subsistema • Deve possuir uma responsabilidade. • Deve ter uma interface bem definida. • Classes de um subsistema devem colaborar apenas entre si. • Um subsistema deve ser particionado para mitigar a complexidade.
  15. 15. Projeto do Software 15 Identificar a Concorrência Classes que precisam agir sobre eventos de modo assíncrono e simultaneamente, são vistas como concorrentes Aloca-se cada subsistema a um processador independente Aloca-se os subsistemas ao mesmo processador e adota-se suporte de concorrência ou
  16. 16. Projeto do Software 16 Alocar Subsistemas a Processadores e Tarefas Tarefas normalmente são dirigidas por evento (interrupção externa ao sistema) ou por relógio (interrupção por um relógio do sistema). Template para Identificação do objeto • Nome da Tarefa: o nome do objeto. • Descrição: narrativa que descreve a finalidade do objeto. • Prioridade: prioridade da tarefa (alta, média, baixa). • Serviços: lista de operações sob responsabilidade do objeto. • Coordenada por: modo pelo qual o comportamento do objeto é invocado. • Comunica-se através de: valores de dados de entrada e saída relevantes para a tarefa.
  17. 17. Projeto do Software 17 Desenvolver o Projeto de Interface Usa como entrada o diálogo entre sistema e ator descrito nos casos de uso e os requisitos não funcionais de usabilidade Questões Importantes • Haverá funcionalidades críticas que exijam desempenho do usuário? • Há a necessidade de tecnologia assistida? • Qual é a taxa aceitável de erros (de operação) cometidos na execução de funcionalidades específicas? • Qual o tempo de aprendizagem para o domínio do uso do sistema? Considerações • Facilidade de aprender: associado ao tempo e esforço mínimo exigido para alcançar um determinado nível de desempenho no uso do sistema. • Facilidade de uso: relacionado à velocidade de execução de tarefas e à redução de erros no uso do sistema.
  18. 18. Projeto do Software 18 Escolher a Estratégia para Gestão de Dados Resume-se ao desenvolvimento do projeto dos atributos e das operações necessárias para gerir (persistir) os objetos • Construir o modelo de classes. • Construir o modelo conceitual de dados. • Construir o modelo lógico de dados. • Construir o modelo físico de dados. • Utilizar padrão DAO (Data Access Object) ou AR (Active Record) para gerir operações primitivas de acesso ao banco de dados. Considerações
  19. 19. Projeto do Software 19 Definir Esquema de Colaboração Colaboração é um meio de comunicação entre subsistemas, endereçado por um contrato Colaboração • O contrato indica o modo que o subsistema deve interagir. • É manifestado por mensagens que se movem entre os objetos dentro dos subsistemas. • Deve conter as classes, operações e formato das mensagens que implementam as interações entre colaboradores.
  20. 20. Projeto do Software 20 Definir Projeto do Objeto Processo para especificar os objetos, suas informações, seu comportamento e sua interface Objeto Instância da Classe
  21. 21. Projeto do Software 21 Especificação de Classe Descrição: objetivos da classe sob a visão dos dados que serão armazenados e dos serviços que serão prestados; Regra de Integridade Referencial: regras de integridade que envolvem essa classe e as classes a ela relacionadas (analisar a cardinalidade); Regra de Processo: regras de processo de negócio que comporão os serviços prestados por esta classe; Atributos Identificadores: atributos identificadores desta classe. Descrição: Esta classe tem por objetivo armazenar os dados dos clientes, sejam eles pessoas física ou jurídica. Regra de Integridade Referencial: Para excluir um registro de cliente, deve-se antes, excluir o respectivo registro de endereço na classe EnderecoCliente. Regra de Processo: Na inclusão de um novo cliente, caso seja pessoa física, validar CPF; caso seja pessoa jurídica, validar CNPJ. Atributos Identificadores: cd_cpf (para pessoas físicas); cd_cnpj (para pessoas jurídicas).
  22. 22. Projeto do Software 22 Especificação de Atributo Descrição: detalhar aqui o significado e os objetivos do atributo em função de sua natureza; Regra de Integridade do Valor do Dado: definir as restrições e regras que devem ser seguidas em função do tipo do atributo; Regra de Derivação: descrever aqui a origem do atributo, caso ele seja formado por outros atributos, por uma fórmula, ou por qualquer origem que não seja ele próprio. Descrição: valor da multa por atraso de pagamento. Regra de Integridade do Valor do Dado: o valor da multa não pode ultrapassar o valor de R$100,00. Regra de Derivação: o valor da multa deve ser calculado da seguinte forma: vl_multa_atraso = vl_fatura * i_atraso * nu_dias_atraso.
  23. 23. Projeto do Software 23 Especificação de Operação Nome da Operação Verbo no infinitivo representando uma ação Nome da classe associada Nome da classe, a qual a operação pertence Descrição da Operação Detalha todos os serviços que a operação tem por objetivo realizar Argumentos Nome Descrição Nome que descreve a natureza do argumento significado de cada argumento Retorno Nome Descrição Nome da informação resultante do processamento (execução) da operação detalhar aqui o significado do retorno Pré-Condições Ocorrência que deve acontecer antes da execução da operação Semântica Descrição da lógica da operação Pós-Condições Resultado produzido depois da execução da operação Exceções Exceptions ocorridas durante a execução da operação. Aqui deve-se detalhar os tratamentos necessários para cada exception.
  24. 24. Projeto do Software 24 Padrões
  25. 25. Projeto do Software 25 Padrões Representam uma solução conhecida para um problema conhecido em um dado contexto • Encapsulamento: um padrão encapsula um problema/solução bem definida. • Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão. • Abstração: os padrões representam abstrações da experiência. • Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe. • Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
  26. 26. Projeto do Software 26 Padrões GoF Gang of Four Criação (criação de objetos) Estruturais (tratam da associação entre classes e objetos) Comportamentais (divisões de responsabilidades entre classes e objetos) Abstract Factory Builder Prototype Singleton Adapter Bridge Decorator Façade Mediator Memento Observer State
  27. 27. Projeto do Software 27 Padrões GRASP Projetando Objetos com Responsabilidade Fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto • Quem deve ser responsável por criar uma nova instância de uma classe? • Que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento", mas as soluções oferecidas pelo "Especialista" não são apropriadas? • Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso? • Como tratar alternativas baseadas no tipo? Como criar componentes de software "plugáveis"? • Como manter os objetos focados, compreensíveis, gerenciáveis e, em conseqüência, com Baixo Acoplamento? • Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação? • Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização? • Qual é o princípio geral para a atribuição de responsabilidades aos objetos?
  28. 28. GRASP Projeto do Software 28 Padrões Information Expert Creator Indirection Low Coupling Pure Fabrication Polymorhism Controller High Cohesion Protected Variations
  29. 29. Projeto do Software 29 Refatoração
  30. 30. Projeto do Software 30 É difícil de modificar Software Mal Projetado É difícil de entender onde as mudanças são necessárias Aumenta-se a probabilidade de erros ao se modificar
  31. 31. Projeto do Software 31 Falta de recursos (tempo, dinheiro, etc.) Motivos? Falta de pessoal especializado Assunto complexo
  32. 32. Projeto do Software 32 Atualizar um sistema para melhorar a sua estrutura e legibilidade, sem alterar o seu comportamento externo. Refatorar
  33. 33. Projeto do Software 33 Para fazer com que o Software seja fácil de entender e modificar Por que utilizar? Para manter o Software saudável ao acrescentar ou alterar funcionalidades Para eliminar duplicidade de funcionalidade Para ajudar a encontrar bugs Para ajudar a desenvolver mais rápido
  34. 34. Projeto do Software 34 Código duplicado Evitando Método longo Classe grande Lista de parâmetros longa Má indentação
  35. 35. Projeto do Software 35 Nomes significativos, que fazem sentido: • confirmarSaldoCCClientePJInternet • confirmarSaldoCCClientePFInternet Bons Vícios Funções tem de ser pequenas, com poucos parâmetros e fazer uma coisa só Comentários em excesso e que dizem o óbvio não são legais Formatação do código-fonte. Usar TABs são legais
  36. 36. Projeto do Software 36 Arquitetura
  37. 37. Projeto do Software 37 Camadas Apresentação Aplicação Dados
  38. 38. Aplicação Model Browser Projeto do Software 38 Camadas Apresentação Dados Controller View Servidor de Dados Servidor Aplicação Frameworks Transversais BD
  39. 39. Projeto do Software 39 MVC – Conceito Model: representa a lógica e os dados de domínio da aplicação ou as regras nas quais os objetos de negócio deverão ser acionados. Provê a interface com o Controller para o acesso das regras de negócio. View: é utilizado para prover e formatar o conteúdo fornecido pelo Model. Deve acessar os dados de domínio e definir como esses dados serão apresentados na interface. Deve ainda prover ao Controller as interações com o usuário (um clique de botão, um evento de alteração de estado de algum controle da interface e etc.). Controller: é responsável por definir e controlar o comportamento da aplicação, como qual interface deve ser apresentada e como o fluxo de informações da aplicação deverá ser disponibilizado para o usuário.
  40. 40. Projeto do Software 40 MVC – Tecnologia Objeto MVC Tecnologia J2EE Model • EJB (Enterprise Java Beans) • Objetos Java View • JSP • Parte dos Frameworks para desenvolvimento Web, como o JSF Controller • Java Servlets • Struts • Alguns módulos de estruturas de Frameworks Web, como o JSF
  41. 41. Projeto do Software 41 Estruturação
  42. 42. Projeto do Software 42 Estruturação* * IEEE, 2004 Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesFundamentos • Projeto Arquitetural: descreve como o software é decomposto e organizado em componentes; • Projeto Detalhado: descreve o comportamento desses componentes;
  43. 43. Projeto do Software 43 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesFundamentos Técnicas Importantes • Acoplamento e Coesão: força do relacionamento entre módulos e como os elementos que compõem um módulo se relacionam; • Decomposição e modularização: dividir e organizar o software em diferentes funcionalidades; • Encapsulamento: agrupar e empacotar elementos tornando os detalhes internos inacessíveis;
  44. 44. Projeto do Software 44 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesFundamentos Técnicas Importantes • Separação – Interface/Implementação: envolve a definição de um componente para especificar uma interface pública, separado dos detalhes de como esse componente é realizado; • Suficiência e Completude: significa garantir que os componentes do software capturam todas as características para as quais foi desenhado e nada mais;
  45. 45. Projeto do Software 45 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Características Chaves Propriedades que afetam o desempenho e a semântica dos componentes • Concorrência: define como decompor o software em processos, tarefas e passos de forma a se manter a eficiência, atomicidade e sincronismo; • Controle e Execução de Eventos: define como organizar dados, fluxos de controle, e tratamento de eventos reativos e temporais utilizando mecanismos disponíveis;
  46. 46. Projeto do Software 46 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Características Chaves • Distribuição de Componentes: define como distribuir o software ao longo do hardware, como os componentes vão se comunicar e como o middleware pode ser utilizado para tratar ambientes heterogêneos; • Tratamento de erros: define como tratar erros, tolerar falhas e conviver com condições especiais;
  47. 47. Projeto do Software 47 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Características Chaves • Interação e Apresentação: define como organizar as interações com usuários e como apresentar as informações (utilizando por exemplo, o Model-View-Controller); • Persistência de dados: define, por exemplo, por quanto tempo os dados devem ser mantidos e tratados;
  48. 48. Projeto do Software 48 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesArquitetura Descreve os subsistemas e componentes de um software e a relação entre eles • Estrutura Arquitetural: pode ser dividida em visões, as quais apresentam um aspecto específico da arquitetura (visão lógica – satisfação dos requisitos funcionais; visão de processos – trata das características de concorrência; visão física – trata das características de distribuição; visão de implementação – como o software é organizado por unidades de implementação);
  49. 49. Projeto do Software 49 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesArquitetura • Design Patterns (padrões de projeto): representam uma solução conhecida para um problema conhecido em um dado contexto. Visualiza um nível mais detalhado da arquitetura. • Padrões de criação: builder, factory, prototype, singleton; • Padrões estruturais: adapter, bridge, composite, decorator, façade; • Padrões comportamentais: command, iterator, mediator, memento, observer;
  50. 50. Projeto do Software 50 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesQualidade
  51. 51. Projeto do Software 51 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesQualidade Análise da Qualidade • Revisões formais dos artefatos de projetos • Provas de conceito da arquitetura (ou componentes) • Análise estática formal (fault-tree analysis, automated cross-checking, rastreabilidade dos requisitos) • Simulação ou prototipagem (desempenho, exeqüibilidade, ...)
  52. 52. Projeto do Software 52 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade NotaçõesQualidade Métricas Apoiam as estimativas de vários aspectos do software, como tamanho, estrutura ou qualidade. • Medidas orientadas a funções: são obtidas através da decomposição funcional (diagrama hierárquico) • Medidas orientadas a objetos: baseadas normalmente no diagrama de classes e em cada classe especificamente
  53. 53. Projeto do Software 53 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Descrição da Estrutura (visão estática) • Diagrama de classes • Diagrama de componentes • CRCs (class responsability collaborator cards) • Diagramas de implantação • Diagramas de entidades e relacionamentos • Linguagens para descrição de interfaces Notações
  54. 54. Projeto do Software 54 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações Descrição do Comportamento (visão dinâmica) • Diagrama de atividades • Diagrama de colaboração • Diagrama de fluxo de dados • Tabelas de decisão • Fluxogramas • Diagrama de sequência • Diagrama de estados Notações
  55. 55. Projeto do Software 55 Estruturação Projeto de Software Fundamentos Estratégias e Métodos Características Chaves Arquitetura Qualidade Notações • Projeto Orientado a Função: geralmente utilizado para abordagem estruturada, gera produtos como diagrama de fluxo de dados e descrição de processos associados. •Projeto Orientado a Objetos: utiliza a filosofia de manter num mesmo objeto, a estrutura e o comportamento, maneira pela qual a realidade se manifesta. Gera inúmeros produtos visuais, como diagrama de classes, sequência, colaboração, pacotes, etc. • Projeto Ágil: entregas rápidas, resumidas a pequenas iterações. Pouca documentação, resumidas às especificadas em código. Métodos
  56. 56. Sugestões Bibliográficas • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. • Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 1 ed. Estados Unidos da América: Prentice Hall, 2004. • Fowler, Martin. Refactoring: Improving the Design of Existing Code. Massachusetts: Addison Wesley, 2006. • Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure. ISBN 1890367125. • Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures. ISBN 1880410818. • Eric S. Norman, Shelly A. Brotherton, Robert T. Fried Estruturas Analíticas de Projeto . ISBN 9788521205043. • Meyer, B. Object-Oriented Software Construction. New Jersey: Prentice Hall, 1988. • Pressman, R. S. Engenharia de Software. 5. ed. São Paulo: Makron Books, 2002. • Kosanski, N., Woods, E.. Software Systems Architecture: working with stakeholders using view points and perspectives. New Jersey: Addison-Wesley, 2005. Projeto do Software 56
  57. 57. Projeto do Software Wagner Zaparoli wzaparoli@gmail.com

×