#09 - Modelagem de Sistemas (2) - Diagrama de Casos de Uso

E aí [Música] o Olá nesse vídeo trataremos na modelagem de caso de uso tendo contato com seus principais conceitos e conhecendo o seu diagrama da uml primeiramente Vamos retomar as frases genéricas desenvolvimento de um software para entendermos que a modelagem de casos de uso está dentro da fase genérica de definição na atividade de análise de requisitos onde definir o que o sistema deve fazer e A modelagem funcional tem duas questões a serem respondidas a primeira delas diz quais serão as funcionalidades do Futuro sistema a resposta disso são os casos de uso em seguida Quem fará

uso dessas funcionalidades cuja a resposta são os atores bons entender um pouco mais disso o modelo de casos de uso é uma representação das funcionalidades e externamente observar bem o sistema e dos elementos externos aos sistemas que interagem com ele é um modelo de análise que representa um refinamento dos requisitos funcionais do sistema em desenvolvimento e direciona diversas tarefas posteriores o processo de desenvolvimento e o diagrama de caso de uso procura possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa com algum conhecimento sobre o problema enfocado tentando apresentar o sistema por intermédio de

uma perspectiva dos usuários esse diagrama tem por objetivo apresentar uma visão externa Geral das funcionalidades que o sistema deverá oferecer aos usuários sem se preocupar em profundidade com a questão de como Tais funcionalidades serão implementadas e vamos conhecer a estrutura básica de um diagrama uml para casos de uso diagrama de caso de uso basicamente é formado pelo ator que é quem usa o sistema pelo caso multiuso que representa a funcionalidade e pelo relacionamento que associa o ator é um caso de uso é um ator é qualquer elemento externo ao sistema que interage com ele ele

não faz parte do sistema troca informações Com sistema e corresponde a um papel representado em relação ao futuro sistema implementado um ator pode ser de vários tipos o mais comum são os cargos por exemplo vendedor atendente farmacêutica professora gerente um ator também pode ser uma representação de um setor por exemplo setor de pagamento setor de atendimento diretoria secretaria dentre outros Nesse contexto vale destacarmos uma diferença por exemplo o setor secretaria não é a mesma representação de secretária quando o ator é secretária estamos dizendo que todos os usuários que tiverem o perfil de secretário terão acesso

ao sistema e quando o ator é uma secretaria envolve mais cargos Ou seja todos que estiverem lotados no setor secretaria acessaram o sistema podem ser estagiário pode ser atendente Inclusive a secretária é uma representação mais abrangente é um ator também pode ser sistema por exemplo sistema de faturamento sistema de RH sistema de segurança ou ainda equipamentos que internamente irão interagir com o sistema por exemplo servidor web ou uma central de comunicação é um ator pode participar de vários casos de uso ele pode ser um ator primário Ou seja aquele que interage diretamente com sistema por

exemplo um setor de atendimento um atendente ou um ator secundário que auxilia os atores primários na utilização do sistema por exemplo um servidor web e não ml os atores são representados por símbolos e bonecos magros ou stickmen contendo Uma Breve descrição logo abaixo do seu símbolo que identifica o papel que o ator em questão assume dentro do diagrama nesse exemplo temos os atores gerente usuário cliente e aluno que representam papéis RH que representam o setor e sistema integrado que representa a software em todo o nome de ator é um substantivo que identifica o seu papel

diante do sistema se identificando atores por definição um ator é todo elemento externo que interage com o sistema Nesse contexto fontes e destinos as informações a serem processadas são atores em potencial assim o analista deve verificar as áreas da empresa que serão afetadas ou utilizaram o sistema e as fontes de informações a serem processadas e Os destinos das informações geradas pelos sistemas Guedes nos apresenta algumas perguntas úteis esse processo de identificação de atores vamos a elas que órgãos ou empresas Ou pessoas irão utilizar o sistema que tipos de usuários poderão utilizar o sistema quais usuários

