Exerccio 4-1: descreva a posio do diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Quando eles so utilizados?

Para que so utilizados? Do livro: Princpios de Anlise e Projeto de Sistemas com UML. Eduardo Bezerra. Editora Campus. Considerando que o processo de desenvolvimento incremental utilizado, a identificao da maioria dos atores e casos de uso feita pelos analistas na fase de concepo. A descrio dos casos de uso considerados mais crticos comea j nessa fase, que termina com 10% a 20% do modelo de casos de uso completo. Na fase de elaborao, a construo do modelo continua de tal forma que, ao seu trmino, 80% do modelo de casos de uso esteja construdo. Na fase de construo, casos de uso formam uma base natural atravs da qual podem-se realizar as iteraes do desenvolvimento. Um grupo de casos alocado a cada iterao. Ento, o desenvolvimento do sistema segue a alocao realizada: em cada iterao, um grupo de casos de uso detalhado (utilizando um nvel de abstrao real) e desenvolvido. O processo continua at que todos os casos de uso tenham sido desenvolvidos e o sistema esteja completamente construdo. Esse tipo de desenvolvimento tambm chamado de desenvolvimento dirigido a casos de uso. Conforme mencionado h pouco nesta seo, um fator importante para o sucesso do desenvolvimento do sistema considerar os casos de uso mais importantes primeiramente. Murray Cantor (Cantor, 1998) prope uma classificao dos casos de uso identificados para um sistema em funo de dois parmetros: risco de desenvolvimento e prioridades estabelecidas pelo usurio. Dessa forma, cada caso de uso se encaixa em uma das categorias a seguir: 1. Risco alto e prioridade alta: casos de uso nesta categoria so os mais crticos. Devem ser considerados o quanto antes. 2. Risco alto e prioridade baixa: embora os casos de uso nesta categoria tenham risco alto, necessrio, antes de comear a consider-los, negociar com o cliente em relao a sua verdadeira necessidade. 3. Risco baixo e prioridade alta: embora os casos de uso tenham prioridade alta, necessrio ter em mente que os casos de uso de mais alto risco devem ser considerados primeiro. 4. Risco baixo e prioridade baixa: em situaes em que o desenvolvimento do sistema est atrasado, estes casos de uso so os primeiros a serem "cortados". Atravs da atribuio de importncia segundo a categorizao de Cantor, um caso de uso no to importante no ser contemplado nas iteraes iniciais. Se o requisito correspondente a esse caso de uso for modificado ou no mais precisar ser considerado, os analistas no tero desperdiado tempo com ele. Note tambm que a descrio expandida de um determinado caso de uso deixada para a iterao na qual este deve ser implementado. Isso evita que se perca tempo inicialmente no seu detalhamento. Alm disso, essa estratgia mais adaptvel aos requisitos volteis. Se todos os casos de uso forem detalhados inicialmente, e se um ou mais requisitos so modificados durante o desenvolvimento, toda a modelagem correspondente a esses casos de uso sofrer modificaes. Por outro lado, se a descrio detalhada deixada para a iterao qual o caso de uso foi alocado, uma eventual mudana dos requisitos associados a esse caso de uso no afetar to profundamente o desenvolvimento. ______________________________________________________________________________ A construo do modelo de casos de uso deve se adequar ao processo de desenvolvimento sendo utilizado. Os casos de uso mais arriscados devem ser considerados primeiramente. ______________________________________________________________________________ Casos de uso nas atividades de anlise e projeto Alguns desenvolvedores escrevem as descries iniciais de casos de uso mencionando detalhes de interface grfica com o usurio (considerando atores humanos). A justificativa que a narrativa dos casos de uso segundo essa abordagem fornece uma idia mais concreta de como se apresentar uma determinada funcionalidade do sistema. Contudo, as desvantagens dessa abordagem se sobrepem s vantagens. Considere a situao de uma parte da interface estar sendo continuamente modificada, por alguma razo. Nessa situao, a desvantagem de utilizao de casos de uso reais (vide Seo 4.1.1.3) se torna ntida, pois o fato de a interface ser modificada possivelmente resultar na modificao da narrativa do caso de uso. Alm disso, lembre-se do objetivo principal do modelo de casos de uso, a saber, modelar os requisitos do sistema. Portanto, casos de uso devem ser independentes do desenho da interface pelo fato de que os requisitos do sistema no devem estar associados a detalhes de interface. Uma melhor abordagem utilizar inicialmente casos de uso essenciais (vide Seo 4.1.1.3) para no acoplar os detalhes da interface da aplicao na especificao narrativa das interaes de um caso de uso. Nessa especificao, a ateno do modelador deve recair sobre a essncia das interaes entre atores e o sistema, em vez de como cada interao realizada fisicamente. Especificaes de casos de uso feitas dessa forma ficam mais imunes a futuras mudanas na interface com o usurio, alm de permitir que o analista de sistemas se concentre no que realmente importante em uma narrativa de caso de uso: as interaes entre ator(es) e sistema. Por exemplo, considere o termo "envia uma requisio" em

