Fundamentos da Engenharia de Software

1.434 visualizações

Publicada em

Coletânea dos principais fundamentos da Engenharia de Software

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.434
No SlideShare
0
A partir de incorporações
0
Número de incorporações
342
Ações
Compartilhamentos
0
Downloads
93
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Fundamentos da Engenharia de Software

  1. 1. https://www.facebook.com/alvarofpinheiroaulas/ br.linkedin.com/in/alvarofpinheiro/ Engenharia de Software Fundamentos http://www.alvarofpinheiro.eti.br
  2. 2. Projeto www.alvarofpinheiro.eti.br
  3. 3. www.alvarofpinheiro.eti.br
  4. 4. Projetos Origem dos erros nos softwares Análise 56% Programação 7% Desenho 27% Outros 10% www.alvarofpinheiro.eti.br
  5. 5. Projetos Custo de correção dos erros Custo Incremento de 100 a 1000 vezes Etapas do ciclo de desenvolvimento www.alvarofpinheiro.eti.br
  6. 6. Projetos Incremento do custo dos erros Captura de requisitos Análise e Desenho Codificação Teste Unitário Prova de Aceitação Manutenção 1 2,5 5 10 25 100 Boehm, 1988 www.alvarofpinheiro.eti.br
  7. 7. Fatores de êxito dos projetos • Em 1998 o Standish Group levantou 365 companhias e 8000 projetos e apresentou os resultados em seu informe de 1999 • Melhora no êxito dos projetos: 16% en 1994 vs. 26% em 1998 além de redução de custos e tempos • Causas: participação dos usuários, suporte executivo, claro estabelecimento dos objetivos do negócio, administração de projetos, entregas permanentes, requisitos firmes, menor tamanho e duração do projeto, etc. www.alvarofpinheiro.eti.br
  8. 8. Êxito do projeto segundo seu tamanho 60 50 40 30 20 10 0 até $750m $750m a $1.5M $1.5M a $3M $3M a $6M $6M a $10M + de $10M Porcentagem de êxito (%) Standish Group, 1999 Tamanho do projeto ($) www.alvarofpinheiro.eti.br
  9. 9. As seis melhores práticas para desenvolver Projetos de SW • Desenvolvimento iterativo • Administração de requisitos • Uso de arquitetura de componentes • Modelo visual (UML) • Verificação contínua da qualidade • Administração de Mudanças www.alvarofpinheiro.eti.br
  10. 10. www.alvarofpinheiro.eti.br
  11. 11. Análise www.alvarofpinheiro.eti.br
  12. 12. www.alvarofpinheiro.eti.br
  13. 13. www.alvarofpinheiro.eti.br
  14. 14. www.alvarofpinheiro.eti.br
  15. 15. www.alvarofpinheiro.eti.br
  16. 16. www.alvarofpinheiro.eti.br
  17. 17. www.alvarofpinheiro.eti.br
  18. 18. www.alvarofpinheiro.eti.br
  19. 19. www.alvarofpinheiro.eti.br
  20. 20. www.alvarofpinheiro.eti.br
  21. 21. www.alvarofpinheiro.eti.br
  22. 22. www.alvarofpinheiro.eti.br
  23. 23. www.alvarofpinheiro.eti.br
  24. 24. www.alvarofpinheiro.eti.br
  25. 25. www.alvarofpinheiro.eti.br
  26. 26. www.alvarofpinheiro.eti.br
  27. 27. www.alvarofpinheiro.eti.br
  28. 28. www.alvarofpinheiro.eti.br
  29. 29. www.alvarofpinheiro.eti.br
  30. 30. www.alvarofpinheiro.eti.br
  31. 31. www.alvarofpinheiro.eti.br
  32. 32. www.alvarofpinheiro.eti.br
  33. 33. www.alvarofpinheiro.eti.br
  34. 34. www.alvarofpinheiro.eti.br
  35. 35. www.alvarofpinheiro.eti.br
  36. 36. www.alvarofpinheiro.eti.br
  37. 37. www.alvarofpinheiro.eti.br
  38. 38. Engenharia de Requisitos www.alvarofpinheiro.eti.br
  39. 39. www.alvarofpinheiro.eti.br
  40. 40. www.alvarofpinheiro.eti.br
  41. 41. www.alvarofpinheiro.eti.br
  42. 42. www.alvarofpinheiro.eti.br
  43. 43. www.alvarofpinheiro.eti.br
  44. 44. www.alvarofpinheiro.eti.br
  45. 45. www.alvarofpinheiro.eti.br
  46. 46. www.alvarofpinheiro.eti.br
  47. 47. www.alvarofpinheiro.eti.br
  48. 48. www.alvarofpinheiro.eti.br
  49. 49. www.alvarofpinheiro.eti.br
  50. 50. www.alvarofpinheiro.eti.br
  51. 51. www.alvarofpinheiro.eti.br
  52. 52. www.alvarofpinheiro.eti.br
  53. 53. www.alvarofpinheiro.eti.br
  54. 54. www.alvarofpinheiro.eti.br
  55. 55. www.alvarofpinheiro.eti.br
  56. 56. www.alvarofpinheiro.eti.br
  57. 57. www.alvarofpinheiro.eti.br
  58. 58. www.alvarofpinheiro.eti.br
  59. 59. www.alvarofpinheiro.eti.br
  60. 60. www.alvarofpinheiro.eti.br
  61. 61. www.alvarofpinheiro.eti.br
  62. 62. www.alvarofpinheiro.eti.br
  63. 63. www.alvarofpinheiro.eti.br
  64. 64. www.alvarofpinheiro.eti.br
  65. 65. www.alvarofpinheiro.eti.br
  66. 66. www.alvarofpinheiro.eti.br
  67. 67. www.alvarofpinheiro.eti.br
  68. 68. www.alvarofpinheiro.eti.br
  69. 69. www.alvarofpinheiro.eti.br
  70. 70. www.alvarofpinheiro.eti.br
  71. 71. www.alvarofpinheiro.eti.br
  72. 72. www.alvarofpinheiro.eti.br
  73. 73. www.alvarofpinheiro.eti.br
  74. 74. www.alvarofpinheiro.eti.br
  75. 75. www.alvarofpinheiro.eti.br
  76. 76. www.alvarofpinheiro.eti.br
  77. 77. www.alvarofpinheiro.eti.br
  78. 78. Metodologias Modelos Processos Técnicas www.alvarofpinheiro.eti.br
  79. 79. www.alvarofpinheiro.eti.br
  80. 80. Engenharia de Software Metodologias O termo Engenharia de Software surgiu em uma conferência no final da década de 60. A proposta inicial era a sistematização do desenvolvimento de software, que deveria ser tratado com engenharia e não como arte. www.alvarofpinheiro.eti.br
  81. 81. Engenharia de Software Metodologias Desta forma, a idéia foi propor a utilização de métodos, ferramentas e técnicas para a produção de software confiável, correto e entregue respeitando os prazos e custos definidos. www.alvarofpinheiro.eti.br
  82. 82. Metodologias As metodologias tradicionais devem ser aplicadas apenas em situações em que os requisitos do software são estáveis e requisitos futuros são previsíveis. www.alvarofpinheiro.eti.br
  83. 83. Metodologias Dentre os fatores responsáveis por alterações nos requisitos estão a dinâmica das organizações, as alterações nas leis e as mudanças pedidas pelos stakeholders, que geralmente têm dificuldades em definir o escopo do futuro software. www.alvarofpinheiro.eti.br
  84. 84. Metodologias As metodologias ágeis incentivam a mudança nos requisitos, pois desta forma é possível realmente entregar ao cliente o produto que ele precisa. www.alvarofpinheiro.eti.br
  85. 85. Metodologias O termo “metodologias ágeis” tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os métodos Extreme Programming (XP), Scrum, DSDM, Crystal e outros, estabeleceram princípios comuns compartilhados por todos esses métodos. www.alvarofpinheiro.eti.br
  86. 86. Metodologias Ágeis Conceito Para ser realmente considerada ágil a metodologia deve aceitar as mudanças ao invés de tentar prever o futuro. O problema é como receber, avaliar e responder às mudanças. www.alvarofpinheiro.eti.br
  87. 87. Metodologias Ágeis Introdução Enquanto as metodologias ágeis variam em termos de práticas e ênfases, elas compartilham algumas características, como desenvolvimento iterativo e incremental, comunicação e redução de produtos intermediários, como documentação extensiva. www.alvarofpinheiro.eti.br
  88. 88. Metodologias Ágeis Introdução Desta forma existem maiores possibilidades de atender aos requisitos do cliente, que muitas vezes são mutáveis. www.alvarofpinheiro.eti.br
  89. 89. Metodologias Ágeis Modelos Dentre as várias metodologias ágeis existentes, as mais conhecidas são a eXtreme Programming e a Scrum. www.alvarofpinheiro.eti.br
  90. 90. Metodologias Ágeis X Metodologias Tradicionais Um exemplo de uma metodologia tradicional ou pesada é o modelo em Cascata, que é composto basicamente por atividades seqüenciais de levantamento de requisitos, análise, projeto, implementação, teste, implantação e manutenção. www.alvarofpinheiro.eti.br
  91. 91. Metodologias Manifesto Ágil O resultado foi a criação da Aliança Ágil e o estabelecimento do “Manifesto Ágil” (Agile Manifesto). www.alvarofpinheiro.eti.br
  92. 92. Metodologias Manifesto Ágil Conceitos Indivíduos e interações ao invés de processos e ferramentas. Software executável ao invés de documentação. Colaboração do cliente ao invés de negociação de contratos. Respostas rápidas a mudanças ao invés de seguir planos. www.alvarofpinheiro.eti.br
  93. 93. Metodologias É uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. www.alvarofpinheiro.eti.br
  94. 94. Modelo Cascata O modelo em Cascata dominou a forma de desenvolvimento de software até o início da década de 90, apesar das advertências dos pesquisadores da área e dos desenvolvedores, que identificaram os problemas gerados ao se adotar esta visão seqüencial de tarefas. www.alvarofpinheiro.eti.br
  95. 95. Modelo Cascata O pesquisador, Tom Gilb, desencoraja o uso do modelo em Cascata para grandes softwares, estimulando o desenvolvimento incremental como um modelo que apresenta menores riscos e maiores possibilidades de sucesso. www.alvarofpinheiro.eti.br
  96. 96. Processo www.alvarofpinheiro.eti.br
  97. 97. O que é um processo • Um processo define quem faz o que, quando e como para se alcançar um objetivo www.alvarofpinheiro.eti.br
  98. 98. Processo • Servir de guia para todos • Especificar quais artefatos devem ser gerados e quando devem ser gerados. • Direcionar as Atividades individuais e de equipes. • Oferecer critérios para o gerenciamento ISO9000-3 www.alvarofpinheiro.eti.br
  99. 99. Processo de desenvolvimento de um software • Elicitação de requisitos • Definição da arquitetura • Análise • Projeto • Implementação • Testes • Implantação • Manutenção www.alvarofpinheiro.eti.br
  100. 100. Controle dos Processos • Arquitetura • CMMI • Fases • Software Process Automation • Fabrica de Software www.alvarofpinheiro.eti.br
  101. 101. Metodologias Tradicionais www.alvarofpinheiro.eti.br
  102. 102. Rational Unified Process (RUP) www.alvarofpinheiro.eti.br
  103. 103. www.alvarofpinheiro.eti.br
  104. 104. RUP RUP é um framework de processo centrado na arquitetura, baseado em UML, dirigido por casos de uso e como tal, precisa ser instanciado de acordo com variáveis de tamanho, complexidade e domínio do sistema, de acordo com a organização com seus níveis de processos e experiências e capacidade das pessoas www.alvarofpinheiro.eti.br
  105. 105. www.alvarofpinheiro.eti.br
  106. 106. www.alvarofpinheiro.eti.br
  107. 107. www.alvarofpinheiro.eti.br
  108. 108. www.alvarofpinheiro.eti.br
  109. 109. www.alvarofpinheiro.eti.br
  110. 110. www.alvarofpinheiro.eti.br
  111. 111. www.alvarofpinheiro.eti.br
  112. 112. www.alvarofpinheiro.eti.br
  113. 113. www.alvarofpinheiro.eti.br
  114. 114. www.alvarofpinheiro.eti.br
  115. 115. www.alvarofpinheiro.eti.br
  116. 116. www.alvarofpinheiro.eti.br
  117. 117. www.alvarofpinheiro.eti.br
  118. 118. www.alvarofpinheiro.eti.br
  119. 119. www.alvarofpinheiro.eti.br
  120. 120. www.alvarofpinheiro.eti.br
  121. 121. www.alvarofpinheiro.eti.br
  122. 122. www.alvarofpinheiro.eti.br
  123. 123. www.alvarofpinheiro.eti.br
  124. 124. www.alvarofpinheiro.eti.br
  125. 125. www.alvarofpinheiro.eti.br
  126. 126. www.alvarofpinheiro.eti.br
  127. 127. www.alvarofpinheiro.eti.br
  128. 128. www.alvarofpinheiro.eti.br
  129. 129. www.alvarofpinheiro.eti.br
  130. 130. www.alvarofpinheiro.eti.br
  131. 131. www.alvarofpinheiro.eti.br
  132. 132. www.alvarofpinheiro.eti.br
  133. 133. www.alvarofpinheiro.eti.br
  134. 134. www.alvarofpinheiro.eti.br
  135. 135. www.alvarofpinheiro.eti.br
  136. 136. www.alvarofpinheiro.eti.br
  137. 137. www.alvarofpinheiro.eti.br
  138. 138. www.alvarofpinheiro.eti.br
  139. 139. www.alvarofpinheiro.eti.br
  140. 140. www.alvarofpinheiro.eti.br
  141. 141. www.alvarofpinheiro.eti.br
  142. 142. www.alvarofpinheiro.eti.br
  143. 143. www.alvarofpinheiro.eti.br
  144. 144. www.alvarofpinheiro.eti.br
  145. 145. www.alvarofpinheiro.eti.br
  146. 146. www.alvarofpinheiro.eti.br
  147. 147. www.alvarofpinheiro.eti.br
  148. 148. www.alvarofpinheiro.eti.br
  149. 149. www.alvarofpinheiro.eti.br
  150. 150. www.alvarofpinheiro.eti.br
  151. 151. www.alvarofpinheiro.eti.br
  152. 152. www.alvarofpinheiro.eti.br
  153. 153. www.alvarofpinheiro.eti.br
  154. 154. www.alvarofpinheiro.eti.br
  155. 155. www.alvarofpinheiro.eti.br
  156. 156. www.alvarofpinheiro.eti.br
  157. 157. www.alvarofpinheiro.eti.br
  158. 158. www.alvarofpinheiro.eti.br
  159. 159. www.alvarofpinheiro.eti.br
  160. 160. www.alvarofpinheiro.eti.br
  161. 161. www.alvarofpinheiro.eti.br
  162. 162. www.alvarofpinheiro.eti.br
  163. 163. www.alvarofpinheiro.eti.br
  164. 164. www.alvarofpinheiro.eti.br
  165. 165. www.alvarofpinheiro.eti.br
  166. 166. www.alvarofpinheiro.eti.br
  167. 167. www.alvarofpinheiro.eti.br
  168. 168. www.alvarofpinheiro.eti.br
  169. 169. www.alvarofpinheiro.eti.br
  170. 170. www.alvarofpinheiro.eti.br
  171. 171. www.alvarofpinheiro.eti.br
  172. 172. www.alvarofpinheiro.eti.br
  173. 173. www.alvarofpinheiro.eti.br
  174. 174. www.alvarofpinheiro.eti.br
  175. 175. www.alvarofpinheiro.eti.br
  176. 176. www.alvarofpinheiro.eti.br
  177. 177. Metodologias Ágeis www.alvarofpinheiro.eti.br
  178. 178. Scrum www.alvarofpinheiro.eti.br
  179. 179. Scrum Fases • Planejamento • Sprints – Ciclos • Encerramento www.alvarofpinheiro.eti.br
  180. 180. Scrum Outra metodologia ágil que apresenta uma comunidade grande de usuários. www.alvarofpinheiro.eti.br
  181. 181. Scrum Objetivo Seu objetivo é fornecer um processo conveniente para projeto e desenvolvimento orientado a objeto. www.alvarofpinheiro.eti.br
  182. 182. Scrum Outros Objetivos  Garantir maior flexibilidade e habilidade para tratamento de sistemas complexos e simples;  Produzir um sistema susceptível a mudanças de requisitos iniciais e adicionais durante o projeto:  Requerimentos dos clientes;  Necessidades do negócio;  Pressão relativa ao tempo;  Competitividade do mercado;  Qualidade;  Recursos. www.alvarofpinheiro.eti.br
  183. 183. Scrum Abordagem A Scrum apresenta uma abordagem empírica que aplica algumas idéias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as idéias de flexibilidade, adaptabilidade e produtividade. www.alvarofpinheiro.eti.br
  184. 184. Scrum Abordagem O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança. www.alvarofpinheiro.eti.br
  185. 185. Scrum Idéia A idéia principal da Scrum é que o desenvolvimento de softwares envolve muitas variáveis técnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. www.alvarofpinheiro.eti.br
  186. 186. Scrum A metodologia é baseada em princípios semelhantes aos da XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas para promover visibilidade para o desenvolvimento. No entanto, as dimensões em Scrum diferem de XP. www.alvarofpinheiro.eti.br
  187. 187. Scrum A Scrum divide o desenvolvimento em iterações (sprints) de trinta dias. Equipes pequenas, de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (os requisitos, em outras palavras) definidas no início de cada sprint. A equipe é responsável pelo desenvolvimento desta funcionalidade. www.alvarofpinheiro.eti.br
  188. 188. Scrum Na Scrum existem reuniões de acompanhamento diárias. Nessas reuniões, que são preferencialmente de curta duração (aproximadamente quinze minutos), são discutidos pontos como o que foi feito desde a última reunião e o que precisa ser feito até a próxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) são identificados e resolvidos. www.alvarofpinheiro.eti.br
  189. 189. Scrum Introdução ORIGEM: ADM (Advanced Development Methods) + VMARK Software METODOLOGIA: Gerenciamento, manutenção e desenvolvimento de softwares: simples e pequenos grandes e complexos PROCESSO: Ágil Empírico Incremental BASE P/ SCRUM: Técnicas e tools OO www.alvarofpinheiro.eti.br
  190. 190. Scrum Características  Deliverable flexível;  Cronograma flexível;  Times de desenvolvimento pequenos (por volta de 6);  Revisões frequentes;  Colaboração;  Orientação a Objeto. www.alvarofpinheiro.eti.br
  191. 191. Scrum Fases Planejamento • Processo definido • Relativamente curta • Design da arquitetura do sistema • Estimativas de datas e custos • Criação do backlog – Participação de clientes e outros departamentos • Levantamento dos requisitos e atribuição de prioridades • Definição de equipes e seus líderes • Definição de pacotes a serem desenvolvidos Backlog www.alvarofpinheiro.eti.br
  192. 192. Scrum Fases Sprint • Processo Empírico • Cada time recebe uma parte do backlog para desenvolvimento – O backlog não sofrerá modificações durante o Sprint • Duração de 1 a 4 semanas • Sempre apresentam um executável ao final Fonte: Mountain Goat Software www.alvarofpinheiro.eti.br
  193. 193. Scrum Fases – Sprint Reuniões Diárias • Cerca de 15 minutos de duração • Gerenciada pelo líder de cada equipe • Todos respondem às perguntas: – O que você realizou desde a última reunião? – Quais problemas você enfrentou? – Em que você trabalhará até a próxima reunião? • Benefícios: – Maior integração entre os membros da equipe – Rápida solução de problemas • Promovem o compartilhamento de conhecimento – Progresso medido continuamente • Minimização de riscos www.alvarofpinheiro.eti.br
  194. 194. Scrum Fases – Sprint Revisão • Deve obedecer à data de entrega – Permitida a diminuição de funcionalidades • Apresentação do produto à clientes e/ou diretores de marketing – Sugestões de mudanças são incorporadas ao backlog • Produto pode até ser lançado no mercado • Benefícios: – Apresentar resultados concretos ao cliente – Integrar e testar uma boa parte do software – Motivação da equipe www.alvarofpinheiro.eti.br
  195. 195. Scrum Fases Encerramento • Iniciada quando todos os aspectos são satisfatórios (tempo, competitividade, requisitos, qualidade, custo) • Atividades: – Testes de integração – Testes de sistema – Documentação do usuário – Preparação de material de treinamento – Preparação de material de marketing www.alvarofpinheiro.eti.br
  196. 196. Qualidade, Gerenciamento e Testes  Passos e papéis bem definidos  Gerenciamento de riscos  Revisões frequentes / diárias  Definição de padrões  Realização de testes  Elaboração de documentação  Grupo QA Controles Backlog Release/Melhoria Mudanças Problemas Soluções Issues Scrum www.alvarofpinheiro.eti.br
  197. 197. Conclusões  Divisão de responsabilidades  papéis bem definidos  Processo ágil e flexível  inúmeras mudanças no decorrer do projeto  Foco em controle/gerenciamento  minimiza risco  maximiza qualidade  Times pequenos  Colaboração  Ausência de práticas de Engenharia de Software (técnicas e notações) e tools  Necessidade de associação com outras metodologias e tools (XP, GNATS)  Dificuldade na implementação de mudanças Scrum www.alvarofpinheiro.eti.br
  198. 198. XP – eXtreme Programming www.alvarofpinheiro.eti.br
  199. 199. www.alvarofpinheiro.eti.br
  200. 200. Introdução Não se pode comparar XP com UML, já que UML se presta apenas como linguagem de modelagem, não define processos e XP define processo e não modelagem. Conclusão, se você quiser pode usar UML com XP. www.alvarofpinheiro.eti.br
  201. 201. Introdução Entretanto, diferente dos processos tradicionais, em XP a modelagem tem duas utilidades: 1. O problema a ser tratado é complexo e precisa ser melhor entendido. 2. Uma parte do sistema ficou "estável" (sem muitas modificações), e pode ser documentada. www.alvarofpinheiro.eti.br
  202. 202. Metodologia XP – eXtreme Programming Dentre as principais diferenças da XP em relação às outras metodologias estão: · Feedback constante; · Abordagem incremental; · A comunicação entre as pessoas é encorajada. www.alvarofpinheiro.eti.br
  203. 203. www.alvarofpinheiro.eti.br
  204. 204. XP – eXtreme Programming Conceito Em XP a modelagem não deve ser usada para definir o design do sistema. Em XP assume-se que o sistema está em constante mudança, ou seja, seu design vai mudar, e sua modelagem vai estar furada. www.alvarofpinheiro.eti.br
  205. 205. XP – eXtreme Programming Teste Primeiro o Desenvolvimento Se quiser modelar para ter um melhor entendimento, sem problemas, mas tenha em mente que é uma modelagem que pode não servir assim que o sistema sofrer alterações, ao invés, XP prega que se use Test First Design (ou Test Driven Development, outro nome pra mesma coisa). www.alvarofpinheiro.eti.br
  206. 206. XP – eXtreme Programming Vantagem Qual a vantagem em usar XP em relação às metodologias tradicionais? XP é baseado em sistemas que sofrem constante mudança de requisitos, para esse tipo de sistema, a vantagem é poder mudar os requisitos sem o impacto no desenvolvimento caso fosse utilizada uma metodologia tradicional. www.alvarofpinheiro.eti.br
  207. 207. XP – eXtreme Programming Primeiro Projeto O primeiro projeto a usar XP foi o C3, da Chrysler. Após anos de fracasso utilizando metodologias tradicionais, com o uso da XP o projeto ficou pronto em pouco mais de um ano. www.alvarofpinheiro.eti.br
  208. 208. XP – eXtreme Programming Paradigma A maioria das regras da XP causa polêmica à primeira vista e muitas não fazem sentido se aplicadas isoladamente. www.alvarofpinheiro.eti.br
  209. 209. XP – eXtreme Programming Paradigma A XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas. www.alvarofpinheiro.eti.br
  210. 210. XP – eXtreme Programming Paradigma As regras, práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem. www.alvarofpinheiro.eti.br
  211. 211. XP – eXtreme Programming Regra: Comunicação A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação. A comunicação entre os desenvolvedores e o gerente do projeto também é encorajada. www.alvarofpinheiro.eti.br
  212. 212. XP – eXtreme Programming Regra: Simplicidade A simplicidade visa permitir a criação de código simples que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de classes e métodos. Outra idéia importante da simplicidade é procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis. www.alvarofpinheiro.eti.br
  213. 213. XP – eXtreme Programming Regra: Feedback A prática do feedback constante significa que o programador terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relação ao cliente, o feedback constante significa que ele terá freqüentemente uma parte do software totalmente funcional para avaliar. O cliente então constantemente sugere novas características e informações aos desenvolvedores. Eventuais erros e não conformidades são rapidamente identificados e corrigidos nas próximas versões. Desta forma, a tendência é que o produto final esteja de acordo com as expectativas reais do cliente. www.alvarofpinheiro.eti.br
  214. 214. XP – eXtreme Programming Regra: Coragem É necessário coragem para implantar os três valores anteriores. Por exemplo, não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento. A coragem também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar. Além disso, é preciso coragem para obter feedback constante do cliente. www.alvarofpinheiro.eti.br
  215. 215. XP – eXtreme Programming Práticas A XP baseia-se nas 12 práticas. www.alvarofpinheiro.eti.br
  216. 216. XP – eXtreme Programming Práticas · Planejamento · Entregas freqüentes · Metáfora · Projeto simples · Testes · Refatoração · Programação em pares · Propriedade coletiva · Integração contínua · 40 horas de trabalho semanal · Cliente presente · Código padrão www.alvarofpinheiro.eti.br
  217. 217. XP – eXtreme Programming Prática 1: Planejamento Consiste em decidir o que é necessário ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros. Além disso, a XP procura evitar os problemas de relacionamento entre a área de negócios (clientes) e a área de desenvolvimento. As duas áreas devem cooperar para o sucesso do projeto, e cada uma deve focar em partes específicas do projeto. Desta forma, enquanto a área de negócios deve decidir sobre o escopo, a composição das versões e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especificadas. www.alvarofpinheiro.eti.br
  218. 218. XP – eXtreme Programming Prática 2: Entregas Freqüêntes Visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo, melhora as avaliações e o feedback do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente. www.alvarofpinheiro.eti.br
  219. 219. XP – eXtreme Programming Prática 3: Metáfora São as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento do software. www.alvarofpinheiro.eti.br
  220. 220. XP – eXtreme Programming Prática 4: Projeto Simples O programa desenvolvido pelo método XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem. Esta forma de raciocínio se opõe ao “implemente para hoje e projete para amanhã”. www.alvarofpinheiro.eti.br
  221. 221. XP – eXtreme Programming Prática 5: Testes A XP focaliza a validação do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando primeiramente os testes. www.alvarofpinheiro.eti.br
  222. 222. XP – eXtreme Programming Prática 6: Refatoração Focaliza o aperfeiçoamento do projeto do software e está presente em todo o desenvolvimento. A refatoração deve ser feita apenas quando é necessário, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que é possível simplificar o módulo atual sem perder nenhuma funcionalidade. www.alvarofpinheiro.eti.br
  223. 223. XP – eXtreme Programming Prática 7: Programação em Pares A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. O desenvolvedor que está com o controle do teclado e do mouse implementa o código, enquanto o outro observa continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos e semânticos e pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser alterados continuamente. Uma grande vantagem da programação em dupla é a possibilidade dos desenvolvedores estarem continuamente aprendendo um com o outro. www.alvarofpinheiro.eti.br
  224. 224. XP – eXtreme Programming Prática 8: Propriedade Coletiva O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça a bateria de testes necessária. Isto é possível porque na XP todos são responsáveis pelo software inteiro. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada. www.alvarofpinheiro.eti.br
  225. 225. XP – eXtreme Programming Prática 9: Integração Contínua Interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham: a última equipe que integrou código novo ao software. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe. www.alvarofpinheiro.eti.br
  226. 226. XP – eXtreme Programming Prática 10: 40 hs de trabalho semanal A XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as pessoas. www.alvarofpinheiro.eti.br
  227. 227. XP – eXtreme Programming Prática 11: Cliente Presente É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento. www.alvarofpinheiro.eti.br
  228. 228. XP – eXtreme Programming Prática 12: Código Padrão Padronização na arquitetura do código, para que este possa ser compartilhado entre todos os programadores. www.alvarofpinheiro.eti.br
  229. 229. www.alvarofpinheiro.eti.br
  230. 230. www.alvarofpinheiro.eti.br
  231. 231. www.alvarofpinheiro.eti.br
  232. 232. www.alvarofpinheiro.eti.br
  233. 233. www.alvarofpinheiro.eti.br
  234. 234. www.alvarofpinheiro.eti.br
  235. 235. www.alvarofpinheiro.eti.br
  236. 236. www.alvarofpinheiro.eti.br
  237. 237. www.alvarofpinheiro.eti.br
  238. 238. Crystal Processo de Desenvolvimento de Software www.alvarofpinheiro.eti.br
  239. 239. • Crystal/Clear faz parte, na realidade, de um conjunto de metodologias criado por Cockburn. As premissas apresentadas para a existência deste conjunto são: www.alvarofpinheiro.eti.br
  240. 240. • Todo projeto tem necessidades, convenções e uma metodologia diferentes. • O funcionamento do projeto é influenciado por fatores humanos, e há melhora neste quando os indivíduos produzem melhor. • Comunicação melhor e lançamentos freqüentes reduzem a necessidade de construir produtos intermediários do processo www.alvarofpinheiro.eti.br
  241. 241. • Crystal/Clear é uma metodologia direcionada a projetos pequenos, com equipes de até 6 desenvolvedores. Assim como com SCRUM, os membros da equipe tem especialidades distintas. Existe uma forte ênfase na comunicação entre os membros do grupo. Existem outras metodologias Crystal para grupos maiores. www.alvarofpinheiro.eti.br
  242. 242. • Toda a especificação e projeto são feitos informalmente, utilizando quadros publicamente visíveis. Os requisitos são elaborados utilizando casos de uso, um conceito similar às estórias de usuário em XP, onde são enunciados os requisitos como tarefas e um processo para sua execução. www.alvarofpinheiro.eti.br
  243. 243. • As entregas das novas versões de software são feitos em incrementos regulares de um mês, e existem alguns subprodutos do processo que são responsabilidade de membros específicos do projeto. www.alvarofpinheiro.eti.br
  244. 244. • Grande parte da metodologia é pouco definida, e segundo o autor, isto é proposital; a idéia de Crystal/Clear é permitir que cada organização implemente as atividades que lhe parecem adequadas, fornecendo um mínimo de suporte útil do ponto de vista de comunicação e documentos www.alvarofpinheiro.eti.br
  245. 245. A família Crystal de Métodos • Criada por Alistair Cockburn • http://alistair.cockburn.us/crystal • Editor da série Agile Software Development da Addison-Wesley. www.alvarofpinheiro.eti.br
  246. 246. Feature Driven Development Desenvolvimento orientado a funcionalidades www.alvarofpinheiro.eti.br
  247. 247. FDD - Características  Método ágil e adaptativo;  Foco nas fases de desenho e construção  Interage com outras metodologias  Não exige nenhum processo específico de modelagem  Possui desenvolvimento iterativo  Enfatiza aspectos de qualidade durante o processo e inclui entregas freqüentes e tangíveis  Suporta desenvolvimento ágil com rápidas adaptações às mudanças de requisitos e necessidades do mercado www.alvarofpinheiro.eti.br
  248. 248. FDD - Processos  O FDD consiste de 5 processos principais: www.alvarofpinheiro.eti.br
  249. 249. FDD – Processos (Cont.)  Desenvolver um modelo compreensível (Develop an overall model)  Construir uma lista de funcionalidades (Build a features list)  Planejar por funcionalidade (Plan By Feature)  Projetar por funcionalidade (Design by feature)  Construir por funcionalidade (Build by feature) www.alvarofpinheiro.eti.br
  250. 250. FDD - Cargos e Responsabilidades  Principais  Gerente de projeto (Project Manager)  Arquiteto líder (Chief architect)  Gerente de desenvolvimento (Development Manager)  Programador líder (Chief programmer)  Proprietário de classe (Class owner)  Especialísta do domínio (Domain experts)  Gerente do domínio (Domain manager) www.alvarofpinheiro.eti.br
  251. 251. FDD - Cargos e Responsabilidades (Cont.)  De apoio  Gerente de versão (Release manager)  Guru de linguagem (Language lawyer/language guru)  Engenheiro de construção (Build engineer)  “Ferramenteiro” (Toolsmith)  Administrador de sistemas (System Administrator)  Adicionais  Testadores (Testers)  Instaladores (Deployers)  Escritores técnicos (Technical writes) www.alvarofpinheiro.eti.br
  252. 252. FDD - Boas Práticas  Modelagem de objetos de domínio (Domain Object Modeling)  Exploração e explicação do problema do domínio  Resulta em um arcabouço  Desenvolver por funcionalidade (Developing by feature)  Desenvolvimento e acompanhamento do progresso através de da lista de funcionalidades.  Proprietários de classes individuais (Individual class ownership)  Cada classe possui um único desenvolvedor responsável www.alvarofpinheiro.eti.br
  253. 253. FDD - Boas Práticas (Cont.)  Equipe de funcionalidades (Feature teams)  Formação de equipes pequenas e dinâmicas.  Inspeção (Inspection)  Uso dos melhores métodos conhecidos de detecção de erros.  Construções freqüentes (Regular Builds)  Garantir que existe um sistema sempre disponível e de-monstrável.  Administração de Configuração (Configuration Manager)  Habilita acompanhamento do histórico do código-fonte.. www.alvarofpinheiro.eti.br
  254. 254. Dynamic Systems Development Method (DSDM) Método dinâmico de desenvolvimento de sistemas www.alvarofpinheiro.eti.br
  255. 255. DSDM - Características  Progenitor do XP  Arcabouço para desenvolvimento rápido de aplicações (RAD)  Fixa tempo e recursos ajustando a quantia de funcio-nalidades  Pequenas equipes  Suporta mudanças nos requisitos durante o ciclo de vida www.alvarofpinheiro.eti.br
  256. 256. DSDM - Fases  O DSDM consiste de 5 fases: Feasibility Review Study www.alvarofpinheiro.eti.br
  257. 257. DSDM – Fases (Cont.) Estudo das possibilidades (Feasibility study) Estudo dos negócios (Business study) Iteração do modelo funcional (Functional model iteration) Iteração de projeto e construção (Design and build iteration) Implementação final (Final implementation) www.alvarofpinheiro.eti.br
  258. 258. DSDM - Cargos e Responsabilidades  Desenvolvedores (Developers)  Desenvolvedores Sêniores (Senior Developers)  Coordenador Técnico (Technical Coordinator  Usuário Embaixador (Ambassador User)  Usuário Consultor (Adviser User)  Visionário (Visionary)  Executivo responsável (Executive Sponsor)  Especialísta do domínio (Domain experts)  Gerente do domínio (Domain manager) www.alvarofpinheiro.eti.br
  259. 259. DSDM - Práticas  Usuário sempre envolvido  Equipe do DSDM autorizada a tomar decisões  Foco na frequente entrega de produtos  Adaptação ao negócio é o critério para entregas “Construa o produto certo antes de você construí-lo corretamente”  Desenvolvimento iterativo e incremental  Mudanças são reversíveis utilizando pequenas iterações  Requisitos são acompanhados em alto nível  Testes integrados ao ciclo de vida www.alvarofpinheiro.eti.br
  260. 260. Adaptive Software Development Desenvolvimento Adaptável de Software www.alvarofpinheiro.eti.br
  261. 261. ASD - Características Iterativo e incremental Sistemas grandes e complexos Arcabouço para evitar o caos Cliente sempre presente Desenvolvimento de aplicações em conjunto (Joint Application development – JAD) www.alvarofpinheiro.eti.br
  262. 262. ASD - Fases  O ASD possui ciclos de 3 fases: www.alvarofpinheiro.eti.br
  263. 263. ASD – Fases (Cont.)  Especular (Speculate)  Fixa prazos e objetivos  Define um plano baseado em componentes  Colaborar (Collaborate)  Construção concorrente de vários componentes  Aprender (Learn)  Repetitivas revisões de qualidade e foco na demostranção das funcionalidades desenvolvidas (Learning loop)  Presença do cliente e especialistas do domínio  Os ciclos duram de 4 a 8 semanas www.alvarofpinheiro.eti.br
  264. 264. ASD - Propriedades  Orientado a missões (Misson-driven)  Atividades são justificadas através de uma missão, que pode mudar ao longo do projeto  Baseado em componentes (Component-based)  Construir o sistema em pequenos pedaços  Iterativo (Iterative)  Desenvolvimento em cascata (Waterfall) só funciona em ambientes bem definidos e compreendidos. O ASD possui foco em refazer do que fazer corretamente já na primeira vez www.alvarofpinheiro.eti.br
  265. 265. ASD – Propriedades (Cont.)  Prazos pré-fixados (Time-boxed)  Força os participantes do projeto a definir severamente decisões do projeto logo cedo.  Tolerância a mudanças (Change-tolerant)  As mudanças são freqüentes  É sempre melhor estar pronto a adaptá-las do que controlá-las  Constante avaliação de quais componentes podem mudar  Orientado a riscos (Risk driver)  Itens de alto risco são desenvolvidos primeiro www.alvarofpinheiro.eti.br
  266. 266. ASD - Cargos e Responsabilidades  Este método não descreve cargos em detalhes  Executivo responsável (Executive Sponsor)  Participantes de uma sessão (workshop) do desenvolvimento de aplicações em conjunto (JAD)  Facilitador (Facilitator)  Liderar e planejar as sessões  Escriba (Scribe)  Efetuar anotações  Cliente (Customer)  Sempre presente  Gerente de Projetos (Project Manager)  Desenvolvedores (Developers) www.alvarofpinheiro.eti.br
  267. 267. Paradigma Orientada a Objetos www.alvarofpinheiro.eti.br
  268. 268. Desenvolvimento de Software Programas Processos Dados www.alvarofpinheiro.eti.br
  269. 269. Enfoque a Programas • Visão tradicional usa perspectiva de algoritmo • O principal bloco de construção é o procedimento ou função • Conduz o foco de atenção para questões referentes ao controle e a decomposição de algoritmos maiores em outros menores • Modelagem de dados quebrando os objetos em tabelas, e criando mecanismos para junção posterior www.alvarofpinheiro.eti.br
  270. 270. Desenvolvimento de Software Objetos Visualiza e representa o mundo real como um conjunto de objetos que interagem entre si para que determinadas operações sejam realizadas. Motorista Carro Parar www.alvarofpinheiro.eti.br
  271. 271. Enfoque a Objetos • Visão contemporânea adota perspectiva OO • Forma de construir software que difere bastante dos enfoques tradicionais • Programação orientada a objetos é freqüentemente referenciada como um “novo” paradigma de programação. • A palavra paradigma, neste contexto, significa um conjunto de teorias, padrões e métodos que juntos representam uma forma de organizar o conhecimento www.alvarofpinheiro.eti.br
  272. 272. Enfoque a Objetos • Ela é definida, no mais puro senso, como a programação implementada pelo envio de mensagens. A solução de um problema consiste em identificar os objetos, mensagens e seqüências de mensagens para efetuar a solução • Um software desenvolvido com essa tecnologia guarda muita semelhança com os objetos do mundo real • Cada objeto do mundo real transforma-se em um “objeto” de software • Conduz o foco de atenção para a montagem de sistemas a partir de componentes www.alvarofpinheiro.eti.br
  273. 273. Exemplo • Você resolve jantar numa pizzaria • Existem vários objetos na pizzaria: – Prédio – Mesa – Garçom, etc.... • Cada Objeto tem características que o descrevem – Mesa redonda ou quadrada – Mesa desocupada ou não www.alvarofpinheiro.eti.br
  274. 274. Objetos (o domínio da aplicação) pilha de entrada pilha de saída chefe docs secretária doc doc arquivo docs www.alvarofpinheiro.eti.br
  275. 275. Representando o mundo real • Temos a representação do mundo real • A aplicação de Entrada e Saída de documentos nas caixas de entrada e saída de uma secretária • Transformando em representação de objetos observamos que eles executam apenas trocas de mensagens para se comunicar entre si www.alvarofpinheiro.eti.br
  276. 276. Objetos (o modelo de objetos) Chefe Pilha de saída Próximo Secretária Arquivo Pilha de entrada doc doc doc doc doc Cópia Anotação Edição Próximo Instrução Interrupção Instrução Empilhamento Registro/Status www.alvarofpinheiro.eti.br
  277. 277. Abstração eliminação do irrelevante e amplificação do essencial www.alvarofpinheiro.eti.br
  278. 278. Abstração • É o mecanismo que nos permite representar uma realidade complexa em termos de um modelo simplificado, de modo que detalhes irrelevantes possam ser suprimidos. • Processo de filtragem de detalhes sem importância do objeto, para que apenas as características apropriadas que o descrevem permaneçam. www.alvarofpinheiro.eti.br
  279. 279. Três abstrações de um carro Placa, conserto, pagamento, etc... Km/l, manutenção, etc... Identificação, impostos, placa, etc... Registros de oficina Registros em casa Registros Detran www.alvarofpinheiro.eti.br
  280. 280. Extraindo o essencial... • Para processar algo do mundo real em computador, temos que extrair as características essenciais. Os dados que representam estas características são maneira como representam tal coisa em um sistema • Um mesmo objeto, por exemplo um carro pode dependendo do contexto ser visualizado de formas diferentes. Os dados relevantes do carro para uma oficina, são diferentes dos dados relevantes para o Detran, por exemplo www.alvarofpinheiro.eti.br
  281. 281. Objetos Conta corrente deposito() saldo www.alvarofpinheiro.eti.br
  282. 282. Objetos • Um objeto é qualquer coisa, real ou abstrata, sobre a qual armazenamos dados e operações que manipulam tais dados • Unidade básica de modularização do sistema na abordagem OO • Um objeto é um ente independente, composto por: – atributos, isto é, características ou propriedades que definem o objeto – comportamento, isto é, um conjunto de ações pré-definidas (denominada métodos), através das quais o objeto responderá à demanda de processamento por parte de outros objetos www.alvarofpinheiro.eti.br
  283. 283. Objetos • Validação de um Objeto – É aplicável ao contexto ? – Existe independente de outros Objetos ? – Possui atributos e operações ? – Exemplos • Cor • Exercício: Defina um computador PC segundo os princípios de Orientação a Objetos www.alvarofpinheiro.eti.br
  284. 284. Simplificando... • Sob o ponto de vista superficial , a expressão orientada a objetos significa que o aplicativo é organizado como uma coleção de objetos que incorporam tanto a estrutura como o comportamento dos dados • Reflita alguns minutos como poderíamos montar este ambiente em termos de objetos!!!. • A seguir um exemplo de um controle de Pizzaria (imagine como seria modelar este ambiente em OO para calcular uma conta) www.alvarofpinheiro.eti.br
  285. 285. Controle de Pizzarias • Sistema que informatiza os pedidos de pizza em um restaurante • Poderia ser modelado pelos objetos, Pedido, Cardápio, Pizza, Caixa, Cliente, Garçom, Cozinheiro, etc. • O Cardápio teria como responsabilidade, armazenar os preços, mantendo-os atualizados • Pedido seria responsável pelo processamento dos pedidos feitos pelos clientes www.alvarofpinheiro.eti.br
  286. 286. Controle de Pizzarias • Caixa calcularia a conta a ser paga. • Caso houvesse alteração no sistema para atender a necessidade de atualização de preços, esta seria uma responsabilidade do Cardápio. Os demais Objetos não sofreriam qualquer espécie de alteração • Caso a forma de calcular a conta fosse modificada (por exemplo a gorjeta), o Caixa seria refeito. • Enfim cada Objeto com sua respectiva função www.alvarofpinheiro.eti.br
  287. 287. Funcionário Cozinheiro Garçom Serviços Cardápio Tipo Prato Preço +AlteraPreço +GetPreço Caixa Comanda +CalculaConta Pedido Cliente www.alvarofpinheiro.eti.br
  288. 288. Classes - Fabrica de Objetos Definição da classe Objetos www.alvarofpinheiro.eti.br
  289. 289. Classes • Podemos fazer uma analogia dizendo que as classes são “fábricas” de objetos. • Exemplificando, temos que Pessoa é uma classe e João é um objeto (instância) da classe Pessoa • Um carro é uma classe; “meu carro” é um objeto • Objetos similares são agrupados em classes www.alvarofpinheiro.eti.br
  290. 290. Desenvolvimento de Software Programas x Classes Programas Classes processos atributos dados operações www.alvarofpinheiro.eti.br
  291. 291. Notação para Classes class Fruta { int gramas; int cals_por_gramas; int total_calorias () { return gramas * cals_por_grama; } } www.alvarofpinheiro.eti.br
  292. 292. Mensagem • A POO identifica uma abordagem em que o programador visualiza seu programa em execução em termos de objetos que se comunicam através de trocas de mensagens • Mensagem - composta por um seletor e por parâmetros (opcional) Cliente Conta debite(50R$) debite www.alvarofpinheiro.eti.br
  293. 293. Mensagem • Objetos interagem enviando mensagens uns para os outros. • O objeto que receber a mensagem responderá através da seleção e execução de um método que fará parte de seu comportamento • Após a execução, o controle volta para o objeto que enviou a mensagem • Uma mesma mensagem pode gerar ações diferentes (alguma forma de polimorfismo) • Em geral, classes bem projetadas escondem seus dados de maneira que eles só possam ser modificados por métodos daquela classe www.alvarofpinheiro.eti.br
  294. 294. Classe Exemplo class Exemplo { public static void Main (string args[]) { Fruta AlgumaFruta = new Fruta(); Citros Laranja = new Citros(); AlgumaFruta.Descascar(); Laranja.Descascar(); Laranja.Espremer(); } } www.alvarofpinheiro.eti.br
  295. 295. Encapsulamento separa os aspectos externos de um objeto dos detalhes de implementação www.alvarofpinheiro.eti.br
  296. 296. Encapsulamento • Encapsulamento separa os aspectos externos de um objeto dos detalhes de implementação internos do objeto • É a propriedade dos objetos de agregarem, em seu interior, dados e as operações que atuam sobre estes dados. • O encapsulamento possibilita que os objetos escondam parte de seus componentes do mundo exterior, de modo que o acesso às suas informações seja controlado • Você não precisa saber como um telefone realmente funciona, para poder usar-lo. Só precisamos saber para que ele serve, e conhecer sua interface, ou seja a forma de nos comunicarmos com ele. www.alvarofpinheiro.eti.br
  297. 297. Encapsulamento • Se a companhia telefônica mudar seus processos, você vai continuar usando o aparelho normalmente • A implementação de uma classe, pode ser alterada sem afetar a sua interface. Se um novo telefone for criado, como um telefone digital, a implementação foi alterada, mas a interface permanece a mesma • Reflita associando as idéias com um liquidificador www.alvarofpinheiro.eti.br
  298. 298. Implementando o encapsulamento • Telefone – interface pública - que você usa para interagir com o objeto – implementação - as operações internas, o propósito do objeto • Carro – interfaces públicas - pedais, direção, câmbio – implementação - o propósito do carro www.alvarofpinheiro.eti.br
  299. 299. Implementando o encapsulamento • Em sistemas puramente orientado a objetos, todos os atributos são privados e apenas podem ser acessados ou alterados através de operações na interface pública Exercício • Descreva as interfaces disponíveis num Sistema de Som Baixar,Aumentar,Gravar,Adiantar,Voltar www.alvarofpinheiro.eti.br
  300. 300. Interfaces Públicas Os detalhes de como são os métodos internamente, ou de como eles são implementados não são visíveis através da interface Cliente Conta nc debite a1 b1 a2 b2 nc é o número da conta do cliente (do tipo Conta) e enxerga os métodos debite, mb2 e mb3. Um objeto do tipo Cliente não precisa saber detalhes de implementação do método debite para chamá-lo, ele só precisa saber que a operação faz um débito na Conta e conhecer a sua assinatura. www.alvarofpinheiro.eti.br
  301. 301. class Conta { private double saldo; private long numero; public void credite(double val) { saldo = saldo + val; } public void debite(double val) { saldo = saldo - val; } public void imprimaSaldo() { System.Out.Println(“Conta:“+numero+“Saldo:R$“ + saldo); } } www.alvarofpinheiro.eti.br
  302. 302. Generalização • Generalização identifica e define coisas comuns em uma coleção de objetos Moveis Cadeiras Mesas Biros Quadrada Redonda www.alvarofpinheiro.eti.br
  303. 303. Generalização/Especialização • Generalização é um processo que ajuda a identificar as classes principais do sistema. Ao identificar as partes comuns dos objetos, a generalização ajuda a reduzir as redundâncias, e promove reutilização • O processo inverso a generalização, e a Especialização, que foca a criação de classes mais individuais www.alvarofpinheiro.eti.br
  304. 304. Herança Conta ContaCorrente Poupança ContaEspecial Sobremesa Bolo Sorvete BoloDeChocolate www.alvarofpinheiro.eti.br
  305. 305. Herança • É o mecanismo para definir uma nova classe em termos de uma já existente • É o relacionamento entre classes de objetos que permite a uma classe incluir atributos e operações definidas por outra classe mais genérica. • A classe mais genérica é chamada de superclasse e as classe mais específicas de subclasse. www.alvarofpinheiro.eti.br
  306. 306. Herança • A forma de validar herança é usar a frase “é um”. • Exemplo da bicicleta e o avião, que ambos tem rodas, assento, capacidade de bagagem. • Bicicleta é um avião • Avião é uma bicicleta. www.alvarofpinheiro.eti.br
  307. 307. Herança Figura Polígono Círculo Cor posição central Num de lados vértices raio www.alvarofpinheiro.eti.br
  308. 308. Herança (Java) class Fruta { int gramas; int cals_por_gramas; int total_calorias () { return gramas * cals_por_grama; } } class Citros extends Fruta { void espremer () {/*............*/} } Todas as cítricas são frutas www.alvarofpinheiro.eti.br
  309. 309. Polimorfismo • Significa que a mesma operação pode ter implementações diferentes. • Uma subclasse pode sobrepor a implementação de uma operação que ela herda de uma superclasse. • Somente pode ser usado com a herança www.alvarofpinheiro.eti.br
  310. 310. Polimorfismo de Sobreposição Fruta Descasca() Cítrica Não Cítrica Descasca() www.alvarofpinheiro.eti.br
  311. 311. Polimorfismo • O polimorfismo de sobreposição é resolvido dinamicamente • Ocorre quando uma classe possui um método com o mesmo nome e assinatura (número, tipo e ordem dos parâmetros) de um método da superclasse. Quando isso acontece, dizemos que a subclasse sobrepõe (overrides) o método da superclasse www.alvarofpinheiro.eti.br
  312. 312. Polimorfismo Ícone origem: Ponto exibir() Botão exibir() O tratamento do exibir() em Botão irá “overridar” o exibir() do Ícone, Apesar de herdar o método dele e poder reutilizá-lo, ele implementará de outra maneira este método www.alvarofpinheiro.eti.br
  313. 313. Polimorfismo • No exemplo do Sistema de Controle de Pizzaria • Na pizzaria, a mensagem PRINT para Pedido produz a conta • Enviada para Cardápio, imprime a lista de preços www.alvarofpinheiro.eti.br
  314. 314. Polimorfismo (Java) class Fruta { int gramas; int cals_por_gramas; int total_calorias () { return gramas * cals_por_grama; } void descascar () {System.Out.Println (descasca uma fruta); } } class Citros extends Fruta { void espremer () {/*............*/} void descascar () {System.Out.Println (descasca uma citro); } } www.alvarofpinheiro.eti.br
  315. 315. Polimorfismo (Java) class Exemplo { public static void Main (string args [ ] ) { Fruta AlgumaFruta = new Fruta (); Citros Laranja = new Citros (); AlgumaFruta.Descascar (); Laranja.Descascar (); Laranja.Espremer (); } } www.alvarofpinheiro.eti.br
  316. 316. Associação e Composição • Objetos são associados quando um usa os serviços do outro, e eles existem independentemente – A pessoa usa o computador • A composição ocorre quando um objeto esta contido no outro (tem). – Lápis - grafite , receptáculo de madeira www.alvarofpinheiro.eti.br
  317. 317. Associação – Agregação – Composição Associação – Agregação – Composição Notação: ------- <>------ <>--------- Empresa (todo) <> --------------- Depto. (parte) www.alvarofpinheiro.eti.br
  318. 318. Custodia de um objeto • Propriedade de um objeto e a responsabilidade posterior de destruí-lo • Exemplo: • biblioteca e livros (custodia da biblioteca) – se a biblioteca for destruída, os livros serão destruídos, a menos dos livros emprestados que a custodia esta com os usuários www.alvarofpinheiro.eti.br
  319. 319. Interfaces - Definições • Uma interface é um esqueleto de uma classe (a forma que a classe deve ter), mostrando os métodos que a classe terá quando alguém a implementar. • É uma coleção de operações usadas para especificar um serviço de uma classe ou componente. www.alvarofpinheiro.eti.br
  320. 320. Interfaces – Características – Interfaces formalizam o polimorfismo – Aumentam o nível de reusabilidade – Viabilizam o uso de componentes – Reduzem o esforço de evolução da aplicação www.alvarofpinheiro.eti.br
  321. 321. Interfaces – Características – Definem um tipo especificando apenas a assinatura de seus métodos – Não podem ser instanciadas – Não possuem atributos e seus métodos não tem corpo – Classes implementam interfaces, ou seja, provêem implementação para os métodos especificados em uma interface www.alvarofpinheiro.eti.br
  322. 322. Interfaces – Utilidades e capacidades – Garantir independência entre componentes de software – Garantir substituição de um serviço sem necessidade de alterar quem está usando este serviço – Usada para generalizar conceitos – Em JAVA, interface tem uma conotação muito forte e poderosa e “emula”, de forma bastante eficiente, herança múltipla www.alvarofpinheiro.eti.br
  323. 323. Herança Múltipla Máquina Voadora Máquina Flutuadora Hidroavião www.alvarofpinheiro.eti.br
  324. 324. interface MaquinaVoadora { int Navegar (ponto de, ponto para); void Pousar (); void Decolar (double combustivel); } class Helicoptero implements MaquinaVoadora { double Tanque_Combust; int Rotac_motor; int Rotores; int Navegar (ponto de, ponto para) { */ o codigo aqui */ } void Decolar (double combustivel) { Tanque_Combust + = combustivel; for (; Rotac_motor < 6000; Rotac_motor ++); } void Pousar () {/*..................*/} } www.alvarofpinheiro.eti.br
  325. 325. MaquinaFlutuadora Navio interface implementação Lancha Veleiro etc..... Windsurf www.alvarofpinheiro.eti.br
  326. 326. interface MaquinaFlutuadora { int Navegar (ponto de, ponto para); void LancarAncora (); void LevantarAncora (double combustivel); } class Navio implements MaquinaFlutuadora class Veleiro implements MaquinaFlutuadora class Veleiro extends Navio www.alvarofpinheiro.eti.br
  327. 327. class HidroAviao implements Navio, MaquinaVoadora { double Tanque_Combust; int Rotac_motor; int Cabo_ancora; void LancarAncora () { Cabo_ancora = 200; } void LevantarAncora () { Cabo_ancora = 0; } int Navegar (ponto de, ponto para) {/*................*/}; void Pousar () { for ( ; Rotac_motor > 0; Rotac_motor --); LancarAncora (); } void Decolar (double combustivel) { LevantarAncora (); Tanque_Combust + = combustivel; for ( ; Rotac_motor < 6000; Rotac_motor ++); } } www.alvarofpinheiro.eti.br
  328. 328. Negócio Acesso GUI Interface Interface Dados CLIENTE BD www.alvarofpinheiro.eti.br
  329. 329. Interfaces – Estudo de Caso – Arquitetura do software para Java Interface Gráfica Camada de Aplicação Camada de Acesso a Dados Comandos SQL insert delete update Interface Implementação BD www.alvarofpinheiro.eti.br
  330. 330. Interface Gráfica Camada de Aplicação Camada de Acesso a Dados Chamada stored procedure insert delete update Interface mantida Implementação muda BD Interfaces – Estudo de Caso – Arquitetura do software para Java www.alvarofpinheiro.eti.br
  331. 331. Abordagem Orientada a Objetos INTERFACE Dados + Operações INTERFACE Dados + Operações solicita serviço responde a solicitação www.alvarofpinheiro.eti.br
  332. 332. Abordagem Orientada a Objetos • Analogia com o LEGO (montar os componentes) – Javabeans, EJB, ActiveX • Em Java temos poucos tipos primitivos (int, long, short, double, float, char, boolean) Tudo são classes. Exceções: Linhas de codigo, Guis, Strings, etc... • Pacotes de bibliotecas de classes da plataforma Java – java.lang - nucleo da linguagem – java.awt - interface gráfica – java.net - operações na rede – java.io - lidar com arquivos – java.util - utilitários www.alvarofpinheiro.eti.br
  333. 333. Unified Modeling Language (UML) www.alvarofpinheiro.eti.br
  334. 334. www.alvarofpinheiro.eti.br
  335. 335. Esquema da evolução da análise de sistemas Métodos orientados a processos simples e notação simples Métodos orientados a dados simples e notação simples Métodos orientados a objetos Simples e notação complexa Processos de desenvolvimento 1994 Complexo (RUP) Notação complexa (UML) www.alvarofpinheiro.eti.br
  336. 336. Evolução da Análise Orientada a Objetos • No princípio encontramos recomendações de desenho (Booch, 1986) • Se impõe o modelo orientado as características dos objetos (Shlaer & Mellor, 1988) • Surgem muitos métodos, mas de autores provenientes das bases de dados relacionais (Coad & Yourdon, Martin & Odell, Rumbaugh, Embley, etc., 1990) • Se impõe os métodos orientados ao comportamento dos objetos (Wirfs-Brock, Jacobson, Rubin & Goldberg, 1994) • Começa a iniciar-se a UML (1994) www.alvarofpinheiro.eti.br
  337. 337. Evolução da Análise Orientada a Objetos 1980 1985 1990 1995 2000 Características UML Comportamentos www.alvarofpinheiro.eti.br
  338. 338. O caminho até a unificação • Grady Booch manifiesta a necessidade de unificar critérios • James Rumbaugh se une a Booch em outubro de 1994 • Ambos elaboram a versão 0.8 do Unified Method • Em 1995 Ivar Jacobson completa o trio de “amigos” www.alvarofpinheiro.eti.br
  339. 339. O caminho até o padrão • Se elabora a versão 0.9 do Unified Modeling Language • Durante 1996 se realizam sucessivas modificações na base e um acréscimo de novos participantes (versões 0.91 e 1.0) • Se realiza a versão 1.1 em conjunto com outras importantes empresas, que é apresentada a OMG (Object Management Group) • A OMG adota a UML versão 1.1 como standard no final de 1997 • Atualmente se encontra vigente a versão 1.4 e se está gerando as bases da versão 2.0, que se espera seja mais estável www.alvarofpinheiro.eti.br
  340. 340. UML Web - June ´96 UML 0.9 OOPSLA ´95 Unified Method 0.8 Other methods Booch method OMT OOSE public feedback Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 UML 1.3 UML partners UML 1.0 UML 1.4 www.alvarofpinheiro.eti.br
  341. 341. UML • Linguagem para visualizar, especificar, construir e documentar software • Padrão aberto • Suporta o ciclo completo do desenvolvimento de sofware • Suportada por várias ferramentas www.alvarofpinheiro.eti.br
  342. 342. Objetivos da UML • Estabelecer uma linguagem visual de modelo, expressivo e sensível em seu uso • Manter uma independência dos processos de modelagem das linguagens de programação • Estabelecer bases formais • Integrar as melhores práticas • Impor um padrão mundial www.alvarofpinheiro.eti.br
  343. 343. Modelos, Visões e Diagramas A model is a complete description of a system from a particular perspective Use Case DiUasgera Cmasse DiUagsera Cmasse Diagrams Use Case DiUasgera Cmasse DiSaegqraumensce Diagrams Scenario DiSagcreanmarsio CDoiallgarbaomrastion Diagrams State DiagSrtaamtes DCiaogmrpamonsent Diagrams Component DCiaogmrapmonsent DDeiapglroamyms ent Diagrams Scenario DiSagcreanmarsio DSiatgarteacmhsart Diagrams State DiagSrtaamtes DiagCrlaamsss Diagrams Models www.alvarofpinheiro.eti.br
  344. 344. Desenvolvimento centrado em Modelos Necessidade dos Usuários Processo 1 Processo de Desenvolvimento de SW Modelo 1 Processo 2 Processo n Modelo 2 Desenvolver Software é transformar modelos SW Novo/ Modificado www.alvarofpinheiro.eti.br
  345. 345. www.alvarofpinheiro.eti.br
  346. 346. www.alvarofpinheiro.eti.br
  347. 347. www.alvarofpinheiro.eti.br
  348. 348. Uso de Modelos • Representações simplificadas de coisas reais • Usados há muitos anos em outros ramos da Engenharia,mais maduras que a nossa • Se constroem para melhorar o entendimento • Exemplos: Maquetes, Planos, Equações, Protótipos, Simulação por Computador, Gráficos informais www.alvarofpinheiro.eti.br
  349. 349. Modelar não é um fim • É um meio para construir melhor • Se é mais barato construir e corrigir os erros sobre o produto, Modelar não tem sentido • É muito melhor ver o produto do software do que o modelo, porém terminar o SW e ver que ele não atende as Necessidades é muito mais caro • A Correção é muito mais eficiente nas etapas iniciais do Processo, e os modelos servirão de base para antecipá-los • É conveniente conhecer vários tipos de Modelos. Distintos problemas ou partes deles, requerem distintas técnicas de modelagem www.alvarofpinheiro.eti.br
  350. 350. www.alvarofpinheiro.eti.br
  351. 351. www.alvarofpinheiro.eti.br
  352. 352. Estrutural: modela aspectos estáticos do software focando nas entidades participantes e seus relacionamentos. Os diagramas deste conjunto são: diagrama de classes, objetos, componentes e implementação. Comportamental: modela aspectos dinâmicos do software focando, na maioria das vezes, como as entidades interagem para prover uma determinada funcionalidade para o usuário. Os diagramas deste conjunto são: diagrama de casos de uso, seqüência, colaboração, estados e atividades. www.alvarofpinheiro.eti.br
  353. 353. www.alvarofpinheiro.eti.br
  354. 354. www.alvarofpinheiro.eti.br
  355. 355. www.alvarofpinheiro.eti.br
  356. 356. Arquitetura dos Modelos Visão de implementação Visão de Distribuição Visão de desenho Visão de processos Visão de casos de uso Estrutura (UC,Classes,Relações) Estrutura Componentes Física (Topologia, Implantação,comunicação) Escalabilidade (threads) www.alvarofpinheiro.eti.br
  357. 357. www.alvarofpinheiro.eti.br
  358. 358. Ferramentas da UML – O porquê das ferramentas da UML – Administração de requisitos com casos de uso – Modelos de interação – Modelos de comportamento – Modelos de desenhos www.alvarofpinheiro.eti.br
  359. 359. Ferramentas da UML • Modelo de requisito • Modelo de estrutura • Modelo de interação • Modelo de comportamento • Ferramentas de desenho • Organização de modelo • Diagrama de casos de uso • Diagrama de clases • Diagrama de objetos • Diagrama de sequências • Diagrama de colaboracionais • Diagrama de estados • Diagrama de atividades • Diagrama de componentes • Diagrama de distribuição • Diagrama de pacotes www.alvarofpinheiro.eti.br
  360. 360. O Porquê destas ferramentas Classe Classe Levantamento Modelo de casos de uso Modelo de classes Modelo de comportamento Modelo de interação www.alvarofpinheiro.eti.br
  361. 361. Modelo de Requisitos • Nos primeiros estágios da programação praticamente se construía a aplicação dos requisitos em linguagem natural • Com o advento dos métodos de análise, se supunha que os requisitos estavam completamente definidos antes da modelagem • Com os métodos orientados a objetos começam a aparecer técnicas de modelagem de requerimentos, baseados na criação de “cenários” www.alvarofpinheiro.eti.br
  362. 362. Construção dos Diagramas • Passos recomendados: • elaborar uma lista de atores e definir suas funções • eleger o ator mais representativo do sistema para começar o diagrama • esgotar todas necessidades funcionais do ator incorporando casos de uso da funcionalidade base • para cada caso de uso, buscar os atores que devam colaborar com ele • repetir os dois passos anteriores para cada ator • incorporar a funcionalidade necessária para exceções e erros • fatorizar os casos de uso • obter os atores abstratos mediante generalização • descrever cada caso de uso a medida que se inclue no modelo • validar e verificar o modelo junto com os usuarios www.alvarofpinheiro.eti.br
  363. 363. Estratégia de Levantamento Erros Exceções Caminho Base Funcionalidade desejada Funcionalidade não desejada www.alvarofpinheiro.eti.br
  364. 364. Casos de Uso • Introduzido formalmente por Ivar Jacobson • Aceitado pela comunidade usuária de OO e por muitos metodologistas • É empregado na etapa de levantamento para captar os requerimentos dos usuários • De fácil compreensão por parte dos usuários dos sistemas • Ferramenta que precisa de outros complementos para ser utilizado em processos de modelagem OO www.alvarofpinheiro.eti.br
  365. 365. Casos de Uso • São empregados para capturar o comportamento que se espera do sistema, sem ter de especificar como este comportamento é implementado (caixa preta); • Possibilitam que desenvolvedores obtenham uma compreensão comum do sistema , junto aos usuários e especialistas do domínio www.alvarofpinheiro.eti.br
  366. 366. Ainda sobre Casos de Uso • Cada caso de uso descreve uma forma possível de utilização do sistema por representar uma porção de sua funcionalidade; • Um caso de uso é uma descrição de um conjunto de seqüência de ações, incluindo variações que um sistema executa a partir das interações externas ao sistema www.alvarofpinheiro.eti.br
  367. 367. www.alvarofpinheiro.eti.br
  368. 368. www.alvarofpinheiro.eti.br
  369. 369. Casos de Uso Usuário Emprestar título Devolver título Reservar título Ator www.alvarofpinheiro.eti.br
  370. 370. www.alvarofpinheiro.eti.br
  371. 371. www.alvarofpinheiro.eti.br
  372. 372. www.alvarofpinheiro.eti.br
  373. 373. www.alvarofpinheiro.eti.br
  374. 374. Cadastrar anamnese Atendente de 1º nível <<extend>> <<extend>> Consultar base de conhecimento Cadastrar satisfação do solicitante Abrir o.s. Fechar o.s. Realizar atendimento de 1º nível <<uses>> Atendente de 1º nível Diagrama de Casos de Uso www.alvarofpinheiro.eti.br
  375. 375. USE CASE: ABRIR O.S. Fluxo de dados principal: O use case inicia quando o solicitante telefona para o ramal do Call Center para a resolução de um problema. O atendente de 1o nível informa a matrícula do solicitante. O sistema verifica se o solicitante está cadastrado. Se o mesmo estiver cadastrado, o atendente informa o equipamento e então o sistema verifica se o mesmo está em manutenção. Se o equipamento não estiver em manutenção, o sistema verifica se o equipamento está em garantia. Se não estiver em garantia, o sistema busca os softwares associados àquele equipamento e o atendente verifica a necessidade de execução do processo de anamnese. O sistema sugere a prioridade do atendimento a partir do nível do solicitante e o atendente de 1o nível confirma a prioridade do atendimento. Em seguida, informa a ocorrência do problema. O atendente de 1o nível usa (consultar base de conhecimento). A seguir, o atendente de 1o nível registra data, hora, tipo e dados obrigatórios da O.S. Fluxo de dados excepcional: 1. Se o solicitante não estiver cadastrado, o sistema não permite que o atendimento seja realizado. 2. Se após a abertura da O.S., o atendente de 1o nível encontrou a solução do problema, estende (fechar O.S). 3. Se o equipamento estiver em manutenção, o sistema não permite que o atendimento seja realizado. 4. Caso o equipamento esteja em garantia e o tipo da O.S. não for de software, o atendente de 1o nível registra data, hora, tipo, dados obrigatórios da O.S e número do contrato, encaminhando-a para o coordenador de 2o nível. www.alvarofpinheiro.eti.br
  376. 376. Diagrama de Classes Aluno Curso Disciplina Professor 1 1..* 0..6 0..* 0..* 1 1..* 1..* matricula-se ensina pertence a Aspectos estáticos www.alvarofpinheiro.eti.br
  377. 377. Diagrama de Classes • Diagrama utilizado para representar os aspectos estáticos do Sistema • Exibe um conjunto de classes e seus relacionamentos www.alvarofpinheiro.eti.br
  378. 378. www.alvarofpinheiro.eti.br
  379. 379. www.alvarofpinheiro.eti.br
  380. 380. www.alvarofpinheiro.eti.br
  381. 381. www.alvarofpinheiro.eti.br
  382. 382. www.alvarofpinheiro.eti.br
  383. 383. www.alvarofpinheiro.eti.br
  384. 384. www.alvarofpinheiro.eti.br
  385. 385. www.alvarofpinheiro.eti.br
  386. 386. www.alvarofpinheiro.eti.br
  387. 387. www.alvarofpinheiro.eti.br
  388. 388. www.alvarofpinheiro.eti.br
  389. 389. www.alvarofpinheiro.eti.br
  390. 390. Diagrama de Seqüência : Atendente de 1º nível : Form AbrirOS : Solicitante Abrir( ) Informar Matrícula Usuário( ) Finalizar Validar Usuário( ) Usuário Não Cadastrado Aspectos Dinâmicos www.alvarofpinheiro.eti.br
  391. 391. Diagrama de Seqüência • Usados para modelar os aspectos dinâmicos do Sistema • É um diagrama de interação que enfatiza a ordenação de mensagens com relação ao tempo www.alvarofpinheiro.eti.br
  392. 392. www.alvarofpinheiro.eti.br
  393. 393. www.alvarofpinheiro.eti.br
  394. 394. www.alvarofpinheiro.eti.br
  395. 395. www.alvarofpinheiro.eti.br
  396. 396. Diagrama de Componentes Aplicação Específica Aplicação Geral MiddleWare System Software Software Gerencial Atendimento Contratos Equipamento Manutenção Preventiva Hardware MTS Windows NT OS Ambiente de Conhecimento Software Func_Help_Desk Defeito Oracle Relacionamento entre os Componentes www.alvarofpinheiro.eti.br
  397. 397. Componentes  • Os componentes são um importante bloco de construção na modelagem dos aspectos físicos do sistema;  • Um componente é uma parte física e substituível do sistema que realiza uma interface ou usa os serviços da mesma;  • Um componente tipicamente representa o empacotamento físico dos elementos lógicos como classes, interfaces e colaborações www.alvarofpinheiro.eti.br
  398. 398. Componentes  Uma interface é uma coleção de operações que são usadas para especificar um serviço de uma classe ou um componente;  O Diagrama de Componentes exibe as organizações e dependências entre componentes, com o propósito de modelar a visão de implementação dos módulos de software executáveis de um sistema; www.alvarofpinheiro.eti.br
  399. 399. Diagrama de Componentes  • Um nodo (nó) é um elemento físico que existe em tempo de execução e representa um recurso comp