Estão interessados ou utilizaram quais funcionalidades e serviços do software quem está interessado em um certo requisito funcional do sistema e quem fornecerá informações ao sistema quem utilizará as informações do sistema quem poderá alterar ou mesmo excluir informações outros softwares irão se comunicar com o sistema Ah e por fim Existe algum rádio especial que interagirá com o sistema retornando a nossa exemplo da Rádio quais seriam os potenciais atores no sistema nós temos aqui setores e Cargos é aqui que não analista de sistemas irá considerar as possibilidades Então nesse caso nós podemos ter como atores o setor

de atendimento o setor financeiro ou os cargos recepcionista telefonista administrador contador e auxiliar administrativo e vamos agora os casos de uso de acordo com Bezerra casos de uso referem-se a serviços tarefas ou funções expressam e Documento o comportamento pretendido para as funções é a especificação de uma sequência completa de interações entre o sistema e os agentes externos e não revelo a estrutura e o comportamento externo do sistema e não ml os casos de uso são representados por elipses com os nomes dentro ou abaixo delas representando a funcionalidade é importante prestarmos atenção no padrão do nome

do caso de uso que é sempre formado por um verbo no infinitivo mais um complemento nesse caso temos como exemplo efetuar matrícula registrar compra Cancelar pedido e efetuar a autenticação é a função de um caso de uso é mostrar o que deve ser feito e não como deve ser feito este diagrama deve ser o mais simples possível porém completo bom e como podemos identificar casos de uso tenta porém Guedes 2018 é importante verificar os objetivos de cada ator identificar os eventos externos que afetaram software verificar a lista de requisitos funcionais verificar quais ações seriam realizadas

quando o caso de uso fosse executado e verificar se o caso não poderia ser englobado por outro nós temos também algumas perguntas úteis nesse processo Quais são as necessidades e objetivos de cada ator em relação ao sistema que informações do sistema deve produzir o sistema deve realizar alguma ação que ocorre regularmente do tempo para cada requisito funcional existe um ou mais casos de uso para atendê-lo e vamos a um exemplo nós temos aqui um requisito funcional que diz o sistema deve permitir a autenticação de usuários o pequeno diagrama de caso de uso seria esse o

ator usuário e o caso de uso efetuar a autenticação que atende a esse requisito funcional e vamos falar agora sobre os relacionamentos caso de uso e atores não existem sozinhos além desses últimos o modelo de casos de uso possui um terceiro componente cuja função é relacionar os atores e casos de uso esse componente corresponde aos relacionamentos sendo assim um ator deve estar relacionado a um ou mais casos de uso Além disso pode haver relacionamentos entre casos de uso ou entre atores e um sistema É nesse contexto ao ml definir os seguintes relacionamentos para o modelo

de casos de uso a comunicação a inclusão a extensão EA generalização os significados e notação gráfica desse relacionamento e serão discutidos a partir de agora e o relacionamento de comunicação É de longe o mais comumente utilizado de todos os relacionamentos ele informa aqui caso de uso o ator está associado o fato de um ator está associado a um caso de uso através de um relacionamento de comunicação significa que esse ator interage ou seja troca informações com sistema por meio daquele caso de uso vejamos um exemplo aqui nós temos um ator usuário que se comunica com

caso de uso reservar livro Isso significa que atores do tipo usuário poderão Executar a operação reservar livro simples né e o relacionamento de inclusão existe somente entre casos de uso é utilizado quando existe uma situação comum a mais um caso de uso semelhante a ideia do uso de rotinas das linguagens de programação e é um relacionamento que indica uma obrigatoriedade ou seja durante a execução de um caso é obrigatória a execução de outro vejamos um exemplo aqui nós temos um ator cliente que se comunica com caso de uso efetuar compra ou seja ele pode realizar

essa operação ao mesmo tempo o caso de uso efetuar compra inclui o caso de uso efetuar o pagamento Isso significa que durante o efetuar compra em algum momento é obrigatório executado efetuar o pagamento não há como efetuar uma compra sem que se efetue o seu pagamento e vamos analisar agora algumas propriedades gerais e um relacionamento de inclusão temos aqui um diagrama genérico de casos de uso no Qual o ator se comunica com caso de uso a que por sua vez inclui um caso de uso B vamos ver o que isso significa o caso a inclui

