Princípios de modelagem de Domínio e Projeto(design) de Software Parte 2

Transcrição

1 Princípios de modelagem de Domínio e Projeto(design) de Software Parte 2 Prof. Gustavo Willam Pereira ENG10082 Programação II Créditos: Prof. Clayton Vieira Fraga Filho

2 Análise de Casos de Uso (continuação) Diagrama de casos de uso Importante salientar que antes de iniciar a análise de cada caso de uso em específico, é importante ter a visão geral do sistema que está sendo proposto, por meio das definições de todos os casos de uso. Para isso, utiliza-se o diagrama de casos de uso, composto de: Atores; Casos de uso; Relacionamentos. 2

3 Análise de Casos de Uso (continuação) Diagrama de casos de uso O Ator, em um diagrama de Casos de Uso (dcu) é um PAPEL DESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (não necessariamente uma pessoa). Outros sistemas (externos) também podem ser atores. A representação do Caso de Uso no Diagrama é simples: a elipse representa uma forma que o sistema se comporta do ponto de vista do Ator. O nome do Caso de Uso é uma forma de elucidar esse comportamento do sistema, assim sendo, o nome do caso de uso define o OBJETIVO do Ator, isto é, o que ele quer fazer no sistema. uc Casosd... Ator uc CasosdeUso Cadastrar clientes 3

4 Análise de Casos de Uso (continuação) Diagrama de casos de uso A notação básica do diagrama são Atores representados pelos bonequinhos. Uma linha conecta atores aos Casos de Uso informando que o sistema permitirá ao Ator usar o Caso de Uso diretamente. Os Casos de Uso são representados por elipses uc CasosdeUso uc: exemplo sistema de vendas Vendedor Cadastrar clientes Cadastrar produtos Efetuar v endas Gerente Registrar recebimentos 4

5 Análise de Casos de Uso (continuação) Após a identificação de todos os casos de uso que devem atender o que os clientes querem para o sistema; De posse da descrição expandida (narrativa) de cada um deles: Verificar o texto dos casos de uso expandidos Selecionar termos que representam informação transmitida do ator para o sistema Agrupar sinônimos 5

6 Análise de Casos de Uso (continuação) Caso de Uso Essencial Cadastrar um cliente Fluxo principal 1. O cliente chega ao balcão para fazer seu cadastro 2. O atendente solicita seu nome e um comprovante de renda (com valor total da renda atualizado) 3. O atendente faz a classificação do cliente e atribui um percentual de desconto 4. O atendente informa ao cliente que seu registro foi feito com sucesso. Fluxos de exceção FE1 - Cliente não lembra sua renda 1. O cliente não tem um comprovante de renda 2. O atendente solicita que seja providenciado 3. O cliente se dispõe a providenciar 4. O registro é suspenso. Fluxos alternativos Não há

7 Análise de Casos de Uso (continuação) Termos identificados na 1º avaliação do analista: Cliente Nome Comprovante de Renda Classificação do cliente Percentual de Desconto Em um outro momento o analista pode necessitar esclarecer junto ao stakeholder: Por que é necessário ter um comprovante de renda? O que é classificação do cliente e como é feita a classificação? Como o percentual de desconto é atribuído? Ou pode ser que essas informações tenham sido obtidas em uma conversa prévia, que tenha sido inclusive gravada em áudio.

8 Análise de Casos de Uso (continuação) O cliente pode explicar ao analista que (quase nunca de forma tão direta como segue): A empresa mantém um cadastro de clientes, com seu código, nome, renda e tipo (Prata e Ouro). Os clientes podem se cadastrar na empresa e participar de 2 categorias (tipos) distintos. Clientes tipo Ouro são aqueles com renda superior a 1000 reais. Estes têm 10% de desconto no valor das suas faturas. Clientes prata são aqueles com renda entre 300 e 1000 reais e tem desconto de 5%. Os demais clientes cadastrados com renda inferior a 300 reais não tem classificação (tipo) e não possuem desconto;

9 Análise de Casos de Uso (continuação) O analista pode identificar a classe de domínio Cliente, como segue: class Venda class Venda class Venda Cliente - codcliente -/ desconto - nome - renda - tipo ou ClienteOuro Cliente - codcliente -/ desconto - nome - renda ClientePrata ou Cliente - codcliente -/ desconto - nome - renda 1 +tipo 1 Tipo - desconto - limiteinferiorrenda - limitesuperiorrenda - tipo

10 Análise de Casos de Uso (continuação) Passos da Atividade de Análise: Identificar as classes Identificar responsabilidades das classes Identificar relacionamentos Identificar atributos Identificar persistência 10

11 Análise de Casos de Uso (continuação) Identificando as classes No primeiro passo de análise, identificaremos três tipos de classes: Fronteira Entidade Controle Tais classes são identificadas separadamente para cada caso de uso 11

