Aula 7 - Modelagem de requisitos em casos de uso

Prévia do material em texto

Disciplina: Projeto de TCC em Sistemas de
Informação
Aula 7: Modelagem de requisitos em casos de uso
Apresentação
Um requisito é tão importante para um sistema que a UML designou casos de uso para representa-los.
Nesta aula, revisaremos os conceitos inerentes ao diagrama de casos de uso, associando casos de uso a funcionalidades do
sistema. Assim sendo você vai desenvolver o diagrama de casos de uso para seu projeto de TCC a partir da lista de
requisitos do sistema de seu TCC e terá desenvolvido um mapa das funcionalidades que o sistema precisa ter para atender
às demandas de seus usuários.
Na sequência, olharemos novamente os formatos para especi�cação textual de casos de uso, para que possa especi�car os
casos de uso de seu diagrama.
Objetivos
Revisar os conceitos de um projeto de TCC;
Construir o diagrama dos casos de uso de seu projeto;
Descrever as formas dos casos de uso.
Diagrama de casos de uso
É um dos mais informais e simples da UML. Sua principal função é apresentar as funcionalidades que o sistema precisa ter. Ele
apresenta os requisitos funcionais do sistema.
O diagrama de casos de uso é um ótimo elemento para a comunicação entre a equipe e os usuários, possibilitando que seus
requisitos possam ser validados junto a eles. Isso assegura que:
• Todos os requisitos funcionais foram identi�cados;
• Quanto aos requisitos identi�cados, o entendimento da equipe de desenvolvimento está correto e corresponde à realidade.
Atenção
Nesse diagrama, não mostramos detalhes de como o sistema realizará suas funcionalidades, pois a visão do caso de uso será
externa do ponto de vista do usuário.
Num diagrama de casos de uso:
Um caso de uso representa um ou mais requisitos. Um requisito pode ser atendido em diferentes casos
de uso.
Elementos do diagrama
1
Atores
2
Casos de uso
3
Relacionamentos entre atores, casos de
uso ou ator e caso de uso
Ator
É algo com comportamento, pois interage diretamente com o sistema. Portanto, é o papel que um agente desempenha. No
diagrama de casos de uso, a representação do ator é a de um boneco chamado de stickman. Vejamos a �gura a seguir:
Um ator pode representar papéis:
• Internos (gerente de compras);
• Externos (cliente e fornecedor).
Um ator também é capaz de representar:
• Setores e departamentos da empresa (contabilidade e contas a pagar);
• Funções desempenhadas na empresa (almoxarifado).
Dispositivos eletrônicos podem ser representados por atores. Exemplos: hardware, servidores ou dispositivos lógicos. Vejamos a
seguir outro exemplo aplicado a sistemas:
Saiba mais
Como identi�car atores?
Identi�car atores pode ser um caminho para os obtermos de um diagrama de casos de uso. Algumas questões podem ajudar
nessa de�nição:
a) Que órgãos, empresas, departamentos, setores ou pessoas usarão o sistema?
b) Quais sistemas e/ou equipamentos poderão comunicar-se com o sistema?
c) Alguém deve ser informado de ocorrências no sistema? Quem?
Casos de uso
Representam, através de elipses, as funcionalidades do sistema.
Prestemos atenção na imagem ilustrativa a seguir. Por se tratar de uma funcionalidade, o nome do caso de uso deve ser
composto de um verbo no in�nitivo + complemento verbal, como, por exemplo, matricular em curso.
Cenários
Um caso de uso é um conjunto de cenários. Um caso de uso descreve uma sequência de ações decorrentes da interação do ator
com o sistema.
Cada sequência de ações é chamada de cenário. Um cenário é uma sequência especí�ca de ações que ilustra o comportamento
de parte do caso de uso.
Os casos de uso possuem sempre um cenário principal, que é a execução do procedimento esperado. Eles podem (ou não)
possuir cenários alternativos com a descrição do comportamento do sistema quando algum passo do cenário principal não
ocorrer como esperado.
Saiba mais
Como identi�car casos de uso?
O segundo passo do procedimento para a construção do diagrama de casos de uso é a identi�cação desses casos, que vão
representar as funcionalidades necessárias ao sistema para atender aos requisitos. Apresentaremos a seguir alguns
questionamentos que podem ajudar na identi�cação dos casos de uso:
1) O que cada ator espera (em termos de funcionalidades) do sistema de forma que ele tenha suas necessidades cobertas?
2) Quais informações o sistema vai produzir? Que funcionalidade(s) vai(ão) sustentar essas informações?
3) O sistema realizará alguma ação que ocorre de forma regular no tempo?
4) Há um caso de uso para atender a cada requisito funcional? Ou seja, todos os requisitos funcionais estão sendo tratados por
algum caso de uso?
Em seguida, poderemos pensar nos casos de uso que não representam um benefício direto para os atores, mas são necessários
para o funcionamento do sistema. Tais casos englobam manutenção de cadastros e de informações provenientes de outros
sistemas.
Relacionamentos (ou associações)
Os possíveis relacionamentos entre os elementos dos diagramas de casos de uso contemplam:
1
Associações entre atores e casos de uso.
2
Generalização/especialização entre atores.
3
Relacionamentos entre casos de uso entre si.
Veja a seguir cada um deles:
Associação entre casos de uso e atores
Único relacionamento possível entre esses dois elementos. É representado por uma linha sólida conectando o ator ao caso de
uso: ator interage com o caso de uso.
A associação está demonstrada na imagem a seguir:
A comunicação é bidirecional: o ator pode informar dados ao caso de uso e, por sua vez,
receber as informações geradas.
Relacionamento entre atores
O único relacionamento possível que pode ocorrer entre atores é a generalização/especialização ilustrada na imagem a seguir.
• Funcionário: Ator generalista;
• Gerente: Ator especializado.
Atenção
Todo gerente também é funcionário (existem características em comum). O que é comum �ca no generalista. O que é especí�co
�ca no respectivo especialista. Pode-se derivar mais de um ator especializado do mesmo ator que o originou (generalista). O ator
geral é o funcionário; o ator especialista, o gerente.
Na imagem a seguir, em que apresentamos um diagrama de casos de uso, podemos observar o uso da
generalização/especialização, cujo ator generalista (usuário) sustenta dois atores especializados:
• Aluno;
• Atendente.
O diagrama mostra que atendente faz algo a mais que outro usuário. Apenas esse atendente
pode cancelar matrícula em curso. Todos os atores podem se relacionar com os três demais
casos de uso.
Possíveis relacionamentos entre os casos de uso
Há três possíveis relacionamentos:
1
Inclusão
2
Extensão
3
Generalização
Eles são percebidos, na maioria das vezes, quando formos especi�car textualmente o que acontece no interior do caso de uso.
1. Inclusão
Representada no diagrama de casos de uso como o estereótipo <<include>>. Ela denota que um caso de uso principal incorpora
obrigatoriamente o comportamento de outro caso de uso incluído. Este caso é um pedaço daquele.
Dica
A separação - extrair o caso de uso incluído de dentro do principal - possibilita o reuso. Não é sempre o objetivo: muitas vezes, a
�nalidade da separação é isolar um comportamento de uma parte relevante da lógica do caso de uso que nem sempre será
reutilizada.
No diagrama ilustrado a seguir, o caso de uso validar disciplina representa um comportamento compartilhado por dois casos de
uso: incluir disciplina e eliminar disciplina. O comportamento de validar disciplina é incorporado obrigatoriamente a esses dois
casos de uso. Em algum ponto da especi�cação textual de ambos, será reportado esse uso ao comportamento do caso de uso
comum: validar disciplina.
2. Extensão
Representada pelo estereótipo <<extend>>, possibilita a expressão de cenários opcionais de um caso de uso. Cada cenário
opcional seria uma variação do comportamento esperado do caso de uso.
Hipoteticamente, um caso de uso B estende o caso de uso A quando, opcionalmente, algum evento desviar A do seu
comportamento esperado e incorporar o comportamento de B. A interrupção é feita no chamado ponto de extensão. A imagem aseguir caracteriza o uso do relacionamento de extensão:
Na imagem a seguir, o diagrama descreve que o caso de uso enviar informe de dívida estende o caso cancelar matrícula em curso.
Atenção
Esse caso poderá opcionalmente incorporar o comportamento do caso enviar informe de dívida em detrimento de uma condição.
O caso de uso estendido será incorporado se - e somente se - o cancelamento do curso implicar em dívida do aluno.
A imagem a seguir ilustra o uso do relacionamento de extensão (<<extend>>) para o caso de uso pagar mensalidade.
Ao pagar mensalidade, o caso de uso pode assumir, de forma excludente, dois
comportamentos distintos conforme a forma de pagamento usada: pagar em cheque ou
pagar em cartão.
3. Generalização/especialização
Representado por linha e seta sólidas apontando para o caso de uso generalizado, usado para representar casos de uso com
comportamentos parecidos (caso de uso comum), embora eles tenham algumas especi�cidades (caso de uso especializado).
Tem similaridades com o relacionamento de extensão (extend), que é o mais usado.
Observe o exemplo a seguir da especialização do caso de uso aplicar em fundos, que pode ser pré ou pós �xado conforme
modalidade de pagamento da rentabilidade. De acordo com a modalidade, o comportamento do caso de uso vai variar, porém
existem partes comuns especi�cadas em aplicar em fundos (caso mais geral).
A especi�cação textual de casos de uso
Olhando para um diagrama de casos de uso, somos incapazes de saber exatamente o comportamento de cada um deles. A UML
não determina nada nesse sentido, deixando seu uso livre no texto narrativo que descreve o comportamento do caso.
Em geral, será a empresa desenvolvedora que determinará o formato da especi�cação textual do caso de uso.
Os formatos para especi�car casos de uso
Autores apontam três formatos para descrever as especi�cações textuais dos casos de uso:
• Resumido ;
• Informal;
• Completo .
1
2
http://estacio.webaula.com.br/cursos/don054/aula7.html
http://estacio.webaula.com.br/cursos/don054/aula7.html
Atenção
Em nosso projeto de TCC, usaremos o completo.
A descrição textual do caso de uso descreve o seu comportamento, incluindo a interação com ator e relacionamento entre os
casos. O trecho de caso de uso a seguir serve de pano de fundo para exempli�car os dois formatos de especi�cação mais
usados: resumido e completo.
Resumido
Caso de uso: registrar venda
O cliente chega em um ponto de pagamento da loja com os itens que deseja adquirir. O caixa registra cada item desejado. Ao �nal,
o sistema apresenta o total a pagar e a relação de itens comprados. O cliente informa, e o caixa registra os dados do pagamento,
que são validados e registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras e sai com os
itens adquiridos. (OLIVEIRA, s/d)
Completo
Vários gabaritos e padrões de formatos estão disponíveis para casos de uso relevantes que precisarem de especi�cações
detalhadas. Descreveremos a seguir as principais seções que compõem este formato.
Seção da especificação Significado
Nome do caso de uso (*) Verbo no infinitivo + complemento verbal
Escopo (*) O nome do sistema/projeto
Atores (*) Atores envolvidos: principal e secundários.
Precondição (*) O que precisa ser verdade para esse caso de uso acontecer.
Pós-condição ou garantia de
sucesso (*)
O que precisa ser verdade quando da finalização bem-sucedida desse caso de uso
Cenário principal (*) O cenário de sucesso, um caminho típico, é incondicional. O caso de uso se concentra no cenário
principal.
Cenários alternativos ou
extensões (*)
• Cenários alternativos quando o cenário principal tiver uma variação do fluxo bem-sucedido.
• A especificação deve indicar o ponto em que se estende o cenário principal (ou típico).
• A especificação deve indicar o ponto em que se retorna ao cenário principal (ou típico) ou em que se
encerra o caso de uso.
Requisitos especiais Requisitos não funcionais relacionados.
Nome do caso de uso: Registrar venda;
Escopo: Sistema de vendas – PDV;
Nível: Usuário;
Atores: Caixa.
Clique nos botões para ver as informações.
• Todos os produtos registrados no sistema e com respectivos preços;
• Caixa autenticado;
• PDF registrado.
Precondição 
• Venda salva;
• Impostos calculados;
• Estoques atualizados;
• Autorizações de pagamento registradas;
• Recibo gerado.
Pós-condições 
1. Cliente chega ao PDV com os itens que deseja adquirir.
2. Caixa inicia uma nova venda.
3. Para cada item de venda do cliente, faça:
    a) Caixa insere o identi�cador do item.
    b) Sistema localiza o item.
    c) Sistema registra e apresenta a linha do item de venda, com identi�cador, nome e valor unitário do produto.
    d) Sistema calcula os impostos do item.