ou usa o caso B ou seja durante o caso a ocorre o caso b o caso a não é completo sem o caso B Isso significa que não há como realizar o caso de usuário sem que em algum momento caso de uso B seja executado o caso de uso B pode ser usado por vários casos de uso semelhante a ideia de chamadas de rotina na linguagem de programação o caso B pode ser então incluído por outros casos além do caso a é o caso b não sabe por qual caso de uso está sendo usado assim

como nas chamadas de rotina na programação e agora o mais importante no diagrama de casos de uso da uml quem usa aponta para quem é usado o que significa no o caso a aponta para o caso B nesse exemplo isso nós podemos verificar pela direção da seta significando que o caso a Obrigatoriamente executa o b caso fosse o contrário a direção da seta também deveria mudar Pois é ela que indica quem usa quem dentro do diagrama e nunca se esqueçam disso ok e vamos ver um exemplo mais prático Aqui nós temos o trecho de um

diagrama da uml que traz um ator cliente que se comunica com casos de uso efetuar compra e consultar compra ou seja ele pode executar essas operações o caso de uso efetuar compra por sua vez inclui os casos de uso emitir comprovante efetuar pagamento e efetuar a autenticação ou seja durante a efetuar compra é obrigatório que em algum momento ocorra o emitiu comprovante o efetuar pagamento e o efetuar a indicação o diagrama não indica em qual ordem nem qual momento esses casos serão executados apenas que o seu uso é obrigatório durante a efetuar compra nós temos

também o caso de uso consultar compra que inclui o caso de uso efetuar a autenticação ou seja durante o consultar compra em algum momento será obrigatório efetuar a autenticação perceba aqui que o caso de uso efetuar a autenticação é uma inclusive tanto de efetuar compra quanto de consultar compra e agora é hora de verificarmos se você realmente entendeu as principais características do relacionamento de inclusão para isso preparamos uma pequena atividade baseada no diagrama genérico de casos de uso temos aqui um diagrama com dois atores e cinco casos de usos caso a caso B caso c

d e e e teremos algumas perguntas cuja resposta é sim ou não para cada pergunta pause o vídeo Analise a situação e verifique se a resposta é sim ou não em seguida nós daremos a resposta vamos lá a primeira pergunta diz o seguinte durante o caso de ser é obrigatório caso a E aí e vamos verificar a relação que existe entre o caso cê e o caso a temos aqui no diagrama um relacionamento de inclusão de ser para a porque afirmamos isso pela direção da seta Lembrando que quem usa aponta para quem é usado ou

seja se a direção da seta vai descer parar nós podemos afirmar que durante o caso você sempre ocorrerá o caso ar porque temos um relacionamento de inclusão logo a resposta parece a pergunta é sim durante o casos e é obrigatório que ocorra o caso a a próxima pergunta o caso B é executado tanto pelo caso a quanto pelo caso e e pense um pouco e vamos analisar os relacionamentos também entre os casos envolvidos na pergunta quando olhamos para o caso aí o caso B verificamos que existe um relacionamento de inclusão de a para B logo

durante o caso a Obrigatoriamente deve ocorrer o caso B e quando analisamos a relação entre o caso e e B também vemos que temos um relacionamento de inclusão de para ver logo durante o caso e é obrigatório que ocorra o caso B analisando então a situação podemos afirmar que o caso B executado tanto pelo caso a quanto pelo caso e e Obrigatoriamente logo a resposta para essa pergunta também é sim E aí a próxima pergunta durante o caso B é obrigatório que ocorra o caso a e o caso e Oi e aí o que você

acha E para isso vamos olhar novamente os relacionamentos quando nós olhamos para o caso a b e e nós voltamos ao relacionamento de inclusão porém temos que olhar sempre para a direção da seta porque quem usa aponta para quem é usado se nós temos um relação uma relação de a para b e d e para B nós não podemos afirmar que durante o caso B obrigatório que eu corro a e o e é o contrário é isso que diz a direção das setas logo a resposta para essa pergunta é não durante o caso b não