contraposio com o termo "duplo clique sobre o boto de envio de requisies". Em resumo, casos de uso que mencionam detalhes de interface grfica so indesejveis durante a anlise. O mais adequado utilizar casos de uso essenciais e, posteriormente, na etapa de projeto, transform-los em casos de uso reais adicionando mais detalhes. ______________________________________________________________________________ Na fase de anlise, descries de casos de uso devem capturar os requisitos funcionais do sistema e ignorar aspectos de projeto, como a interface grfica com o usurio. ______________________________________________________________________________ Pode-se, agora, descrever um procedimento a ser utilizado na construo do modelo de casos de uso quando da utilizao de um processo de desenvolvimento incremental: 1. Identifique os atores e casos de uso na fase de concepo. Alguns atores e casos de uso s sero identificados posteriormente, mas a grande maioria deve ser descoberta nesta fase. 2. Na fase de elaborao: a. Desenhe o(s) diagrama(s) de casos de uso; b. Escreva os casos de uso em um formato de alto nvel e essencial. c. Ordene a lista de casos de uso de acordo com prioridade e risco. Cada partio corresponde a um grupo de casos de uso que ser implementado em um dos ciclos de desenvolvimento do sistema. 3. Associe cada grupo de casos de uso a urna iterao da fase de construo. Os grupos mais prioritrios e arriscados devem ser alocados s iteraes iniciais. 4. Na i-sima iterao da fase de construo: a. Detalhe os casos de uso do grupo associado a esta iterao (se necessrio, utilize o nvel de abstrao real). b. Implemente estes casos de uso. Casos de uso e outras atividades do desenvolvimento O modelo de casos de uso direciona a realizao de vrias outras atividades do desenvolvimento. Planejamento e gerenciamento do projeto O modelo de casos de uso uma ferramenta fundamental para o gerente de um projeto no planejamento e controle de um processo de desenvolvimento incremental e iterativo. Ao final de cada iterao, o gerente pode avaliar a produtividade na realizao das tarefas. Essa avaliao serve como massa de dados para que esse profissional realize a alocao das tarefas e recursos para as prximas iteraes. Testes do sistema Em um processo de desenvolvimento incremental e iterativo, no h uma fase de testes propriamente dita. Ao contrrio, os testes do software so realizados continuamente durante todo o desenvolvimento. Os profissionais responsveis pelos testes utilizam o modelo de casos de uso para planejar as atividades de teste. Os casos de uso e seus cenrios oferecem casos de teste. Quando o sistema est sendo testado, os cenrios sobre o sistema podem ser verificados para identificar a existncia de erros. Documentao do usurio Os manuais e guias do usurio tambm podem ser construdos com base no modelo de casos de uso. Na verdade, se o modelo de casos de uso foi bem construdo, deve haver uma correspondncia clara entre cada caso de uso do sistema e uma seo do manual do usurio. Isso porque esse modelo est baseado na noo de que o sistema construdo para se adequar perspectiva de seus usurios. Exerccio 4-2: construa um modelo de casos de uso para a seguinte situao fictcia: "Estamos criando um servio de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volumes so considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor".

Exerccio 4-3: Considere a seguinte narrativa do caso de uso Realizar Saque. Identifique os erros existentes nesta narrativa. Construa uma nova verso deste caso de uso que no contenha os erros encontrados. A operao de um caixa eletrnico tem incio a partir de uma sesso em que o cliente seleciona a opo de realizar saque. O cliente ento escolhe uma quantia a ser retirada, a partir de um conjunto de opes de quantia disponveis. O sistema verifica se a conta correspondente tem saldo suficiente para satisfazer a requisio. Seno, uma mensagem adequada reportada, o que acarreta na execuo da extenso. Se h dinheiro suficiente, os nmeros da conta e da agncia do cliente so enviados ao banco, que aprova ou desaprova a transao. Se a transao aprovada, a mquina libera a quantia correspondente e emite um recibo. Se a transao desaprovada, a extenso Informar Falha executada. O banco notificado, independentemente de uma transao aprovada ter sido completada ou no pela mquina. Se a transao completada, o banco realiza o dbito na conta do cliente (Bjork, 1998). Caso de Uso - Realizar Saque Sumrio: Este caso de uso possibilita a um cliente realize um saque de um caixa eletrnico Ator Primrio: Cliente Ator Secundrio: Banco Pr-Condies: Cliente autenticado Fluxo Principal 1. O caso de uso tem incio quando o ator Cliente seleciona a opo realizar saque 2. O sistema pergunta ao Cliente a quantia a ser retirada. {Especifica Valor} 3. O Cliente digita a quantia desejada. {Verifica Disponibilidade de Valor no Caixa} 4. Executa o sub-fluxo Avalia Quantia Disponvel. {Verifica Saldo Suficiente} 5. O sistema contata o ator banco para determinar se existe saldo suficiente na conta do Cliente. {Aprova Transao} 6. O sistema inicia uma transao com o ator banco e solicita a retirada da quantia desejada. 7. O sistema libera a quantia desejada 8. O sistema emite um recibo para o Cliente 9. O sistema fecha a transao com o ator banco. 10. O sistema armazena um log da transao. 11. O caso de uso se encerra. S1: Avalia Quantia Disponvel 1. O sistema determina se tem fundos suficientes mo para fornecer a quantia solicitada 2. O sistema verifica se a importncia requisitada maior do que a quantia disponvel. 3. O sistema verifica se a importncia desejada pode ser fornecida com as notas existentes no caixa eletrnico. (R$ 50,00 no podem ser fornecidos se s houver trs notas de R$ 20,00). Fluxos Alternativos A1 O cliente no digita a quantia desejada Em {Especifica Valor} se o ator cliente no especifica a quantia desejada 1. ... A2 O caixa automtico no pode fornecer a quantia solicitada Em {Verifica Disponibilidade de Valor no Caixa} se o caixa no tem disponibilidade de dinheiro para atender a solicitao do ator cliente. 1. O sistema reporta uma mensagem adequada 2. O caso de uso se encerra. A3 O link com o banco caiu Em qualquer ponto do fluxo principal. 1. ... A4 O Cliente no tem saldo suficiente Em {Verifica Saldo Suficiente} se o ator Cliente no tem recursos suficientes em sua conta para cobrir a retirada 1. O sistema reporta uma mensagem adequada 2. O caso de uso se encerra. A5 O banco no aprova a transao Em {Aprova Transao} se o ator Banco no aprova a transao devido violao de alguma regra de negcio (por exemplo: limite dirio excedido) 1. O sistema reporta uma mensagem adequada 2. Retorna ao fluxo principal.