12 Análise de Casos de Uso (continuação) Caso de Uso Essencial Cadastrar um cliente Fluxo principal 1. O cliente chega ao balcão para fazer seu cadastro 2. O atendente informa o procedimento e solicita o nome do cliente e um comprovante de renda (com valor total da renda atualizado) [FE1] 3. [EV] O atendente registrar o nome e a renda do cliente 4. [RS] O sistema exibe a classificação do cliente e o percentual de desconto autorizado. 5. O atendente informa ao cliente que seu registro foi feito com sucesso. Fluxos de exceção FE1 - Cliente não lembra sua renda 1. O cliente não tem um comprovante de renda 2. O atendente solicita que seja providenciado 3. O cliente se dispõe a providenciar 4. O registro é suspenso. Fluxos alternativos Não há

13 Análise de Casos de Uso (continuação) Exemplo Que classes preciso criar? uma classe de fronteira para lidar com a interação dos atores com o sistema uma classe de entidade para representar as informações relevantes do cliente uma classe de controle para gerenciar o fluxo de execução do caso de uso 13

14 Análise de Casos de Uso (continuação) Exemplo TelaCadastroCliente ControladorCliente Cliente Há diferentes opções de visualização dos estereótipos, por exemplo modo texto: <<boundary>> TelaCadastroCliente <<control>> ControladorCliente <<entity>> Cliente 14

15 Análise de Casos de Uso (continuação) Exemplo <<boundary>> TelaCadastroCliente <<control>> ControladorCliente <<entity>> Cliente Só teremos um cliente? Onde ficarão armazenados os demais? Que classe será responsável por realizar as tarefas de persistência? 15

16 Análise de Casos de Uso (continuação) Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>> ou <<persistence>>. <<boundary>> TelaCadastroCliente <<control>> ControladorCliente <<entity>> Cliente <<entity collection>> CadastroClientes Compatível com o vetor de clientes, ou lista de clientes na programação estruturada. 16

17 Diagramas de interação Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa. Inicialmente deve-se identificar as informações trocadas entre os elementos identificados durante e categorizados pela método BCE. 17

18 Diagramas de interação: Sequência : CadastroClientes : Atendente : TelaCadastroCliente : ControladorCliente : Cliente 1 : nome, renda() 2 : nome, renda() 3 : calcula o % de desconto() 4 : classifica o cliente() 5 : Cria a entidade() 6 : Cadastra a entidade na lista() 18

19 Diagrama de Sequência: Overview Instância da classe, ou ator. Pode ter o nome ou o tipo, ou ambos. : CadastroClientes : Atendente : TelaCadastroCliente : ControladorCliente : Cliente 1 : nome, renda() Região de execução 2 : nome, renda() 3 : calcula o % de desconto() 4 : classifica o cliente() Estímulo ou mensagem enviada de um objeto para o outro, ou executada pelo mesmo objeto 5 : Cria a entidade() 6 : Cadastra a entidade na lista() Linha de vida: o sistema ou o ator está inativo, mas está instanciado Quando a linha está cheia, o sistema está ativo (operando ou aguardando o resultado de alguma operação) 19

20 Diagramas de interação : CadastroClientes : Atendente : TelaCadastroCliente : ControladorCliente : Cliente 1 : nome, renda() 2 : nome, renda() 3 : calcula o % de desconto() Por que existe esse envio de informações? O que TelaCadastroCliente precisa fazer? O mesmo vale para as demais 4 : classifica o cliente() 5 : Cria a entidade() 6 : Cadastra a entidade na lista() 20

21 Alocando responsabilidades Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (1º passo); Exemplo das classes com métodos: <<boundary>> TelaCadastroCliente <<control>> ControladorCliente +cadastrar(nome, renda) +cadastrar(nome, renda) +calculadesconto() +classificacliente() <<entity collection>> CadastroClientes <<entity>> Cliente +clientes +cadastrar(nome, renda, desconto, tipo) +nome +renda +desconto 21

22 Identificando Atributos Também é necessário identificar quais os atributos das classes Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade Nesta etapa ainda não precisamos indicar quais os tipos dos atributos 22

23 Diagrama final 23

24 Análise de Casos de Uso (continuação) Outro exemplo Efetuar Login (resumo do caso de uso) Fluxo principal: 1. Usuário informa login e senha 24

25 Análise de Casos de Uso (continuação) Exemplo Que classes preciso criar? uma classe de fronteira para lidar com a interação dos atores com o sistema uma classe de entidade para representar as informações relevantes do aluno uma classe de controle para gerenciar o fluxo de execução do caso de uso 25

26 Análise de Casos de Uso (continuação) Exemplo TelaLogin ControladorLogin Us uario Há diferentes opções de visualização dos estereótipos, por exemplo modo texto: < < boundary > > Tela Login < < c ontrol> > ControladorLogin < < entity > > Us uario 26

27 Análise de Casos de Uso (continuação) Exemplo < < boundary > > Tela Login < < c ontrol> > ControladorLogin < < entity > > Us uario Só teremos um usuário? Onde ficarão armazenados os demais usuários? Que classe será responsável por realizar as tarefas de persistência? 27

