Roteiro de elabora o de um caso de uso

1.881 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.881
No SlideShare
0
A partir de incorporações
0
Número de incorporações
34
Ações
Compartilhamentos
0
Downloads
80
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Roteiro de elabora o de um caso de uso

  1. 1. Roteiro de Elaboração de um Modelo de Casos de Uso Profa. Dra. Judith Pavón Relatório Técnico RT.2012.CCO/SI.01.00 Abril – 2012
  2. 2. Índice1. Objetivo do Documento ..............................................................................................32. Conceitos Básicos ........................................................................................................43. Diretrizes para Elaborar um Modelo de Casos de Uso ................................................74. Diretrizes para Identificar Atores ................................................................................85. Diretrizes para Identificar Casos de Uso .....................................................................96. Diretrizes para Especificar um Caso de Uso ................................................................97. Padrão para Especificar um Caso de Uso ...................................................................108. Diretrizes para Revisar a Especificação de um Caso de Uso ......................................119. Os Dez Erros Típicos na Elaboração de um Modelo de Casos de Uso ........................1210. Exemplo ...................................................................................................................15RT.2012.CCO/SI.01.00 Page 2
  3. 3. 1. Objetivo do DocumentoEste documento tem por objetivo servir como guia aos alunos dos cursos de Ciência daComputação e Sistemas de Informação da Universidade Salvador (UNIFACS) para aelaboração de um modelo de casos de uso.Existem bons livros disponíveis aqui no Brasil que tratam sobre o tema de elaboraçãode modelos de casos de uso. No entanto, uma razão que me levou a escrever esterelatório técnico foi o fato que muitos desses livros acabam dando maior ênfase ànotação que deve ser utilizada no diagrama de casos de uso e não orientam naelaboração de modelos de casos de uso. Certamente, essa notação é importante paraqualquer projetista, mas, igualmente importante, é entender como aplicar essanotação na modelagem de um domínio de problema.Em vista do comentado acima, este relatório não tem como objetivo ser umareferência completa sobre a notação de modelos de casos de uso, definida pela UML(Linguagem de Modelagem Unificada), e nem como referência para aprender todos osconceitos básicos relacionados. Este documento tem como objetivo apresentardiretrizes que orientem, principalmente a iniciantes da modelagem orientada aobjetos, na elaboração de modelos de casos de uso, mostrando passo a passo, comoaplicar os diferentes conceitos em um caso prático.O documento consiste das seguintes seções:• A seção 2 apresenta os conceitos básicos referentes ao contexto de modelos decasos de uso;• A seção 3 apresenta as diretrizes essenciais para iniciar a elaboração de um modelode casos de uso;• A seção 4 apresenta diretrizes para identificar os atores;• A seção 5 apresenta diretrizes para identificar casos de uso;• A seção 6 apresenta diretrizes para descrever um caso de uso;• A seção 7 apresenta um padrão para a especificação de um caso de uso;• A seção 8 apresenta diretrizes para revisar a especificação de um caso de uso;• A seção 9 apresenta os dez erros típicos na elaboração de um modelo de casos deuso;• A seção 10 apresenta um exemplo de especificação de caso de uso.RT.2012.CCO/SI.01.00 Page 3
  4. 4. 2. Conceitos BásicosUma das primeiras etapas dentro do processo de desenvolvimento de software é olevantamento de requisitos, tanto funcionais como não funcionais. Especificamente, aetapa de levantamento de requisitos corresponde a buscar junto ao usuário, todas asinformações referentes as funções que o sistema deve executar (requisitos funcionais)e as restrições sob as quais o sistema deve operar (requisitos não funcionais). Logoapós, o levantamento de requisitos, deve ser realizada a organização destes requisitospara que possam ser contemplados no desenvolvimento do produto de software.Grande parte dos requisitos funcionais será organizada como processos de negócioconhecidos como casos de uso. Os casos de uso referem-se aos serviços ou processosde negócio que podem ser utilizados de alguma maneira pelos usuários do sistema,como emitir um relatório ou comprar um produto. Os casos de uso são utilizados paraexpressar e documentar o comportamento ou funções do sistema.Um modelo de casos de uso é composto pelo diagrama de casos de uso e adocumentação dos elementos do modelo, conforme pode ser observado na Figura 1. Figura 1. Representação de um Modelo de Casos de UsoO diagrama de casos de uso é composto por casos de uso, atores e os relacionamentosou associações. Um caso de uso é uma seqüência de ações que o sistema executa ouproduz um resultado de valor observável para um ator. Os casos de uso capturam emodelam os requisitos funcionais, servindo como um acordo entre as pessoasenvolvidas no desenvolvimento do sistema (stakeholders), descrevendo seucomportamento sob diversas condições conforme responde às requisições dosinteressados, denominados atores primários. Os atores não fazem parte do sistema.Eles representam qualquer pessoa, entidade ou dispositivo que interage com osistema. Pode representar um ser humano, uma máquina, outro sistema ou umRT.2012.CCO/SI.01.00 Page 4
  5. 5. departamento de uma empresa. Um ator representa os papéis que o usuário dosistema pode desempenhar.O relacionamento entre atores e casos de uso é conhecido como linha decomunicação, pois representa o canal de comunicação entre um ator e um caso deuso, conforme pode ser observado na Figura 2. Figura 2. Linha de comunicação entre ator e caso de uso.Os relacionamentos básicos entre casos de uso são: inclusão, extensão egeneralização. Ao detalhar ou elaborar a especificação de casos de uso é possíveldescobrir novos processos de negócio e estruturar os relacionamentos dos casos deuso no diagrama.O relacionamento de inclusão (<<include>>) ocorre quando um caso de uso base exigeum conjunto de atividades necessárias para a sua execução no cenário principal,porém não é o objetivo do caso de uso base. Há duas situações típicas para casos deuso de inclusão:• Quando existe um comportamento comum para vários casos de uso. Neste caso,esse comportamento pode ser separado e modelado como um caso de uso de inclusãoassociado aos vários casos de uso que contêm este comportamento.• Quando existe um comportamento muito complexo ou extenso no cenário principalde um caso de uso, mas que não é o centro ou objetivo deste caso de uso. Essecomportamento poderia ser representado como um caso de uso de inclusão.O comportamento definido pelo caso de uso de inclusão é explicitamente inserido nocaso de uso base. A representação é uma linha tracejada do caso de uso base para ocaso de uso de inclusão, acrescida do estereótipo <<include>>, como descrito na Figura3.RT.2012.CCO/SI.01.00 Page 5
  6. 6. Figura 3. Representação de um caso de uso de inclusão.O relacionamento de extensão (<<extend>>) ocorre quando um caso de uso base temum conjunto de ações que devem ser realizadas em um caso de exceção. Casos de usode extensão modelam comportamento alternativo do caso de uso. O caso de uso deextensão é inserido no caso de uso base, somente se a condição de extensão forverdadeira.A representação é uma linha tracejada do caso de uso estendido para o caso de uso debase, acrescida do estereótipo <<extend>>, como descrito na Figura 4. Figura 4. Representação de um caso de uso de extensão.O relacionamento de generalização ocorre quando um caso de uso genérico (pai)possui um cenário principal, onde certos passos são diferentes dos seus casos de usoespecíficos (filhos). A representação é uma linha contínua em que os casos de usofilhos apontam para o caso de uso pai, como pode ser observado na Figura 5. Figura 5. Representação de um relacionamento de generalização.RT.2012.CCO/SI.01.00 Page 6
  7. 7. O relacionamento de generalização também pode ser definido entre atores, pois elespodem ter características comuns, sendo representado por um ator genérico, e osatores com características particulares são representados como atores filhos.Normalmente, a generalização de atores é modelada em um diagrama separado, ondeestão somente os atores, enquanto apenas o ator generalizado é desenhado nosdiagramas onde aparecem os casos de uso. Esta prática costuma ser realizada para nãopoluir o diagrama de casos de uso, pois a idéia principal é que o diagrama seja uminstrumento de comunicação com o cliente e usuários, portanto deve ser simples efácil de entender. Na figura 6 é mostrado um exemplo de uma generalização de atores. Figura 6. Representação de uma generalização de atores.Nas próximas seções são apresentadas diversas diretrizes para elaborar um modelo decasos de uso e para documentar os elementos do diagrama de casos de uso.3. Diretrizes para Elaborar um Modelo de Casos de UsoComo foi mencionado anteriormente, o modelo de casos de uso é composto pelodiagrama de casos de uso, e pelas documentações dos atores e casos de uso. Os casosde uso definem uma promessa ou contrato de como um sistema se comportará.Os passos essenciais na elaboração de um modelo de casos de uso são:Estabelecer uma fronteira• Identificar atoresRT.2012.CCO/SI.01.00 Page 7
  8. 8. • Descrever atores• Identificar casos de uso• Descrever brevemente o objetivo de cada caso de uso• Identificar relacionamentos entre atores e casos de uso• Elaborar diagramas de casos de uso• Elaborar a descrição passo a passo de cada caso de usoO primeiro passo a ser realizado é definir a fronteira (alcance do sistema). Uma vezdefinida a fronteira, é importante pensar primeiro nos atores. A idéia por trás de casosde uso é decidir para que o sistema será usado antes de decidir o que o sistema iráfazer. Se alguém modela o sistema pensando primeiro nos casos de uso e depois nosatores, está com um problema sério, pois quer dizer que ainda não entendeu afilosofia de modelo de casos de uso. Vale a pena lembrar que um modelo de casos deuso deve ser modelado a partir da perspectiva do usuário e não do desenvolvedor.Portanto, se vamos colocar o usuário no centro de nossas preocupações, então osatores devem ter prioridade número um nas nossas atividades. Uma vez identificadosos atores, os mesmos precisam ser documentados, isto é, deve ser elaborada umabreve descrição sobre o que representa cada um deles. Logo após, devem seridentificados os casos de uso, que são as metas ou serviços do sistema utilizados pelosusuários. Elabora-se uma descrição sucinta de cada caso de uso, de forma a deixarclaro o objetivo do mesmo. A seguir, são definidas as associações entre atores e casosde uso e elabora-se o diagrama de casos de uso. Depois deve ser elaborada a descriçãopasso a passo de cada caso de uso, considerando os diversos cenários possíveis paraesse processo de negócio, e por último, é realizado um refinamento tanto do diagramacomo da documentação associada.4. Diretrizes para Identificar AtoresNa identificação de atores podem ser utilizadas algumas perguntas básicas com afinalidade de obter os principais atores envolvidos no sistema:a) Que pessoas, órgãos, empresas ou grupos de usuários utilizarão o sistema?b) Que elementos ou componentes estimularam os casos de uso ou funcionalidades dosistema, além dos usuários?c) Que outros sistemas se comunicarão com o sistema a ser construído?RT.2012.CCO/SI.01.00 Page 8
  9. 9. d) Que pessoas, órgãos, empresas, sistemas ou grupos de usuários receberãoinformações do sistema?e) Que papéis desempenham os usuários ou grupo de usuários que utilizam o sistema?Observação: existem atores que não iniciam nenhum caso de uso, mas são “tocados”por casos de uso, isto é, simplesmente recebem informações do sistema.5. Diretrizes para Identificar Casos de UsoPodem ser utilizadas algumas perguntas básicas com a finalidade de obter os principaiscasos de uso:a) Quais são as metas de cada ator?b) Quais são os serviços utilizados pelos atores?c) O ator precisa ser informado sobre eventos externos ou mudanças no sistema?d) O ator precisa ser informado sobre certas ocorrências no sistema?e) Quais são os processos de negócio envolvidos no domínio do problema?Observação: uma vez identificados os casos de uso, eles devem ser trazidos paraanálise da equipe de desenvolvimento, somente depois devem ser especificadosdetalhadamente.6. Diretrizes para Especificar um Caso de UsoOs casos de uso podem ser descritos com diferentes níveis de detalhamento, istodepende da metodologia adotada pela equipe de desenvolvimento. Na fase de análise,quando o objetivo é estudar o sistema para descobrir as necessidades do cliente, usa-se a descrição essencial de caso de uso, que consiste na definição do nome do caso deuso, uma breve descrição do objetivo do mesmo e citar os atores primários. Noentanto, na fase de projeto, quando a meta é produzir uma solução implementada deum sistema para o cliente, deverá ser realizada a descrição detalhada do caso de uso,também conhecido como caso de uso expandido, onde inclui a especificação dosdiferentes fluxos possíveis dentro desse contexto.Cada caso de uso deve ser descrito de forma a contemplar todos os cenários possíveis.Geralmente, estes cenários são organizados em três grupos:1. Fluxo Principal: é considerado o cenário feliz, isto é, cenário de sucesso do início aofim. O fluxo principal deve focar sempre o objetivo principal do processo de negócio.RT.2012.CCO/SI.01.00 Page 9
  10. 10. Quando existir mais de um cenário que possa ser candidato do fluxo básico ouprincipal, o analista deve escolher o mais utilizado ou aquele que melhor retrata o casode uso, deixando os outros como alternativos.2. Fluxo Alternativo: corresponde aos cenários opcionais ou caminhos alternativos dofluxo principal. São as variantes do fluxo principal.3. Fluxo de Exceção: corresponde aos cenários que tratam os erros ou exceções.Existem algumas bibliografias que não consideram esta terceira alternativa, colocandotanto os cenários opcionais como os que tratam os erros nos fluxos alternativos.Depois de descrever o fluxo principal do caso de uso, deve-se imaginar o que poderiadar errado em cada um dos passos descritos, gerando assim os fluxos de exceção. Umfluxo de exceção é um evento capaz de impedir o prosseguimento do caso de uso senão for devidamente tratado.Um caso de uso deve descrever o que deve ser feito e quem faz, mas nunca deve serdescrito o como. Deve-se evitar descrever qualquer processo interno do sistema (ex.deve-se armazenar os dados do pagamento do empréstimo na tabela Pagamento dobanco de dados).7. Padrão para Especificar um Caso de UsoA seguir é apresentado um template que mostra os elementos que conformam opadrão de especificação de um caso de uso utilizado nos cursos de Ciência daComputação e Sistemas de Informação da Universidade Salvador (UNIFACS).O template utilizado para especificar casos de uso é apresentado a seguir:Caso de Uso: indicar o código e nome do caso de uso.Finalidade: breve descrição do objetivo do caso de uso.(opcional) Ator primário: indicar o nome ou nomes de atores que iniciam o caso deuso.(opcional) Pré-condição: é uma restrição ou restrições que devem ser verdadeirasantes de começar o caso de uso.Fluxo Principal: descrever os passos necessários para alcançar o objetivo do processode negócio com sucesso. Enumerar os passos, indicando a interação entre usuário esistema.RT.2012.CCO/SI.01.00 Page 10
  11. 11. Fluxos alternativos: colocar um título para cada fluxo alternativo. Enumerar os passos,indicar o número do passo do fluxo principal ou outro fluxo do qual é derivada eespecificar onde continua, se retorna ao fluxo principal ou se o caso de uso éencerrado.Fluxos de exceção: colocar um título para cada fluxo de exceção. Enumerar os passos,indicar o número do passo do fluxo principal ou outro fluxo do qual é derivada eespecificar onde continua, se retorna ao fluxo principal, alternativo ou se o caso de usoé encerrado.(opcional) Pós-condição: refere-se ao estado do sistema quando o caso de usotermina. Pode conter variantes.Extensões: citar os casos de uso que estendem o caso de uso que está sendoespecificado.Inclusões: citar os casos de uso que são incluídos pelo caso de uso que está sendoespecificado.Regras de Negócio: citar as regras de negócio usadas no caso de uso.8. Diretrizes para Revisar a Especificação de um Caso de UsoRevisar a especificação de um caso de uso não é uma tarefa trivial, pois requer de umcerto esforço e de muita concentração. Um aspecto importante a ressaltar é que duaspessoas que descrevem um caso de uso do mesmo processo de negócio,provavelmente especificarão uma seqüência de passos diferentes, pois cada pessoatem a sua própria lógica. Porém, todo caso de uso tem passos obrigatórios. Essespassos envolvem as informações que de alguma forma passam dos atores para osistema, e do sistema para os atores, sem os quais o caso de uso não faz sentido ounão pode prosseguir. Esses passos devem constar em qualquer caso de uso expandido(descrição detalhada do caso de uso), e a falta deles faz com que o caso de uso estejaincorretamente descrito.Outro aspecto a revisar é a linguagem utilizada para a especificação do caso de uso,pois deve ser feita sob a perspectiva do usuário do sistema, portanto, devem serevitados os termos técnicos ou características de implementação na descrição de umcaso de uso.Os casos de uso devem ser descritos de forma simples o bastante para que os usuáriosentendam e verifiquem, mas preciso o bastante para que os analistas e projetistaspossam utilizar como modelo base para a construção do sistema.RT.2012.CCO/SI.01.00 Page 11
  12. 12. Em relação à revisão da consistência da especificação de um caso de uso, recomenda-se realizar as seguintes perguntas:• O objetivo do caso de uso é claro e preciso? A descrição do caso de uso atinge o objetivo pré-definido quando termina a execução do fluxo principal?• Existe ambigüidade em relação à seqüência de passos do caso de uso utilizado paraatingir ao objetivo especificado?• O caso de uso especifica a informação que o ator precisa saber para atingir seuobjetivo?• O caso de uso especifica a informação que o sistema precisa possuir para atender oobjetivo da solicitação do ator?• O caso de uso identifica as ações externamente relevantes que o sistema deverealizar para satisfazer as solicitações do ator?• O caso de uso especifica as interações entre o sistema e atores de acordo com assuas responsabilidades?• Todos os passos da especificação de Caso de Uso estão de acordo com a realidade,isto é, de acordo com o que o usuário deseja durante a operação do sistema?• As situações de falha e sucesso são especificadas claramente no caso de uso?• As pré-condições e pós-condições estão claramente identificadas?• Foram referenciados na especificação do caso de uso os nomes dos casos de usorelacionados (inclusões ou extensões)?• A especificação do caso de uso (considerando todos os fluxos) apresenta uma visãocompleta do comportamento do sistema referente ao processo de negócio modelado?9. Os Dez Erros Típicos na Elaboração de um Modelo de Casos de Uso Esta seção tem como objetivo apresentar os dez erros mais comuns quecostumam acontecer nos modelos de casos de uso de pessoas iniciantes namodelagem orientada a objetos. Acredito que esta seção pode ser muito útil parasanar aquelas dúvidas que ficam pendentes depois de ter lido todas as diretrizesapresentadas acima. A seguir são descritos estes erros: ERRO 10: Cada requisito funcional sempre corresponde a UM caso de uso.RT.2012.CCO/SI.01.00 Page 12
  13. 13. Esta afirmação costuma ser o erro mais freqüente entre os profissionais iniciantes namodelagem de casos de uso. Um requisito funcional nem sempre corresponde a umcaso de uso. Acontece que um caso de uso representa um processo de negócio, isto é,um conjunto de ações com início, meio e fim. Porém, um requisito funcional nemsempre se refere a um processo de negócio, muitas vezes o requisito funcional ésimplesmente uma única ação. A seguir são especificados dois requisitos funcionaisreferentes à compra de passagens pela Internet:- Requisito 1: O sistema deve permitir realizar ao usuário a compra de passagensaéreas pela Internet.- Requisito 2: O sistema deve permitir que o usuário possa selecionar o vôo desejado.Note que no primeiro exemplo (“Comprar passagem”), o requisito funcionalcorresponde a um caso de uso, pois o mesmo corresponde a um processo de negócio,onde devem ser realizados vários passos para atingir o objetivo de comprar apassagem. No entanto, no segundo exemplo (“Selecionar Vôo”), o requisito funcionalcorresponde simplesmente a um passo dentro de um caso de uso, pois selecionar ovôo desejado implica simplesmente uma ação. Não existe a possibilidade de definir umconjunto de passos para o fluxo principal do segundo exemplo, e como conseqüência,não é um caso de uso. ERRO 9: Na especificação do caso de uso somente devem ser especificadas as ações realizadas pelo usuário para interagir com o sistema.A descrição detalhada de um caso de uso deve especificar a interação entre o usuário eo sistema. A ausência dos passos de interação que registrem essa troca de informaçõesdeixa o caso de uso sem sentido. Portanto, um caso de uso está incorretamentedescrito quando somente são especificadas as ações do usuário, como se podeobservar no exemplo abaixo.Caso de Uso: Comprar passagens aéreasFluxo Principal:1. Cliente informa os dados da passagem.2. Cliente confirma os dados da passagem.3. Cliente informa os dados do pagamento da passagem.4. Cliente confirma a compra da passagem.RT.2012.CCO/SI.01.00 Page 13
  14. 14.  ERRO 8: Na especificação de um caso de uso deve ser detalhado o processamento interno do sistema.Os casos de uso devem mostrar o que é feito e por quem é feito, mas nunca o como.Um erro freqüente é especificar detalhes de implementação na especificação de umcaso de uso (ex. citar o nome do banco de dados ou da tabela onde serãoarmazenados os dados referentes ao processo de negócio modelado). O projetistadeve-se lembrar que a descrição ou especificação de um caso de uso não deve mudarquando mudam os detalhes de implementação, pois o caso de uso representa oprocesso de negócio, portanto, ele somente pode mudar quando existe algumaalteração ou mudança no próprio processo de negócio. ERRO 7: As associações <<include>> e <<extend>> representadas no diagrama de casos de uso devem ser utilizadas o máximo possível, com a finalidade de deixar mais claro o domínio do problema.Geralmente quando o projetista exagera com o uso das associações ourelacionamentos <<include>> e <<extend>> gera um diagrama de casos de usopoluído, deixando o modelo mais complexo e difícil de entender. Para este tipo desituação, recomenda-se analisar caso a caso a relevância de cada associação. Na seção2 são descritas as situações nas quais se recomenda utilizar estas associações, casocontrário evite a sua utilização. ERRO 6: A especificação de um caso de uso deve referenciar aos elementos da interface do sistema.Recomenda-se elaborar um esboço da interface para ter uma noção da interação dousuário com o sistema. Porém, isso não implica que devem ser mencionados oselementos da interface do sistema na especificação do caso de uso. O caso de usorepresenta o processo de negócio independente da interface utilizada no sistema.Portanto, se a interface muda não tem porque mudar a especificação do caso de uso.Exemplo: “Usuário pressiona o botão CONFIRMAR”. Esta frase indica quenecessariamente deverá existir um botão com o rótulo “Confirmar”, o que implicaamarrar a descrição do caso de uso a uma interface específica. ERRO 5: Na especificação de um caso de uso devem ser incluídos os detalhes referentes a mecanismos de segurança.Aspectos relacionados com mecanismos de segurança geralmente não são detalhadosnas especificações de casos de uso. Exemplo: “Operação de login do usuário nosistema”. O que pode ser especificado no sistema é que o usuário será autenticado noRT.2012.CCO/SI.01.00 Page 14
  15. 15. sistema, mas não como será feita esta autenticação, pois amanhã ou depois estaautenticação pode mudar (ex. reconhecimento de voz), mas o caso de uso não devemudar por causa desta alteração. A autenticação no sistema ou identificação dousuário no sistema geralmente recomenda-se colocar como uma pré-condição do casode uso. ERRO 4: As pré-condições devem ser verificadas dentro do caso de uso.Uma pré-condição é uma restrição que precisa ser verdadeira ANTES que inicie o casode uso. Portanto, a mesma não deve ser verificada dentro da especificação do caso deuso. ERRO 3: Um caso de uso é uma rotina do sistema.Geralmente os desenvolvedores assumem que um caso de uso constitui uma rotina dosistema, mas esta afirmação não é verdadeira. Isto costuma ser muito comum quandoo projetista precisa elaborar modelos de casos de uso tendo como base o código deum sistema legado. Porém, nem sempre uma rotina do sistema representa umprocesso de negócio. A pergunta que deve ser realizada é: -“Quais são os processos denegócio deste sistema?” e não considerar que cada rotina corresponderá a um caso deuso específico. ERRO 2: Um caso de uso de extensão ou de inclusão não precisam ser referenciados no caso de uso base.Todo caso de uso de extensão ou inclusão que é representado no diagrama de casosde uso deve ser referenciado na especificação do caso de uso base correspondente. Ocaso de uso de inclusão geralmente é referenciado no fluxo principal do caso de usobase, e o caso de uso de extensão em algum fluxo alternativo ou de exceção do casode uso base. ERRO 1: Na descrição dos fluxos alternativos ou de exceção não precisa conter um passo que indique como o caso de uso continua.Para cada fluxo alternativo ou fluxo de exceção deve ser especificado como esse fluxocomeça (indicar o passo do fluxo principal ou de outro fluxo da onde vem), quais açõessão tomadas e como o caso de uso continua.10. ExemploA seguir é mostrado um exemplo de especificação de caso de uso, utilizando otemplate apresentado acima. O exemplo refere-se ao caso de uso “VerificarRT.2012.CCO/SI.01.00 Page 15
  16. 16. disponibilidade de passagens”, dentro do contexto de um Sistema de Compras dePassagens Aéreas via Web. Na Figura 7, apresenta-se o diagrama de casos de usocorrespondente.Figura 7. Extração de uma parte do Diagrama de Casos de Uso do Sistema de Compras de Passagens Aéreas.Caso de Uso: UC1 - Verificar Disponibilidade de PassagensFinalidade: Pesquisar as passagens disponíveis, indicando os aeroportos de origem ede destino, quantidade e tipo de passageiros (adultos e crianças), bem como a data daviagem.Ator primário: ClientePré-condição: Cliente devidamente autenticado no sistema.Fluxo Principal:1. Sistema solicita os dados referentes a passagem (dados de origem e destino,indicação se é uma passagem somente de ida ou ida e volta, data e quantidade depassageiros)2.Cliente informa os dados referentes à passagem:- ida e volta (ou somente ida);- aeroportos de origem e de destino;- data de ida e volta (ou somente ida);- quantidade de adultos;- quantidade de crianças.3. Sistema valida os dados do critério de busca (RN01, RN02).RT.2012.CCO/SI.01.00 Page 16
  17. 17. 4. Sistema seleciona os voos disponíveis correspondentes ao critério de busca (RN03).5. Sistema calcula valor da passagem dos voos disponíveis que satisfazem os dadosinformados .6. Sistema exibe voos disponíveis (data e número do vôo, hora de saída e chegada,escalas e/ou conexões, preço e taxas de embarque);7. Cliente seleciona voo de ida ou voos de ida/volta de interesse.8. Sistema exibe os detalhes do voo selecionado e o contrato.9. Cliente escolhe sair do sistema.10. O caso de uso é encerrado.Fluxos alternativos:A1. Cliente decide comprar a passagem A1.1. No passo 9 do fluxo principal o Cliente seleciona "Comprar Passagem" A1.2. Ir para UC9 – Comprar Passagem A1.3. Retorna ao passo 9 do fluxo principal.A2. Cliente decide realizar nova busca. A2.1. No passo 9 do fluxo principal o Cliente seleciona "Nova Busca" A2.2. Retorna ao passo 1 do fluxo principal.Fluxo de exceção:E1. Aeroporto de origem igual ao de destino E1.1. No passo 3 do fluxo principal o sistema identifica que o aeroporto de origem é o mesmo que o de saída. E1.2. O Sistema mostra a seguinte mensagem "Os aeroportos de origem e de destino devem ser diferentes" E1.3.- Retorna ao passo 1 do fluxo principal.RT.2012.CCO/SI.01.00 Page 17
  18. 18. E2. Data de ida maior à data atual E2.1. No passo 3 do fluxo principal o sistema identifica que a data de ida é maior à data atual. E2.2. O Sistema mostra a seguinte mensagem "A data de ida deve ser maior à data atual" E2.3. Retorna ao passo 1 do fluxo principal.E3. Não encontra voos disponíveis E3.1. No passo 5 do fluxo principal o sistema identifica que não existem voos diponíveis para o critério de busca informado pelo cliente. E3.2. O Sistema mostra a seguinte mensagem "Não existem voos disponíveis para o período informado. Informe outro período de datas." E3.3.- Retorna ao passo 1 do fluxo principal.Extensões: UC9 - Comprar PassagemInclusões: NenhumaRegras de Negócio: RN01, RN02, RN03RN01 – O aeroporto de origem deve ser diferente ao aeroporto de destino.RN02 – A data de ida deve ser igual ou maior à data atual.RN03 – Um voo disponível é um um voo com pelo menos um assento disponível.BIBLIOGRAFIA RECOMENDADABEZERRA, Eduardo, Princípios de Análise e Projeto de Sistemas com UML. 2ª. ed. Rio deJaneiro: Campus, 2006.COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um guia prático paradesenvolvedores de software. Bookman. 2005.DOUG, R.; KENDALL S. Applying Use Case Driven Object Modeling with UML. Addison-Wesley. 2001.RT.2012.CCO/SI.01.00 Page 18
  19. 19. GEDES, G. TA. A. UML: Uma Abordagem Prática. Novatec. 2004PENDER, T. UML a Bíblia. Campus. 2004.PRESSMAN, R. Engenharia de Software. 7a ed., Artmed. 2011.SOMMERVILLE, Ian. Engenharia de Software. 9a ed., Pearson. 2011.WASLALICK, R.S. Análise e Projeto de Sistemas de Informação Orientados a Objetos.Rio de Janeiro: Elsevier. 2004.RT.2012.CCO/SI.01.00 Page 19

×