Exerccio 4-4: qual a notao da UML para um caso de uso? Qual a notao da UML para um ator? Qual a notao utilizada na UML para o relacionamento de generalizao?

Exerccio 4-5: defina o que significa um ator. O que significa um ator estar associado a um caso de uso por um relacionamento de comunicao? Ator: Um ator define um papel que pode ser desempenhado por um usurio na sua interao com o sistema. Um usurio aqui pode ser um indivduo ou um outro sistema. Um mesmo usurio pode assumir vrios papis ao longo de sua interao com o sistema Uma lista de atores uma lista de papis e no uma lista de usurios. Atores esto fora do sistema, e normalmente fora do controle do sistema Conectando atores e casos de uso: Os atores e os casos do uso com os quais eles interagem so ligados pela associao de comunicao. A seta opcional, mas, quando usada, ela indica qual elemento comea a interao. Para entender plenamente o papel definido para um ator, voc deve saber em que casos de uso o ator est envolvido. Para entender plenamente o alcance de um caso de uso, voc deve saber os atores com os quais ele se comunica. Atores se comunicam com o sistema por muitas razes, incluindo: Iniciar um caso de uso. Os casos de uso sempre so iniciados por atores. Pedir alguns dados armazenados no sistema, os quais ento o caso do uso apresenta ao ator. Mudar os dados armazenados no sistema por meio de um dialogo com o sistema. Informar que ocorreu algo que o sistema deve estar ciente,. Um ator inicia um caso de uso. Entretanto, depois que o caso de uso comeou, ele pode se comunicar com vrios outros atores. Considera-se s vezes, erradamente, que a associao de comunicao representa o fluxo de dados. No isso. A associao de comunicao representa um dilogo entre o ator e o sistema, um tipo de canal de comunicao sobre o qual podem fluir dados em ambas as direes durante o dilogo. Casos de uso se comunicam com atores por muitos motivos: Se algo especial aconteceu no sistema, um ator pode ter de ser informado. Um caso de uso pode necessitar da ajuda de um ator para tomar uma deciso. Um caso de uso pode delegar responsabilidade a um ator.

Exerccio 4-6: qual o objetivo dos diagramas de casos de uso? O diagrama de casos de uso tem o objetivo de ilustrar em um nvel alto de abstrao quais elementos externos interagem com que funcionalidades do sistema. Nesse sentido, a finalidade de um DCU apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam. Exerccio 4-7: defina o conceito de requisito. Que tipos de requisitos existem? Explique o que realizado na fase de levantamento de requisitos de um sistema de informaes. Um requisito descreve uma condio ou capacidade a que um sistema deve se adaptar; eles podem ser derivados diretamente da necessidade de um stakeholder ou usurio ou extrados de um contrato, padro, especificao, ou outro documento formalmente imposto. s vezes til expressar tipos de requisitos diferentes: Requisitos Funcionais: Aes que o produto deve realizar de modo a fornecer funcionalidades teis para seus usurios. Estes requisitos definem as razes fundamentais para a existncia do produto. Exemplo: Software para uma central telefnica servindo a um prdio de apartamentos: O sistema deve emitir uma conta telefnica por apartamento considerando todas as ligaes realizadas pelo apartamento no ms, contendo as seguintes informaes:...

Requisitos no funcionais: So propriedades ou qualidades que o produto deve possuir Estes requisitos normalmente so relacionados funcionalidade do produto, ou seja, uma vez que saibamos o que o sistema deve fazer, podemos determinar como ele ir se comportar e que caractersticas de qualidade ele deve apresentar (por exemplo, performance e nvel de segurana desejado) Exemplo: Automvel acelerar, mudar marcha (requisitos funcionais) conforto, cor do painel de instrumentos (requisitos no funcionais)

Exerccio 4-8: que tipo de relacionamento possvel entre um ator e um caso de uso? Que tipo de relacionamento pode haver entre casos de uso? Que tipo de relacionamento pode haver entre atores? A tabela a seguir exibe as alternativas possveis entre relacionamentos entre atores e casos de uso em um diagrama de casos de uso. As clulas da tabela com um X indicam possibilidade. As clulas no preenchidas indicam impossibilidade.

Entre atores Entre casos de uso Comunicao Incluso Extenso Generaliza o X X X X

Entre ator e caso de uso X

Exerccio 4-9: descreva a(s) diferena(s) entre os relacionamentos de incluso, de extenso e de herana? If most systems can be fully described using only use cases with relationships only to their actors, what would force us to add relationships between use cases, especially when we have already noted that most teams get into trouble when they try to use them? The simple answer is that two forces draw us toward using relationships. One force is commonality in behavior between two or more use cases, and the other is reducing complexity by isolating portions of use cases that may apply only in specific circumstances. When common behavior occurs, gathering it into a use case of its own can lead to improved readability and consistency of description. Similarly, if some behavior applies only in very specific contexts, separating that behavior into a use case of its own can make the rest of the use case easier to understand. The trick is knowing when to separate behavior into its own use case and when to leave well enough alone. No matter whatand we cannot emphasize this enoughdo not introduce relationships between use cases until you have at least a draft of the flow of events of the use cases. Outlining may seem sufficient, but it often lacks the detail necessary to see commonality (in the case of inclusion) or variation (in the case of extension). The only reason for introducing relationships is to deal with commonality and variations in the flows of events of the use cases; if you introduce them earlier, you are doing so without any real knowledge. Once you have at least drafted the use-case descriptions, commonality and variations will become obvious and you may safely proceed, provided that introducing the relationships will increase the understandability of the use-case descriptions. Use Case Modeling Ian Spence & Kurt Bittner,