4. Sistema apresenta o valor total da venda com impostos calculados.
5. Caixa informa o pagamento do cliente.
6. Sistema registra e trata o pagamento do cliente.
7. Sistema �naliza venda e apresenta o recibo dela.
8. Sistema contabiliza a baixa no estoque de cada item vendido.
Fonte: (OLIVEIRA, s/d)
Cenário principal (ou �uxo básico) 
3.a. Sistema não localiza o identi�cador do item.
    1. Sistema avisa o erro e rejeita a entrada.
    2. Sistema retorna ao passo 3.a do cenário principal.
  6.a. Pagamento em dinheiro.
    1. Caixa insere quantia do dinheiro fornecida.
    2. Sistema apresenta valor do troco e libera gaveta do dinheiro.
    3. Caixa deposita dinheiro fornecido e entrega troco ao cliente.
    4. Sistema registra pagamento em dinheiro.
  6.b. Pagamento com cartão de crédito.
    1. Caixa insere dados do cartão do cliente.
    2. Sistema mostra o pagamento para con�rmação.
    3. Caixa con�rma o pagamento.
    4. Sistema envia solicitação de autorização de pagamento à administradora do cartão do cliente.
4.a. Sistema detecta falha ao tentar se comunicar com sistema externo.
    1. Sistema avisa do erro ao caixa.
    2. Caixa solicita ao cliente forma de pagamento alternativa.
    5. Sistema recebe aprovação de pagamento.
    6. Sistema registra o pagamento com cartão de crédito.
