Educação Profissional Técnica de Nível Médio Curso Técnico de Informática

2. Educação Profissional Técnica de Nível Médio Curso Técnico de Informática Disciplina: Interpretação de Projetos de Software Professor: Cheli dos S. Mendes da Costa Analise e Modelagem orientada a objetos

3. "A maneira como você coleta, gerencia e utiliza as informações determina se você vai vencer ou perder”. Bill Gates 09/2014 Cheli Mendes

4. Antes de falamos sobre as ferramentas, vamos lembrar um pouco da Análise de Requisitos. Na analise de requisitos são identificadas as ações que serão executadas pelo sistema para que este possa alcançar os objetivos esperados. Desta análise são extraídas as funcionalidades que o sistema deve ser capaz de executar e as interações com o ambiente computacional e humano.

5. Estes são os requisitos funcionais de um sistema. Também são identificados os requisitos não funcionais que se referem às questões internas do software, não alteram sua funcionalidade, mas dão identidade ao produto do software.

6. Alguns dos requisitos não funcionais mais citados nas literaturas específicas são: • Usabilidade: é o atendimento ao perfil das pessoas que irão utilizar o sistema, isto influenciará na produtividade e aceitação do software; • Confiabilidade: diz respeito aos resultados produzidos pelo sistema,estes devem estar corretos;

7. Desempenho: trata dos comprometimentos de recursos que o sistema exige e tempo para execução em compatibilidade com suas funcionalidades; • Segurança: Confidencialidade e proteção dos dados do usuário. • Integridade: garantia de fidelidade dos dados contidos no sistema e garantia de que os erros serão recuperados.

8. Existem muitos outros, mas o que importa é o conjunto de requisitos assinalarem o comprometimento entre os desenvolvedores, clientes e usuários, sobre o produto de software a ser desenvolvido. Antes do desenvolvimento do software, é necessário que haja o conhecimento de seu escopo, as necessidades de recursos e um cronograma de planejamento, além de muitas outras informações acerca do trabalho a ser realizado.

9. Uma vez alcançado um nível de compreensão suficiente, é realizado atividades de preparação do plano de projeto. O plano de projeto se apoia nas atividades de engenharia de software da metodologia de organização. Cada parte do projeto deve ter estima das necessidades e recursos e outras especificações.

10. Diagrama de Atividades

11. Diagrama de atividades Apresenta muitas semelhanças com os antigos fluxogramas. O Diagrama de Atividades é um instrumento indicado para iniciar o processo de modelagem do problema. Este diagrama preocupa-se em descrever os passos a serem percorridos para a conclusão de um método ou algoritmo específico e não um processo completo como é o diagrama de sequência.

12. Diagrama de Atividades Este diagrama é de fácil compreensão por parte do cliente e usuários. Ele mostra um fluxo sequencial das atividades bem como suas decisões e condições. É composto por: Estado inicial e estado final: indica onde começa e termina o diagrama; O Estado Inicial é representado por um círculo preenchido, a partir do qual é gerada uma transição que determina o início do processo. O Estado Final é representado por um círculo não preenchido envolvendo um segundo círculo preenchido. Exemplo de um estado Inicial Exemplo de um estado final

13. Diagrama de Atividades Receber numero do produto É composto por: Estado de Ação : Representa uma tarefa ou ação; Representa a realização de uma ação dentro de um fluxo de controle. Exemplo Estado da Ação

14. Diagrama de Atividades Uma atividade costuma possuir diversos Estados de Ação. Um Estado de Ação pode conter tanto uma descrição da ação que está sendo realizada, como a ação propriamente dita, expressa através de uma fórmula, em pseudocódigo ou mesmo em código escrito em uma linguagem de programação.

15. Diagrama de Atividades Fluxo de Controle É composto por: Fluxo de Controle /Transições: estabelece o fluxo do diagrama; Quando a ação está completa, o fluxo de controle passa imediatamente à próxima ação. O fluxo é especificado utilizando setas de fluxo para mostrar o caminho de uma ação seguinte.

16. Diagrama de Atividades É composto por: Ponto de decisão: Representa um ponto do fluxo de controle onde deve ser realizado um teste, uma tomada de decisão. As transições geradas por um Ponto de Decisão necessitam ser providas de uma Condição de Guarda(texto entre colchetes) para determinar qual a condição do teste.

17. Diagrama de Atividades Exemplo

18. Diagrama de Atividades É composto por: Fluxo de Objetos: Representa o estado dos objetos envolvidos na atividade descrita pelo diagrama. É representado por uma reta tracejada contendo uma seta que atinge o quadrado representando um objeto, contendo um texto descrevendo o nome do objeto e a classe a qual ele pertence.