O relacionamento Include:

1.

Um relacionamento include permite extrair sees comuns da descrio de dois ou mais casos e coloc-las em um caso de uso separado a partir do qual elas podem ser referenciadas. Cada caso de uso original passa a ter ento um relacionamento includes com o novo caso de uso;

O relacionamento Extend:

O relacionamento extend usado em casos onde comportamento opcional ou excepcional inserido em um caso de uso existente. O propsito original da extenso era fornecer um mecanismo para especificar opes que pudessem ser adicionadas a um produto existente tais como: adicionar o envio de e-mails por voz a um servio telefnico convencional existente. til pensar no relacionamento de extenso como um relacionamento de acrscimo, uma vez que ele sempre acrescenta funcionalidade a um caso de uso existente. A caracterstica marcante do caso de uso que estende um caso de uso original que ele no demanda nenhuma alterao no caso de uso original. Isto significa que o caso de uso estendido deve ser capaz de se virar sozinho. Ele deve ser completo, sem qualquer necessidade de extenses a fim de gerar valor. As seguintes situaes podem dar margem utilizao do extend: Descries de caractersticas que so opcionais ao comportamento bsico do sistema, por exemplo, caractersticas que podem ser adquiridas ou no. Descries complexas de erros ou tratamentos de excees que, de outra forma, iriam obscurecer o comportamento primrio do sistema. Exemplos disso so fluxos alternativos de tamanho significativo, especialmente aqueles cujo tamanho maior do que o do fluxo principal. Customizao do modelo de requisitos para atender a necessidades especficas do usurio. Exemplos disso so fluxos alternativos que especificam como usurios especficos tratam diferentes condies que ocorrem dentro de um mesmo caso de uso. Gerncia de escopo e verso. Um exemplo disso so caractersticas que no sero introduzidas at as ltimas verses.

Em contraste ao relacionamento include, um relacionamento extend conhece necessariamente o caso de uso que ele estende. Conceitualmente, o mecanismo de extenso idntico aquele dos fluxos alternativos. Um caso de uso de extenso, assim como um fluxo alternativo, insere a si prprio no fluxo do caso de uso que ele estende. Somente o caso de uso de extenso conhece o ponto no caso de uso base onde o comportamento ser

inserido. Em conseqncia, freqentemente um caso de uso de extenso comea sua vida como um fluxo alternativo. Nem todo fluxo alternativo deve virar um caso de uso de extenso. As regras para os fluxos alternativos so mais frouxas do que aquelas para os casos de uso de extenso. Devido ao fato de que os fluxos alternativos so parte do caso de uso, eles podem explorar seu conhecimento do estado do caso de uso, suas pr-condies, e outros fluxos de eventos para terminar o caso de uso ou para continuar o fluxo do caso de uso em pontos de extenso diferentes daquele onde eles assumiram o controle. Tudo o que os casos de uso de extenso conhecem a respeito do caso de uso original o ponto de extenso onde eles introduziram a si prprios no fluxo de eventos do caso de uso estendido.

Generalizao entre Casos de Uso A generalizao entre casos de uso nos permite criar descries genricas de comportamento que podemos especializar para satisfazer necessidades particulares.

Generalizao entre atores A generalizao entre atores usada para mostrar semelhanas entre atores. O principal valor mostrar que alguns grupos de atores compartilham responsabilidades ou caractersticas comuns. Algumas vezes, o uso de generalizao entre atores pode simplificar o modelo de casos de uso reduzindo o nmero de linhas de comunicao entre atores e casos de uso. Na maioria das vezes, no entanto, ela de nenhuma utilidade. O uso de generalizao entre atores tipicamente um sintoma de que os modeladores confundiram papis com cargos da organizao.

No revi as respostas daqui em diante... Jonas

Exerccio 4-10: considere um sistema de controle de uma biblioteca. Fornea a descrio narrativa para os seguintes casos de uso: Reservar Livro (situao em que um usurio faz a reserva de um livro), Obter Emprstimo de Livro (situao em que um usurio pega um exemplar de livro emprestado), Cancelar Reserva (situao em que um usurio cancela uma reserva) e Devolver Cpia (situao em que um usurio devolve uma cpia anteriormente adquirida). Observao: Pessoalmente, tenho dvidas se Reservar Livro e Cancelar Reserva so dois casos de uso distintos. Acho que so fluxos diferentes do mesmo caso de uso: Manter Reserva

Caso de Uso - Reservar Livro

Sumrio: Este caso de uso possibilita a um usurio da biblioteca fazer a reserva de um livro. Esta reserva efetuada diretamente pelo Usurio usando a Internet. Ator Primrio: Usurio Pr-Condies: O Usurio cadastrado na Biblioteca. O Usurio j foi autenticado pelo Sistema. Fluxo Principal 1. O caso de uso tem incio quando o ator usurio decide reservar um livro e escolhe a opo correspondente. {Localizar livro} 2. Usurio fornece a identificao do livro desejado 3. O sistema localiza o livro desejado {Verificar disponibilidade de exemplar} 4. O sistema verifica a disponibilidade de exemplar do livro desejado {Verifica reservas em aberto} 5. O sistema verifica o nmero de reservas em aberto para o usurio (RN01) 6. O sistema efetua a reserva e informa ao usurio o prazo mximo para a retirada do livro (RN02) 7. O caso de uso se encerra Fluxos Alternativos A1 No existe nenhum exemplar disponvel