Cenários alternativos (extensões) 
1. Interface de usuário com tela sensível a toque em um monitor de tela plana com pelo menos 23 polegadas.
2. Resposta de autorização de crédito, dentro de 30 segundos, em 90% dos casos.
3. A recuperação de falhas de servidores devem ser consistente e robusta.
Fonte: (OLIVEIRA, s/d)
Requisitos especiais 
Atenção
Observe que cada passo do cenário principal é numerado e que em cada um pode haver uma ou mais falhas (insucessos). 
Nos cenários alternativos, temos um número e uma letra. Exemplo: no passo 2 do cenário principal (caixa inicia uma nova venda),
pode haver uma exceção (sistema não inicia) tratada no cenário alternativo como 2.a.).
Prtanto, (a) é a primeira alternativa do passo 2. 
Já o passo 7 (sistema registra e trata o pagamento do cliente) possui dois cenários alternativos: 7.a (pagamento em dinheiro) e 7.b
(pagamento em cartão de crédito). 
Caso tívessemos uma terceira forma de pagamento, como, por exemplo, cheque, ela seria o passo 7.c dos cenários alternativos.
Repare na quantidade de detalhes dessa especi�cação. Nesse formato, devem ser consideradas todas as possiblidades de
exceção e insucesso em relação a cada passo do cenário principal. A especi�cacão de caso de uso acima descrita poderia ter
muito mais detalhes, como, por exemplo, o tratamento das seguintes exceções: 
• A qualquer momento, o sistema falha; 
• Tratamento de outras formas de pagamento (cheque e débito); 
• Caixa cancela o pagamento.
Esse detalhamento vai depender do sistema e da necessidade.
Como especi�car Casos de uso que contenham <Include>
Considere o trecho de diagrama a seguir de um sistema de locadora para aluguel de DVD cujos dependentes podem ser incluídos
e eliminados do plano de sociedade com a locadora. Observe que existe um caso comum a ambos: pesquisar dependente. A partir
da especi�cação de um deles (incluir dependente), entenderemos como se dá o uso do <include>.
Especi�caçãodo caso incluir dependente:
Clique nos botões para ver as informações.
1. Atendente informa identi�cação do cliente.
2. Sistema localiza dados do cliente informado.
3. Atendente informa dados do dependente.
4. Sistema localiza dados do dependente informado – <<include pesquisar dependente>>.
5. Sistema registra dados do dependente do cliente informado.
Cenário principal 
2.a. Cliente não localizado.
- Sistema informa cliente não registrado no sistema e retorna ao passo 1 do cenário principal.
    4.a. Dependente Já registrado.