28 Análise de Casos de Uso (continuação) Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>> ou <<persistence>> <<boundary>> TelaLogin <<control>> ControladorLogin <<entity collection>> CadastroUsuarios <<entity>> Usuario 28

29 Diagramas de interação Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa. Inicialmente deve-se identificar as informações trocadas entre os elementos identificados durante e categorizados pela método BCE. 29

30 Diagramas de interação Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interação (sequência e colaboração) são muito úteis nesta tarefa : usuário : TelaLogin : Con trolado rlogin : Cadas troalunos efetuarlogin(login, senha) efetuarlogin(login, senha) checar(login, senha) regis trars es sao() 30

31 Alocando responsabilidades Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (1º passo); Exemplo das classes com métodos: <<boundary>> TelaLogin efetuarlogin(login, senha) <<control>> ControladorLogin efetuarlogin(login, senha) registrarsessao() <<entity collec tion>> CadastroUsuarios <<entity>> Usuario checar(login, senha) 31

32 Identificando Atributos Também é necessário identificar quais os atributos das classes Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade Nesta etapa ainda não precisamos indicar quais os tipos dos atributos 32

33 Diagrama final 33

34 Pausa para organizar os elementos: Classe criada para receber a interação <<boundary>> TelaLogin * efetuarlogin(login, senha) 1 Classe criada para controlar interação <<control>> ControladorLogin efetuarlogin(login, senha) registrarsessao() 1 <<entity collection>> 1 CadastroUsuarios checar(login, senha) Classe criada para armazenar (servir de depósito, repositório) de usuários <<entity>> Usuario login senha Conceito do domínio do problema 34

35 Pausa para organizar os elementos: Pacotes Em UML, um pacote é definido como: "Um mecanismo de propósito geral para organizar elementos semanticamente relacionados em grupos." Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de "Conteúdo do pacote". Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos em outros pacotes. InterfaceGrafica Domínio Vejamos um exemplo no StarUML Controladora Persistencia 35

36 Diagrama de Casos de Uso: uma atualização Após a descrição (expansão) de todos os casos de uso, obtemos uma versão final do diagrama de casos de uso, considerando os pontos de inclusão e extensão. uc CasosdeUso Versão inicial do UD uc CasosdeUso Outra versão do UD Cadastrar clientes Cadastrar clientes Cadastrar produtos «extend» Vendedor Cadastrar produtos Vendedor «extend» Efetuar v endas Efetuar v endas Consultar v endas «extend» Gerente Registrar recebimentos Registrar recebimentos Gerente 36

37 Diagrama de Casos de Uso: mais conceitos Pontos de Extensão <<extend>> Início da técnica de Caso de Uso: analistas tinham um problema para acrescentar comportamentos em Casos de Uso que já estavam definidos. Eles imaginavam que seria muito bom se o Caso de Uso definido abrisse uma porta para que os novos comportamentos da evolução do software fossem incorporados. Essa foi a motivação do relacionamento «extend». Um Caso de Uso disponibiliza um ponto de extensão (extension point) que outros Casos de Uso podem observar e de acordo com uma condição, este Caso de Uso que está observando pode assumir o controle e embutir os seus comportamentos. 37

38 Diagrama de Casos de Uso: mais conceitos Pontos de Extensão <<extend>> uc CasosdeUso Cadastrar clientes Cadastrar produtos «extend» Vendedor «extend» Efetuar v endas Consultar v endas «extend» Registrar recebimentos Gerente 38

39 Diagrama de Casos de Uso: mais conceitos Pontos de Inclusão <<include>> O ponto de inclusão é usado quando um caso de uso deve incluir o comportamento do outro. Significa que o caso de uso A inclui o comportamento do caso de uso B. É representada pelo estereótipo <<include>> uc CasosdeUso A «include» B Exemplo: O stakeholder do sistema de pedidos solicitou que exista uma forma de imprimir a segunda via da Venda realizada. Considerando que o caso de uso Efetuar Vendas (já existente) tenha em seu fluxo principal a opção de imprimir a venda que está sendo feita, podese extrair o trecho e criar um caso de uso Imprimir cópia da venda 39

40 Diagrama de Casos de Uso: mais conceitos Pontos de Inclusão <<include>>: O ponto de inclusão é usado quando um caso de uso deve incluir o comportamento do outro. A inclusão sempre é executada. Exemplo: Imagine que o stakeholder do sistema de pedidos solicitou que exista uma forma de imprimir a segunda via da Venda realizada. Considerando que o caso de uso Efetuar Vendas (já existente) tenha em seu fluxo principal a opção de imprimir a venda que está sendo feita, pode-se extrair o trecho e criar um caso de uso Imprimir cópia da venda 40

41 Diagrama de Casos de Uso: mais conceitos Pontos de Inclusão <<include>> O diagrama final ficaria: uc CasosdeUso Cadastrar clientes Cadastrar produtos «extend» Vendedor «extend» Efetuar v endas Consultar v endas «include» «extend» Imprimir cópia da Venda Registrar recebimentos Gerente 41