Em {Verificar disponibilidade de exemplar} se no existe exemplar disponvel para reserva a. O sistema reporta uma mensagem adequada para o usurio e informa a data prevista para que haja um exemplar disponvel b. O sistema pergunta ao usurio se ele deseja efetuar a reserva de exemplar emprestado c. Se o usurio responder afirmativamente, agenda a reserva e reporta uma mensagem informando que o usurio ser contatado quando o exemplar estiver disponvel, caso contrrio o caso de uso se encerra. A2 O usurio excedeu o nmero mximo de reservas em aberto Em {Verifica reservas em aberto} se o usurio excedeu o nmero mximo permitido de reservas (RN01) a. O sistema reporta uma mensagem adequada para o Usurio b. O Caso de Uso se encerra A3 A biblioteca no possui o livro desejado Em {Localizar livro} se a biblioteca no tem o livro desejado a. O sistema reporta uma mensagem adequada para o Usurio b. O Caso de Uso se encerra

Obter Emprstimo de Livro

Sumrio: Este caso de uso possibilita a um usurio pegar emprestado um exemplar de livro. Ator Primrio: Bibliotecria Pr-Condies: Bibliotecria identificada. A Bibliotecria tem em mos o exemplar a ser emprestado. Fluxo Principal 1. A Bibliotecria entra com a identificao do exemplar e do usurio. 2. O sistema verifica a existncia de reservas para o exemplar desejado 3. O sistema verifica a existncia de emprstimos em aberto para o usurio. 4. O sistema verifica o nmero de exemplares em poder do usurio (RN03) 5. O sistema registra o emprstimo e imprime um recibo contendo os dados do emprstimo 6. O caso de uso se encerra Fluxo Alternativo (2): J existe uma reserva do exemplar desejado para outro usurio a. O sistema reporta uma mensagem adequada para a bibliotecria b. O caso de uso se encerra Fluxo Alternativo (2): O exemplar estava reservado para o prprio usurio a. O sistema d baixa na reserva b. Retorna ao passo (3) Fluxo Alternativo (3): O usurio tm emprstimos em aberto a. O sistema reporta uma mensagem adequada b. O caso de uso se encerra Fluxo Alternativo (4): O usurio excedeu o nmero mximo de emprstimos a. O sistema reporta uma mensagem adequada b. O caso de uso se encerra Cancelar Reserva Sumrio: Este caso de uso possibilita a um usurio cancelar uma reserva. O prprio usurio, usando a Internet, registra o cancelamento. Ator Primrio: Usurio Pr-Condies: O Usurio cadastrado na Biblioteca. O Usurio j foi autenticado pelo Sistema. Fluxo Principal: 1. O usurio solicita sua lista de reservas 2. O sistema apresenta a lista de reservas 3. O usurio seleciona a reserva a ser cancelada 4. O sistema pede a confirmao do usurio para cancelar a reserva 5. O usurio confirma o cancelamento 6. O sistema cancela a reserva 7. O sistema mostra para o usurio a lista de reservas atualizada e oferece ao usurio a opo de efetuar novo cancelamento ou encerrar o caso de uso. Fluxo Alternativo (2): O usurio no tem reservas em seu nome a. O sistema reporta uma mensagem apropriada b. O caso de uso se encerra Fluxo Alternativo (5): o usurio no confirma o cancelamento da reserva a. Volta para o passo 2 Devolver Cpia Sumrio: O usurio devolve um exemplar em seu poder Ator Primrio: Bibliotecria Pr-Condies: Bibliotecria identificada. A Bibliotecria tem em mos o exemplar a ser devolvido. Fluxo Principal: 1. A bibliotecria entra com o cdigo do exemplar

2. O sistema apresenta o registro do emprstimo 3. A bibliotecria confirma a devoluo 4. O sistema registra a devoluo 5. O sistema verifica se houve atraso na devoluo 6. O sistema verifica a existncia de reservas agendadas para o exemplar devolvido 7. O caso de uso se encerra Fluxo Alternativo (5): devoluo em atraso a. O sistema calcula o nmero de dias em atraso e a multa a ser paga (RN04) b. O sistema reporta uma mensagem apropriada c. A bibliotecria registra o pagamento da multa d. Volta ao passo 6 Fluxo Alternativo (6): existem reservas agendadas para o exemplar devolvido a. Executa o Caso de Uso Efetivar Reserva Agendada b. Volta para o passo 7

Glossrio
Emprstimo em Aberto: emprstimo vencido e no devolvido Dados do Emprstimo: ttulo do livro, cdigo do exemplar, data do emprstimo, data da devoluo

Regras de Negcio
RN01: Um Usurio no pode ter mais de duas reservas em aberto em seu nome. RN02: O prazo mximo para a retirada de um livro reservado de dois dias. RN03: Um Usurio pode ter no mximo trs exemplares em seu poder num determinado instante de tempo. RN04: A multa a ser aplicada de R$ 1,00 por dia til de atraso. Exerccio 4-11: durante a execuo de um caso de uso, podem ocorrer excees. Considere o caso de uso Realizar Pedido, no qual pode ser que o cliente solicite um produto que est fora de estoque. Como voc modelaria tal situao? Desenhe um diagrama de casos de uso. Realizar Pedido Fluxo Principal: ... O usurio entra com a identificao do produto O sistema verifica no estoque a disponibilidade do produto pedido O sistema acrescenta o produto ao carrinho de compras do usurio ... Fluxo de Exceo (...): O produto solicitado no existe em estoque O sistema reporta uma mensagem apropriada ...

