Engenharia de Software II - Aula 15

350 visualizações

Publicada em

Slides da 15ª aula da disciplina "Engenharia de Software II".

Curso: Sistemas de Informação.

Publicada em: Negócios
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
350
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
19
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Engenharia de Software II - Aula 15

  1. 1. Alessandro Almeida | www.alessandroalmeida.com
  2. 2. Prova 1:Dia 10 de outubro
  3. 3.  Serão consolidados e disponibilizados para a turma  Caso algum grupo prefira não compartilhar seu material, entre em contato comigo Nas provas (Prova 1 e Exame Final) teremos alguma(s) questão(ões) sobre os trabalhos apresentados
  4. 4. Valendo 20 horas de AC!
  5. 5.  Quem realizar a leitura e documentar suas conclusões somará 20 horas de AC  No mínimo, 5 páginas (fonte Arial, tamanho 12) Importante:  Não é um resumo do livro!  O objetivo é fazer uma reflexão sobre as ideias do Edward Yourdon
  6. 6. Conclusões sobre a atividade
  7. 7.  Durante as apresentações de vocês, navegamos por toda a estrutura da UML...
  8. 8. Será que alguém utiliza a UML na sua plenitude?
  9. 9.  Todos os diagramas são tão populares quanto a própria UML?
  10. 10.  Caso de Uso Classes Objetos Sequência Atividades Comunicação Visão Geral Máquina de Estados Implementação
  11. 11.  Caso de Uso Classes Objetos Sequência Atividades Comunicação Visão Geral Máquina de Estados Implementação
  12. 12. Será que todos os diagramas sãoaplicáveis à dinâmica dos projetos que participamos?
  13. 13. Jim Rumbaugh Grady Booch Ivar Jacobson
  14. 14. Jim Rumbaugh Grady Booch Ivar Jacobson
  15. 15. UML ajuda!
  16. 16. Mas não é A SOLUÇÃO paragerenciamento de requisitos e modelagem da solução.
  17. 17. Não seja ortodoxo na hora de utilizar a UML!(customize sem medo, mas de forma consciente)
  18. 18. Para mapear e documentar os requisitos...
  19. 19.  Um caso de uso descreve uma sequência de ações que representam um cenário principal e cenários alternativos Demonstra o comportamento de um sistema (ou parte dele), através de interações com atores  Texto e diagrama
  20. 20.  Cenário (ou fluxo) principal...  Deu tudo certo (ou, caminho feliz)! Cenário (ou fluxo) alternativo...  Vixe... Deu erro!
  21. 21.  Caso de Uso #001: Realizar pagamento com boleto Ator: Cliente do banco Fluxo principal: 1. O cliente digita o código do boleto 2. O sistema valida as informações e apresenta o valor do pagamento e a data do vencimento 3. O cliente confirma as informações apresentadas 4. O sistema solicita a senha para pagamento 5. O cliente informa a senha 6. O sistema processa o pagamento e informa o saldo atualizado da Conta Corrente
  22. 22.  No Caso de Uso #001: Realizar pagamento com boleto, poderíamos descrever também os fluxos alternativos:  Conta corrente sem saldo  Senha incorreta  Código de barras do boleto incorreto  Boleto vencido  Etc.
  23. 23.  Para complementar, também poderíamos incluir as Regras de Negócio, Pré-condições, Pós-condições, etc. Ou seja, você pode adaptar a parte textual do Caso de Uso de acordo com a necessidade do seu projeto...
  24. 24.  Lembram com o DFD Nível 0 (Diagrama de Contexto)?  O Diagrama de Caso de Uso tem função parecida  Mostra o limite do sistema e as interações com o mundo exterior
  25. 25.  Permite visualizar de forma rápida os atores, os casos de uso e os relacionamentos entre eles  Quais atores realizam quais casos de uso?  Quais casos dependem de outros casos de uso? Lembrem-se...  “Uma imagem vale mais do que mil palavras!”
  26. 26. Até a versão 1.2 da UML, o<<include>> era chamado <<uses>>
  27. 27. Começando a brincar com o Caso de Uso
  28. 28. alessandro.almeida@uol.com.brwww.slideshare.net/alessandroalmeida

×