Professor Mário Dantas

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.