Análise de Sistemas

1. Análise de Sistemas Análise e Projeto Prof. Jeime Nunes Email: jeime_na@yahoo.com.br Site: www.jeimenunes@wordpress.com

2. Fluxo de análise e projeto • O objetivo aqui é traduzir os requisitos em uma especificação de como implementá-los; • A UML será utilizada para essa especificação; • É preciso transformar os requisitos em um projeto do sistema; • Será desenvolvida uma arquitetura para o sistema;

3. Fluxo de análise e projeto

4. Fluxo de análise e projeto

5. Fluxo de análise e projeto • Realizar caso de uso • Conjunto de elementos que descreve como o caso de uso será realizado;

6. Fluxo de análise e projeto • Vamos usar o exemplo do sistema bancário

7. Realizar caso de uso • Para cada caso de uso: • Encontrar as classes de análise; • Ainda bastante abstratas; • Futuramente podem ser divididas ou mesmo transformadas em subsistemas; • Para cada classe descrever responsabilidades, atributos e relacionamentos; • As classes de análise podem ser de três tipos: • Fronteira, entidade e controle;

8. Realizar caso de uso • Classes de Fronteira (boundary classes) • Fazem a fronteira do sistema com qualquer interface externa; • Isolam o núcleo do sistema do mundo exterior; • Evitam que mudanças no mundo exterior afetem outras classes do sistema; • Identificadas com o estereótipo <<boundary>>; • Notação UML: ou

9. Realizar caso de uso • Descobrindo Classes de Fronteira • Regra geral é uma classe para cada par ator/caso de uso;

10. Realizar caso de uso • Classes de entidade (entity) • Representam os conceitos principais do sistema, as fontes de informações que o sistema manipula; • Principal função é armazenar e gerenciar informação; • Notação UML: ou

11. Realizar caso de uso • Descobrindo classes de entidade • Observe o glossário e o fluxo de eventos do caso de uso; • Identifique substantivos no fluxo de eventos; • Os substantivos são candidatos naturais a classes de entidade; • Remova substantivos redundantes e vagos; • Remova atributos e operações (serão usados mais tarde);

12. Realizar caso de uso • Fluxo de evento principal • O cliente informa os dados necessários para efetuar o pagamento do cartão: • - O código de barras da fatura que deseja efetuar o pagamento; • - O valor que deseja pagar. • 2. O sistema recupera a conta bancária do cliente logado; • 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento; • 4. O sistema debita da conta do cliente; • 5. O sistema envia o pagamento à operadora de cartão de crédito; • 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento; • Efetuar pagamento do QualitiCard

13. Realizar caso de uso • Efetuar pagamento do QualitiCard

14. Realizar caso de uso • Classes de controle • Coordenam o comportamento (lógica de controle) do caso de uso; • Interface entre fronteira e entidade; • Deixam as classes de fronteira mais reusáveis, pois ficam isoladas do comportamento específico do sistema; • Identificadas com o estereótipo <<control>>; • Notação UML: ou

15. Realizar caso de uso • Classes de controle • Usualmente, um classe de controle por caso de uso; • Casos de uso com fluxos simples podem ser realizados sem classes de controle; • Casos de uso com fluxos mais complexos podem precisar de mais de uma classe de controle;

16. Realizar caso de uso • Distribuir comportamento entre as classes • Alocar responsabilidades às classes; • Modelar interações entre classes através dos diagramas de interação: • Usaremos os diagramas de sequência e colaboração;

17. UML: Diagrama de Sequência

18. Diagrama de Sequência • Diagrama que representa a sequência de eventos do sistema; • Identificando os métodos que são disparados entre os atores e os objetos envolvidos; • É baseado na descrição dos casos de uso do sistema; • O texto dos casos de uso são fontes de informações para identificar as operações e consultas do sistema;

19. Diagrama de Sequência

20. Elementos do Diagrama de Sequência • Atores: são instâncias dos atores declarados no diagrama de casos de uso; • Objetos: são objetos que participam de uma iteração durante um determinado tempo; • Se você já iniciou o diagrama de classes, os objetos serão instâncias das classes existentes no sistema;

21. Elementos do Diagrama de Sequência • Linha de vida: representa o tempo em que um objeto existe durante um processo; • Interrompida com um “X” quando o objeto é destruído; • Foco de controle ou Ativação: indica os períodos que um objeto está participando ativamente do processo;

22. Elementos do Diagrama de Sequência • Mensagens ou estímulos • Utilizadas para demonstrar a ocorrência de eventos; • Normalmente forçam a chamada de um método em algum dos objetos; • Podem ser disparadas entre: ator para ator, ator para objeto; objeto para objeto e objeto para ator;

23. Elementos do Diagrama de Sequência • Mensagens de retorno • É a resposta a uma mensagem para o objeto que a chamou; • São representadas por uma seta tracejada apontando para o objeto ou ator que recebe o resultado do método chamado;

24. Elementos do Diagrama de Sequência • Auto-chamadas • São mensagens que partem da linha de vida de um objeto e atingem a linha de vida do próprio objeto;

25. Elementos do Diagrama de Sequência • Fragmentos de Interação • É uma parte de uma interação, porém é considerado como uma interação independente; • Representado por um retângulo que envolve a interação, com uma aba no canto superior contendo um operador que indica o tipo de diagrama de interação ele se refere; • Ex: • sd Confirmar pedido Nome da interação Operador sd (diagrama de sequência

26. Elementos do Diagrama de Sequência • Fragmentos de Interação Os fragmentos são úteis para poder referencia-los por meio do operador Ref (Referred – referido). Ou seja, o fragmento faz referência a outro diagrama.

27. Elementos do Diagrama de Sequência • Ocorrência de Interação Operador As referencias em um fragmento de interação são chamadas de Ocorrências de Interação. Permite a criação de diagramas complexos que fazem referências a outros diagramas.

28. Elementos do Diagrama de Sequência • Fragmentos combinados e operadores UML • Utilizados para uma modelagem semi-independente de parte do diagrama em que se deve focar algum problema; • Representado por um retângulo que determina a área de abrangência do fragmento; • No canto superior esquerdo do retângulo contém uma subdivisão com um operador de interação que define o tipo de fragmento que está sendo modelado;

29. Elementos do Diagrama de Sequência • Fragmentos combinados e operadores UML

30. Elementos do Diagrama de Sequência • Outros Operadores UML • Opt (Opção): determina que o fragmento combinado pode ou não ser executado;

31. Elementos do Diagrama de Sequência • Outros Operadores UML • Loop (Laço): determina que o fragmento representa um laço que poderá ser repetido diversas vezes;

32. Elementos do Diagrama de Sequência • Outros Operadores UML • Par (paralelo): representa uma execução paralela de dois ou mais comportamentos; • Break(Quebra): indica uma quebra na execução normal do processo; • CriticalRegion (Região Critica): identifica uma operação que não pode ser interrompida por outro processo até ser totalmente concluída; • Ignore(Ignorar): indica que as mensagens contidas no fragmento devem ser ignoradas; • Vejam outras no livro;