1 / 85

Professor Mário Dantas

Engenharia de Software. Set/2010. Professor Mário Dantas. Aula 04- Agenda. Princípios e conceitos de análise e projeto;. MODELAGEM DE ANÁLISE.

mimis
Download Presentation

Professor Mário Dantas

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Engenharia de Software Set/2010 Professor MárioDantas

  2. Aula 04- Agenda • Princípios e conceitos de análise e projeto;

  3. MODELAGEM DE ANÁLISE Durante as últimas décadas, um grande número de métodos de modelagem de análise foi desenvolvido. Pesquisadores identificaram problemas de análise e suas causas, e desenvolveram uma variedade de notações de modelagem e conjuntos de heuríticas correspondentes para resolve-los. Cada método de análise tem um ponto de vista singular. No entanto, todos os métodos de análise estão relacionados a um conjunto de princípios operacionais (PRESSMAN, 2006).

  4. O que é? • A modelagem da análise usa uma combinação de formas textuais e diagramáticas para mostrar os requisitos de dados, função e comportamento, de modo que seja relativamente fácil de entender e revisar o sistema.

  5. Quem faz? • Um engenheiro de software (ou analista) constrói um modelo usando requisitos extraídos do cliente.

  6. Por que é importante? • Por representar os requisitos de várias maneiras, aumentando a chance de serem encontrados erros, inconsistências e que omissões sejam descobertas.

  7. Qual é o produto do trabalho? • Uma variedade de formas diagramáticas podem ser escolhidas para o modelo de análise. Cada uma fornece uma visão de um ou mais elementos do modelo.

  8. Como tenho certeza de que fiz corretamente? • Revisados quanto à correção, completeza e consistência. • Devem refletir as necessidades dos interessados e estabelecer um fundamento com base na qual o projeto pode ser conduzido.

  9. Princípios da Modelagem de Análise • O domínio da informação de um problema deve ser representado e entendido; • As funções a serem desenvolvidas pelo software devem ser definidas; • O comportamento do software (como conseqüência de eventos externos) precisa ser representado. • O modelos que mostram informações, funções e comportamento devem ser particionados de um modo que revele detalhes em forma de camadas (ou hierarquias); • A tarefa de análise deve ir da informação mais essencial até os detalhes de implementação.

  10. Conjunto genérico de Tarefas para modelagem de Análise • Revisar os requisitos de negócio, as características/necessidades dos usuários, as saídas visíveis ao usuário, as restrições do negócio e outros requisitos técnicos que foram determinados durante a atividade de comunicação com o cliente e o planejamento.

  11. Conjunto genérico de Tarefas para modelagem de Análise • Expandir e refinar os cenários do usuário. • Definir todos os atores; • Representar como os atores interagem com o software. • Extrair funções e características dos cenários de usuário. • Revisar o cenário do usuário quanto à completude e precisão.

  12. Conjunto genérico de Tarefas para modelagem de Análise • Modelar o domínio da informação. • Representar todos os principais objetos de informação; • Definir atributos para cada objeto de informação; • Representar os relacionamentos entre os objetos de informação.

  13. Conjunto genérico de Tarefas para modelagem de Análise • Modelar o domínio funcional. • Mostrar como as funções modificam os objetos de dados; • Refinar funções para fornecer detalhes de elaboração; • Escrever um narrativa de processamento que descreva cada função e subfunção; • Revisar os modelos funcionais.

  14. Conjunto genérico de Tarefas para modelagem de Análise • Modelar o domínio comportamental. • Identificar os eventos externos que causam mudanças comportamentais no sistema; • Identificar os estados que representam cada modo de comportamento observável externamente; • Mostrar como o evento faz o sistema se mover de um estado para outro; • Revisar os modelos comportamentais.

  15. Conjunto genérico de Tarefas para modelagem de Análise • Analisar e modelar a interface do usuário. • Conduzir tarefa de análise; • Criar protótipos de imagem de tela; • Revisar todo os modelos quanto à completude, consistência e omissões.

  16. O modelo de análise deve: • Descrever o que o cliente exige • Estabelecer a base para a criação de um projeto de software • Definir um conjunto de requisitos que possam ser validados quando o software for construído

  17. Regras práticas de Análise • O nível de abstração deve ser relativamente alto. • Adie a consideração de modelos de infra-estrutura e outros não funcionais até o projeto. • Minimize o acoplamento ao longo de todo o sistema • Certifique-se de que o modelo de análise tem valor para todos os interessados • Mantenha o modelo tão simples quanto puder

  18. Análise de Domínio • É a identificação, análise e especificação dos requisitos comuns de um domínio de aplicação específico. • Sua meta é encontrar ou criar classes de análise e/ou as funções e características que são amplamente aplicáveis, de modo que possam ser reutilizadas.

  19. Abordagens de Modelagem de Análise • Elementos baseados em cenários • Elementos baseados em classes • Elementos comportamentais • Elementos orientados a fluxos

  20. Atividade 002 • 4 grupos para apresentar as abordagens de modelagem de análise • Data: 15/09/2010

  21. Projeto de Software

  22. Objetivos • Conhecer os conceitos relacionados ao projeto de software, bem como sua aplicação; • Saber quais decisões devem ser tomadas sobre a arquitetura de sistema durante o processo de projeto de arquitetura.

  23. Projeto de Software • Engloba um conjunto de princípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade. • Seu objetivo é produzir um modelo ou representação que exiba firmeza, comodidade e prazer, ou seja, que satisfaça aos requisitos do sistema.

  24. Projeto de Software • O que é? • O projeto cria uma representação ou modelo de software, mas diferente do modelo de análise (que enfoca a descrição dos dados, função e comportamento requeridos). • O modelo de projeto fornece detalhe sobre as estruturas de dados, arquitetura, interfaces e componentes do software necessários para implementar o sistema.

  25. Projeto de Software • Quem faz? • Engenheiros de software conduzem cada uma das tarefas de projeto. • Por que é importante? • Permite ao engenheiro de software modelar o sistema ou produto que deve ser construído. Esse modelo pode ser avaliado quanto à qualidade e aperfeiçoado antes que o código seja gerado, testes sejam conduzidos e usuários finais fiquem envolvidos em grande número.

  26. Atividades de projeto

  27. Atividades de projeto • Projeto ƒda Arquitetura do Software: • visa a definir os grandes componentes estruturais do software e seus relacionamentos. • ƒProjeto de Dados: • tem por objetivo projetar a estrutura de armazenamento de dados necessária para implementar o software. • Projeto de Interfaces: • descreve como o software deverá se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces externas) e com pessoas que o utilizam (interface com o usuário). • Projeto Procedimental Detalhado: • tem por objetivo refinar e detalhar a descrição procedimental dos componentes estruturais da arquitetura do software.

  28. Princípios da Modelagem de Projeto • O projeto deve estar relacionado ao modelo de análise; • Sempre considere a arquitetura do sistema a ser construído; • O projeto dos dados é tão importante quanto o projeto de funções de processamento; • As interfaces (tanto externas quanto internas) precisam ser projetadas como cuidado. • O projeto de interface do usuário deve estar sintonizado com as necessidades do usuário final. No entanto, em cada caso, ele deve enfatizar a facilidade de uso.

  29. Princípios da Modelagem de Projeto • O projeto a nível de componente deve ser funcionalmente independente; • Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente externo. • Representações de projeto (modelos) devem ser facilmente compreensíveis. • O projeto de ser desenvolvido iterativamente. A cada iteração, o projetista deve lutar por maior simplicidade.

  30. Conjunto genérico de tarefas para o Projeto • Usando o modelo de análise, selecionar um estilo (padrão) arquitetural que seja apropriado para o software.

  31. Conjunto genérico de tarefas para o Projeto • Particionar o modelo de análise em subsistemas de projeto e alocar esses subsistemas na arquitetura. • Certifica-se de que cada subsistema seja funcionalmente coesivo. • Projetar as interfaces dos subsistemas. • Alocar classes ou funções de análise a cada subsistema. • Usando o modelo de domínio de informação, projetar as estruturas de dados adequadas.

  32. Conjunto genérico de tarefas para o Projeto • Projetar as interfaces do usuário. • Rever os resultados das análises de tarefas. • Especificar a seqüência de ações com base nos cenário dos usuários. • Criar o modelo comportamental da interface. • Definir objetos de interface e mecanismos de controle. • Rever o projeto de interface e revisar conforme a necessidade.

  33. Conjunto genérico de tarefas para o Projeto • Conduzir o projeto em nível de componentes. • Especificar todos os algoritmos em um nível de abstração relativamente baixo. • Refinar a interface de cada componente. • Definir a estrutura de dados em nível de componente. • Rever o projeto em nível de componente • Desenvolver um modelo de implantação.

  34. Projeto de Software • Qual é o produto do trabalho? • Um modelo de projeto que inclui representações de arquitetura, interface, componente e implantação. • Como tenho certeza de que fiz corretamente? • O modelo de projeto é avaliado pela equipe de software em um esforço para determinar se contém erros, inconsistências ou omissões; se existem alternativas melhores e se o modelo pode ser implementado dentro das restrições, cronograma e custo que foram estabelecidos.

  35. Projeto de Software Objetivo: produzir um modelo que satisfaça ao requisitos. Evolução contínua à medida que a análise se aperfeiçoa e entendimento amplia.

  36. Projeto de Software Projeto serve de base para todas as etapas da Engenharia de Software • Projeto é necessário? Sem projeto, como modificar, testar e avaliar a qualidade? • Permite avaliar a qualidade antes de implementar

  37. Conceitos de Projeto • Abstração: • visão de alto nível dos aspectos fundamentais do sistema, de maneira que obtenha-se uma ocultação dos detalhes. • Arquitetura: • organização dos componentes de programas, suas interações e as estruturas usadas pelos componentes. • Padrões: • descreve uma estrutura para resolver um determinado problema.

  38. Módulos são integrados com o objetivo de atender a um requisito “Dividir e conquistar” Modularização

  39. Por que modularizar? • Planejar mais fácil • Manutenção • Testes e depuração • Ocultação de Informações • Módulos devem ser especificados e projetados de tal modo que informações desnecessárias sejam inacessíveis • Apenas o necessário é fornecido para a realização de funções • Abstração + ocultação (erros não são propagados nas modificações)

  40. Independência Funcional Modularidade + abstração + ocultação = Independência Funcional • “Finalidade única” e menos interação • Interfaces simplificadas • Manutenção mais fácil • Propagação de erros minimizada • Reutilização • Dois critérios (qualitativos) para avaliação • COESÃO: robustez funcional de um módulo (módulo realiza uma única tarefa) • ACOPLAMENTO: indicação da interdependência entre módulos

  41. Refinamento e Refatoração • Refinamento • Processo de elaboração (alto nível -> mais detalhes) • Refinamentos sucessivos • (Abstração + refinamentos): conceitos complementares • Refatoração • Reorganizar para simplificar o projeto sem alterar as funções e os comportamentos. • O que pode ser refatorado? • Redundância, elementos não utilizados, algoritmos ineficientes, etc

  42. ExtractMethodExemplo Sem Variáveis Locais voidimprimeDivida () { Enumerate e = _pedidos.elementos (); double divida = 0.0; // imprime cabeçalho System.out.println (“***************************”); System.out.println (“*** Dívidas do Cliente ****”); System.out.println (“***************************”); // calcula dívidas while (e.temMaisElementos ()){ Pedido cada = (Pedido) e.proximoElemento (); divida += cada.valor (); } // imprime detalhes System.out.println (“nome: ” + _nome); System.out.println (“divida total: ” + divida); }

  43. ExtractMethodExemplo Com Variáveis Locais voidimprimeDivida () { Enumerate e = _pedidos.elementos (); double divida = 0.0; imprimeCabecalho (); // calcula dívidas while (e.temMaisElementos ()){ Pedido cada = (Pedido) e.proximoElemento (); divida += cada.valor (); } //imprime detalhes System.out.println(“nome: ” + _nome); System.out.println(“divida total: ” + divida); } voidimprimeCabecalho () { System.out.println (“***************************”); System.out.println (“*** Dívidas do Cliente ****”); System.out.println (“***************************”); }

  44. ExtractMethodExemplo COM Variáveis Locais voidimprimeDivida () { Enumerate e = _pedidos.elementos (); double divida = 0.0; imprimeCabecalho (); // calcula dívidas while (e.temMaisElementos ()){ Pedido cada = (Pedido) e.proximoElemento (); divida += cada.valor (); } imprimeDetalhes (divida); } voidimprimeDetalhes (double divida) { System.out.println(“nome: ” + _nome); System.out.println(“divida total: ” + divida); }

  45. ExtractMethodcomatribuição voidimprimeDivida () { imprimeCabecalho (); double divida = calculaDivida (); imprimeDetalhes (divida); } doublecalculaDivida () { Enumerate e = _pedidos.elementos (); double divida = 0.0; while (e.temMaisElementos ()){ Pedido cada = (Pedido) e.proximoElemento (); divida += cada.valor (); } return divida; }

  46. ExtractMethoddepois de compilar e testar voidimprimeDivida () { imprimeCabecalho (); double divida = calculaDivida (); imprimeDetalhes (divida); } doublecalculaDivida () { Enumerate e = _pedidos.elementos (); doubleresultado = 0.0; while (e.temMaisElementos ()){ Pedido cada = (Pedido) e.proximoElemento (); resultado += cada.valor (); } returnresultado; }

  47. Projeto de Arquitetura

  48. Objetivos • Introduzir projeto arquitetural e discutir sua importância. • ƒExplicar porque vários modelos são necessários para documentar uma arquitetura de software. • ƒ Descrever os tipos de modelos arquitetural que podem ser usados.

  49. Arquitetura do Software • O processo inicial de projeto, que consiste em identificar os subsistemas é chamado de projeto de arquitetura. • A saída desse processo de projeto é uma descrição da arquitetura do software.

  50. Projeto de Arquitetura • Sistemas grandes são sempre decompostos em subsistemas que fornecem algum conjunto de serviços relacionados. • O projeto de arquitetura é o primeiro estágio no processo de projeto e representa uma ligação crítica entre os processos de engenharia de projeto e de requisitos. • O processo de projeto de arquitetura envolve o estabelecimento de um framework básico que identifica os principais componentes de um sistema e as comunicações entre eles.

More Related