Olá sejam bem-vindos ao canal in software com ênfase ml Eu sou professor Janes Guedes e eu já trabalho com ml há vários anos eu já publiquei quatro livros sobre o assunto e já ministrei diversas palestras e cursos técnicos sobre modelagem softare com ML na aula de hoje eu pretendo iniciar a falar sobre o diagrama de caso de uso esta vai ser uma aula introdutória haverá um segundo vídeo um pouco mais avançado sobre o assunto e Nesta aula eu pretendo introduzir diagrama de caso de uso e falar sobre alguns conceitos básicos sobre atores casos de uso
e sobre como documentar ess caso de uso Então vamos dar início à nossa aula então como eu falei hoje nós vamos falar sobre diagrama de caso de uso vai ser a primeira parte dessa aula Haverá uma segunda aula com conceitos um pouco mais avançados e exemplos ah como eu falei eu já publiquei quatro livros sobre o assunto Ah então me primeiro livro foi sobre ml uma abordagem prática que tratava exclusivamente sobre ml 1.5 mas já abordava o MR2 no final do livro que ela estava surgindo depois eu lancei o guia de consulta rápida o ml2
era exclusivo sobre essa segunda versão da linguagem em seguida eu lancei o ml2 guia prático e finalmente eu lancei o carro chefe dos meus das minhas publicações que é o em2 uma abordagem prática que se encontra na terceira Edição e eu já estou trabalhando na quarta Edição Esse é o livro mais atualizado e mais completo dos que eu já publiquei Então vamos deixar a propaganda vamos começar a falar sobre o diagrama de caso de uso Então esse diagrama ele é utilizado durante a fase de engenheria de quisitos sobretudo durante as fases de análise de requisitos
e especificação de requisitos Como já falei no meu vídeo anterior a engenheria de requisitos é na minha opinião a fase mais importante da engenharia de softw uma vez que é nela que nós definimos o que precisa ser feito nós compreendemos o problema que precisa ser resolvido Então essa fase precisa ser muito bem feita com muita responsabilidade porque não adianta desenvolver uma solução e Nós não sabemos exatamente qual é o problema a ser solucionado ah durante as fases de análise requisitos os requisitos que foram elicitados que foram levantados na fase de elicitação de requisitos primeira fase
das requisitos eles são melhor detalhados eles são analisados eles são examinados e são gerados requisitos de sistema requisitos com maior profundidade e maior detalhe esses requisitos Eles já passam a fazer parte da especificação de requisitos na verdade análise e especificação se confundem um pouco basicamente a especificação de requisitos é a documentação dos requisitos analisados bom embora o diagrama de caso de uso ele seja produzido durante a fase de Eng requisitos ele costuma ser consultado durante todo o processo de modelagem uma vez que ele é a base da modelagem do softw e ele serve também como
base para diversos diagramas que nós iremos estudar em outras aulas o diagrama de caso de uso ele apresenta uma linguagem simples e de fácil compreensão o objetivo é que quem Leia esses diagramas e a Sua documentação possa ter uma ideia Geral de como o sistema irá se comportar um diagrama de caso de uso identifica os atores que poderão utilizar o software e as funcionalidades que o sistema irá disponibilizar a esses atores atores são essencialmente conjuntos de usuários e as funcionalidades são as funções os serviços que o software oferece aos seus usuários vamos falar um pouquinho
sobre atores Então os atores eles representam os papéis desempenhados pelos usuários que irão utilizar as funcionalidades do sistema Mas por que são chamados de atores ah os atores eles representam grupos de usuários Como já havia falado e eles são chamados de porque esses grupos de usuários eles desempenham papéis na medida que utiliza o software então um usuário ele pode em um determinado momento desempenhar o papel de digitador ou programador e ter acesso a um conjunto de funcionalidades mais limitado em um outro momento ele pode se logar no sistema com permissões de administrador então ele vai
desempenhar um papel mais importante E terá acesso a funcionalidades mais importantes do sistema então por isso que são esse tipo de componente é chamado de ator porque representa um papel do sistema então atores em geral representam grupos de pessoas que interagem com o sistema mas eventualmente e com bastante Raridade eles podem representar um hardware especial ou um software especial que interaja com o sistema mas não é qualquer hardware não é qualquer software é um hard e realmente seja importante pro software realmente transmita informações receba instruções do software para agir e também não é qualquer software
são softwares que tem algum nível de integração com o meu software que interajam com ele de alguma maneira como sistema integrado por exemplo Então os atores no diagrama de cas de uso eles são representados por bonecos Magos que são esses bonequinhos aqui e com o texto abaio deles para identificar qual é o papel que eles representam então Aqui nós temos alguns exemplos gerente funcionário cliente aqui são atores que representam grupos de usuários e aqui embaixo Nós temos dois atores especiais que é o medidor de radiação e o sistema integrado notem que ele possui esse texto
entre entre sinais de maior e menor que tem o a palavra System Isso significa que is é um ator especial no caso que pode representar um hardware ou software especial então is aqui representa um medo de radiação que é um hardware que vai ficar transmitindo informações pro sistema e recebendo instruções dele Ah é um Harder especial porque ele está no local provavelmente distante e no lugar perigoso para vidas humanas então é válido representar este robô como sendo um ator e Aqui nós temos um outro ator especial que representa um software um sistema integrado que vai
interagir com o meu sistema para receber informações out itir informações para ele por isso é válido representar ele como ator mas na maioria das vezes 99% das vezes os atores vão representar grupos de usuários agora como identificar atores bom Então primeiramente deve-se procurar identificar as entidades externas que irão interagir com o sistema em seguida deve agrupar essas entidades que possuam características semelhantes ir utilizar as mesmas funcionalidades do software e possuiram os mesmos níveis de permissão então Elas serão identificadas como um único ator então exemplos desse tipo de entidades ditadores desenvolvedores ou projetistas algumas perguntas que
podem ser feitas para se identificar atores que tipos de usuários poderão utilizar o sistema quais usuários Estão interessados utilizarão quais funcionalidades e serviços do software quem fornecerá informações ao sistema quem utilizará as informações do sistema ainda quem poderá alterar ou mes excluir informações do sistema Existe algum outro software como sistema integrado que irá interagir com o sistema aqui nós estamos tentando identificar softwares especiais que interagem com nosso software Existe algum hardware especial como por exemplo o robô vai interagir com soft aqui nós estamos tentando identificar algum ator que irá representar algum [Música] hard no momento
que eu identifico esses candidatos atores eu preciso listá-los e tentar atribuir responsabilidades e objetivos a esses atores basicamente o que cada ator pretende atingir a utilizar o softw se eu não consigo atribuir io para um ator então dificilmente ele realmente será um ator e deverá ser eliminado Ah agora vamos falar um pouquinho sobre caso de uso casos de uso eles representam as funcionalidades que irão ser utilizados pelos atores um caso de uso ele expressa e documenta um comportamento pretendido para uma funcionalidade através de um ou mais cenários um caso de uso el sempre vai ter
no mínimo um cenário que é o cenário principal mas ele poderá ter cenários alternativos e cenários de sessão existem casos de usos primários e casos de usos secundários casos de usos primários ão representam processos importantes que vão enfocar requisitos funcionais do software enquanto que os casos secundários são casos de uso que se referem a processos não tão importantes processos periféricos como cadastros e relatórios simples em alguns casos Principalmente quando há muitos casos de usos primários os casos de US secundários nem devem ser representados para não deixar o diagrama polu então caso de uso na uml
representado como um elipse contendo um texto dentro dele nas primeiras versões da umr em algumas ferramentas cas antigas o texto vi embaixo da elipse mas atualmente o texto vem dentro da elipse o texto emal tem que tem ser tem que iniciar com verbo no infinitivo e deve ser suscinto deve representar aquela funcionalidade da forma resumida mas Clara Bom os casos de uso eles costumam possuir documentação eles costumam ser documentados então a documentação descreve várias informações e principalmente os cenários que comporão aquele caso de uso mas Além disso uma um caso de uso ele vai representar
ele vai a documentação de caso de uso vai conter o objetivo de o caso de uso as suas possíveis pré-condições as suas possíveis pós condições pré-condições são condições que precisam ser satisfeitas antes que o caso de uso possa ser executado pós condições são condições que passam a valer após o caso de uso ter sido concluído Quais atores irão interagir com o caso de uso deve haver no mínimo um ator podem haver atores secundários mas tem que ha sempre um ator primário e e a descrição passo a passo de cada cenário ã então nessa descrição eu
devo determinar quais ações devem ser executadas pelo ator principal e quais ações devem ser executadas pelo sistema durante a execução do caso de uso ã também devo explicar quais parâmetros devem ser fornecidos e quais restrições e validações o caso de uso deve obedecer eh Existem várias formas de documentar Eh caso de uso eh a documentação ela pode ser mais estruturada ou pode ser por meio de um texto mais líde então nessa aula nós iremos apresentar duas formas de de escrever caso de uso aqui tem a uma forma de documentação de caso de uso mais estruturada
então aqui ele representada a documentação representada por uma tabela ise aqui é um modelo então o primeiro campo é Identificação do caso de uso em geral ele vai ser vai ter um código e o nome do caso de uso a identificação do caso de uso geral isso é um pouco raro tá vai conter o código e o nome do caso de uso geral a partir do do qual este caso de uso atual foi derivado isso não é obrigatório Como eu disse não é muito comum um resumo onde se descreve resumidamente a Aquele caso de uso
se destina Qual é o se ob o ator principal que é o ator que mais interage com esse caso de uso é o único ator obrigatório possíveis atores secundários pode haver algum ator que interaja com o sistema de maneira [Música] secundária fornecendo ou recebendo informações por exemplo isso não é obrigatório podem existir ou não pré-condições nesse Campo vai se descrever as possíveis pré-condições árias para a execução daquele caso de uso isso não é obrigatório pós condições também descreve as possíveis condições que deveriam ser satisfeitas quando o caso de uso fosse encerrado isso também não é
obrigatório em seguida vem o cenário principal é o único cenário que precisa existir ele é dividido em duas partes ações do ator e ações do sistema as ações do ator descrevem cada uma das ações que o ator principal executa no naquele cenário e as ações do sistema são cada uma das ações que o sistema executa normalmente em resposta a alguma ação do ator depois nós descrevemos as regras de negócio restrições e validações vamos descrever cada regra de negócio ou seja como aquele cenário deve ser executado condições que precisam ser validadas regras que precisam ser obedecidas
esse tipo de coisa Ah depois pode haver cenários alternativos isso não é obrigatório Mas podem haver mais de um cenário alternativo também são divididos em ações do ator e ações do sistema um cenário alternativa um cenário que pode ocorrer ou não de acordo com a satisfação de uma condição que não quer dizer que eles sejam raros e depois vem o cenário de sessão que também não são obrigatórios podem existir ou não esse cenário de exceção assim como o cenário alternativo precisa ter um título curto para descrever a condição para que aquele cenário de exão ocorre
e também vai ser dividido em ações de ator e ações sistema então o cenário de exão como nome disz descreve uma exceção algo que precisa ser tratado caso uma ação inválida ocorra bom Aqui nós temos um exemplo de daquela da da do preenchimento desse modelo e um caso de uso real e o Sistema de Controle bancário que representa a abertura de uma conta comum então Aqui nós temos a identificação do caso de uso é o c01 pode o c01 e o título é Abrir conta comum resumo este caso descreve as etapas percorridas por um cliente
intermediado por um funcionário para abrir uma conta corrente comum o ator principal é o funcionário porque é ele que realmente interage com o sistema apesar do interesse maior C do cliente o cliente ele só representa o papel de ator secundário uma vez que ele fornece informações para funcionário pré-condições Nós temos duas nessa situação o cliente precisa possuir um cadastro autualizado e para abrir uma conta corrente é precisa ser maior de idade e as pós condições é necessário realizar um depósito inicial e deve ser emitir o cartão da conta para o cliente aqui nós temos o
cenário principal do caso de uso Abrir conta comum então nós teria dividid em ações de ator e ações do sistema Então primeiramente o funcionário ele solicita abertura de uma conta corrente comum ou seja solicita a execução dessa funcionalidade o sistema em resposta ele solicita a Identificação do cliente por meio do seu CPF o funcionário informa o CPF do cliente o sistema consulta o cliente e solicita comprovante residência oos funcionário fornece o comprovante o sistema solicita a senha da conta o Cliente informa a senha notem queor principal que está atuando então nós temos que especificar que
é o ator secundário o Cliente informa a senha o sistema em resposta abre a conta corrente executo o caso de uso o c08 realizar depósito porque é uma regra de negócio que a ao concluir o a abertura deve se fazer um depósito e esse processo é representado por um outro caso de uso e depois emite o cartão da conta e também uma pós-condição da execução desse caso de uso aqui nós temos as regras de negócios restrições e validações que precisam ser obedecidas e são três no caso o cliente precisa fornecer algum comprovante recente de residência
a 100 pr6 dígitos e o valor depósito é R 5 nós temos um cenário alternativo que se refere à manutenção do cadastro do cliente e basicamente informa que caso o cliente não possua cadastro ou seu cadastro seja desatualizado é necessário executar o caso de uso o c04 gerenciar clientes Então vai ser feita a manutenção do cadastro daquele cliente por meio desse outro caso de uso e nós temos três cenários de sessão cenário de sessão 1 2 e TR cenário de sessão um se refere a situação que o cliente é menor de idade então o sistema
ele tem que informar que o cliente não possui idade mínima para uma conta corrente e deve recusar o pedido de abertura de conta o segundo cenário de sessão se refere à situação que o comprovante de residência á então o sistema el D informar que o comprovante residência inválido e recusar o pedido de abertura da conta e o terceiro cenário de sessão refere a sen inválido a não tem dígito suficiente por exemplo então o sistema Dev informar que o número de da senha inválido e solicitar que outra senha seja escolhida e Aqui nós temos um modelo
textual documentação de caso de uso é uma outra forma de documentação de documentação de caso de uso alguns preferem uma forma estruturada outros preferem uma forma mais textual e Existem várias variações aqui então nós temos um exemplo de de um modelo textual para documentar caso de uso então aqui eh ã primeiramente se coloca o código do caso de uso e o título dele é o mesmo da outra documentação obviamente só tá representado de forma diferente então é o c01 Abrir conta comum o resumo é o mesmo que já foi descrito o ator principal o ator
secundário são os mesmos as prés condições e pós condições são os mesmos as regras de negócio restrições e validações são as mesmas elas só estão sendo representadas de maneira diferente Ah o cenário principal é representado dessa maneira com os passos numerados Então tem que se colocar o funcionário solicita abertur de uma conta corrente comum sistema solicita edicação do cliente com meio de seu CPF funcionário farmac do cliente o sistema consulta o cliente o sistema solicita um comprovante de residência o funcionário fornece comprovante sistema solicita senha da conta o Cliente informa a senha o sistema abre
a conta corrente Sista executa o caso de uso o c08 realizar depósito o sistema emite o cartão da conta E aí nós temos cenários alternativos o meso os mesmos cenários só a forma de descrever os passos é diferente então cenário alternativo se manutenção do C cliente então ele começa com 4 a né porque a partir do Passo 4 que pode ocorrer o cenário alternativo então o cliente não possui cadastro ou seu cadastro desatualizado o sistema executa cas de uso o c04 gerenciar clientes nós temos cenário de exão que se f a também éo passo quatro
tá então o cliente é menor de idade ã então o sistema informa que o cliente não possui idade mínima para abrir uma conta corrente o sistema recusa o pedido de abertur de conta o segundo cenário de sessão se refere a situação em o comprovante de resistência inválido aqui está 6 a porque isso ocorre no Passo seis áo principal né pode anunciar na sessão relativa a ele então o sistema informa comprovante de residência inválido e o sistema recusa o pedido de abertura de conta e no cenário de sessão três se refere a situação de ser inválida
que pode ocorrer no Passo oito cenário principal então o sistema informa que o nú de digitos a 100 válida e o sistema solicita que outra ser ser escolhido bom Como identificar caso de uso deve-se definir a fronteira do sistema basicamente a fronteira do sistema ela define o que está dentro e o que está fora sistema isso é útil para ajudar a definir o escopo do software no escopo do software eu defino Quais são as reais funcionalidades que se referem aqu aquele software e o que está fora do seu escopo que pertence a outros sistemas ainda
que possam ser integrados mas não aquele a fronteira do sistema é muito útil para já para já estabelecer para os stakeholders para os clientes para as partes interessadas o que pertence ao software e o que não pertence a ele tá Para não acontecer de já causar decepção às partes interessadas e para deixar bem claro Qual é o objetivo daquele software Além disso além de definir a fronteira do sistema deve se identificar as funcionalidades necessárias ao software Como já foi falado funcionalidades são as funções e serviços que correspondem aos requisitos funcionais que foram estabelecidos pelas partes
interessadas que são que o software precisa suportar então reitos funcionais já foram faladas na aula anterior basicamente os requisitos funcionais determinam as funcionalidades todos os serviços que o software precisa suportar agora como identificar casos então basicamente identificar caso de uso muitas vezes se confunde com identificar atores é um pouco difícil separar as duas coisas na medida que a gente vai identificando atores A Nós já vamos identificando caso de uso Ahã então uma maneira de auxiliar na identificação das funcionalidades é verificar a lista dos atores que vão compor o sistema e verificar Quais são os objetivos
de cada ator os objetivos de um ator muitas vezes vão corresponder a uma ou mais funcionalidades Ahã também pode ser útil identificar os possíveis eventos externos que afetarão sóa muitas vezes esses eventos fazem com que seja executado uma determinada funcionalidade ou influenciam de alguma maneira no processamento de uma ou mais funcionalidades outra maneira é verificar o conjunto de requisitos funcionais que foram identificados durante a elicitação de requisitos e verificar se cada um desses requisitos eles possuem um caso de uso e determina Qual é o seu comportamento e qual ator ou atores podem utilizá-lo agora como
saber se os casos de uso foram identificados corretamente é muito comum que eh usuários projetistas analistas eh iniciantes na no uso da umr no na utilização de casos de uso come cometam erros básicos identificar casos de uso às vezes eles confundem casos de usos com passos de cenários bom então como nós sabemos se um caso de uso foi realmente identificado corretamente se aquele realmente um caso de uso Bom primeiramente um caso de uso ele costuma ter uma série de passos e uma série de cenários no mínimo um então uma maneira de determinar se uma funcionalidade
é realmente um caso de uso é verificar quais ações vão ser realizados quando aquela funcionalidade for ser executada e eu não consigo identificar as ações que devem ser executadas durante a execução do caso de uso provavelmente ele não é um caso de uso real também ah se o número de passos de um caso de uso for muito pequeno então eu preciso verificar se esse caso de uso realmente ele é um caso de uso real ou seja deveria ser englobado por outro caso de uso acrescentando seus passos as etapas um outro caso de uso ou então
de repente se tornar um cenário alterna desse outro caso de uso como eu falei é muito comum que os iniciantes eles confundam cenários alternativos ou mesmo Passos individuais como casos de usos completos ah Além disso para identificar casos de usos primários que são realmente os casos de usos que importa representar num diagrama de casos de uso deve se verificar se eles realmente agregam valor ao software a ser desenvolvido eles devem representar processos importantes para interessados Se não eles podem ser simples casos de uso secundários como ã cadastro simples ou relatório simples e muitas vezes não
é necessário representá-los porque isso até às vezes até atrapalha no momento que um diagrama de casos de uso ele possui muitos casos de uso representar casos de usos secundários pode tornar o diagrama de casos de uso ã muito difícil de ler muito poluído bom e é isso nós concluímos a nossa primeira parte sobre diagrama de cas de uso logo nós iremos gravar um segundo vídeo sobre outras características do cas de uso como associações inclusões extensões iremos dar alguns exemplos práticos de aplicação desse diagrama eu espero que vocês tenham gostado essa aula e se vocês gostaram
eu gostaria de solicitar que vocês curtam esse vídeo compartilhem e comentem obrigado pela atenção nós nos vemos nos próximos vídeos