Exerccio 4-12: construa o modelo de casos de uso para a seguinte situao. Tente identificar tambm regras de negcio que se apliquem situao, de acordo com o texto fornecido. Uma rede de televiso est requisitando um sistema para gerenciar informaes sobre uma de suas produes televisivas (por exemplo, uma minissrie ou uma novela). Uma produo televisiva tem uma verba e composta de cenas. Cenas so escolhidas em uma determinada seqncia. Cada cena tem uma durao em minutos e gravada em uma ou mais fitas. Cada fita possui um nmero de srie e uma capacidade (medida em minutos que podem ser gravados na mesma). Deseja-se saber em que fita(s) se encontra uma determinada cena. Cada cena pode ter sido gravada muitas vezes (futuramente, na edio da obra, o produtor selecionar uma dessas tomadas de cena para compor a verso final da produo televisiva). Deve-se manter o registro de todas as cenas filmadas, de quais atores e dubls participaram de cada cena. Deseja-se saber tambm, que dubl substituiu que ator em cada cena. Para uma produo televisiva como um todo, deseja-se manter a informao de quais outros funcionrios, os chamados funcionrios de apoio, participaram das filmagens. Esses funcionrios podem ser de diversos tipos (cmeras, iluminadores, contra-regras etc.). Alm disso, pode haver funcionrios de apoio que exeram mais de uma funo na mesma produo televisiva. Atores e dubls negociam seus salrios individualmente, em cada produo televisiva em que participam. Os demais funcionrios tm um salrio fixo por funo. necessrio tambm armazenar essas informaes para ter uma idia do consumo de recursos em relao verba. Aps o trmino de uma obra, o sistema deve produzir um relatrio com o valor a ser pago para cada funcionrio. O sistema tambm deve produzir um relatrio de informaes sobre as cenas de uma obra televisiva, e sobre que atores, dubls e demais funcionrios participaram dessa obra televisiva.

Atores Produtor Modelo de Casos de Uso

Casos de Uso Principais:

CSU01: Obter informaes sobre cenas Sumrio: Atravs deste caso de uso o ator obtm informaes sobre uma cena (gravaes efetuadas, atores e dubls que participaram de cada cena, fitas onde foram gravadas as cenas, etc.) CSU02: Obter informaes sobre funcionrios que participam da produo Sumrio: Relao de funcionrios que participaram das filmagens, funes exercidas, salrios pagos, etc. CSU03: Gerar relao de cenas Sumrio: Relao de cenas segundo o nmero de seqncia, contendo informaes tais como: sinopse, durao, personagens envolvidos, nmero de gravaes efetuadas, datas das gravaes, gravao escolhida, etc.

Casos de Uso Secundrios:

Casos de Uso CRUD (Create, Read, Update, Delete). Exemplos: Cadastrar Produo (Registrar detalhes da produo: verba, ttulo, etc.) Cadastrar Cena (Registrar detalhes de uma cena: durao, locao, personagens, etc.) Registrar Gravao de Cena (data, locao, atores envolvidos, dubls utilizados, fitas gravadas, etc.) Cadastrar Fita (numero de srie, capacidade, etc.) Cadastrar Funo (funes necessrias produo: descrio, salrio, etc.) Cadastrar Funcionrio (registrar participao do funcionrio na produo: funes exercidas) Cadastrar Ator (registrar participao de ator: dados pessoais, salrio negociado, etc.) Cadastrar Dubl (registrar participao de dubl: dados pessoais, salrio negociado, etc.) Regras de Negcio 1. Um funcionrio pode exercer mais de uma funo na produo 2. Uma fita no pode ser usada para a gravao de mais de uma cena nem para gravaes diferentes de uma mesma cena 3. ... Exerccio 4-13: o seguinte documento de requisitos foi adaptado do livro (Wirfs-Brock et aI, 1991). Leia o texto com ateno. A seguir, elabore um modelo de casos de uso inicial para o sistema. O GNU Editor um editor grfico interativo. Com ele, usurios podem criar e editar desenhos compostos de linhas, retngulos, elipses e texto. H dois modos de operao do editor. Apenas um modo de operao est ativo em um dado momento. Os dois modos de operao so: modo de seleo e modo de criao. Quando o modo de seleo est ativado, os elementos grficos podem ser selecionados com o cursor do mouse. Um ou mais elementos grficos podem ser selecionados e manipulados; se vrios elementos grficos forem selecionados, eles podem ser manipulados como se fossem um nico elemento grfico. Elementos que tenham sido selecionados desse modo so definidos como a "seleo atual". A seleo atual indicada visualmente atravs da exibio dos pontos de controle para o elemento. Um clique seguido de um arrasto de mouse sobre um ponto de controle modifica o elemento ao qual o ponto de controle est associado. Quando o modo de criao est ativado, a seleo atual est vazia. O usurio pode selecionar um objeto grfico a partir de um conjunto de objetos grficos predefinidos. A criao de um elemento de texto: a posio do primeiro caractere do texto determinada pela posio na qual o usurio clica o boto do mouse. O modo de criao desativado quando o usurio clica o mouse fora do elemento de texto. Os pontos de controle para um elemento de texto so posicionados nos quatro cantos da regio em que o texto inserido. O arrasto desses pontos de controle muda a regio. Os outros elementos que podem ser criados pelo usurio so linhas, retngulos e elipses. O elemento apropriado comea quando o boto do mouse pressionado e se completa quando o boto do mouse liberado. Esses dois eventos criam o "ponto de partida" e o "ponto de parada" A "criao de linha" define uma linha do ponto de partida at o ponto de parada. Esses so os pontos de controle. O arrasto de um ponto de controle modifica o ponto extremo correspondente. A "criao de retngulo" define um retngulo tal que dois dos cantos do retngulo diametralmente opostos do retngulo correspondem ao ponto de partida e ao ponto de parada. Os cantos do retngulo formam os pontos de controle. O arrasto de um ponto de controle modifica o canto correspondente. A "criao de elipse define uma elipse que est contida dentro de um retngulo definido pelos dois pontos definidos acima. O raio maior da elipse metade do comprimento do retngulo, e o seu raio menor metade da altura do retngulo. Os pontos de controle so os cantos do retngulo que contm a elipse. O arrasto de um ponto de controle modifica o canto correspondente. Ser assumido que o programa deve fornecer uma tela grfica do diagrama sendo criado, e que um mouse e um teclado sero utilizados como dispositivos de entrada.