19. Diagrama de Atividades É composto por: Recebimento de Sinal: Representa o recebimento de um sinal de um dispositivo externo, normalmente um item de hardware.

20. Diagrama de Atividades Raias: representam os papéis ou as unidades organizacionais dentro do modelo. São uma extensão do Diagrama de Atividades, onde procura-se identificar os diversos setores, departamentos ou mesmo os atores que interagem com um processo. As Raias de Natação são formadas por retângulos representando divisões que identificam as zonas de influência de um determinado setor sobre um determinado processo.

21. Diagrama de Atividades Diagrama de Atividades Referente as etapas de publicação de Livro de um autor

22. Exemplo 1

23. Recomendações de utilização do Diagrama de atividades • Modelagem dos processos do negócio. • Modelagem da lógica de um caso de uso. • Modelagem da lógica de uma operação complexa.

24. Modelagem dos processos do negócio. O processo de negócio também é um processo de entendimento. Às vezes os modelos são construídos para melhorar o entendimento de um determinado problema. Nesse caso, o enfoque está em entender o comportamento do sistema no decorrer de diversos casos de uso.

25. Modelagem dos processos do negócio.

26. Modelagem da lógica de um caso de uso. • Na descrição de um caso de uso, não há uma sintaxe clara para indicar decisões, iterações e fluxos executados em paralelo. É comum utilizar frases como “O passo P ocorre até que a condição C seja verdadeira” ou “Vai para o passo 9 do Fluxo Principal” Nessas situações, é interessante complementar a especificação do caso de uso com um diagrama de atividades. O diagrama de atividades deve ser usado para complementar a especificação e não para substituí-la.

27. Modelagem da lógica de um caso de uso.

28. Modelagem da lógica de uma operação complexa. Em alguns casos, quando uma operação de uma classe de controle implementa uma regra de negócio, pode haver a necessidade de descrever a lógica dessa operação ou da própria regra de negócio. Diagramas de atividades também podem ser usados com esse objetivo.

29. Modelagem da lógica de uma operação complexa. A nota de um aluno em uma disciplina (um valor de 0 a 10) é obtida pela média de duas avaliações durante o semestre, A1 e A2, ou pela frequência nas aulas. • Se o aluno obtiver nota maior ou igual a 7.0 (sete), será aprovado. • Se o aluno obtiver nota maior ou igual a 5.0 (cinco) e menor que 7.0 (sete), deverá fazer a avaliação final. • Se o aluno obtiver nota menor que 5.0 (cinco) será reprovado. • Se o aluno obtiver uma frequência menor que 75% em uma turma, será automaticamente reprovado. • Após a prova final, o aluno será considerado aprovado, se sua média final for maior ou igual a 6.0 (seis), caso contrário, será reprovado.

30. Modelagem da lógica de uma operação complexa.

31. Exemplo extraDo Caso de uso – Realizar Pedido

32. Atividade Desenvolva um diagrama de Atividades conforme estes detalhes: O Estudante de Curso inicia uma sessão no sistema e apresenta suas credenciais. • O sistema verifica se a credencial é válida. • O sistema solicita que o estudante realize sua matrícula, selecionando 4 disciplinas. • O estudante preenche um formulário eletrônico de matrícula e o submete para uma análise de consistência. O sistema analisa as informações contidas no formulário. – Se as informações são consistentes, o estudante é incluído em turmas abertas de 4 disciplinas, iniciando pelas preferenciais. – Se as informações não são consistentes, o sistema informa o motivo da inconsistência e solicita que o formulário seja alterado.

33. Caso de Uso- Use case

34. Caso de Uso Use case é a especificação de uma sequência de interação entre um sistema e os agentes externos que utilizaram esse sistema. Descrevem a visão do sistema e suas interações com o mundo exterior. O analista descreve como o usuário interage com o sistema. São identificados atores que interagem com o sistema enviando estímulos e o sistema responde aos estímulos do ator.

35. Caso de Uso Na modelagem de casos de uso o analista não deve levar em consideração a implementação do sistema. O objetivo não é especificar o software, mas sim, o que o software deve atender.

36. Caso de Uso • No caso de uso é descrito: • As ações que o usuário executa para realizar sua parte dos trabalhos nos processos em que participam; • Os requisitos funcionais do sistema de maneira consensual entre usuários e desenvolvedores; • Descrição sobre responsabilidades de cada ator identificado; • Oferecer possíveis situações do mundo real para o teste do sistema.