é obrigatório que ocorra o caso ar e o caso ele Ah e por fim durante o caso você é obrigatório caso B vamos analisar olhando para o diagrama você pode dizer Ué não existe relação entre si e b não tem como essa resposta ser sim mas vamos olhar com mais cuidado primeiramente vamos analisar a relação que existe entre o caso cê e o caso a Como já vimos existe um relacionamento de inclusão de Separa então durante o caso você sempre ocorrerá o caso de uso a quando olhamos a relação que existe entre o caso a

e o caso B também percebemos uma inclusive Como já verificamos as questões anteriores então durante o casuar é obrigatório que ocorre o b horas se durante o casos e sempre ocorre o caso a E durante o a sempre vai ocorrer o caso B nós podemos afirmar que durante o caso você é obrigatório que ocorra o caso B dados relacionamento de inclusão logo a resposta para essa pergunta é sim e eu só análise um pouco mais veja novas situações para que você reforça os conceitos sobre o relacionamento de inclusão E aí e vamos agora conhecer o

relacionamento de extensão ou ex tende a extensão é usada quando se tem uma sequência opcional de eventos e se deseja incluir no caso de uso indica a necessidade de uma condição Para que ocorra e representa a situações que não ocorrem sempre ou seja durante um caso de uso pode ser necessário executar outro vamos ilustrar um pouco temos aqui um pequeno diagrama com ator vendedor que se comunica com o caso de uso efetuar venda e o caso de uso efetuar venda tem uma extenção com o caso de uso cadastrar cliente logo podemos afirmar que durante o

caso de uso efetuar venda pode ser necessário cadastrar cliente isso depende de uma condição no caso aqui podemos afirmar que durante uma venda caso o cliente não tem ainda realizado um cadastro na loja ou no mercado por exemplo é necessário realizar o cadastrar cliente e vamos analisar agora algumas propriedades o relacionamento de extensão considere dois casos de uso a e b um relacionamento de extensão de a para B indica que um ou mais os cenários tb podem incluir o comportamento especificado por a nesse caso disse que P estendi ar o caso de uso ar é

chamado de estendido e o caso de uso B de extensor assim podemos afirmar que o caso a pode ou não executar o caso b o caso B só é executado quando o caso a precisa dele e é necessário que uma condição seja satisfeita no caso a para que o caso B seja executado e agora o mais importante no diagrama da uml temos a seguinte propriedade quem estende a ponta para quem é estendido ou seja se nesse exemplo temos o caso B apontando para o caso a com o e nós fizemos que durante o caso a

pode ser necessário executar o b&b estende a um pouco confuso né mas com o tempo você se acostuma ao ml e assim mesmo e vamos ilustrar um pouco mais a extensão considere uma interface de autenticação de usuário na qual o usuário deve informar o seu nome de usuário EA sua senha e confirmar o seu acesso de vez em quando o usuário esquece o seu acesso isso já aconteceu com todos não é mesmo quando isso acontece é importante que o usuário tenha condições de recuperar o seu acesso se representarmos isso com diagrama de casos de uso

nós temos a seguinte representação temos um ator usuário se comunica com efetuar a autenticação e nós temos o recuperar acesso que é um caso de uso que estende o efetuar autenticação isso é indicado pela direção da seta então é correto afirmar mos que durante a efetuar a autenticação pode ser necessário recuperar acesso e com mais um exemplo temos aqui parte da interface do sistema acadêmico do IFMS quando o professor entra no seu diário de classe ele tem algumas funcionalidades a sua disposição como registro de frequências conteúdo avaliações notas planos de ensino impressão e o fechamento

do diário se nós se apresentarmos isso com diagrama de caso de uso podemos ser a seguinte representação temos um ator professor que se comunica com caso de uso editar diário e esse caso de uso possui várias opções representadas por I existentes Então temos aqui durante o editar diário Pode ser que o professor vai registrar frequência cadastrar conteúdos editar avaliações editar notas cadastrar plano de ensino imprimir documentos ou fechar o diário e o relacionamento de extensão é muito interessante quando quando nós queremos representar opções dentro de uma funcionalidade E chegou a hora de testarmos os seus