Exerccio 4-14: considere a seguinte declarao obtida de um gerente de uma empresa que comercializa livros por correio durante o levantamento de requisitos para construo de um sistema de software: "Aps a ordem de compra do cliente ter sido registrada, o vendedor envia uma requisio ao depsito com detalhes da ordem de compra." Quais atores em potencial podem ser identificados a partir desse texto? Considerando-se somente o trecho fornecido no exerccio, podem ser identificados 3 atores em potencial, a saber: Cliente, Vendedor e Depsito. O primeiro o ator primrio e os dois ltimos so atores secundrios. O nome do caso de uso correspondente poderia ser Comprar Produtos. Exerccio 4-15: considere o exemplo de relacionamento de extenso entre casos de uso apresentado na Seo 4.1.3.3 , que descreve relacionamentos de extenso entre os casos de uso Editar Documento e os extensores Corrigir Ortografia e Substituir Texto. Desenhe um diagrama de casos de uso para essa situao. Como voc faria para estender seu diagrama de casos de uso com um novo requisito, a saber, permitir que o editor de textos possibilite a criao de um ndice remissivo sobre um documento sendo editado?

Exerccio 4-16: em uma empresa, vrios projetos so realizados. Os cinqenta empregados da empresa trabalham em pelos menos um projeto. H um sistema implantado na empresa que permite aos participantes de um determinado projeto marcarem suas horas de trabalho. Esse sistema tambm permite

que outra pessoa, ao fim do ms, gere os relatrios com os totais de horas trabalhadas de cada participante. Quantos atores voc definiria para esse sistema? E quantos papis? Na situao descrita neste exerccio, pode-se definir um ator denominado Empregado . Este seria o ator primrio no caso de uso Registrar Horas Trabalhadas. Podemos tambm criar um ator denominado Gerncia. que seria o ator primrio no caso de uso Obter Horas Trabalhadas. O diagrama de casos de uso a seguir ilustra a soluo aqui descrita.

Exerccio 4-17: O TurboNote+ um programa shareware que permite aos seus usurios criar mensagens de lembrete que permanecem na rea de trabalho de seus computadores. (Esse programa funciona como uma verso eletrnica daqueles bloquinhos de papel cujas folhas podem ser afixadas na parede.) Ao criar uma nova folhinha no Turbo-Note+, o usurio pode preench-la com texto. As folhinhas podem ser movidas pela rea de trabalho, conforme a vontade do usurio. As folhinhas permanecem na rea de trabalho. Toda vez que o usurio inicia o seu computador, as folhinhas esto l, na rea de trabalho. Quando no so mais necessrias, as folhinhas podem ser removidas. Se o usurio escrever uma expresso aritmtica em uma folhinha, o resultado da expresso exibido. Desenhe o diagrama de casos de uso para o TurboNote+.

No Confunda Casos de Uso com "Funes" A infeliz semelhana visual entre diagramas de caso de uso e diagramas de fluxos de dados s vezes leva as pessoas a definir casos de uso que so em verdade apenas funes ou itens de menu. Qualquer que seja a razo, este provavelmente o erro mais freqente cometido pelos iniciantes em modelagem usando casos de uso. Veja Figura 4-5. A figura 4-5. Uso incorreto de casos de uso como opes de menu ou funces O que h de errado com Figura 4-5? Pense novamente na nossa definio de uma descrio de uso-caso (um relato sobre algum meio de usar o sistema para fazer algo til). Os casos de uso acima so todos, independentemente, teis? A resposta, naturalmente, no. A figura retrata coisas que o sistema deve fazer, mas elas so todas relacionadas a uma nica coisa que o cliente quer fazer no sistema: fazer pedidos. Todas as coisas restantes so fluxos alternativos deste caso de usoso coisas que podem so feitas no curso de fazer um pedido. Onde h s uma coisa til a ser feita, h s um caso de uso. A soluo mostrada na Figura 4-5 um exemplo de decomposio funcional, ou (como diz um colega meu) um exemplo dos "vages em formao circular - um ator no centro de um crculo de casos de uso. Este problema muito comum. Por que as pessoas so levadas a este tipo de soluo? Temos uma necessidade intrnseca para ordenar as coisas e, onde no existe nenhuma ordem, tentamos imp-la. No caso da decomposio funcional, temos uma tendncia natural a tentar quebrar o problema em pedaos cada vez menores, numa crena ingnua de que assim procedendo podemos simplificar o problema. Esta percepo est errada; quando decompomos casos de uso, ns realmente complicamos o problema.