- Sistema informa dependente já registrado no sistema e retorna ao passo 3 do cenário principal.
Fonte: (OLIVEIRA, s/d)
Cenários alternativos 
A inclusão do caso pesquisar dependente ocorre no passo 4 do cenário principal. Nesse momento, ocorre a interrupção na
execução do caso incluir dependente, e o �uxo desvia para a execução do caso pesquisar dependente. Ao �nal desse caso de uso,
o �uxo retorna para o cenário principal de incluir dependente no passo seguinte ao da inclusão do caso de uso (passo 5).
Como especi�car Casos de Uso que contenham <Extends>
Observe o diagrama a seguir que usaremos para explicar como são especi�cados os casos de extensão (<extends>). Temos 3
extends no diagrama, porém 2 deles estão relacionados entre si e o terceiro, não. O caso de uso calcular multa será usado se - e
apenas se - a entrega estiver sendo feita com atraso. Já os casos de uso pagar em dinheiro e pagar em cheque são mutuamente
exclusivos: apenas um deles será executado de acordo com a forma de pagamento (condição) escolhida pelo cliente.
Especi�caremos a seguir o caso registrar devolução de DVD, mostrando como declarar o uso de casos de extensão:
Solução 
Caso de uso: Registrar devolução de DVD
Cenário principal
  1. Atendente informa identi�cação da mídia.