37. Caso de Uso – Diagrama A diagramação oferece uma visão geral do modelo, mas suas descrições são realizadas por texto, pois, os modelos visuais não são suficientes para fornecer todas as informações necessárias. A documentação em texto deve definir os requisitos solicitados pelo cliente ou usuário e descrever as funcionalidades do sistema.

38. Caso de Uso Formato de Descrição • Descrição Continua – A narrativa é feita através de um texto livre. • Exemplo: Caso de uso Realizar Saque em Caixa eletrônico • O cliente chega ao caixa eletrônico e insere seu cartão. O sistema requisita a senha do cliente. Após o cliente fornecer sua senha e esta ser validada . O sistema exibe as opções de operações possíveis. O cliente opta por realizar um saque . Então o sistema requisita o total a ser sacado. O sistema fornece a quantia desejada e imprime o recibo para o cliente.

39. Caso de Uso • Formato de Descrição • Descrição Numerada - A narrativa é descrita através de uma seria de passos numerados. • Exemplo: Caso de uso Realizar Saque • Cliente insere seu cartão no caixa eletrônico. • Sistema apresenta solicitação de senha. • Cliente digita senha. • Sistema exibe menu de operações disponíveis • Cliente indica que deseja realizar um saque. • Sistema requisita quantia a ser sacada. • Cliente retira a quantia e o recibo.

40. Caso de Uso • Formato de Descrição • Descrição Particionada - A narrativa tem o objetivo de separar as ações do ator e as reações do sistema. • Exemplo: Caso de uso Realizar Saque

41. Importante A descrição de um caso de uso deve ser legível para o usuário final. Grau de detalhamento – Pode variar , mais deve ser o mais sucinto.

42. Caso de Uso pode ser Real ou Essencial • Caso de Uso Essencial é abstrato e não faz menção a tecnologia a ser utilizado. - Pode ser descrito é qualquer formato. - Indicado para situações em que os sistema tem mais de uma interface para o mesma funcionalidade.

43. Caso de Uso Essencial Exemplo: Interface do site na internet ou uma interface via telefone celular. Podem ser utilizados para modelagem de Caso de Uso de negocio (o sistema é considerado a própria organização empresarial. As funcionalidades são os processos empresariais.

44. Caso de Uso Essencial Exemplo de descrição Essencial ( e numerada) Realiza Saque . • Cliente fornece sua identificação. • Sistema identifica o usuário. • Sistema fornece operações disponíveis • Cliente solicita o saque de uma determinada quantia. • Sistema fornece a quantia desejada da conta do cliente. • Cliente recebe dinheiro e recibo

45. CasodeUsoReal É citado detalhes da tecnologia a ser utilizada na implementação do caso de uso. Descrição continua , enumerada e particionada são exemplos reais.

46. Cenário • É a descrição de uma das maneiras pelos quais um caso de uso pode ser realizado, também chamado de instancia de um caso de uso. • Normalmente a diversos canários para um caso de uso. 09/2014 Cheli Mendes

47. Cenário Exemplo para o Caso de Uso Realizar Compra. Um cliente telefona para a empresa. Um vendedor atende ao telefone. Cliente declara seu desejo de fazer um pedido. Vendedor pergunta a forma de pagamento. Cliente indica que vai pagar com cartão de credito. Vendedor requisita o numero do cartão, a data de expiração e o endereço de entrega. Vendedor pede informações do primeiro item Cliente fornece o primeiro item. Vendedor pede as informações do segundo item. Cliente fornece o segundo item. Vendedor pede informações do terceiro item. Cliente fornece o terceiro item.

48. Cenário Vendedor informa que o terceiro item não tem em estoque. Cliente pede que vendedor feche a compra só com os dois primeiros itens. Vendedor fornece o valor total, a data de entrega e uma identificação do pedido. Cliente agradece e desliga o telefone. Vendedor contata a transportadora para envio do produto para o cliente.

49. Importante Podemos utilizar outros cenários para a fase de testes, onde se constata se há a existência de erros na implantação do sistema . Também é levantado outras situações na construção do cenário. Exemplo: O que acontece se o cliente desligar o telefone antes de realizar o seu pedido? E se o cartão de credito do cliente não for aceito ? A empresa transportadora é um ator do sistema?

50. Atores • Na UML qualquer elemento externo que interage com o sistema é denominado ator. CATEGORIAS • Pessoas( Empresa, Cliente, Gerente, vendedor e etc.) • Organizações ( Empresa Fornecedora , Agencia de impostos e etc.) • Outros sistemas ( Sistema de cobranças, Sistema de estoque de Produtos e etc.) • Equipamentos (leitora de códigos de barram sensor e etc.)