conhecimentos sobre o relacionamento de extensão para isso preparamos mais uma atividade trazendo um diagrama e algumas perguntas cuja resposta pode ser sim ou não antes de ouvir a nossa explicação para cada pergunta pause o vídeo Analise a situação e tenta encontrar a sua resposta vamos lá primeira pergunta durante o caso F é obrigatório executar o casos e vamos analisar o relacionamento entre esses casos de uso entre o caso efe o casos e existe um relacionamento de extensão a extensão não indica uma obrigatoriedade mas uma relação que depende de uma condição Ou seja que acontece Às

vezes a direção da seta também nos indica que o caso F aponta para o caso ser dessa maneira não há como casos e ocorrer durante a realização do caso F portanto a resposta para essa pergunta bom então durante o caso f não é obrigatório executar o caso você E durante o caso F pode ser necessário executar o caso você e vamos analisar novamente o que você acha e olhando para relação temos um hextend ok como é que está indica uma necessidade porém a direção da seta não permitia que durante um caso F possa ocorrer um

caso você pois é filho está apontando para você e não contrário logo a resposta para essa pergunta também é não durante o caso f não há como ocorrer o caso você E durante o caso Cê pode ser necessário executar o caso F1 que você acha agora hein e olhando novamente para o relacionamento temos um relacionamento de extensão com o caso F apontando para o caso ser como Já estudamos quem estende a ponta para quem é estendido então podemos afirmar que sim durante um caso Cê pode ser necessário executar o caso f é o caso B

Obrigatoriamente ocorre durante o caso e e pode ser necessário durante o caso de e agora em que você acha Pare e pense um pouco e Vamos considerar os relacionamentos entre os casos envolvidos na pergunta e quando olhamos a relação entre o caso e e o caso B temos um relacionamento de inclusão o que significa isso que durante o caso e Obrigatoriamente deve ocorrer o caso B E isso está indicado pela direção da seta com e apontando para bebê Ok vamos lá próxima relação entre o caso dei o caso B existe um relacionamento de extensão o

caso B está apontando para o caso de logo é correto afirmar nos que durante o caso de pode ser necessário realizar o caso B assim olhando para Pergunta a resposta é sim o caso B Obrigatoriamente ocorre durante o caso e e pode ser necessário durante o caso de e ficou um pouco confuso volte para exercício anterior sobre a inclusão retorne as afirmações e depois análise novamente essa exercício da extensão é essencial que você entenda a diferença entre as propriedades do relacionamento de inclusão e de extensão para uma boa modelagem o ML de casos de uso

e vamos conhecer agora o relacionamento de generalização e especialização que Implica também no reuso do comportamento de um caso de uso na definição de outros casos de uso assim como a inclusão EA extensão é a generalização e especialização aplica os princípios da herança da orientação a objetos permite que os passos de um caso de uso sejam herdados por outro caso de uso indica um relacionamento do tipo vamos ver um pequeno exemplo temos aqui um diagrama com ator atendente que se comunica com caso de uso Abrir conta o caso de uso Abrir conta possui duas especializações

ou seja Abrir conta especial abrir conta poupança dessa maneira é possível afirmar que abrir conta pode ser do tipo abrir conta especial ou abrir conta poupança cada uma tem os passos genéricos do Abrir conta mais as suas especificidades não passo a passo da realização da tarefa o outro exemplo nós temos um ator cliente que se comunica com efetuar pagamento e efetuar pagamento pode ser do tipo efetuar pagamento à vista efetuar pagamento a prazo fácil né é a generalização e especialização também aplicado sobre atores esse relacionamento permite que um ator é de características de um ator

mais genérico esse último normalmente chamado de ator base o ator herdeiro pode especializar o comportamento do ator base vamos analisar um pouco exemplo nós temos aqui um pequeno diagrama com dois atores aluno e professor um aluno se comunica diretamente com os casos de uso pesquisar catálogo e reservar livro já o ator professor se comunica com solicitar compra de título porém se observarmos aqui o relacionamento de generalização e especialização que entre atores não achávamos de herança podemos ver que um professor herda as características de um aluno e logo nós podemos afirmar que um professor além de