2. Sistema localiza locação com a mídia informada.
3. Sistema apresenta registro da locação com valor pagar.
4. Atendente informa forma de pagamento.
5. Caso forma de pagamento seja: 
• Dinheiro: <extends PAGAR EM DINHEIRO>; 
• Cartão: <extends PAGAR no CARTÃO>.
Fim-caso.
6. Sistema registra devolução.
7. Sistema emite recibo de quitação do pagamento.
Cenários alternativos
  1.a. Mídia não localizada.
- Sistema informa mídia não registrada no sistema ou não
alugada. 
- Retorna ao passo 1 do cenário principal.
2.a. Locação não localizada (inconsistência de dados).
- Sistema informa “Locação não registrada para a mídia no
sistema” e encerra caso de uso.
2.b. Se data corrente > data prevista de devolução. Então
deve-se calcular multa <Extends CALCULAR MULTA POR
ATRASO>>.
Fonte: (OLIVEIRA, s/d)
Para haver uma melhor visualização, destacamos em negrito as chamadas aos casos de
extends. No cenário principal, opcionalmente usamos pagar em dinheiro ou pagar em cartão.
Já nos cenários alternativos, condicionalmente, usamos calcular multa por atraso.
Considerações �nais sobre especi�cações
Temos algumas dicas sobre especi�cações de casos de uso.
1
Não use detalhes de implementação ou de determinada tecnologia em suas especi�cações.
• A tecnologia �cará obsoleta, e seu caso de uso terá de ser revisto.
• Evite, por exemplo, descrever como: Usuário insere o seu cartão. Em vez disso, use: Usuário informa dados da agencia,
conta e senha de acesso.
2
Procure não associar casos de uso a telas de sistemas (nesse momento).
• Procure evitar essa prática, pois, no momento em que estivermos especi�cando os casos de uso, ainda é cedo para
pensarmos em interface, que será objeto da fase de projeto do sistema.
3
Os casos de uso incluídos (chamados de <include>) ou estendidos (chamados de <extends>) também devem ter
descrição textual, podendo ser no formato resumido ou informal.
4
Quando um passo for muito complicado, ele poderá vir a ser um novo caso de uso que se relacionará com o caso original
pelo esteriótipo <include>.
Atividade
1. Com base na lista de 10 requisitos funcionais, elabore o diagrama de casos de uso.
RF1 - O coordenador pode inserir, alterar ou excluir pessoa jurídica.
RF2 - O coordenador pode inserir, alterar ou excluir pessoa física.
RF3 - O coordenador pode solicitar passagem aérea.
RF4 - O coordenador pode solicitar viagem.
RF5 - O coordenador pode solicitar suprimentos.
RF6 - O coordenador pode solicitar recursos ao projeto.
RF7 - O avaliador pode aprovar ou não as solicitações pendentes.
RF8 - O software pode enviar e-mail aos solicitantes e coordenadores sobre aprovação de suas solicitações.
RF9 - O software deve permitir que as solicitações sejam impressas a qualquer momento e em qualquer status pelos
coordenadores.
RF10 - Os coordenadores podem consultar o status das solicitações.
2. Procedimento de emprestar DVD de uma locadora de DVD:
O cliente escolhe os DVDs que pretende alugar e os entrega ao caixa. O caixa solicita ao cliente sua identi�cação (CPF ou
telefone). Ele informa sua identi�cação, e o sistema veri�ca se o cliente está devidamente cadastrado. Estando cadastrado, o
caixa informa o ID de cada DVD a ser alugado. O sistema veri�ca se o ID está devidamente cadastrado e mostra o nome desse
DVD com o respectivo preço de locação. Ao �nal do registro de todos os DVDs, con�rma a locação. O sistema, nesse momento,
registra a locação dos DVDs informados e imprime o recibo de locação com o valor que deve ser pago no ato da devolução. Caso
o DVD informado para locação não esteja cadastrado, deve ser tratado pelo sistema, emitindo mensagem de erro. Da mesma
forma que a identi�cação do cliente não cadastrado.
3. Avalie as assertivas a seguir no que concerne aos relacionamentos possíveis em diagrama de casos de uso.
I. Atores podem ser especializados. Nesse caso, o ator especializado �ca responsável pelo comportamento comum.
II. Casos de uso podem ser estendidos, denotando um comportamento obrigatório entre eles.
III. Casos de uso não podem ser especializados.
IV. No relacionamento de inclusão, o caso de uso de inclusão é obrigatoriamente incorporado ao caso de uso principal.
Assinale a única alternativa que apresenta apenas as assertivas corretas.
a) I, II, III e IV
b) Apenas I e IV
c) Apenas IV
d) Apenas II e III
e) Apenas II e IV
Notas
Resumido 1
Contém apenas o cenário principal, o cenário de sucesso. Em geral, é usado na fase inicial de identi�cação de requisitos e/ou em
casos de uso mais simples.
Completo 2
Contém não apenas o cenário principal como também os alternativos, complementando a especi�cação com elementos que
de�nam, por exemplo, pré e pós condições. Usado para especi�cação textual de caso de uso com lógica complexa e/ou com
comportamento relevante do negócio.
Referências
LARMAN, C. Utilizando UML e padrões? Uma introdução à análise e ao projeto orientados a objetos e ao processo uni�cado. 3.
ed. Porto Alegre: Artmed, 2007.
BOOCH G ; JACOBSON I ; RUMBAUGH J UML guia do usuário 2 ed Rio de Janeiro: Elsevier 2005
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2005.
FOWLER, M. UML essencial - um breve guia para a linguagem-padrão. 3. ed. Porto Alegre: Artmed, 2005.
OLIVEIRA, M. V. de. Modelagem de sistemas. Aula 3 (PPT). Rio de Janeiro: Unesa, s/d.
WAZLAWICK, R. S. Metodologia de pesquisa para ciência da computação. Rio de Janeiro: Elsevier, 2008.
Próxima aula
Revisão dos conceitos inerentes ao diagrama de classes;
Desenvolvimento do diagrama conceitual de classes.
Explore mais
Para complementar os assuntos estudados nesta aula, não deixe de acessar os materiais indicados:
O que é UML <https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408> ;
Modelagem de sistemas <https://www.devmedia.com.br/modelagem-de-sistemas-atraves-de-uml-uma-visao-geral/27913> ;
Site o�cial de UML <//www.uml.org/> .
https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
https://www.devmedia.com.br/modelagem-de-sistemas-atraves-de-uml-uma-visao-geral/27913
http://www.uml.org/