Eis por que. O propsito de um caso de uso descrever como algum ou alguma coisa usar o sistema para fazer algo que til para ele. Ele descreve o que o sistema faz num nvel conceitual de modo que podemos entender bastante sobre o sistema para decidir se o sistema se comporta corretamente ou no. Ele nos ajuda a formar um modelo conceitual do sistema. Agora pergunte a si mesmo: voc vai querer usar este sistema somente para investigar o estado de um pedido se eu nunca fiz um pedido? No muito provvel. Ou, eu vou querer mudar um pedido se eu nunca fiz um pedido? No, provavelmente no. Todas estas coisas so teis para mim somente se eu fiz um pedido; todos eles so necessrios para prover a capacidade do sistema de me permitir fazer um pedido. Decompor o sistema em casos de uso menores realmente obscurece o propsito real do sistema; no extremo, ns acabamos com uma quantidade enorme de pedaos de comportamento, desconexos e isolados. Ns no podemos dizer o que o sistema faz. como olhar um carro que foi desmontadotalvez voc possa dizer que um carro, e voc sabe que as partes devem ser teis de alguma forma, mas voc realmente no pode dizer como. Quando trabalhar com casos de uso, lembre-se que casos de uso so um meio de pensar no sistema total e organiz-lo em pedaos administrveis de funcionalidade pedaos que fazem algo til. Para obter o jogo correto de casos de uso, pergunte a si mesmo: "o que os atores realmente esto tentando fazer com este sistema?" Caso voc esteja se perguntando como a verso melhorada da Figura 4-5 se pareceria, observe a Figura 4-6. Estes dois casos de uso incluiriam todas as "funes" que o diagrama anterior separou em casos de uso. Voc pode perguntar por que isto melhor. A resposta simplesela foca no valor que o cliente quer do sistema, e no em como subdividimos e estruturamos a funcionalidade dentro do sistema. Exerccio 4-18: suponha que um sistema de vendas deve gerar de forma automtica um conjunto de estatsticas para a diretoria da empresa no ltimo dia til de cada ms. Desenhe o diagrama de casos de uso para essa situao. H mais de uma maneira de represent-la?

Exerccio 4-19: Na utilizao da Internet, normalmente um usurio utiliza um programa navegador (browser) que, por sua vez, se comunica com um ou mais servidores Web para fornecer as pginas nas quais o usurio est interessado. O que est errado no diagrama a seguir? Desenhe novos diagramas para representar corretamente a situao, considerando duas alternativas de escopo. Na primeira, o programa navegador o sistema. Na segunda, a Internet o sistema.

O erro do diagrama est no fato de que atores no se comunicam em um diagrama de casos de uso. Na primeira alternativa de escopo (o sistema o browser), o sistema sendo modelado tem que se comunicar (interagir) com dois atores no caso de uso Obter URL: Usurio da Internet e Servidor WEB. Na segunda alternativa de escopo (o sistema a Internet), o prprio servidor WEB faz parte do sistema sendo modelado e por conta disse no deve ser representado como um ator. Os dois diagramas de casos de uso a seguir ilustram as duas alternativas diferentes.

Exerccio 4-20: assinale V ou F para as seguintes assertivas: ( ) pessoas com o mesmo cargo em uma empresa podem representar papis de diversos atores.

( ) um ator pode representar pessoas de diferentes cargos. A primeira e a segunda assertiva so verdadeiras. Na verdade essas assertivas so formas diferentes de declarar a mesma informao: um ator representa um papel em relao ao sistema. Considere o exemplo do exerccio 4-16. Pode haver uma pessoa que seja um funcionrio comum em um certo projeto, alm de ser o gerente em outro projeto. Neste caso, a mesma pessoa assumir papis diferentes em instantes distintos em relao ao sistema. Exerccio 4-21: altere os seguintes "nomes de casos de uso" de acordo com as nomenclaturas apresentadas neste captulo: a) Cliente realiza transferncia de fundos em um caixa eletrnico. b) Clientes compram livros na livraria. c) produzido um relatrio de vendas para o gerente. d) Hspede se registra em um hotel. A seguir, so apresentados os nomes de casos de uso de acordo com a nomenclatura adotada no livro. Possveis nomes para atores primrios em cada situao so tambm fornecidos. Deve-se enfatizar, no entanto, que isso somente uma conveno de nomenclatura. Outras convenes podem ser usadas. a.Transferir Fundos b.Comprar Livros c. Obter Relatrio de Vendas d.Abrir Estadia Cliente Usurio Gerncia Hspede

Exerccio 4-22: desenhe diagramas de casos de uso para os seguintes sistemas: a) A biblioteca de sua universidade. b) O seu aparelho celular. c) Um sistema de validao de cartes de crdito. Exerccio 4-23: suponha que exista um caso de uso Pagar Pedido em um sistema, que realizado pelo ator Cliente. Neste caso de uso, o cliente realiza o pagamento de um pedido realizado em algum momento do passado. Considerando este caso de uso, voc pode pensar em algum outro caso de uso do sistema? Exerccio 4-24: considere o modelo de casos de uso inicial para o Sistema de Controle Acadmico (Seo 4.7.3). Modifique esse modelo para contemplar as seguintes novidades: a. O coordenador informa equipe de desenvolvimento que h datas inicial e final pr-estabelecidas dentro de um semestre para que um professor possa lanar notas ou fornecer sua disponibilidade de carga horria para semestre letivo seguinte. E o prprio coordenador que deve estabelecer essas datas. b. Da mesma forma, h um perodo para realizao de inscries e outro para cancelamentos das mesmas. Fora desses perodos, o sistema no deve aceitar tais operaes. O coordenador tambm deve ter a possibilidade de definir esses perodos. c. O coordenador declara que precisa ser informado pelo sistema (por e-mail, por exemplo) quando este ltimo cria uma nova lista de espera para uma determinada disciplina. Exerccio 4-25: considere novamente o Sistema de Controle Acadmico. Suponha que o analista de sistemas identificou uma nova regra de negcio, descrita a seguir: Inscrio em Projeto Final (RN07) Descrio: Para se inscrever na disciplina de "Projeto Final de Curso", o aluno precisa ter, no mnimo, 100 crditos concludos. Para contemplar essa regra do negcio, o analista de sistemas resolveu criar um caso de uso Realizar Inscrio em Projeto Final e faz-lo herdeiro do caso de uso Realizar Inscrio, atravs de um relacionamento de generalizao. Veja a figura a seguir. Discuta essa soluo. Ela correta? Fornea a descrio do caso de uso herdeiro.