solicitar a compra de título também pode pesquisar catálogo e reservar livro aqui entre um princípio muito importante quem herda a ponta para quem é herdado ou seja a direção da seta é essencial para a compreensão do processo de herança entre atores e vamos parar mais um exemplo agora temos aqui um diagrama genérico com dois atores e vários casos de uso quando olhamos para o ator um nós podemos dizer que ele se comunica diretamente com o caso F ou casos e o caso a e o caso de e os relacionamentos de inclusão e extensão também permite

que o ator um Execute o caso B e quando olhamos para o ator dois ele se comunica diretamente com o caso de uso e edda do relacionamento de inclusão também pode executar o caso B porém existe uma herança o ator dois herda as características do ator um logo ele pode acessar tudo que o ator um tá meio acessa portanto nesse exemplo o ator dois pode acessar todas as funcionalidades modeladas e após estudarmos os conceitos de inclusão extensão e generalização e especialização vamos ver um exemplo um pouco mais completo Considere a seguinte descrição um cliente pode

efetuar uma compra diretamente ou após buscar um produto no site para iniciar uma compra é necessário que o cliente esteja autenticados no sistema se for a sua primeira compra deverá se cadastrar para continuar o processo caso já tenha cadastro ele pode atualizar seus dados Se necessário ou regularizar pendências anteriores se existirem para conclusão da compra é obrigatório efetuar o pagamento que pode ser à vista ou a prazo após o pagamento a compra é finalizada com a emissão do comprovante e para treinar um pouco pause esse vídeo Pegue um papel rabisque um diagrama e tem que

ver se você compreendeu realmente os conceitos tente construir um diagrama aplicando inclusões extensões e generalizações vamos lá e pela descrição apresentada podemos ver o seguinte diagrama da uml nós temos um ator cliente que acessa diretamente o efetuar compra Mas pela descrição E isso também pode ser feito após o buscar produto ou seja após buscar produto pela extensão o cliente pode efetuar uma compra durante a compra se for a sua primeira vez ele deverá efetuar o seu cadastro então nós temos resistente cadastrar cliente ou seja só ocorrerá quando esse cadastro não existir a mesma coisa para

o alterar cliente quando o cliente já possuir um cadastro e desejar alterar algum dado ele tem essa hextend alterar cliente ou regularizar uma pendência também uma outra opção caso ele já possui um cadastro e alguma pendência anterior durante a compra é obrigatório efetuar a autenticação para o início da compra então nós temos aí um relacionamento de inclusão de efetuar a compra para efetuar e são e durante a autenticação se o usuário Esqueceu a sua senha de acesso por exemplo ele pode recuperar isso não tá na descrição mas nós colocamos aqui um exemplo para colocar um

pouco mais de extended nosso diagrama ou seja durante a efetuar a autenticação se for necessário o cliente irá recuperar o seu acesso para concluir a sua compra o cliente Obrigatoriamente precisa efetuar o pagamento aí nós temos um relacionamento de inclusão de efetuar compra para efetuar pagamento que pode ser do tipo efetuar pagamento a prazo efetuar pagamento à vista representados com relacionamento de generalização e especialização ou seja efetuar pagamento pode ser do tipo a prazo ou a vista e por fim é obrigatória a emissão do comprovante por isso que nós temos um relacionamento de inclusão de

efetuar compra para o emitir comprovante Esse é um pequeno exemplo que os três principais relacionamentos existentes entre casos de uso a inclusão a extensão EA generalização e especialização e ao ml também tem um elemento chamado pacote para sistemas mais complexos a quantidade de casos de uso cresce acima de um limite de fácil visualização representar todos os casos de uso único diagrama Talvez o torna um tanto elegível nesse contexto um pacote a um mecanismo de agrupamento definido pela ml esse mecanismo pode ser utilizado para agrupar elementos semanticamente relacionados a notação para um pacote é de uma

pasta com uma aba e o seu nome uso de pacotes permite formar grupos de casos de uso e atores de tal sorte que o modelo de caso de uso possa ser compreendido e gerenciado por partes e sistemas complexos os elementos do diagrama de caso de uso pode ser divididos em diversos pacotes no contexto da modelagem caso de uso os pacotes podem ser utilizados para diversos objetivos mas o principal deles é estrutural de uma maneira que permita a melhor compreensão da modelagem as fronteiras uma fronteira de sistema identifica um classificador que contém um conjunto de casos

de uso permite identificar o subsistema o mesmo sistema completo além de destacar o que está contido no sistema e o que não está atores são externas ao sistema enquanto o caso de uso são internos uma fronteira de sistema é representada por um retângulo envolvendo os casos de uso nela contidos além de um título que o descreve nesse exemplo nós temos os casos de uso pesquisar catálogo e reservar livro delimitados pela Fronteira empréstimos isso pode está especificando um agrupamento de funcionalidades diretamente relacionadas a empréstimos dentro de um sistema maior e vamos agora estudar uma situação bem

recorrente no desenvolvimento de sistemas No que diz respeito à diagrama de caso de uso o que a gente chama de manter e é muito comum requisito funcional com a seguinte redação o sistema deve permitir o gerenciamento dos dados de X onde x pode ser qualquer tipo de dado produto cliente compras vendas dentre outros o que implica um gerenciamento dos dados e x implica em cadastrar X no banco de dados o que a gente conhece com uma operação de insert alterar que o update consultar que é o select o excluir que é o de Elite e

o cancelar que também é um update essas operações básicas de banco de dados para que nós possamos através desses dados gerar informação com o novo sistema ou seja de que maneira a gente transforma-se requisito funcional num diagrama de caso de uso aí que surge o padrão manter nós temos a seguinte configuração para cada requisito funcional que tem a redação de gerenciamento dos dados de X cria-se um grupo chamado manter X por exemplo se for para manter os dados de clientes nós vamos ter um manter clientes se for para ter um o gerenciamento de dados de

vendas manter vendas logo nós temos um manter x com diversas ex tênis cadastrar x alterar x consultar x e excluir x e cancelar x nem sempre todas essas assistentes vão existir depende muito das regras de negócio mas esse é um padrão que sempre seguimos quando desenvolvemos A modelagem de caso de uso no sistema de informação e Entretanto é essencial que você preste atenção nessa dica importante Considere o seguinte diagrama nós temos um manter pedido que cadastra altera cancela e exclui pedidos Você pode perguntar qual é a diferença entre excluir pedido e Cancelar pedido é comum

nós acharmos que se tratam das mesmas operações Mas isso é um erro vamos entender porquê é o caso de uso excluir pedido impliquem apagá-lo do banco de dados é uma Operação realizada quando ocorre o chamado o cadastro indevido ou seja um pedido que não era para ter sido cadastrado e acabou o correto para isso é necessário excluído do banco de dados nós não teremos mais acesso a essa informação porque ela deixará de existir já o Cancelar pedido implica na mudança de status dele no banco de dados é uma operação recorrente quando nós temos ações de

cancelamento ou desistências de álcool por exemplo usuário fez um pedido e quer cancelar logo logo nós vamos mudar o seu status para cancelado isso não implica na exclusão no banco de dados inclusive poderemos gerar relatórios e pedidos cancelados isso é muito importante em várias situações gerenciais portanto excluir pedido implica numa operação de exclusão um de elite no banco de dados e o cancelamento é um update é importante que a a empresa com relação à diferença entre essas duas operações Nem sempre é obrigatório que as duas estejam presentes no manter x mas se elas existirem deve

ser Clara a diferença entre elas e agora que você já conhece o diagrama 1 ml para casos de uso no próximo vídeo nós vamos aprender a fazer uma ferramenta Case chamada astah-community Não perca Ah e por esse vídeo é só espero que vocês tenham entendido bem os conceitos da modelagem de casos de uso qual ml ficamos por aqui tchau tchau